本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。

使用 Gateway API 演进 Kubernetes 网络

作者：Mark Church (Google)、Harry Bagdi (Kong)、Daneyon Hanson (Red Hat)、Nick Young (VMware)、Manuel Zapf (Traefik Labs) | 2021 年 4 月 22 日星期四

Ingress 资源是 Kubernetes 众多成功案例之一。它创建了一个多样化的 Ingress 控制器生态系统，这些控制器以标准化和一致的方式在数十万个集群中使用。这种标准化帮助用户采用了 Kubernetes。然而，在 Ingress 创建五年后，出现了碎片化的迹象，分裂成不同但惊人相似的 CRD 和过载的注解。Ingress 普及的同样的可移植性也限制了它的未来。

在 2019 年圣地亚哥 Kubecon 大会上，一群热情的贡献者齐聚一堂，讨论Ingress 的演变。讨论一直持续到街对面的酒店大堂，由此产生的内容后来被称为 Gateway API。这次讨论基于几个关键假设：

路由匹配、流量管理和服务暴露的基础 API 标准已经商品化，作为自定义 API，它们对实现者和用户几乎没有价值
可以通过通用核心 API 资源表示 L4/L7 路由和流量管理
可以以不牺牲核心 API 用户体验的方式提供更复杂能力的扩展性

引入 Gateway API

这导致了设计原则，使得 Gateway API 能够在 Ingress 的基础上进行改进：

表达能力 - 除了 HTTP 主机/路径匹配和 TLS，Gateway API 还可以表达 HTTP 头操作、流量权重和镜像、TCP/UDP 路由等能力，这些能力在 Ingress 中只能通过自定义注解实现。
面向角色的设计 - API 资源模型反映了路由和 Kubernetes 服务网络中常见的职责分离。
可扩展性 - 资源允许在 API 中的各个层附加任意配置。这使得在最合适的位置进行细粒度定制成为可能。
灵活的一致性 - Gateway API 定义了不同的一致性级别——核心（强制支持）、扩展（如果支持则可移植）和自定义（不保证可移植性），统称为灵活的一致性。这促进了一个高度可移植的核心 API（如 Ingress），同时为 Gateway 控制器实现者提供了灵活性。

Gateway API 是什么样的？

Gateway API 引入了一些新的资源类型：

GatewayClasses 是集群范围的资源，充当模板，明确定义从它们派生的 Gateways 的行为。这在概念上类似于 StorageClasses，但用于网络数据平面。
Gateways 是 GatewayClasses 的已部署实例。它们是执行路由的数据平面的逻辑表示，可以是集群内代理、硬件负载均衡器或云负载均衡器。
路由 (Routes) 不是单一资源，而是代表许多不同的协议特定路由资源。HTTPRoute 具有匹配、过滤和路由规则，适用于可以处理 HTTP 和 HTTPS 流量的 Gateway。类似地，还有 TCPRoutes、UDPRoutes 和 TLSRoutes，它们也具有协议特定的语义。该模型还允许 Gateway API 在未来逐步扩展其协议支持。

The resources of the Gateway API

Gateway 控制器实现

好消息是，尽管 Gateway 处于 Alpha 阶段，但已经有几个Gateway 控制器实现可以运行。由于它是标准化的规范，以下示例可以在其中任何一个上运行，并且功能应该完全相同。请查看入门指南，了解如何安装和使用这些 Gateway 控制器之一。

动手使用 Gateway API

在下面的示例中，我们将演示不同 API 资源之间的关系，并引导您完成一个常见用例：

foo 团队将其应用程序部署在 foo 命名空间中。他们需要控制其应用程序不同页面的路由逻辑。
bar 团队在 bar 命名空间中运行。他们希望能够对其应用程序进行蓝绿发布以降低风险。
平台团队负责管理 Kubernetes 集群中所有应用程序的负载均衡器和网络安全。

以下 foo-route 对 foo 命名空间中的各种服务进行路径匹配，并有一个指向 404 服务器的默认路由。这通过 foo.example.com/login 和 foo.example.com/home 分别暴露 foo-auth 和 foo-home 服务。

