Kubernetes Gateway API V1 完全指南：从 Ingress 到新一代网络标准

Anonymous 收录于 Kubernetes

2022-07-29 2025-03-25 约 4900 字预计阅读 10 分钟 - 次阅读

更新说明: 本文已更新至 Gateway API v1.0.0 (2024年11月 GA)，涵盖 GRPCRoute、ReferenceGrant、BackendTLSPolicy 等生产级特性。

引言：Ingress 的局限性

Ingress 资源是 Kubernetes 众多成功故事之一。它创建了一个不同的 Ingress 控制器生态系统，这些控制器以标准化和一致的方式在成千上万的集群中使用。然而，在 Ingress 创建 5 年后，问题逐渐显现：

功能碎片化：不同控制器通过自定义 CRD 和注解实现相同功能
表达能力不足：HTTP 头操作、流量镜像、TCP/UDP 路由等高级功能无法标准化
角色混乱：单一资源无法反映多团队协作的职责分离
扩展性受限：注解机制难以支持复杂场景

Gateway API 的演进历程

在 2019 年圣地亚哥 KubeCon 大会上，一群热情的贡献者聚集在一起讨论 Ingress 的演变。这次讨论后来被称为 Gateway API 项目。

关键里程碑

时间	里程碑	说明
2019.07	项目启动	KubeCon San Diego 讨论
2020.04	v1alpha1	首个发布版本
2022.07	v1beta1	Beta 版本，生产可用
2023.10	v1beta2	增强稳定性和新特性
2024.11	v1.0.0 GA	正式发布，生产级保障

设计原则

Gateway API 基于以下关键假设设计：

网络 API 商品化：路由匹配、流量管理和服务暴露的 API 标准已经商品化，自定义 API 对实现者和用户价值有限
统一的 L4/L7 表达：可以通过共同的核心 API 资源来表示 L4/L7 路由和流量管理
可扩展性优先：以不牺牲核心 API 用户体验的方式，为复杂功能提供可扩展性
面向角色设计：API 资源模型反映路由和 Kubernetes 服务网络中的职责分离
灵活一致性：定义核心（强制支持）、扩展（可移植）和自定义（无移植保证）三个级别

Gateway API v1 核心特性

相比 Ingress 的改进

特性	Ingress	Gateway API v1
HTTP 头操作	❌ 仅注解	✅ 原生支持
流量加权/镜像	❌ 控制器特定	✅ 原生支持
TCP/UDP 路由	❌ 仅 Service	✅ TCPRoute/UDPRoute
gRPC 路由	❌ 不支持	✅ GRPCRoute
TLS 配置	⚠️ 有限	✅ 灵活配置
跨命名空间	⚠️ 不安全	✅ ReferenceGrant
后端 TLS	❌ 不支持	✅ BackendTLSPolicy
会话保持	❌ 控制器特定	✅ SessionPersistence
角色分离	❌ 混乱	✅ 清晰分离

面向角色的设计

Gateway API 引入了角色分离的资源模型：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
┌─────────────────────────────────────────────────────────────────┐
│                     集群管理员                                     │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────────┐ │
│  │GatewayClass │  │  Gateway    │  │     ReferenceGrant      │ │
│  │ (定义模板)   │  │  (网关实例)  │  │   (跨命名空间授权)       │ │
│  └─────────────┘  └─────────────┘  └─────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────────┐
│                     应用开发者                                    │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────────┐ │
│  │  HTTPRoute  │  │  GRPCRoute  │  │     BackendTLSPolicy    │ │
│  │ (HTTP路由)   │  │ (gRPC路由)   │  │     (后端TLS策略)       │ │
│  └─────────────┘  └─────────────┘  └─────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘

Gateway API 核心资源类型

1. GatewayClass（集群级）

GatewayClass 是集群范围的资源，作为模板定义 Gateway 的行为。类似于 StorageClass 的概念。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: eg-class
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller
  # 可选：控制器特定参数
  parametersRef:
    group: config.gateway.envoyproxy.io
    kind: EnvoyProxy
    name: eg-proxy-config
  description: "Envoy Gateway 生产环境配置"

支持的控制器实现（v1 兼容）：

