亚马逊AWS官方博客

告别 Ingress-NGINX：用 Amazon Load Balancer Controller Gateway API 实现更强大的流量管理

一、背景

Kubernetes 官方宣布 Ingress-NGINX 将于 2026 年 3 月退役，这标志着 Kubernetes 网络管理进入新阶段。本文深入探讨从 Ingress-NGINX 迁移到 Amazon Load Balancer Controller Gateway API 的完整方案，涵盖两者的架构差异、功能对比、五大典型场景的配置示例（基础转发、URL 重写、金丝雀发布、HTTPS 证书管理、基于 Host 的路由），以及基于 ingress2gateway 工具的七步迁移路径。通过 DNS 加权路由实现零停机迁移，帮助 EKS 用户平滑过渡到下一代网络标准。

1.1 前置要求

在开始迁移之前，请确保：

  • EKS 集群版本 ≥ 1.24
  • 已安装 kubectl 并配置好集群访问
  • 具有集群管理员权限
  • 备份现有配置
  • 准备好测试环境

1.2 Ingress Controller 和 Ingress 的关系

Ingress 是 Kubernetes 上的一个资源对象，用来管理集群外部访问集群内部服务的方式。通过 Ingress 资源来配置不同的转发规则，从而实现根据不同的规则设置，访问集群内不同的 Service 所对应的后端 Pod。

Ingress Controller 通常是 Kubernetes 上的一个 deployment 或者 daemonset 工作负载，接收来自集群外部的请求，并根据 Ingress 对应的转发规则将请求转发到后端 Pod。如果 Ingress 有增删改的变动，Ingress Controller 会及时更新转发行为。

常见的 Ingress Controller 包括 Ingress-NGINX、Traefik、HAProxy 或者云厂商提供的负载均衡器（如 Amazon Load Balancer Controller）等。

1.3 Ingress-NGINX 即将退役

Kubernetes 网络和安全响应委员会官方宣布：Ingress-NGINX 项目将退役，维护期将持续至 2026 年 3 月。2026 年 3 月后，该项目将不再有进一步的发布、缺陷修复或安全更新。详细公告，请参见 Ingress NGINX 退役：你需要了解的内容。

然而 Ingress-NGINX 作为一个 Ingress Controller，它的退役并不代表 Ingress 的废弃，Ingress API 是已经进入 GA 的稳定 API，Kubernetes 社区并不会将其移除。

1.4 迁移方案选择

对于仍在 Amazon EKS 集群内使用 Ingress-NGINX 组件的用户，有两种方案可供选择：

1、迁移到 Amazon Load Balancer Controller，继续使用 Ingress

    • 只需替换 annotation
    • 迁移难度较低
    • 适合短期快速迁移

2、转向使用 Gateway API（推荐）

    • 迁移难度相对高一些
    • 更贴合未来技术发展方向
    • 本文重点介绍此方案

二、Gateway API

2.1 Gateway API 概述

Ingress API 于 2015 年进入 Kubernetes，最初的设计目标只是为 HTTP 提供一个基础的”反向代理”抽象，但是随着微服务和多租户架构的发展，其局限性日益突出。

Ingress API 的局限性

  • 供应商锁定: 每个 Ingress Controller 都有自己的一套 annotation，通过这样的方式自定义配置，因此很难从一个 Ingress Controller 迁移到另一个。
  • 责任边界模糊: 到底谁才是 Ingress 资源的所有者？是负责设置负载均衡器和 TLS 的 Infra 团队，还是定义路由路径的 App 团队？这种权责不清导致 Ingress 资源的管理混乱。
  • 表现力有限: 像流量拆分、基于 Header 的路由，甚至是简单的重定向等核心需求，都需要非标准的 Workaround 来实现。
  • 仅支持 L7 协议: Ingress 仅适用于第 7 层协议，如 HTTP 和 HTTPS。非 L7 功能均由 Ingress Controller 自行实现。

因此 Ingress API 已被 Kubernetes 社区封冻，后续不再推出新的功能，Kubernetes 社区把精力转移到了新的 Gateway API。Gateway API 能提供更标准化、功能丰富且具未来适应性的 Kubernetes 网络流量配置方法。

Gateway API 核心组件

