带到了开源社区。简介：为了让开发者和用户在多集群、混合环境下像在单一Kubernetes集群平台上一样使用熟悉的开源项目和产品，方便开发功能，RedHat、蚂蚁、阿里云共同发起并开源了OCM（OpenClusterManagement，项目官网（\_https://open-cluster-manageme...\_），旨在解决多集群、混合环境下资源、应用、配置、策略等的生命周期管理。目前OCM已经向CNCFTOC提交了Sandbox级别项目的孵化申请。作者：冯勇（卢静）在云计算领域，如果还有人没有听说过Kubernetes，似乎有些人们不知道重庆火锅一定要有辣椒，Kubernetes已经像手机上的Android、笔记本上的Windows一样成为管理数据中心的事实标准平台。围绕Kubernetes，开源社区构建了丰富的技术生态，没有无论是CI/CD、监控运维，还是应用框架、安全防入侵，用户都能找到适合自己的项目和产品。然而，一旦场景扩展到多集群、混合云环境，用户可以依赖的开源技术屈指可数，而且往往不够成熟和全面。为了让开发者和用户能够像在单一Kubernetes集群平台上一样，在多集群混合环境下使用熟悉的开源项目和产品轻松开发功能，RedHat共同发起并开源了OCM（OpenClusterManagement，项目官方网站（\_https://open-cluster-management.io/\_）与Ant和阿里云，旨在解决多集群和混合环境中的资源、应用程序和配置、策略和其他对象的生命周期管理目前OCM已经向CNCFTOC提交了Sandbox级别项目的孵化申请。焦点还是在生产层面Kubernetes是否可用，第一批落地“多集群联邦”技术的玩家出现了。他们大多是Kubernetes实践远超平均水平的先行者。从最早的Redhat和Google进入市场试用KubeFedv1，到后来携手IBM吸取经验推出KubeFedv2。除了这些大型企业在Kubernetes的生产实践中探索多集群联邦技术外，在商业市场上，各厂商基于Kubernetes封装的服务产品也大多经历了从单集群产品服务的演进过程到多集群形式和混合云场景。.事实上，企业和商业用户都有共同的需求，主要集中在以下几个方面：多区域问题：当集群需要部署在异构基础设施上或跨更广泛的区域时。**Kubernetes集群依赖etcd作为数据持久层，etcd作为一个分布式系统，对系统内成员之间的网络延迟有要求，对成员数量也有一定的限制，但可以调整延迟可以容忍Heartbeat等参数适配，但无法满足全球跨国家跨洲部署需求，也无法保证大规模场景可用区域数。所以，为了让etcd至少能稳定运行，etcd一般会按地域规划成多个集群。此外，在业务可用性和安全性的前提下，混合云架构越来越被用户接受。很难跨云服务商部署单个etcd集群，相应的，Kubernetes集群也被拆分成多个。当集群数量逐渐增多，管理员疲于应付时，自然需要一个聚合管控系统来同时管理和协调多个集群。规模问题：当单集群规模遇到瓶颈时。**开源版本的Kubernetes确实存在明显的规模瓶颈，但更糟糕的是，我们很难真正量化Kubernetes的规模。一开始，社区提供了kubemark套件来验证集群的性能，但现实很骨感。kubemark做的是基于Workload在不同节点数下的反复扩缩调度。但在实践中，Kubernetes性能瓶颈的成因很复杂，场景也很多。kubemark很难全面客观地描述多集群的规模，只能作为非常粗粒度级别的参考方案。后来社区支持使用scaleenvelopes来多维度衡量集群容量，然后就有了更高级的集群压测套件perf-tests。当用户对规模问题有了更清晰的认识后，可以根据实际场景（如IDC规模、网络拓扑等）提前规划多个Kubernetes集群的分布，多集群联邦的需求也就随之而来。**灾难恢复/隔离问题：当有更细粒度的隔离和灾难恢复要求时。**业务应用的容灾是通过集群内的调度策略，将应用部署到不同粒度的基础设施可用区。结合网络路由、存储、访问控制等技术，解决可用区故障后的业务连续性问题。但是如何解决集群层面，甚至是集群管控平台本身的故障呢？etcd作为一个分布式系统自然可以解决大部分节点故障的问题，但不幸的是在实践中etcd服务仍然可能宕机，这可能是由于管理失误或网络分区造成的。为了防止etcd出现问题时“毁灭世界”，往往通过减小“爆炸半径”来提供更细粒度的容灾策略。比如在实践中，更倾向于在单个数据中心内搭建多个集群来避免脑裂问题，同时让每个集群成为一个独立的自治系统，即使在网络出现问题的情况下也能完全运行分区或离线上层控制，至少保持现场稳定。这自然会产生同时管理和控制多个Kubernetes集群的需求。另一方面，隔离需求也来自于集群缺乏多租户能力，所以直接采用了集群级别的隔离策略。顺便说一下，好消息是Kubernetes的控制平面公平性/多租户隔离正在一砖一瓦地构建。通过1.20版本进入Beta的APIPriorityAndFairness特性，可以根据场景主动定制流量软隔离策略，而不是像ACL那样被动的通过惩罚来限制流量。如果在集群规划之初就将集群划分为多个集群，那么隔离问题自然就解决了。例如，我们可以根据业务为大数据分配专属集群，或者为特定业务应用分配专属集群等。OCM的主要功能和架构OCM旨在简化混合环境中部署的多个Kubernetes集群的管理.可用于扩展Kubernetes生态中不同管理工具的多集群管理能力。OCM总结了多集群管理所需的基本概念，认为在多集群管理中，任何管理工具都需要具备以下能力：理解集群的定义选择一个或多个集群来分发配置或通过某种方式工作调度方法加载到一个或多个集群管理用户对集群的访问控制将管理探针部署到多个集群OCM采用hub-agent架构，包括几个多集群管理原语和基本组件来实现上述需求：通过ManagedClusterAPI，OCM会在每个集群中安装一个名为Klusterlet的代理，完成集群注册、生命周期管理等功能。定义如何通过PlacementAPI将配置或工作负载安排到哪些集群中。调度结果将存储在PlacementDecisionAPI中。其他配置管理和应用程序部署工具可以使用PlacementDecisiono来确定需要配置和部署哪些集群。定义通过ManifestWorkAPI分发到集群的配置和资源信息。通过ManagedClusterSetAP对集群进行分组，为用户访问集群提供边界。通过ManagedClusterAddonAPI，定义管理探针如何部署到多个集群，以及它如何安全可靠地与集线器端控制平面通信。架构如下图所示，其中registration负责集群注册，集群生命周期管理，以及管理插件注册和生命周期管理；工作负责资源分配；placement负责集群负载调度。在此基础上，开发者或SRE团队可以基于OCM提供的API原语，轻松开发和部署不同场景的管理工具。通过使用OCM的API原语，可以简化很多其他开源多集群管理项目的部署和运维，也可以扩展很多Kubernetes单集群管理工具的多集群管理能力。例如：简化submariners等多集群网络解决方案的管理。利用OCM的插件管理功能，将Submariner的部署和配置集中在一个统一的管理平台上。为应用部署工具（KubeVela、ArgoCD等）提供丰富的多集群调度策略和可靠的资源分发引擎。扩展现有的kuberenetes单集群安全策略治理工具（OpenPolicyAgent、Falco等），实现多集群安全策略治理能力。OCM还内置了两个管理插件，用于应用部署和安全策略管理。其中，应用部署插件采用订阅者模式，通过定义订阅通道（Channel）可以从不同的来源获取应用部署的资源信息。kubernetessig-multicluster的多项设计方案，包括KEP-2149ClusterID和KEP-1645Multi-ClusterServicesAPI中clusterset的概念。我们还与其他开发者合作，在社区中推动WorkAPI的发展。OCM的主要优势高度模块化---可以自由选择/定制的模块整个OCM架构非常类似于“微内核”操作系统。OCM的底盘提供核心能力、集群元数据抽象等服务，而其他扩展能力则作为独立组件可拆卸部署。如上图所示，除了整个OCM解决方案的核心能力外，其他上层能力可以根据实际需要进行裁剪。例如，如果我们不需要复杂的集群拓扑关系，那么我们可以裁剪集群分组相关模块，如果我们不需要通过OCM传递任何资源，只作为元数据使用，那么我们甚至可以将Agent组件剪掉由整个资源交付。这也有利于引导用户一步步登录OCM。前期用户可能只需要使用一小部分功能，之后随着场景的扩大逐渐引入更多的功能组件，甚至同时支持在运行的控制面上进行热点。插拔。更具包容性——面向复杂使用场景的瑞士军刀整个OCM解决方案从设计之初就考虑到复杂场景下高级能力的构建，通过集成部分第三方主流技术方案。例如，为了支持更复杂的应用资源渲染和交付，OCM支持以HelmChart的形式安装应用，支持加载远程Chart仓库。同时还提供了Addon框架，支持用户通过提供的扩展接口定制开发自己的需求。例如，Submarine是基于Addon框架开发的多集群网络信任解决方案。Easeofuse---降低使用复杂度为了降低用户使用的复杂度和迁移到OCM方案的方便性，OCM提供了传统的指令式多集群联邦控制流程。值得注意的是，以下提及的功能还在研发过程中，将在后续版本中正式与大家见面：作为中央管理和控制系统自动化编排单个集群的最直观方式。ManagedClusterAction可以有自己的命令类型、命令内容和命令执行的特定状态。通过ManagedClusterView，我们可以主动将托管集群中的资源“投射”到多集群联邦中央系统中。通过读取这些资源在中央系统中的“投影”，我们可以在联邦系统中进行更加动态和准确的监控。决策。OCM在蚂蚁集团的实践OCM技术已经应用到蚂蚁集团的基础设施中。第一步，OCMKlusterlet通过一些类似于社区ClusterAPI的运维方式，一个一个的部署到被管理的集群中。这样，蚂蚁域内几十个线上线下集群的元信息就统一接入了OCM。这些OCMKlusterlets为上层产品平台提供了多集群管理和运行的基础能力，方便未来的功能扩展。具体来说，OCM第一步包括以下几个方面：无证书：在传统的多集群联邦系统中，我们往往需要为每个集群的元数据配置相应的集群访问证书，这也是KubeFedv2A的集群元数据模型中的必填字段。因为OCM整体采用Pull架构，部署在各个集群的Agent从hub拉取任务，没有hub主动访问实际集群的过程，所以各个集群的元数据只是一个完全“脱敏”的占位符象征。同时，由于不需要存储证书信息，OCM方案不存在证书被复制和盗用的风险。自动化的集群注册：在之前的集群注册过程中，人工介入的环节较多，拉长了协作沟通的时间，同时失去了变更的灵活性，比如站点层面的灵活性或者机房级别。在很多场景下，人工验证是必不可少的。我们可以充分利用OCM集群注册提供的审核和验证能力，将其集成到领域内的审批流程工具中，从而实现整个集群注册流程的自动化，实现以下目标：（1）简化集群初始化/接管过程。(2)更明确地控制控制中心的权限。自动化集群资源安装/卸载：所谓接管主要包括两件事（a）在集群中安装管理平台需要的应用资源（b）将集群元数据录入管理平台。对于（a）可进一步分为Cluster级和Namespace级的资源，以及（b）一般是上层管控系统的关键操作，从产品接管集群的那一刻起，就认为产品已经接管了集群。输入元数据。在引入OCM之前，所有的准备工作都需要人工一步步推进。整个过程可以通过OCM实现自动化，简化人工协作和沟通的成本。这件事的本质是把集群管理梳理成一个流程化的操作，在集群元数据之上定义状态的概念，让产品中心自动接管需要在一个过程中完成的“琐事”。基于过程的方式。集群在OCM中注册后，资源的安装和卸载流程就明确了。通过以上工作，蚂蚁域内数十个集群全部归OCM管理。在双十一等重大促销活动中，自动创建和删除的集群也实现了自动接入和删除。后期还计划与KubeVela等应用管理技术集成，协同完成蚂蚁域应用、安全策略等云原生管理能力。阿里云OCM实践在阿里云，OCM项目是KubeVela针对混合环境应用无差异化交付的核心依赖之一。KubeVela是一个基于开放应用模型（OAM）的“一站式”应用管理和交付平台，是目前唯一由CNCF基金会托管的云原生应用平台项目。在功能上，KubeVela可以为开发者提供端到端的应用交付模型，以及灰度发布、弹性伸缩、可观察性等多项面向多集群的运维能力，并且可以适用于具有统一工作流交付和管理的混合环境。在整个过程中，OCM是KubeVela实现Kubernetes集群注册、管理和应用分发策略的主要技术。在公有云上，KubeVela的上述特性结合阿里云ACK的多集群管理能力，可以为用户提供强大的应用交付控制面，可以轻松实现：混合环境下一键建站环境。例如，典型的混合环境可以是公共云ACK集群（生产集群）加上由ACK多集群（测试集群）管理的本地Kubernetes集群。在这两种环境中，应用程序组件的提供者往往是不同的。例如，数据库组件在测试集群中可能是MySQL，而在公有云中是阿里云RDS产品。在这样的混合环境中，传统的应用部署和运维极其复杂。另一方面，KubeVela允许用户在部署计划中轻松定义要部署的产品、交付工作流以及针对不同环境声明差异化配置。这不仅省去了繁琐的手动配置过程，而且借助Kubernetes强大的自动化能力和确定性，大大降低了发布和运维的风险。多集群微服务应用交付：云原生架构下的微服务应用往往由容器组件、Helm组件、中间件组件、云服务组件等多种组件组成。KubeVela为用户提供了面向微服务架构的多组件应用交付模型，利用OCM提供的分布式策略在多集群、混合环境下进行统一的应用交付，大大降低了微服务应用的运维和管理难度.未来，阿里云团队将联合RedHat/OCM社区、甲骨文、微软等合作伙伴，进一步完善KubeVela面向混合环境的应用编排、交付和运维能力，让微服务应用交付和管理在云原生时代真正做到“又快又好”。加入社区目前OCM社区还处于快速发展的早期阶段，非常欢迎有兴趣的公司、组织、学校和个人参与。在这里，你可以与来自蚂蚁集团、RedHat、阿里云的技术专家以及Kubernetes核心贡献者成为合作伙伴，共同学习、构建和推动OCM的普及。GitHub地址(https://github.com/open-cluster-management-io)通过视频了解OCM(https://www.youtube.com/channel/UC7xxOh2jBM5Jfwt3fsBzOZw)在社区周会上与大家见面(https://docs.google.com/document/d/1CPXPOEybBwFbJx9F03QytSzsFQImQxeEtm8UjhqYPNg)在KubernetesSlack频道中自由聊天#open-cluster-mgmt(https://slack.k8s.io/)加入邮件列表并浏览主要讨论(https://groups.google.com/g/open-cluster-management）访问社区官网获取更多信息（https://open-cluster-management.io/）INCLUSION外滩大会将于今年9月10日举行预定，作为全球金融科技盛会，将继续保持科技初心，让科技更具普惠性。在11日下午的多集群与混合云架构开源专场，OCM社区的主要开发者将为大家带来围绕OCM构建多集群与混合云的最佳实践。欢迎您线下参与，面对面交流。感谢您对OCM的关注和参与，欢迎分享给更多有相同需求的朋友，让我们共同努力，进一步提升多集群和混合云的体验！版权声明：本文内容由阿里云实名注册用户投稿，版权归原作者所有。阿里云开发者社区不拥有自己的版权，也不承担相应的法律责任。具体规则请参考《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如发现本社区涉嫌抄袭内容，请填写侵权投诉表进行举报，一经查实，本社区将立即删除涉嫌侵权内容。
