跳到主要内容

Gateway API 采用指南

📌 参考版本: Gateway API v1.4.0, Cilium v1.19.0, EKS 1.32, AWS LBC v3.0.0, Envoy Gateway v1.7.0

📅 撰写日期: 2025-02-12 | ⏱️ 阅读时间: 约 25 分钟

1. 概述​

随着 NGINX Ingress Controller 官方生命周期终止（EOL）时间定于 2026 年 3 月，向 Kubernetes Gateway API 过渡已经从可选变为必须。本指南涵盖从理解 Gateway API 架构到比较 5 大主流实现方案（AWS LBC v3、Cilium、NGINX Gateway Fabric、Envoy Gateway、kGateway）、深入 Cilium ENI 模式配置、分步迁移执行策略以及性能基准测试规划的全部内容。

1.1 目标读者​

  • 运维 NGINX Ingress Controller 的 EKS 集群管理员：制定 EOL 应对策略
  • 规划 Gateway API 迁移的平台工程师：技术选型与 PoC 执行
  • 评估流量管理架构现代化的架构师：长期路线图设计
  • 考虑 Cilium ENI 模式与 Gateway API 集成的网络工程师：基于 eBPF 的高性能网络

1.2 文档结构​

📚 Document Structure
Required
1. Overview — Structure, audience2. NGINX Retirement — EOL timeline, security3. Gateway API Architecture — 3-Tier model, roles4. Implementation Comparison — AWS Native vs Open Source, NGINX mappings, code6. Conclusion — Recommendations, roadmap
Situational
5. Benchmark Planning — Test design
阅读策略
  • 快速了解：第 1-3、6 节（约 10 分钟）
  • 技术选型：第 1-4、6 节（约 20 分钟）
  • 完整迁移：全文阅读（约 25 分钟）

2. NGINX Ingress Controller 退役 — 为何迁移势在必行​

2.1 EOL 时间线​

关键事件详情：

  • 2025 年 3 月：IngressNightmare（CVE-2025-1974）被发现 — 通过 Snippets 注解实现的任意 NGINX 配置注入漏洞加速了 Kubernetes SIG Network 对退役的讨论
  • 2025 年 11 月：Kubernetes SIG Network 正式宣布 NGINX Ingress Controller 退役。引用维护者资源不足（仅 1-2 名核心维护者）以及 Gateway API 成熟度作为主要原因
  • 2026 年 3 月：官方 EOL — 安全补丁和漏洞修复完全停止。在生产环境中继续使用可能导致合规违规
必要行动

**2026 年 3 月之后，NGINX Ingress Controller 将不再接收安全漏洞补丁。**为了维持 PCI-DSS、SOC 2 和 ISO 27001 等安全认证，您必须过渡到基于 Gateway API 的解决方案。

2.2 安全漏洞分析​

IngressNightmare (CVE-2025-1974) 攻击场景：

IngressNightmare 攻击概述

针对 Kubernetes 集群中 Ingress NGINX Controller 的未授权远程代码执行（RCE）攻击向量。外部和内部攻击者均可通过恶意 Admission Review 攻陷控制器 Pod，从而获取集群中所有 Pod 的访问权限。（来源：Wiz Research）

风险评估：

⚠️ NGINX Ingress Security Risk Assessment
Known vulnerabilities and impact scope
Arbitrary config injection via Snippets annotations
CriticalCVSS: 9.8
Impact Scope:Full Ingress traffic hijacking
Invalid config propagation due to no schema validation
HighCVSS: 7.5
Impact Scope:Service disruption, security policy bypass
RBAC privilege escalation (namespace isolation bypass)
CriticalCVSS: 9.1
Impact Scope:Cross-namespace privilege theft
End of patches after EOL
CriticalCVSS: N/A
Impact Scope:No zero-day vulnerability response
当前运维中的注意事项

