CNStack 多集群服务：基于 OCM 打造完善的集群管理能力

作者：学靖

概述

随着 Kubernetes 在企业业务中的应用和发展，单集群内的管理能力已经趋于完善，越来越多的客户期望在多云、多集群场景部署其业务，因此需要提供相应的多云、多集群管理能力。

CNStack 多集群服务是 CNStack 面向多集群、多云场景提供的云原生服务，能够统一管理 CNStack 平台创建的、阿里云上的、客户自建的和其他云上的 Kubernetes 集群。

在 CNStack 2.0 中，CNStack 多集群服务是以云服务（cnstack-multicluster）的形式存在，这样一方面在单集群模式下用户可以完全聚焦集群内管理，另一方面也便于多集群服务能力独立演进，更加敏捷高效。该服务在 CNStack2.0 中主要提供以下功能，并会逐步在后续版本上线更多能力（如多集群资源分发、应用跨集群故障迁移、多集群Service等）。

扩展 **OCM [ 1] ** 的集群注册能力，提供更加完善的注册相关的集群管理能力
提供多种分发资源的模式：
- 基于 OCM ManifestWork API 的 Pull 模式
- 基于 Cluster Gateway 的 Push 模式
支持实现多集群多租户管理，多集群统一认证和鉴权
为平台和云服务/云组件提供管控集群（Hub Cluster）和被管理集群（Managed Cluster）之间的跨集群高可用互访能力

完善的集群注册能力

基于 Kubernetes，云原生 PaaS 团队和红帽等技术伙伴开源了 CNCF Open Cluster Management（OCM）项目。而 CNStack 多集群服务则是基于 OCM 项目，提供了多集群的创建、注册、取消注册等生命周期管理能力，允许用户以 Kubernetes 自定义资源声明的方式描述需要创建或者纳管的集群。该服务通过扩展 OCM，打造了非常完善的集群注册能力。

架构

CNStack 多集群服务注册架构如下图所示：

UI Backend

为 UI 提供多集群服务所有相关的 APIs。

OCM Hub/Agent

OCM 相关组件，用以实现基础的集群注册能力。组件主要包括 **registration-operator [ 2] 、registration [ 3] ** 和 **work [ 4] **，分为 hub 端和 agent 端，OCM Hub 则为在 Hub Cluster 部署的组件，OCM Agent 则为在 Managed Cluster 部署的组件。

Cluster Import Controller

实现了 CNStack 所扩展的集群管理能力。

Cluster Gateway

**cluster-gateway [ 5] ** 是一个多集群网关，用于将 Kubernetes api 流量路由到多个 Kubernetes 集群的网关APIServer。它是一个 Aggregated APIServer，可集成 OCM。

Managed ServiceAccount

**managed-serviceaccount [ 6] **这里是用于让 Cluster Gateway 以 Kubernetes ServiceAccount 的 token 的方式而非 x509证书的方式访问被管理集群的 Kubernetes api。它将 ServiceAccount 同步到被管理集群中，并从这些被同步的 ServiceAccount 收集 token，然后同步回 hub 集群。

CNStack Agent

自动采集集群厂商及核心组件状态等信息。

完整的集群生命周期管理

OCM 中使用 ManagedCluster API 来表示被管理集群的期望状态和当前状态，并建立了注册、取消注册集群生命周期的管理。虽然 OCM 在 ManagedCluster 的定义和集群注册的设计上足够优秀，但其并不能完全满足我们的需求，因此我们在 CNStack 2.0 中扩展了集群的生命周期管理，使其更加完整。

声明式注册（通过创建 ManagedCluster 触发注册）

在 CNStack 2.0 的架构设计中，采用“所有管理对象都是资源”的编程模型，所以我们的集群管理也采用声明式的 API，即通过声明 ManagedCluster 来完成注册。这样被管理集群的期望状态和当前状态都呈现在资源（ManagedCluster）上。

OCM 本身对集群注册的管理主要是通过手动或者 clusteradm 去被管理集群部署 OCM Agent，之后由 OCM Agent 在 Hub 集群自动创建 ManagedCluster。另外 OCM 虽然也允许用户在部署 OCM Agent 之前创建 ManagedCluster，但仍然存在问题：OCM Agent 只会在创建 ManagedCluster 时候上报 CABundle 到 ManagedCluster 上。这个问题会导致我们无法通过声明 ManagedCluster 来触发注册，因为 ManagedCluster 不会由 OCM Agent 来创建，而是由 CNStack 管控组件创建，这样就无法在管控集群中使用 ManagedCluster.spec.managedClusterClientConfigs 去访问被管理集群（如 Cluster Gateway 的 Const 模式就是通过这种方式访问的）。

