Kubernetes 生态中，ingress-nginx 作为最受欢迎的 Ingress 控制器之一，长久以来支撑着无数集群的流量入口。然而，随着 Gateway API 的成熟，其弃用进程已然启动。这一决定并非仓促，而是基于深刻的工程考量：维护开销的持续攀升、扩展性瓶颈的显现，以及 SIG-network 社区的渐进式公告策略。本文将从工程视角剖析这些决策，提供可落地的参数建议和迁移清单，帮助团队平稳过渡。
维护开销的工程剖析
ingress-nginx 的维护负担是推动弃用进程的核心驱动力。作为一个基于 NGINX 的开源项目，它需要同步 Kubernetes API 变更、NGINX 核心更新以及社区反馈的安全补丁。根据 GitHub 仓库数据，ingress-nginx 每年处理数百个 issue 和 PR，其中安全漏洞修复占比显著。举例而言，2025 年初披露的 CVE-2025-1974（CVSS 9.8）允许未经认证的攻击者通过 Pod 网络执行任意代码，这暴露了项目在复杂代码库下的脆弱性。
工程上，维护开销体现在多方面。首先，代码库规模庞大：控制器需同时管理控制平面（Go 语言实现）和数据平面（NGINX 配置生成），导致高耦合。高负载时，CPU 争用可能引发 Pod 重启，影响稳定性。其次，API 兼容性问题频发。随着 Kubernetes 从 v1beta1 向 v1 迁移，ingress-nginx 需反复调整注解支持，如废弃的 nginx.ingress.kubernetes.io/secure-backends（v0.21.0 起）。这些变更要求维护者投入大量时间测试兼容性，尤其在多版本集群环境中。
量化来看，社区测试显示，ingress-nginx 在启用插件（如限流、认证）后的 QPS 仅为 9-10 万，而无插件场景下也易受规则更新影响吞吐下降 20% 以上。相比之下，维护一个活跃的贡献者团队已成挑战：项目计划进入维护模式，仅修复 bug 和安全问题，不再添加新功能。这反映了资源有限的现实 ——SIG-network 更倾向将精力转向标准化 API。
与 Gateway API 的扩展限制对比
ingress-nginx 的 scaling limitations 在 Gateway API 面前尤为突出。传统 Ingress API 局限于 L7 HTTP/HTTPS 协议，支持 TCP/UDP 等 L4 需自定义扩展，缺乏原生标准化。这导致在微服务环境中，gRPC 或多协议流量管理依赖供应商特定注解，移植性差。例如，NGINX Ingress 的 server-snippet 虽灵活，但易引发配置冲突，且不兼容其他控制器如 HAProxy。
Gateway API 则通过 GatewayClass、Gateway 和 HTTPRoute 等资源，提供角色分离模型：管理员管理 Gateway（定义监听端口、协议），开发者专注 Route（路由规则）。这提升了扩展性，支持内置流量拆分（权重 0-100%）、镜像和头部匹配，而非依赖注解。基准测试显示，基于 Envoy 的 Gateway 实现（如 Envoy Gateway）在 16 连接下 QPS 超 13 万，远高于 ingress-nginx 的 3-4 万（单连接）。此外，Gateway API 的 CRD 设计允许快速迭代，v1.0 已 GA，支持 L4/L7 统一管理，避免了 Ingress 的碎片化。
工程决策中，scaling 限制还体现在资源消耗上。ingress-nginx 的混合容器（控制 + 数据平面）在高并发下内存峰值可达 500MB/Pod，而 Gateway API 实现如 Kong Gateway 通过分离平面，单 Pod 仅 200MB 左右。更重要的是，Gateway API 的可观测性更强：内置指标暴露（如 Prometheus 兼容的流量拆分率），而 ingress-nginx 需额外配置 Metrics Server。
这些对比促使 SIG 认定 ingress-nginx 难以跟上云原生演进：微服务需细粒度路由，边缘计算需 L4 支持。弃用后，项目将转向 InGate 等继任者，专注于维护模式下的稳定性。
Kubernetes SIG 的分阶段公告策略
Kubernetes SIG-network 的公告策略体现了社区的渐进主义，避免 abrupt 变更对生态冲击。进程始于 KEP（Kubernetes Enhancement Proposal）讨论，如 KEP-1453 将 Ingress 毕业到 GA，同时预告 Gateway API 的引入。2025 年 11 月 12 日的官方博客（primary source）标志着正式退休公告：ingress-nginx 将于 2026 年底进入维护模式，期间提供安全补丁，但无新功能。
分阶段策略包括：1）API 弃用警告：从 v1.22 起，extensions/v1beta1 Ingress 被移除，强制迁移到 networking.k8s.io/v1；2）社区反馈期：通过 SIG 会议和 GitHub issues 收集意见，持续 6-12 个月；3）迁移工具发布：如 ingress2gateway 工具，可自动转换 Ingress YAML 到 Gateway 资源；4）生态兼容：要求实现者（如 NGINX Gateway Fabric）支持双模，平滑过渡。
这一策略的风险控制体现在监控参数上：SIG 建议集群管理员设置告警阈值，如 Ingress 规则兼容率 <90% 时触发迁移通知。工程上，可落地参数包括：回滚策略（保留 ingress-nginx v1.11.5 作为 fallback）、超时阈值（Gateway 部署后 5min 内验证流量完整性）。
可落地参数与迁移清单
为工程化弃用，提供以下参数和清单：
监控要点：
- 维护模式下，安全补丁响应时间 ≤7 天；QPS 下降 >10% 触发告警。
- Scaling 参数：Gateway 流量拆分权重 10-90%，镜像比例 ≤5% 以避开性能瓶颈。
- 兼容阈值：双模期，Ingress/Gateway 流量比 1:1 时监控延迟 <50ms。
迁移清单：
- 评估当前 Ingress 规则：使用 kubectl get ingress -o yaml，识别注解依赖。
- 安装 Gateway CRD：kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.0.0/standard-install.yaml。
- 转换资源：ingress2gateway convert -f ingress.yaml -o gateway.yaml；验证 HTTPRoute 路径匹配。
- 部署控制器：选择 Envoy Gateway 或 Kong，Helm install --set gatewayClass.name=envoy。
- 测试流量：使用 curl -H "Host: example.com" 测试拆分；回滚点：若错误率 >1%，切换回 ingress-nginx。
- 渐进 rollout：先 20% 流量到 Gateway，监控 24h 后全量切换。
- 清理：维护模式后，删除旧 Pod，释放资源。
通过这些步骤，团队可最小化风险，实现从 ingress-nginx 到 Gateway API 的平稳迁移。
资料来源
- Kubernetes 官方博客：https://kubernetes.dev/blog/2025/11/12/ingress-nginx-is-retiring/
- ingress-nginx GitHub：https://github.com/kubernetes/ingress-nginx
- Gateway API 文档：https://gateway-api.sigs.k8s.io/
- 社区基准测试：John Howard 的 Gateway API Benchmarks
（字数：1025）