Gateway API v1.2：WebSockets、超时、重试及更多

Kubernetes SIG Network 很高兴宣布 Gateway API v1.2 正式发布！该 API 版本于 10 月 3 日发布，我们很高兴地报告说，我们现在有许多符合规范的实现供您尝试。

Gateway API v1.2 为标准通道（Gateway API 的 GA 发布通道）带来了一些新功能，引入了一些新的实验性功能，并启动了我们新的发布流程 - 但它也带来了两个需要注意的重大更改。

重大更改

GRPCRoute 和 ReferenceGrant v1alpha2 版本移除

现在 GRPCRoute 和 ReferenceGrant 的 v1 版本已升级到标准版，为了减轻长期支持旧版本给 Gateway API 社区带来的维护负担，旧的 v1alpha2 版本已从标准通道和实验通道中移除。

在升级到 Gateway API v1.2 之前，您需要确认 Gateway API 的所有实现都已升级为支持这些资源的 v1 API 版本，而不是 v1alpha2 API 版本。请注意，即使您在 YAML 清单中使用的是 v1 版本，控制器可能仍然在使用 v1alpha2 版本，这会导致升级期间失败。此外，Kubernetes 本身也会尽力阻止您删除它认为您正在使用的 CRD 版本：请查看发布说明，了解有关如何安全升级的更多信息。

更改 .status.supportedFeatures（实验性）

一个较小的重大更改：Gateway 中的 .status.supportedFeatures 现在是一个对象列表，而不是字符串列表。这些对象有一个 name 字段，因此从字符串的转换很简单，但移动到对象允许未来有更大的灵活性。此节尚未出现在标准通道中。

升级到标准通道

Gateway API 1.2.0 将四个功能升级到标准通道，这意味着它们现在可以被认为是正式发布。包含在标准发布通道中表示对 API 表面的高度信任，并提供向后兼容性的保证。当然，与任何其他 Kubernetes API 一样，标准通道功能可以在未来继续通过向后兼容的添加进行发展，我们当然希望在未来对这些新功能进行进一步的改进和完善。有关所有这些如何工作的更多信息，请参阅 Gateway API 版本控制策略。

HTTPRoute 超时

GEP-1742 将 timeouts 节引入到 HTTPRoute 中，允许配置 HTTP 流量的基本超时。这是一个简单但重要的功能，对于处理 HTTP 流量时的适当弹性至关重要，现在已成为标准。

例如，此 HTTPRoute 配置将到 /face 路径的流量超时时间设置为 300 毫秒

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: face-with-timeouts
  namespace: faces
spec:
  parentRefs:
    - name: my-gateway
      kind: Gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /face
    backendRefs:
    - name: face
      port: 80
    timeouts:
      request: 300ms

有关更多信息，请查看 HTTP 路由文档。（请注意，这仅适用于 HTTPRoute 超时。GRPCRoute 超时还不属于 Gateway API。）

Gateway 基础设施标签和注解

Gateway API 的实现负责创建使每个 Gateway 正常工作所需的后端基础设施。例如，在 Kubernetes 集群中运行的实现通常会创建服务和部署，而基于云的实现可能会创建云负载均衡器资源。在许多情况下，能够将标签或注解传播到这些生成的资源可能会很有帮助。

在 v1.2.0 中，Gateway 的 infrastructure 节移动到标准通道，允许您为 Gateway API 控制器创建的基础设施指定标签和注解。例如，如果您的 Gateway 基础设施在集群中运行，您可以使用以下 Gateway 配置指定 Linkerd 和 Istio 注入，从而使基础设施更容易集成到您安装的任何服务网格中

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: meshed-gateway
  namespace: incoming
spec:
  gatewayClassName: meshed-gateway-class
  listeners:
  - name: http-listener
    protocol: HTTP
    port: 80
  infrastructure:
    labels:
      istio-injection: enabled
    annotations:
      linkerd.io/inject: enabled

有关更多信息，请查看 infrastructure API 参考。

后端协议支持

