Kubernetes 社群在 2025 年正式宣布 Ingress-NGINX 將在 2026 年退休，象徵雲原生入口正式邁入新階段。Ingress 不再是 Kubernetes 核心的一部分，入口能力重新交回外部生態系，企業也因此需要重新思考未來的入口策略。本篇將從 Ingress 的歷史、Gateway API 的角色、整體市場的變化，一路談到企業該如何選擇適合的入口方案，並以 F5 的三大產品線作為完整分析。

Kubernetes Ingress-NGINX 的退休：雲原生入口的一個時代結束

2025 年 11 月，Kubernetes 社群正式宣布 Ingress-NGINX 將在 2026 年 3 月退休並停止維護與安全更新。這看似只是專案收尾，但其實代表 Kubernetes 正在調整入口策略，未來的 K8s 不會再提供預設的 Ingress 實作。

Ingress-NGINX 多年來是大家最熟悉、最常用的 Ingress Controller，也在許多公司的第一個 Kubernetes 架構中扮演重要角色。如今它退場，代表 Kubernetes 不再試圖管理所有 L7 流量，而是將這個領域交還給外部的流量治理生態來發展。

為什麼 Ingress 會走到終點？

Ingress 在 Kubernetes 剛起步的年代確實解決了大問題：用最簡單的方式，讓外部流量能夠進到集群裡的服務。但隨著雲原生架構越來越複雜，原本的設計開始顯得綁手綁腳。

最明顯的限制，就是它只處理 HTTP/HTTPS，而且幾乎只能做 host 和 path 的路由。如果你想做更進階一點的事，像是流量分流、細緻的 TLS 控制、Header 導流、Rate Limit、WAF、或多協定支援等，Ingress 本身根本不夠用。結果所有人都跑去用一大堆 annotations 或各家自製的 CRD，真正的行為就變成「看 Controller 怎麼實作」，而不是「看 Kubernetes 標準怎麼定義」。

換句話說，Ingress 的共同語言早就名存實亡。對整個社群來說，繼續維護一個無法標準化的 API，代價太高，也沒有太大意義。這就是它最終走到終點的關鍵原因。

Gateway API 的出現與它遇到的挑戰

為了改善 Ingress 的各種限制，社群後來推出了 Gateway API，希望能用更完整、可擴展的方式處理入口流量。它的設計比 Ingress 成熟許多，支援更多協定、更細緻的路由規則，也能把 TLS、政策、Listener、Route 等概念拆得更清楚。

不過，Gateway API 的彈性與擴展性也帶來另一種挑戰：它的設計非常全面，能處理的場景遠比 Ingress 複雜，因此不同廠商在實作上勢必會做出差異。雖然 API 本身定義得更抽象、更模組化，但資料平面與控制平面的落地方式仍然各不相同，生態圈也不容易因此完全統一。

因此，Gateway API 雖然是比 Ingress 更好的技術基礎，但真正的價值仍取決於廠商如何實作與延伸。這也讓 Kubernetes 更明確地意識到：入口管理並不適合由 K8s 核心主導，而是應該交給專門做流量治理的生態系持續演進。

Kubernetes 與入口正式切割：這代表什麼？

Ingress-NGINX 的退場與 Gateway API 的定位調整，其實都指向同一件事：Kubernetes 核心越來越傾向專注在「工作負載生命週期管理」本身，而不是企圖同時扮演 L7 流量治理的角色。

從 Kubernetes 的角度來看，入口並不是它一定要親自處理的領域。企業需要的不只是把流量導到 Pod，而是需要完整的入口能力，像是 WAF、API 安全、DDoS 防護、多協定支援、全球流量分配、Zero Trust、AI 流量治理等等。這些功能已經超出 Kubernetes 核心的職責範圍。

因此，把入口交還給外部生態系，不僅能讓 Kubernetes 本身更純粹，也讓整個雲原生世界可以採用更多樣、更強大的入口技術。也代表入口技術不再依附於 Kubernetes，而是成為企業架構中可以獨立選擇、自由演進的重要組件。

未來市場趨勢：入口生態正準備迎來新一輪爆發

隨著 Kubernetes 不再提供預設的入口實作，整個市場反而變得更活躍。因為入口依然是所有應用必須解決的問題，需求沒有變，只是從「K8s 內建」變成「由生態系百花齊放」。

商用市場則會迎來更明顯的加速，尤其是那些本來就深耕流量治理的廠商。無論是提供 L7 Proxy、API Gateway、WAF、安全防護，或是支援多雲與全球網路的方案，都會在這波入口外移的趨勢中變得更加重要。企業在選型時，也會更著重於端到端的能力與跨環境的一致性，而不是單純依賴 Kubernetes 內建的元件。

公有雲供應商也會在這波趨勢中持續加強自己的原生能力，特別是在負載平衡、API Gateway、WAF 與全球流量網路等整合上，讓企業能更輕鬆地把入口能力直接托管在雲端平台中。

總結來說，入口不再由 Kubernetes 單一技術定義，而是回到整個雲原生生態系共同競爭、共同創新的領域。這對企業而言意味著更多選擇，也意味著需要重新思考入口在整體架構中的位置。

F5 能如何協助企業？

在 Kubernetes 的場域裡，F5 Application Delivery and Security Platform（ADSP） 擁有豐富的應用網路與應用安全方案，不論企業採用的是傳統應用、現代雲原生服務，或是跨多集群的分散式架構，都能找到對應的部署模式與治理能力。目前市場上有三個主要方案分別是 BIG-IP、NGINX 以及 F5 Distributed Cloud（XC），它們各自對應不同的應用型態與場景。