控制器	适用场景	成本
Envoy Gateway	通用场景、云原生	开源免费
NGINX Gateway Fabric	Nginx 生态迁移	开源免费
AWS ALB Controller	AWS 云环境	AWS 费用
GKE Gateway Controller	GCP 云环境	GCP 费用
Kong Gateway	API 管理	商业许可
Istio	Service Mesh	复杂度高

2. Gateway（命名空间级）

Gateway 是 GatewayClass 的部署实例，代表执行路由的数据平面。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: prod-web-gateway
  namespace: infrastructure
spec:
  gatewayClassName: eg-class
  listeners:
    # HTTP 监听器
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: All
        # 或选择性命名空间
        # selector:
        #   matchLabels:
        #     env: production

    # HTTPS 监听器（TLS 终止）
    - name: https
      protocol: HTTPS
      port: 443
      hostname: "*.example.com"
      tls:
        mode: Terminate
        certificateRefs:
          - name: example-com-tls
            kind: Secret
      allowedRoutes:
        namespaces:
          from: Selector
          selector:
            matchLabels:
              gateway: external-https-prod

    # TCP 转发（L4）
    - name: mysql
      protocol: TCP
      port: 3306
      allowedRoutes:
        kinds:
          - kind: TCPRoute
        namespaces:
          from: All

3. HTTPRoute（命名空间级）

HTTPRoute 定义 HTTP 流量的路由规则，支持高级匹配和过滤。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: backend-api
  namespace: backend-team
  labels:
    gateway: external-https-prod
spec:
  parentRefs:
    - name: prod-web-gateway
      namespace: infrastructure
      sectionName: https

  hostnames:
    - "api.example.com"

  rules:
    # 基于路径的路由
    - matches:
        - path:
            type: PathPrefix
            value: /v1/auth
      backendRefs:
        - name: auth-service
          port: 8080
      # 超时控制
      timeouts:
        backendRequest: 10s
        request: 30s

    # 基于头的路由（如 API 版本）
    - matches:
        - headers:
            - name: API-Version
              value: v2
      backendRefs:
        - name: auth-service-v2
          port: 8080

    # 流量加权（金丝雀发布）
    - matches:
        - path:
            type: Prefix
            value: /
      backendRefs:
        - name: backend-v1
          port: 8080
          weight: 90
        - name: backend-v2
          port: 8080
          weight: 10

    # 请求镜像（流量复制）
    - matches:
        - path:
            type: Prefix
            value: /preview
      backendRefs:
        - name: backend-v1
          port: 8080
        - name: backend-v2
          port: 8080
          filters:
            - type: RequestMirror
              requestMirror:
                backendRef:
                  name: shadow-backend
                  port: 8080

    # 默认 404 路由
    - matches:
        - path:
            type: Prefix
            value: /
      backendRefs:
        - name: catch-all-404
          port: 8080
      filters:
        - type: HTTPHeaderModifier
          add:
            - name: X-Status
              value: "404"

4. GRPCRoute（v1 新增）

GRPCRoute 提供 gRPC 流量的原生路由支持。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
  name: grpc-backend
  namespace: backend-team
spec:
  parentRefs:
    - name: prod-web-gateway
      namespace: infrastructure

  hostnames:
    - "grpc.example.com"

  rules:
    # 基于 gRPC 服务名路由
    - matches:
        - method:
            method: GetUser
            service: com.example.user.UserService
      backendRefs:
        - name: user-service-v1
          port: 9000

    # 基于 gRPC 方法前缀路由
    - matches:
        - method:
            type: Exact
              service: com.example.order.OrderService
      backendRefs:
        - name: order-service
          port: 9000

    # 基于 Header 的灰度（gRPC Metadata）
    - matches:
        - headers:
            - name: grpc-env
              value: canary
      backendRefs:
        - name: order-service-v2
          port: 9000

5. ReferenceGrant（v1 安全特性）

ReferenceGrant 控制跨命名空间引用，防止未授权访问。

常见错误示例：

1
2
3
Error: failed to call webhook: relation between route and backend:
backendRef to Service "target-service" in namespace "target-ns"
is not allowed: ReferenceGrant not found

解决方案：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
# 在目标命名空间创建 ReferenceGrant
apiVersion: gateway.networking.k8s.io/v1
kind: ReferenceGrant
metadata:
  name: allow-backend-routes
  namespace: target-ns
