原文作者：林靜，黃曉芬
原文鏈接：Ingress-NGINX 項目停止，是要簡單平移，還是策略性重構？
轉載來源：NGINX 中文社區
NGINX 唯一中文官方社區 ，盡在 nginx.org.cn
Ingress-NGINX 社區項目在 2026 年 3 月後，將不再發布新版本，不再修復漏洞，也不會針對可能發現的任何安全漏洞提供更新。作為一個在大量用户默認使用的方案，突然停止研發，並且留給用户並不多的遷移時間，確實在業界引起了巨大的震動。
在本文中，我們將從事件背景、開源思考、市場分析、遷移策略與建議這幾個方面與您一同探討，是選擇簡單的遷移平移，還是進行策略性重構？
事件背景
“聽説 F5 要停止 Ingress-NGINX 項目的研發了？”一位朋友從微信上發來消息。我告訴他“搞混了，Ingress-NGINX 不是 F5 NGINX 的項目，而是 Kubernetes 社區的項目。F5 的項目叫 NGINX Ingress Controller。你可以理解為社區強調 Ingress 並用 NGINX 做了一個入口的參考項目，所以叫 Ingress-NGINX，而 F5 強調的是基於自己的 NGINX 來實現的 Ingress，所以可以叫 NGINX-Ingress。”
Ingress 規範自 2015 年以 beta 方式引入 Kubernetes 時，Ingress-NGINX 項目就一直以 Ingress 的樣例項目的姿態出現，在早期的 Kubernetes 相關官方文檔中一直有這樣的表述。在本次關於 Ingress-NGINX 項目退役的官方宣佈文檔中，依然有這樣的描述：
“Ingress NGINX was an Ingress controller, developed early in the history of the Kubernetes project as an example implementation of the API. ”
Ingress 規範本身從 2015 到 2020 年 8 月，隨着 Kubernetes v1.19 的發佈才被正式 GA，跨越了約 5 年時間。而實際上，就在 Ingress 規範 GA 之前，2018 年 2 月社區針對 Ingress 發起過大規模的社區調查，隨後在 2019 年 11 月聖地亞哥的 KubeCon 上，一個新的 API：Service API 被提出，這個 Service API 就是 Gateway API 的前身，2023 年 10 月 Ingress API 最終被社區正式凍結，推薦用户轉向 Gateway API 規範。
2024 年香港 KubeCon 上，Ingress-NGINX 的 maintainer 張晉濤提到該項目在漏洞修復方面人手完全不夠，近年來 Ingress-NGINX 爆出了多個重大漏洞如 CVE-2025-24514、CVE-2025-1974、CVE-2025-1097、CVE-2025-1098 等，其中 CVE-2025-1974 的 CVSS 評分達 9.8，該漏洞可以導致黑客直接接管整個 k8s 集羣。很多時候會被安全響應委員會追着屁股趕活，漏洞修復速度很慢。退役官方文檔中提到“多年來，該項目只有一兩個人利用自己的業餘時間、下班後和週末進行開發工作。”
可以看出，即便 Ingress 規範本身在社區也是命運多舛，而作為一個樣例性項目的 Ingress-NGINX 被終止也自然並不出乎意外。
開源思考
並不意外，並不代表我們不去思考。Ingress-NGINX 項目作為 Kubernetes 默認的 Ingress Controller，是許多用户的默認選項，也是大量 PaaS 廠商默認打包的組件，如此重要的項目，多年來完全依賴於少量的人維護，是典型的“大量使用，少有貢獻”的開源項目。在開源項目使用中，有一個根本性的風險就是：項目再重要，也沒有人義務為你服務。在此次事件發生後，有人在微信羣中抱怨到：“似乎事件一出，好像很多人又成了專家，重新關注了 Ingress，可是你真的願意為這個項目做出貢獻嗎？”與一些開源項目一樣，它被大量的關鍵組織、企業應用，卻很少得到真正的社區貢獻，即便是炙手可熱的 CNCF 基金會，也一樣面臨這樣的難題。開源的 star 不等於可持續性，開源的使用規模不等於開源的健康度，開源的免費不等於開源可以替代企業級產品。Ingress-NGINX 項目的停止，是雲原生領域給我們敲響的警鐘。對於生產級基礎設施，我們必須重新思考項目的：
- 可持續性
- 維護者結構
- 技術路線
- 商業支持
- SLA 與合規性要求
開源不是產品形態，而是一種合作形態。在關鍵基礎設施上，企業必須為“可持續性”和“可靠性”付費、投入或承擔責任。
市場分析
上面我們提到缺乏人手是導致 Ingress-NGINX 項目停止的一個直接原因，而從另一方面，市場產品的多樣性以及技術發展的走勢也是一個重要因素。查看 Ingress Controller Additional Controllers 頁面，我們可以看到高達 30 個 Ingress Controller 產品可供用户選擇，產品提供的多樣性也反向意味着上游作為參考定位的項目，其發展的情緒與意願會降低。
這些 Ingress Controllers，從驅動類型角度看，可以分為：
- API 場景驅動型：Ambassador(已被 Gravitee 收購)，Tyk，Gloo 典型的是此類
- 企業驅動型：F5 Container Ingress Services(CIS)，F5 NGINX Ingress Controller 等是典型此類
- 副產品驅動型：Istio Ingress，Cilium Ingress Controller 等屬於此
從產品技術分類看，可以分為：
- NGINX Based：例如 Azure Gateway Ingress，F5 NGINX Ingress Controller 等
- Envoy Based:例如 Contour, Emissary-Ingress, Kusk Gateway, Enroute，Gloo 等
- HAproxy Based：HAproxy Ingress Controller, Voyager
- 專用高性能硬件或軟件數據面 Based：F5 BIG-IP Container Ingress Services
作為 Kubernetes 的關鍵入口位置，Ingress Controller 承擔了兩個方面的具體落地，一個是流量，一個是安全。從這些諸多的產品可以看出，不同的社區、廠商都希望在此位置抓住用户流量，有的從自己擅長的 API 領域入手，有的則是利用自身在東西向流量或 K8s 網絡的優勢來切入到南北向流量的管理，而像 F5 則完全是利用自身在流量管理與 API 安全方面的領先優勢來進入到該領域。這裏有一個很重要的思考，Kubernetes 的流量是不是隻屬於 k8s 平台管理員考慮的範疇，是僅考慮 k8s 所定義的這些雲原生的網絡流量規範，還是應該更加務實的注重企業在實際落地服務發佈時的一些需求，如多端口，多 IP，更好的長連接管理等？我們是否應該站在全局基礎設施流量的高度來看待 Ingress Controller 的選型？
遷移策略與建議
既然入口控制器產品如此之多，在考慮進行方案遷移之時，您需要首先從以下三個維度來判別自己要選擇哪種策略：
- 繼續保持 Ingress 規範
- 考慮轉向新的 Gateway API 規範
- 考慮新的架構來建立更可靠與持久的入口解決方案
讓我們分別分析這些策略。
01 考慮繼續保持 Ingress 規範
繼續保持 Ingress 規範是技術遷移上難度最小的一種模式，幾乎所有的入口控制器產品都會支持 Ingress 規範。儘管是同規範平移，但是依然存在以下風險與難點：
方案自身特點導致的配置不對等：由於 Ingress 本身僅定義了少量的規範標準，導致了大量方案實現中都會存在方案本身獨特的特點，如不同的啓動參數，不同的全局配置項，不同的 annotations，不同的自定義 CRD，不同的片段插入，不同的插件。甚至在某些特定情況下你可能完全找不到能夠對等的配置方法，此時就必須為此做出取捨或找到變通的方法。
不同的數據面，產生不同的行為：NGINX，HAproxy，Envoy 等均為不同的數據面，即便相同的功能下，可能依然會有不同的行為特點，這是較為隱藏的風險，在實際遷移中要仔細測試，以驗證不同數據面產品是否對應用產生了不同的行為影響。因此從這個角度來説，依然選擇 NGINX 作為數據面是較為理智的行為，此時無需考慮不同數據面產品帶來的風險，且學習成本更低。
開源產品可持續性：我們不應該在同一個地方犯兩次錯誤，建議優先考慮企業驅動型 Ingress Controller 解決方案，由於這類解決方案的背後是商業公司在支持，因此選擇該類解決方案可以在產品的延續性、漏洞修復、新功能等方面得到足夠的保障。F5 的 Ingress Controller 將是最佳選擇，您一方面可以首先選用該解決方案的開源免費版本，在遷移成功後，再根據自己的實際需要，選擇是否購買企業服務支持以獲得服務以及更多商業版本功能特性，另一方面，如果您原本的配置非常複雜且工作量巨大，您還可以直接選擇購買 F5 NGINX 的諮詢服務以獲得廠商級遷移支持。
未來技術規範的支持：儘管我們是選擇 Ingress 規範的技術平移，但是我們依然也要着眼未來，即需考慮對 Gateway API 規範的支持，那麼此時您就需要疊加考慮相同數據面且又能夠同時支持 Gateway API 的產品或方案。F5 NGINX 的解決方案可以同時滿足這些條件。
安全 WAF 能力：如果您已在 Ingress-NGINX 中使用了第三方的 ModSecurity WAF，那麼您就需要注意選擇的目標方案是否依然能夠提供類似的 WAF 能力，這在大部分的開源 Ingress Controller 方案中都不提供，而F5 NGINX Ingress Controller 是支持部署 F5 WAF for NGINX 的。
此外，您還需要考慮在實際遷移過程中，必然是採用過渡式遷移，儘管我們可以使用 IngressClass 等技術來同時部署多種 Ingress Controller，但這些不同的控制器必須配置的是不重疊的 IP 或/和端口，這意味着在此期間應用的訪問將面臨不同的端口或者IP，因此用户還需考慮 DNS、應用修改配合、網絡架構修改等工作，例如在 Ingress Controller 之前部署 F5 等負載均衡器（軟件或硬件），來統一收口 IP 來避免 DNS 的大規模調整，並利用 F5 來將請求分發到不同的 Ingress Controller 上。如果您選擇的是 F5 NGINX 解決方案，這些架構級的工作將由 F5 一併幫您解決，充分降低了遷移的實際難度。
如果您想了解遷移到 F5 NGINX Ingress Controller 中的一些關鍵配置與參數項映射，您可以參考本篇遷移手冊。一般來説，用户的大部分配置會與以下幾個功能方面有關：
- 自定義 annotations
- 速率限制，或全局速率限制
- SSL 終結-四層服務轉發
- Headers 與 URL 操縱
- 安全策略或 WAF 策略
需要提醒的是，Ingress 規範已被 Kubernetes 凍結，意味着不會再有新的功能。但 F5 NGINX Ingress Controller 提供了自己的 CRD，該 CRD 下提供了大量的符合企業所需的特性功能，並保持持續發展。
02 考慮轉向 Gateway API 規範
恭喜您，選擇了一條新的道路，選擇 Gateway API 規範意味着您的入口解決方案將與社區保持一致，並獲得持續的新能力，但同時也意味着遷移的難度與工作量更大。由於這兩個規範完全不同，您需要自己逐項完成從 Ingress 規範到 Gateway API 規範的配置遷移，所以您不僅要保持功能遷移的一致性，還需要理解 Gateway API 的新設計思想。Gateway API 最大的設計思想是角色分離，它解決了 Ingress 中管理角色對象不清問題，清晰的定義了 Infrastructure provider, Cluster provider 以及 Application developer 這三個角色，使得在底層數據面、中層控制面、上層應用維護面解耦，適應了企業的實際需求。對於角色分離這一點，其實即便您使用 Ingress 規範的 F5 NGINX Ingress Controller 您一樣也可以通過 VS 與 VSR, Policy 這些 CRD 來獲得類似的體驗。整體上 Gateway API 解決了以下技術或團隊協作問題：
解決 Ingress 能力不足問題(核心，擴展，自定義)
- 避免實現方案過度依賴 Annotation/啓動參數
- 擴展支持更多協議（不僅僅是 http）
- 解決過於簡單的資源對象表示能力（例如 Ingress 僅有 Host，path 這些）
- 解決 Ingress 默認不可以跨 NS 問題
- 解決 Ingress 可移植性差的問題
- 由於原生 Ingress 功能單一，導致不同廠家產品採用大量不可互通的自定義擴展
解決 Ingress 角色對象不清問題
基於 API 契約，減輕了應用 owner 與基礎實施 owner 的溝通成本
讓雲原生架構與基礎架構有效融合,有利於企業 SRE
- 從僅開發者視角轉向關注企業 IT 架構整體
使用 Gateway API 的另一個優勢是在生成式 AI 時代下的模型推理服務，利用 Gateway API的Inference extension 來實現模型路由、優先級訪問控制、基於負載真實壓力感知的負載均衡等能力。F5 Gateway Fabric 項目已經實現該 Inference extension，可為推理服務提供更好的入口路由方案。
F5 在統一 NGINX One的SKU 下，為用户提供了多種產品方案組合，用户可以在 Ingress 技術方向與 Gateway API 技術方向靈活切換，我們提供了從 Ingress 規範轉向 Gateway API 規範的轉換工具 ingress2gateway 幫助您更加簡便的遷移到 Gateway API 規範。如果您想查閲 F5 NGINX 對Gateway API 規範的支持情況，可以參考此文檔鏈接：https://docs.nginx.com/nginx-gateway-fabric/overview/gateway-api-compatibility/。
至此我們可以稍作總結下，您可以選擇以下既安全又兼顧未來技術走向的遷移路徑：
03 考慮新的架構來建立更可靠與持久的入口解決方案
上述遷移方案中，我們主要討論的依然是從 PaaS 或者 Kubernetes 自身的角度來解決服務發佈問題，我們一直利用的都是 Kubernetes 自身網絡流量規範。這些都是純純的雲原生思想的設計。而在實際企業生產中，很難做到如此純淨的完全面向雲原生的應用設計，很多時候我們的應用是未經雲原生化改造，而直接遷移到容器中的，這些應用會需要類似長連接友好、會話保持友好、SNAT 地址友好、TCP 協議微調友好、四層協議友好、同 IP 多端口服務發佈、多 IP 同端口服務發佈、與 DNS 發佈聯動等實際需求。同時，從團隊的角度也需要將 PaaS 的服務流量入口與基礎架構網絡進行友好的對接，這就需要一個能夠融合和連接兩者的解決方案。
F5 Container Ingress Services（CIS）解決方案即是站在全局基礎設施流量角度來考慮的一個解決方案，它兼容 Ingress 方案，同時更加強調能夠解決上述提到的特殊企業級服務發佈需求。這是一個企業級的商業解決方案，擁有自己的 CRD，也擁有更加符合網絡人員視角的發佈定義，這確保了用户並不會因上游的協議規範變化而受到影響。同時 F5 的硬件產品為大規模服務發佈提供了強力的性能支撐。整體來説，F5 CIS 方案擁有以下特點：
- 更豐富的服務發佈方式
- 更高性能的數據面，增強的 L4 發佈能力
- 直達服務 pod，減少延遲
- 避免大 IP 承載所有業務，分散 IP 失敗導致的風險
- 跨部門協同，工作邊界清晰
- 支持 Hub 模式的權限隔離，確保網絡人員與應用人員不打架
- 支持 Multi k8s clusters
- 支持 DNS 聯動
- 支持 WAF 策略聲明式定義
- 支持與 Ingress Controller 配合與聯動
F5 同時還提供了支持 Gateway API 規範的 F5 BIG-IP Next For Kubernetes（BNK）方案，它與 CIS 類似，但是無需額外的 BIG-IP 設備或虛機，部署形態是以容器方式直接部署在系統中，或部署在 DPU 網卡中。
總結
通過上述分析，我們可以意識到，這將不是一個簡單的平移還是戰略重構的二選一，從實際安全生產運維角度，如果您當前正在使用 Ingress 規範，我們將建議您首先採用同數據面技術、同規範的平移，在應用遷移穩定後再考慮引入最新的 Gateway API 規範。F5 NGINX Ingress Controller 是 NGINX 的原廠產品，是 Ingress-NGINX 遷移的最佳同數據面方案，並可以有效保證產品的後續延續性。您可以參考上述提到的遷移路徑，可以順滑的繼續採用開源免費方案，也可以通過採用商業產品方案獲得更多高級特性以及服務支持。而如果您正處於沒有包袱的起始階段，我們將建議您站在全局基礎架構流量的角度重新考慮 Kubernetes 入口流量的設計，將其從架構性的角度引入，而不是僅僅為了面向開發人員進行簡單業務發佈的方式，您可以充分評估 F5 CIS 方案以及支持 Gateway API 規範的 F5 BIG-IP Next For Kubernetes（BNK）方案。
遷移必然會以過渡的形態持續較長時間，如果您遇到任何遷移的問題，歡迎與 F5 銷售代表聯繫，獲得我們專業遷移諮詢服務。
點擊下方文章，閲讀遷移手冊
01從 Ingress-NGINX Controller 遷移至 NGINX Ingress Controller
02將部署從 NGINX Ingress Controller 遷移至 NGINX Gateway Fabric
