在今天的 Kubecon(2019.05.21)上,微软宣布了一个新名词:Service Mesh Interface,简称 SMI,是一个运行于 Kubernetes 之上的服务网格规范,定义了一个能够被多个厂商实现的通用标准,其中包含了能够满足绝大多数通用需求的基本特性。
SMI 中定义了一组描述能力很有限的对象,用于进行服务网格的控制。的确如前文所说的设计重点一样,仅考虑了最核心(也就是最少)的功能支持,以兼容目前和未来的可能有的网格产品。
这一组 API 对 HTTP 和 TCP 服务自身进行了定义,例如:
apiVersion: specs.smi-spec.io/v1alpha1
kind: HTTPRouteGroup
metadata:
name: the-routes
matches:
- name: metrics
pathRegex: "/metrics"
methods:
- GET
- name: health
pathRegex: "/ping"
methods: ["*"]
---
apiVersion: specs.smi-spec.io/v1alpha1
kind: TCPRoute
metadata:
name: tcp-route
观察这一段代码样本,其 HTTP 部分,对服务端的路径、动作都做能做出详细的定义。未来这里还将加入对 Header 和 gRPC 的支持,SMI 发起者们认为这是一个很方便利用 OpenAPI 等工具自动生成的部分。它是一个基础,可以用于访问控制、频率限制等高级功能。
SMI 提供了一个很简单的访问控制功能,同样是使用 CRD 的方式,例如下面的代码:
kind: TrafficTarget
apiVersion: access.smi-spec.io/v1alpha1
metadata:
name: path-specific
namespace: default
destination:
kind: ServiceAccount
name: service-a
namespace: default
port: 8080
specs:
- kind: HTTPRouteGroup
name: the-routes
matches:
- metrics
sources:
- kind: ServiceAccount
name: prometheus
namespace: default
这里可以看到,利用 sources
和 destination
,对服务的访问能力进行了限制。这两个定义来看,只能包含网格内调用,尚无对 Ingress/Egress 流量的支持。
前面提到,流量拆分是在流量规范的基础上定义的,因此其定义相对简单:
apiVersion: split.smi-spec.io/v1alpha1
kind: TrafficSplit
metadata:
name: foobar-rollout
spec:
service: foobar
backends:
- service: foobar-v1
weight: 1
- service: foobar-v2
weight: 0m
这里的服务定义和 Istio 不同,这个对象的候选访问目标,是选择条件重叠的一组独立服务。典型工作流:
foobar-v1
的 Deployment,标签为 app: foobar
version: v1
。foobar
,选择器定义为 app: foobar
。foobar-v1
,选择标准为 app:foobar
且 version: v1
。foobar
的 FQDN 来完成访问。要调整流量分拆,只需调整 backends
中不同后端服务的权重即可。
指标数据的核心分为两个对象种类:resource
和 edge
,resource
代表 pod
、namespace
、node
等对象,而 edge
则描述了流量的方向。
apiVersion: metrics.smi-spec.io/v1alpha1
kind: TrafficMetrics
# See ObjectReference v1 core for full spec
resource:
name: foo-775b9cbd88-ntxsl
namespace: foobar
kind: Pod
edge:
direction: to
resource:
name: baz-577db7d977-lsk2q
namespace: foobar
kind: Pod
timestamp: 2019-04-08T22:25:55Z
window: 30s
metrics:
- name: p99_response_latency
unit: seconds
value: 10m
- name: p90_response_latency
unit: seconds
value: 10m
- name: p50_response_latency
unit: seconds
value: 10m
- name: success_count
value: 100
- name: failure_count
value: 100
监控资源除了满足 Prometheus 等监控系统的使用之外,还能对服务拓扑、集群资源监控以及金丝雀发布等功能提供数据支持。
下图是这一新组织的合作方(没有 Google 好奇怪):
其中多数厂商大家都非常熟悉了,有几个补充一下:
Solo.io 的 Service Mesh Hub 和 SuperGloo 已经更新,宣布对 SMI 的支持。
根据 Github 的数据,目前贡献前两名分别是 Buoyant 和 HashiCorp。
在去年 InfoQ 的 《Service Mesh2018年度总结》一文中有这么一段话:
Service Mesh 这一技术的广阔前景,加上 Istio 的疲弱表现,吸引了更多对此技术具有强烈需求或相关技术储备的竞争者出现,除了 AWS 、 F5 这样的公有云方案,以及 Consul、Kong 等同类软件解决方案,还出现了 Solo.io 这样的更加激进的跨云方案加入战团。 Service Mesh技术的浪潮已将业界席卷其中,然而这一年来,角逐者有增无减,2019 年里,Istio 仍是关键——除非 Istio 能够做出符合顶尖项目的水准,否则,Service Mesh 技术很可能会以多极化、市场细分的形式落地。
好像我们猜到了开头,猜错了结局?