27

意外：Servicemesh Interface（SMI）

 4 years ago
source link: https://www.tuicool.com/articles/RRZrYnR
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

在今天的 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 好奇怪 ）：

qmyMrmi.png!web

其中多数厂商大家都非常熟悉了，有几个补充一下：

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

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

参考


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK