InfoQ 专访：Kubernetes 上的服务生态系统

服务网格接口（Service Mesh Interface，简称 SMI）是微软牵头的多家公司最近刚宣布的一项全行业规范倡议，它旨在定义一组通用的、可移植的 API，为开发人员提供跨不同服务网格技术的互操作性。SMI 的宣布在Kubecon欧盟场的主题演讲中占据了显著地位。

随着微服务、容器以及诸如 Kubernetes 之类的编排器的大量使用，服务网格技术变得越来越重要。由于服务网格技术的不断涌现，许多厂商都推出了各种平台来促进应用程序的开发。然而，这存在厂商锁定的风险，开发人员将应用程序从一个平台迁移到另一个平台的可移植性。

在上层，SMI 提供如下功能：

• Kubernetes 上的服务网格标准接口

• 用于最通用的服务网格用例的基本特性

• 随着时间的推移灵活地支持新的服务网格能力

• 使用服务网格技术实现生态系统创新的空间

SMI 借鉴了 Kubernetes 资源 Ingress 等的原理，定义了一组通用的 API，并允许厂商提供自己的最佳实现。使用这些 API 编程能为应用程序提供可移植性。

InfoQ 就 SMI 的发布采访了微软首席项目经理Lachlan Evenson。讨论的主题还包括 Kubernetes 上的服务网格生态系统及 Gabe Monroy博客上的引用。

InfoQ：在 KubeCon 欧洲场的主题演讲中谈到“智能端点和哑管道（smart endpoints and dumb pipes）”，以及随着微服务的发展，这些管道现在需要怎样变得更加智能，您能概括下这意味着什么吗？

Evenson：多年来，网络体系结构的口号是尽可能保持网络管道的静音，并在应用程序中构建智能。网络的任务是转发数据包，而用于加密、压缩或身份认证的任何逻辑都应存在于网络端点内。互联网是以这句格言为前提的，所以你可以说它运行得相当好。

但是今天，随着微服务、容器和诸如 Kubernetes 之类的编排系统的爆炸式发展，工程团队面临着越来越多的网络端点安全、管理和监控问题。服务网格技术通过使网络变得更智能，为解决这个问题提供了解决方案。服务网格技术不是教所有的服务加密会话、授权客户端、发射合理的遥测数据，也不是在应用程序版本之间无缝地转移流量，而是将这种逻辑推送到由一组单独管理的 API 控制的网络中。

InfoQ：我们可以先谈下微服务和服务网格的关系吗？根据 Kubecon 欧洲场的走廊讨论，SMI 对于一般的微服务，尤其是对于 Kubernetes 来说，似乎还处于采用生命周期的早期，是这样吗？

Evenson：如我们所见，由于服务网格技术的激增，许多厂商为应用程序开发人员提供了新的、令人兴奋的选择。但问题是，转向网格技术的开发人员必须选择一个厂商提供者并直接编写他们的 API。他们被锁定了在服务网格实现中。如果没有通用的接口，开发人员将失去可移植性和灵活性，并且从广泛生态系统创新中获益的能力也会受到限制。

除了 Gabe Monroy 在博客中提到的内容外，现在的时机正适合 SMI，因为与社区中的其他通用的抽象（CNI、CRI、Ingress、NetworkPolicy）一样，它们专注于解决开发人员的需求，而不是指定技术实现。在服务网格领域创建一组通用的抽象，能促进生态系统的增长，并能为开发人员和集群管理员提供选择最佳类实现的自由。

InfoQ：您能提供下更多的关于服务网格接口的技术细节，并解释下这主要是针对开发人员的还是平台提供商的吗？如果是针对平台提供商的，它会以怎样方式影响开发人员呢？

Evenson：它是以不同的方式来针对两者的。它允许平台提供商为最常用的服务网格特性提供单一抽象，同时能保持为作业选择最佳实现的自由。这使平台能够保持灵活性和一定的可移植性，同时使用户能够访问最需要的服务网格特性。

从开发人员的角度来看，他们现在有了一组可以从服务网格中获取需求的 API。这些通用抽象删除了实现中的某些特性。例如，“我希望能为我的服务提供金丝雀部署”是一个常见的问题，他们可以简单地使用 SMI TrafficSplit API 来处理这种复杂问题，而不必编写离散的低级资源程序。

InfoQ：在主题演讲中，提到服务网格接口类似于 Kubernetes 资源Ingress（在 Kubernetes 1.1 中引入）。公平地说，Ingress 的功能范围非常具体。而 SMI 则试图提供跨多个不同的平台（ISTIO、Linkerd、Consul 等）的通用接口，这些平台具有比网络 ingress 更多的功能。那将如何克服这一挑战呢？

Evenson：我们不是只关注服务网格生态系统的原始功能，而是与企业客户合作，来了解他们关注服务网格的首要需求。我们让这些共同的企业需求引导我们在 SMI 中创建抽象。

InfoQ： 服务网格空间中有大量的使用 isito，那么有多少 isito 内部构件或概念将出现在 SMI 中？或者是，SMI 仅关注服务网格提供的核心功能呢？

Evenson：是后者，SMI 将根据我们从企业客户那里了解到他们为什么使用服务网格，并基于这些信息提供最通用的抽象。

InfoQ：您能谈下 SMI 社区及其路线图吗?

Evenson：SMI 是一个开放项目，由微软、Linkerd、HashiCorp、Solo.io、Kinvolk 和 Weaveworks 联合启动。并得到了 Aspen Mesh、Canonical、Docker、Pivotal、Rancher、Red Hat 和 VMware 的支持。

我们联合 HashiCorp、Buoyant、Solo.io 和其他公司根据从企业客户处了解到的三大服务网格功能构建初始规范：

• 流量策略－跨服务应用身份和传输加密等策略

• 流量遥测 － 捕获关键指标，如错误率和服务间的延迟

• 流量管理 - 在不同服务之间转移流量

这只是我们希望通过 SMI 实现目标的开始阶段。随着更多令人兴奋的网格功能的开发，随着时间的推移，我们完全可以期待 SMI API 的逐步发展，期待新的功能可以扩展当前的规范。

我们正在与创始合作伙伴一起，识别其他应该定义的 API，也在为即将到来的项目里程碑构建路线图。

综上所述，服务网格技术已经引起应用程序开发人员的极大关注。SMI 借鉴了经过时间考验的应用程序开发原则，旨在为多个厂商和平台提供商提供统一的规范来实现在服务网格实现上的竞争，同时通过一组通用接口为应用程序开发人员提供可移植性。

请访问smi-spec.io 了解更多关于 SMI 的详细信息，了解规范本身的相关信息请访问 GitHub。

原文链接：

Service Mesh Interface (SMI): Q&A with Microsoft’s Lachlan Evenson