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

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
注册配置 MSE Nacos/ZooKeeper,118元/月
可观测链路 OpenTelemetry 版,每月50GB免费额度
简介: 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 多集群服务注册架构如下图所示:

image.png

  • 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,可以极大分摊管控集群的压力。架构如下图所示:image.png

  • Push 模式

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

image.png

使用 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 后可以保证多集群鉴权能够成功完成。

image.png


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


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

image.png

管控集群中所有控制面请求都收敛在 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/authentication/#user-impersonation

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
Prometheus 监控 Kubernetes
【云原生】k8s集群资源监控平台搭建—20230227
【云原生】k8s集群资源监控平台搭建—20230227
128 0
|
3月前
|
运维 Kubernetes 监控
云原生时代的运维革新:Kubernetes 在现代 IT 架构中的角色
随着云计算的不断演进,传统的运维模式已逐渐不能满足快速迭代和弹性伸缩的需求。本文将深入探讨 Kubernetes 作为容器编排工具如何引领运维领域的变革,并展示其在现代 IT 架构中的应用价值。通过实例分析,我们将了解 Kubernetes 如何优化资源管理、自动化部署和提高系统可靠性,同时指出实践中可能遇到的挑战及应对策略。
|
3月前
|
弹性计算 运维 Kubernetes
云原生时代的运维革新:Kubernetes在现代IT架构中的角色
随着云计算的日益普及,传统运维模式逐渐不能满足现代企业的需求。本文将深入探讨Kubernetes如何在云原生时代重塑运维工作,包括自动化部署、弹性伸缩、服务发现等关键特性,以及它如何帮助企业实现敏捷性和效率的双重提升。
83 0
|
存储 运维 监控
《CDP企业数据云平台从入门到实践》——CDP集群管理(1)
《CDP企业数据云平台从入门到实践》——CDP集群管理(1)
437 0
|
SQL 消息中间件 边缘计算
《CDP企业数据云平台从入门到实践》——CDP集群管理(2)
《CDP企业数据云平台从入门到实践》——CDP集群管理(2)
177 0
|
API
《CDP企业数据云平台从入门到实践》——CDP集群管理(6)
《CDP企业数据云平台从入门到实践》——CDP集群管理(6)
127 0
|
分布式计算 资源调度 搜索推荐
《CDP企业数据云平台从入门到实践》——CDP集群管理(5)
《CDP企业数据云平台从入门到实践》——CDP集群管理(5)
111 0
|
存储 监控 API
《CDP企业数据云平台从入门到实践》——CDP集群管理(3)
《CDP企业数据云平台从入门到实践》——CDP集群管理(3)
190 0
|
SQL 监控 搜索推荐
《CDP企业数据云平台从入门到实践》——CDP集群管理(4)
《CDP企业数据云平台从入门到实践》——CDP集群管理(4)
167 0
|
监控 数据安全/隐私保护
《CDP企业数据云平台从入门到实践》——CDP集群管理(7)
《CDP企业数据云平台从入门到实践》——CDP集群管理(7)
121 0