将网格的Gateway API引入Kuma - Kong公司

Kuma 2.3 引入 GAMMA 支持

Kuma 2.3 的发布为 GAMMA（网格管理和管理的网关 API）资源提供了实验性支持。长期以来，Kuma 已支持网关 API，通过内置网关处理入口流量。而借助 GAMMA 支持，用户现在可以使用网关 API 中的“HTTPRoute”资源，指定如何在网格内路由和修改流量。

Gateway API 和 GAMMA 的目标

Gateway API 和 GAMMA 的主要目标是创建一个可被任何入口基础设施或服务网格实现的标准化 API 和规范。这种可移植性允许用户只需学习一个 API，从而降低在不同实现之间切换的障碍。此外，这也减少了与实现集成的工具开发工作量。

这些 API 旨在尽可能表达核心功能，同时提供扩展点以支持实现特定行为和规范。

HTTPRoute 在网格中的应用

在网格中使用 HTTPRoute 的核心概念是将其附加到“Service”父节点，而不是“Gateway”类型的“parentRef”。这种方式可以跨网格标准化 HTTPRoute 的使用。然而，由于“Service”资源的复杂性和过载问题，在 GAMMA 从实验阶段毕业之前，可能会出现替代方案。

HTTPRoute 的工作原理

当 HTTPRoute 附加到“Service”父节点时，任何针对该服务的请求（即服务定义的 DNS 名称）都会首先被过滤，然后按照 HTTPRoute 的规则进行路由。请求可以被网格路由到 HTTPRoute 中定义的“backendRefs”，而不是直接路由到由 kube-proxy 控制的“Service”端点。

使用 Kuma 和 HTTPRoute 的示例

以下是一个使用 Kuma 和 HTTPRoute 的示例场景：

示例：通过 HTTP 头保护后端服务

通过 HTTPRoute，可以为后端服务添加 HTTP 头来实现流量修改。以下是一个示例配置：

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: enable-catalog-feature
  namespace: ui-backend
spec:
  parentRefs:
    - name: catalog
      namespace: products
      port: 80
      kind: Service
  rules:
    - filters:
        - type: RequestHeaderModifier
          requestHeaderModifier:
            add:
              - name: x-dev-feature
                value: "enabled"
      backendRefs:
        - name: catalog-v1
          port: 80
          weight: 90

在此配置中，parentRefs 指向一个 Service，Kuma 将其解释为 GAMMA 资源。

GAMMA 的两种路由模式

GAMMA 支持两种路由模式：

消费者路由：适用于父服务的单个消费者命名空间。路由资源的命名空间与父服务的命名空间不同，只有该命名空间中的用户可以修改路由。
生产者路由：适用于父服务的所有请求。路由资源与父服务位于同一命名空间，只有父服务的所有者可以修改路由。

例如，以下 HTTPRoute 是一个消费者路由，其影响范围仅限于“ui-backend”命名空间中的工作负载：

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: catalog-route
  namespace: ui-backend
spec:
  parentRefs:
    - name: catalog
      namespace: products
      port: 80
      kind: Service
  rules:
    - backendRefs:
        - name: catalog-v1
          port: 80

流量分流的用例

假设我们有两个版本的“catalog”服务，分别标记为 v1 和 v2。我们可以通过以下配置将 90% 的流量分配给 v1，10% 的流量分配给 v2：

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: catalog-split-route
  namespace: products
spec:
  parentRefs:
    - name: catalog
      port: 80
      kind: Service
  rules:
    - backendRefs:
        - name: catalog-v1
          port: 80
          weight: 90
        - name: catalog-v2
          port: 80
          weight: 10

通过运行以下命令，可以验证流量分配情况：

for i in {1..10}; do curl http://catalog.products | jq -r .os.hostname; done

结果显示，流量分配比例约为 9:1。

Kuma 的 MeshHTTPRoutes 支持

Kuma 还支持创建 MeshHTTPRoutes，这是一种自定义资源，与 HTTPRoute 类似，但基于 Kuma 的 kuma.io/service 概念。这些资源可以用于 Kubernetes 和 Universal 环境，并支持整个 Kuma 区域。

一致性测试的重要性

对于 Gateway API 的实现者来说，一致性测试是一个重要工具。它们可以验证实现是否符合规范，并帮助改进规范语言和解决歧义。

Kuma 已通过了“Gateway + HTTPRoute”的一致性测试，以及作为 GAMMA 资源的 HTTPRoute 测试。这表明 Kuma 正在努力成为完全符合 Gateway API 和 GAMMA 的实现。

未来展望

目前，GAMMA 的重点是实现路由标准化，但其目标不限于此。未来，GAMMA 计划探索 Gateway API 在服务网格中的所有潜在用例。Kuma 也将继续参与 Kubernetes SIG 网络项目的上游开发，为推动这一领域的发展贡献力量。

原文链接: https://konghq.com/blog/engineering/gamma-and-kuma