关于后端:探索-Gateway-API-在-Service-Mesh-中的工作机制

前几天 Gateway API 发表在 0.8.0 中反对服务网格，这意味着 GAMMA（Gateway API for Mesh Management and Administration）有了新进展，尽管目前还是 试验阶段。去年 6 月 Gateway API 公布 0.5.0 时，我还写了一篇 SMI 与 Gateway API 的 GAMMA 倡导意味着什么？。现在，SMI 作为 sandbox 我的项目的年度审查曾经 过了几个月仍未提交，唏嘘。

废话不多说，咱们来看下 0.8.0 下的 Gateway API 如何在 Service Mesh 中工作。

TL;DR

Gateway API 对服务网格的反对依然是试验阶段，然而曾经有厂商跟进（当然也都是试验阶段）。

相比 Gateway API 解决南北向流量将路由绑定到 Gateway 资源 相比，在网格中路由则是与 Service 进行绑定。简略了解成 Service 代理了 Gateway 的角色，不过该 Service 是指标 Service。

Gateway API 中的服务网格

要说服务网格，咱们先来看下服务 Service。

形象 Service

Service 中 Kubernetes 中是一个独立的资源，这里说的形象是从逻辑上进行形象，形象成前端和后端两局部。

前端（Frontend）通常就是 Service 的 DNS 名字或者 ClusterIP；后端（Backend）则是通过标签选择器抉择的 Endpoint 或者 EndpointSlice。

路由与服务

把路由间接绑定到 Service 上，被认为是 当下最优 的抉择。Service 与其余资源的耦合度太高，比方 IP 调配、DNS、端点汇合、负载平衡等等，但在目前的网格设计中也是惟一的最优抉择，将来会寻求更好的抉择，比方 ServiceBinding（见后文）

这样做的益处呢，就是将服务的前后端别离与当初的 xRoute API 中的 parentRef 和 backendRef 关联，无需引入额定的 API。

不同的时候，在 xRoute API 中的 backendRef 也能够是一个 Service，然而最终在路由申请时，指标还是 Endpoint 或者 EndpointSlice，只不过他们与 parentRef 中的 Service 不是强关联的。

kind: HTTPRoute
metadata:
  name: smiley-route
  namespace: faces
spec:
  parentRefs:
    - name: smiley
      kind: Service
      group: core
      port: 80
  rules:
    ...

如果一个 Service 上配置了多个路由，匹配到多条路由的申请将被回绝。

申请流程

1. 客户端发送申请

2. 网格数据面代理拦挡申请

   1. 通过虚构 IP 地址、DNS 主机名、或者名字来确认流量是属于哪个 Service（不会应用 xRoute 上的 hostname 字段）
   2. 如果 Service 没有配置路由，将应用申请的原始目的地进行转发
   3. 找到匹配的优先级最高（消费者路由高于生产者路由，见下文）的路由进行转发
   4. 如果配置了路由，但都无奈匹配，则拒绝请求

路由的命名空间

为什么要提命名空间，是因为路由与服务在雷同或者不同命名空间下所代表的含意不同。

同命名空间

路由 smiley-route 与 Service smiley 位于同一个命名空间 faces，该路由上设置了申请超时工夫 100ms。这意味着，所有拜访 Service smiley（来自任一命名空间下的任一工作负载）并匹配 smiley-route 路由规定的申请，都受该超时配置的影响。

这种路由被称为 生产者路由（Producer Route），影响指标为该服务的所有申请。

kind: HTTPRoute
metadata:
  name: smiley-route
  namespace: faces
spec:
  parentRefs:
  - name: smiley
    namespace: faces
    kind: Service
    group: core
    port: 80
  rules:
    ...
    timeouts:
      request: 100ms

不同命名空间

路由 smiley-route 与 Service smiley 位于不同的命名空间，与下面不同的是，所有拜访 Service smiley（来自命名空间 fast-clients 下的任一工作负载）并匹配 smiley-route 路由规定的申请，都受该超时配置的影响。

这种路由被称为 消费者路由（Consumer Route），影响同命名空间下拜访木雕服务的所有申请。

kind: HTTPRoute
metadata:
  name: smiley-route
  namespace: fast-clients
spec:
  parentRefs:
  - name: smiley
    namespace: faces
    kind: Service
    group: core
    port: 80
  rules:
    ...
    timeouts:
      request: 100ms

同一 Service 上的多个路由

这里的前提条件是这些路由都位于同一命名空间下，即 同为生产者路由，或同为消费者路由 。这种状况将会遵循 路由合并规定 多这个路由进行合并，如果要为同一命名空间下的多个工作负载配置不同的 消费者路由，目前还无奈实现。惟一的

比方上面定义了两个消费者路由 smiley-route-50 和 smiley-route-100

kind: HTTPRoute
metadata:
  name: smiley-route-50
  namespace: fast-clients
spec:
  parentRefs:
  - name: smiley
    namespace: faces
    kind: Service
    group: core
    port: 80
  rules:
    ...
    timeouts:
      request: 50ms
---
kind: HTTPRoute
metadata:
  name: smiley-route-100
  namespace: fast-clients
spec:
  parentRefs:
  - name: smiley
    namespace: faces
    kind: Service
    group: core
    port: 80
  rules:
    ...
    timeouts:
      request: 100ms

路由与策略

之前也写文介绍过 Gateway API 中的策略，有趣味的能够看一下 一文搞懂 Kubernetes Gateway API 的 Policy Attachment。

在网格中策略附加能够非常简单。策略能够利用于任何命名空间中的任何资源，但如果指标位于不同的命名空间中，则它只能利用于来自同一命名空间的申请（追随消费者路由的逻辑）。

网格一致性测试

首先来看下何为 一致性配置文件：

Gateway API 会提供用于一致性测试的配置文件，在运行一致性测试能够抉择这些配置文件。而后将一致性后果报告回网关 API 我的项目并取得认证（例如徽章）。除了测试外围的性能，也能够自主增加厂商的特定实现中的扩大性能进行测试。

这些 Gateway API 的实现会将测试报告提交到 官网仓库的一致性测试报告目录 中，能够作为大家选型时的根据之一。

目前有 HTTP、TLS、TLSPassthrough（基本上都是依据 xRoute 来进行组织，因而后续也会有 GRPC、TCP、UDP）。针对服务网格，也提出了 mesh 配置文件。

官网博客 中提到 Kuma 2.3+、Linkerd 2.14+、和 Istio 1.16+ 中的 Gateway API 实现曾经全副通过 mesh 一致性测试，但截止目前未看到测试报告，预计还在上传中。

关注 ” 云原生指北 ” 公众号
（转载本站文章请注明作者和出处盛世浮生，请勿用于任何商业用途）