kind: HTTPRoute
apiVersion: networking.x-k8s.io/v1alpha1
metadata:
  name: foo-route
  namespace: foo
  labels:
    gateway: external-https-prod
spec:
  hostnames:
  - "foo.example.com"
  rules:
  - matches:
    - path:
        type: Prefix
        value: /login
    forwardTo:
    - serviceName: foo-auth
      port: 8080
  - matches:
    - path:
        type: Prefix
        value: /home
    forwardTo:
    - serviceName: foo-home
      port: 8080
  - matches:
    - path:
        type: Prefix
        value: /
    forwardTo:
    - serviceName: foo-404
      port: 8080

在同一个 Kubernetes 集群的 bar 命名空间中运行的 bar 团队也希望将其应用程序暴露到互联网，但他们也希望控制自己的金丝雀和蓝绿发布。以下 HTTPRoute 配置了以下行为：

对于发往 bar.example.com 的流量
- 将 90% 的流量发送到 bar-v1
- 将 10% 的流量发送到 bar-v2
对于发往 bar.example.com 且 HTTP 头为 env: canary 的流量
- 将所有流量发送到 bar-v2

The routing rules configured for the bar-v1 and bar-v2 Services

kind: HTTPRoute
apiVersion: networking.x-k8s.io/v1alpha1
metadata:
  name: bar-route
  namespace: bar
  labels:
    gateway: external-https-prod
spec:
  hostnames:
  - "bar.example.com"
  rules:
  - forwardTo:
    - serviceName: bar-v1
      port: 8080
      weight: 90
    - serviceName: bar-v2
      port: 8080
      weight: 10
  - matches:
    - headers:
        values:
          env: canary
    forwardTo:
    - serviceName: bar-v2
      port: 8080

路由和 Gateway 绑定

因此，我们有两个 HTTPRoute 匹配并将流量路由到不同的服务。您可能想知道，这些服务在何处可访问？它们通过哪些网络或 IP 暴露？

路由如何暴露给客户端由路由绑定管理，它描述了路由和 Gateway 如何在彼此之间创建双向关系。当路由绑定到 Gateway 时，意味着它们的集体路由规则已在底层负载均衡器或代理上配置，并且可以通过 Gateway 访问路由。因此，Gateway 是可通过路由配置的网络数据平面的逻辑表示。

How Routes bind with Gateways

管理委托

Gateway 和 Route 资源之间的分离允许集群管理员将部分路由配置委托给各个团队，同时仍保留集中控制。以下 Gateway 资源在端口 443 上暴露 HTTPS，并使用集群管理员控制的证书终止该端口上的所有流量。

kind: Gateway
apiVersion: networking.x-k8s.io/v1alpha1
metadata:
  name: prod-web
spec:
  gatewayClassName: acme-lb
  listeners:  
  - protocol: HTTPS
    port: 443
    routes:
      kind: HTTPRoute
      selector:
        matchLabels:
          gateway: external-https-prod
      namespaces:
        from: All
    tls:
      certificateRef:
        name: admin-controlled-cert

以下 HTTPRoute 展示了路由如何通过其 kind (HTTPRoute) 和资源标签 (gateway=external-https-prod) 确保其匹配 Gateway 的选择器。

# Matches the required kind selector on the Gateway
kind: HTTPRoute
apiVersion: networking.x-k8s.io/v1alpha1
metadata:
  name: foo-route
  namespace: foo-ns
  labels:

    # Matches the required label selector on the Gateway
    gateway: external-https-prod
...

面向角色的设计

当您将所有这些结合在一起时，您将拥有一个可以安全地由多个团队共享的负载均衡基础设施。Gateway API 不仅是用于高级路由的更具表达力的 API，而且还是面向角色的 API，专为多租户基础设施而设计。其可扩展性确保它将随着未来的用例而演变，同时保持可移植性。最终，这些特性将使 Gateway API 很好地适应不同的组织模型和未来的实现。

尝试并参与

有许多资源可供查阅以了解更多信息。

查看用户指南，了解可以解决哪些用例。
试用其中一个现有 Gateway 控制器
或者参与进来，帮助设计和影响 Kubernetes 服务网络的未来！