当咱们创立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提供：
- 有两种管制立体模式：全局（global）和近程（remote）。这在服务网格畛域是十分独特的。
- 有一个新的DNS”.mesh“区域给服务发现。
- 有一种新的“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使整个服务网格基础设施堆栈以统一的形式进行。
“全局”和“近程”架构有几个益处：
- 咱们能够通过扩大“近程”管制立体来独立扩大每个区域，并在某个区域呈现问题时实现HA。
- 没有单点故障：即便“全局”管制立体产生故障，咱们依然能够在“近程”管制立体上注册和登记数据立体代理，并且每个服务的最新地址依然能够流传到其余基于Envoy的边车。
- “全局”管制立体容许咱们主动流传每个区域的状态，同时确保“近程”管制立体理解每个区域的Kuma Ingress，以实现跨区域连贯。
管制立体的拆散管制着如何在区域之间同步Kuma资源（如网格和策略），然而它须要另外两个组件，以便可能以自动化形式在整个区域的数据立体层进行发现和连贯：服务发现和“Ingress”数据立体代理模式。
跨区域发现和连贯
如咱们所述，多区域部署可用于跨多个云和集群部署分布式服务网格，并反对在不同区域运行的服务之间的无缝通信，无效地提供跨区域服务发现和连贯。
在其余用例中，跨区域连贯可用于：
在单个和多云环境中跨多个Kubernetes集群、区域和可用性区域启用高可用性
- 容许流量从一个区域转移到另一个区域，以进行劫难复原
- 通过利用流量控制策略来确定将服务流量从一个区域转移到另一个区域的条件，从而实现咱们的应用程序从VM到Kubernetes（或从物理数据中心到云）的逐渐转换。Kuma的多区域部署通过提供两个重要性能实现跨区域连贯：
- 一种新的“Ingress”数据立体代理模式将传入的流量解决到一个区域。每个区域将部署一个Kuma Ingress，能够随着交通流量的减少而程度伸缩。“Ingress”数据立体模式是在默认代理模式和“网关”模式（以反对第三方API网关）的根底上增加的。因为采纳了新的“Ingress”模式，Kuma不须要区域之间的立体网络拓扑，并且能够反对更简单的基础设施。
- 内置的服务发现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微信公众号。