对于现有的 NGINX Ingress 环境，我们建议立即应用 admission controller 策略，禁止使用 nginx.ingress.kubernetes.io/configuration-snippet 和 nginx.ingress.kubernetes.io/server-snippet 注解。

2.3 通过采用 Gateway API 从根本上解决漏洞​

Gateway API 从根本上解决了 NGINX Ingress 的结构性安全漏洞。

🔄 NGINX Ingress vs Gateway API Comparison
Architecture and configuration differences
Resource Structure
NGINX IngressAll settings in a single Ingress resource
Gateway APISeparation of concerns with 3 resources (GatewayClass, Gateway, HTTPRoute)
Configuration
NGINX IngressNon-standard annotations (50+)
Gateway APIStandard CRD fields
Permission Management
NGINX IngressAll settings controllable with namespace-level Ingress permission
Gateway APIPer-resource RBAC separation (Infra/Platform/App teams)
Controller Replacement
NGINX IngressFull Ingress rewrite required
Gateway APIOnly change GatewayClass
Extensibility
NGINX IngressSnippet injection or custom controllers
Gateway APIPolicy Attachment pattern

1. 配置片段注入攻击

NGINX Ingress 允许通过注解注入任意字符串，造成严重安全风险：

# ❌ NGINX Ingress — 可注入任意字符串
annotations:
  nginx.ingress.kubernetes.io/configuration-snippet: |
    # 可窃取相邻服务凭据 (CVE-2021-25742)
    proxy_set_header Authorization "stolen-token";

2. 所有权限集中在单一资源中

  • 路由、TLS、安全和扩展设置全部混合在一个 Ingress 资源中
  • 无法按注解进行 RBAC 分离 — 要么拥有完整 Ingress 权限，要么没有
  • 只需要路由访问权限的开发者也获得了 TLS/安全修改权限

3. 供应商注解依赖

  • 非标准功能通过供应商特定注解添加 → 可移植性丧失
  • 注解冲突调试困难
  • 管理 100+ 供应商注解的复杂度不断增长

这些结构性问题使 NGINX Ingress 无法满足生产环境的安全要求。

活跃的社区支持
  • 15+ 生产级实现：AWS、Google Cloud、Cilium、Envoy、NGINX、Istio 等
  • 定期季度发布：截至 v1.4.0 包含 GA 资源
  • 官方 CNCF 项目：由 Kubernetes SIG Network 主导

3. Gateway API — 下一代流量管理标准​

3.1 Gateway API 架构​

Gateway API 角色模型 — 来源: gateway-api.sigs.k8s.io

来源：Kubernetes Gateway API 官方文档 — 三种角色（基础设施提供者、集群运维人员、应用开发者）分别管理 GatewayClass、Gateway 和 HTTPRoute

详细对比

关于 NGINX Ingress 和 Gateway API 的详细架构对比，请参阅 2.3 通过采用 Gateway API 从根本上解决漏洞，包含分标签页的详细分析。

3.2 三层资源模型​

Gateway API 通过以下层次结构分离职责：

Gateway API 资源模型 — 来源: gateway-api.sigs.k8s.io

来源：Kubernetes Gateway API 官方文档 — GatewayClass → Gateway → xRoute → Service 层次结构

👥 Role-Based Responsibility Separation
Resource managers and change frequency
GatewayClass⏱ 1-2 per quarter
Manager:Infrastructure Team (SRE, Cluster Admin)
Responsibility:Controller selection, global policies, cost optimization
Gateway⏱ 1-2 per month
Manager:Platform Team (Network Engineers)
Responsibility:Listener config, TLS certificates, load balancer settings
HTTPRoute⏱ Daily
Manager:Application Team (Developers)
Responsibility:Per-service routing, Canary deployment, A/B testing
Service⏱ Per deployment
Manager:Application Team (Developers)
Responsibility:Backend endpoint management

3.3 GA 状态 (v1.4.0)​

Gateway API 分为 Standard Channel 和 Experimental Channel，各资源的成熟度级别不同：

