網路架構 Kubernetes ingress-nginx Gateway API Envoy Gateway Cilium

ingress-nginx 三月正式退役後留下的 Kubernetes 網關真空：Gateway API 把 annotation 換成 HTTPRoute

ingress-nginx controller 於 2026 年 3 月 31 日 EOL 之後不再有任何 patch，CVE-2026-3288 這種 rewrite-target 注入洞永遠不會被修。文章拆解 Gateway API 為什麼是 SIG Network 指定的接手方案、ingress2gateway 1.0 怎麼自動轉換 30 種 annotation，以及 Envoy Gateway、Cilium Gateway、Traefik 3、HAProxy 幾條實際遷移路線的取捨。

ingress-nginx controller 在 2026 年 3 月 31 日正式進入 end-of-life，Kubernetes SIG Network 跟 Security Response Committee 聯合聲明從那天起停止一切 release、bugfix、CVE 修補。這個從 2015 年就在 Kubernetes 生態運作、幫全球超過 40% 叢集把外部流量導進 Service 的 controller，就這樣停在最後一次 commit。四個月後回頭看，很多團隊還是把上線環境掛在已經沒有維護的 controller 上，靠著「反正還能跑」的心態撐一天算一天，直到下一顆 CVE 爆炸為止。

CVE-2026-3288 就是最好的例子。這顆漏洞讓有 Ingress 建立權限的人透過 nginx.ingress.kubernetes.io/rewrite-target annotation 直接注入 nginx 設定，最終在 controller 容器裡拿到任意程式碼執行權限，CVSS 評分 8.8。1.13.8、1.14.4、1.15.0 這幾個版本收到最後一次 patch 之後，未來新爆的洞不會再有官方修補。留在 ingress-nginx 上等於自願接下所有未來 zero-day 的風險。

為什麼 SIG Network 決定砍掉 ingress-nginx

官方公告寫得很客氣，說的是「維護人力不足、社群無法長期支撐 controller 的複雜度」，但真正的問題是架構本身。ingress-nginx 靠著上百個 annotation 撐起 Ingress 資源沒有的功能——rewrite、canary、mirror、rate-limit、CORS、auth-url——這些 annotation 全部塞在 metadata 裡當自由格式字串傳給 nginx template 產生設定檔。字串處理只要有一個地方沒 escape，就是一顆 RCE。

Ingress API 本身早在 2020 年就凍結，SIG Network 把力氣全部投在 Gateway API。ingress-nginx 這種「用 annotation 補強 API 表達力」的路線，維護者其實一直在幫一個已經 dead 的 API 補洞。當 Gateway API 在 2023 年 GA、2025 年主要 controller 都有實作、Google 跟 Fastly 也把重心搬過去之後，繼續投人力在 ingress-nginx 就沒有意義了。

值得澄清一件事：被砍掉的是 ingress-nginx 這個特定 controller，不是 Ingress API，也不是 F5 商業版的 NGINX Ingress Controller。後者是完全不同的 codebase，仍然在維護。但社群版跟商業版的功能差距不小，annotation 語法也有差異，直接切換不是無痛的。

Gateway API 把 annotation 拉回 spec 裡面

Gateway API 的核心設計是三層分離：GatewayClass 描述「這是哪種 controller」，Gateway 描述「這是一個 listener 綁在哪個 IP、哪個 port、哪個憑證」，HTTPRoute 描述「這個路徑要導到哪個 Service」。三層對應到平台工程師、叢集管理員、應用開發者三種角色，每一層都有自己的 RBAC 邊界。

實務上的差異最明顯在路徑重寫。ingress-nginx 寫法是把 rewrite-target 塞進 annotation：

1
2
3
4
5
6
7
8
9
10
11
12
13
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
  - http:
      paths:
      - path: /api(/|$)(.*)
        backend:
          service:
            name: api
            port:
              number: 80

Gateway API 的等價寫法把 rewrite 變成 spec 的 first-class field：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
spec:
  parentRefs:
  - name: prod-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplacePrefixMatch
          replacePrefixMatch: /
    backendRefs:
    - name: api
      port: 80

差別看起來只是欄位改名，但這樣的改動意味著 controller 不需要再解析自由格式字串。所有變更走 CRD schema 驗證，惡意 payload 沒有機會進到 nginx template。CVE-2026-3288 這類注入攻擊在 Gateway API 的設計裡從根本上被擋掉。

ingress2gateway 1.0 把 annotation 自動翻譯

Kubernetes SIG Network 在 2026 年 3 月 20 日發布 ingress2gateway 1.0，同一週 ingress-nginx EOL 生效。這個 CLI 工具支援 30 幾種常見的 ingress-nginx annotation 自動轉換，包含 rewrite-target、ssl-redirect、backend-protocol、use-regex、canary-、cors-、auth-url 這些高頻用法。

指令直接對現有叢集掃描：

1
ingress2gateway print --providers=ingress-nginx --namespace=production

工具會把每一筆 Ingress 拆成對應的 Gateway、HTTPRoute、ReferenceGrant，輸出成 YAML 讓工程師確認過再套用。實務上不建議直接 apply，得逐一 review 兩件事：一是有些 annotation 沒有 Gateway API 對應（例如 configuration-snippet 這種塞任意 nginx directive 的用法），工具會標記出來要求手動處理；二是命名衝突，同一個 host 底下有多筆 Ingress 對應到同一個路徑時，Gateway API 的 route matching 語意跟 ingress-nginx 略有差異。

