1. Ingress-NGINX退役背景与迁移紧迫性
2026年3月,Kubernetes社区将正式退役Ingress-NGINX控制器,这个自Kubernetes早期就存在的入口网关解决方案即将完成其历史使命。作为目前生产环境中使用最广泛的Ingress控制器,这次退役影响范围涵盖从中小型企业到大型互联网公司的各类Kubernetes集群。
重要提示:虽然距离最终退役还有近两年时间,但考虑到企业级环境的复杂性,建议至少提前6个月完成迁移工作。历史经验表明,最后一刻的迁移往往会导致配置遗漏和稳定性问题。
这次变革的核心驱动力来自于Gateway API的成熟。作为第二代Kubernetes网络API,Gateway 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 Controller)
- Envoy Gateway(CNCF孵化项目)
- 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: 8080
2.3 迁移工具链搭建
官方推荐的迁移工具链包括:
ingress2gateway:核心转换工具(已发布v1.0稳定版)
# 安装最新版 brew install ingress2gateway # 或使用Go安装 go install github.com/kubernetes-sigs/ingress2gateway@v1.0.0gwctl:Gateway API专用调试工具
kubectl krew install gwctl gwctl get gateways --all-namespaces监控指标转换:需要将原有的Ingress-NGINX Prometheus指标映射到新控制器的监控体系
3. 分阶段迁移实施指南
3.1 第一阶段:并行部署验证
建议采用蓝绿部署策略,保持原有Ingress-NGINX运行的同时部署Gateway API:
graph 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(/|$)(.*)转换后的HTTPRoute:
apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute spec: rules: - matches: - path: type: PathPrefix value: /api filters: - type: URLRewrite urlRewrite: path: type: ReplacePrefixMatch replacePrefixMatch: /案例2:JWT验证
原配置(使用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 -duration=5m -rate=100 -targets=requests.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配置片段 | 改用各实现的扩展CRD |
| mutual 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月前顺利完成这一重要的架构升级。