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

  • 来源:网络
  • 更新日期:2020-08-14

摘要:仅在几年前,当我们谈论基础架构时,我们指的是物理基础架构:服务器、内存、磁盘、网络交换机以及连接它们所需的所有电缆。我曾经有一些电子表格,在其中插入一些数字并获取构建可

仅在几年前,当我们谈论基础架构时,我们指的是物理基础架构:服务器、内存、磁盘、网络交换机以及连接它们所需的所有电缆。我曾经有一些电子表格,在其中插入一些数字并获取构建可支持数千甚至数百万用户的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进行原型制作,以使其适合生产。等待不应该那么久。

新网箭头云服务器