概述
介绍
Kuma 是一个与平台无关的开源控制平面，用于 service mesh 和微服务的管理，支持 Kubernetes，VM 和 裸机环境。Kuma 有以下特性：
- 兼容通用环境和 Kubernetes 环境：与平台无关，可以在任何地方运行和操作。
- 独立和多区域：可以独立部署，也支持多区域、多集群。
- 多服务网格：可以通过一个控制平面管理多个单独的服务网格，降低整个组织的运维成本。
- 基于属性的策略：允许通过 tag 细粒度的选择 source 和 destination 策略。
- 基于 Envoy：采用 Envoy 作为数据平面。
- 水平扩展。
Kuma 多集群部署示例图如下：
工作原理
Sidecar
在编写网络应用程序时，会遇到可观测性、流量管理、安全性等共性问题。可以当然可以采用 sdk 的形式去将这些问题集成在框架中，但这是和语言相关的，必须为每一种编程语言提供这样的 sdk，并且需要考虑不同语言之间的兼容性问题。
一个想法是采用 sidecar 代理：将所有网络连接中可观测性、流量管理等问题，委托给进程外的 sidecar 完成，sidecar 接管所有传入和穿出的请求和响应。开发人员可以专注于应用程序本身，而不是处理复杂的网络问题上去。
由于一个系统具有多个服务，每一个服务有许多实例，这要求具有相同数量的代理。因此，sidecar 代理模型需要一个控制平面，允许动态配置代理的行为，而无需手动配置它们。代理与控制平面的连接以接收新配置，控制平面也为代理提供最新的配置。
服务网格包括数据平面和控制平面，通常服务网格出现在 Kubernetes 环境中，但是任何环境（VM 和裸机）上都可以构建服务网格）。
运行模式
kuma-cp 是 Kuma 控制面的可执行文件，支持通用环境和 Kubernetes 环境：
- 在 Kubernetes 上运行：不需要外部依赖，利用 K8s API 服务器存储配置。
- 在通用环境上运行：Kuma 需要 PostgreSQL 数据库作为依赖项，用于存储配置。
架构
Kuma 网络由数据平面和控制平面两个部分组成：
- 数据平面：由一个个应用服务+Sidecar 代理组成，在数据平面中代理接管网络流量，Kuma 采用 Envoy 作为数据平面代理。
- 控制平面：用于配置数据平面，独立于数据平面运行。用户可以在控制平面配置策略，控制平面生成数据平面配置并分发到数据平面。Kuma 实现了Envoy xDS API ，以便数据平面代理可以从控制平面检索其配置。
Kuma 按照运行环境的不同，分为 Kubernetes 和通用（universal）两种运行模式。
Kubernetes 模式
当在 Kubernetes 模式下运行时，Kuma 将其所有状态和配置存储在底层 Kubernetes API 服务器上。
将 Kubernetes 中的服务加入服务网格进行管理的唯一步骤就是开启 Sidecar 注入，kuma.io/sidecar-injection: enabled 标签用于将 sidecar 注入到 pod 中。
Services 和 Pods
对于一个 Kubernetes Service 和关联的 Pod，Kuma 控制面会自动的生成一个注解
kuma.io/service: <name>_<namespace>_svc_<port>，其中 name 和 namespace 还有 port 均来自 Service 信息。某些情况下 Pods 不属于任何的 Service，仅仅是单纯的一个 Pod。在这种情况下，Kuma 会自动生成的注解为
kuma.io/service: <name>_<namespace>_svc，其中 name 和 namespace 来自于 Pod 资源。
Universal 模式
在通用模式下运行时，Kuma 需要 PostgreSQL 数据库来存储其状态。