✅ Gateway API GA Status
Resource stability and production recommendation
GatewayClassStandard
GA (v1)✅
Controller definition, parameter reference
GatewayStandard
GA (v1)✅
Listeners, TLS, load balancer settings
HTTPRouteStandard
GA (v1)✅
HTTP routing, header/query matching
GRPCRouteStandard
GA (v1)✅
gRPC service mesh matching
ReferenceGrantStandard
GA (v1beta1)✅
Cross-namespace reference security
BackendTLSPolicyStandard
Beta (v1alpha3)⚠️
Backend TLS termination (mTLS)
TLSRouteExperimental
Alpha (v1alpha2)❌
TLS Passthrough (SNI routing)
TCPRouteExperimental
Alpha (v1alpha2)❌
L4 TCP routing
UDPRouteExperimental
Alpha (v1alpha2)❌
L4 UDP routing (DNS, VoIP)
Experimental Channel 注意事项

Alpha 状态的资源不保证 API 兼容性，在次版本升级时可能发生字段变更或删除。对于生产环境，我们建议仅使用 Standard channel 中的 GA/Beta 资源。

3.4 核心优势​

通过可视化图表和 YAML 示例探索 Gateway API 的 6 大核心优势。

✕
🚫
기존 Ingress
단일 권한 모델
🏢 인프라 팀 → GatewayClass🔒
RBAC 격리
🔧 플랫폼 팀 → Gateway🔒
RBAC 격리
💻 앱 팀 → HTTPRoute🔒

4. Gateway API 实现方案对比 - AWS 原生 vs 开源​

本节对 5 大主流 Gateway API 实现方案进行详细对比。了解每个方案的功能、优势和劣势，有助于您为组织做出最优选择。

4.1 方案总览对比​

以下矩阵对比了 5 个 Gateway API 实现方案的关键功能、限制和使用场景。

Gateway API Solution Overview Comparison
5 solutions · 5 comparison categories
Overview▶
Click to expand
Key Features▶
Click to expand
Key Limitations▶
Click to expand
Best Use Cases▶
Click to expand
Not Recommended▶
Click to expand

4.2 综合对比表​

Gateway API Solution Comprehensive Comparison
72 comparison items · 10 categories · 5 solutions
Basic Info (5개)▶
Click to expand · 5개 항목
Gateway API (6개)▶
Click to expand · 6개 항목
Core Features (8개)▶
Click to expand · 8개 항목
Security (4개)▶
Click to expand · 4개 항목
Performance (3개)▶
Click to expand · 3개 항목
Operations (5개)▶
Click to expand · 5개 항목
Mesh Integration (4개)▶
Click to expand · 4개 항목
Advanced Features (6개)▶
Click to expand · 6개 항목
AI/ML (3개)▶
Click to expand · 3개 항목
Observability (4개)▶
Click to expand · 4개 항목
Cost (5개)▶
Click to expand · 5개 항목
Community (4개)▶
Click to expand · 4개 항목

4.3 NGINX 功能映射​

对比 8 个关键 NGINX Ingress Controller 功能在各 Gateway API 方案中的实现方式。

🔀 NGINX Features → Gateway API Mapping
NGINX feature implementation by solution
#NGINX FeatureAWS NativeCiliumNGINX FabricEnvoy GWkGateway
1
Basic AuthLambda/JWTL7 PolicyOIDC PolicyExtAuthJWT/OIDC
2
IP AllowlistWAF IP Sets + SGCiliumNetworkPolicyNginxProxySecurityPolicyRouteOption
3
Rate LimitingWAF Rate RuleL7 Rate LimitNginxProxyBackendTrafficPolicyRouteOption
4
URL RewriteHTTPRoute FilterHTTPRoute FilterHTTPRoute FilterHTTPRoute FilterHTTPRoute Filter
5
Body SizeWAF Size Rule-NginxProxyClientTrafficPolicyRouteOption
6
Custom ErrorALB Fixed Response-Custom BackendDirect ResponseDirectResponse
7
Header RoutingHTTPRoute matchesHTTPRoute matchesHTTPRoute matchesHTTPRoute matchesHTTPRoute matches
8
Cookie AffinityTG Stickiness-Upstream ConfigSession PersistenceRouteOption

