Nginx Ingress Controller 停止維護：影響分析與轉換建議

前言

2025 年 11 月 11 日，Kubernetes SIG Network 與安全回應委員會正式宣布 Ingress NGINX Controller 將於 2026 年 3 月停止維護。這項決定對全球數以萬計的 Kubernetes 集群帶來重大影響，本文整理了此決策的背景、影響範圍，並提供轉換建議。

背景說明

Ingress NGINX 的歷史地位

Ingress NGINX Controller 是 Kubernetes 生態系統中最早期且最受歡迎的 Ingress 控制器之一。作為 Kubernetes 項目早期開發的示範實作，它憑藉以下特點成為業界標準選擇：

卓越的靈活性：支援廣泛的配置選項和自訂功能
豐富的功能集：涵蓋從基礎路由到進階流量管理的完整需求
雲端中立性：不依賴特定雲端供應商或基礎設施平台
成熟的生態系統：擁有完整的文件、社群支援和最佳實踐

停止維護的原因

Kubernetes 官方公告指出，Ingress NGINX 面臨以下核心挑戰：

1. 維護人力嚴重不足

長期以來，整個項目僅依賴一到兩位維護者在業餘時間進行開發維護工作。儘管使用者眾多，卻始終無法吸引足夠的貢獻者參與維護。

2. 技術債務累積

過去被視為優勢的靈活性，如今已成為沉重的技術負擔：

安全性問題：例如允許透過 annotations 注入任意 NGINX 配置片段（snippets）的功能，已被視為嚴重的安全漏洞
架構複雜度：廣泛的功能選項導致維護和測試的複雜度持續攀升
現代化標準：難以滿足當代雲原生軟體對安全性和可維護性的要求

3. 替代方案失敗

2024 年，維護者曾宣布計劃開發 InGate 作為替代方案，但該項目未能獲得足夠支持，最終也將一併退役。

影響分析

時程規劃

2025 年 11 月至 2026 年 3 月：維持盡力而為的維護（best-effort maintenance）
2026 年 3 月後：
- 不再發布新版本
- 不再修復任何錯誤
- 不再處理任何安全漏洞
- GitHub 儲存庫轉為唯讀狀態

受影響範圍

1. 直接技術影響

現有部署持續運作 停止維護不會立即影響現有部署，已安裝的 Ingress NGINX 將繼續運作，相關安裝檔案（Helm charts、容器映像）也將保持可用狀態。

安全風險顯著提升 最關鍵的影響在於安全性：2026 年 3 月後發現的任何安全漏洞都不會獲得修補，這將使持續使用的組織暴露於日益增加的安全風險中。

2. 維運層面影響

無法獲得官方支援：遇到問題時無法依賴上游維護團隊
相容性問題：未來 Kubernetes 版本可能出現相容性問題而無人修復
功能凍結：無法期待新功能開發或現有功能改進

3. 合規性影響

對於必須符合資訊安全標準（如 ISO 27001、SOC 2、PCI DSS）的組織，使用不再維護的軟體可能導致稽核問題。特別是在金融、醫療等受嚴格監管的產業，這可能成為嚴重的合規風險。

檢測方法

您可以透過以下指令檢查集群是否使用 Ingress NGINX：

kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

如果返回結果，表示您的集群正在使用 Ingress NGINX Controller。

轉換策略建議

選項一：轉換至 Gateway API（強烈推薦）

為何選擇 Gateway API？

Gateway API 是 Kubernetes 官方開發的新一代流量管理 API，旨在取代傳統的 Ingress API。相較於 Ingress，Gateway API 提供：

架構優勢

角色分離：清楚區分基礎設施管理者與應用開發者的職責
更強的表達能力：支援更複雜的路由規則和流量管理場景
原生支援：TCP、UDP 路由以及更細緻的流量控制

標準化與可移植性

跨供應商標準：避免廠商鎖定，易於在不同實作間切換
持續演進：由 Kubernetes SIG Network 積極維護和發展

