网关 API

Gateway API 是一系列 API 类型,提供动态基础设施配置和高级流量路由。

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

设计原则

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

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

资源模型

Gateway API 有三种稳定的 API 类型

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

  • Gateway: 定义流量处理基础设施的实例,例如云负载均衡器。

  • HTTPRoute: 定义 HTTP 特定的规则,用于将来自网关侦听器的流量映射到后端网络端点的表示形式。这些端点通常表示为 服务

Gateway API 被组织成不同的 API 类型,这些类型具有相互依赖的关系,以支持组织的面向角色的性质。网关对象与一个且仅一个 GatewayClass 相关联;GatewayClass 描述了负责管理该类网关的网关控制器。然后,一个或多个路由类型(例如 HTTPRoute)与网关相关联。网关可以过滤可能附加到其“侦听器”的路由,从而与路由形成双向信任模型。

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

A figure illustrating the relationships of the three stable Gateway API kinds

GatewayClass

网关可以由不同的控制器实现,通常具有不同的配置。网关必须引用一个 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。该类的网关将由实现的控制器管理。

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

网关

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

一个最小的网关资源示例

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 流量。由于“地址”字段未指定,因此实现的控制器会为网关分配一个地址或主机名。此地址用作处理路由中定义的后端网络端点的流量的网络端点。

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

HTTPRoute

HTTPRoute 类型指定了从网关侦听器到后端网络端点的 HTTP 请求的路由行为。对于服务后端,实现可以将后端网络端点表示为服务 IP 或服务的支持端点。HTTPRoute 表示应用于底层网关实现的配置。例如,定义新的 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

在此示例中,来自网关“example-gateway”的 HTTP 流量(Host: 标头设置为“www.example.com”且请求路径指定为“/login”)将被路由到端口“8080”上的服务“example-svc”。

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

请求流程

下面是一个简单的示例,说明了如何使用网关和 HTTPRoute 将 HTTP 流量路由到服务

A diagram that provides an example of HTTP traffic being routed to a Service by using a Gateway and an HTTPRoute

在此示例中,作为反向代理实现的网关的请求流程如下

  1. 客户端开始为 URL“http://www.example.com”准备 HTTP 请求
  2. 客户端的 DNS 解析器查询目标名称,并了解到与网关关联的一个或多个 IP 地址的映射。
  3. 客户端向网关 IP 地址发送请求;反向代理接收 HTTP 请求,并使用 Host: 标头匹配从网关和附加的 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 本身实现的,而是将规范定义为 自定义资源,并由各种 实现 支持。 安装 Gateway API CRD 或按照所选实现的安装说明进行操作。安装实现后,请使用 入门 指南来帮助您快速开始使用 Gateway API。

有关所有 Gateway API 类型的其他详细信息,请参阅 API 规范

上次修改时间:2024 年 1 月 1 日下午 9:15 PST:修复多个链接错误 (8b46ec4047)