你正在查看的文档所针对的是 Kubernetes 版本： v1.30

Kubernetes v1.30 版本的文档已不再维护。你现在看到的版本来自于一份静态的快照。如需查阅最新文档，请点击最新版本。

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), 和其他评审及发布说明的贡献者 | 译者 Michael Yao (DaoCloud) | 2024.05.09

继去年十月正式发布 Gateway API 之后，Kubernetes SIG Network 现在又很高兴地宣布 Gateway API v1.1 版本发布。在本次发布中，有几个特性已进阶至标准渠道（GA），特别是对服务网格和 GRPCRoute 的支持也已进阶。我们还引入了一些新的实验性特性，包括会话持久性和客户端证书验证。

新内容

进阶至标准渠道

本次发布有四个备受期待的特性进阶至标准渠道。这意味着它们不再是实验性的概念；包含在标准发布渠道中的举措展现了大家对 API 接口的高度信心，并提供向后兼容的保证。当然，与所有其他 Kubernetes API 一样，标准渠道的特性可以随着时间的推移通过向后兼容的方式演进，我们当然期待未来对这些新特性有进一步的优化和改进。有关细节请参阅 Gateway API 版本控制政策。

服务网格支持

在 Gateway API 中支持服务网格意味着允许服务网格用户使用相同的 API 来管理 Ingress 流量和网格流量，能够重用相同的策略和路由接口。在 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

通过使用一种便于从一个网格迁移到另一个网格的可移植配置，此 HTTPRoute 对象将把发送到 faces 命名空间中的 color Service 的流量按 50/50 拆分到原始的 color Service 和 color2 Service 上。

GRPCRoute

如果你已经在使用实验性版本的 GRPCRoute，我们建议你暂时不要升级到标准渠道版本的 GRPCRoute，除非你正使用的控制器已被更新为支持 GRPCRoute v1。在此之后，你才可以安全地升级到实验性渠道版本的 GRPCRoute v1.1，这个版本同时包含了 v1alpha2 和 v1 的 API。

ParentReference 端口

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

例如，你可以将 HTTPRoute 挂接到由监听器 port 而不是监听器 name 字段所指定的一个或多个特定监听器。

有关细节请参阅挂接到 Gateways。

合规性配置文件和报告

合规性报告 API 被扩展了，添加了 mode 字段（用于指定实现的工作模式）以及 gatewayAPIChannel（标准或实验性）。 gatewayAPIVersion 和 gatewayAPIChannel 现在由套件机制自动填充，并附有测试结果的简要描述。这些报告已通过更加结构化的方式进行重新组织，现在实现可以添加测试是如何运行的有关信息，还能提供复现步骤。

实验性渠道的新增内容

Gateway 客户端证书验证

Gateway 现在可以通过在 tls 内引入的新字段 frontendValidation 来为每个 Gateway 监听器配置客户端证书验证。此字段支持配置可用作信任锚的 CA 证书列表，以验证客户端呈现的证书。

以下示例显示了如何使用存储在 foo-example-com-ca-cert ConfigMap 中的 CACertificate 来验证连接到 foo-https Gateway 监听器的客户端所呈现的证书。

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 术语阐述

为了在整个 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 San Diego 上作为下一代 Ingress API 提出的。从那时起，一个令人瞩目的社区逐渐形成，共同开发出了可能成为 Kubernetes 历史上最具合作精神的 API。到目前为止，已有超过 200 人为该 API 做过贡献，而且这一数字还在不断攀升。

维护者们要感谢为 Gateway API 做出贡献的每一个人，无论是提交代码、参与讨论、提供创意，还是给予常规支持，我们都在此表示诚挚的感谢。没有这个专注且活跃的社区的支持，我们不可能走到这一步。

试用一下

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

要试用此 API，请参阅入门指南。

参与进来

你有很多机会可以参与进来并帮助为 Ingress 和服务网格定义 Kubernetes 路由 API 的未来。

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

2023 年 11 月 Gateway API v1.0 中的新实验性特性
2023 年 10 月 Gateway API v1.0：正式发布（GA）
2023 年 10 月介绍 ingress2gateway；简化 Gateway API 升级
2023 年 8 月 Gateway API v0.8.0：引入服务网格支持