背景
服務網格 Istio 於 8 月 31 日發布 1.31 版本。根據 InfoQ 的報導，這個版本有兩個值得關注的重點：一是正式支援以 agentgateway 作為 ambient mesh 模式下的 Layer 7 waypoint proxy，二是專案將所有容器映像與 Helm chart 的發布位置從 Google Cloud 移出，轉移到新的託管環境。前者關係到 Istio 如何處理日益增長的 AI agent 流量，後者則要求所有使用者在今年底之前完成遷移，否則將無法正常拉取映像與套件。
在說明新功能之前，需要先理解兩個背景概念。Ambient mesh 是 Istio 近年主推的新架構，它捨棄了傳統在每個 Pod 注入 sidecar proxy 的做法，改以節點層級的 ztunnel 處理加密傳輸，再搭配按需部署的 waypoint proxy 提供七層流量管理能力。Waypoint proxy 的作用是攔截特定服務或命名空間的流量，執行路由、政策與觀測等功能。Agentgateway 則是由 Solo.io 開發並捐贈給 Linux Foundation 的資料平面，以 Rust 語言實作，除了處理一般 HTTP 流量外，還原生支援 Model Context Protocol 等 agent 通訊協定，也就是說它是針對 AI agent 之間、以及 agent 與工具之間的流量所設計的代理層。Istio 1.30 已經加入實驗性的 gateway-only 整合，1.31 則把它延伸到 waypoint 角色。
Agentgateway 作為 Waypoint 的運作方式
在 Istio 1.31 中，團隊可以透過新的 istio-agentgateway-waypoint GatewayClass，將 agentgateway 部署為 ambient mesh 裡的七層 waypoint proxy。這代表使用 Kubernetes Gateway API 的標準方式即可宣告 waypoint，而底層實際執行的是 agentgateway 而非預設的 Envoy。這個版本同時修正了 ListenerSet 的處理邏輯，以及 agentgateway 後端之間的 mTLS 連線問題，補強了整合的完整性。
與 waypoint 支援搭配出現的還有一套新的流量切分機制，目前標示為 alpha 階段。服務或命名空間可以透過 use-waypoint-canary 標籤指定一個 canary waypoint，再用 use-waypoint-canary-weight 註解設定要導向 canary 的新連線比例，整個過程不需要修改用戶端。維護團隊明確警告這些標籤、註解與行為未來可能變動。另外有一個實務上必須知道的限制：既存連線不會被搬移，因此長連線較多的場景中，實際觀察到的流量分配可能明顯落後於設定值。
這個切分機制在初期版本中有一個實際的缺陷，並在 9 月 21 日釋出的 Istio 1.31.1 中被修正。原本的問題是：僅被引用為 canary 的 agentgateway waypoint 不會被套用對應服務的路由與政策設定，導致被切分過去的連線直接被拒絕。1.31.1 除了修掉這個問題，也包含安全性修正，並修正了 IPv6-only 叢集中 ALLOW_ANY_DYNAMIC_DNS 轉發行為的錯誤。
其他值得注意的技術更新
針對大型網格，1.31 在流量管理上有兩個實用的補強。第一是 DestinationRule 與 MeshConfig 新增 zoneAwareLbSetting 欄位，讓 Envoy 優先把流量送到與下游 proxy 同一可用區的端點，只有在本地容量不足時才外溢到其他區域。與既有的 localityLbSetting 相比，差異在於外溢與否由 Envoy 依即時狀況自動判斷，而不是依賴靜態百分比設定，對跨區流量成本與延遲的控管更為彈性。第二是輸出模式新增 ALLOW_ANY_DYNAMIC_DNS，會在請求時依 HTTP Host 標頭即時解析主機名稱，省去為每一個外部目的地逐一撰寫 ServiceEntry 的負擔。
安全面上，COMPLIANCE_POLICY 環境變數新增 fips-140-3 選項，啟用後 TLS 會被限制在 1.2 以上版本，並只允許 FIPS 相容的加密套件與 P-256、P-384 曲線。不過發布說明特別指出，僅設定執行期政策並不足夠，Go 組件必須以 Go 1.24 或更新版本、搭配 GOFIPS140=v1.0.0 或後續驗證版本建置，才算符合要求。另外 AuthorizationPolicy 新增 trustDomains 與 notTrustDomains 欄位，可依對端憑證中的 trust domain 比對或排除請求，讓跨網格、多信任域的授權控制更細緻。
Istio 1.31.0 支援的 Kubernetes 版本範圍為 1.32 至 1.36。
發布成品遷移的影響與時程
本次發布最迫切的行動項目其實不在新功能，而是託管位置的變更。根據 Istio 部落格 8 月 21 日的文章，來自 Microsoft 的 Steven Jin 與來自 Solo.io 的 Keith Mattix 表示，因為資金模式的改變，Istio 今年將把所有基礎設施從 Google Cloud Platform 遷移到 Amazon Web Services。仍在使用 gcr.io/istio-release、registry.istio.io 或 Google 託管 Helm 儲存庫的團隊必須儘早更新設定。
專案採用俗稱 scream test 的停機測試來找出尚未遷移的使用者：下一次測試排定於 10 月 13 日 15:00 至 18:00 UTC 暫停舊端點，最終測試從 12 月 8 日 15:00 UTC 持續到 12 月 9 日 15:00 UTC，之後舊端點將正式退役。驗證映像簽章的團隊還要注意金鑰輪替：遷移指引列出 1.31.0 使用 istio-key.pub，1.31.1 起改用 istio-key-v2.pub。
至於新託管位置的選擇，Jin 在 GitHub 追蹤議題上被問到為何選 Docker Hub 而非 GHCR 時回應，GHCR 存在一些未公開記載的限制，以專案目前的使用量很容易超過那些上限。這個決策反映的是大型開源專案在工件分發上的現實考量：速率上限與配額往往比功能本身更關鍵。
影響與限制
整體來看，Istio 1.31 呈現出兩條並行的發展方向。技術面上，把 agentgateway 納入 waypoint 角色，顯示服務網格正嘗試把 AI agent 流量納入既有的流量管理與安全框架，而不是讓它游離在網格之外；不過 canary 切分仍屬 alpha，行為可能變動，長連線場景的切分延遲與 1.31.0 的路由缺陷都提醒使用者不宜過早投入生產環境。基礎設施面上，從 GCP 到 AWS 的遷移是硬性時程，10 月的 scream test 與 12 月的退役日期意味著尚未調整拉取來源、簽章金鑰與 Helm 儲存庫設定的團隊，最晚在今年底前勢必遭遇中斷。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。