K8s Gateway API 详解 – wiki词典

作者： /

K8s Gateway API 详解

I. 引言

Kubernetes 已成为容器编排的事实标准，但在管理集群外部流量方面，其内置的 Ingress API 长期以来暴露出一些局限性。Ingress 主要侧重于 HTTP/HTTPS 路由，其功能表达能力相对有限，难以支持更复杂的流量管理场景（如流量分发、协议转换、细粒度策略控制等），且供应商实现碎片化，缺乏标准化的扩展机制。

为了解决这些挑战，并为 Kubernetes 带来下一代流量管理能力，Gateway API 应运而生。Gateway API 旨在提供一个更具表现力、可扩展性强的标准化接口，用于配置各种网关（如负载均衡器、代理、API 网关），以更灵活、更安全地管理进入和离开 Kubernetes 集群的流量。它不仅仅是 Ingress 的简单替代品，更是一种全新的、面向角色的流量管理模型，将基础设施操作者、集群管理员和应用开发者清晰地分离，极大地提升了流量配置的灵活性和可治理性。

Gateway API 的核心优势在于其强大的表达能力、灵活的扩展性以及对角色分离的良好支持，使其能够更好地满足现代微服务架构和复杂网络环境的需求。

II. Gateway API 核心概念

Gateway API 引入了一系列新的自定义资源定义 (CRDs)，它们共同构成了一个分层的流量管理模型。理解这些核心概念是掌握 Gateway API 的关键。

A. GatewayClass: 定义网关的类型和能力

GatewayClass 资源是 Gateway API 的基础设施配置层。它由集群管理员或基础设施提供商定义，用于描述一类网关实现（例如 NGINX Gateway、Istio、Contour 等）的通用特性和配置模板。一个 GatewayClass 实例通常会关联一个特定的控制器，该控制器负责处理属于此 GatewayClass 的所有 Gateway 资源。

  • 控制平面 (Control Plane) 与数据平面 (Data Plane): GatewayClass 隐式地定义了将要被配置的数据平面（实际处理流量的代理）的类型，以及控制平面（负责将 Gateway API 资源转换为数据平面配置的控制器）。
  • 实现者 (Implementer): spec.controllerName 字段指定了负责实现该 GatewayClass 的控制器名称。例如，example.com/gateway-controller。

B. Gateway: 流量的入口点，监听端口和协议

Gateway 资源是集群中实际流量的入口点。它由集群操作员创建和管理，用于指定网关的监听地址、端口、协议以及 TLS 配置。一个 Gateway 资源会引用一个 GatewayClass，从而继承该 GatewayClass 定义的底层网关实现。

  • Namespace 隔离与权限: Gateway 资源通常部署在一个特定的命名空间，并可以控制哪些 Route 资源可以绑定到它。这允许应用开发者在自己的命名空间中定义路由规则，但不能直接暴露端口或配置网关基础设施。
  • 引用 GatewayClass: spec.gatewayClassName 字段指定了该 Gateway 实例所使用的 GatewayClass。
  • 监听器 (Listeners): spec.listeners 字段定义了网关监听的协议、端口和主机名，以及可选的 TLS 配置。

C. Route 资源: 定义流量路由规则

Route 资源是 Gateway API 中最灵活和最常用的部分，由应用开发者或团队管理。它们定义了如何将来自 Gateway 的流量路由到后端服务。Gateway API 提供了多种 Route 类型，以支持不同协议的流量：

  1. HTTPRoute: 用于 HTTP 和 HTTPS 流量的路由规则。它是最丰富和最常用的 Route 类型，提供了强大的流量管理能力。

    • 匹配规则 (Matching rules):
      • hostnames: 根据请求的主机头进行匹配。
      • path: 根据请求路径进行匹配（前缀匹配、精确匹配、正则表达式匹配）。
      • headers: 根据请求头进行匹配。
      • queryParams: 根据请求查询参数进行匹配。
    • 流量转发 (Traffic forwarding):
      • backendRefs: 将流量转发到一个或多个 Kubernetes Service 或其他后端端点。
      • weight: 支持将流量按比例分发到多个后端服务，实现金丝雀发布、蓝绿部署等。
    • 流量控制 (Traffic control):
      • redirect: 将请求重定向到其他 URL。
      • rewrite: 重写请求的 Host 或 Path。
      • filters: 支持更高级的流量处理，如请求/响应头修改、认证、限速等。

  2. TLSRoute: 用于传输层安全 (TLS) 流量的路由。它允许在 TLS 握手完成后根据 SNI (Server Name Indication) 路由加密流量，通常用于需要透传原始 TCP 连接的场景，例如数据库连接。

  3. TCPRoute: 用于通用 TCP 流量的路由。它允许基于目标端口将原始 TCP 连接路由到后端服务。适用于非 HTTP/HTTPS 协议的 TCP 应用程序。

  4. UDPRoute: 用于通用 UDP 流量的路由。它允许基于目标端口将 UDP 数据包路由到后端服务。适用于非 HTTP/HTTPS 协议的 UDP 应用程序，如 DNS、日志传输等。

  5. GRPCRoute: (在 Gateway API 的发展中是一个重要的补充，目前已 GA)。专为 gRPC 流量设计。由于 gRPC 基于 HTTP/2 协议，且其特有的服务、方法和头信息处理方式，GRPCRoute 提供了更细致的 gRPC 流量匹配和路由能力。

