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

Gateway API v1.1：服务网格、GRPCRoute 以及更多

作者：Richard Belleville (Google)、Frank Budinsky (IBM)、Arko Dasgupta (Tetrate)、Flynn (Buoyant)、Candace Holman (Red Hat)、John Howard (Solo.io)、Christine Kim (Isovalent)、Mattia Lavacca (Kong)、Keith Mattix (Microsoft)、Mike Morris (Microsoft)、Rob Scott (Google)、Grant Spence (Red Hat)、Shane Utt (Kong)、Gina Yeh (Google) 以及其他评审和发布说明贡献者 |

Gateway API logo

继去年十月 Gateway API 的 GA 版本发布之后，Kubernetes SIG Network 很高兴地宣布 Gateway API 的 v1.1 版本发布。在此版本中，有几个功能升级到 Standard Channel (GA)，其中最引人注目的是对服务网格和 GRPCRoute 的支持。我们还引入了一些新的实验性功能，包括会话持久性和客户端证书验证。

新增内容

毕业至 Standard Channel

此版本包括四个备受期待的功能毕业至 Standard Channel。这意味着它们不再是实验性的概念；被纳入 Standard 发布渠道表明对 API 接口的高度信心，并提供向后兼容性的保证。当然，与任何其他 Kubernetes API 一样，Standard Channel 的功能可以随着时间的推移，通过向后兼容的增补继续演进，我们当然期望这些新功能在未来会有进一步的完善和改进。有关此工作原理的更多信息，请参阅 Gateway API 版本控制策略。

服务网格支持

Gateway API 中的服务网格支持允许服务网格用户使用相同的 API 来管理入口流量和网格内流量，复用相同的策略和路由接口。在 Gateway API v1.1 中，路由（例如 HTTPRoute）现在可以有一个 Service 作为 parentRef，以控制到特定服务的流量行为。更多信息请阅读 Gateway API 服务网格文档或查看 Gateway API 实现列表。

举个例子，可以在应用程序调用图的深处使用 HTTPRoute 进行工作负载的金丝雀部署，如下所示：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: color-canary
  namespace: faces
spec:
  parentRefs:
    - name: color
      kind: Service
      group: ""
      port: 80
  rules:
  - backendRefs:
    - name: color
      port: 80
      weight: 50
    - name: color2
      port: 80
      weight: 50

这将把发送到 faces 命名空间中 color 服务的流量在原始的 color 服务和 color2 服务之间进行 50/50 的分割，使用一种可移植的配置，很容易从一个网格迁移到另一个网格。

GRPCRoute

如果你已经在使用实验版本的 GRPCRoute，我们建议在你所使用的控制器更新以支持 GRPCRoute v1 之前，暂缓升级到 GRPCRoute 的 Standard Channel 版本。在此之前，升级到 v1.1 中包含 v1alpha2 和 v1 API 版本的 GRPCRoute 实验性渠道版本是安全的。

ParentReference Port

port 字段已添加到 ParentReference 中，允许你将资源附加到 Gateway Listener、Service 或其他父资源（取决于实现）。绑定到端口还允许你一次附加到多个 Listener。

例如，你可以将一个 HTTPRoute 附加到一个或多个由 Listener port 指定的 Gateway 的特定 Listener 上，而不是使用 Listener 的 name 字段。

更多信息，请参见附加到网关。

一致性配置文件和报告

一致性报告 API 已通过 mode 字段（用于指定实现的工件模式）和 gatewayAPIChannel（standard 或 experimental）进行了扩展。gatewayAPIVersion 和 gatewayAPIChannel 现在由套件机制自动填充，并附有测试结果的简要描述。报告已以更结构化的方式重新组织，并且实现现在可以添加有关测试运行方式的信息并提供复现步骤。

Experimental Channel 的新增内容

网关客户端证书验证

通过在 tls 中引入一个新的 frontendValidation 字段，网关现在可以为每个 Gateway Listener 配置客户端证书验证。该字段支持配置一个 CA 证书列表，可用作信任锚来验证客户端提供的证书。

以下示例展示了如何使用存储在 foo-example-com-ca-cert ConfigMap 中的 CA 证书来验证连接到 foo-https Gateway Listener 的客户端所提供的证书。

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: client-validation-basic
spec:
  gatewayClassName: acme-lb
  listeners:
  - name: foo-https
    protocol: HTTPS
    port: 443
    hostname: foo.example.com
    tls:
      certificateRefs:
      - kind: Secret
        group: ""
        name: foo-example-com-cert
      frontendValidation:
        caCertificateRefs:
        - kind: ConfigMap
          group: ""
          name: foo-example-com-ca-cert

会话持久性与 BackendLBPolicy

会话持久性正通过一个新的策略（BackendLBPolicy）引入 Gateway API，用于服务级别的配置，并作为 HTTPRoute 和 GRPCRoute 中的字段，用于路由级别的配置。BackendLBPolicy 和路由级别的 API 提供了相同的会话持久性配置，包括会话超时、会话名称、会话类型和 Cookie 的生命周期类型。

下面是一个 BackendLBPolicy 的配置示例，它为 foo 服务启用了基于 Cookie 的会话持久性。它将话名称设置为 foo-session，定义了绝对超时和空闲超时，并将 Cookie 配置为会话 Cookie。

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: BackendLBPolicy
metadata:
  name: lb-policy
  namespace: foo-ns
spec:
  targetRefs:
  - group: core
    kind: service
    name: foo
  sessionPersistence:
    sessionName: foo-session
    absoluteTimeout: 1h
    idleTimeout: 30m
    type: Cookie
    cookieConfig:
      lifetimeType: Session

其他所有内容

TLS 术语澄清

作为使我们的 TLS 术语在整个 API 中更加一致这一更广泛目标的一部分，我们对 BackendTLSPolicy 引入了一些破坏性变更。这导致了新的 API 版本（v1alpha3），并要求此策略的任何现有实现正确处理版本升级，例如，通过备份数据并在安装此较新版本之前卸载 v1alpha2 版本。

任何对 v1alpha2 BackendTLSPolicy 字段的引用都需要更新到 v1alpha3。字段的具体更改包括：

  • targetRef 变为 targetRefs，以允许一个 BackendTLSPolicy 附加到多个目标。
  • tls 变为 validation
  • tls.caCertRefs 变为 validation.caCertificateRefs
  • tls.wellKnownCACerts 变为 validation.wellKnownCACertificates

有关此版本中包含的更改的完整列表，请参阅 v1.1.0 发行说明。

Gateway API 背景

Gateway API 的想法最初是在 2019 年圣地亚哥 KubeCon 上作为下一代 Ingress API 提出的。从那时起，一个令人难以置信的社区已经形成，共同开发了可能是 Kubernetes 历史上最具协作性的 API。到目前为止，已有 200 多人为此 API 做出了贡献，而且这个数字还在继续增长。

维护者们要感谢为 Gateway API 做出贡献的*每一个人*，无论是通过向仓库提交代码、参与讨论、提出想法，还是一般的支持。没有这个专注而活跃的社区的支持，我们真的不可能走到今天。

立即试用

与其他 Kubernetes API 不同，你无需升级到最新版本的 Kubernetes 即可获得最新版本的 Gateway API。只要你运行的是 Kubernetes 1.26 或更高版本，你就能使用此版本的 Gateway API。

要试用该 API，请遵循我们的入门指南。

参与其中

我们有很多机会参与进来，帮助定义 Kubernetes 入口和服务网格路由 API 的未来。