自 Kubernetes v1.20 以来，Service 和 EndpointSlice 资源支持稳定的 appProtocol 字段，允许用户指定 Service 支持的 L7 协议。随着 KEP 3726 的采用，Kubernetes 现在支持三个新的 appProtocol 值

kubernetes.io/h2c

RFC7540 中描述的基于明文的 HTTP/2：RFC7540

kubernetes.io/ws

RFC6445 中描述的基于明文的 WebSocket：RFC6445

kubernetes.io/wss

RFC6445 中描述的基于 TLS 的 WebSocket：RFC6445

使用 Gateway API 1.2.0，现在支持遵守 appProtocol 成为标准。例如，给定以下 Service

apiVersion: v1
kind: Service
metadata:
  name: websocket-service
  namespace: my-namespace
spec:
  selector:
    app.kubernetes.io/name: websocket-app
  ports:
    - name: http
      port: 80
      targetPort: 9376
      protocol: TCP
      appProtocol: kubernetes.io/ws

然后，包含此 Service 作为 backendRef 的 HTTPRoute 将自动升级连接以使用 WebSockets，而不是假设连接是纯 HTTP。

有关更多信息，请查看 GEP-1911。

实验通道中的新增加项

*Route 资源命名规则

现在可以命名 HTTPRoute 和 GRPCRoute 资源中的 rules 字段，以便更容易引用特定的规则，例如

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: multi-color-route
  namespace: faces
spec:
  parentRefs:
    - name: my-gateway
      kind: Gateway
      port: 80
  rules:
  - name: center-rule
    matches:
    - path:
        type: PathPrefix
        value: /color/center
    backendRefs:
    - name: color-center
      port: 80
  - name: edge-rule
    matches:
    - path:
        type: PathPrefix
        value: /color/edge
    backendRefs:
    - name: color-edge
      port: 80

现在，日志或状态消息可以将这两个规则称为 center-rule 或 edge-rule，而不是被迫按索引引用它们。有关更多信息，请参阅 GEP-995。

HTTPRoute 重试支持

Gateway API 1.2.0 引入了对计数 HTTPRoute 重试的实验性支持。例如，以下 HTTPRoute 配置在重试之间延迟 500 毫秒的情况下，将对 /face 路径的请求重试最多 3 次

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: face-with-retries
  namespace: faces
spec:
  parentRefs:
    - name: my-gateway
      kind: Gateway
      port: 80
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /face
    backendRefs:
    - name: face
      port: 80
    retry:
      codes: [ 500, 502, 503, 504 ]
      attempts: 3
      backoff: 500ms

有关更多信息，请查看 GEP 1731。

基于百分比的 HTTPRoute 镜像

Gateway API 长期以来一直支持请求镜像功能，该功能允许将相同的请求发送到多个后端。在 Gateway API 1.2.0 中，我们引入了基于百分比的镜像，允许您指定镜像到不同后端的请求百分比。例如，以下 HTTPRoute 配置将 42% 的请求镜像到 color-mirror 后端

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: color-mirror-route
  namespace: faces
spec:
  parentRefs:
  - name: mirror-gateway
  hostnames:
  - mirror.example
  rules:
  - backendRefs:
    - name: color
      port: 80
    filters:
    - type: RequestMirror
      requestMirror:
        backendRef:
          name: color-mirror
          port: 80
        percent: 42   # This value must be an integer.

还有一个 fraction 节，可以用来代替 percent，以便更精确地控制镜像的流量数量，例如

    ...
    filters:
    - type: RequestMirror
      requestMirror:
        backendRef:
          name: color-mirror
          port: 80
        fraction:
          numerator: 1
          denominator: 10000

此配置将 10,000 个请求中的 1 个镜像到 color-mirror 后端，这可能与非常高的请求率有关。有关更多详细信息，请参阅 GEP-1731。

其他后端 TLS 配置

此版本包括与 Gateway 和工作负载（后端）之间的通信相关的 TLS 配置的三项添加

