意外：Servicemesh Interface（SMI）

在今天的 Kubecon（2019.05.21）上，微软宣布了一个新名词：Service Mesh Interface，简称 SMI，是一个运行于 Kubernetes 之上的服务网格规范，定义了一个能够被多个厂商实现的通用标准，其中包含了能够满足绝大多数通用需求的基本特性。

设计重点

1. Kubernetes 服务网格的标准接口。
2. 实现最通用的服务网格用例支持。
3. 能够支持新晋厂商加入的兼容能力。
4. 建立有创新空间的生态系统，促进服务网格技术的发展。

规范内容

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 方面大有名气的 SuperGloo 和 Service Mesh hub 之外，还有远程调试、混沌工程、unikernels 以及微服务网关等几个产品。
• Mesery 和 Kinvolk：近期都发表了 Istio vs Linkerd 的性能测试报告。
• Canonical：Ubuntu 母公司。
• Kubecost：对 Kubernetes 集群进行成本分析。

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 技术很可能会以多极化、市场细分的形式落地。

好像我们猜到了开头，猜错了结局？

参考

• https://link.medium.com/zsUhK6OgSW
• https://github.com/deislabs/smi-spec
• https://msft.today/hello-service-mesh-interface-smi-a-specification-for-service-mesh-interoperability/
• https://skyao.io/publication/201902-service-mesh-2018-summary/