意外：Servicemesh Interface（SMI）
在今天的 Kubecon（2019.05.21）上，微软宣布了一个新名词：Service Mesh Interface，简称 SMI，是一个运行于 Kubernetes 之上的服务网格规范，定义了一个能够被多个厂商实现的通用标准，其中包含了能够满足绝大多数通用需求的基本特性。
设计重点
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: foobarversion: 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/