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

Gateway API v1.0 中的新实验性功能

作者：Candace Holman (Red Hat), Dave Protasowski (VMware), Gaurav K Ghildiyal (Google), John Howard (Google), Simone Rodigari (IBM) |

最近，Gateway API 宣布了其 v1.0 GA 版本，标志着该项目的一个重要里程碑。

除了稳定 API 中的一些核心功能外，还添加了一些令人兴奋的新实验性功能。

后端 TLS 策略

BackendTLSPolicy 是一种新的 Gateway API 类型，用于指定从网关到后端 Pod 通过 Service API 对象的 TLS 连接配置。它被指定为 直接策略附件，没有默认值或覆盖，应用于访问后端的 Service，其中 BackendTLSPolicy 与其应用的 Service 位于同一命名空间中。所有指向引用 Service 的 Gateway API 路由都应遵循配置的 BackendTLSPolicy。

虽然之前提供了 配置边缘和直通终止 TLS 的方法，但这个新的 API 对象专门解决了 TLS 的配置问题，以便将 HTTPS 从网关数据平面传输到后端。这被称为“后端 TLS 终止”，使网关知道如何连接到具有自己证书的后端 Pod。

Termination Types

BackendTLSPolicy 的规范包括

  • targetRef - 定义策略的目标 API 对象。只允许 Service。
  • tls - 定义 TLS 的配置，包括 hostname、caCertRefs 和 wellKnownCACerts。可以指定 caCertRefs 或 wellKnownCACerts，但不能同时指定两者。
  • hostname - 定义网关用于连接到后端的服务器名称指示 (SNI)。后端提供的证书必须与此 SNI 匹配。
  • caCertRefs - 定义一个或多个对包含 PEM 编码的 TLS 证书的对象的引用，这些证书用于在网关和后端之间建立 TLS 握手。
  • wellKnownCACerts - 指定是否可以在网关和后端之间的 TLS 握手中使用系统 CA 证书。

示例

使用系统证书

在此示例中，BackendTLSPolicy 配置为使用系统证书连接到 TLS 加密的上游连接，其中支持 dev Service 的 Pod 应为 dev.example.com 提供有效证书。

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: BackendTLSPolicy
metadata:
  name: tls-upstream-dev
spec:
  targetRef:
    kind: Service
    name: dev-service
    group: ""
  tls:
    wellKnownCACerts: "System"
    hostname: dev.example.com

使用显式 CA 证书

在此示例中，BackendTLSPolicy 配置为使用配置映射 auth-cert 中定义的证书连接到 TLS 加密的上游连接，其中支持 auth Service 的 Pod 应为 auth.example.com 提供有效证书。

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: BackendTLSPolicy
metadata:
  name: tls-upstream-auth
spec:
  targetRef:
    kind: Service
    name: auth-service
    group: ""
  tls:
    caCertRefs:
      - kind: ConfigMapReference
        name: auth-cert
        group: ""
    hostname: auth.example.com

以下说明了一个 BackendTLSPolicy，它为服务后端的 Service 配置 TLS

流程图 LR client(["client"]) gateway["Gateway"] style gateway fill:#02f,color:#fff httproute["HTTP
Route"] style httproute fill:#02f,color:#fff service["Service"] style service fill:#02f,color:#fff pod1["Pod"] style pod1 fill:#02f,color:#fff pod2["Pod"] style pod2 fill:#02f,color:#fff client -.->|HTTP
request| gateway gateway --> httproute httproute -.->|BackendTLSPolicy|service service --> pod1 & pod2

有关更多信息，请参阅 TLS 文档。

HTTPRoute 超时

Gateway API 最新版本 (v1.0) 的一项重要增强功能是在 HTTPRoute 规则中引入了 timeouts 字段。此功能提供了一种动态方式来管理传入 HTTP 请求的超时，从而为您的网关设置增加精确性和可靠性。

通过超时，开发人员可以通过两种基本方式微调其 Gateway API 的行为

  1. 请求超时:

    请求超时是 Gateway API 实现必须在其中向客户端的 HTTP 请求发送响应的持续时间。它可以灵活地指定此超时何时开始，可以在接收到整个客户端请求流之前或之后，使其成为特定于实现的。此超时有效地覆盖了整个请求-响应事务，从而提高了服务的响应能力。

  2. 后端请求超时:

    对于处理后端的人员来说，后端请求超时是一个游戏规则改变者。它为从网关发送到后端服务的单个请求设置超时。此超时跨越从请求启动到接收来自后端的完整响应。此功能在网关需要重试与后端的连接时特别有用，从而确保在各种条件下顺利通信。

值得注意的是，request 超时包含 backendRequest 超时。因此，backendRequest 的值不应超过 request 超时的值。

配置这些超时的能力为您的 Kubernetes 服务增加了一层新的可靠性。无论是确保在指定的时间范围内处理客户端请求，还是管理后端服务通信，Gateway API 的超时都提供了您需要的控制和可预测性。

