乐趣区

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

相干链接

[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…

退出移动版