Ingress-nginx 退役：cert-manager 现状支持及未来展望

花韻仙語

发布时间：2025-12-05 16:00:18

424人浏览过

来源于php中文网

原创

自从 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-nginx 退役：cert-manager 现状支持及未来展望

过去使用 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 核心资源的绝对控制权。

Designs.ai

AI设计工具

下载

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

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

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

Ingress-nginx 退役：cert-manager 现状支持及未来展望

对习惯 Ingress 的用户而言，“ListenerSet + HTTPRoute”组合提供了最贴近原生 Gateway API 的类 Ingress 使用体验，如下图所示：

Ingress-nginx 退役：cert-manager 现状支持及未来展望

过去 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 本身的注解，后者作为兜底默认策略。