進階功能

流量分割與金絲雀部署：原生支援漸進式發布策略
更細緻的路由控制：支援 header、query parameter 等多維度路由
擴展性設計：透過標準化的擴展機制支援客製化需求

Gateway API 實作選擇

主流的 Gateway API 實作包括：

實作方案	特色	適用場景
Envoy Gateway	CNCF 畢業項目 Envoy 的官方 Gateway 實作	需要企業級穩定性與豐富功能
Istio Gateway	整合服務網格功能	需要完整的服務網格能力
Cilium Gateway	基於 eBPF 技術，高效能	追求極致效能與可觀測性
Kong Gateway	商業支援，豐富的插件生態	需要 API 管理與商業支援
Traefik	輕量級，易於配置	中小型部署與快速上手

使用 ingress2gateway 工具進行轉換

Kubernetes SIG Network 提供了 ingress2gateway 工具來協助自動化轉換過程。

安裝方式

# 使用 Go 安裝
go install github.com/kubernetes-sigs/ingress2gateway@v0.4.0

# 使用 Homebrew (macOS/Linux)
brew install ingress2gateway

# 或從 GitHub Releases 下載二進位檔案
# https://github.com/kubernetes-sigs/ingress2gateway/releases

基本使用

# 轉換當前命名空間的所有 Ingress NGINX 資源
./ingress2gateway print --providers=ingress-nginx

# 轉換所有命名空間的資源
./ingress2gateway print --providers=ingress-nginx --all-namespaces

# 指定特定命名空間
./ingress2gateway print --providers=ingress-nginx --namespace=production

# 從檔案讀取並轉換
./ingress2gateway print --providers=ingress-nginx --input-file=ingress.yaml

# 輸出為 JSON 格式
./ingress2gateway print --providers=ingress-nginx --output=json

轉換對應關係

Ingress 欄位	Gateway API 對應
`ingressClassName`	轉換為 `gatewayClassName`
`defaultBackend`	生成無 hostname 的 Gateway Listener 與 catchall HTTPRoute
`tls[].hosts`	為每個 host 生成 HTTPS Listener（port 443）
`tls[].secretName`	對應到 Listener 的 `certificateRefs`
`rules[].host`	生成對應的 Gateway HTTP Listener 與 HTTPRoute
`rules[].http.paths[].path`	對應到 HTTPRoute `matches[].path.value`
`rules[].http.paths[].pathType`	對應到 HTTPRoute `matches[].path.type`
`rules[].http.paths[].backend`	對應到 HTTPRoute `backendRefs[]`

衝突解決機制

ingress2gateway 採用確定性的處理順序：

依照 Ingress 資源的建立時間戳排序（越舊越優先）
時間戳相同時，依照 namespace/name 排序
發生衝突時（如相同 path 但不同 backend），較晚的資源會回報錯誤

轉換步驟

階段一：評估與準備

盤點現有配置

# 匯出所有 Ingress 資源
kubectl get ingress --all-namespaces -o yaml > current-ingress.yaml

# 檢查使用的 annotations
kubectl get ingress --all-namespaces -o jsonpath='{range .items[*]}{.metadata.annotations}{"\n"}{end}' | grep nginx

評估客製化功能
- 列出所有使用的 NGINX annotations
- 識別 snippets 或自訂配置
- 確認是否有依賴特定 NGINX 模組的功能
選擇 Gateway API 實作
- 根據組織需求選擇合適的 Gateway Controller
- 建立測試環境進行概念驗證

階段二：測試環境驗證

建立測試環境

# 安裝選定的 Gateway Controller（以 Envoy Gateway 為例）
kubectl apply -f https://github.com/envoyproxy/gateway/releases/download/latest/install.yaml

轉換與部署測試

# 轉換現有配置
ingress2gateway print --providers=ingress-nginx \
  --input-file=current-ingress.yaml \
  --output=yaml > gateway-api-config.yaml

# 檢視轉換結果
cat gateway-api-config.yaml

