Ingress NGINX停服倒计时4个月！你的业务还扛得住吗？

2025 年 11 月，Kubernetes SIG Network 与 Security Response Committee 宣布社区维护的 Ingress NGINX 将在 2026 年 3 月退休。届时将不再发布新版本、修复缺陷或提供安全更新。现有部署不会立即中断，相关安装包（镜像、Helm Chart）也将保留，但继续在生产中使用将面临无法修复的安全风险。

本文基于社区公告与多方技术文章，系统梳理 Ingress NGINX 退休的背景、对组织的影响、可选迁移路径与实操建议，并给出示例配置与检查命令，帮助平台团队制定可靠的迁移方案。

1. 为什么要退休 Ingress NGINX

• • 维护人力长期不足：多年仅 1–2 位维护者依靠业余时间支撑，难以匹配其广泛使用带来的维护负荷。
• • 技术债与安全风险：历史上为灵活性提供的“snippets”等特性在今天被视为严重安全隐患，形成难以消解的技术债。
• • 替代方向清晰：社区推动 Gateway API 作为 Ingress 的现代替代，具备更明确的职责分离、更丰富的原生特性、更好的可扩展治理。

结论是：为保障用户安全与生态可持续性，必须明确终止维护时间表，并引导迁移。

2. 对组织的实际影响

• • 安全合规风险提升：2026 年 3 月后新披露的漏洞将不再修复，互联网暴露型业务风险不可接受。
• • 运营负担增加：继续使用意味着需要额外外层安全防护（WAF、隔离、流量限制）与应急预案，成本显著。
• • 隐性迁移工作量：大量团队将从“黑盒”使用转向理解与重构路由与策略，跨团队协同与变更治理成为主体工作。
• • 生态变化：厂商与社区提供多条替代路径（Gateway API、HAProxy、NGINX OSS 等），但需要结合现有特性依赖做兼容性评估。

建议：尽快评估现状、制定迁移路线，并预留充足的联调与验收窗口。

3. 可选迁移路径与适用场景

路线 A：迁移至 Gateway API（长期架构升级）

• • 适用：愿意进行架构现代化、需要更强的策略表达与协议支持（HTTP/HTTPS/TCP/UDP/gRPC）、多团队职责分离的中大型平台。
• • 优势：资源模型清晰（Gateway/GatewayClass/HTTPRoute 等）、原生支持流量分配与高阶匹配、减少注解耦合。
• • 成本：学习曲线较高；需要新运维流程与监控审计体系；多租户隔离与治理需重新设计。

路线 B：平滑替换为其他 Ingress 控制器（短期降低风险）

• • 适用：时间紧、特性依赖重、希望最小改动维持现有 Ingress 资源与注解模式。
• • 常见选项与特点：
• • NGINX Ingress Controller（F5 维护的 OSS）：Apache 2.0 许可、活跃维护、与 Ingress NGINX 注解映射完善，支持 CRD（VirtualServer/Policy/TransportServer），有明确迁移文档与社区支持。
• • HAProxy Kubernetes Ingress：高性能、注解等价能力强，提供从 NGINX 注解的直接映射与迁移助手工具；对“snippets”这类不安全能力有更稳健替代。
• • Traefik（Nginx Ingress Provider，实验性）：宣称支持约 80% 常用注解，可低改动迁移，但全局行为与部分能力有限制，需要仔细对齐。
• • 云厂商控制器（AWS/GCP/Azure）：与云负载均衡深度集成，适合单云策略，但存在锁定与混合云限制。
• • 其他企业级控制器（Kong、Emissary 等）：功能丰富（认证、限流、API 网关能力），适合有现成栈或需要高阶策略的组织。

建议：对特性依赖和运维约束做矩阵评估后选择，避免仅凭“熟悉度”或“单一指标”。

4. 迁移准备与盘点清单

• • 识别是否使用 Ingress NGINX：
• • 运行命令：kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx
• • 全量收集 Ingress 与注解使用：
• • 目的：建立注解使用的基线，识别不可替代或需要改造的部分（如 snippets、复杂 URL 重写、WAF 集成）。
• • 关联的运维项：
• • 证书管理（cert-manager、默认 cipher 与 TLS 行为）、监控与日志、变更与回滚流程、域名/DNS 切换策略。
• • 风险点重点关注：
• • 限流算法一致性、TLS 双向认证与链处理、URL 重写与正则、WAF（ModSecurity/CRS）规则迁移与等效性。

示例命令（提取注解清单并审计）：

   # 列出所有 Ingress 的注解（按命名空间与名称）
kubectl get ingress -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.metadata.annotations}{"\n"}{end}'