图例：

  • ✅ 原生支持（无需额外工具）
  • ⚠️ 部分支持或需要额外配置
  • ❌ 不支持（需要单独方案）

4.4 实施难度对比​

⚖️ Implementation Difficulty Comparison
Feature implementation difficulty by solution
FeatureAWS NativeCiliumNGINX FabricEnvoy GWkGateway
Basic Auth
Medium
Medium
Easy
Medium
Easy
IP Allowlist
Easy
Easy
Easy
Easy
Easy
Rate Limiting
Medium
Medium
Easy
Easy
Easy
URL Rewrite
Easy
Easy
Easy
Easy
Easy
Body Size
Medium
Hard
Easy
Easy
Easy
Custom Error
Easy
Hard
Medium
Easy
Easy
Header Routing
Easy
Easy
Easy
Easy
Easy
Cookie Affinity
Easy
Hard
Easy
Medium
Easy

4.5 成本影响分析​

AWS Native vs 开源：成本与性能影响对比
按功能综合比较额外成本、延迟开销和跳数增加
功能
AWS Native 成本
开源成本
性能影响
Basic Auth (JWT)
Lambda 执行成本 ~$2-10/月（每 100 万请求）
无（自行实现）
AWS: Lambda 调用 +5-50ms（冷启动 +200ms） 开源: 网关内置处理, <1ms
⚠️ AWS: +1 跳（ALB → Lambda Authorizer） 开源: 无额外跳数
IP Allowlist
WAF IP Set + 规则 $5 (Web ACL) + $1 (规则) = $6/月
无（NetworkPolicy）
AWS: WAF 规则评估 +0.5-1ms 开源: 内核/eBPF 层处理, <0.1ms
✅ 双方均无额外跳数 AWS: ALB 内联处理 开源: 网络层处理
Rate Limiting
WAF Rate-Based Rule $5 (Web ACL) + $1 (规则) + $0.60/百万请求
无（L7 Policy）
AWS: WAF 规则评估 +0.5-1ms 开源: Envoy/NGINX 代理处理, +1-2ms
⚠️ AWS: 无额外跳数（ALB 内联） 开源: 未使用 L7 代理时可能增加代理跳数
Body Size 限制
WAF Body Size Rule 包含在 WAF 成本中
无（Proxy Config）
AWS: WAF 请求体检查 +1-3ms（与请求体大小成正比） 开源: Proxy buffer 设置, <1ms
✅ 双方均无额外跳数 在现有路径内联处理
总计
WAF 总计: ~$20-100/月 （随流量变动）
无 （仅计算资源）
AWS: 随规则数累计 +1-5ms 开源: 经由代理时 +2-5ms
⚠️ AWS: 使用 Lambda Auth 时最多 +1 跳 开源: 使用 L7 代理时最多 +1 跳
成本优化建议
  • 需要 3 个以上 WAF 功能时，AWS Native 具有成本效益。可以在单个 WebACL 中整合多个规则
  • 仅需 1-2 个功能时，开源方案（Cilium、Envoy Gateway）可免费实现
  • 延迟敏感型工作负载推荐开源方案，在内核/eBPF 层处理，无 WAF 规则评估开销
  • 使用 Lambda Authorizer 时，注意冷启动导致的 p99 延迟飙升。建议配置 Provisioned Concurrency

4.6 功能实现代码示例​

对比各方案的实现方式。点击标签页查看每个方案的代码。

1. 认证（Basic Auth 替代方案）​

# AWS LBC v3 的原生 JWT 验证
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: jwt-protected-route
  namespace: production
