迈向下一代K8S流量管理：全面解析Gateway API

一个由角色分离、多协议支持、跨命名空间路由构建的标准化K8S网络新时代已经来临，彻底解决Ingress API面临的现实困境。

K8S系列之3.3：下一代流量标准（Gateway API 详解）

一、Ingress API的局限：为什么需要新一代API？

Kubernetes Ingress API自诞生以来，一直是暴露HTTP/HTTPS流量的主要方式。它提供了基本的路由功能：基于主机名和URL路径的流量转发、TLS终止等。不过，随着微服务架构和云原生实践的深入，Ingress API逐渐显露出其根本性不足。

1.1 核心设计缺陷

Ingress API最初的设计假设是 “一个集群，一个Ingress控制器” 。这一假设在多团队、大规模生产环境中变得不再适用。具体表现为：

角色混乱：单个Ingress资源同时包含基础设施配置（如TLS证书）和业务路由规则，迫使运维和开发人员操作同一份资源，缺乏清晰的职责边界。
功能表达有限：原生仅支持最基础的基于主机头和URI的HTTP路由，复杂的流量管理功能（如权重分流、请求头修改）高度依赖各控制器厂商特定的注解（Annotations）。这不仅导致了“注解地狱”，更严重削弱了配置的可移植性。

# 典型的Ingress配置示例：混合了路由规则和特定于Nginx的注解
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/configuration-snippet: |
      proxy_set_header X-Custom-Header "value"
    # 其他几十行特定实现的注解...
spec:
  tls:
  - hosts:
      - app.example.com
    secretName: tls-secret
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

扩展性差：Ingress API本身的扩展点极少，高级功能的唯一实现途径是注解，这是一种非结构化、易出错的扩展方式。
多租户支持薄弱：难以在一个集群中为不同团队安全地共享和隔离网关基础设施。

K8S系列之3.3：下一代流量标准（Gateway API 详解）

1.2 Gateway API的诞生使命

正是为了解决这些痛点，Kubernetes SIG-Network社区推出了Gateway API，它被明确设计为Ingress API的继任者（successor）。其核心设计目标可以概括为以下四点：

面向角色（Role-Oriented）：API资源的设计与使用Kubernetes的组织角色（如基础设施提供商、集群运维、应用开发者）保持一致。
富有表现力（Expressive）：原生支持灰度发布、流量加权、基于标头/方法/查询参数的路由等高级功能，无需依赖实现特定的注解。
可扩展（Extensible）：提供结构化的扩展点（如策略附件Policy Attachment、外部引用），允许在API各层进行细粒度定制。
可移植（Portable）：作为一个通用规范，得到众多供应商和开源项目（如Istio、Nginx Gateway Fabric、AWS ALB Controller等）的广泛实现，确保配置在不同环境间具备可移植性。

二、Gateway API vs. Ingress：核心理念的革新

Gateway API不仅仅是一次功能升级，更是一次网络流量治理范式的转变。它与Ingress的核心差异体目前三个层面：

2.1 从单体资源到分层抽象

Ingress API将所有配置塞进一个资源。Gateway API则通过分层资源模型实现了职责分离：

GatewayClass：定义一类网关的蓝图，由特定控制器实现（类比StorageClass）。
Gateway：由集群运维或平台团队管理，定义流量入口点（监听器、端口、协议、TLS证书）和准入策略。
Route（如HTTPRoute）*：由应用开发者管理，定义具体的流量路由规则，并将其“附着”（attach）到Gateways上。

2.2 从注解到结构化API

Gateway API将Ingress中通过注解实现的许多功能标准化为API字段。

例如，流量拆分在Ingress中一般需要特定于控制器的注解，而在Gateway API中则是一个标准字段：

# Gateway API HTTPRoute 中的流量拆分（权重路由）
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: canary-route
spec:
  parentRefs:
  - name: my-gateway
  rules:
  - backendRefs:
    - name: stable-service
      port: 8080
      weight: 90  # 90%流量到稳定版
    - name: canary-service
      port: 8080
      weight: 10  # 10%流量到金丝雀版

