全面提升易用性：OpenClusterManagement 0.7 版本发布
作者：左修
OCM 0.7版本发布
千呼万唤始出来，三月末 OpenClusterManagement 社区正式发布了 v0.7 版本。在新的版本有一系列新的功能特性欢迎感兴趣的读者体验探索，同时在这个版本中社区维护者对目前已有的功能也修复了一些问题并对面向最终用户的体验进行了打磨和提升。新登陆的用户可以参考文档[1]进行体验，已经部署 0.6 版本的用户也可以参考文档[2]对现有环境进行升级。
新特性 DefaultClusterSet
为了使用户平滑登陆到 OCM 的跨集群编排能力（如 Placement）上，在新的 0.7 版本中支持了新的特性“DefaultClusterSet”。在历史的 OCM 版本中，用户需要提前在 OCM 中规划好集群的 ClusterSet 拓扑才可以进一步体验到相关的高级特性，而如今所有注册进 OCM 环境中的托管集群都会被默认注册进名叫“default” 的 ClusterSet 中。这样一来我们在拓扑相对简单的多集群环境中通过直接将“default”绑定/映射到某个中枢集群的命名空间中以进行多集群编排。
关于如何在 OCM 里基于 ClusterSet 规划多集群拓扑请参考文档[3]。
Placement API 进化至 v1beta1 版本
经过 v1alpha1 版本的社区反馈，OCM 社区正式将 Placement API 进化至 v1beta1 版本。Beta 版本意味着社区会为该版本的 API 模型兼容性维护提供更可靠的保障。同时为了简化 Placement API 面向最终用户的体验，在 Beta 版本中 Placement API 后续将支持基于 Taint/Toleration 的语义的多集群调度。这样一来，熟悉 Kubernetes 原生调度机制的用户可以参考单集群给节点打 Taint/给容器打 Toleration 的模式类比应用到多集群场景里来：我们可以给某些集群打上 Taint，再在 Placement API 中声明 Toleration 已实现动态的多集群调度。
Hub 集群版本要求从 1.19 降低至 1.12
在之前的 OCM 版本中对 Hub 中枢集群版本的要求为 1.19 以上，这主要是因为 OCM 中枢组件依赖 GA 版本的 CSR API 工作。现在在 0.7 版本中提供了对 Beta 版本 CSR API 的兼容性，但是目前这个兼容性需要手工为 OCM 的 registration 组件添加以下配置参数开启：
> --feature-gate=V1beta1CSRAPICompatibility=true
Hosted 部署模式
OCM 默认的部署模式为“hub-spoke”[4]模式，即在每个托管集群中部署一个或者多个 Agent 控制器代理操作集群，这也是多集群中常说的“Pull“架构模式。新的版本中 OCM 支持将部署架构调整为 Agent 控制器上移指中枢集群的部署模式，我们称之为“Hosted 部署”。在 Hosted 模式中托管集群内将不需要再部署其他的组件，所有的代理控制器均在远端执行。
OCM 和 KubeVela 1.3 版本增强多集群功能集成
同时发布的 KubeVela 1.3 版本中对 OCM 和 KubeVela 进行了进一步的集成，可以参考上面的操作指南及录屏进行体验。在以上指南中，我们可以体验到：
- 如何通过 KubeVela 的插件机制为多集群环境部署 OCM 中枢组件 Hub
- 如何通过 vela 命令行为托管集群部署 OCM 代理控制器组件 Klusterlet
- 体验 KubeVela 1.3 多集群应用发布功能
阿里云 ACK 敏捷版 OCM 实践
在新版本的阿里云 ACK 敏捷版[6]中，全面集成登陆了 OCM 的多集群代理网关插件。我们同样可以在自己的 OCM 环境根据文档[7]快速体验。总体来说，通过多集群代理网关插我们可以使得 OCM 中枢集群中的组件可以穿越任何网络基础设施访问到托管集群的控制面，同时访问托管集群的客户端密钥也会动态滚动以避免拷贝泄漏等等安全问题。我们甚至可以将本地笔记本电脑中的任意 KinD 集群注册到云上的 OCM 中枢中并进行正向的 API 访问。
参考链接：
[1] 文档
[2] 文档
[3] 文档
[4] hub-spoke
[5] OCM 和 KubeVela 1.3 版本增强多集群功能集成操作指南
[6] 阿里云 ACK 敏捷版
[7] 文档
本文为阿里云原创内容，未经允许不得转载。