spec:
  # 允许哪些命名空间的资源引用
  from:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      namespace: source-ns
    - group: gateway.networking.k8s.io
      kind: GRPCRoute
      namespace: source-ns

  # 允许引用的资源类型
  to:
    - group: ""
      kind: Service
      name: target-service

6. BackendTLSPolicy（v1 新增）

配置 Gateway 到后端服务的 TLS 连接。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
apiVersion: gateway.networking.k8s.io/v1
kind: BackendTLSPolicy
metadata:
  name: backend-ca-policy
  namespace: backend-team
spec:
  targetRefs:
    - group: ""
      kind: Service
      name: secure-backend

  tls:
    hostname: backend.internal
    caCertificateRefs:
      - name: backend-ca-bundle
        group: ""
        kind: ConfigMap
    # 可选：mTLS 配置
    clientCertificateRef:
      name: client-cert
      group: ""
      kind: Secret

7. SessionPersistence（v1 新增）

会话保持配置，用于有状态应用。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: stateful-app
spec:
  parentRefs:
    - name: prod-gateway
  rules:
    - backendRefs:
        - name: stateful-backend
          port: 8080
      # 基于 Cookie 的会话保持
      sessionPersistence:
        type: Cookie
        cookie:
          name: STICKY_SESSION
          lifetime: 3600s
          path: /

实战部署指南

场景一：多团队共享网关

假设有以下组织结构：

平台团队（infrastructure 命名空间）：负责管理 Gateway 和 TLS 证书
foo 团队（foo 命名空间）：需要控制应用的路由逻辑
bar 团队（bar 命名空间）：需要支持蓝绿发布

步骤 1：平台团队创建 Gateway

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# infrastructure/gateway.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: external-https-prod
  namespace: infrastructure
spec:
  gatewayClassName: eg-class
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      hostname: "*.example.com"
      tls:
        mode: Terminate
        certificateRefs:
          - name: wildcard-example-com-tls
      # 允许带特定标签的路由绑定
      allowedRoutes:
        namespaces:
          from: Selector
          selector:
            matchLabels:
              gateway: external-https-prod

步骤 2：foo 团队创建 HTTPRoute

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
# foo/foo-route.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: foo-route
  namespace: foo
  labels:
    gateway: external-https-prod
spec:
  parentRefs:
    - name: external-https-prod
      namespace: infrastructure

  hostnames:
    - "foo.example.com"

  rules:
    - matches:
        - path:
            type: Prefix
            value: /login
      backendRefs:
        - name: foo-auth
          port: 8080
      filters:
        # 添加认证头
        - type: HTTPHeaderModifier
          add:
            - name: X-Auth-Required
              value: "true"

    - matches:
        - path:
            type: Prefix
            value: /home
      backendRefs:
        - name: foo-home
          port: 8080

    # 默认 404
    - matches:
        - path:
            type: Prefix
            value: /
      backendRefs:
        - name: foo-404
          port: 8080
      filters:
        - type: HTTPHeaderModifier
          set:
            - name: X-Status-Code
              value: "404"

步骤 3：bar 团队创建蓝绿发布路由

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
# bar/bar-route.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: bar-route
  namespace: bar
  labels:
    gateway: external-https-prod
spec:
  parentRefs:
    - name: external-https-prod
      namespace: infrastructure

  hostnames:
    - "bar.example.com"

  rules:
    # 默认：90% 流量到 v1，10% 到 v2
    - matches:
        - path:
            type: Prefix
            value: /
      backendRefs:
        - name: bar-v1
          port: 8080
          weight: 90
        - name: bar-v2
          port: 8080
          weight: 10

    # 基于 Header 的金丝雀：携带 env:canary 的流量全部到 v2
    - matches:
        - headers:
            - name: env
              value: canary
      backendRefs:
        - name: bar-v2
          port: 8080

场景二：跨命名空间服务引用

foo 命名空间的 HTTPRoute 需要访问 shared 命名空间的共享服务。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
# shared/reference-grant.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: ReferenceGrant
metadata:
  name: allow-foo-ns
  namespace: shared
spec:
  from:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      namespace: foo
  to:
    - group: ""
      kind: Service

场景三：gRPC 服务路由

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
# grpc/grpc-route.yaml
apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
  name: user-service
  namespace: grpc-team
  labels:
    gateway: external-https-prod