2.3 从集群级隔离到细粒度多租户

Ingress难以实现安全的多租户。Gateway API通过 allowedRoutes 机制，允许Gateway管理者准确控制哪些命名空间或携带特定标签的资源可以将路由附加到网关上，实现了基础设施共享与租户隔离的平衡。

# Gateway中通过命名空间选择器控制路由附加权限
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shared-infra-gateway
spec:
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    allowedRoutes:
      namespaces:
        from: Selector
        selector:
          matchLabels:
            gateway-access: "enabled" # 只允许带此标签的命名空间

为了方便您从宏观上快速把握二者的核心差异，可以参考下表：

特性维度	Ingress API	Gateway API
核心抽象	单一Ingress资源	分层模型 (GatewayClass, Gateway, Route)
职责分离	弱，配置混合	强，面向不同角色（运维、开发）
功能扩展	主要依赖非结构化注解	结构化扩展点（策略、过滤器）
多租户支持	弱，基于RBAC的粗粒度控制	强，通过 allowedRoutes 细粒度控制
协议支持	主要为HTTP/HTTPS	原生支持HTTP、HTTPS、gRPC、TCP、TLS、UDP等
跨命名空间	支持但不够直观和安全	原生、安全地支持
状态反馈	有限	丰富的资源状态（status）字段

三、核心资源模型：面向角色的架构设计

Gateway API的精髓在于其面向角色的资源模型，它将网络配置的控制权安全地分配给组织中的不同角色。

3.1 资源层级与角色映射

Gateway API主要包含以下几种核心资源类型：

GatewayClass

作用：定义一类网关的共享配置和使用的控制器。
管理者：基础设施提供商（如云厂商）或集群管理员。
示例：创建名为 internet-facing-lb 的GatewayClass，指向阿里云或AWS的负载均衡器控制器。

Gateway

作用：根据GatewayClass创建的一个具体的网关实例。它声明了 “我想要一个监听在80和443端口的负载均衡器”。
管理者：集群运维人员或应用程序管理员。
示例：在 infra 命名空间创建 prod-gateway，配置TLS证书和监听器。

HTTPRoute / GRPCRoute / TCPRoute 等

