1. Ingress-NGINX退役背景与迁移紧迫性2026年3月Kubernetes社区将正式退役Ingress-NGINX控制器这个自Kubernetes早期就存在的入口网关解决方案即将完成其历史使命。作为目前生产环境中使用最广泛的Ingress控制器这次退役影响范围涵盖从中小型企业到大型互联网公司的各类Kubernetes集群。重要提示虽然距离最终退役还有近两年时间但考虑到企业级环境的复杂性建议至少提前6个月完成迁移工作。历史经验表明最后一刻的迁移往往会导致配置遗漏和稳定性问题。这次变革的核心驱动力来自于Gateway API的成熟。作为第二代Kubernetes网络APIGateway API解决了Ingress API存在的多个根本性缺陷模块化设计将网关配置分解为GatewayClass、Gateway、HTTPRoute等资源实现关关分离角色分离明确区分基础设施管理员部署Gateway和应用开发者配置Route的职责边界跨实现兼容通过标准规范确保不同厂商的实现保持行为一致性扩展能力内置Filter机制替代各家自定义Annotation的混乱局面2. 迁移准备工作清单2.1 环境审计与资产盘点在开始迁移前需要全面审计现有Ingress-NGINX的配置和使用情况# 获取集群中所有Ingress资源及其使用的注解 kubectl get ingress -A -o jsonpath{range .items[*]}{.metadata.namespace}/{.metadata.name}: {.metadata.annotations}{\n}{end} # 统计各命名空间Ingress资源数量 kubectl get ingress -A --no-headers | awk {print $1} | sort | uniq -c需要特别关注的配置项包括自定义SSL证书和TLS配置流量控制相关注解限流、超时、重试路径重写规则CORS等安全相关配置特殊的路由匹配逻辑如正则表达式2.2 目标环境准备Gateway API需要以下基础设施支持Kubernetes版本v1.25推荐v1.28以获得完整功能Gateway控制器选择官方参考实现Gateway API Provider原BIG-IP ControllerEnvoy GatewayCNCF孵化项目Istio Gateway各云厂商的托管实现如AWS ALB Controller v2网络策略调整# 示例允许Gateway Pod与后端服务的通信 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-gateway-to-backend spec: podSelector: matchLabels: app.kubernetes.io/component: gateway policyTypes: - Egress egress: - to: - podSelector: matchLabels: app.kubernetes.io/component: backend ports: - protocol: TCP port: 80802.3 迁移工具链搭建官方推荐的迁移工具链包括ingress2gateway核心转换工具已发布v1.0稳定版# 安装最新版 brew install ingress2gateway # 或使用Go安装 go install github.com/kubernetes-sigs/ingress2gatewayv1.0.0gwctlGateway API专用调试工具kubectl krew install gwctl gwctl get gateways --all-namespaces监控指标转换需要将原有的Ingress-NGINX Prometheus指标映射到新控制器的监控体系3. 分阶段迁移实施指南3.1 第一阶段并行部署验证建议采用蓝绿部署策略保持原有Ingress-NGINX运行的同时部署Gateway APIgraph LR A[客户端] --|现有流量| B[Ingress-NGINX] A --|测试流量| C[Gateway API] B -- D[后端服务] C -- D具体操作步骤使用ingress2gateway转换现有配置ingress2gateway print --namespace production \ --providers ingress-nginx \ --emitter envoy-gateway gateway-api.yaml应用转换后的配置kubectl apply -f gateway-api.yaml通过DNS权重或负载均衡器规则分流测试流量以AWS为例resource aws_route53_record test { zone_id var.zone_id name example.com type A weighted_routing_policy { weight 10 # 10%流量到新网关 } alias { name aws_lb.gateway.dns_name zone_id aws_lb.gateway.zone_id evaluate_target_health true } }3.2 第二阶段配置深度转换常见配置转换示例案例1复杂路径重写原Ingress-NGINX配置annotations: nginx.ingress.kubernetes.io/rewrite-target: /$2 spec: rules: - http: paths: - path: /api(/|$)(.*)转换后的HTTPRouteapiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute spec: rules: - matches: - path: type: PathPrefix value: /api filters: - type: URLRewrite urlRewrite: path: type: ReplacePrefixMatch replacePrefixMatch: /案例2JWT验证原配置使用nginx-lua插件annotations: nginx.ingress.kubernetes.io/enable-global-auth: true nginx.ingress.kubernetes.io/auth-url: http://auth-service/validate转换方案使用Envoy Gateway的扩展过滤器apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: annotations: gateway.envoyproxy.io/filter-extension: jwt spec: rules: - filters: - type: ExtensionRef extensionRef: group: gateway.envoyproxy.io kind: JWT name: jwt-auth3.3 第三阶段流量切换与验证关键验证点功能验证使用自动化测试工具回放生产流量样本vegeta attack -duration5m -rate100 -targetsrequests.txt | vegeta report性能基准测试# 比较新旧网关的P99延迟 kubectl exec -it perf-test -- \ hey -z 1m -c 50 -q 100 \ -H Host: example.com \ http://gateway-api-service监控指标对比请求成功率连接建立时间后端响应时间分布5xx错误率4. 疑难问题解决方案4.1 不兼容配置处理常见不兼容场景及解决方案原配置类型问题描述解决方案configuration-snippet直接插入Nginx配置片段改用各实现的扩展CRDmutual TLS双向TLS认证使用ReferenceGrant绑定CA证书自定义错误页非标准错误响应实现ErrorFilter扩展4.2 灰度发布策略迁移原Canary注解的替代方案apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute spec: rules: - matches: - headers: - name: x-canary value: true backendRefs: - name: canary-service port: 80 weight: 10 - backendRefs: - name: main-service port: 80 weight: 904.3 监控告警调整需要更新的关键告警规则网关实例健康状态从nginx_up改为网关特定指标证书过期监控从nginx_ssl_expire_time改为gateway_cert_expiry请求速率限制告警重新基于gateway_requests_total配置5. 迁移后的优化建议完成基础迁移后可以考虑以下进阶优化启用细粒度流量管理apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute spec: rules: - matches: - path: type: PathPrefix value: /checkout timeouts: request: 5s backend: 4s retries: attempts: 3 conditions: - 5xx - gateway-error实现全链路加密apiVersion: gateway.networking.k8s.io/v1 kind: BackendTLSPolicy spec: targetRef: group: kind: Service name: checkout-service tls: caCertRefs: - name: internal-ca group: kind: ConfigMap hostname: checkout.internal采用策略附件模式apiVersion: gateway.networking.k8s.io/v1 kind: PolicyAttachment metadata: name: global-timeout spec: targetRef: group: gateway.networking.k8s.io kind: Gateway name: internet-facing defaults: timeouts: request: 10s迁移过程中积累的经验表明尽早开始规划、采用渐进式迁移策略、建立完善的验证体系是确保平稳过渡的关键。建议每周同步迁移进度每月进行阶段性回顾确保在2026年3月前顺利完成这一重要的架构升级。