2025 年 11 月，Kubernetes 社群投下了一顆震撼彈：長期以來作為預設選項的 Ingress-NGINX 將於 2026 年 3 月正式退休，停止所有維護與安全更新。
這不僅是一個開源專案的終結，更象徵著 Kubernetes 發展策略的重大轉向，官方決定不再主導流量治理的標準實作，而是將主導權交還給蓬勃發展的外部生態系。對於眾多依賴 Ingress-NGINX 構建初代雲原生架構的企業而言，這既是必須面對的變革挑戰，也是升級架構、擁抱現代化流量治理的關鍵轉機。
為何這位「老兵」必須退場？ #
Ingress-NGINX 的退場，並非單純因為技術過時，而是架構限制、資安風險與社群量能三者交織下的必然結果。
1. 規格與實作的雙重脫節 #
Kubernetes 原生 Ingress 規格設計之初過於陽春，僅定義了 HTTP/HTTPS 路由。為了滿足現實世界中對 L4 (TCP/UDP)、WAF、Header 操作等需求，開源社區版被迫透過大量的 Annotations 與 ConfigMap 來「魔改」。這導致了嚴重的「配置碎片化」，寫在 YAML 裡的行為不再由 K8s 標準定義，而是取決於控制器如何實作，失去了雲原生最引以為傲的可攜性。
2. 架構老舊引發的資安危機 #
為了彌補規格不足，社群版大量開放了 Snippet 與 Lua 腳本注入功能。這些為了靈活性而開的後門，在現代資安視角下成了高危險的漏洞溫床。近年來，Ingress-NGINX 頻繁爆發 CVE，每一次修補往往伴隨著功能的閹割或相容性破壞，讓維運團隊在「保持靈活」與「修補漏洞」之間陷入兩難。
3. 社群維護動能的枯竭 #
儘管擁有數百萬用戶，但 Ingress-NGINX 背後的核心維護者寥寥無幾。面對龐大的技術債和層出不窮的漏洞，志工社群早已不堪重負。當一個專案的維護成本遠超社群負荷，且架構已無法安全地支援未來需求時，「有尊嚴的退休」成為了對用戶最負責任的決定。
這不是單一因素導致的落幕，而是隨著規格演進、資安威脅態勢日益嚴峻，Ingress-NGINX 已不再能安全且可預期地支撐企業級需求。
Gateway API：理想豐滿，但遷移路遙 #
為了徹底解決 Ingress 的結構性問題，Kubernetes 推出了 Gateway API。它採用了更模組化的設計（GatewayClass, Gateway, HTTPRoute），完美實現了角色權責分離（開發者管路由、維運者管閘道），並原生支援了多協定與進階流量策略。
然而，Gateway API 的成熟不代表遷移的輕鬆。對於企業而言，將成千上萬行現有的 Ingress YAML 全部重寫為 Gateway API 是一項巨大的工程。企業面臨的真實困境是：「我知道 Gateway API 是未來，但我現在的 Ingress 服務不能停，而且我需要立即解決開源社區版停止維護後的資安空窗期。」
這正是市場重組的關鍵時刻，企業需要的不是一個單純的新工具，而是一個能平滑過渡的戰略夥伴。
入口治理的「解綁」與生態系的爆發 #
Kubernetes 核心團隊的放手，實則是對「流量治理」專業度的認可。未來的 K8s 將更專注於工作負載的生命週期，而將入口（Ingress/Gateway）與安全（WAF/API Security）交由外部生態系主導。
這意味著企業將不再受限於「K8s 預設什麼就用什麼」的框架，而是獲得了根據業務需求選擇最佳方案的主動權。市場生態將從單一主導走向多元競合，而那些具備端到端完整治理能力的商用解決方案，將成為協助企業穿越這波轉型動盪、建立穩定架構的關鍵力量。
F5 NGINX：穿越轉型週期的穩健橋樑 #
在這個過渡期，F5 NGINX 的價值在於它提供了一條「無需打掉重練」的平滑演進路徑。對於長期依賴 Ingress-NGINX 的企業來說，直接採用 F5 NGINX 是風險最低的選擇。它不僅修補了開源社區版在安全與支援上的缺口，更提供了同時兼容 Ingress API 與 Gateway API 的雙軌彈性架構。
1. 解決燃眉之急：NGINX Ingress Controller (NIC) #
F5 NGINX Ingress Controller (NIC) 是企業最容易立即採用、風險相對最低的短期與中期解方。雖然核心同樣基於 NGINX，但它由 F5 專屬團隊負責維護與安全修補，徹底解決了社群版 CVE 頻發、補丁延遲與無人維護的風險。
-
無痛遷移與相容性：NIC 能夠無縫接手現有的 Ingress 流量，企業無需立即大規模重寫架構。
-
告別 Annotation Hell：除了支援標準 Ingress 資源，NIC 更引入了豐富的 CRD 資源。這是一種結構化、具備型別檢查的配置方式，能替代混亂的 Annotations，讓進階路由（如藍綠部署、斷路器）與 WAF 策略變得清晰且易於管理。
-
企業級防護：直接整合 NGINX App Protect WAF，在入口層即阻擋 OWASP Top 10 與 L7 DoS 攻擊，強化容器應用入口安全。
-
原生支援整合 BIG-IP 生態：可原生整合 BIG-IP 系列方案，強化集群外圍流量治理與安全防護，實現從邊緣到應用的多層次防禦體系。
2. 佈局未來架構：NGINX Gateway Fabric (NGF) #
當企業準備好擁抱 Gateway API 時，NGINX Gateway Fabric (NGF) 提供了標準化的實作。這意味著企業可以在同一個 NGINX 生態系中，依照自己的步調，從 Ingress 平滑遷移到 Gateway API，而無需更換底層技術堆疊。
-
統一的資料平面：無論是現在使用 NIC 跑 Ingress，還是未來用 NGF 跑 Gateway API，底層皆是使用高效穩定的 NGINX 作為資料平面。這意味著企業可以在同一個 NGINX 生態系中，依照自己的步調並行運作或平滑遷移，而無需更換底層技術堆疊或重新適應新的 Proxy 行為。
-
原生 Gateway API 與 Inference Extension 支援：NGF 專為 Gateway API 規格打造，並緊跟最新的 Gateway API Inference Extension 標準。這讓企業能以標準化的方式定義 AI/ML 工作負載，在基礎設施層統一處理對 LLM 模型的請求路由、切換與負載平衡，大幅簡化生成式 AI 服務的部署與管理複雜度。
3. 統一管理：NGINX One 與 Instance Manager (NIM) #
透過 SaaS 化的管理控制台 NGINX One，企業可以統一納管分散在集群的 NGINX 實例。而針對有嚴格合規需求或需地端部署的場景，NGINX Instance Manager (NIM) 則提供了同樣強大的管理能力。這兩者皆能解決過去版本破碎、配置漂移的痛點，讓維運團隊從單一面板掌握全域的流量與安全狀態，實現真正的跨環境治理。
結語：選擇權回到你自己手中，F5 ADSP 重塑戰略 #
Ingress-NGINX 的退休聲明，實際上是 Kubernetes 發給所有架構師的一份邀請函：「請重新思考你的流量入口策略。」 這不僅是更換一個 Controller，而是重新審視整體架構的機會。
在這個轉折點，F5 Application Delivery and Security Platform (ADSP) 提供了超越單一工具的縱深戰略。你不必因為 API 的迭代而恐慌，因為你可以根據業務場景靈活組合不同的治理模式：
-
敏捷應用交付 (NGINX)：如前所述，利用 F5 NGINX 在集群內實現高效能與靈活的 Ingress/Gateway 轉型，是現代化應用的首選。
-
基礎設施防線 (BIG-IP)：透過 Container Ingress Services (CIS)，企業能將既有的 BIG-IP 強大能力（SLB、GSLB、WAF 等）直接延伸至 Kubernetes 集群，讓傳統基礎設施與現代化容器環境無縫整合。
-
混合場景全域治理 (Distributed Cloud/XC)：面對多集群分散部署，F5 XC 能建立安全的多集群互連，將分散在地端與雲端的 K8s 集群串聯成一個邏輯網路，讓跨集群的應用溝通無縫且安全，同時實現全域流量調度，讓單一策略配置能即時同步至全球節點。
在這個後 Ingress 時代，入口不再只是一個簡單的 K8s 資源物件，而是企業資安縱深防禦與多雲戰略的第一道防線。真正重要的不是替換一個 Controller，而是選擇一個能隨著你的架構成長、同時涵蓋軟體、硬體與 SaaS 的完整流量治理策略。