作用：描述如何将到达Gateway的流量路由到集群内的后端服务（Service）。
管理者：应用程序开发者。
示例：在 app-team-a 命名空间创建 httproute-frontend，将所有 /api/* 的请求路由到 backend-service。

3.2 HTTPRoute：下一代路由规则的核心

HTTPRoute 是Gateway API中最常用的路由资源，其表达能力远超Ingress。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: advanced-httproute
spec:
  parentRefs:
  - name: sample-gateway # 关联到哪个Gateway
    namespace: ingress-ns
  hostnames:
  - "app.example.com" # 匹配的域名
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /store
      headers:
      - name: x-canary
        value: enable
      queryParams:
      - name: debug
        value: "true"
    filters:
    - type: RequestHeaderModifier
      requestHeaderModifier:
        add:
        - name: x-request-id
          value: "generated-uuid"
    backendRefs:
    - name: canary-store-service
      port: 8080
      weight: 10
  - matches:
    - path:
        type: PathPrefix
        value: /store
    backendRefs:
    - name: store-service # 默认后端
      port: 8080
      weight: 90

一个 HTTPRoute 的核心结构包括：

parentRefs：指定此路由附加到哪个（些）Gateway。
hostnames：匹配请求的Host头。
rules：路由规则数组，按定义顺序匹配。
matches：丰富的匹配条件（路径、请求头、查询参数、HTTP方法）。
filters：对请求或响应的处理（修改头、重定向、重写、流量镜像等）。
backendRefs：转发到的后端服务，支持权重和细化端口。

四、跨命名空间路由与GAMMA：统一服务网格流量

Gateway API的设计使其天生具备跨命名空间引用的能力，这为统一管理集群内外的流量（即南北向流量）和集群内的服务间流量（即东西向流量）奠定了基础。

4.1 安全的跨命名空间路由

跨命名空间路由是Gateway API支持多租户的关键。应用开发者可以在自己的命名空间中创建HTTPRoute，通过 parentRefs 字段引用其他命名空间（如共享基础设施命名空间）中的Gateway。

# 在应用团队命名空间创建路由，指向共享网关
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: team-a-route
  namespace: team-a-namespace
spec:
  parentRefs:
  - name: shared-gateway # 共享网关
    namespace: infra-namespace # 网关在另一个命名空间
  rules:
  - backendRefs:
    - name: team-a-service # 后端服务在当前命名空间
      port: 80

为了确保这种跨命名空间引用的安全性，Gateway API提供了 ReferenceGrant 资源，它类似于一个“引用授权书”，必须由被引用资源所在命名空间的管理员创建，明确允许来自其他特定命名空间的引用。

4.2 GAMMA：Gateway API与服务网格的融合

服务网格（如Istio、Linkerd）主要管理东西向流量，一般使用自己的API（如Istio的VirtualService 和 Gateway）。这导致了南北向（Gateway API）和东西向（服务网格API）流量管理使用两套不同的API，增加了复杂性和学习成本。

为了解决这个问题，社区发起了 GAMMA（Gateway API for Mesh Management and Administration）倡议。GAMMA的目标是扩展Gateway API，使其也能用于配置服务网格内的东西向流量。

GAMMA的核心思想是：允许HTTPRoute等路由资源直接引用Kubernetes Service 作为其父级，而不仅仅是Gateway。这样，同一个 HTTPRoute 资源既可以用于配置从网关到服务的入口流量，也可以用于配置从服务A到服务B的内部流量。

# 使用GAMMA扩展的HTTPRoute配置东西向流量
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: reviews-mesh-route
  namespace: bookinfo
spec:
  parentRefs:
  - kind: Service # 父引用是一个Service，而非Gateway
    name: reviews
    port: 9080
  rules:
  - matches:
    - headers:
      - name: end-user
        value: premium
    backendRefs:
    - name: reviews-v2
      port: 9080
  - backendRefs:
    - name: reviews-v1
      port: 9080
      weight: 50
    - name: reviews-v3
      port: 9080
      weight: 50

这意味着，未来开发人员可能只需要掌握Gateway API这一套语义清晰的API，就能管理所有进出和流经集群的流量，实现流量管理API的真正统一。

五、实践：从零开始使用Gateway API

K8S系列之3.3：下一代流量标准（Gateway API 详解）

5.1 安装与部署

Gateway API以CRD（CustomResourceDefinition）的形式提供，大多数Kubernetes发行版默认不安装。需要手动安装CRD和对应的控制器实现。

# 1. 安装Gateway API CRDs
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.3.0/standard-install.yaml

# 2. 安装一个Gateway API实现（例如Nginx Gateway Fabric）
# 具体安装步骤请参考对应实现的官方文档

# 3. 创建一个GatewayClass
kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: nginx-gateway-class
spec:
  controllerName: gateway.nginx.org/controller
EOF

5.2 从Ingress迁移到Gateway API

迁移一般是一个渐进的过程。社区提供了 ingress2gateway 等工具来协助自动化转换基本的路由规则。不过，迁移的核心挑战在于如何处理原来依赖的各种控制器特定注解。

迁移策略提议：

评估：梳理现有Ingress资源中使用的所有注解，区分哪些是标准Ingress功能，哪些是厂商扩展。
映射：将标准功能映射到Gateway API的对应字段（如主机名、路径、TLS）。对于厂商扩展，查阅你选用的Gateway API实现文档，看其是否支持以及如何通过策略附件等扩展点配置。
并行运行与切流：在迁移期间，可以同时运行Ingress Controller和Gateway API控制器，通过DNS权重或负载均衡器逐步将流量从旧端点切换到新端点。
利用云厂商工具：一些云服务商（如阿里云）提供了白屏化的迁移工具，协助用户从自建的Nginx Ingress平滑迁移到其托管的、支持Gateway API的云原生网关产品。