spec:
  parentRefs:
    - name: production-gateway
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      filters:
        - type: ExtensionRef
          extensionRef:
            group: eks.amazonaws.com
            kind: JWTAuthorizer
            name: cognito-authorizer
      backendRefs:
        - name: api-service
          port: 8080

---
# JWTAuthorizer CRD（LBC v3 扩展）
apiVersion: eks.amazonaws.com/v1
kind: JWTAuthorizer
metadata:
  name: cognito-authorizer
spec:
  issuer: https://cognito-idp.us-west-2.amazonaws.com/us-west-2_ABC123
  audiences:
    - api-gateway-client
  claimsToHeaders:
    - claim: sub
      header: x-user-id
    - claim: email
      header: x-user-email

2. 速率限制​

限制

AWS Native（LBC v3）不支持网关级别的原生速率限制。使用 AWS WAF Rate-based Rule 实现基于 IP 的请求限制。

# 将 WAF Rate-based Rule 关联到 ALB
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gateway
  annotations:
    # 速率限制 WAF ACL ARN
    aws.load-balancer.waf-acl-arn: arn:aws:wafv2:us-west-2:123456789012:regional/webacl/rate-limit/a1b2c3d4
spec:
  gatewayClassName: aws-alb
  listeners:
    - name: http
      port: 80
      protocol: HTTP

使用 ACK（AWS Controllers for Kubernetes）创建 WAF Rate-based Rule：

ACK WAFv2 控制器支持通过 Kubernetes 清单声明式管理 WAF 资源。

通过 EKS Capabilities 启用 ACK（推荐）：

使用 EKS Capabilities（2025 年 11 月 GA），ACK 控制器作为 AWS 完全托管服务运行。控制器在 AWS 托管基础设施上执行，不会在工作节点上部署额外的 Pod。

# 1. 创建 IAM Capability Role
aws iam create-role \
  --role-name EKS-ACK-Capability-Role \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": { "Service": "eks.amazonaws.com" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "aws:SourceAccount": "<ACCOUNT_ID>" }
      }
    }]
  }'

# 附加 WAFv2 权限策略
aws iam put-role-policy \
  --role-name EKS-ACK-Capability-Role \
  --policy-name ACK-WAFv2-Policy \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Action": ["wafv2:*"],
      "Resource": "*"
    }]
  }'

# 2. 在 EKS 集群上创建 ACK Capability
aws eks create-capability \
  --cluster-name my-eks-cluster \
  --capability-type ACK \
  --capability-configuration '{
    "capabilityRoleArn": "arn:aws:iam::<ACCOUNT_ID>:role/EKS-ACK-Capability-Role"
  }'

# 3. 验证 CRD 注册
kubectl get crds | grep wafv2
替代方案：Helm 直接安装（非 EKS 环境）

对于非 EKS 环境或需要直接管理控制器的场景，可通过 Helm 安装。

helm install ack-wafv2-controller \
  oci://public.ecr.aws/aws-controllers-k8s/wafv2-chart \
  --namespace ack-system \
  --create-namespace \
  --set aws.region=ap-northeast-2

此方式会将控制器作为 Pod 部署到工作节点上，通过 IRSA（IAM Roles for Service Accounts）管理权限。

# ACK WAFv2 WebACL - Rate-based Rule 定义
apiVersion: wafv2.services.k8s.aws/v1alpha1
kind: WebACL
metadata:
  name: rate-limit-acl
  namespace: production
spec:
  name: rate-limit-acl
  scope: REGIONAL
  defaultAction:
    allow: {}
  rules:
    - name: ip-rate-limit
      priority: 1
      action:
        block: {}
      statement:
        rateBasedStatement:
          limit: 500            # 5 分钟内最大请求数（100~2,000,000,000）
          aggregateKeyType: IP  # 基于 IP 聚合
      visibilityConfig:
        sampledRequestsEnabled: true
        cloudWatchMetricsEnabled: true
        metricName: ip-rate-limit
  visibilityConfig:
    sampledRequestsEnabled: true
    cloudWatchMetricsEnabled: true
    metricName: rate-limit-acl
