关于阿里云: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. 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 多集群服务冀望后续可能逐渐把这样的能力展现给用户。

相干链接

[1] OCM

https://open-cluster-management.io/

[2] registration-operator

https://github.com/open-cluster-management-io/registration-operator

[3] registration

https://github.com/open-cluster-management-io/registration

[4] work

https://github.com/open-cluster-management-io/work

[5] cluster-gateway

https://github.com/oam-dev/cluster-gateway

[6] managed-serviceaccount

https://github.com/open-cluster-management-io/managed-serviceaccount

[7] OCM Agent 只会在创立 ManagedCluster 时候上报 CABundle

https://github.com/open-cluster-management-io/registration/pull/270

[8] Pod Readiness Gates

https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate

[9] 减少缓存（Inforemer）

https://github.com/oam-dev/cluster-gateway/pull/117

[10] 假装（Impersonation）

https://kubernetes.io/docs/reference/access-authn-authz/authe…