前几天 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 上配置了多个路由,匹配到多条路由的申请将被回绝。
申请流程
- 客户端发送申请
-
网格数据面代理拦挡申请
- 通过虚构 IP 地址、DNS 主机名、或者名字来确认流量是属于哪个
Service
(不会应用xRoute
上的hostname
字段) - 如果
Service
没有配置路由,将应用申请的原始目的地进行转发 - 找到匹配的优先级最高(消费者路由高于生产者路由,见下文)的路由进行转发
- 如果配置了路由,但都无奈匹配,则拒绝请求
- 通过虚构 IP 地址、DNS 主机名、或者名字来确认流量是属于哪个
路由的命名空间
为什么要提命名空间,是因为路由与服务在雷同或者不同命名空间下所代表的含意不同。
同命名空间
路由 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
一致性测试,但截止目前未看到测试报告,预计还在上传中。
关注 ” 云原生指北 ” 公众号
(转载本站文章请注明作者和出处盛世浮生,请勿用于任何商业用途)