所以我们通过：

1）自动化部署 OCM Agent

2）修复 **OCM Agent 只会在创建 ManagedCluster 时候上报 CABundle [ 7] ** 实现了声明式集群注册。

涵盖创建和删除集群的生命周期

CNStack 平台可以创建集群，为了统一管理，我们扩展了 ManagedCluster，让其也涵盖了创建和删除集群的生命周期，用户可以通过声明 ManagedCluster 来创建期望的集群，并在创建后注册。删除亦然。

和通过注册管理的三方集群相比，多集群服务对于自己创建的集群，拥有完全的生命周期管理权限，包括集群创建、修改、扩缩容以及删除。使用者只需要按照提示准备若干台 Linux 机器，并确保这些机器可被从平台所在节点通过 SSH 访达（密码或者秘钥），然后根据指引填写集群表单，就可以快速创建一套 K8s 集群。

值得一提的是，对于自建集群的生命周期管理能力，由阿里巴巴开源的集群镜像技术和 ACK 发行版来提供底层支持，也就是说，使用者通过多集群管理服务创建的集群，就是一套标准的 ACK 发行版，具备以下优势：

阿里巴巴开源的集群镜像技术：

https://github.com/sealerio/sealer

ACK 发行版：
https://github.com/AliyunContainerService/ackdistro

无需使用阿里云云就可以感受和阿里云 ACK 一致的使用体验，相较社区版 K8s 更为稳定
不依赖公网，可在离线环境完成分钟级的创建和运维，支持 RHEL/Anolis/Kylin 等多种操作系统
内置网络插件（hybridnet）、存储插件（open-local/csi-hostpath）、运维插件（npd/l-zero），且支持 IPv6双栈、GPU、多架构等特性
内置集群预检工具，可以在集群部署之前检查出可能影响集群稳定性的隐患
内置集群健康检查工具，可以一键检查集群是否健康
支持对 K8s 管控组件进行隔离和容量管理，以提升 etcd 性能以及 OS 稳定性

扩展注册成功状态

集群是否注册成功，在不同的产品或场景中判断条件往往不同。在 CNStack 2.0 中，就需在 OCM 的 ManagedClusterConditionAvailable 为 true 基础上，增加对一些管控组件状态的判断，才可认为该集群最终注册完成。

为了扩展性和灵活性，CNStack2.0中，我们参考 Kubernetes **Pod Readiness Gates [ 8] ** 的设计，在 ManagedCluster API 上做了扩展，使得可以自定义符合业务需求的集群注册成功的状态。

增强取消注册能力

集群取消注册是通过删除 ManagedCluster 来触发的，主要清理注册集群过程中在 hub集群和被管理集群上创建的资源。在 CNStack 2.0 中这样的能力还不够，还会存在以下问题和隐患：

1. 在取消注册时，实现多集群能力的组件也需要清理资源，且需要在清理 OCM Agent 之前完成，否则会在 Hub 集群和被管理集群造成垃圾
2. 集群取消注册时，ManifestWork 和 ManagedClusterAddon 等资源不回收会影响集群的二次注册和集群对应 namespace 无法删除

针对问题 a，我们允许用户先清理自己创建的资源，然后才执行基础的取消注册逻辑（卸载 OCM Agent 和清理元数据）。允许用户给 ManagedCluster 添加自定义 finalizer，在资源清理完后，删除相应 finalizer，CNStack 多集群服务会检测 ManagedCluster，在没有用户自定义 finalizer 以后，才会执行基础的取消注册逻辑。

针对问题 b，CNStack 多集群服务基于问题 a 的机制，在集群取消注册时去清理掉集群相关的 ManifestWork、ManagedClusterAddon 等资源，以确保不会有相应问题出现。

适应不同网络场景的多种注册模式

在 CNStack 2.0 中，我们从设计上来说，支持两种注册模式：Auto 和 Manual。Auto 模式，适用于 Hub 集群和被管理集群网络可以互通的场景。这种方式更加自动化，通信结构更简单。Manual 模式，适用于只有被管理集群可以访问到 Hub 集群的场景。这种方式比较适用于纳管那些因安全性考虑不对外开放的集群。不过这种模式因为某些原因在 CNStack 2.0 中尚未对用户透出，后续版本会补齐。

多种分发资源的模式

CNStack 2.0 对多集群的资源下发支持 Pull 和 Push 两种模式。支持两种模式让多集群能力更加灵活。

Pull 模式

Pull 模式是基于 OCM ManifestWork API 的，OCM 自身提供的能力。该模式的主要优点在于每个被管理集群都由 agent，可以极大分摊管控集群的压力。架构如下图所示：

