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 团队和红帽等技能同伴开源了 CNCFOpen 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 发行版，具备以下优势：

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

github.com/sealerio/se…

ACK 发行版： github.com/AliyunConta…

无需运用阿里云云就能够感触和阿里云 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 多集群服务希望后续能够逐步把这样的才能展示给用户。

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

概述

完善的集群注册才能