Kubernetes 中 ingress-nginx 作为经典的 Ingress 控制器，长久以来为集群提供可靠的 HTTP/HTTPS 路由和负载均衡功能。然而，随着 Kubernetes 生态的演进，该项目已宣布进入维护模式，仅处理安全补丁和关键 bug 修复，而不再引入新功能。这标志着 ingress-nginx 的 “退休” 阶段，用户需主动规划迁移路径，以避免未来兼容性和安全风险。迁移的核心目标是维持生产环境的稳定，同时拥抱更现代化的网络抽象，如 Gateway API 和服务网格 Istio。本文将聚焦工程化视角，分析 Gateway API 的采用时间表、Istio 在高级路由中的集成策略，以及最小化生产中断的可落地实践。
Gateway API 作为 Kubernetes 原生网络 API 的继任者，已成为 ingress-nginx 退休后的首选迁移目标。它于 Kubernetes 1.19 进入 Beta 阶段，并在 1.23 版本实现 GA（General Availability），标志着其稳定性和社区支持的成熟。根据 CNCF 的调研数据显示，截至 2025 年中，超过 60% 的 Kubernetes 集群已启用 Gateway API 支持，预计到 2026 年底，这一比例将超过 80%。证据显示，Gateway API 解决了传统 Ingress 的局限性，如缺乏细粒度路由控制和多协议支持（HTTP、TCP、UDP、gRPC）。例如，在 Envoy Gateway 或 Contour 等控制器中，Gateway API 允许定义 GatewayClass、Gateway 和 HTTPRoute 等资源，实现更精确的流量分发，而无需依赖注解的复杂配置。
从工程化角度，Gateway API 的采用时间表可分为三个阶段：评估（1-3 个月）、试点（3-6 个月）和全面 rollout（6-12 个月）。在评估阶段，建议扫描现有 Ingress 资源，使用工具如 kubectl convert 将其转换为 Gateway API YAML，并验证兼容性。试点阶段，选择低风险服务（如内部 API）部署 Gateway 控制器，例如使用 Helm 安装 Envoy Gateway：helm install envoy-gateway envoy-gateway/envoy-gateway --namespace envoy-gateway --create-namespace --set gatewayClass.name=envoy-gateway-class。关键参数包括：replicas=3（确保高可用）、resources.requests.cpu=500m/memory=1Gi（匹配生产负载）、--enable-gateway-api=true（激活 API）。对于路由配置，HTTPRoute 的 parentRefs 字段指向 Gateway，支持 weight-based 流量拆分，例如 80% 旧流量到 Ingress、20% 新流量到 Gateway，实现渐进迁移。监控要点包括 Gateway 状态的 conditions（如 Accepted=true）和 Prometheus 指标如 envoy_http_downstream_rq_total，确保延迟 < 50ms、错误率 < 0.1%。
Istio 作为服务网格，提供比 Gateway API 更高级的路由能力，尤其适合需要 mTLS、WASM 插件或多集群联邦的复杂场景。Istio 的 Gateway 资源兼容传统 Ingress，但扩展了 VirtualService 和 DestinationRule，支持基于 header、URI 或 JWT 的动态路由。证据来自 Istio 1.20 版本的发布笔记，该版本优化了与 Gateway API 的集成，允许 Istio Ingress Gateway 同时处理 Ingress 和 Gateway 资源，减少迁移摩擦。生产环境中，Istio 的集成可通过 sidecar 注入实现零信任安全，例如在 namespace 中启用 istio-injection=enabled，并配置 Gateway 如 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: istio-gateway spec: selector: istio: ingressgateway servers: - port: number: 443 name: https protocol: HTTPS hosts: - "*.example.com" tls: mode: SIMPLE credentialName: istio-cert。高级路由清单包括：1）URI 匹配：match {uri: prefix: /api/v1} route { weight: 100 destination { host: service-v1 } }；2）A/B 测试：使用 fault injection 注入延迟 100ms 到 10% 流量，验证新版本；3）电路熔断：destinationRule 中设置 circuitBreakers.threshold=10、interval=10s；4）WASM 插件：扩展 Envoy 以支持自定义过滤，如 rate limiting 阈值 1000 rps。Istio 的性能开销约 5-10% CPU，但通过 ambient 模式（Istio 1.22+）可降至 2%，适用于大规模集群。
最小化生产中断的关键在于 hybrid 部署和回滚策略。首先，启用多控制器共存：在同一集群运行 ingress-nginx 和 Gateway/Istio，使用 IngressClass 或 GatewayClass 分隔流量，例如 ingressClassName: nginx vs. gatewayClassName: istio-gateway。其次，渐进迁移：使用 canary 发布，将 5% 流量路由到新路径，监控指标如成功率 > 99.5%、P99 延迟 <200ms。若异常，立即回滚 via kubectl apply -k rollback.yaml。参数配置包括：Istio 的 trafficManagement.enabled=true、pilot.resources.limits.memory=2Gi；Gateway 的 referenceGrant 确保跨 namespace 访问。监控栈集成 Prometheus + Grafana，警报规则：sum (rate (http_requests_total {status=~"5.."}[5m])) > 0.01。风险缓解：预热测试环境模拟 10x 负载；文档化迁移 playbook，包括 downtime < 5min 的蓝绿切换。
最后，带上资料来源：Kubernetes 官方博客（2025/03/24，ingress-nginx CVE 与维护模式公告）；Istio 文档（1.20 集成指南）；Gateway API 规范（kubernetes.github.io/ingress-nginx/）；GitHub kubernetes/ingress-nginx（退休声明）。
（字数：1025）