使用CNCF的Kuma和Envoy运行多集群和多云服务网格

本文主要是介绍使用CNCF的Kuma和Envoy运行多集群和多云服务网格，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

当我们创建Kuma（日语中“熊”的意思）时，我们梦想创建一个可以跨每个集群、每个云和每个应用程序运行的服务网格。这些都是大型组织必须实现的需求，以支持他们的应用程序团队跨各种架构和平台：VM、Kubernetes、AWS、GCP等等。

Kuma现在是CNCF的一个项目，在撰写本文时，它是唯一一个向基金会捐赠并获接受的以Envoy为基础的服务服务，我们一直不懈地在社区中执行这个愿景。（编者按：在发布本文时，Open Service Mesh是另一个向基金会捐赠并获接受的以Envoy为基础的服务服务。）

从今年夏天发布的具有先进多区域（multi-zone）功能的Kuma 0.6开始，Kuma现在在一个多网格控制平面上支持每一个云供应商、每一个架构和每一个平台。在多区域部署中部署时，Kuma抽象了跨多个区域的服务网格策略的同步，以及跨这些区域的服务连通性（和服务发现）。区域可以是一个Kubernetes集群、一个数据中心、一个云区域、一个VPC、一个子网等等--我们可以按照自己的喜好分割区域，我们还可以将Kubernetes和VM工作负载混合到一个分布式网格部署中。

Kuma创建了一个服务连接覆盖混合基础设施自动发现和连接服务，包括混合Kubernetes + VM服务。

自第一天起，Kuma就推出了多网格支持，增加了的多区域功能可以在同一个集群上创建多个隔离的网格（具有专用的mTLS CA），减少了团队协调，增加了隔离并提高了安全性。而不是每个人都共享的一个大型服务网格。此外，由于多区域利用了自Kuma第一个版本以来提供的一流的K8s + VM支持，因此组织中的所有团队和工作负载都可以受益于服务网格，而不仅仅是我们的新项目。

因此，团队使用分布在每个云、集群和工作负载上的Kuma服务网格，可以从一个单独的Kuma集群本身进行管理。同时，多个服务网格可以在一个Kuma控制平面上提供（水平可伸缩），以简化跨组织的网格管理--非常类似于Kubernetes及其名称空间的工作方式。

Kuma在同一个部署上支持多个虚拟网格，消除了为每个应用程序提供多个服务网格集群的需求，从而显著降低了ops成本。

使用KDS扩展xDS

我们在Kuma可以通过利用“多区域”部署模式，在多个集群、云或区域之间部署分布式服务网格。“多区域”部署是在v0.6+中引入的一种运行Kuma的新方式，另外还有“独立”部署模式（每个区域一个服务网格）。

在多区域部署中，有几个重要的功能，Kuma提供：

1. 有两种控制平面模式：全局（global）和远程（remote）。这在服务网格领域是非常独特的。
2. 有一个新的DNS”.mesh“区域给服务发现。
3. 有一种新的“Ingress”数据平面代理类型，可以在Kuma网格内实现区域之间的连接。

在分布式部署中，“全局”控制平面将负责接受Kuma资源，通过原生Kubernetes CRD或基于VM的部署中的YAML来确定服务网格的行为。它将负责将这些资源传播到“远程”控制平面--每个我们想要支持的区域都有一个。

“远程”控制平面将通过Envoy xDS API的扩展与“全局”控制平面交换Kuma资源，我们将该API称为KDS（Kuma Discovery Service），通过gRPC协议，也就是通过HTTP/2。“远程”控制平面还将接受来自基于Envoy的数据平面代理的请求，这些代理属于传统xDS上的同一区域。

远程控制平面还嵌入一个DNS服务发现，可用于发现跨不同区域的服务。上面的架构很容易地安装，只需通过几个步骤使用Kuma CLI “kumactl”或HELM chart。

在Kuma里，我们将Envoy代理过程抽象为“kuma-dp”过程，使用户不必直接配置或启动“envoy”，从而使启动数据平面代理的整个过程更加容易。高级用户如果他们愿意的话，仍然可以访问底层的“envoy”进程。

利用Envoy原生的xDS API在每个区连接“kuma-dp”与“远程”控制平面，以及利用KDS连接“远程”控制平面到全局控制平面，实际上我们使用了gRPC使整个服务网格基础设施堆栈以一致的方式进行。

“全局”和“远程”架构有几个好处：