BIG-IP：傳統關鍵業務的強大入口與安全能力（硬體＆軟體）

BIG-IP 長期在企業中扮演關鍵應用的流量與安全核心。在 Kubernetes 中，透過 F5 Container Ingress Services（CIS），企業可以將 BIG-IP 放在叢集外部，作為高性能、高安全性的 Ingress 控制層。它能將自身成熟的能力直接延伸到 Kubernetes，包括：

  • L4/L7 進階負載平衡 (LTM)
  • GSLB 全球流量分配（DNS）
  • WAF、Bot 防護、L7 DDoS 防護 (AWAF)
  • L3/L4 DDoS 防護 (AFM)
  • Access Control 與身分驗證 (APM)
  • API 閘道、API 安全 (AWAF+APM)

透過 CIS，BIG-IP 能動態感知 Kubernetes 服務、同步路由規則，讓傳統應用與雲原生應用共享一套一致的安全與流量治理能力。

NGINX：現代應用的雲原生入口 （軟體＆容器）

自從 F5 在 2019 年收購 NGINX 之後，原本只被視為輕量級反向代理的 NGINX，逐漸演化成一套完整的雲原生入口平台。許多過去只有 BIG-IP 才能做到的安全能力——像是 WAF、Bot 防護、L7 DDoS 防護——如今都能透過 NGINX App Protect (現為 F5 WAF for NGINX) 模組整合進 NGINX 本身，使它成為足以支撐企業級流量與安全需求的入口方案。

2025 年推出的 NGINX One 更顛覆了以往分散式管理的痛點。透過 NGINX Instance Manager（NIM）和 NGINX One Console，企業可以在一個統一介面裡管理所有 NGINX 實例（不論是在 VM、Kubernetes、雲端還是邊緣），同時追蹤配置、安全政策、生命週期與流量行為，讓 NGINX 真正成為「跨環境的應用入口平台」。

NGINX Ingress Controller（NIC）適合追求成熟、細膩可調、以 annotations 與自家 CRD 為核心的傳統 Ingress 架構； NGINX Gateway Fabric（NGF）則採用 Gateway API 的新世代模式，控制與資料平面分離、支援多協定與多租戶分權，更適合大型或平台工程導向的 Kubernetes 環境。

F5 Distributed Cloud（XC）：多集群、多雲的分散式入口平台 （SaaS）

F5 Distributed Cloud 提供的是 SaaS 型態的入口能力，部署上具有最高彈性。企業可以直接以服務方式消費 XC，並透過 Customer Edge（CE） 安裝在 VM、裸機或雲端環境中的軟體節點來與 Kubernetes 集群整合。

Customer Edge（CE）會自動偵測 Kubernetes 集群內的服務，協助完成服務發布與流量接入，同時也提供一套完整的 API 安全能力。除了最基本的路由與流量管理之外，XC 具備 API Discovery、API 行為分析、敏感資料偵測、威脅模式比對等安全態勢分析功能，能讓企業隨時掌握所有 API 的暴露面與潛在風險。再加上內建的 WAF、Bot 防護與 DDoS 防禦，XC 能在 API 進出集群的每一步提供完整防護。透過 F5 全球 ADN 骨幹網路，它還能協助不同集群與不同雲環境建立穩定高速的連結，並處理跨 Kubernetes Cluster 的 DNS 發布，讓跨叢集、跨雲的服務串接變得更可靠也更一致。

XC 的最大特點，是能將分散在 On-Prem、雲端、多地區的多個 Kubernetes 叢集「串成一個邏輯平台」，處理跨叢集、跨雲的應用到應用（App‑to‑App）連結與治理，特別適合大規模、多環境的企業平台。

整體來說，F5 ADSP 提供的是一套從傳統資料中心、雲原生叢集到多雲分散式架構都能覆蓋的入口能力：

  • BIG-IP：強安全、高性能的集群外入口
  • NGINX：彈性、軟體化、貼近 Kubernetes 的集群內入口
  • Distributed Cloud（XC）：跨集群、多雲、全球級的分散式入口

不論企業在哪一個轉型階段，都能透過 F5 建立一致、安全且可持續演進的入口架構。

F5 ADSP Overview

結語：入口不再只是流量問題，而是整體架構的戰略選擇

Ingress-NGINX 的退休並不是故事的結束，而是雲原生入口正式走向多元化的一個轉折點。從 Ingress 到 Gateway API，再到各家廠商推出的不同入口方案，我們其實看到的是 Kubernetes 逐漸回到它原本的定位：管理應用，而不是管理所有與網路、安全、跨叢集治理相關的複雜議題。

對企業來說，這反而是一個重新盤點整體架構的好時機：哪些入口能力必須在自己的平台中具備？哪些應該由平台工程或全球網路層統一治理？而哪些安全能力又需要從應用與服務層開始強化？這些問題沒有標準答案，也不會只有一種解法。

而 F5 ADSP 可以覆蓋企業在不同階段、不同規模、不同部署模式下的需求，不論你是想強化叢集內的雲原生入口、讓傳統應用與新平台無縫協作，或需要跨集群、多雲的治理能力，都有對應的方案可以選擇。

入口不再是 Kubernetes 預設提供的能力，也不再由某一種技術就能定義。它會成為企業架構中可調整、可演進、而且更具彈性的核心組件。這正是入口外移後最有趣、也最值得關注的地方。

References