# 部署到測試環境
kubectl apply -f gateway-api-config.yaml

功能驗證
- 測試所有路由規則是否正確運作
- 驗證 TLS/SSL 憑證配置
- 確認 health checks 與探測
- 測試效能與資源使用情況
處理不相容功能
- 針對無法直接轉換的 annotations，尋找 Gateway API 的對應實作方式
- 必要時使用 Gateway Controller 特定的擴展功能

階段三：金絲雀部署

並行運作
- 在生產環境同時運作 Ingress NGINX 與新的 Gateway Controller
- 使用流量鏡像或藍綠部署策略

漸進式流量切換

# 先切換非關鍵服務
kubectl label service app-service gateway-enabled=true

# 監控指標與日誌
kubectl logs -n gateway-system -l app=gateway-controller

監控與調整
- 持續監控錯誤率、延遲、資源使用
- 根據觀察結果調整配置

階段四：完整轉換

移除舊配置

# 備份現有配置
kubectl get ingress --all-namespaces -o yaml > backup-ingress.yaml

# 逐步刪除 Ingress 資源
kubectl delete ingress -n production app-ingress

解除安裝 Ingress NGINX

# 使用 Helm 解除安裝
helm uninstall ingress-nginx -n ingress-nginx

# 或使用 kubectl 刪除
kubectl delete namespace ingress-nginx

文件更新
- 更新部署文件與運維手冊
- 教育訓練團隊成員熟悉 Gateway API

選項二：轉換至其他 Ingress Controller

若組織暫時無法轉換至 Gateway API，可以考慮切換到其他持續維護的 Ingress Controller。

主流替代方案

HAProxy Ingress

穩定性佳，效能優異
豐富的負載平衡演算法
適合對效能要求高的場景

Traefik

現代化設計，支援自動服務發現
原生支援 Let’s Encrypt
優秀的可視化介面
同時支援 Ingress 與 Gateway API

NGINX Inc. Ingress Controller

NGINX 官方商業版本
提供商業支援與進階功能
付費授權但有完整保障

Kong Ingress Controller

強大的 API 管理功能
豐富的插件生態系統
企業級功能與支援

Contour

基於 Envoy，VMware 支援
簡潔的設計哲學
良好的社群支援

轉換考量因素

選擇替代 Ingress Controller 時，應評估：

功能相容性：是否支援您目前使用的 Ingress 功能與 annotations
維護狀態：項目的活躍度與維護團隊規模
效能需求：是否滿足您的流量處理需求
學習曲線：團隊上手的難易度
商業支援：是否需要付費的技術支援
生態系統整合：與現有監控、日誌系統的整合能力

轉換步驟（以 Traefik 為例）

# 1. 安裝 Traefik
helm repo add traefik https://traefik.github.io/charts
helm install traefik traefik/traefik -n traefik --create-namespace

# 2. 更新 Ingress 資源的 ingressClassName
kubectl patch ingress app-ingress -n production \
  --type='json' \
  -p='[{"op": "replace", "path": "/spec/ingressClassName", "value":"traefik"}]'

# 3. 轉換 NGINX 特定的 annotations 為 Traefik annotations
# 需要根據實際使用的功能進行調整

# 4. 驗證與測試
kubectl describe ingress app-ingress -n production

# 5. 移除 Ingress NGINX（確認一切正常後）
helm uninstall ingress-nginx -n ingress-nginx

轉換時程建議

基於安全性考量，建議採取以下時程：

高優先級（立即開始，2026 年 Q1 完成）

適用於以下情境：

處理敏感資料或高價值資產的系統
受嚴格監管的產業（金融、醫療、政府）
面向公眾的生產服務
使用了已知存在安全風險的功能（如 snippets）

中優先級（2026 年 Q2 前完成）

適用於：

內部服務與開發環境
風險承受度較高的組織
已有完善的安全監控與防護機制

低優先級（2026 年底前完成）

適用於：