# 将创建的 WebACL ARN 连接到 Gateway
# WebACL 创建后从 status.ackResourceMetadata.arn 获取 ARN：
#   kubectl get webacl rate-limit-acl -n production \
#     -o jsonpath='{.status.ackResourceMetadata.arn}'
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gateway
  annotations:
    aws.load-balancer.waf-acl-arn: <WebACL ARN>
spec:
  gatewayClassName: aws-alb
  listeners:
    - name: http
      port: 80
      protocol: HTTP
ACK WAFv2 控制器要求
  • ACK WAFv2 控制器需要 wafv2:CreateWebACL、wafv2:UpdateWebACL、wafv2:DeleteWebACL、wafv2:GetWebACL 等 IAM 权限
  • EKS Capabilities：将 WAFv2 权限附加到 IAM Capability Role。控制器在 AWS 托管基础设施上运行
  • Helm 安装：通过 IRSA（IAM Roles for Service Accounts）或 EKS Pod Identity 授予最小权限
  • WebACL 和 ALB 必须在同一区域

3. IP 白名单​

# 将 WAF 关联到 ALB（LBC v3）
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gateway
  annotations:
    aws.load-balancer.waf-acl-arn: arn:aws:wafv2:us-west-2:123456789012:regional/webacl/ip-allowlist/a1b2c3d4
spec:
  gatewayClassName: aws-alb
  listeners:
    - name: http
      port: 80
      protocol: HTTP

使用 ACK（AWS Controllers for Kubernetes）创建 WAF IP 白名单：

ACK WAFv2 控制器支持通过 Kubernetes 清单声明式管理 IPSet 和 WebACL。

# 1. ACK WAFv2 IPSet - 定义允许的 IP 列表
apiVersion: wafv2.services.k8s.aws/v1alpha1
kind: IPSet
metadata:
  name: allowed-ips
  namespace: production
spec:
  name: allowed-ips
  scope: REGIONAL
  ipAddressVersion: IPV4
  addresses:
    - "10.0.0.0/8"        # VPC 内部
    - "192.168.1.0/24"    # 办公网络
    - "203.0.113.100/32"  # 特定允许 IP
# 2. ACK WAFv2 WebACL - 基于 IPSet 的白名单规则
# IPSet 创建后从 status.ackResourceMetadata.arn 获取 ARN：
#   kubectl get ipset allowed-ips -n production \
#     -o jsonpath='{.status.ackResourceMetadata.arn}'
apiVersion: wafv2.services.k8s.aws/v1alpha1
kind: WebACL
metadata:
  name: ip-allowlist-acl
  namespace: production
spec:
  name: ip-allowlist-acl
  scope: REGIONAL
  defaultAction:
    block: {}  # 默认阻止，仅白名单 IP 通过
  rules:
    - name: allow-trusted-ips
      priority: 1
      action:
        allow: {}
      statement:
        ipSetReferenceStatement:
          arn: <IPSet ARN>  # allowed-ips IPSet 的 ARN
      visibilityConfig:
        sampledRequestsEnabled: true
        cloudWatchMetricsEnabled: true
        metricName: allow-trusted-ips
  visibilityConfig:
    sampledRequestsEnabled: true
    cloudWatchMetricsEnabled: true
    metricName: ip-allowlist-acl
# 3. 将创建的 WebACL ARN 连接到 Gateway
# WebACL 创建后从 status.ackResourceMetadata.arn 获取 ARN：
#   kubectl get webacl ip-allowlist-acl -n production \
#     -o jsonpath='{.status.ackResourceMetadata.arn}'
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gateway
  annotations:
    aws.load-balancer.waf-acl-arn: <WebACL ARN>
spec:
  gatewayClassName: aws-alb
  listeners:
    - name: http
      port: 80
      protocol: HTTP
