一文带您了解微软的开放服务网格

仅在几年前，当我们谈论基础架构时，我们指的是物理基础架构：服务器、内存、磁盘、网络交换机以及连接它们所需的所有电缆。我曾经有一些电子表格，在其中插入一些数字并获取构建可支持数千甚至数百万用户的Web应用程序所需的硬件规格。

一切都变了。首先是虚拟基础架构，位于这些物理服务器机架之上。借助一组虚拟机管理程序以及软件定义的网络和存储，我可以指定应用程序的计算要求，并在其他人为我管理的物理硬件之上配置该应用程序及其虚拟网络。如今，在超大规模公共云中，我们正在业务流程框架之上构建分布式应用程序，该框架可自动管理向上和向外的扩展。

使用服务网格来管理分布式应用程序基础结构

这些新的应用程序基础结构需要它们自己的基础结构层，该层足够智能以响应自动扩展，处理负载平衡和服务发现并仍支持策略驱动的安全性。

坐在微服务容器外部，您的应用程序基础结构被实现为服务网格，每个容器都链接到作为边车运行的代理。这些代理管理容器间的通信，使开发团队可以专注于他们的服务和它们托管的API，而应用程序运营团队则管理连接它们的服务网格。

实施服务网格的任何人可能面临的最大问题是：它们太多了：谷歌流行的Istio、开源Linkerd、HashiCorp的Consul或更多的实验工具，例如F5的Aspen Mesh。在整个组织中，很难选择一个，而且仍然很难在一个上实现标准化。

当前，如果要将服务网格与Azure Kubernetes Service一起使用，建议使用Istio，Linkerd或Consul，并将其说明作为AKS文档的一部分。这不是最简单的方法，因为您需要单独的虚拟机来管理服务网格以及AKS上正在运行的Kubernetes集群。但是，正在开发的另一种方法是Service Mesh Interface（SMI），它提供了一套标准的接口，用于将Kubernetes与Service Mesh链接。由于Kubernetes团队一直在领导开发，Azure一直为SMI提供支持。

SMI：一组通用的服务网格API

SMI是像Kubernetes一样的Cloud Native Computing Foundation项目，尽管目前只是一个沙盒项目。处于沙箱中意味着它尚未被认为是稳定的，因为它经历了CNCF开发计划的各个阶段，因此可能会发生重大变化。当然，在云和Kubernetes供应商以及服务网格项目的支持下，有很多支持。SMI旨在为Kubernetes提供一组基本API，以连接到符合SMI的服务网格，因此您的脚本和操作员可以与任何服务网格一起使用。无需锁定单个提供商。

作为一组自定义资源定义和扩展API服务器构建的SMI可以安装在任何经过认证的Kubernetes发行版上，例如AKS。安装到位后，您可以使用熟悉的工具和技术定义应用程序和服务网格之间的连接。SMI应该使应用程序具有可移植性。例如，您可以使用Istio使用SMI在本地Kubernetes实例上进行开发，并将任何应用程序带到具有SMI兼容服务网格的托管Kubernetes中，而不必担心兼容性。

重要的是要记住，SMI本身并不是服务网格。这是服务网格需要实现以具有通用基本功能集的规范。没有什么可以阻止服务网格进一步发展并添加自己的扩展和接口的，但是它们必须具有吸引力才能被应用程序和应用程序运营团队使用。SMI项目背后的人们还注意到，随着服务网格定义的发展和预期功能列表的改变，他们并不反对将新功能移植到SMI规范中。

引入开放式服务网格，Microsoft的SMI实现

微软最近宣布在其在SMI社区中的工作的基础上，推出了首个Kubernetes服务网格。开放服务网格是一种符合SMI的轻量级服务网格，可作为托管在GitHub上的开源项目运行。Microsoft希望OSM成为社区主导的项目，并打算尽快将其捐赠给CNCF。您可以将OSM视为SMI的参考实现，它是基于现有服务网格组件和概念构建的。

尽管Microsoft并未这么明确地说，但在其公告和文档中有其在Azure上使用服务网格的经验，并且着重于操作员方面。在最初的博客文章中，Michelle Noorali将OSM描述为“让Kubernetes操作员毫不费力地安装，维护和运行”。这是一个明智的决定。OSM与供应商无关，但是它很可能成为AKS的众多服务网格选项之一，因此使其易于安装和管理将成为推动接受度的重要组成部分。

OSM建立在其他服务网格项目中完成的工作之上。尽管它具有自己的控制平面，但数据平面是在Envoy上构建的。同样，这是一种务实且明智的方法。SMI与您如何控制和管理服务网格实例有关，因此使用熟悉的Envoy处理策略可以使OSM建立在现有技能集的基础上，减少学习曲线，并允许应用程序操作员从有限的SMI功能集过渡到更复杂的Envoy功能在必要时。

当前，OSM实现了一组通用服务网格功能。其中包括对流量转移的支持，保护服务到服务的链接，应用访问控制策略以及在服务中处理可观察性。OSM通过自动部署Envoy Sidecar代理自动将新的应用程序和服务添加到网格中。

部署和使用OSM

要从OSM alpha版本开始，请从项目的GitHub版本页面下载其命令行界面osm 。运行时osm install，它将使用默认名称空间和网格名称将OSM控制平面添加到Kubernetes集群。您可以在安装时更改它们。安装并运行OSM后，您可以使用策略定义添加服务到网格中，以添加Kubernetes命名空间，并自动将sidecar代理添加到托管命名空间中的所有pod。

这些将实现您选择的策略，因此在开始部署之前设计一套SMI策略是一个好主意。OSM GitHub存储库中的示例策略将帮助您入门。OSM有用地包括Prometheus监视工具包和Grafana可视化工具，因此您可以快速查看服务网格和Kubernetes应用程序的运行方式。

Kubernetes是现代的云原生应用程序中的重要基础架构元素，因此开始将其视之为重要。这要求您将其与运行在其上的应用程序分开进行管理。AKS、OSM、Git和Azure Arc的组合应该为您提供托管Kubernetes应用程序环境的基础。应用程序基础架构团队管理AKS和OSM，设置应用程序和服务的策略，同时Git和Arc控制应用程序的开发和部署，并通过OSM的可观察性工具提供实时的应用程序指标。

所有这些元素完全融合还需要一段时间，但是很明显，微软正在对分布式应用程序管理以及必要的工具做出重大承诺。有了AKS，该套件的基本要素以及OSM和Arc均已添加，因此无需等待。您现在可以使用Envoy作为服务网格在Azure上构建和部署Kubernetes，同时在实验室中对OSM和Arc进行原型制作，以使其适合生产。等待不应该那么久。