开放模块化多集群管理平台OCM-阿里云开发者社区

作者：金敏（左修）

摘要：OCM（开放集群管理）是CNCF官方的多集群开源云原生项目，主要由红帽，阿里云，微软等多个云厂商共同推动。本次分享主要介绍OCM的架构与功能、OCM近期的新特性以及OCM与KubeVela的集成。

分享人：金敏（左修），OCM维护者，阿里云开发工程师，Kubernetes 维护者及多个子项目管理员，2019欧洲/2019北美/2020北美/2021中国 KubeCon 讲师，Kubernetes APF 特性发起人/作者，Kubernetes Java/Spring Cloud Kubernetes维护者。

概述

为什么从单集群到多集群

OCM主要架构/功能介绍

OCM近期特性介绍

OCM与KubeVela的集成

正文

一、概述

Open Cluster Management简称OCM，是开放模块化的多集群管理，所谓的集群是指Kubernetes集群。OCM是CNCF云原生sandbox项目之一，最开始从红帽的Advanced Cluster Management的商业化产品中沉淀出来的平台，随后有阿里云、支付宝、Microsoft Azure、腾讯的加入，目前支付宝内部PaaS平台已经有OCM落地的产品，在阿里云专有云中，OCM也会成为阿里云CNStack非常亮眼的一部分，下面从一个使用者的场景角度阐述为什么要从单机群到多集群、OCM主要架构和功能介绍以及OCM近期的动态。

二、为什么从单集群到多集群

在云原生相关技术实践过程中，随着实践规模的慢慢扩大，单个Kubernetes集群规模已无法支撑，需要过渡到多集群的方案上。在一年前，OCM还是非常新的项目，所以活跃度比较低，随着近期越来越多的伙伴加入，也基于OCM开发一系列的特性，KubeVela和OCM也已经有一些集成（如多集群的应用下发）。

KubeVela核心组件都是和OCM共用的，OCM可以在多集群KubeVela的基础上，执行面向生产更稳定的任务（如证书的滚动、自动拓补发现）。那么单集群有哪些瓶颈呢？

1、单集群瓶颈

a. 跨机房/地域Etcd运维问题

首先是跨机房跨地域Etcd运维的问题，在轻量规模的K8s运维里，一个Kubernetes集群可以看作是Etcd上面无状态的应用，大部分情况K8s的运维的问题，是取决于Etcd的运维问题；

Etcd有地域化配置的一些硬性要求，包括两个机房之间的延迟，如果地域比较远，将面临Etcd要拆分进行部署，如跨机房跨地域，因为Etcd要拆分进行部署，所以对应的k8s集群也需要进行重新规划，另外在生产运维过程中也随着K8s的规模增长而遇到Etcd请求压力的瓶颈。

b. Kubenretes“可用性半径”控制问题

其次单机群的一个瓶颈是“可用性半径”控制问题，在K8s里面虽然有Namespace的概念，在设计上希望能够通过Namespace描述这样的租户隔离性，比如应用1应该部署在Namespace1，应用2部署在Namespace2，但事实上K8s原生的隔离性还未达到期望，此外即使达到了理想的隔离状态，但还需要预防一些不能预知的灾难（如k8s升级/运维/宕机事件），为了能够最简单方式隔绝这些问题，就需要进行“可用性半径”控制，也就是经常提到的爆炸半径控制(比如在成都有个机房，上海有个机房，分别部署一套K8s，在地域化推荐的服务中也可以通过每个地域一套集群使得各自可用性不会出现冲突和相互牵连)。

c. 原生Kubernetes租户级别隔离性不足

最后是K8s内部原生租户级别的隔离性不足，在多集群之外，还有一个并行的工作小组叫做多租户，多集群和多租户要解决的问题是同质的，而多集群解决隔离性是采取一种更温和的方式：充分尊重单个集群K8s，不修改源代码，在控制平面进行对应K8s集群的管理，可以灵活的接管或者踢出一个集群。所谓的多租户形态的集群管理，目标是能全透明的将各个集群的信息映射/收集回中枢控制面中再进行统一的管理。

2、多集群用户场景

a. 集群级别的弹性扩容

目前多集群应用的场景也有很多，首先是集群级别的弹性扩容，如阿里云上双11的弹性大促和扩容；类似场景还有机房级别的弹性迁移，如在多机房迁移或者运营商的切换等情况下，需要进行集群级别的迁移，这种情况下需要多集群的控制平面，去管理和衔接其中的复杂性。

