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 通用可用 (GA) 版本发布之后，Kubernetes SIG Network 很高兴地宣布发布 Gateway API v1.1 版本。在此版本中，一些功能已晋升到 Standard Channel（通用可用），尤其值得一提的是对服务网格和 GRPCRoute 的支持。我们还引入了一些新的实验性功能，包括会话持久化和客户端证书验证。

新功能

晋升到标准版

此版本包含四项备受期待的功能晋升到标准版。这意味着它们不再是实验性概念；包含在标准发布渠道中表明对 API 表面的高度信心，并提供向后兼容性保证。当然，与任何其他 Kubernetes API 一样，Standard Channel 功能可以随着时间的推移通过向后兼容的附加功能继续发展，我们当然也期望这些新功能未来会得到进一步的完善和改进。有关这一切如何工作的更多信息，请参阅Gateway API 版本控制策略。

服务网格支持

Gateway API 中的服务网格支持允许服务网格用户使用相同的 API 管理入口流量和网格内流量，重用相同的策略和路由接口。在 Gateway API v1.1 中，路由（如 HTTPRoute）现在可以将 Service 作为 parentRef，以控制流向特定 Service 的流量行为。有关更多信息，请阅读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 Service 的流量在原始 color Service 和 color2 Service 之间以 50/50 的比例进行分流，使用一种易于从一个网格迁移到另一个网格的可移植配置。

GRPCRoute

如果您已经在使用 GRPCRoute 的实验性版本，我们建议暂缓升级到 GRPCRoute 的标准通道版本，直到您正在使用的控制器已更新以支持 GRPCRoute v1。在此之前，可以安全地升级到 v1.1 中的 GRPCRoute 实验通道版本，该版本包含 v1alpha2 和 v1 API 版本。

ParentReference 端口

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

例如，您可以按照 Listener port 指定的方式，将 HTTPRoute 附加到 Gateway 的一个或多个特定 Listener，而不是使用 Listener name 字段。

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

一致性配置文件和报告

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

实验性渠道的新增功能

网关客户端证书验证

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

以下示例展示了如何使用存储在 foo-example-com-ca-cert ConfigMap 中的 CACertificate 来验证连接到 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，用于 Service 级别配置；也作为 HTTPRoute 和 GRPCRoute 中的字段，用于路由级别配置。BackendLBPolicy 和路由级别 API 提供相同的会话持久性配置，包括会话超时、会话名称、会话类型和 Cookie 生命周期类型。

下面是 BackendLBPolicy 的一个示例配置，它为 foo Service 启用基于 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 的未来。

查看用户指南，了解可以解决哪些用例。
试用一个现有的 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