自從宣佈 ingress-nginx 和 InGate 將於 2026 年 3 月退役以來，關於從 Ingress 遷移到 Gateway API 的問題越來越多。由於兩者設計差異，cert-manager 目前無法提供同樣的 TLS 自助服務體驗。
Ingress 是單一資源，而 Gateway API 將資源拆分為集羣運營方管理的 Gateway 資源和團隊管理的 HTTPRoute 資源，證書配置則放在集羣運營方管理的 Gateway 上。
缺失的關鍵是 Gateway API 的實驗性資源 XListenerSet，目標是恢復共享 Gateway 上的按團隊 TLS 配置。cert-manager 計劃在 1.20 版本（預計 2026 年 2 月 10 日）加入對 XListenerSet 的實驗性支持，1 月份會有 alpha 版本發佈。
多租户 Ingress 遷移難點
大多數 Ingress 用户採用多租户方式運行 Ingress 控制器，包括 ingress-nginx 和 InGate。所謂多租户 Ingress 控制器指的是：
- 每個集羣只有一個由平台團隊管理的共享控制器或代理。
- 各團隊管理自己的 Ingress 和 TLS 註解。
- cert-manager 自動按主機名簽發證書。
而 Gateway API 中，TLS 配置遷移到了 Gateway 資源：開發者可以創建 HTTPRoute，但無法安全修改平台團隊擁有的共享 Gateway。因此失去了 TLS 自助能力，每次 TLS 變更都需要提交工單，如下圖所示：
- 以前 Ingress，應用開發者自行配置 TLS。
- 現在 Gateway，應用開發者需請求集羣運營方配置 Gateway 上的 TLS。
這意味着自助體驗相較現有 Ingress 工作流有所下降。雖然這看似降低開發效率，但 Gateway API 的設計初衷是解決 Ingress API 中的安全隱患：不同團隊可能會通過創建相同主機名但不同 TLS 配置的 Ingress，惡意或無意劫持其他團隊流量。大型集羣中多個團隊的衝突 Ingress 對象常造成流量截取。將 TLS 配置集中在 Gateway 層，則強化了安全邊界，代價是簡單多租户場景下自助服務受限。
為什麼 cert-manager 目前無法獨立解決
cert-manager 當前對 Gateway API 的支持僅能管理 Gateway 資源上的 TLS 配置：cert-manager 監聽 Gateway 資源中帶有 cert-manager.io/issuer 或 cert-manager.io/cluster-issuer 註解、包含 HTTPS 監聽器且 tls.certificateRefs 已設置的對象，自動創建對應的 Certificate 和 Secret。
示例如下：
apiVersion: gateway.networking.k8s.io/v1
kind:Gateway
metadata:
name:istio-gateway
annotations:
cert-manager.io/cluster-issuer:letsencrypt-prod
spec:
gatewayClassName:istio
listeners:
-name:https
hostname:'foo.example.com'
port:443
protocol:HTTPS
allowedRoutes:
namespaces:
from:All
tls:
mode:Terminate
certificateRefs:
-name:gateway-tls
注意 cert-manager 不關注 HTTPRoute 上的主機名，因為這些主機名主要供 Gateway API 控制器識別對應 Gateway 的監聽器，不用於 TLS。
該模式僅在以下情況適用：
- 每個團隊擁有獨立 Gateway（增加成本與基礎設施複雜度），或
- Gateway 被實現為“輕量”邏輯對象。
但對常見的“一個共享 Gateway + 多團隊”模式不適用。當前沒有安全且簡便的方式允許多個團隊在共享 Gateway 上自主管理 TLS，除非使用風險較大的通配符證書或危險的 RBAC 配置。
ListenerSet：缺失的關鍵組件
根據 GEP-1713，Gateway API 計劃引入 ListenerSet 資源（目前是實驗性的 XListenerSet），主要用於解決由自動化工具（例如 Knative）管理大量監聽器的 Gateway 資源問題。
因此認為 ListenerSet 也能解決多租户共享 Gateway 上的 TLS 自助配置問題，同時保持基礎設施運營方對 Gateway 資源的控制權。
通過 ListenerSet，能夠實現：
- 平台團隊擁有唯一共享 Gateway 及其基礎設施。
- 各應用團隊在 ListenerSet 對象中創建自己的監聽器及 TLS 配置。
Gateway API 控制器通過 RBAC 和命名空間隔離，確保團隊只能管理自己的監聽器，避免配置衝突：
對 Ingress 用户來説，ListenerSet + HTTPRoute 是最接近原生 Gateway API 的 Ingress 體驗，如下圖所示：
- 過去 Ingress，應用開發者可自行配置 TLS。
- 現在 Gateway + ListenerSet，應用開發者依然能保持自助配置 TLS，無需每次都找集羣運營方。
cert-manager 路線圖：2026 年 2 月支持 XListenerSet
計劃發佈內容
cert-manager 1.20 將支持對 XListenerSet 資源的 cert-manager.io/issuer 和 cert-manager.io/cluster-issuer 註解，作為實驗性功能（需開啓特性開關）。XListenerSet 的註解優先於 Gateway 註解，後者作為默認。
時間線
- 2026 年 1 月：發佈支持 XListenerSet 的 alpha 版本，歡迎測試反饋。
- 2026 年 2 月 10 日：cert-manager 1.20 正式發佈，包含實驗性 XListenerSet 支持。
隨着 Gateway API 將 ListenerSet 資源升級為穩定版，cert-manager 將添加對穩定版本的支持，並提供從 XListenerSet 到 ListenerSet 的遷移方案。
Ingress-nginx 與 InGate 退役：用户影響
cert-manager 1.20 計劃於 2026 年 2 月發佈，恰在 ingress-nginx 和 InGate 退役前一個月。由於 XListenerSet 仍處於實驗階段，需明確預期：
- 目前使用 Gateway API 尚無安全且完善的多租户 TLS 自助方案。
- cert-manager 1.20 提供 XListenerSet 作為實驗路徑，供用户評估和提前採用。
- cert-manager 1.21 或 1.22 將在 Gateway API 1.5 穩定支持 ListenerSet 後，提供穩定支持。
總結
cert-manager 方面表示，其致力於讓用户平滑過渡到 Gateway API。已開始將所有教程遷移到 Gateway API，期望 XListenerSet 為多租户 Ingress 控制器用户提供清晰遷移路徑。
對於現有 ingress-nginx 用户，建議先遷移到其他 Ingress 控制器（如 Traefik），而非立刻切換 Gateway API。待 cert-manager 支持穩定的 ListenerSet 資源後，再規劃向 Gateway API 的遷移。
詳情可查看官方公告。