要开始使用，您可以使用超时字段在 HTTPRoute 规则中定义超时，并将其类型指定为 Duration。零值超时 (0s) 将禁用超时，而有效的非零值超时应至少为 1 毫秒。

这是一个在 HTTPRoute 中设置请求和后端请求超时的示例

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: timeout-example
spec:
  parentRefs:
  - name: example-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /timeout
    timeouts:
      request: 10s
      backendRequest: 2s
    backendRefs:
    - name: timeout-svc
      port: 8080

在此示例中，定义了 10 秒的 request 超时，以确保在指定的时间范围内处理客户端请求。此外，还为从网关到名为 timeout-svc 的后端服务的单个请求设置了 2 秒的 backendRequest 超时。

这些新的 HTTPRoute 超时为 Kubernetes 用户提供了更多管理网络通信的控制和灵活性，有助于确保为客户端和后端提供更顺畅、更可预测的体验。有关更多详细信息和示例，请参阅 官方超时 API 文档。

网关基础架构标签

虽然 Gateway API 为不同的实现提供了一个通用的 API，但每个实现都会在底层创建不同的资源来应用用户的意图。这可能包括配置云负载均衡器、创建集群内 Pod 和服务等等。

虽然 API 一直提供扩展点 - GatewayClass 中的 parametersRef - 来自定义特定于实现的内容，但没有通用的核心方式来表达常见的架构自定义。

Gateway API v1.0 通过 Gateway 对象上的新 infrastructure 字段为此铺平了道路，从而可以自定义底层架构。目前，这从两个关键字段开始：标签和注释。设置这些字段后，任何生成的基础架构都将在其上设置提供的标签和注释。

例如，我可能想将我的一个应用程序的所有资源组合在一起

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: hello-world
spec:
  infrastructure:
    labels:
      app.kubernetes.io/name: hello-world

未来，我们正在研究更常见的基础架构配置，例如资源大小。

有关更多信息，请参阅此功能的文档。

支持 Websockets、HTTP/2 等！

并非所有 Gateway API 实现都支持自动协议选择。在某些情况下，如果没有显式选择加入，协议将被禁用。

当 Route 的后端引用 Kubernetes 服务时，应用程序开发人员可以使用 ServicePort appProtocol 字段指定协议。

例如，以下 store Kubernetes 服务指示端口 8080 支持 HTTP/2 Prior Knowledge。

apiVersion: v1
kind: Service
metadata:
  name: store
spec:
  selector:
    app: store
  ports:
  - protocol: TCP
    appProtocol: kubernetes.io/h2c
    port: 8080
    targetPort: 8080

目前，Gateway API 具有以下一致性测试

  • kubernetes.io/h2c - HTTP/2 Prior Knowledge
  • kubernetes.io/ws - 通过 HTTP 的 WebSocket

有关更多信息，请参阅 后端协议选择的文档。

gwctl，我们新的 Gateway API 命令行工具

gwctl 是一种旨在替代 kubectl 以查看 Gateway API 资源的命令行工具。

与 Gateway v1.0 版本捆绑在一起的 gwctl 的初始版本包括用于管理 Gateway API 策略的有用功能。Gateway API 策略是修改网关资源行为的强大扩展机制。使用策略的一个挑战是可能很难发现哪些策略影响哪些网关资源。gwctl 通过回答以下问题来弥合这一差距

  • 哪些策略可在 Kubernetes 集群中使用？
  • 哪些策略附加到特定的网关、HTTPRoute 等？
  • 如果策略应用于网关资源层次结构中的多个资源，则影响特定资源的有效策略是什么？（例如，如果将 HTTP 请求超时策略应用于 HTTPRoute 及其父网关，则 HTTPRoute 的有效超时是什么？）

gwctl 仍处于开发的早期阶段，因此可能有点粗糙。请按照存储库中的说明安装并试用 gwctl。

示例

以下是一些如何使用 gwctl 的示例

# List all policies in the cluster. This will also give the resource they bind
# to.
gwctl get policies -A
# List all available policy types.
gwctl get policycrds
# Describe all HTTPRoutes in namespace ns2. (Output includes effective policies)
gwctl describe httproutes -n ns2
# Describe a single HTTPRoute in the default namespace. (Output includes
# effective policies)
gwctl describe httproutes my-httproute-1
# Describe all Gateways across all namespaces. (Output includes effective
# policies)
gwctl describe gateways -A
# Describe a single GatewayClass. (Output includes effective policies)
gwctl describe gatewayclasses foo-com-external-gateway-class

参与其中

这些项目以及更多项目在 Gateway API 中不断改进。有很多机会可以参与进来，并帮助定义 Kubernetes 路由 API（用于 Ingress 和 Mesh）的未来。

如果您对此感兴趣，请加入我们的社区，并帮助我们共同构建 Gateway API 的未来！