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) 以及其他审查和发布说明贡献者 | 2024 年 5 月 9 日，星期四

继去年 10 月 Gateway API 正式发布后，Kubernetes SIG Network 很高兴地宣布 Gateway API 的 v1.1 版本发布。在此版本中，一些功能升级到标准通道（GA），特别是包括对服务网格和 GRPCRoute 的支持。我们还引入了一些新的实验性功能，包括会话持久性和客户端证书验证。

新增功能

升级到标准

此版本包括将四个期待已久的功能升级到标准。这意味着它们不再是实验性概念；包含在标准发布通道中表示对 API 表面的高度信任，并提供向后兼容性的保证。当然，与任何其他 Kubernetes API 一样，标准通道功能可以随着时间的推移继续进行向后兼容的添加而发展，而且我们当然希望在未来对这些新功能进行进一步的改进和完善。有关这一切如何工作的更多信息，请参阅 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 的标准通道版本。在此之前，可以安全地升级到 v1.1 中包含 v1alpha2 和 v1 API 版本的 GRPCRoute 的实验通道版本。

ParentReference 端口

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

例如，您可以根据侦听器 port 指定，而不是侦听器 name 字段，将 HTTPRoute 附加到一个或多个 Gateway 的特定侦听器。

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

一致性配置文件和报告

一致性报告 API 已使用 mode 字段（旨在指定实现的工作模式）和 gatewayAPIChannel（标准或实验性）进行了扩展。gatewayAPIVersion 和 gatewayAPIChannel 现在由套件机制自动填充，同时还包含测试结果的简要描述。报告已以更结构化的方式重新组织，并且实现现在可以添加有关测试如何运行的信息并提供重现步骤。

实验通道的新增功能

网关客户端证书验证

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

以下示例显示了如何使用存储在 foo-example-com-ca-cert ConfigMap 中的 CACertificate 来验证连接到 foo-https 网关侦听器的客户端提供的证书。

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），为服务级别配置，以及 HTTPRoute 和 GRPCRoute 中的字段，为路由级别配置，将会话持久性引入到 Gateway API 中。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 术语澄清

作为在整个 API 中使我们的 TLS 术语更加一致的更广泛目标的一部分，我们对 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 的未来，无论是用于入口还是服务网格。

查看用户指南，了解可以解决哪些用例。
尝试现有的 Gateway 控制器之一。
或者加入我们的社区，一起帮助构建 Gateway API 的未来！

Gateway API v1.0 中的新实验性功能 11/2023
Gateway API v1.0：GA 发布 10/2023
介绍 ingress2gateway；简化 Gateway API 的升级 10/2023
Gateway API v0.8.0：引入服务网格支持 08/2023