一個常被忽略的細節是：轉換完之後絕對不要讓同一組 host+path 同時存在 Ingress 跟 HTTPRoute，兩個 controller 會搶同一份流量，結果不可預測。官方建議的切換順序是先在測試環境跑 ingress2gateway、驗證 HTTPRoute 語意跟原本 Ingress 行為一致、再逐個 namespace 遷移、確認流量正常後才刪掉舊 Ingress。

另一個實務坑是憑證管理。ingress-nginx 把 TLS 設定塞在 Ingress 的 spec.tls 欄位裡面，每個 Ingress 自帶憑證。Gateway API 換成 Gateway 資源集中掛憑證，一個 Gateway 可以綁多個 HTTPRoute。cert-manager 在 1.14 之後才完整支援 Gateway API 的憑證自動簽發流程，還在跑舊版 cert-manager 的叢集要先升級才能無縫切換 Let’s Encrypt 憑證。

Envoy Gateway、Cilium、Traefik 3、HAProxy 該選哪個

Gateway API 是規範，實作有將近二十家。真正在生產環境撐得起量、社群活躍的其實不多，選擇範圍收斂在四個：

Envoy Gateway 是 Envoy 官方團隊做的 Gateway API 實作，2025 年底 GA。適合原本已經用 Envoy 或 Istio 的團隊，共用同一套 xDS 設定跟 observability 管道。單一 Deployment 起一個 shared instance，資源占用中等，效能穩定。缺點是設定跟 Envoy 本身一樣不直觀，剛入門的團隊會被 Listener、Route、Cluster 幾層抽象搞混。

Cilium Gateway 走完全不同的路線，把 Gateway API 實作直接寫進 Cilium 的 eBPF datapath。同一份設定同時處理 NetworkPolicy、Service Mesh、Gateway，L3/L4/L7 統合在 kernel 層，不需要額外的 sidecar proxy。效能是幾個選項裡最好的，特別是在 east-west traffic 為主的叢集。但前提是整個叢集要用 Cilium 當 CNI，中途換 CNI 是重大工程。

Traefik 3 在小型叢集依然是最直觀的選擇，設定簡潔、自動探索 Service、儀表板做得漂亮。Gateway API 支援齊全，效能中等，適合 1-10 個 node 規模的環境。但在高吞吐場景（每個 replica 5 萬 rps 以上）延遲明顯拉長，超過這個規模的團隊得考慮換到 Envoy Gateway 或 HAProxy。

HAProxy Ingress 是效能導向的老牌選擇，在 100 rounds Gateway API 測試裡零失敗，處理極高 QPS 時延遲穩定。設定風格接近傳統 HAProxy 熟悉的 backend/frontend 抽象，DevOps 出身的工程師上手快。適合金融、電商這類要求 SLA 嚴格的環境。

短期沒時間評估的話，用同一個 CNI 的優先選 Cilium Gateway，一般團隊選 Envoy Gateway，需要簡單直觀的選 Traefik 3。

值得提一下 Kong Gateway 跟 Contour 這兩個較常被忽略的選項。Kong 走 API Gateway 路線，內建 rate limiting、JWT 驗證、OIDC 整合，適合有 API 管理需求、需要多租戶隔離的場景，但相對重、學習曲線也陡。Contour 由 Project Contour 維護、底層一樣是 Envoy，設定風格比 Envoy Gateway 更簡潔，是懶得碰 xDS 又想吃 Envoy 效能的折衷方案。這幾個都通過 Gateway API conformance 測試，社群活躍度中等。

沒有 Kubernetes 的環境該怎麼想

不是所有需要 reverse proxy 的場景都在 Kubernetes 上。單機 VPS 或幾台實體機的部署，繼續用 Caddy、原生 nginx、HAProxy 都是合理選擇——ingress-nginx 的問題出在 Kubernetes 特化的 controller 邏輯，跟 nginx 本身的品質無關。真正需要 Gateway API 的門檻是「多台機器、動態拓撲、需要標準化流量抽象」，單機環境用不到這層抽象。

反過來說，如果團隊本來就在跑 Kubernetes、還壓在 ingress-nginx 上沒動作，時間已經到了。EOL 過了四個月，未來每一顆爆出來的 CVE 都會是永久漏洞。ingress2gateway 已經把大部分工作自動化，剩下的是排時間做流量切換演練跟人力訓練。

NCSE Network 提供臺灣是方電訊機房的 VPS 主機與 IP Transit 服務，配備 Intel Gold CPU 與 NVMe SSD，能穩定支撐 Kubernetes 叢集所需的低延遲網路環境，也提供 10M 到 100G 的 IP 對接方案支撐大流量 Gateway 節點。需要協助評估 Kubernetes 網路架構或機房代管的團隊，可以到 ncse.tw 了解更多細節。

標籤： # 網路架構 # Kubernetes # ingress-nginx # Gateway API # Envoy Gateway # Cilium
NCSE Network 技術團隊
作者
NCSE Network 技術團隊

我們是 NCSE Network 的技術團隊，專注於雲端基礎設施、網路架構與 Linux 系統管理。在這裡分享我們在實際營運中累積的第一手技術經驗。

需要高品質的網路服務？

NCSE Network 提供 IP Transit、IP Tunnel 及 BGP 路由規劃，10M～100G 彈性頻寬，多上游備援確保穩定。

了解網路服務 →