ACK WAFv2 IPSet 管理提示
  • 更新 IPSet 的 addresses 字段后，ACK 控制器会自动同步 AWS WAF IPSet
  • 结合 GitOps（ArgoCD/Flux）可通过 PR 方式管理 IP 变更
  • IPSet 和 WebACL 必须在同一区域，需要 wafv2:*IPSet*、wafv2:*WebACL* 权限（EKS Capabilities：IAM Capability Role / Helm：IRSA）

4. URL 重写​

所有实现方案均支持的标准 Gateway API 功能。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: url-rewrite
spec:
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /old-api
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplacePrefixMatch
          replacePrefixMatch: /new-api
    backendRefs:
    - name: api-service
      port: 8080

5. 请求体大小限制​

限制

使用 AWS WAF Rule 限制请求体大小。

# 将 WAF Body Size Limit Rule 关联到 ALB
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gateway
  annotations:
    aws.load-balancer.waf-acl-arn: arn:aws:wafv2:us-west-2:123456789012:regional/webacl/body-size-limit/a1b2c3d4
spec:
  gatewayClassName: aws-alb
  listeners:
    - name: http
      port: 80
      protocol: HTTP

使用 ACK（AWS Controllers for Kubernetes）创建 WAF Body Size Rule：

# ACK WAFv2 WebACL - Body Size Limit Rule 定义
apiVersion: wafv2.services.k8s.aws/v1alpha1
kind: WebACL
metadata:
  name: body-size-limit-acl
  namespace: production
spec:
  name: body-size-limit-acl
  scope: REGIONAL
  defaultAction:
    allow: {}
  rules:
    - name: block-large-body
      priority: 1
      action:
        block: {}
      statement:
        sizeConstraintStatement:
          fieldToMatch:
            body:
              oversizeHandling: MATCH  # 也匹配超大请求体
          comparisonOperator: GT
          size: 10485760              # 10MB（字节单位）
          textTransformations:
            - priority: 0
              type: NONE
      visibilityConfig:
        sampledRequestsEnabled: true
        cloudWatchMetricsEnabled: true
        metricName: block-large-body
  visibilityConfig:
    sampledRequestsEnabled: true
    cloudWatchMetricsEnabled: true
    metricName: body-size-limit-acl
将规则整合到单个 WebACL

如果同时使用 IP 白名单、速率限制和请求体大小限制，无需为每个功能创建单独的 WebACL——在一个 WebACL 中通过 priority 区分多个规则即可整合管理。每个 ALB 只能关联一个 WebACL，因此整合管理是必须的。

6. 自定义错误页面​

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: custom-error
spec:
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /maintenance
    filters:
    - type: ExtensionRef
      extensionRef:
        group: alb.networking.aws.com
        kind: FixedResponse
        name: maintenance-page
---
apiVersion: alb.networking.aws.com/v1
kind: FixedResponse
metadata:
  name: maintenance-page
spec:
  statusCode: 503
  contentType: text/html
  body: |
    <html>
      <body>
        <h1>Under Maintenance</h1>
        <p>We'll be back soon!</p>
      </body>
    </html>

7. 基于 Header 的路由​

所有实现方案均支持的标准 Gateway API 功能。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: header-routing
spec:
  rules:
  # 将 beta 用户路由到 beta 后端
  - matches:
    - headers:
      - name: X-User-Type
        value: beta
    backendRefs:
    - name: beta-backend
      port: 8080

  # 将其他用户路由到生产后端
  - backendRefs:
    - name: prod-backend
      port: 8080
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gateway
  annotations:
    # 启用 ALB 粘性会话
    alb.ingress.kubernetes.io/target-group-attributes: stickiness.enabled=true,stickiness.lb_cookie.duration_seconds=86400
spec:
  gatewayClassName: aws-alb
  listeners:
  - name: http
    port: 80
    protocol: HTTP

4.7 路由选择决策树​