D. Policy Attachment: 扩展和增强网关功能

Gateway API 支持通过策略附件模型（Policy Attachment）来扩展和增强网关功能。这意味着可以在不同层级（GatewayClass、Gateway、Route 甚至更细粒度的资源）附加自定义策略，例如：

  • 请求/响应操作 (Request/Response Manipulation)
  • 认证和授权 (Authentication and Authorization)
  • 限流 (Rate Limiting)
  • 熔断 (Circuit Breaking)
  • 可观测性配置 (Observability Configuration)

这些策略通过独立的 CRDs 定义，并通过标准的 Policy 资源附加到 Gateway API 的核心资源上，实现了功能与核心配置的解耦，提高了可插拔性和扩展性。

III. Gateway API 的工作原理和优势

Gateway API 不仅是一组新的 CRDs，它更是一种全新的流量管理范式，其设计理念和工作原理带来了显著的优势。

A. 协调控制器 (Coordinating Controllers)

Gateway API 的核心工作原理是基于协调控制器模式。不同的 Gateway 实现（例如 NGINX, Envoy, Istio 等）会部署一个或多个控制器来监听 Gateway API 资源的变化。当这些资源被创建、更新或删除时，控制器会响应这些事件，并将其翻译成底层数据平面（即实际的代理服务器或负载均衡器）的配置。这种解耦的设计使得 Gateway API 成为一个通用的接口，而具体的实现细节则由不同的供应商控制器负责。

B. 资源层级结构 (Hierarchical Resource Structure)

Gateway API 采用分层的资源模型，这反映了不同角色在流量管理中的职责分离：

  1. GatewayClass (基础设施提供商)：定义了网关实现的通用模板和能力，由基础设施团队或集群管理员维护。
  2. Gateway (集群操作员)：创建和管理实际的网关实例，负责其生命周期、监听端口和 TLS 配置，并指定使用哪个 GatewayClass。
  3. Route (应用开发者)：定义了具体的流量路由规则，将请求从 Gateway 转发到后端服务。开发者可以独立管理自己的路由规则，无需关注底层网关的部署细节。

这种层级结构确保了职责的清晰划分，避免了单一巨型配置文件的复杂性，并提高了安全性。

C. 角色分离 (Role Separation)

Gateway API 的设计理念之一是实现清晰的角色分离，这极大地改善了流量管理的协作效率和安全性：

  • 基础设施提供商 (Infrastructure Provider)：负责提供和管理 GatewayClass，定义可用的网关类型和底层实现。
  • 集群操作员 (Cluster Operator)：负责部署和配置 Gateway 资源，管理网关的生命周期、暴露的端口和公共 IP，并确保网关的正常运行。他们控制了流量的入口点。
  • 应用开发者 (Application Developer)：负责创建和管理 HTTPRoute、TLSRoute 等 Route 资源，定义其应用程序的流量路由规则。他们拥有对应用流量的细粒度控制，但不能影响网关的基础设施。

这种分离允许每个角色专注于自己的核心任务，减少了误配置的风险，并提升了整体的治理能力。

D. Gateway API 的核心优势总结

  1. 更强大的表达能力 (More Expressive Capabilities): 相比 Ingress，Gateway API 提供了对 HTTP 请求更细致的控制（如更丰富的匹配规则、请求/响应头修改、URL 重写、流量加权等），并支持 TCP/UDP/TLS/gRPC 等多种协议，极大地扩展了流量管理的场景。
  2. 更强的可扩展性 (Enhanced Extensibility): 通过 GatewayClass 和策略附件机制，Gateway API 可以无缝地集成各种第三方网关实现，并支持自定义的流量管理策略，而无需修改核心 API。
  3. 标准化的多协议支持 (Standardized Multi-Protocol Support): Ingress 几乎只支持 HTTP/HTTPS，而 Gateway API 从设计之初就考虑了多种协议，提供了统一的 API 接口来管理不同类型的流量。
  4. 清晰的角色分离 (Clear Role Separation): 分层的资源模型自然地将基础设施、集群操作和应用开发职责区分开来，提升了大型团队协作的效率和安全性。
  5. 供应商中立性 (Vendor Neutrality): Gateway API 提供了一个通用的接口，避免了 Ingress API 中因供应商实现差异而导致的配置碎片化问题，使得用户可以更轻松地切换不同的网关实现。
  6. 高级流量管理特性 (Advanced Traffic Management Features): 内置对金丝雀发布、蓝绿部署、A/B 测试等高级流量管理模式的支持，使得实施这些策略变得更加简单。

