探索 Gateway API 在 Service Mesh 中的工作机制 _API

前几天 Gateway API 宣布在 0.8.0 中支持服务网格[1]，这意味着 GAMMA[2]（Gateway API for Mesh Management and Administration）有了新进展，虽然目前还是实验阶段。去年 6 月 Gateway API 发布 0.5.0 时，我还写了一篇 SMI 与 Gateway API 的 GAMMA 倡议意味着什么？[3] 。如今，SMI 作为 sandbox 项目的年度审查已经过了几个月仍未提交[4]，唏嘘。
废话不多说，我们来看下 0.8.0 下的 Gateway API 如何在 Service Mesh 中工作。
TL;DRGateway API 对服务网格的支持仍然是实验阶段，但是已经有厂商跟进（当然也都是实验阶段）。
相比 Gateway API 处理南北向流量将路由绑定到 Gateway 资源[5] 相比，在网格中路由则是与 Service 进行绑定。简单理解成 Service 代理了 Gateway 的角色，不过该 Service 是目标 Service 。
Gateway API 中的服务网格要说服务网格，我们先来看下服务 Service 。
抽象 ServiceService 中 Kube.NETes 中是一个独立的资源，这里说的抽象是从逻辑上进行抽象，抽象成前端和后端两部分。
前端（Frontend）通常就是 Service 的 DNS 名字或者 ClusterIP；后端（Backend）则是通过标签选择器选择的 Endpoint 或者 EndpointSlice 。

文章插图
图片
路由与服务【探索 Gateway API 在 Service Mesh 中的工作机制】

文章插图
图片
把路由直接绑定到 Service 上，被认为是当下最优的选择。Service 与其他资源的耦合度太高，比如 IP 分配、DNS、端点集合、负载均衡等等，但在目前的网格设计中也是唯一的最优选择，未来会寻求更好的选择，比如 ServiceBinding（见后文）
这样做的好处呢，就是将服务的前后端分别与现在的 xRoute API 中的 parentRef 和 backendRef 关联，无需引入额外的 API 。
不同的时候，在 xRoute API 中的 backendRef 也可以是一个 Service，但是最终在路由请求时，目标还是 Endpoint 或者 EndpointSlice，只不过他们与 parentRef 中的 Service 不是强关联的。

kind: HTTPRoutemetadata:name: smiley-routenamespace: facesspec:parentRefs:- name: smileykind: Servicegroup: coreport: 80rules:...

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

请求流程

客户端发送请求
网格数据面代理拦截请求
通过虚拟 IP 地址、DNS 主机名、或者名字来确认流量是属于哪个 Service（不会使用 xRoute 上的 hostname 字段）
如果 Service 没有配置路由，将使用请求的原始目的地进行转发
找到匹配的优先级最高（消费者路由高于生产者路由，见下文）的路由进行转发
如果配置了路由，但都无法匹配，则拒绝请求

路由的命名空间为什么要提命名空间，是因为路由与服务在相同或者不同命名空间下所代表的含义不同。
同命名空间路由 smiley-route 与 Service smiley 位于同一个命名空间 faces，该路由上设置了请求超时时间 100ms 。这意味着，所有访问 Service smiley （来自任一命名空间下的任一工作负载）并匹配 smiley-route路由规则的请求，都受该超时配置的影响。
这种路由被称为生产者路由（Producer Route）[6]，影响目标为该服务的所有请求。

kind: HTTPRoutemetadata:name: smiley-routenamespace: facesspec:parentRefs:- name: smileynamespace: faceskind: Servicegroup: coreport: 80rules:...timeouts:request: 100ms

不同命名空间路由 smiley-route 与 Service smiley 位于不同的命名空间，与上面不同的是，所有访问 Service smiley（来自命名空间 fast-clients 下的任一工作负载）并匹配 smiley-route 路由规则的请求，都受该超时配置的影响。
这种路由被称为消费者路由（Consumer Route）[7]，影响同命名空间下访问木雕服务的所有请求。

kind: HTTPRoutemetadata:name: smiley-routenamespace: fast-clientsspec:parentRefs:- name: smileynamespace: faceskind: Servicegroup: coreport: 80rules:...timeouts:request: 100ms