使用以下决策树为您的组织选择最优方案。

4.8 基于场景的推荐​

以下是基于常见组织场景的推荐方案。

🎯 Scenario-based Solution Recommendations
Optimal Gateway API implementation selection guide by use case
AWS All-in + Minimal Ops
1stAWS Native2ndCilium
Managed, SLA guaranteed, small ops team
High Performance + Observability
1stCilium2ndEnvoy GW
Best eBPF performance, Hubble Service Map
NGINX Experience + Multi-cloud
1stNGINX Fabric2ndEnvoy GW
Leverage existing NGINX knowledge, cloud neutral
CNCF + Service Mesh
1stEnvoy GW2ndkGateway
Istio compatible, CNCF standard compliance
AI/ML + Unified Gateway
1stkGateway2ndCilium
AI routing, MCP Gateway, future-oriented
Finance/Healthcare Security
1stAWS Native2ndCilium
WAF, Shield, audit trails, compliance
Startup + Cost Optimization
1stCilium2ndNGINX/Envoy
Fixed costs, avoid vendor lock-in
Hybrid/Multi-cluster
1stCilium2ndkGateway
BGP Control Plane, multi-site mesh
Quick PoC (Validation)
1stAWS Native2ndNGINX Fabric
Fast setup, managed, proven stability
Long-term Strategic Investment
1stCilium2ndEnvoy GW
eBPF future tech, CNCF ecosystem

5. 基准测试对比规划​

计划进行系统化的基准测试，对 5 个 Gateway API 实现方案进行客观的性能对比。将在相同的 EKS 环境中测量吞吐量、延迟、TLS 性能、L7 路由、扩展性、资源效率、故障恢复和 gRPC 共 8 个场景。

详细基准测试计划

关于测试环境设计、详细场景、测量指标和执行计划，请参阅**Gateway API 实现方案性能基准测试计划**。

6. 总结与未来路线图​

6.1 总结​

🎯 Gateway API Implementation Selection Guide
Optimal route for your organization needs
AWS Native→ AWS all-in organizations
✓ Fully managed, auto-scaling, zero ops
Cilium→ High performance + observability focus
✓ Best eBPF performance, Hubble visibility, ENI native
NGINX Fabric→ Leveraging NGINX experience
✓ Proven stability, familiar config, fast transition
Envoy Gateway→ CNCF standard + service mesh
✓ Rich L7 features, Istio integration, extensibility
kGateway→ AI/ML integration needs
✓ AI routing, enterprise support, Solo.io ecosystem

根据上表选择最适合您组织的方案。

AWS Native (LBC v3) — 最小运维开销、托管 ALB/NLB、SLA 保障、AWS WAF/Shield/ACM 集成。最适合以稳定性优先于性能的纯 AWS 环境。

6.2 未来扩展路线图​

🗺️ Future Expansion Roadmap
Gateway API Ecosystem Evolution Path — click to expand
🚀
Now
Now
1/4▼
📊
6 Months
6 Months
2/4▼
🔗
1 Year
1 Year
3/4▼
🤖
2 Years
2 Years
4/4▼

6.3 核心信息​

信息

在 2026 年 3 月 NGINX Ingress EOL 之前完成迁移，从根源上消除安全威胁。

Gateway API 不仅仅是 Ingress 的替代品，更是云原生流量管理的未来。

  • 角色分离：平台团队和开发团队之间职责清晰分离
  • 标准化：无供应商锁定的可移植配置
  • 可扩展性：向东西向流量、Service Mesh 和 AI 集成扩展

立即开始：

  1. 收集当前 Ingress 清单（迁移执行策略文档）
  2. 选择匹配您工作负载的方案（第 6.1 节）
  3. 构建 PoC 环境（迁移执行策略文档）
  4. 执行渐进式迁移（迁移执行策略文档）

相关文档​

子文档（高级指南）​

特定主题的深入内容在单独的子文档中提供。

相关分类​

外部参考​