隔離的測試環境
個人學習與實驗環境
計劃短期內下線的服務

重要提醒：即使是低優先級場景，也不建議在 2026 年後繼續長期使用 Ingress NGINX。

風險管理建議

1. 建立轉換專案團隊

指派專人負責轉換工作，明確角色與職責：

專案經理：協調與時程管理
技術負責人：架構設計與技術決策
DevOps 工程師：執行轉換與測試
安全專家：風險評估與安全驗證

2. 詳細記錄與備份

在轉換過程中：

完整備份現有配置
記錄所有變更與決策
建立退版計劃
保留測試證據

3. 漸進式部署策略

避免一次全部升級：

從非關鍵服務開始
分批次進行轉換
保持退版能力
持續監控與調整

4. 建立監控與告警

確保能及時發現問題：

# 範例：監控 Gateway 健康狀態
apiVersion: v1
kind: Service
metadata:
  name: gateway-metrics
  namespace: gateway-system
spec:
  selector:
    app: gateway
  ports:
  - name: metrics
    port: 9090
---
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: gateway-monitor
  namespace: gateway-system
spec:
  selector:
    matchLabels:
      app: gateway
  endpoints:
  - port: metrics

5. 知識轉移與訓練

組織團隊教育訓練課程
建立新的維運手冊
分享最佳實踐
建立內部問答知識庫

常見問題解答

Q1: 我可以繼續使用 Ingress NGINX 到什麼時候？

技術上可以持續使用，但強烈不建議在 2026 年 3 月後繼續使用於生產環境。主要風險是安全漏洞不會獲得修補。

Q2: Gateway API 是否已經生產就緒？

是的。Gateway API 已於 2023 年達到 GA（Generally Available）狀態，多個主流實作（如 Istio、Envoy Gateway、Cilium）都已在大規模生產環境中使用。

Q3: 轉換會造成服務中斷嗎？

採用適當的策略（如藍綠部署或金絲雀發布），可以做到零停機轉換。關鍵是充分的測試與漸進式切換。

Q4: 小型團隊是否有資源完成轉換？

ingress2gateway 工具可以自動化大部分轉換工作。對於簡單的配置，轉換過程可以在數天內完成。建議優先選擇易於上手的 Gateway 實作，如 Traefik。

Q5: 如果我的雲端供應商還在使用 Ingress NGINX 怎麼辦？

聯繫您的雲端供應商了解他們的轉換計劃。主流雲端供應商（AWS、GCP、Azure）都已提供或正在開發 Gateway API 支援。

Q6: 是否有工具可以幫助評估轉換複雜度？

除了 ingress2gateway，還可以使用 kubectl 搭配腳本分析：

# 統計使用的 annotations
kubectl get ingress --all-namespaces -o json | \
  jq '[.items[].metadata.annotations | keys[]] | unique'

# 找出使用 snippets 的 Ingress
kubectl get ingress --all-namespaces -o json | \
  jq '.items[] | select(.metadata.annotations | 
  to_entries[] | .key | contains("snippet"))'

結論

Ingress NGINX Controller 的退役標誌著 Kubernetes 流量管理進入新階段。雖然這項變更為現有用戶帶來額外的轉換負擔,但同時也是升級至更現代、更安全的架構的契機。

核心建議

立即行動：不要等到 2026 年 3 月才開始規劃
優先選擇 Gateway API：作為官方推薦的長期方案
充分測試：確保轉換不影響業務運作
記錄與分享：協助社群共同度過轉換期

Gateway API 代表著 Kubernetes 流量管理的未來,提供更強大的功能、更好的安全性與更清晰的架構設計。雖然轉換需要投入時間與資源,但長遠來看,這將為組織帶來更穩定、更靈活的基礎設施。

感謝 Ingress NGINX 維護者多年來的辛勤付出,他們的貢獻讓 Kubernetes 生態系統得以蓬勃發展。現在,是時候擁抱下一代技術,延續這份精神,建構更美好的雲原生未來。

前言