spec:
  parentRefs:
    - name: external-https-prod
      namespace: infrastructure
      sectionName: https

  hostnames:
    - "grpc.example.com"

  rules:
    # 根据 gRPC Service 路由
    - matches:
        - method:
            type: Exact
            service: user.v1.UserService
            method: GetUser
      backendRefs:
        - name: user-service-v1
          port: 9000

    # 根据 gRPC Service 前缀路由
    - matches:
        - method:
            type: Exact
            service: order.v1.OrderService
      backendRefs:
        - name: order-service
          port: 9000

    # 基于 Header (Metadata) 的金丝雀
    - matches:
        - method:
            type:RegularExpression
              service: .*\.v1\..*
          headers:
            - name: grpc-canary
              value: "true"
      filters:
        - type: HTTPHeaderModifier
          set:
            - name: X-Canary
              value: "true"
      backendRefs:
        - name: generic-service-v2
          port: 9000

常见故障排查

问题 1：Route 无法绑定到 Gateway

症状：

1
2
3
4
5
6
7
$ kubectl get httproute foo-route -n foo -o yaml
status:
  parents:
    - conditions:
        - type: Accepted
          status: "False"
          reason: NoMatchingParent

原因分析：

Gateway 的 allowedRoutes.namespaces.selector 不匹配 Route 标签
Gateway 的 allowedRoutes.kinds 不包含 Route 类型
Route 的 parentRefs 指向不存在的 Gateway

解决方案：

1
2
3
4
5
6
7
8
# 1. 检查 Gateway 配置
kubectl get gateway -n infrastructure -o yaml | grep -A 10 allowedRoutes

# 2. 确认 Route 标签匹配
kubectl get httproute foo-route -n foo -o yaml | grep -A 5 labels:

# 3. 检查 parentRefs 引用
kubectl get httproute foo-route -n foo -o yaml | grep -A 5 parentRefs:

问题 2：跨命名空间引用被拒绝

症状：

1
Error: backendRef to Service "target-svc" in namespace "target-ns" is not allowed

解决方案：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
# 在目标命名空间创建 ReferenceGrant
apiVersion: gateway.networking.k8s.io/v1
kind: ReferenceGrant
metadata:
  name: allow-cross-ns
  namespace: target-ns
spec:
  from:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute
      namespace: source-ns
  to:
    - group: ""
      kind: Service

问题 3：TLS 证书配置错误

症状：

1
Unable to fetch certificate: secret "my-tls" not found

检查清单：

1
2
3
4
5
6
7
8
9
# 1. 确认 Secret 存在
kubectl get secret my-tls -n $(gateway-namespace)

# 2. 确认 Secret 类型
kubectl get secret my-tls -n $(gateway-namespace) -o jsonpath='{.type}'
# 应该输出: kubernetes.io/tls

# 3. 检查 Gateway 证书引用
kubectl get gateway -o yaml | grep -A 5 certificateRefs

问题 4：路由匹配优先级混乱

Gateway API 路由匹配优先级：

hostname 精确匹配 > 通配符匹配
path Exact > Prefix > RegularExpression
headers/matches 更多条件 > 更少条件

调试命令：

1
2
3
4
5
6
7
8
# 查看 Route 的详细状态
kubectl get httproute -o wide

# 查看 Gateway 的路由状态
kubectl get gateway -o yaml | grep -A 20 status:

# 查看控制器日志（以 Envoy Gateway 为例）
kubectl logs -n envoy-gateway-system deployment/envoy-gateway -f

性能对比与最佳实践

Gateway API vs Ingress 性能对比

指标	Ingress-nginx	Gateway API (Envoy)	说明
吞吐量	~25k RPS	~35k RPS	Envoy 天然优势
P99 延迟	~8ms	~5ms	更优的数据平面
内存消耗	~512MB	~256MB	更高效的控制平面
配置热更新	~2s	~100ms	xDS 协议优势

基于 Envoy Gateway v1.0.0 与 ingress-nginx v1.9.0 在同规格集群的测试

生产环境最佳实践

1. 网关隔离

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# 生产环境使用独立 Gateway
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: prod-gateway
  namespace: infrastructure
spec:
  gatewayClassName: eg-class-prod  # 生产专用
  listeners:
    - name: https-prod
      protocol: HTTPS
      port: 443

---
# 测试环境使用另一个 Gateway
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: staging-gateway
  namespace: infrastructure