Push 模式

Push 模式是基于 Cluster-Gateway 实现的。该模式的主要优点在于操作方面，也不需要考虑往每个被管理集群安装 Agent。架构如下所示：

使用 Cluster Gateway 除了具备路由透明，权限一致，通信安全的能力，还有一个好处是：无论是 Auto 模式还是 Manual 模式，在集成注册成功后，我们都可以统一使用 Cluster Gateway 访问被管理集群的资源。

当然，我们在使用过程中也发现和修复了 Cluster Gateway 的一些问题，最主要的是其在集成 OCM 时的性能问题：在集成 OCM 跨多个集群访问时的性能远落后于直接通过被管理集群 kubeconfig 访问，严重影响多集群资源下发和多集群聚合能力。其主要原因是：Cluster Gateway 在集成 OCM 后，频繁访问 Hub 集群 APIServer，获取 ManagedCluster，造成 APIServer 限频，从而 RT 远高于直接通过 kubeconfig 访问时的 RT。我们通过增加缓存 **（Inforemer） [ 9] **解决了该性能问题，从单个 Get 请求的 Benchmark 结果看 RT 减少 95%，与直接通过 kubeconfig 访问被管理集群相差无几。

多集群多租户管理与统一认证与鉴权

CNStack 2.0 中，在多集群云服务的帮助下，租户管理与认证和鉴权也扩展至多集群。这里主要是利用 OCM ManifestWork 机制，将租户、角色相关资源分发到多个集群。

用户对被管理集群的访问是使用平台 UI 或者是平台提供的 kubeconfig 去访问的，请求会经过管控集群的 Management Gateway，Management Gateway 会对请求的用户进行统一认证。而多集群鉴权则是通过**伪装（Impersonation） [ 10] **结合下发到被管理集群的 RBAC 完成，主要流程是 Management Gateway 在认证之后会为请求增加 Impersonate-User Header，再经过 Cluster Gateway 将请求发到被管理集群的 Kube APIServer。

关于伪装，这里有个细节是，请求经过 Hub Kube APIServer 以后，Impersonate-User 这个 header 会被丢弃（"Impersonate-"为前缀的几个都会被丢弃）。而 Cluster Gateway 是 Aggregated APIServer，请求都会先到达 Hub Kube APIServer，再到达 Cluster Gateway，因此请求在到达 Cluster Gateway 时已经没有这个Impersonate-User 这个 header 了。而 Cluster Gateway 有个 ClientIdentityPenetration feature gate，打开时，可以从请求的 context 中获取 User 信息（Name、Groups、Extra），并将其设置到 Header 中。因此 Cluster Gateway 开启 ClientIdentityPenetration feature gate 后可以保证多集群鉴权能够成功完成。

管控集群与被管理集群的互访

在 CNStack 2.0 中，平台和云服务/云组件有些组件是需要跨管控集群与被管理集群通信的，因此我们在管控集群与被管理集群之间构建了通路。架构图如下所示：

管控集群中所有控制面请求都收敛在 Management Gateway，数据面请求收敛在 Ingress Controller；被管理集群上服务都由 Ingress Controller 代理。

为了屏蔽网络联通的复杂性，比如对应网关代理的 IP 和端口发生变化等，无论是管控集群访问被管理集群 Ingress Controller，还是被管理集群访问管控集群 Management Gateway 和 Ingress Controller，我们都提供通过 Kuberetes Headless Service 实现路由的通路。

CNStack 2.0 中，对被管理集群的 Kubernetes API 的访问都经由 Management Gateway 转 Cluster Gateway 到达被管理集群 Kube APIServer。使用 Cluster Gateway 的优势，前文也有表述，具备路由透明，权限一致，通信安全的能力，并且方便统一访问方式。

对于被管理集群上业务想要通过域名访问 Ingress Controller 所代理的管控服务时，可以通过增加一个映射到 Headless Service 对应网关代理（Management Gateway/Ingress Controller）的 ExternalName Service，然后配合管控集群上 Ingress 对象的定义，在业务中使用${ExternalName Service}.${Serviece Namespace}.svc访问。

展望

从多云、多集群的领域来说，做好集群管理是第一步，它很重要，在不同厂商、不同位置、不同网络的集群都被注册到管控平台后，用户往往期望将应用扩展到多个集群，并期望能提供如应用跨集群故障迁移、多集群 Service、容灾备份、就近访问等场景能力。伴随应用管理而来的还有相关安全合规的策略管理。CNStack 多集群服务期望后续能够逐步把这样的能力展示给用户。