Ingress-Nginx 26年3月正式退役！那以后用什么？当然是 Gateway API！

希里安近日见闻

最近天冷了，各位小伙伴注意保暖，身体健康才是最重要的！

大名鼎鼎的Cloudflare宕机事件各位小伙伴应该看到了吧，号称科技圈的赛博活佛，居然发生了大规模的服务中断，很多媒体进行了报道，每次互联网服务的中断事件，做运维相关职位的小伙伴应该是职业本能比较关注的。

介绍下Cloudflare

Cloudflare是一家美国的互联网基础设施与网络安全公司，总部在旧金山。它提供的核心能力可以概括为三类：加速网站访问、保护网站安全、提供边缘计算能力

Cloudflare 为什么这么重要？

• • 全球最大 DDoS 防护网络
• • 超过 20% 的全球网站使用 Cloudflare
• • 拥有全球最快的DNS解析服务（1.1.1.1）
• • Workers 边缘计算越来越受欢迎
• • 极高的稳定性（所以一宕机会非常显眼）
• • 免费套餐非常强（个人开发者也用得上）

很多网站把 Cloudflare 当作“基础设施的一部分”，所以它一旦宕机，全球很多服务都会受到影响。它的客户包括：

• • 大型科技公司（X、ChatGPT、Discord、Shopify、DoorDash 等）
• • 金融机构
• • 在线服务平台
• • 开源项目（npm、GitLab、PyPI 等使用 Cloudflare 的安全加速）
• • 政府与企事业单位

事件时间：2025-11-18 约 11:20 UTC 开始发生大规模故障，14:30 UTC 开始恢复主要流量，17:06 UTC 恢复到全部服务正常。

影响范围：Cloudflare 的核心 CDN/安全路径受影响，中断波及多个高流量平台，包括X、ChatGPT、Spotify、Canva以及其他依赖Cloudflare的网站和服务。用户报告称，这些平台出现加载失败、错误页面或完全无法访问。

Cloudflare官方事后分析（Post-Mortem）明确表示不是网络攻击或外部恶意行为。此次宕机源于Bot Management（机器人管理）功能中的一个潜在bug。

感兴趣的小伙伴，具体可查看官方博客https://blog.cloudflare.com/zh-cn/18-november-2025-outage/2025 年 11 月 18 日 Cloudflare 服务中断 2025-11-18[1]

Ingress-Nginx 即将退役

昨天看到这篇CNCF的文章Ingress NGINX 退役通知：你需要了解的内容[2]，不知道各位小伙伴有看没。

我给大家总结了下，大概如下：

• • Kubernetes SIG Network 和安全响应委员会宣布，Ingress NGINX 项目将进入退役流程
• • 项目将提供有限维护直至 2026年3月。之后将不再提供任何新功能、错误修复或安全更新
• • 虽然现有部署不会“立即失效” — 安装资源（Helm chart、镜像）仍可使用，但从安全、兼容性、功能演进角度看，风险将逐步上升

退役原因：

• • 维护负担重：项目代码复杂，灵活性高，这给安全与维护带来了巨大挑战
• • 维护者不足：长期以来主要依靠极少数维护者利用业余时间支撑（one or two people doing development work, on their own time, after work hours and on weekends）
• • 新的标准、架构方向：随着 Gateway API 的成熟，Kubernetes 社区把网络入口流量管理从传统的 Ingress 模型扩展到更丰富、标准化、更具有多层面 (L4/L7) 支持的模型，因而，社区资源倾向于“新标准”而不是继续强化一个即将被逐步淘汰的控制器
• • 安全漏洞暴露＋风险上升：文章提到比如 CVE-2025-1974 等严重漏洞让社区警觉：一个广泛部署但维护薄弱的项目，在安全形势快速变化下，风险难以控制

给用户的建议：

• • 首选推荐：迁移到现代替代方案 Gateway API
• • 备选方案：如果仍需使用 Ingress 资源，可选择 Kubernetes 文档中列出的其他 Ingress 控制器（Apisix、Kong、BFE、Cilium、Higress、Istio、Envoy、Traefik等等）

退役时间线

其实，这个Ingress-Nginx退役并不意外，所以大家还可以选择其他正在维护的ingress项目，当然最好还是慢慢迁移到官方推荐的替代方案 Gateway API

2023年10 月: Gateway API v1.0 正式发布，标志其为 Kubernetes 流量入口的新标准 2025年11月: 官网宣布将于 2026年3月停止维护 2026年3月: 预计完全退役

为什么Ingress要迁移至Gateway API？

这里就不具体展开讲Ingress的基础概念，不太清楚的可以查看官方文档Ingress 控制器[3]

Ingress 模型的局限性

1. 1. 注解依赖：功能配置依赖大量供应商特定注解
2. 2. 类型安全缺失：配置错误只能在运行时发现
3. 3. 扩展性差：难以支持复杂的流量管理需求
4. 4. 多租户支持弱：缺乏细粒度的权限控制

理论上来说 Ingress 可以换控制器，但实际上Ingress 设计于 2014 年，当时功能非常有限：

• • 主体只能表达：Host/Path → Service
• • 复杂功能只能依靠大量 非标准注解（annotations）：
• • 每家控制器有 不同注解
• • 路由不兼容
• • 配置方式不兼容
• • 行为不一致

导致迁移成本极高

annotations:
    # 大量功能依赖注解，缺乏类型安全
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
    nginx.ingress.kubernetes.io/rate-limit: "100"

