Ingress-nginx退役，cert-manager的现状支持与未来展望

Ingress-nginx 退役后，cert-manager 对现有支持及未来展望值得关注，随着 Ingress-nginx 逐渐退出使用，cert-manager 作为证书管理解决方案，正逐步承担更多重任，当前，cert-manager 已具备对多种证书管理的支持能力，并不断优化以适应市场需求，cert-manager 将继续提升性能、扩展支持范围，确保平稳过渡，为用户提供更可靠、高效的证书管理服务。

自从 ingress-nginx 和 ingate 宣布将于 2026 年 3 月正式停止维护以来，围绕如何从 ingress 平滑迁移到 gateway api 的讨论持续升温。由于二者在架构理念与资源模型上的根本差异，cert-manager 当前尚无法在 gateway api 场景下复现原有 ingress 中的 tls 自助服务能力。

Ingress 是一个单体式资源，而 Gateway API 则采用分层设计：由集群运维人员管控的 Gateway 资源，与由业务团队自主管理的 HTTPRoute 资源解耦；TLS 配置被统一收口至 Gateway 层，由平台侧集中管理。

当前缺失的关键拼图，是 Gateway API 中处于实验阶段的 XListenerSet 资源——其核心目标正是在共享 Gateway 上恢复按团队粒度的 TLS 自主配置能力。cert-manager 已规划在 1.20 版本（预计发布于 2026 年 2 月 10 日）中引入对 XListenerSet 的实验性支持，并将在 1 月份先行推出 alpha 版本供早期验证。

多租户 Ingress 迁移的核心挑战

绝大多数 Ingress 用户以多租户模式部署控制器，典型代表包括 ingress-nginx 和 InGate。所谓多租户 Ingress 控制器，通常具备以下特征：

• 单个集群内仅部署一套由平台团队统一运维的共享控制器或代理；
• 各业务团队独立创建并维护自己的 Ingress 资源及 TLS 相关注解；
• cert-manager 基于主机名自动完成证书申请、签发与注入。

而在 Gateway API 模型中，TLS 配置已上移至 Gateway 资源层级：开发者虽可自由创建 HTTPRoute，却无权修改平台团队所拥有的共享 Gateway 对象。这直接导致 TLS 配置丧失自助能力，任何变更均需提交工单协调处理，如下图所示：

• 过去使用 Ingress 时，应用开发者可直接定义 TLS 参数；
• 当前采用 Gateway 时，TLS 配置必须由集群运营方在 Gateway 上统一设置。

这一转变虽削弱了部分场景下的开发敏捷性，但恰恰体现了 Gateway API 的安全设计哲学：Ingress API 存在潜在风险——不同团队可能通过声明相同主机名但不同 TLS 设置的 Ingress 对象，无意或恶意劫持他人流量。尤其在大型集群中，多个团队共存时因冲突 Ingress 导致的流量劫持事件屡见不鲜。将 TLS 管控权收敛至 Gateway 层，显著提升了租户间的安全隔离边界，代价则是牺牲了简单多租户模型下的自助便利性。

cert-manager 当前为何难以独立破局

目前 cert-manager 对 Gateway API 的 TLS 支持，仅限于监听 Gateway 资源本身：它会识别带有 cert-manager.io/issuer 或 cert-manager.io/cluster-issuer 注解、启用了 HTTPS 监听器、且已配置 tls.certificateRefs 字段的 Gateway 对象，并据此自动生成 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 中的主机名字段，因为该字段仅用于路由匹配，不参与 TLS 握手过程。

该机制仅适用于以下两类有限场景：

• 每个团队独占一个 Gateway 实例（带来额外资源开销与运维复杂度），或
• Gateway 实现为轻量级逻辑抽象（如某些服务网格控制面）。

但对于主流的“单一共享 Gateway + 多团队协作”模式而言，当前并无兼顾安全性与易用性的标准方案。若强行启用通配符证书或过度开放 RBAC 权限，则可能引入严重安全隐患。

ListenerSet：填补空白的关键组件

依据 GEP-1713 提案，Gateway API 正在推进 ListenerSet 资源的标准化（现阶段以实验性 XListenerSet 形式存在），最初定位是支撑 Knative 等自动化平台高效管理海量监听器的需求。

实践发现，ListenerSet 同样能有效应对多租户共享 Gateway 下的 TLS 自助配置难题，同时保障基础设施运营方对 Gateway 核心资源的绝对控制权。

借助 ListenerSet，可达成如下分工：

• 平台团队掌控唯一的共享 Gateway 及其底层基础设施；
• 各业务团队通过创建属于自身命名空间的 ListenerSet 对象，定义专属监听器及其 TLS 配置。

Gateway API 控制器结合 RBAC 与命名空间隔离机制，确保各团队只能操作自己所属的 ListenerSet，彻底规避跨团队配置冲突：

对习惯 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 注解（需显式启用特性门控）。当同一 Gateway 关联多个 ListenerSet 时，XListenerSet 的注解优先级高于 Gateway 本身的注解，后者作为兜底默认策略。

关键时间节点

• 2026 年 1 月：发布首个支持 XListenerSet 的 alpha 版本，面向社区开放测试与反馈；
• 2026 年 2 月 10 日：cert-manager 1.20 正式版上线，包含实验性 XListenerSet 支持功能。

待 Gateway API 将 ListenerSet 资源正式晋升为稳定版本（v1）后，cert-manager 将同步提供对稳定版 ListenerSet 的完整支持，并配套推出从 XListenerSet 到 ListenerSet 的平滑迁移工具与指南。

Ingress-nginx 与 InGate 退役：实际影响评估

cert-manager 1.20 计划于 2026 年 2 月发布，恰好位于 ingress-nginx 和 InGate 官方退役前一个月。鉴于 XListenerSet 当前仍属实验性质，需明确以下预期：

• 当前基于 Gateway API 的多租户 TLS 自助方案尚未成熟，缺乏生产就绪的安全保障；
• cert-manager 1.20 提供的 XListenerSet 支持，仅为技术预演路径，供用户提前评估与试用；
• 稳定支持将随 Gateway API v1.5（含 ListenerSet GA）落地，预计集成于 cert-manager 1.21 或 1.22 版本中。

结语

cert-manager 团队强调，推动用户平稳过渡至 Gateway API 是其长期战略重点。目前已全面启动文档与教程体系向 Gateway API 的迁移工作，期望 XListenerSet 成为多租户 Ingress 控制器用户的首选演进路径。

对于仍在使用 ingress-nginx 的用户，建议优先考虑迁移至其他成熟的 Ingress 控制器（如 Traefik），而非仓促切换至 Gateway API。待 cert-manager 对稳定版 ListenerSet 提供完备支持后，再系统性规划向 Gateway API 的整体迁移。

更多细节请参阅官方公告。

源码地址：点击下载