Kuma 提供的部署模式在 service mesh 领域非常独特，有两种部署模式：
- 独立式：Kuma 的默认部署模型具有一个控制平面（可以水平扩展）和许多直接与其连接的数据平面。
- 多区域：Kuma 的高级部署模型支持多个 Kubernetes 或基于 VM 的区域，或在 Kubernetes 和 VM 上运行的混合服务网格。
独立部署
这是 Kuma 最简单的部署模式，也是默认的部署模式。
- 控制平面：有一种可以水平扩展的控制平面部署。
- 数据平面代理：数据平面代理连接到控制平面，无论部署在何处。
- 服务连接性：每个数据平面代理都必须能够连接到每个其他数据平面代理，无论它们部署在何处。
独立部署模式下，有一定的局限性：
- 要求所有的数据平面代理与其他所有的数据平面代理都能进行通信。
- 独立部署只能连接到一个集群。
- 无法混合 Universal 和 Kubernetes 集群工作负载。
组件
独立部署包括：
- 控制平面（kuma-cp）：
- 接受来自数据平面代理的连接。
- 接受对将应用于数据平面代理的策略的创建和更改。
- 保存所有正在运行的数据平面代理的清单。
- 使用 XDS 将配置发送到数据平面代理。
- 数据平面代理（envoy）：
- 连接到区域控制平面。
- 使用 XDS 从控制平面接收配置。
- 连接到其他数据平面代理。
失效模式
控制平面离线：
- 新的数据平面代理将无法加入网格。这包括通过自动部署机制（例如滚动更新过程）新创建的新实例（Pod/VM），这意味着控制平面连接故障可能会阻止应用程序的更新和创建新实例的事件。
- 在启用 mTLS 的网格上，数据平面代理可能无法在到期（默认为 24 小时）之前刷新其客户端证书，从而导致来自/流向该数据平面的流量失败。
- 数据平面代理配置将不会更新。
- 数据平面代理之间的通信仍然有效。
多区域部署
Kuma 支持多区域部署，甚至是 Kubernetes 集群和 Universal 集群的混合部署。
运行机制
在 Kuma 中将服务标记以 kuma.io/service 标签标记，这意味着运行在任何地方的数据平面代理可以通过 kuma.io/service 标签值找到该服务。不同区域上的同一服务用相同的 kuma.io/service 标记，可以在特定区域发生故障时自动进行服务故障转移。
如果一个新的后端服务 serviceA 部署在区域 zone-b，下面看这两个问题。
- 这个新的后端服务如何被通告到 zone-a 区域（区域间的同步）。
- 一个来自于 zone-a 区域的请求如何被路由到 zone-b 区域（区域间的请求路由）。
区域间的信息同步
当 zone-b 区域中加入了一个新的服务 serviceA 后，区域间的信息同步如下：
- zone-b 的控制面将该服务加入到 zone-b Ingress 资源的 availableServices（可用服务列表）中，Ingress 持有可用服务列表，以便可以路由区域外的请求。
- zone-b 的控制平面也会将该区域的 Ingress 资源信息（Ingress 的地址等），同步到 Global 全局控制平面。
- 全局控制平面将通过 Kuma 发现服务（KDS，基于 xDS 的协议）将区域入口 Ingress 资源和所有策略传播到所有其他区域。
区域间的请求路由
当 zone-a 中有请求想请求 serviceA 服务时：
- 首先会进行本地服务和远程服务之间的负载均衡，决定发往本区域服务还是远程区域服务。
- 如果存在区域 Egress，流量会先通过本地区域 zone-a 出口进行路由，然后再发送到远程区域 zone-b 入口。
- 远程区域 zone-b 入口收到请求后，路由到本地服务 ServiceA。
对于负载平衡，是根据其后面运行的实例数量进行加权。因此，具有 2 个实例的区域接收的流量是具有 1 个实例的区域的两倍。可以配置位置感知的负载均衡，来支持本地服务实例。
组件
多区域部署包括：
- 全局控制平面（Global kuma-cp）：
- 仅接受来自区域控制平面的连接。
- 接受对将应用于数据平面代理的策略的创建和更改。
- 将策略发送到区域控制平面。
- 将区域入口向下发送到区域控制平面。
- 保留所有区域中运行的所有数据平面代理的清单（这样做只是为了可观察性，但对于操作不是必需的）。
- 拒绝来自数据平面代理的连接。
- 区域控制平面（Zone kuma-cp）：
- 接受来自该区域内启动的数据平面代理的连接。
- 从全局控制平面接收策略更新。
- 将数据平面代理和区域入口的更改发送到全局控制平面。
- 使用 XDS 计算配置并将其发送到本地数据平面代理。
- 更新区域入口中区域中存在的服务列表。
- 拒绝非来自全球的政策变化。
- 数据平面代理（Envoy）：
- 连接到本地区域控制平面。
- 使用 XDS 从本地区域控制平面接收配置。
- 连接到其他本地数据平面代理。
- 连接到区域入口以发送跨区域流量。
- 从本地数据平面代理和本地区域入口接收流量。
- 区域入口（Ingress）：
- 从本地区域控制平面接收 XDS 配置。
- 从其他区域数据平面代理到本地数据平面代理的代理流量。
- （可选）区域出口（Egress）：
- 从本地区域控制平面接收 XDS 配置。
- 来自本地数据平面代理的代理流量：
- 来自其他区域的区域入口代理；
- 从本地区域到外部服务。
失效模式
全局控制平面离线
- 政策更新将不可能。
- 区域之间服务列表的更改不会传播：
- 在其他区域中将无法发现新服务。
- 从区域中删除的服务在其他区域中仍将显示为可用。
- 无法禁用或删除区域。
本地和跨区域应用程序流量均不会受到此故障情况的影响；数据平面代理更改将在其区域内传播。
区域控制平面离线
- 新的数据平面代理将无法加入网格。这包括通过自动部署机制（例如滚动更新过程）新创建的新实例（Pod/VM），这意味着控制平面连接故障可能会阻止应用程序的更新和创建新实例的事件。
- 在启用 mTLS 的网格上，数据平面代理可能无法在到期（默认为 24 小时）之前刷新其客户端证书，从而导致来自/流向该数据平面的流量失败。
- 数据平面代理配置将不会更新。
- 数据平面代理之间的通信仍然有效。
- 跨区域通信仍然有效。
- 其他区域不受影响。
这种故障案例，与独立部署的控制平面离线故障一致。
全局和区域控制平面之间的通信失效
控制平面之间的配置错误或网络连接问题可能会发生这种情况：
区域内的操作是正常的（数据平面代理可以加入、离开，所有配置都将正确更新和发送）。
策略更改不会传播到区域控制平面。
区域 Ingress，区域 Egress 和数据平面的变更不会传播到全局控制平面：
- 数据平面代理的全局清单视图将过时（这只会影响可观察性）。
- 其他区域不会看到该区域内注册的新服务。
- 其他区域不会看到该区域不再运行某服务。
- 其他区域不会看到本地区域中运行的每个服务的实例数量发生变化。
全局控制平面不会将其他区域入口的更改发送到该区域：
- 本地数据平面代理不会看到在其他区域注册的新服务。
- 本地数据平面代理将看不到其他区域不再运行某服务。
- 本地数据平面代理不会看到在其他区域中运行的每个服务的实例数量的变化。
本地和跨区域应用程序流量均不会受到此故障情况的影响。
两个区域之间的通信失效
如果存在区域之间的网络连接问题，可能是以下原因：
- 在控制平面和来自其他区域的区域入口之间。
- 在控制平面和区域出口之间（如果存在）。
- 在区域出口（如果存在）和其他区域的区域入口之间。
- 区域的所有区域出口实例（如果存在）均已关闭。
- 区域的所有区域入口实例均已关闭。
当它发生时：
- 每个区域内的通信和操作不受影响。
- 每个区域之间的通信将失败。
通过配置正确的弹性设置（重试、探针、局部感知负载均衡、断路器），可以快速切断故障区域并将流量重新路由到另一个区域。