Gateway API 由四个主要部分组成：

  • GatewayClass: 可以把它看作是设置 Gateway 的模板或蓝图。它定义了一组具有相同配置的 Gateway，这些 Gateway 由一个与该 GatewayClass 关联的 Gateway Controller 管理
  • Gateway: 作为集群的入口实际处理流量的地方，比如一个 Cloud Load Balancer，根据你的配置将进入的流量转发到合适的目标
  • HTTPRoute: 用于定义 HTTP 流量的路由规则。它描述了如何将来自 Gateway 的流量映射到后端 Pod，可以基于 URL 路径、Header 或主机名等条件进行匹配和转发
  • GRPCRoute: 用于定义 gRPC 流量的路由规则，将来自 Gateway 的流量映射到后端 Pod

这些组件共同提供了一种结构化且灵活的方式，用于在 Kubernetes 环境中管理流量和路由。

2.2 Amazon Load Balancer Controller（LBC）Gateway API

Amazon Load Balancer Controller 除了作为一个 Ingress Controller 的实现，支持 Ingress API 之外，也开始支持 Gateway API。目前 LBC 通过 Amazon NLB 支持四层路由 (TCPRoute, UDPRoute, TLSRoute)，通过 Amazon ALB 支持七层路由 (HTTPRoute, GRPCRoute)。

关于 Amazon Gateway API Controller

此外，Amazon 还有一个 Amazon Gateway API Controller，也是一个 Kubernetes Gateway API 的实现。但是 Amazon Gateway API Controller 更侧重于通过 VPC Lattice 支持东西向的流量。参考其限制。

2.3 功能对比

Ingress vs Gateway API 功能对比

功能 Ingress Gateway API 优势
角色分离 不支持 支持 运维和开发职责清晰
流量拆分 需要annotation 原生支持 标准化配置
多协议支持 仅HTTP/HTTPS HTTP/HTTPS/gRPC/TCP/UDP 更灵活
URL重写 需要annotation 原生支持 标准化配置
供应商锁定 高 低 易于迁移
金丝雀发布 需要多个Ingress 单个HTTPRoute 配置更简洁
Header路由 需要annotation 原生支持 标准化配置
跨命名空间路由 不支持 支持 更强大的路由能力

三、Ingress-NGINX 与 Amazon LBC Gateway API 的配置对比

接下来我们会列举常见的几种场景下，基于 Ingress-NGINX 的配置和基于 Amazon LBC 的 Gateway API 配置差异：

  • 场景1：基础转发
  • 场景2：URL重写
  • 场景3：金丝雀发布/流量拆分
  • 场景4：HTTPS证书管理
  • 场景5：基于Host的路由

准备工作

首先，针对 Ingress-NGINX 和 Amazon LBC Gateway API，分别创建 IngressClass 和 GatewayClass。

Ingress-NGINX:

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: nginx
spec:
  controller: k8s.io/ingress-nginx
Amazon LBC Gateway API:
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: aws-alb-gateway-class
spec:
  controllerName: gateway.k8s.aws/alb

3.1 场景 1：基础转发

分别使用 Ingress 和 Gateway API 的方式转发到 dep-nginx service 的 80 端口。其中 demo-route 通过 demo-gateway.status.addresses 内自动生成的 Hostname 可直接访问。

Ingress 的原有功能被拆分到了 HTTPRoute 和 Gateway 两个资源。这样设计最重要的目的是实现角色解耦，运维人员负责定义 Gateway，他们关心的是 TLS 存放在哪儿、开放什么端口、哪些路由可以被挂载到网关等等。而开发人员负责定义 HTTPRoute，他们关心的是请求路径、要转发给哪个 Service 等等。

Ingress 方式:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-ingress
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - backend:
          service:
            name: dep-nginx
            port:
              number: 80
        path: /
        pathType: Prefix

Gateway API 方式:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: demo-gateway
spec:
  gatewayClassName: aws-alb-gateway-class
  listeners:
  - allowedRoutes:
      namespaces:
        from: Same
    name: http
    port: 80
    protocol: HTTP

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

3.2 场景 2：URL 重写

URL 重写分为基于路径的重写和基于主机名重写两部分。针对基于路径的重写配置对比如下，其中 demo-route 通过 demo-gateway.status.addresses 内自动生成的 Hostname 加上 path 前缀 “/app” 可直接访问。Ingress 带有很多 Ingress-NGINX 专有的 annotation，但是相同的功能，在 Gateway API 中已经作为标准的字段体现。