# 快速检索是否使用不安全的 snippets 注解
kubectl get ingress -A -o json | jq -r '
  [.items[] | {
    ns: .metadata.namespace,
    name: .metadata.name,
    hasSnippets: ( (.metadata.annotations // {}) | has("nginx.ingress.kubernetes.io/configuration-snippet") )
  }] | map(select(.hasSnippets)) | .[] | "\(.ns)\t\(.name)"'

5. 分阶段迁移策略（建议流程）

• • Phase 1：并行部署新控制器
• • 在独立命名空间安装目标控制器（例如 NGINX OSS 或 HAProxy），不要立即替换生产流量。
• • Phase 2：配置映射与等价性验证
• • 为注解建立映射清单；必要时采用目标控制器的 CRD（如 VirtualServer、Policy）替代注解堆叠。
• • Phase 3：功能与性能测试
• • 双运行（双控制器）+ 指定 ingressClassName 控制路由归属；使用测试应用验证路由、SSL、CORS、认证、限流、重写、可观测性。
• • Phase 4：灰度迁移与回滚预案
• • 从低风险业务开始逐步切换，DNS/流量分级迁移，监控关键指标并保留快速回退路径。
• • Phase 5：收尾与治理更新
• • 完成迁移后卸载 Ingress NGINX，清理旧 ConfigMap/注解，更新运维手册、监控与告警。

6. 配置示例与参考

下列片段展示从 Ingress NGINX 迁移到两类常见替代方案的配置思路。请根据自身控制器版本与官方文档校验细节。

6.1 NGINX Ingress Controller（F5 OSS）并行部署与最小改动迁移

• • 并行安装（Helm 示例，独立命名空间）：

   helm repo add nginx-stable https://helm.nginx.com/stable
helm repo update
helm install nginx-oss nginx-stable/nginx-ingress \
  --namespace nginx-oss --create-namespace \
  --set controller.allowSnippetAnnotations=false

• • 最小改动迁移示例（更新 ingressClassName 指向新控制器）：

   apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  namespace: demo
  annotations:
    # 原有 NGINX 注解通常在迁移指南中有映射；尽量避免使用 snippets
    nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
  ingressClassName: nginx-oss # 指向新控制器的 IngressClass
  rules:
  - host: www.example.com
    http:
      paths:
      - path: /app/(.*)
        pathType: Prefix
        backend:
          service:
            name: web-svc
            port:
              number: 80

• • 使用 CRD（VirtualServer）提升可读性与校验：

   apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: web
  namespace: demo
spec:
  host: www.example.com
  routes:
  - path: /app
    route:
      path: /app
    action:
      pass: web-svc
  policies:
  - name: rate-limit-policy

6.2 HAProxy Ingress Controller 注解映射示例

• • 常见注解映射（示意）：
• • nginx.ingress.kubernetes.io/load-balance -> haproxy.org/load-balance
• • nginx.ingress.kubernetes.io/backend-protocol -> haproxy.org/backend-protocol
• • nginx.ingress.kubernetes.io/proxy-connect-timeout -> haproxy.org/proxy-connect-timeout
• • nginx.ingress.kubernetes.io/cors-allow-origin -> haproxy.org/cors-allow-origin
• • 示例 Ingress（指向 HAProxy 控制器）：

   apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  namespace: demo
  annotations:
    haproxy.org/load-balance: "leastconn"
    haproxy.org/backend-protocol: "HTTP"
    haproxy.org/proxy-connect-timeout: "5s"
    haproxy.org/cors-allow-origin: "https://www.example.com"
spec:
  ingressClassName: haproxy
  rules:
  - host: www.example.com
    http:
      paths:
      - path: /app
        pathType: Prefix
        backend:
          service:
            name: web-svc
            port:
              number: 80

6.3 Gateway API 基本示例（HTTPRoute）

• • 资源模型：GatewayClass -> Gateway -> HTTPRoute
• • 示例（以 HTTPRoute 为例，聚焦路由配置）：

   apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: web-gw
  namespace: gateway
spec:
  gatewayClassName: my-gateway-class
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      certificateRefs:
      - kind: Secret
        name: web-cert
    allowedRoutes:
      namespaces:
        from: All
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: web-route
  namespace: demo
spec:
  parentRefs:
  - name: web-gw
    namespace: gateway
  hostnames:
  - "www.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /app
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplacePrefixMatch
          replacePrefixMatch: /
    backendRefs:
    - name: web-svc
      port: 80

7. 测试与验证要点

• • 功能一致性：路由匹配、重写、CORS、认证、会话亲和、WAF 规则等逐项验证。
• • 性能与稳定性：吞吐、延迟、CPU/内存占用、零停机热更新能力。
• • 安全性：TLS 配置、证书链、双向认证、限流与防护策略；审查是否移除不安全能力（如 snippets）。
• • 可观测性：原生指标（Prometheus）、日志结构、故障定位手册更新。
• • 变更与回滚：灰度策略、双控并行、DNS/流量切换与快速回退预案。

8. 结论与建议

Ingress NGINX 的落幕不是失败，而是生态演进的必然阶段。平台团队应将其视作契机，借助更现代的接口与治理模型提升网络层的安全性、可维护性与可观测性。路线选择上，“Gateway API 作为长期目标 + 近期选择一个与现状贴近的控制器平滑替换”是多数组织的务实策略。

关键在于：尽快盘点特性依赖、做好并行验证、建立稳健的灰度与回滚方案，以工程化的方式降低迁移风险，避免在 2026 年前后被动应对。

参考与延伸阅读

加入知识星球，共同探索云原生学习之旅！

重磅！！

往期回顾

K8S工具推荐，Kargo：下一代 GitOps 持续交付工具

K8S工具推荐：Bufstream-唯一通过 Jepsen 验证的云原生 Kafka 实现

K8S工具推荐： 使用 Kubemark 进行 Kubernetes 大规模集群模拟实践

K8S工具推荐：使用Argo Rollouts实现GitOps自动化测试与回滚

K8S工具推荐：资源编排新利器：三大云厂商联合推出 KRO

K8S工具推荐：告别复杂认证！Kubernetes登录神器kubelogin指南

K8S工具推荐：Kubernetes资源优化神器KRR：一键诊断集群资源浪费

Kubernetes工具推荐：使用 k8s-pod-restart-info-collector简化故障排查

K8S工具推荐：动态无缝的Kubernetes多集群解决方案-Liqo

K8S学习路线2025

𝙺̲𝚞̲𝚋̲𝚎̲𝚛̲𝚗̲𝚎̲𝚝̲𝚎̲𝚜̲ 管理的最佳实践（2025）

如何落地一个企业级PaaS容器云平台：从规划到实施全流程指南