内容简介：在今天的 Kubecon（2019.05.21）上，微软宣布了一个新名词：Service Mesh Interface，简称 SMI，是一个运行于 Kubernetes 之上的服务网格规范，定义了一个能够被多个厂商实现的通用标准，其中包含了能够满足绝大多数通用需求的基本特性。SMI 中定义了一组描述能力很有限的对象，用于进行服务网格的控制。的确如前文所说的设计重点一样，仅考虑了最核心（也就是最少）的功能支持，以兼容目前和未来的可能有的网格产品。这一组 API 对 HTTP 和 TCP 服务自身进行了定义，例
在今天的 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 技术很可能会以多极化、市场细分的形式落地。
好像我们猜到了开头，猜错了结局？
参考
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