Ingress 方式:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    nginx.ingress.kubernetes.io/use-regex: "true"
  name: demo-ingress
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - backend:
          service:
            name: dep-nginx
            port:
              number: 80
        path: /app(/|$)(.*)
        pathType: ImplementationSpecific

Gateway API 方式:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: demo-gateway
spec:
  gatewayClassName: aws-alb-gateway-class
  listeners:
  - allowedRoutes:
      namespaces:
        from: Same
    name: http
    port: 80
    protocol: HTTP

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: demo-route
spec:
  parentRefs:
  - name: demo-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /app
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplacePrefixMatch
          replacePrefixMatch: /
    backendRefs:
    - name: dep-nginx
      port: 80

3.3 场景 3：金丝雀发布 / 流量拆分

实现金丝雀发布，如果是 Ingress 的方式，需要定义两个 Ingress 资源，并使用 Ingress-NGINX 专有的 annotation；而 Gateway API 在一个 HTTPRoute 资源就能定义出来，Gateway API 具有更强的表达能力。

Ingress 方式:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-main
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service-v1
            port:
              number: 80

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "20" # 相对于总流量的百分比
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service-v2
            port:
              number: 80

Gateway API 方式:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: demo-gateway
spec:
  gatewayClassName: aws-alb-gateway-class
  listeners:
  - allowedRoutes:
      namespaces:
        from: Same
    name: http
    port: 80
    protocol: HTTP

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: demo-canary
spec:
  parentRefs:
  - name: demo-gateway
  rules:
  - backendRefs:
    - name: my-app-service-v2
      port: 80
      weight: 20 # 20% 流量
    - name: my-app-service-v1
      port: 80
      weight: 80 # 80% 流量
    matches:
    - path:
        type: PathPrefix
        value: /

3.4 场景 4：HTTPS 证书管理

Ingress 的方式下，TLS 证书需要在 EKS 集群内创建为 secrets，然后让 Ingress 引用。并且 HTTP 到 HTTPS 重定向也需要使用 Ingress-NGINX 特有的 annotation 来支持。

Amazon LBC 支持 HTTPS 流量，以及 HTTP 到 HTTPS 的重定向。但是实现上和 Gateway API 的规范有一定差异，TLS 证书的管理是使用 Amazon LBC 专有的 LoadBalancerConfiguration 资源来做配置，然后再将其引用到 Gateway 资源对象中。

Ingress 方式:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-ingress
  annotations: 
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true" # 强制跳转 HTTPS
spec:
  tls:
  - secretName: example-com-tls # 事先将证书导入到 K8s secrets
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - backend:
          service:
            name: dep-nginx
            port:
              number: 80
        path: /
        pathType: Prefix

Gateway API 方式:

apiVersion: gateway.k8s.aws/v1beta1
kind: LoadBalancerConfiguration
metadata:
  name: demo-gateway-config
spec:
  listenerConfigurations:
  - defaultCertificate: arn:aws:acm:<REGION>:<ACCOUNT-ID>:certificate/<CERTIFICATE-ID> 
    protocol: HTTPS
port: 443

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: demo-gateway
spec:
  gatewayClassName: aws-alb-gateway-class
  infrastructure:
    parametersRef:
      group: gateway.k8s.aws
      kind: LoadBalancerConfiguration
      name: demo-gateway-config
  listeners:
  - allowedRoutes:
      namespaces:
        from: Same
    name: https
    port: 443
    protocol: HTTPS
  - allowedRoutes:
      namespaces:
        from: Same
    name: http
    port: 80
    protocol: HTTP

# HTTP 到 HTTPS 重定向
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: demo-route-redirect
spec:
  parentRefs:
  - name: demo-gateway
    sectionName: http
  rules:
  - filters:
    - type: RequestRedirect
      requestRedirect:
        scheme: https      # 强制跳转到 https
        port: 443          # 显式指定端口
        statusCode: 301    # 使用 301 永久重定向

# HTTPS 流量路由
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: demo-route-tls
spec:
  parentRefs:
  - name: demo-gateway
    sectionName: https
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: dep-nginx
      port: 80

3.5 场景 5：基于 Host 的路由

根据不同的域名将流量路由到不同的后端服务，常用于多租户或多应用场景。

