Ingress-nginx 退役：cert-manager 现状支持及未来展望
自从宣布 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 的迁移。
详情可查看官方公告。