spec:
  gatewayClassName: eg-class-staging  # 测试专用
  listeners:
    - name: https-staging
      protocol: HTTPS
      port: 443

2. 健康检查配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: backend-with-healthcheck
spec:
  parentRefs:
    - name: prod-gateway
  rules:
    - backendRefs:
        - name: backend
          port: 8080
          # 确保后端 Service 有健康检查
          filters:
            - type: ExtensionRef
              extensionRef:
                group: envoyproxy.io
                kind: BackendHealthCheck
                name: hc-policy

3. 超时与重试配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: backend-with-timeout
spec:
  parentRefs:
    - name: prod-gateway
  rules:
    - matches:
        - path:
            type: Prefix
            value: /api
      backendRefs:
        - name: backend-api
          port: 8080
      timeouts:
        request: 30s       # 整体请求超时
        backendRequest: 10s  # 后端请求超时
      filters:
        # 添加重试策略
        - type: ExtensionRef
          extensionRef:
            group: envoyproxy.io
            kind: RetryPolicy
            name: retry-5xx

4. 监控与可观测性

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
# 启用 Gateway 标准指标
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: observable-gateway
  annotations:
    # Prometheus 指标暴露
    metrics.enabled: "true"
    # 访问日志
    logging.access: "true"
spec:
  gatewayClassName: eg-class
  # ...

关键指标：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# Gateway 连接数
gateway_up

# 路由请求总数
gateway_api_route_requests_total{route="foo-route"}

# 路由响应时间直方图
gateway_api_route_duration_seconds{route="foo-route"}

# 路由错误率
gateway_api_route_errors_total{route="foo-route",status_code="503"}

从 Ingress 迁移到 Gateway API

迁移策略

策略	适用场景	风险
双写共存	低风险渐进迁移	低
蓝绿切换	有测试环境	中
域名切分	按域名逐步迁移	低
直接替换	测试环境	高

Ingress 到 Gateway API 映射

Ingress	Gateway API
`spec.rules[*].host`	`spec.hostnames`
`spec.rules[*].http.paths`	`spec.rules[*].matches`
`spec.rules[].http.paths[].backend.service`	`spec.rules[*].backendRefs`
`spec.tls`	`spec.listeners[*].tls`
`nginx.ingress.kubernetes.io/canary`	`spec.rules[].backendRefs[].weight`
`nginx.ingress.kubernetes.io/canary-by-header`	`spec.rules[].matches[].headers`

迁移示例

原 Ingress 配置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /api(/|$)(.*)
            pathType: ImplementationSpecific
            backend:
              service:
                name: api-service
                port:
                  number: 8080

迁移后的 Gateway API：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-route
spec:
  parentRefs:
    - name: example-gateway
  hostnames:
    - example.com
  rules:
    - matches:
        - path:
            type: RegularExpression
            value: /api(/|$)(.*)
      backendRefs:
        - name: api-service
          port: 8080
      filters:
        - type: URLRewrite
          urlRewrite:
            path:
              type: ReplacePrefixMatch
              replacePrefixMatch: /$2

总结与展望

Gateway API v1 的优势

标准化：跨控制器的一致 API，提高可移植性
角色分离：清晰的多团队协作模型
生产就绪：GA 版本提供稳定性保障
功能丰富：支持 gRPC、TLS、会话保持等高级特性
面向未来：可扩展架构支持未来协议

何时使用 Gateway API

场景	推荐
新项目部署	✅ Gateway API
多团队共享网关	✅ Gateway API
需要 gRPC 路由	✅ Gateway API
复杂流量管理	✅ Gateway API
简单 HTTP 路由	⚠️ Ingress 足够
已有 Ingress 投资	⚠️ 渐进迁移

未来发展

Gateway API 路线图：

v1.1：Enhanced Telemetry（增强可观测性）
v1.2：Mesh integration（Service Mesh 集成）
未来：WAF integration、Rate limiting 标准化

参考资源

Gateway API 官方文档: https://gateway-api.sigs.k8s.io/
Envoy Gateway 文档: https://gateway.envoyproxy.io/
Gateway API v1.0.0 发布公告: https://kubernetes.io/blog/2024/11/
实现对比: https://gateway-api.sigs.k8s.io/implementations/
从 Ingress 迁移指南: https://gateway-api.sigs.k8s.io/guides/migrating-from-ingress/