Ingress 通过 rules 下的 host 字段实现多域名路由，每个域名需要在同一个 Ingress 中配置；而 Gateway API 可以为每个域名创建独立的 HTTPRoute，通过 hostnames 字段指定域名，职责更加清晰，也支持通配符域名。

Ingress 方式：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: app1.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app1-service
            port:
              number: 80
  - host: app2.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app2-service
            port:
              number: 80

Gateway API 方式:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: demo-gateway
spec:
  gatewayClassName: aws-alb-gateway-class
  listeners:
  - allowedRoutes:
      namespaces:
        from: Same
    name: http
    port: 80
    protocol: HTTP

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app1-route
spec:
  parentRefs:
  - name: demo-gateway
  hostnames:
  - app1.example.com
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: app1-service
      port: 80

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app2-route
spec:
  parentRefs:
  - name: demo-gateway
  hostnames:
  - app2.example.com
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: app2-service
      port: 80

四、Ingress-NGINX 到 Amazon LBC 的迁移路径

为了实现零停机迁移，在完成迁移之前，都不要删除 Ingress 资源也不要卸载 Ingress-NGINX controller。

4.1 迁移步骤

步骤 1：安装 Amazon Load Balancer Controller

参考 Installation Guide – Amazon Load Balancer Controller，安装完成后启用 Gateway API 功能：

kubectl patch deployment aws-load-balancer-controller \
  -n kube-system \
  --type='json' \
  -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--feature-gates=NLBGatewayAPI=true,ALBGatewayAPI=true"}]'

验证安装：

# 检查 controller 状态
kubectl get deployment -n kube-system aws-load-balancer-controller

# 检查 CRD 是否安装
kubectl get crd | grep gateway
步骤 2 ：利用 ingress2gateway 工具批量转换

Kubernetes 开源社区发布了一个 ingress2gateway 的工具，这个工具可以将 Kubernetes 集群中的 Ingress 批量转换到 Gateway API 资源。

安装工具：

# 使用 Go 安装
go install github.com/kubernetes-sigs/ingress2gateway@latest

# 或下载二进制文件
wget https://github.com/kubernetes-sigs/ingress2gateway/releases/latest/download/ingress2gateway-linux-amd64
chmod +x ingress2gateway-linux-amd64
mv ingress2gateway-linux-amd64 /usr/local/bin/ingress2gateway

运行转换：

# 转换单个 Ingress
ingress2gateway print --providers=ingress-nginx --input-file=ingress.yaml > gateway-api.yaml

# 转换集群中所有 Ingress
ingress2gateway print --providers=ingress-nginx --all-namespaces > gateway-api-all.yaml

# 转换特定命名空间
ingress2gateway print --providers=ingress-nginx --namespace=production > gateway-api-prod.yaml

运行效果示例：
步骤 3 ：根据 Amazon LBC 文档进一步调整

但是 Ingress-NGINX 在 Ingress 资源上还有大量的专有 annotation，可参考Ingress-NGINX Annotations。

Ingress-NGINX 的 annotation 的功能，包括 TLS 证书管理、金丝雀发布、Rewrite、重定向等，需使用以下 Amazon LBC Gateway API 特有的 CRD 进行平替：

  • LoadBalancerConfiguration: 负载均衡器级别配置（TLS 证书、监听器等）
  • TargetGroupConfiguration: 目标组配置（健康检查、会话保持等）
  • ListenerRuleConfiguration: 监听器规则配置（高级路由规则）

ingress2gateway 工具并不支持生成 Amazon LBC 特有的资源，因此用户需根据 Amazon LBC Gateway API 文档，在 ingress2gateway 工具生成的 YAML 文件上做进一步的适配修改。

常见 annotation 映射：

Ingress-NGINX Annotation Gateway API
nginx.ingress.kubernetes.io/rewrite-target HTTPRoute.filters.urlRewrite
nginx.ingress.kubernetes.io/canary HTTPRoute.backendRefs.weight
nginx.ingress.kubernetes.io/ssl-redirect HTTPRoute.filters.requestRedirect
nginx.ingress.kubernetes.io/backend-protocol TargetGroupConfiguration
nginx.ingress.kubernetes.io/healthcheck-* TargetGroupConfiguration
步骤 4 ：部署转换好的 Gateway API 资源

