Kuma官网人工翻译 部署结构
https://kuma.io/docs/2.5.x/production/deployment/
部署结构总览
kuma的部署方式在service mesh中是非常独特的。并且都是我们在企业用户的指导下开发的，尤其是在分布式部署方面。
kuma可以采用俩种部署模式来在任何地方使用服务网格。从运行一个简单的单点到更复杂一个或多个的kubernetes或者虚拟机的复杂场景，甚至还包括混合的通用型，其中kuma同时在Kubenetes和虚拟机上运行。
这个俩个部署模式是
- 独立（standalone）
kuma在控制平面中默认的部署模式（可水平缩放）和和多个数据平面直接连接。 - 多区域
kuma的高级部署模式，支持多个kubernetes或者虚拟机急群中。或者在kubernetes和虚拟机中共同运行混合服务网格。
自动连接：连接在服务网格中最好是自动的。所以当一个服务使用另一个服务时唯一所必要的信息是目标服务的名称。kuma通过内置的服务发现来提供连接。在多区域部署模式中，还提供了区域CP和区域入口资源
独立部署
关于
这是kuma最简单的部署模式，也是默认的部署模式。
- 控制平面：这是一种可以水平缩放的控制平面的部署模式
- 数据平面代理：这个数据平面代理链接控制平面，而不管控制平面在部署在哪里
- 服务连接：每个数据平面代理都必须能够连接到其他数据平面，无论其他数据平面部署在哪里。
这个模式说明了我们可以部署kuma和它的数据平面代理在独立的网络结构模式下，所以这个服务连接从任意数据平面代理可以直接和任意数据平面代理建立连接。
在区域的上下文中，独立模式通常是一个不错的选择。（在一个kubernetes急群或者一个AWS VPC中）
如果要使用这种结构进行安装，请按照单机部署文档进行操作[Deploy a standalone control plane | Kuma]
局限性
- 所有数据平面代理需要能够与其他所有数据平面代理进行通讯。
- 独立部署模式不能混合使用普通与Kubenetes工作负载
- 独立部署一次只能连接到一个k8s集群
故障模式
控制平面离线
- 新的控制平面代理不能直接加入到网格中。这个包括了新实例（Pod，VM）和新创建的自动部署机器（举个例子滚动更新的过程）。意味着控制平面的连接故障可能会阻止创建新实例的应用程序和时间更新。
- 在启用了mTLS的网格上，数据平面可能无法再到期之前更新他的客户端证书（默认24小时），从而导致该数据平面的流量失败。
- 数据平面代理配置将不能更新
- 数据平面代理之间的通信仍然能工作。
你可以将故障当做冻结区域网格配置。连接仍然有效但是改变不会反应在数据平面代理上。
多区域部署模式
关于
kuma支持在多个区域中运行服务网格。他甚至能够混合使用kubernetes和通用区域运行。你的网格环境可以包含多个隔离的服务网格（多租户）和不同工作地区运行的工作负载，在不同的云服务商或不同的数据中心中。这个集群可以是kubernetes急群或者VPC或者是包含在同一个分布式网络环境中的任何其他部署。唯一的条件是在相同数据平面中所有数据平面必须能够连接到其他数据平面。
如果没有可选的区域出口
要使用这个结构进行安装请参照：
如何工作
在kuma中，区域被抽象出来，这意味着您的数据平面代理将无论运行在哪里，都可以找到服务。通过这种方式，通过这种方式，您可以在不同的区域中使用相同的kuma.io/service，使数据平面成为多区域服务。这使您能够在特定区域出现故障时自动进行故障转移。
让我们看一下服务zone-b的后端是如何被广播到zone-a的以及来自本地zone-a的请求如何被路由到zone-b中的远程服务。
目的服务区域
当新服务后端加入了网格zone-b中，zone-b区域控制平面添加这个服务在zone-b上的availableService（可用服务）ZoneIngress 资源。作为区域入口运行的kuma-dp代理使用服务列表进行配置以便他能路由进入的请求。这个ZoneIngress也会被同步到全局的控制平面。
这个全局的控制平面将通过Kuma发现服务（KDS）广播区域入口资源和政策到其他节点，他是一个基于xDS的协议。
资源服务区域
zone-b ZoneIngress资源从全局控制平面同步到zone-a区域控制平面。请求从zone-a到availableService的请求在该服务的本地实例和远程实例之间进行负载均衡。 发送到zone-b的请求被路由到zone-b的区域入口代理。
对于负载均衡，区域入口端点（endpoint）根据其背后的实例数进行加权。所以有俩个实例的区域收到的请求会是有单个实例区域的俩倍。你还可以使用位置感知负载均衡在本地服务中。
在存在区域出口)时，流量在被发送到远程区域入口之前被路由通过本地区域出口。
如果使用了透明代理(k8s默认)，kuma生成一个VIP，一个格式为<kuma.io/service>.mesh的DNS条目，同时在80端口上监听流量。<kuma.io/service>.mesh:80格式化只是习惯。VirtualOutbounds使您能够自定义监听端口以及这些服务的DNS名称
区域入口不是API网关，它只适用于网格内的跨区域通信。kuma网关支持API网关同时也能够部署增加区域入口。
多区域部署的组件
多区域部署包括了
全局控制平面
- 仅接受来自区域控制平面的连接。
- 接受将应用于数据平面代理的策略进行创建和修改。
- 将策略下发到区域控制平面。
- 下发区域入口（ingresses 复数）到区域控制平面。
- 保留所有区域中运行的数据平面代理清单。（这样做只是为了可观测性，而不是操作所必须的）
- 拒绝来自数据平面代理的连接。
区域控制平面
- 接收来自此区域内启动的数据平面代理连接。
- 在全局控制平面中接受策略更新
- 向全局控制平面中发送数据平面代理和区域入口变化
- 使用XDS计算和发送配置到本地数据平面代理
- 更新区域入口中区域中存在的服务列表
- 拒绝非来自全局的策略改变
数据平面代理
- 连接本地区域控制平面
- 使用XDS从本地区域控制平面中接受配置
- 连接其他本地数据平面代理
- 连接到区域入口以发送跨区域流量
- 从本地数据平面代理和本地区域入口中接收流量
区域入口
- 从本地区域控制平面中接收XDS配置
- 在本地数据平面代理中代理其他区域数据平面代理的流量
区域出口
- 从本地区域控制平面中接受XDS配置。
从本地数据平面代理中代理流量
- 来自其他区域的区域入口代理
- 来自本地区域的对外服务
故障模式
全局控制平面下线
- 策略将不能更新
区域之间服务列表的更改不会传播
- 新服务将不能发现其他区域
- 从区域中删除的服务在其他区域中仍可用/
- 你无法禁用或删除区域
请注意，本地和跨区域应用程序流量不受此故障影响。数据平面代理更改将在区域内传播。
区域控制平面下线
- 新的数据平面代理不能加入的网格。这包括由自动部署机制（例如滚动更新过程）新创建的新实例（Pod、VM）。意味着控制平面连接故障可能会组织创建新实例的应用程序和事件的更新。
- 在启用了mTLS的网格上，数据平面代理可能无法在到期前刷新其客户端证书（默认为24小时），从而导致来自/到该数据平面的流量失败。
- 数据平面代理配置将不会更新
- 数据平面代理之间的通信仍然有效
- 跨区域连接仍然有效
- 其他区域不受影响
你可以将故障当做冻结区域网格配置。连接仍然有效但是改变不会反应在数据平面代理上。
全局和区域控制平面之间的通信失败
这可能发生在控制平面之间的错误配置或网络连接上。
- 区域内的操作将正常运行。（数据平面代理能够加入、离开，并且所有配置都能更新并正确发送）
策略更新将不会传播搭到区域控制平面
- 数据平面的全局清单将会过期（这只会影响可观测性）
- 其他区域将看不懂此区域内注册的新服务
- 其他区域将看不懂服务不再此区域内运行
- 其他区域将不会看到本地区域中运行的每个服务的实例数发生变化。
全局控制平面不会讲其他区域入口的更改发送到该区域。
- 本地数据平面代理将不能看到新服务注册到其他区域中
- 本地数据平面代理将不能看到服务不再在其他区域中运行。
- 本地数据平面代理将不能看到在其他区域中运行的每个服务的实例数的变化。
- 全局控制平面不会讲来自其他区域入口的更改发送到该区域
注意本地和跨区域应用通信将不受这个故障影响
俩个区域之间通信失败
如果存在网络连接问题可能会发生这种情况：
- 在控制平面和从其他区域进入的区域之间。
- 控制平面和区域出口之间（如果存在）。
- 区域出口（如果存在）和其他区域的区域入口之间。
- 一个区域的所有区域出口实例（如果存在）都已关闭。
- 一个区域的所有区域入口实例都已关闭。
当它发生时：
- 每个区域内的通信和操作不受影响。
- 每个区域之间的通信都将失败。
通过正确的恢复设置(Retries：重试, Probes：探测, Locality Aware LoadBalancing：局部感知负载均衡, Circuit Breakers：断路器) 能够将故障区域快速切断并转移到另一个区域。