Cilium 1.20 的發布，把幾個原本分散的 Kubernetes 網路課題放在同一個版本裡處理：Gateway API 的功能覆蓋範圍、eBPF 資料路徑的可擴充性、混合核心版本叢集的網路裝置選擇，以及無 sidecar 雙向 TLS 的身分來源。根據 InfoQ 報導，Cilium 工程師 Nico Vibert 與 Donia Chaiehloudj 在發布公告中說明這些變更，並將 Gateway API 描述為「更廣泛的流量管理層」。
從 Ingress 退役到 Gateway API 的角色分工
這波變化的背景，是 Kubernetes 社群逐步把 Gateway API 視為 Ingress 之後的正式方向。原有 Ingress NGINX 控制器已退役，社群建議組織轉向 Gateway API；AWS 的 Load Balancer Controller 也已經正式支援 Gateway API，透過 Application Load Balancer 處理 HTTP 與 gRPC，透過 Network Load Balancer 處理 TCP 與 UDP。Gateway API 的設計重點不只是替換註解式的 Ingress，而是把「基礎設施提供者」與「應用團隊」的角色切開，讓共享閘道與個別路由的所有權可以分離。Cilium 的差異在於同一個專案就能提供 CNI、Service 網路與閘道功能，不需要再把多個元件拼裝起來。
Gateway API 1.6 帶進的新能力
Cilium 1.20 將支援的 Gateway API 版本從 1.4 推進到 1.6，新增 ExternalAuth、ListenerSets、CORS 過濾、TCPRoute 與 UDPRoute。ExternalAuth 讓 HTTPRoute 在把請求送往應用之前，先向外部授權服務查詢；閘道可依回應決定放行、把使用者導向登入頁，或直接拒絕請求。授權服務還能將身分標頭傳給後端應用，等於把驗證與授權邏輯從應用程式碼裡抽出來，交由基礎設施層統一處理。TCPRoute 與 UDPRoute 的意義則是讓純第四層流量不必再退回 LoadBalancer 或 NodePort Service，資料庫、DNS 這類非 HTTP 服務也能走同一套 Kubernetes API。
ListenerSets 處理的是另一個層次的問題：所有權。應用團隊可以在自己的命名空間新增 listener，平台團隊仍掌握共享 Gateway 的控制權，並決定哪些命名空間有權擴充。平台工程師 Mohamed Salem BEN ATAIA 在 LinkedIn 上評論，這補上了「團隊擁有 Route、但新增主機名稱或連接埠卻得回頭請平台改設定」的落差，他的評語是這消除了平台瓶頸。
打開 eBPF 資料路徑
第二個主要變更是把 eBPF 資料路徑開放給第三方插件。過去雲端供應商若需要自訂的觀測或網路行為，只能把變更貢獻回上游，或自行維護一份 fork，兩種做法都伴隨長期的合併與維護成本。現在插件以獨立行程運行，可以獨立建置、版本化與升級，Cilium 透過一個小型 custom resource 與 gRPC 介面與之溝通。這批資料路徑插件由 Google 開發，Vibert 與 Chaiehloudj 的形容是，這讓 Cilium 更像一套網路作業系統，而不是封閉的網路設備。
這項機制目前是 beta，並未被定位成一般叢集使用者可任意使用的通用擴充系統。Cilium 文件明確指出，它鎖定的是對 Cilium 內部運作有深入理解的維運者；插件可能破壞 Cilium 或削弱安全性，且當 Cilium 內部架構調整時，插件維護者可能需要跟著更新程式碼。換句話說，這是一道給平台廠商與大型基礎設施團隊的門，而不是應用開發者隨手可用的外掛介面。
netkit 自動選擇與 ztunnel 的進展
Cilium 1.20 也替 pod 資料路徑加入自動選擇。設定 bpf.datapathMode=auto 之後，每個代理會在啟動時檢測所在主機，核心支援就以 netkit 建立網路裝置，否則回退到傳統的 veth pair。netkit 需要 Linux 6.8 以上，預設值仍是 veth，因此既有安裝不會自動改變，必須由維運者主動開啟。這解決的是混合叢集的實務難題：同一批節點可能跑著不同核心版本，以往若想採用新裝置，往往得把叢集拆成不同節點池，連帶增加排程與維運複雜度。netkit 是較新的核心網路裝置類型，主要用來降低容器網路在封包處理上的額外開銷。
第四個方向是 ztunnel，也就是 Cilium 1.19 為無 sidecar 雙向 TLS 引入的每節點代理。1.20 讓使用者在內部憑證頒發機構與 SPIRE 簽發的工作負載身分之間選擇，並加入註冊與連線健康度的 Prometheus 指標。ztunnel 在透過 HBONE 通道建立 TLS 1.3 連線時會先保留新連線，避免 Cilium 舊有雙向認證設計可能出現的首封包遺失，同時加密同節點 pod 之間支援的 TCP 流量。HBONE 是 Istio 定義的隧道封裝方式，這條路線與 Istio 的 ambient mode 相當接近，而 Cilium 的實作正是建立在原先為 Istio 建立的 ztunnel 專案之上。目前 Cilium 的 ztunnel 仍為 beta，舊有的 Mutual Authentication 功能則已標記為棄用。
實務意義與升級限制
把這些變更放在一起看，Cilium 1.20 的方向是讓單一專案承擔更多原本需要多個元件分工的職責：Gateway API 吸收更多 L4 與驗證情境，ztunnel 往節點層級的 mTLS 推進，eBPF 資料路徑則從封閉走向可插拔。對平台團隊而言，ListenerSets 與 ExternalAuth 降低的是跨團隊協調成本，netkit 自動選擇降低的是作業系統版本異質性帶來的維運負擔。但這些能力多半帶有前置條件：插件機制需要對內部架構的理解與後續維護承諾，ztunnel 尚未進入正式穩定階段，netkit 只在較新核心上生效。
升級前還需留意 1.20 版發布說明列出的變更項目，其中點名使用舊版 Mutual Authentication、Kafka 感知策略、Envoy Go 擴充、自訂 CNI 配置，以及若干已棄用 API 的使用者，可能需要採取相應動作。這些提醒反映的是同一個現實：功能邊界擴大的同時，舊路徑的相容期也在縮短。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。