完成适配修改之后，将修改好的 Gateway API 资源，以及 Amazon LBC 特有的资源，全部部署到 EKS 集群中。

# 部署 Gateway API 资源
kubectl apply -f gateway-api.yaml

# 验证部署
kubectl get gateway,httproute -A

# 获取 Gateway 地址
kubectl get gateway demo-gateway -o jsonpath='{.status.addresses[0].value}'

然后使用 Gateway.status.addresses 内自动生成的地址进行测试：

# 获取 ALB 地址
ALB_ADDRESS=$(kubectl get gateway demo-gateway -o jsonpath='{.status.addresses[0].value}')

# 测试访问
curl http://$ALB_ADDRESS/
curl -I http://$ALB_ADDRESS/app
步骤 5 ： DNS 加权路由

如果您使用了如 Amazon Route53 这类支持加权路由策略的 DNS 服务，可以逐步将流量从 Ingress-NGINX 导向 Amazon LBC。

# 获取 Ingress-NGINX 和 Gateway 的地址
NGINX_LB=$(kubectl get svc -n ingress-nginx ingress-nginx-controller -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
ALB_ADDRESS=$(kubectl get gateway demo-gateway -o jsonpath='{.status.addresses[0].value}')

# 在 Route53 中创建加权路由记录
# 初始: NGINX 100%, ALB 0%
# 逐步调整: NGINX 80%, ALB 20% → 50%/50% → 20%/80% → 0%/100%
步骤 6 ：监控和观察

在流量切换过程中，密切监控以下指标：

# 监控 ALB 响应时间变化
aws cloudwatch get-metric-statistics \
  --namespace AWS/ApplicationELB \
  --metric-name TargetResponseTime \
  --dimensions Name=LoadBalancer,Value=<your-alb-arn-suffix> \
  --start-time $(date -u -v-1H '+%Y-%m-%dT%H:%M:%S') \
  --end-time $(date -u '+%Y-%m-%dT%H:%M:%S') \
  --period 300 \
  --statistics Average \
  --output table

# 监控 ALB 5XX 错误总数

aws cloudwatch get-metric-statistics \
 --namespace AWS/ApplicationELB \
 --metric-name HTTPCode_ELB_5XX_Count \
 --dimensions Name=LoadBalancer,Value=<your-alb-arn-suffix> \
 --start-time $(date -u -v-1H +%Y-%m-%dT%H:%M:%S) \
 --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
 --period 300 \
 --statistics Sum

# 查看 ALB 访问日志（需要先启用）

aws s3 ls s3://your-alb-logs-bucket/ --recursive | tail -20
步骤 7 ：删除旧的 Ingress 资源并卸载 Ingress-NGINX

流量全部切换到 Amazon LBC 之后，即可删除旧的 Ingress 资源并卸载 Ingress-NGINX controller。

# 删除 Ingress 资源
kubectl delete ingress --all -A

# 卸载 Ingress-NGINX
helm uninstall ingress-nginx -n ingress-nginx

# 删除命名空间
kubectl delete namespace ingress-nginx

至此，整个迁移工作全部完成。

4.2 注意事项和最佳实践

重要注意事项

  • 不要急于删除旧资源 – 保留 Ingress-NGINX 至少 1-2 周，确保所有流量已切换且监控无异常后再删除。
  • 备份配置 – 在迁移前务必备份所有 Ingress 配置和 Ingress-NGINX 的 ConfigMap，以便在需要时快速回滚。
  • 监控告警 – 设置 ALB 的 CloudWatch 告警，重点监控 5xx 错误率、响应时间变化和目标健康状态。
  • 回滚计划 – 准备好快速回滚到 Ingress-NGINX 的步骤，保留 DNS 记录的 TTL 较短（如 60 秒），并文档化回滚流程。

最佳实践

  • 使用 GitOps 管理 – 使用 ArgoCD 或 Flux 等 GitOps 工具管理 Gateway API 资源，实现配置的版本控制和自动化部署。
  • 分阶段迁移 – 建议分三个阶段进行：第一阶段迁移非生产环境（开发、测试），第二阶段迁移生产环境的非关键服务，第三阶段迁移生产环境的关键服务。每个阶段观察 1-2 周，确保稳定后再进入下一阶段。
  • 命名规范 – 使用清晰的命名规范，如 Gateway 使用”环境-可见性-用途”格式（prod-public-gateway），HTTPRoute 使用”应用名-功能-route”格式（myapp-api-route），并添加合适的标签。
  • 命名空间隔离 – 将 Gateway 放在基础设施命名空间（如 infrastructure），HTTPRoute 放在各自的应用命名空间，实现职责分离和资源隔离。
  • 启用访问日志 – 在 LoadBalancerConfiguration 中启用 ALB 访问日志，将日志存储到 S3，便于后续的问题排查和审计。

4.3 常见问题 FAQ

Q1: 迁移过程中会有停机时间吗？

A: 按照本文的迁移路径，使用 DNS 加权路由可以实现零停机迁移。关键是在流量完全切换之前不要删除旧资源。在迁移期间，Gateway API 和 Ingress 可以同时运行，它们使用不同的负载均衡器，互不影响。

Q2: 迁移后性能和成本会有什么变化？

A: Amazon ALB 的性能通常优于 Ingress-NGINX，且无需管理 Pod 资源。成本方面需要具体分析：Ingress-NGINX 需要 EC2 实例成本（需要足够资源运行 NGINX Pod），而 Amazon ALB 是 ALB 固定费用加 LCU 费用。对于中小规模应用，ALB 可能更经济；对于大规模应用，需要详细计算。建议在测试环境进行压测对比。

Q3: 所有 Ingress-NGINX 功能都能迁移吗？

A: 大部分功能都有对应实现。基础路由、URL 重写、重定向、TLS 终止、金丝雀发布都可以直接迁移。但自定义 NGINX 配置需要重新实现，Lua 脚本需要改用其他方案。

跨命名空间路由：Gateway API 原生支持跨命名空间路由，这是相比 Ingress 的重要优势。在 Gateway 的 listeners 配置中，将 allowedRoutes.namespaces.from 设置为 “All” 即可允许所有命名空间的 HTTPRoute 挂载到该 Gateway。这对于共享网关、多租户场景非常有用。

健康检查配置：Amazon LBC 的健康检查配置与 Ingress-NGINX 有较大差异。在 Gateway API 中，需要使用 Amazon LBC 专有的 TargetGroupConfiguration CRD 来配置健康检查参数（如检查路径、间隔、超时、健康/不健康阈值等）。这些配置通过 TargetGroupConfiguration 资源定义后，可以被 HTTPRoute 引用，实现更精细的健康检查控制。

Q4: 迁移失败如何回滚？

A: 回滚步骤包括：调整 DNS 权重将流量切回 Ingress-NGINX，等待 DNS TTL 过期，删除 Gateway API 资源，验证 Ingress-NGINX 正常工作。这也是为什么建议保留 DNS 记录的 TTL 较短（如 60 秒），并在迁移前准备好详细的回滚文档。

Q5: 如何监控 Gateway 的健康状态？

A: 可以使用 kubectl describe 命令查看 Gateway 和 HTTPRoute 的状态，使用 Amazon CLI 查看 ALB 目标组的健康检查状态，以及通过 CloudWatch 监控 ALB 的各项指标（如 5xx 错误率、响应时间、目标健康状态等）。建议设置 CloudWatch 告警，在出现异常时及时通知。

五、总结

Ingress-NGINX 的退役标志着 Kubernetes 网络管理进入新阶段。Gateway API 作为下一代标准，提供了：

  • 更好的角色分离 – 运维和开发职责清晰
  • 更强的表达能力 – 原生支持流量拆分、重写等功能
  • 更低的供应商锁定 – 标准化的 API，易于迁移
  • 更广的协议支持 – 不仅限于 HTTP/HTTPS

对于 Amazon EKS 用户，Amazon Load Balancer Controller 提供了成熟的 Gateway API 实现，结合 Amazon ALB/NLB 的强大功能和原生集成优势，不仅能够无缝替代 Ingress-NGINX，更能充分发挥云原生架构的弹性和可观测性，是企业级生产环境的理想选择。

参考资源

本篇作者

张铭

10年+ 开发和设计经验，在边缘计算、大规模集群性能优化等领域有丰富的实战经验，擅长系统架构、云原生技术。

戴涛

13年+ IT专业服务经验，云计算项目经验丰富，擅长系统架构、容器/云原生领域。

AWS 架构师中心：云端创新的引领者

探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用