IV. 使用 Gateway API 示例

为了更好地理解 Gateway API 的实际应用，我们来看一个简单的 HTTP 路由示例。

假设我们有一个 example.com 域名的 Web 应用程序，其中包含两个服务：webapp-v1 和 webapp-v2。我们希望将所有对 example.com 的请求路由到 webapp-v1，并将所有对 example.com/api 的请求路由到 webapp-v2。

在开始之前，我们需要确保集群中已经安装了 Gateway API CRDs，并且部署了一个兼容 Gateway API 的实现（例如 Envoy Gateway, NGINX Gateway 或 Istio 等）。

1. 定义 GatewayClass (由基础设施提供商/集群管理员创建一次)

首先，定义一个 GatewayClass 来声明我们要使用的网关实现。这里我们假设使用的是一个名为 example-gateway-controller 的控制器。

yaml
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: my-gateway-class
spec:
controllerName: example.com/gateway-controller # 替换为实际的控制器名称
parametersRef:
group: config.example.com
kind: GatewayConfig
name: default-config

2. 创建 Gateway (由集群操作员创建)

接下来，创建一个 Gateway 实例，它引用了 my-gateway-class 并监听 HTTP 流量。

yaml
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: my-gateway
namespace: default
spec:
gatewayClassName: my-gateway-class
listeners:
- name: http
protocol: HTTP
port: 80
hostname: "example.com" # 网关将响应 example.com 的请求

应用此 Gateway 资源后，底层的网关实现（由 example.com/gateway-controller 管理）会部署一个负载均衡器或代理，并开始监听 example.com 的 80 端口。

3. 定义 HTTPRoute (由应用开发者创建)

现在，应用开发者可以定义 HTTPRoute 来指定流量如何路由到后端服务。

yaml
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: example-app-route
namespace: default
spec:
parentRefs: # 关联到之前创建的 Gateway
- name: my-gateway
namespace: default # 确保 Gateway 和 HTTPRoute 在同一个 namespace 或有权限访问
hostnames:
- "example.com"
rules:
- matches:
- path:
type: PathPrefix
value: /api # 匹配所有以 /api 开头的路径
backendRefs:
- name: webapp-v2 # 路由到 webapp-v2 Service
port: 80
- matches:
- path:
type: PathPrefix
value: / # 匹配所有其他路径
backendRefs:
- name: webapp-v1 # 路由到 webapp-v1 Service
port: 80

在这个 HTTPRoute 配置中：
* parentRefs 将此路由绑定到 my-gateway。
* hostnames 指定了此路由适用于 example.com。
* 第一个 rule 匹配所有以 /api 开头的请求，并将其转发到 webapp-v2 服务。
* 第二个 rule 规则匹配所有其他请求（即 / 前缀），并将其转发到 webapp-v1 服务。由于规则是按顺序评估的，所以 /api 的规则会优先于 / 的规则。

K8s Ingress 与 Gateway API 对比的简要体现:

通过上述示例可以看出，Gateway API 的分层设计提供了更高的灵活性和更清晰的职责分离。
* Ingress: 通常将网关的部署细节、端口监听、主机配置以及路由规则混杂在一个 Ingress 资源中，或者需要通过 IngressClass 和大量注解来扩展，导致配置复杂且难以维护。
* Gateway API: 将基础设施配置 (GatewayClass)、网关实例 (Gateway) 和应用路由 (HTTPRoute) 分开，使得不同角色可以专注于各自的配置，降低了配置的复杂性，并提供了更原生的扩展机制（如 Policy Attachment），而无需依赖大量的非标准注解。这使得高级流量管理（如复杂的流量分发、协议转换、细粒度策略）的实现更加直观和标准化。

V. 总结与展望

Gateway API 不仅仅是 Kubernetes Ingress 的一个升级，它代表了 Kubernetes 流量管理领域的一次重大飞跃。通过其分层的资源模型、清晰的角色分离、强大的表达能力和卓越的扩展性，Gateway API 解决了一系列 Ingress 长期存在的痛点。它提供了一个标准化、供应商中立的框架，使得在 Kubernetes 中配置和管理复杂的网关和路由规则变得更加高效和可控。

随着云原生技术栈的不断成熟，微服务架构和分布式系统对流量管理提出了越来越高的要求。Gateway API 凭借其对多协议支持、高级流量控制策略以及与不同网关实现无缝集成的能力，正迅速成为 Kubernetes 生态系统中管理南北向（North-South）和东西向（East-West）流量的首选方案。

展望未来，Gateway API 将继续演进，可能进一步增强对服务网格（Service Mesh）集成的支持、更丰富的安全策略配置，以及与更多云服务提供商和开源项目的深度融合。对于任何在 Kubernetes 上构建和运行应用程序的组织而言，理解和采纳 Gateway API 都将是提升其流量管理能力和运营效率的关键一步。它为 Kubernetes 用户提供了一个更强大、更灵活、更面向未来的流量管理平台。

滚动至顶部