欢迎光临
我们一直在努力

意外: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

这里可以看到,利用 sourcesdestination,对服务的访问能力进行了限制。这两个定义来看,只能包含网格内调用,尚无对 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:foobarversion: v1
  • 客户端使用 foobar 的 FQDN 来完成访问。

要调整流量分拆,只需调整 backends 中不同后端服务的权重即可。

流量监控

指标数据的核心分为两个对象种类:resourceedgeresource 代表 podnamespacenode 等对象,而 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 技术很可能会以多极化、市场细分的形式落地。

好像我们猜到了开头,猜错了结局?

参考

文章来源于互联网:意外:Servicemesh Interface(SMI)

赞(0)
未经允许不得转载:莱卡云 » 意外:Servicemesh Interface(SMI)