1. Gateway 上的新 backendTLS 字段

   这个新字段允许您指定 Gateway 在连接到后端时应使用的客户端证书。

2. BackendTLSPolicy 上的新 subjectAltNames 字段

   以前，hostname 字段用于配置 Gateway 应发送到后端的 SNI 和证书应提供的身份。当指定新的 subjectAltNames 字段时，任何匹配至少一个指定 SAN 的证书都将被视为有效。这对于 SPIFFE 尤其重要，其中基于 URI 的 SAN 可能不是有效的 SNI。

3. BackendTLSPolicy 上的新 options 字段

   与 Gateway 监听器上的 TLS 选项字段类似，我们认为相同的概念对于后端 TLS 的 TLS 特定配置也具有广泛的用途。

有关更多信息，请查看 GEP-3135。

更多更改

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

项目更新

除了技术方面，v1.2 版本还标志着 Gateway API 项目本身生命周期中的几个里程碑。

发布流程改进

Gateway API 从未打算成为一个静态 API，随着越来越多的项目将其用作构建的基础组件，我们清楚地意识到我们需要为 Gateway API 发布带来更多的可预测性。为此，我们很高兴 - 也有些紧张！- 地宣布我们已经正式确定了一个新的发布流程

• 范围界定（4-6周）：维护者和社区确定我们希望包含在发布版本中的功能集。这里的重点是将功能移出实验频道——理想情况下，这包括将它们移至标准频道，但也可能意味着删除它们。

• GEP 迭代和审查（5-7周）：贡献者为被接受进入发布版本的功能编写或更新网关增强提案（GEP），重点是就该功能的设计和毕业标准达成共识。

• API 改进和文档（3-5周）：贡献者在网关 API 控制器中实现这些功能，并编写必要的文档。

• SIG 网络审查和发布候选版本（2-4周）：维护者获得所需的上游审查，构建发布候选版本，并发布新版本。

网关 API 1.2.0 是使用新流程的第一个版本，虽然新事物总会有一些粗糙的地方，但我们相信它进展顺利。我们已经完成了网关 API 1.3 的范围界定阶段，预计将在 2025 年 1 月底左右发布。

gwctl 移出

gwctl CLI 工具已移至其自身的存储库：https://github.com/kubernetes-sigs/gwctl。gwctl 已被证明是网关 API 社区的宝贵工具；我们相信，将其移至其自身的存储库将使其更易于维护和开发。和往常一样，我们欢迎贡献；虽然仍处于实验阶段，但 gwctl 已经帮助简化了网关 API 的使用——尤其是对于该项目的新手！

维护者变更

为了完善我们对项目本身的更改，我们很高兴地宣布 Mattia Lavacca 加入了网关 API 维护者的行列！我们也很遗憾地宣布 Keith Mattix 已卸任 GAMMA 负责人——令人高兴的是，Mike Morris 已重返该职位。我们感谢 Keith 所做的一切，并很高兴 Mattia 和 Mike 的加入。

尝试一下

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

要试用该 API，请按照我们的入门指南进行操作。在撰写本文时，已有五个实现符合网关 API v1.2 标准。按字母顺序排列

• Cilium v1.17.0-pre.1，实验频道
• Envoy Gateway v1.2.0-rc.1，实验频道
• Istio v1.24.0-alpha.0，实验频道
• Kong v3.2.0-244-gea4944bb0，实验频道
• Traefik v3.2，实验频道

参与其中

有很多机会参与并帮助定义 Kubernetes 路由 API 的未来，无论是在入口还是服务网格方面。

• 查看用户指南，了解可以解决哪些用例。
• 试用一个现有的网关控制器。
• 或者加入我们的社区，共同构建网关 API 的未来！

维护者要感谢所有为网关 API 做出贡献的人，无论是提交到存储库的提交、讨论、想法还是总体支持。如果没有这个敬业且活跃的社区的支持，我们绝不可能走到今天。

相关的 Kubernetes 博客文章

• Gateway API v1.1：服务网格、GRPCRoute 以及更多
• 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

• ←上一篇
下一篇→