b. 沙箱测试演练环境的扩容

其次，具备沙箱测试演练环境的扩容，在实际工作中需要各类环境，如集成测试、普通CI测试等等，将这样的环境进行隔离可以通过多集群扩展的方式。随着工具链（类似K8s集群级别的弹性扩容）在一步一步的发展成熟，把测试环境通过多集群进行管理，也是水到渠成的事情。

c. 广地域基础设施运维

再者，广地域基础设施运维场景，由于地域和地域之间存在物理级别的网络延迟，所以在选择进行基础设施规划的时候，就没有太多选择的空间。一般根据是否建设专线等等物理条件直接决定多集群规划拓扑。

d. 多云多服务商环境灵活性

多集群让用户在选择多云多服务商环境更加具有灵活性。

e. 跨团队/组织集群间协作

最后，跨团队跨组织集群间协作问题，单个的K8s集群总会遇到问题进行追责，在可观测性建设不完整的情况下，可以将某个集群分配给某个团队进行管理。

3、评价软性指标

评价OCM指标有哪些呢？

• 首先最重要的是基础设施依赖性和耦合性，在多集群的场景里，有个多集群的中枢的大脑，去任意非常灵活的管理不同的集群，而在接管集群之前不会预设太多的依赖；

• 其次，OCM的可扩展性希望做到像搭积木一样，可以灵活的将所需的资源加进来，不需要的资源踢出去，具有热插拔性和可剪裁性，而开放性方面不会在功能上对厂商预设限制；

• 最后，厂商的中立性，不会夹带任何的厂商级别的互斥，可以实现多个厂商云之间灵活切换。

三、OCM主要架构/功能介绍

1、主要架构

OCM的架构图

首先，在K8s架构中，K8s有一个控制节点叫kube-master（包括Scheduler、Apiserver、Controller manager等组件），将节点注册到master里，在这个过程中，Node是通过List Watch是从远端控制面里把对应的元数据信息（如Pod、Node）拉取下来，所以这是一个经典的Pull的架构模型。在原生的K8s里面有Kubemaster，还有Kubelet，在OCM里面对标是：Hub Cluster 对标Kubemaster，Klusterlet对标Kubelet，将K8s集群当原子的黑箱看成Klusterlet，在运维OCM多集群管控面的集群时，其实就是在像运维某个Node一样运维单个Kubernetes群，该架构是天然模仿Kubernetes的架构也就是基于Pull模型。

2、主要概念

在了解Hub和Klusterlet这两个核心的概念后，目前OCM支持的核心功能是什么呢？

a. ManagedCluster/逻辑托管集群

首先是ManagedCluster即逻辑托管集群，无论是集群在接管流程上的灵活性，还是对基础设施的耦合性、依赖性均是面向ManagedCluster模型进行操作的，然后被托管集群注册到OCM中枢上，在中枢里就可以操作ManagedCluster模型以及查看对应的集群级别的的元数据；

b. ManifestWork/资源下发

当多个集群注册到OCM中枢上，就可以面向多个ManagedCluster进行下发资源，在下发资源的过程中，需要拟定义一个ManifestWork的资源，在Work API中定义需要下发内容，例如要下发Deployment应用与对应的Service，将其打包到API里并与ManagedCluster建立对应关系，就可以在对应集群上发布标记的资源。目前ManifestWork已经是社区中公共的标准；

c. Placement/多集群路由

第三个功能是Placement，即多集群路由或者称为多集群的匹配或调度，如何将下发的资源与对应的集群进行关联，将需要定义的资源关联到一个路由策略上，这个路由策略决定了将这组资源复制或者粘贴到哪些集群上面；

d. Add-On/插件

Add-On插件是为了提高多集群的可扩展性，类似K8s中Control Runtime，是面向开发者自定义Operator Controller的一个框架。

3、集群纳管

如上图是被纳管的集群接入到OCM中枢的场景，首先需要规划出中枢集群，在中枢集群里执行命令Clusteradm join操作，生成渲染后的指令，将其复制在被纳管集群里执行，这样被纳管的集群就注册成功了。OCM注册流程是不互信的，需要双向握手，类似于TCP握手，不仅需要被纳管的集群向中枢集群发起接管的请求，还需要中枢集群去批准这个请求。