1. 我们可以通过扩展“远程”控制平面来独立扩展每个区域，并在某个区域出现问题时实现HA。
2. 没有单点故障：即使“全局”控制平面发生故障，我们仍然可以在“远程”控制平面上注册和注销数据平面代理，并且每个服务的最新地址仍然可以传播到其他基于Envoy的边车。
3. “全局”控制平面允许我们自动传播每个区域的状态，同时确保“远程”控制平面了解每个区域的Kuma Ingress，以实现跨区域连接。

控制平面的分离控制着如何在区域之间同步Kuma资源（如网格和策略），但是它需要另外两个组件，以便能够以自动化方式在整个区域的数据平面层进行发现和连接：服务发现和“Ingress”数据平面代理模式。

跨区域发现和连接

如我们所述，多区域部署可用于跨多个云和集群部署分布式服务网格，并支持在不同区域运行的服务之间的无缝通信，有效地提供跨区域服务发现和连接。

在其他用例中，跨区域连接可用于：

在单个和多云环境中跨多个Kubernetes集群、区域和可用性区域启用高可用性

• 允许流量从一个区域转移到另一个区域，以进行灾难恢复
• 通过利用流量控制策略来确定将服务流量从一个区域转移到另一个区域的条件，从而实现我们的应用程序从VM到Kubernetes（或从物理数据中心到云）的逐步转换。Kuma的多区域部署通过提供两个重要功能实现跨区域连接：

1. 一种新的“Ingress”数据平面代理模式将传入的流量处理到一个区域。每个区域将部署一个Kuma Ingress，可以随着交通流量的增加而水平伸缩。“Ingress”数据平面模式是在默认代理模式和“网关”模式（以支持第三方API网关）的基础上添加的。由于采用了新的“Ingress”模式，Kuma不需要区域之间的平面网络拓扑，并且可以支持更复杂的基础设施。
2. 内置的服务发现DNS服务器将服务的地址解析为同一区域中副本的IP地址或另一个区域中的入口代理的地址。同样，“全局”和“远程”控制平面也可以按照Kuma上的多区域指令，点击一下即可安装Ingress和DNS服务发现。

在服务发现方面，Kuma在内置DNS解析器上创建一个“.mesh”DNS条目，该条目可用于解析同一区域或其他区域中的服务，从而有效地“扁平化”跨复杂基础设施的服务发现。根据已配置的流量路由策略，Kuma将确定我们是否应该使用本地区域中的服务副本，还是应该将请求解析为另一个区域中的Kuma Ingress的IP地址，然后利用SNI确定已请求了哪些服务，并相应地路由请求。

在这个示例中，我们有三个服务（users、invoices和billing）。“invoices.mesh”的请求将被代理到同一区域内的一个IP地址，而“billing.mesh”的请求则被自动代理到另一个区域的Ingress。

由于SNI对于跨区域通信是强制性的，因此必须在网格上启用mTLS策略。此外，由于Kuma已经知道所有的服务在哪里运行，跨区域发现和连接将自动发生。

当一个新的服务被注册到Kuma，一个新的“kuma.io/zone”标签被添加到数据平面定义中，这样我们就可以使用基于属性的策略选择器来配置Kuma策略，比如流量路线，以确定跨区域流量的行为（不同区域的蓝/绿或灰度，加权流量，以及流量移动）。

使用默认端口80上的任何“{service-name}.mesh”（即使服务未在端口80上侦听）时，DNS解析器（除了解析服务的地址外）还将自动解析以下端口：目标服务并将其注入到连接中，以保持整个连接的正常运行时间，即使一个团队决定重新分配其他团队可能正在使用的服务端口。此功能减少了在Kuma网格中维护大量服务和连接所需的团队协作。

总结

多得了自v0.6+以来Kuma提供的新的多区域功能，我们现在可以轻松地跨多个Kubernetes集群、云和区域运行服务网格。由于Kuma原生既支持容器化工作负载，又支持VM工作负载，因此该功能还可以用于创建跨混合架构的服务连通性。

通过提供一键式安装步骤来自动安装新区域以及诸如全局/远程控制平面，内置服务发现和本机Kuma Ingress之类的功能，Kuma抽象化服务连接性，通过创建有效覆盖的网络让服务跨复杂的网络拓扑发现和使用彼此。这使其非常适合任何企业或分布式环境。

要启动和运行Kuma，你可以查看安装页面以及官方的Slack频道。

网格快乐！🚀

点击阅读网站原文。

CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux  Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。扫描二维码关注CNCF微信公众号。

这篇关于使用CNCF的Kuma和Envoy运行多集群和多云服务网格的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！