Gateway API

通过使用可扩展、面向角色、感知协议的配置机制，使网络服务可用。Gateway API 是一个包含 API 类型的附加组件（add-on），这些类型提供了动态基础设施配置和高级流量路由。

设计原则

以下原则塑造了 Gateway API 的设计和架构

• 面向角色： Gateway API 类型根据负责管理 Kubernetes 服务网络的组织角色进行建模
  • 基础设施提供商： 管理基础设施，允许多个隔离的集群为多个租户提供服务，例如云提供商。
  • 集群操作员： 管理集群，通常关注策略、网络访问、应用权限等。
  • 应用开发者： 管理运行在集群中的应用，通常关注应用级配置和 Service 组合。
• 可移植： Gateway API 规范被定义为 Custom Resources，并得到许多实现的支持。
• 富有表现力： Gateway API 类型支持常见流量路由用例的功能，例如基于头的匹配、流量加权以及其他仅在 Ingress 中通过使用自定义注解才能实现的功能。
• 可扩展： Gateway 允许在 API 的各个层链接自定义资源。这使得在 API 结构中的适当位置进行细粒度定制成为可能。

资源模型

Gateway API 有三种稳定的 API 类型

• GatewayClass： 定义一组具有通用配置并由实现该类的控制器管理的网关。

• Gateway： 定义一个流量处理基础设施实例，例如云负载均衡器。

• HTTPRoute： 定义 HTTP 特定的规则，用于将来自 Gateway 监听器的流量映射到后端网络端点的表示。这些端点通常表示为 Service。

Gateway API 组织成不同的 API 类型，这些类型具有相互依赖的关系，以支持组织的面向角色的特性。一个 Gateway 对象只关联一个 GatewayClass；GatewayClass 描述了负责管理此类 Gateway 的网关控制器。然后，一种或多种路由类型（例如 HTTPRoute）与 Gateway 关联。Gateway 可以过滤可能附加到其 listeners 的路由，与路由形成双向信任模型。

下图展示了三种稳定的 Gateway API 类型之间的关系

GatewayClass

Gateways 可以由不同的控制器实现，通常具有不同的配置。Gateway 必须引用一个包含实现该类的控制器名称的 GatewayClass。

一个极简的 GatewayClass 示例

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: example-class
spec:
  controllerName: example.com/gateway-controller

在此示例中，已实现 Gateway API 的控制器被配置为管理控制器名称为 example.com/gateway-controller 的 GatewayClass。属于此类的 Gateways 将由实现方的控制器管理。

有关此 API 类型的完整定义，请参阅 GatewayClass 参考。

Gateway

Gateway 描述一个流量处理基础设施实例。它定义了一个可用于处理流量的网络端点，例如对 Service 等后端进行过滤、负载均衡、流量拆分等。例如，Gateway 可以代表一个云负载均衡器或一个配置为接受 HTTP 流量的集群内代理服务器。

一个极简的 Gateway 资源示例

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-class
  listeners:
  - name: http
    protocol: HTTP
    port: 80

在此示例中，流量处理基础设施的一个实例被编程为监听端口 80 上的 HTTP 流量。由于未指定 addresses 字段，实现方的控制器会为 Gateway 分配一个地址或主机名。此地址将用作网络端点，用于处理在路由中定义的后端网络端点的流量。

有关此 API 类型的完整定义，请参阅 Gateway 参考。

HTTPRoute

HTTPRoute 类型指定了将 HTTP 请求从 Gateway 监听器路由到后端网络端点的行为。对于 Service 后端，实现可以将后端网络端点表示为 Service IP 或 Service 的后备 EndpointSlices。HTTPRoute 表示应用于底层 Gateway 实现的配置。例如，定义一个新的 HTTPRoute 可能会导致在云负载均衡器或集群内代理服务器中配置额外的流量路由。

一个极简的 HTTPRoute 示例

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: example-httproute
spec:
  parentRefs:
  - name: example-gateway
  hostnames:
  - "www.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /login
    backendRefs:
    - name: example-svc
      port: 8080

在此示例中，来自 Gateway example-gateway 且 Host: 头被设置为 www.example.com 并且请求路径被指定为 /login 的 HTTP 流量将被路由到 Service example-svc 的端口 8080。

有关此 API 类型的完整定义，请参阅 HTTPRoute 参考。

请求流程

以下是使用 Gateway 和 HTTPRoute 将 HTTP 流量路由到 Service 的一个简单示例

在此示例中，作为反向代理实现的 Gateway 的请求流程如下：

1. 客户端开始准备对 URL http://www.example.com 的 HTTP 请求。
2. 客户端的 DNS 解析器查询目标名称，并获知与 Gateway 相关联的一个或多个 IP 地址的映射关系。
3. 客户端将请求发送到 Gateway IP 地址；反向代理接收 HTTP 请求并使用 Host: 头来匹配从 Gateway 及其关联的 HTTPRoute 派生的配置。
4. （可选）反向代理可以根据 HTTPRoute 的匹配规则执行请求头和/或路径匹配。
5. （可选）反向代理可以根据 HTTPRoute 的过滤规则修改请求；例如，添加或移除请求头。
6. 最后，反向代理将请求转发到一个或多个后端。

一致性

Gateway API 涵盖了广泛的功能集，并且得到了广泛的实现。这种组合需要清晰的一致性定义和测试，以确保 API 在任何使用它的地方都能提供一致的体验。

请参阅一致性文档，以了解发布渠道、支持级别和运行一致性测试等详细信息。

从 Ingress 迁移

Gateway API 是 Ingress API 的后继者。然而，它不包含 Ingress 类型。因此，需要将您现有的 Ingress 资源一次性转换为 Gateway API 资源。

有关将 Ingress 资源迁移到 Gateway API 资源的详细信息，请参阅Ingress 迁移指南。

下一步

Gateway API 资源并非由 Kubernetes 原生实现，而是定义为由各种实现支持的 Custom Resources。请安装 Gateway API CRD 或遵循您所选实现提供的安装说明。安装某个实现后，请使用入门指南，帮助您快速开始使用 Gateway API。

有关所有 Gateway API 类型的更多详细信息，请参阅API 规范。