新晋 CNCF 沙箱项目 OpenClusterManagement 带来了它的最新特性

2021 年 12 月 02 日
本文字数：3045 字
阅读完需：约 10 分钟

作者 | 左修

OpenClusterManagement（OCM）项目在 11 月 9 日的 CNCF 委员会会议中正式批准为 CNCF 的沙箱项目，并且也吸引了微软 AKS 研发同学的加盟。同时 OCM 社区也即将在 KubeCon 2021 中国的主题演讲里展开介绍 KubeVela 社区和 OCM 社区正在共建的集成特性。

分布式云正在成为云计算行业的趋势。从用户的角度认识所谓分布式云就是可以根据基础实施拓扑形式和功能需求选择合适的社区项目方案和集群管理模式获取流畅的用户体验，同时从云厂商的角度就需要在技术服务上主动适配开放的技术标准并且在一致性通过的前提下兼容其他厂商的技术方案。所以评价分布式云混合云技术方案的开放性的重要指标之一就是项目的厂商中立性和开放性，然而实践上中立性的目标是比较理想化的因为每个厂商都需要跟随本身的商业利益，所以回到混合云技术方案上我们需要重点建设的指标是在开放性，反过来绑定终端用户恰好是与分布式云的初衷背道而驰的。

下面要展开介绍 OCM 项目是个开源开放的 Kubernetes 多集群管理平台项目，目前由阿里云，红帽以及微软等公司跨厂商联合推动。在宏观架构设计上 OpenClusterManagement 主要采用了自治管理架构，同时功能组件高度模块化可剪裁。这样而来终端用户可以根据实际的场景灵活安装拆卸自己所需要的部分模块，举个例子如果用户需要采用某个厂商的功能那么只需要在 OCM 上通过订阅插件快速安装厂商的服务，同时如果用户不再需要某模块了就可以干净地拆卸掉。换言之，一个最小的 OCM 安装模式下，OCM 只会提供精炼的集群元数据以证书管理等基础功能。

一、新的子项目 Cluster-Gateway

1、Endpoint-less 的多集群 API 网关框架 / Cluster-Gateway

Cluster-Gateway 由阿里云主要贡献的 OCM 新晋子项目，也即将引用在阿里云在云栖大会亮相的 ACK 敏捷版项目中。

OCM 在自管理模式下不会再要求被托管集群提供任何形式的 API 访问入口及证书，但是实践上我们往往仍然迫切需要一个从中枢集群动态正向访问各个集群的工作链路，同时这个链路需要考虑分布式云 VPC 网络隔离的问题，甚至被托管集群有的情况下不具备开放网络出口的条件。

在 OCM 里 Cluster-Proxy 这个神奇的特性可以帮助你在中枢集群和被托管集群之间没有任何正向网络连通性的情况下使得 API 请求能从中枢集群正确抵达被托管集群，甚至 Exec，Logs 等复杂请求也可以正常工作。这得益与 Kubernetes 社区在 Apiserver-Netwrok-Proxy（ANP）项目上积累的经验：https://github.com/kubernetes-sigs/apiserver-network-proxy

通过上述 OCM 的插件开发框架（Addon-Framework），Cluster-Proxy 可以帮你托管维护滚动 ANP 的 Server 端和 Agent 端的 TLS 证书并同步两者之间的配置。

在网络连通性稳定工作之后，再借助于下面 Kubernetes 社区的 Aggregated Apiserver 开发框架 Apiserver-Runtime，我们联合 KubeVela 社区为 OCM 开发了 Cluster-Gateway 项目以提供一个自定义资源及”/proxy”子资源，它就像 Kubernetes 原生的”pods/proxy”, ”services/proxy”一样工作：https://github.com/kubernetes-sigs/apiserver-runtime

这样一来 Cluster-Proxy 提供了四层的网络链路，Cluster-Gateway 提供了七层的网络多集群路由，于是整体的 API Push 链路就可以完整工作了。详细信息可以参考下图：

该特性本身借助于 OCM 的插件框架简化了 ANP 的部署及证书滚动等繁冗的事情，这些细碎平凡的工作恰恰是构建多集群平台最先需要解决的通用问题，也是多集群平台能简易敏捷工作的基础。一句话来说，我们可以把最枯燥的事情交给 OCM，然后再由你来定义 OCM 的功能上限。

>> 更多关于 OCM 最新插件 cluster-proxy 的文档可以参考：https://open-cluster-management.io/getting-started/integration/cluster-proxy/

2、更多新特性

OpenClusterManagement 社区还有许多正在积极建设的特性模块等待你去体验发现，篇幅原因这里不能详细展开，可以参考的包括：

ManifestWork 资源下发的“订阅式”回流特性

多集群策略配置下发的 Kustomize 集成

多集群 Workload 弹性能力

参与社区了解更多

二、 OCM 能力回顾

首页仓库：

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

主题站点：

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

中文主题站点：

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

OpenClusterManagement 项目由 2020 年末开始走向公众，至今半年多来经过在蚂蚁金服大规模运维实践的打磨下逐渐走向稳定成熟。后续在吸引了阿里云，微软等厂商的登陆合作之后正式号召社区用户的使用和合作，并于最近正式被 CNCF 采纳为沙箱开源项目。以下为 OpenClusterManagement 项目的主要架构组成：

1、集群生命周期核心控制器 / Registration

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

这是 OCM 里的最核心组件，用于控制管理集群的注册流程和元数据及其生命周期。显而易见集群的元数据本身是更上层能力的必需基础，其提供的集群元数据模型也是之上工作的各个模块的公共“协议”。值得一提的是 OCM 的集群元数据是极其简练的，甚至不包含任何被托管集群的证书密钥，这是得益于 Pull 模式天然排除证书管理的安全性和复杂性。此外 OCM 里的集群注册托管流程是基于“双向握手”认证的，并且在注册完成后在中枢 Hub 集群内会自动生成管理一个与被托管集群同名的命名空间作为工作空间。

2、持续稳定的资源下发能力 / Work

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

在各个集群对应的命名空间中我们可以通过 ManifestWork API 将期望的资源打包下发给被托管集群，值得注意的是在被托管集群中会持久化一份备份的资源 AppliedManifestWork API 以保证在出现网络分区或者中枢离线的情况下被托管集群依然可以持续的维持期望的状态。通过 Kubernetes 社区多集群工作小组的决议 Work API 即将会被推为社区标准。

3、动态集群拓扑路由能力 / Placement

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

完全解耦模块化的多集群路由策略模块。在使用时通过对集群分组或者进一步筛选指定集群的标签之后，Placement 控制器就会动态计算出路由策略的计算结果即一份被匹配的集群列表。这份列表会根据集群的可用性以及其他卫星属性动态变化。用户可以基于 Placement 控制器自由开发属于自己的多集群高级特性例如多集群 Workload 下发等等。此外在 OCM 里集群的标签也分为普通的静态标签/Label，以及由被托管集群采集上报的动态标签/ClusterClaim，这些都可以作为多集群路由策略的信息输入。