作者：望宸

本文希望提供一種更簡單的方式，來理解這些容易混淆的技術概念：Nginx、Ingress、Ingress Controller、Ingress API、Nginx Ingress、Higress、Gateway API。

Nginx 和 Kubernetes

我們先按和 Kubernetes 是否有關，分為兩類：

Nginx 是在沒有 Kubernetes 的年代，流量入口上的事實標準，是獨立運行在任何 Linux/Windows 服務器上的 Web 服務器。提供以下主要功能：

• 接收請求；
• 轉發請求；
• 負載均衡；
• 簡單的流量治理，例如限流、緩存、重寫。

而 Ingress API、Ingress Controller、Nginx Ingress、Higress、Gateway API 都依賴 Kubernetes，Kubernetes 出現後，才有了這些概念。其中，Ingress API 是 Kubernetes 管理流量的規範，Ingress Controller 是規範的實現組件，Nginx Ingress 和 Higress 都是規範的完整實現和功能擴展，Gateway API 則是 Ingress API 的升級和下一代。

需要注意的是，Ingress 經常單獨出現，需要基於語境來判斷，有可能是指 Ingress API，也有可能是指 Ingress 資源，即用户編寫的具體配置對象（YAML），遵循 Ingress API。

Ingress API 和 Ingress Controller

Ingress API 和 Ingress Controller 分別是 Kubernetes 流量管理的規範和執行器。

Ingress API：用聲明式的方式，描述外部流量如何進入集羣裏的 Service，包括：

• 如何通過域名訪問服務；
• 如何根據 URL 路徑路由到不同後端服務；
• 後端服務是誰；
• 是否啓用 HTTPS 加密。

形象地説，Ingress API 可以理解位 Kubernetes 中管理流量的説明書。

Ingress Controller：是 Ingress API 的實現組件，即執行者，包括：

• 監聽 Ingress 資源變化；
• 將 Ingress 規則轉換為實際的反向代理配置；
• 接收外部流量並按規則路由；
• 處理 TLS 終止（HTTPS 解密）；
• 提供健康檢查、負載均衡、重試等流量治理能力。

通過以上能力，Ingress Controller 就實現了 Kubernetes 入口流量的管理。

Nginx Ingress 和 Higress

Nginx Ingress 和 Higress 都是 Ingress API 的完整實現和功能擴展。

Nginx Ingress：用 Nginx 作為底層實現的 Ingress API，控制面和數據面耦合在同一個進程/容器中。優點是簡單、易用、社區廣泛。

缺點是：

• 不是原生的 Ingress API，Ingress API 語義偏弱；
• 擴展靠 Annotation（工程噩夢）；
• 生成 nginx.conf + reload，動態配置能力弱（頻繁 reload 影響性能）。

適用於簡單、穩定、小規模的場景。

Higress：數據面是基於 Enovy，控制面給基於 istio，是原生的 Ingress API。

優點是：

• 控制面與數據面解耦，可獨立擴縮容；
• 基於 xDS 協議，實現真正的動態配置（無 reload，零中斷）；
• 原生支持插件擴展：Wasm、Lua、Go 插件由控制面統一管理並下發；
• 兼容多協議 & 多標準：同時支持 Ingress API 和 Gateway API。

缺點是，相比 Nginx 廣泛的社區基礎，Higress 為代表的原生 Ingress API，部署和維護存在學習成本。

適用於高性能、高擴展、企業級的場景。

Nginx Ingress 退役

11月，Kubernetes SIG Network 和安全響應委員會宣佈 Ingress NGINX 退役。（⚠️ NGINX 並未退役。）

意味着：

• Ingress NGINX 盡力維護服務至 2026 年 3 月；
• 不再發布任何新版本；
• 不再修復任何漏洞；
• 也不會更新任何可能發現的安全漏洞；
• GitHub 代碼庫將設置為只讀，僅供參考；
• 現有的 Ingress NGINX 部署將繼續運行，安裝文件也將繼續可用。

引發退役的根本原因：：

• 多年來，該項目只有一兩個人利用業餘時間，在工作之餘進行開發工作；
• 嘗試和 Gateway API 社區合作開發一個替代控制器，但未能激發更多人蔘與 Ingress NGINX 的維護。

Higress：Nginx Ingress 退役的替代優先方案

• Kubernetes 官方推薦，即官方社區文檔中進行了説明；
• 對 Nginx Ingress 的 Annotation 兼容度最高，支持 51 種，覆蓋 90% 的用户場景，這意味着現有的 K8s Ingress YAML 文件無需大量修改即可完成遷移；
• 長期投入，並提供企業版服務，即阿里雲 API 網關；
• 提供監聽 K8s Ingress（Ingress 模式），適用於希望保持 K8s 原生工作流（如GitOps）的團隊；和控制枱配置 API（API 管理模式），適用於需要集中治理和精細化管理的場景。

Gateway API 和 Ingress API

Gateway API 是 Ingress API 規範的超集和下一代。他的出現，是為了解決 Ingress API 自身無法搞定的問題。其中，Higress 已經支持 Gateway API 標準，用户可從 Ingress API 平滑遷移至 Gateway API。

Ingress API 存在的問題，Gateway API 這樣去解決：

職責不清，後果是 Ingress 是“一人寫全”，沒有權限邊界。-> Gateway API 通過角色分離解決，定義基礎設施提供者、集羣管理員、應用開發者。

功能表達能力弱，依賴 Controller 特有擴展，後果是不標準、不同實現之間遷移成本高。-> Gateway API 通過 Wasm、插件、服務網格集成解決擴展的標準化。

僅支持 HTTP/HTTPS，無法處理 TCP/UDP/gRPC 等協議。-> 雲原生應用早已不只是 Web 服務，Gateway API 通過統一的 API，管理所有南北向流量。

無法表達複雜路由邏輯，微服務治理需求遠超 Ingress 能力。-> Gateway API 支持 Wasm、插件、服務網格集成，通過標準化的高級路由解決。

一個 Ingress Controller 全局共享，缺乏多租户隔離，多租户場景下存在安全和配置衝突風險。-> Gateway API 提供了獨立 Gateway 的實例。