Kubernetes 多集群管理平台 OCM v0.9.0 发布：进一步改善托管集群安全性问题

2022-11-29
浙江
本文字数：3518 字
阅读完需：约 12 分钟

作者：Brae Troutman

随着 OpenClusterManagement（OCM）项目的持续发展，我们觉得有必要周期性向大家同步近期项目的一些进展了，包括我们我们下一步未来发展的方向以及作为贡献者如何参与进来我们的社区。2022 年的尾声即将到来，让我们来进一步看一下项目研发方面的新内容吧！

关于 Open Cluster Management

OCM 是一款 Kubernetes 多集群平台开源项目，它可以帮助你大大简化跨云/多云场景下的集群管理，无论这些集群是在云上托管，还是部署在自建数据中心，再或者是在边缘数据中心中。OCM 提供的基础模型可以帮助我们同时理解单集群内部的容量情况，也可以横跨多集群进行资源/工作负载的编排调度。与此同时，OCM 还提供了一系列强大的扩展性或者叫做插件框架（addon-framework）来帮助我们集成 CNCF 生态中的其他项目，这些扩展性也可以帮助我们无侵入地针对你的特定使用场景手工扩展特性。

OCM 目前是 CNCF 官方 Sandbox 级别项目，吸纳了来自超过 15 个不同组织的维护者横跨不同的云原生厂商和解决方案提供商。我们认为 OCM 是一种对于目前已经废弃的 Kubernetes 多集群工作小组下的 Kubefed 项目的可行的平行替代方案，同时我们也在致力于在 Kubefed 的正式下线后继承延续 Kubernetes 官方多集群管理的使命。

Website:

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

GitHub:

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

新版本 v0.9.0 内容

我们很高兴在此宣布 OCM v0.9.0 版本的正式发布。在这个版本中，我们已经进一步提升了托管集群上的安全性相关问题并且可以提供了流畅的托管集群到主集群的服务暴露功能。你也可以根据这里的研发计划来看到这个版本中的新增特性等等，同时窥见社区整体正在朝哪个方向发展。

降级 Work 守护容器的安全权限

在之前的 OCM 迭代版本中，Work 守护容器通常在托管集群中是运行在管理员权限上的。这个发布版本中，为了实践“权限最小化”的原则，OCM 支持了以 ManifestWork 粒度单独定义非管理员的权限身份，这样以来就允许例如多集群应用运维的最终用户针对场景为不同的集群定义不同的权限。

支持多集群服务的暴露和路由

在最新版本的 OCM 的 Cluster-Proxy 插件里新增了在托管集群中暴露/开放一个 Service 以使得中枢集群内的客户端可以访问的特性，即使是横跨 VPC 可以流畅进行暴露。原本所有的流量是被定向路由到了各个托管集群的 Kube-Apiserver 上面，这一定程度上增加了运行 master 相关组件的节点的压力。现在 Cluster-Proxy 的插件守护容器支持了可以通过指定某个集群的某个目标服务，以使得流量的负载均衡得到了些优化，同时向中枢集群暴露服务的粒度调整也更加灵活。

支持通用化插件配置

对于某些希望可配置化的 OCM 插件，我们提供了一些新的插件 API 可扩展性来支持用户提供定制插件的配置引用信息，同时在插件框架中，我们也支持了在发现对应配置发生变化时，可以即时触发插件相关的资源的重新部署下发。

其他更新

除了以上三点的主要进展之外，这个版本也在 OCM 本身的多版本支持上取得了一些进展，同时我们也更新了 ClusterSet 以及 Placement API 的定义：

升级 ManagedClusterSet API 到 v1beta2 版本：更新了 ClusterSet API 并且渐渐下线移除了一些历史的资源，同时我们也提供了存量数据到 v1beta2 版本的向后兼容性。
提升了 Placement API 的状态反馈：为 Placement API 提供了更多状态类型和错误类型来描述场景，尤其是当用户需要诊断排查问题的时候。
新增了用户场景指导在 OCM 的社区仓库中：分享了更多现实中的 OCM 使用场景以及进一步展示了如何横跨多个集群部署应用，以及如何操作 OCM 的核心功能。

接下来还有什么？

接下来的 OCM 版本中会侧重于如何更好地和 Kubernetes 相关的官方社区标准集成，以使得从 Kubernetes 社区来到 OCM 社区贡献的体验更加友好，同时也我们也在致力于如何将 OCM 现有的功能使用到其他边缘场景中。

OCM 控制平面的独立部署

作为向 OCM 边缘场景落地的一部分投入，我们已经做出了一个初步版本的实现以支持将 OCM 整体编译成一个二进制文件简易运行（在这里由 @ycyaoxdu 展示）。在下一个版本中，我们计划进一步完善这些概念，包括在 OCM 的中枢集群中甚至屏蔽删除掉 Pod，Node 等主集群本身的资源相关 API。

基于 Pull 模式的 ArgoCD 集成

在之前的 OCM 版本中，中枢集群上的 ArgoCD 的控制器负责直接与托管集群进行 API 交互以维持应用相关的资源达到预期的状态。但这绕过了 OCM 里中枢集群和托管集群之间的安全通信管道，同时将托管集群内部的状态检查以及更新等等的任务成本转移到了中枢集群上面。我们计划引入一个新的 MultiClusterApplicationSet API 资源，来聚合 ArgoCD 的应用模版并复用 OCM 的通信管道下发到各个托管集群中，之后部署在各个托管集群上的 ArgoCD 代理控制器就可以在集群内部进行状态维护了。

Placement 扩散策略 + 拓扑感知的调度

当我们横跨多云/异构集群管理应用时，有些用户的场景需要指定某种类型的 Kubernetes 集群来进行工作负载的下发。根据场景我们提炼出了三种多集群部署的调度语义：集群亲和性，集群反亲和性和扩散。这些功能可以帮助我们指定我们倾向于将某些资源部署到某些期望的集群上，哪些不期望的集群上等等。

感知代理的中枢和托管集群网络通信

在多集群的架构中，有些隔离托管集群只能通过一个代理进行访问，这往往需要我们除了证书之外进行大量的配置工作围绕网络代理。通过以注册令牌作为 CSR 的替代品，OCM 可以灵活接管并且维护更大范围的集群配置了。

感谢贡献者

开源社区软件的美好存在于体验的多样性和贡献者们对贡献的向往。OCM 招揽了超过 70 名贡献者来自超过 15 个不同的公司。像在我们的项目中，每个社区成员都可以扮演一个重要角色在软件的成长与发展中，不仅仅可以是在社区的构建中，也可以是在开源的参与过程中。

也就是说，我们很高兴欢迎新的贡献者在过去的 3 个月的开发周期里持续涌现新的贡献者：

Ian Miller 帮助社区启动了“Selective Policy Enforment”特性
TYTaO 通过使用哈希功能在 ManifestWork 中实现了如何辨别不同的 OCM 资源
IlonaShishov 为 OCM 实现了 VSCode 的插件，包括但并不限于：清理并添加更多的信息为 Webview UI 工具库，同时为 ManagedCluster 和 Klusterlet OCM 对象新增了可视化组件。

当然，一个社区项目离不开持续陪伴使用的人们，这里是一些用户的使用例子和他们所属的公司正在 OCM 社区中探索或者已经运用于他们的多集群应用管理中：