Gateway API 的优势

Gateway API 有 统一的 CRD 标准：

• • GatewayClass
• • Gateway
• • HTTPRoute
• • TCPRoute
• • UDPRoute
• • GRPCRoute
• • TLSRoute

不同控制器遵循共同标准，迁移成本极低

多 Listener 多端口 原生支持 ngress 只能监听一个 80/443 Gateway 支持：

• • 多个端口
• • 多协议
• • 多 TLS 配置
• • 同一个网关下多个 Route

对多租户尤其友好

内置金丝雀、流量分割、Header 匹配、重写等高级路由

backendRefs:
  - name: v1
    weight: 80
  - name: v2
    weight: 20

无需注解！这是最大优势

支持多种网关实现（可自由选择）

Ingress 最大依赖 NGINX，Gateway 则支持：

• • Envoy
• • HAProxy
• • Traefik
• • Cilium
• • Kong
• • GKE/AKS/AWS-LB 原生控制器

选择更多，生态更强

Gateway API 控制器选择

首选：Envoy Gateway

• • Kubernetes 官方支持
• • Envoy 是 CNCF 成熟项目
• • 性能极强
• • 企业级能力（mTLS、WASM 插件、高级路由）
• • CRD 兼容最好
• • 部署相对容易

这是目前替代 Ingress-NGINX 的 最主流方案

架构组件

• • envoy-gateway-controller: Gateway API 资源管理
• • envoy-proxy: 数据平面流量处理
• • rate-limit-service: 速率限制服务
• • ext-auth-service: 外部认证服务

Gateway API 如何部署

这里以最主流的 Envoy Gateway 为例

Step 1：安装 Gateway API CRD

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.4.0/standard-install.yaml

检查：

kubectl get crd | grep gateway

如果选择Envoy Gateway的话，这一步就不用执行了，因为Envoy Gateway 会自动带上 Gateway API CRD，为了更好的安装体验和兼容性

# envoy 附带了最新版本的gateway api crd资源
root@node1:~/gateway-helm/crds# ls
gatewayapi-crds.yaml  generated

Step 2：安装 Envoy Gateway

方式 A：快速部署

kubectl apply -f https://github.com/envoyproxy/gateway/releases/download/v1.6.0/install.yaml

方式 B：使用 Helm（推荐）

helm install eg oci://docker.io/envoyproxy/gateway-helm --version v1.6.0 -n envoy-gateway-system --create-namespace

等待部署：

kubectl wait --timeout=5m -n envoy-gateway-system deployment/envoy-gateway --for=condition=Available

Step 3：创建 GatewayClass

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: envoy
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller

kubectl apply -f gatewayclass.yaml
root@node1:~# kubectl get gatewayclass
NAME    CONTROLLER                                      ACCEPTED   AGE
envoy   gateway.envoyproxy.io/gatewayclass-controller   True       30d

Step 4：创建 Gateway

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: eg
spec:
  gatewayClassName: envoy
  listeners:
    - name: http
      protocol: HTTP
      port: 80

kubectl apply -f gateway.yaml

Step 5：创建 HTTPRoute（替代 Ingress）

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: myapp-route
spec:
  parentRefs:
    - name: eg
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: myapp
          port: 80

kubectl apply -f myapp-route.yaml

当然以上步骤是分开的，也可以直接使用官方给的例子：

kubectl apply -f https://github.com/envoyproxy/gateway/releases/download/v1.6.0/quickstart.yaml -n default

Ingress → Gateway API 转换

Ingress

kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: example.com

Gateway API

kind: HTTPRoute
spec:
  hostnames: ["example.com"]
  rules:
  - matches:
      - path:
          type: PathPrefix
          value: /
    filters:
      - type: URLRewrite
        urlRewrite:
          path:
            type: ReplaceFullPath
            replaceFullPath: /

优势：全部是标准字段，无需注解，控制器兼容性好

实际建议迁移策略

Step 1：迁移前准备扫描

• • Ingress 资源以及注解使用
• • 检查依赖的 NGINX snippet 的资源
• • TLS 配置
• • 访问模式
• • 制定回滚计划

Step 2：转换准备

• • 调研控制器（推荐 Envoy Gateway）
• • 部署Gateway API CRDs
• • 安装部署选定的Gateway控制器
• • 创建GatewayClass和Gateway资源
• • 逐步转换HTTPRoute配置
• • 更新CI/CD流水线

Step 3：双栈运行（安全期）

• • Ingress-NGINX + Envoy Gateway 并存
• • 流量逐步切换，验证流量路由正确性
• • 验证所有业务稳定

Step 4：迁移后验证

• • 功能完整性测试
• • 安全配置验证
• • 监控告警配置
• • 文档更新

Step 5：清理 Ingress-NGINX（2026 前完成）

• • 移除控制器 Deployment
• • 移除 IngressClass
• • 清理相关注解

最后

以上先介绍这些，当然最终的选择取决于你的工作环境、团队协作需求以及个人偏好。

安装使用只是第一步，通过工具的学习使用，让他人受益才能发挥工具的价值！

引用链接

[1] 2025 年 11 月 18 日 Cloudflare 服务中断 2025-11-18: https://blog.cloudflare.com/zh-cn/18-november-2025-outage/ [2] Ingress NGINX 退役通知：你需要了解的内容: https://github.com/kubernetes-retired/ [3] Ingress 控制器: https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress-controllers/