共计 3651 个字符，预计需要花费 10 分钟才能阅读完成。
当咱们创立 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 微信公众号。
