乐趣区

关于运维:还在为多集群管理烦恼吗RedHat-和蚂蚁阿里云给开源社区带来了OCM

jiezi

简介： 为了让开发者、用户在多集群和混合环境下也能像在单个 Kubernetes 集群平台上一样，应用本人相熟的开源我的项目和产品轻松开发性能，RedHat 和蚂蚁、阿里云独特发动并开源了 OCM（Open Cluster Management，我的项目官网（\_https://open-cluster-manageme…\_），旨在解决多集群、混合环境下资源、利用、配置、策略等对象的生命周期治理问题。目前，OCM 已向 CNCF TOC 提交 Sandbox 级别我的项目的孵化申请。​

作者：冯泳（鹿惊）

在云计算畛域如果还有人没听过 Kubernetes，就如同有人不晓得重庆火锅必须有辣椒。Kubernetes 曾经像手机上的 Android，笔记本上的 Windows 一样成为治理数据中心事实上的规范平台了。围绕着 Kubernetes，开源社区构建了丰盛的技术生态，无论是 CI/CD、监控运维，还是利用框架、平安反入侵，用户都能找到适宜本人的我的项目和产品。可是，一旦将场景扩大到多集群、混合云环境时，用户可能依赖的开源技术就比比皆是，而且往往都不够成熟、全面。
​

为了让开发者、用户在多集群和混合环境下也能像在单个 Kubernetes 集群平台上一样，应用本人相熟的开源我的项目和产品轻松开发性能，RedHat 和蚂蚁、阿里云独特发动并开源了 OCM（Open Cluster Management，我的项目官网（\_https://open-cluster-management.io/\_），旨在解决多集群、混合环境下资源、利用、配置、策略等对象的生命周期治理问题。目前，OCM 已向 CNCF TOC 提交 Sandbox 级别我的项目的孵化申请。
​


Open Cluster Management

多集群治理倒退历史

让咱们把工夫拉回到几年前，当业界关注 / 争执的焦点还在 Kubernetes 是否生产级可用的时候，就呈现了最早一批登陆“多集群联邦”技术的玩家。它们大都是体量上远超均匀水准的 Kubernetes 实际先驱，从最早 Redhat、谷歌入场做了 KubeFed v1 的尝试，再到起初携手 IBM 吸取经验又推出 KubeFed v2。除了这些大型企业在生产实践 Kuberentes 的场景中摸索多集群联邦技术，在商业市场上，各个厂商基于 Kubernetes 包装的服务产品也大多经验了从单集群产品服务到多集群状态、混合云场景进化的过程。其实，无论是企业本身还是商业用户都有共性的需要，聚焦在以下几个方面：
​

多地区问题：当集群须要在异构基础设施上或者横跨更广地区进行部署。

**

Kubernetes 集群依赖 etcd 作为数据长久层，而 etcd 作为分布式系统对系统中各个成员之间的网络提早上有要求，对成员的数量也有一些限度，尽管在提早可能容忍的状况下能够通过调整心跳等参数适配，然而不能满足跨国跨洲的全球性部署需要，也不能保障规模化场景下可用区的数量，于是为了让 etcd 至多能够稳固运行，个别会按地区将 etcd 布局为多个集群。此外，以业务可用和安全性为前提，混合云架构越来越多地被用户承受。逾越云服务提供商很难部署繁多 etcd 集群，随之对应的，Kubernetes 集群也被决裂为多个。当集群的数量逐步增多，管理员疲于应答时，天然就须要一个聚合的管控零碎同时治理协调多个集群。

规模性问题：当单集群规模性遇到瓶颈。

**

诚然，Kubernetes 开源版本有着显著的规模性瓶颈，然而更蹩脚是，咱们很难真正量化 Kubernetes 的规模。社区一开始提供了 kubemark 套件去验证集群的性能，可是事实很骨感，kubemark 所做的事件基于局限于在不同节点数量下重复对 Workload 进行扩缩容调度。可是实际中造成 Kubernetes 性能瓶颈的起因简单、场景泛滥，kubemark 很难全面主观形容多集群的规模性，只能作为十分粗粒度下的参考计划。起初社区反对以规模性信封来多维度掂量集群容量，再之后有了更高级的集群压测套件 perf-tests。当用户更清晰地意识到规模性的问题之后，就能够依据理论场景（比方 IDC 规模、网络拓扑等）提前布局好多个 Kubernetes 集群的散布，多集群联邦的需要也随之浮出水面。
**

容灾 / 隔离性问题：当呈现更多粒度的隔离和容灾需要。

**

业务利用的容灾通过集群内的调度策略，将利用部署到不同粒度的基础设施可用区来实现。联合网络路由、存储、访问控制等技术，能够解决可用区生效后业务的连续性问题。然而如何解决集群级别，甚至是集群管理控制平台本身的故障呢？
​

etcd 作为分布式系统能够人造解决大部分节点失败的问题，可是可怜的是实际中 etcd 服务也还是可能呈现宕机的情况，可能是治理的操作失误，也可能是呈现了网路分区。为了避免 etcd 呈现问题时“覆灭世界”，往往通过放大“爆炸半径”来提供更粒度的容灾策略。比方实际上更偏向于在单个数据中心外部搭建多集群以躲避脑裂问题，同时让每集群成为独立的自治零碎，即便在呈现网络分区或者更下层管控离线的状况下能够残缺运行，至多稳固放弃现场。这样天然就造成了同时管控多个 Kubernetes 集群的需要。
​

另一方面，隔离性需求也来自于集群在多租户能力上的有余，所以间接采取集群级别的隔离策略。顺带一提的好消息是 Kubernetes 的管制面公平性 / 多租户隔离性正在一砖一瓦建设起来，通过在 1.20 版本进入 Beta 的 API Priority And Fairness 个性，能够依据场景被动定制流量软隔离策略，而不是被动的通过相似 ACL 进行流量的惩办限流。如果在最开始进行集群布局的时候划分为多个集群，那么隔离性的问题天然就解决了，比方咱们能够依据业务给大数据调配独占集群，或者特定业务利用调配独占请集群等等。
​

OCM 的次要性能和架构

OCM 旨在简化部署在混合环境下的多 Kubernetes 集群的管理工作。能够用来为 Kubernetes 生态圈不同管理工具拓展多集群治理能力。OCM 总结了多集群管理所需的根底概念，认为在多集群治理中，任何管理工具都须要具备以下几点能力：
​

  1. 了解集群的定义
  2. 通过某种调度形式抉择一个或多个集群
  3. 散发配置或者工作负载到一个或多个集群
  4. 治理用户对集群的访问控制
  5. 部署治理探针到多个集群中

​

OCM 采纳了 hub-agent 的架构，蕴含了几项多集群治理的原语和根底组件来达到以上的要求：
​

  • 通过 Managed Cluster API 定义被治理的集群，同时 OCM 会装置名为 Klusterlet 的 agent 在每个集群里来实现集群注册，生命周期治理等性能。

​

  • 通过 Placement API 定义如何将配置或工作负载调度到哪些集群中。调度后果会寄存在 Placement Decision API 中。其余的配置管理和利用部署工具能够通过 Placement Decisiono 决定哪些集群须要进行配置和利用部署。

​

  • 通过 Manifest Work API 定义散发到某个集群的配置和资源信息。

​

  • 通过 Managed Cluster Set AP 对集群进行分组，并提供用户拜访集群的界线。

​

  • 通过 Managed Cluster Addon API 定义治理探针如何部署到多个集群中以及其如何与 hub 端的管制面进行安全可靠的通信。

架构如下图所示，其中 registration 负责集群注册、集群生命周期治理、治理插件的注册和生命周期治理；work 负责资源的散发；placement 负责集群负载的调度。在这之上，开发者或者 SRE 团队可能基于 OCM 提供的 API 原语在不同的场景下不便的开发和部署管理工具。


​

通过利用 OCM 的 API 原语，能够简化许多其余开源多集群治理我的项目的部署和运维，也能够拓展许多 Kubernetes 的单集群管理工具的多集群治理能力。例如：
​

  1. 简化 submariner 等多集群网络解决方案的治理。利用 OCM 的插件治理性能将 submariner 的部署和配置集中到对立的治理平台上。
  2. 为利用部署工具（KubeVela, ArgoCD 等）提供丰盛的多集群负责调度策略和牢靠的资源散发引擎。
  3. 拓展现有的 kuberenetes 单集群安全策略治理工具（Open Policy Agent，Falco 等）使其具备多集群安全策略治理的能力。

​

OCM 还内置了两个治理插件别离用来进行利用部署和安全策略治理。其中利用部署插件采纳了订阅者模式，能够通过定义订阅通道（Channel）从不同的源获取利用部署的资源信息，其架构如下图所示：
​


​

同时为了和 kubernetes 生态系统紧密结合，OCM 实现了 kubernetes sig-multicluster 的多个设计方案，包含 KEP-2149 Cluster ID 和 KEP-1645 Multi-Cluster Services API 中对于 clusterset 的概念。也在和其余开发者在社区独特推动 Work API ​的开发。
​

OCM 的次要劣势

​

高度模块化 — 可自由选择 / 剪裁的模块

​

整个 OCM 架构很像是“微内核”操作系统，OCM 的底盘提供外围能力集群元数据抽象等等服务，而其余扩大能力都是作为独立组件可拆分的进行部署。如上图所示 OCM 的整个计划里除了最外围的能力局部之外，其余下层的能力都是能够依据理论需要进行裁剪的，比方如果咱们不须要简单集群拓扑关系，那么就能够剪裁掉集群分组相干的模块，如果咱们不须要通过 OCM 下发任何资源仅作为元数据应用，那么甚至能够剪裁掉整个资源下发的 Agent 组件。这也有利于疏导用户逐渐登陆 OCM，在初期用户可能只须要用到很小的一部分性能，再随着场景拓展缓缓引入更多的个性组件，甚至同时反对在正在运行中的管制面上热插拔。
​

更具备包容性 — 简单应用场景的瑞士军刀

​

整个 OCM 计划在设计之初就思考到通过集成一些第三方支流的技术计划进行一些简单场景高级能力的建设。比方为了反对更简单的利用资源渲染下发，OCM 反对以 Helm Chart 的模式装置利用且反对载入近程 Chart 仓库。同时也提供了 Addon 框架以反对应用方通过提供的扩展性接口定制开发本人的需要，比方 Submarine 就是基于 Addon 框架开发的多集群网络信赖计划。
​

易用性 — 升高应用复杂性

为了升高用户的应用复杂度以及迁徙到 OCM 计划的繁难度，OCM 提供了传统指令式的多集群联邦管制流程。值得注意的是以下提及性能尚在研发过程中，将在后续版本和大家正式见面：
​

  • 通过 Managed Cluster Action 咱们能够向被纳管的集群一一下发原子指令，这也是作为一个中枢管控零碎自动化编排各个集群最直观的做法。一个 Managed Cluster Action 能够有本人的指令类型，指令内容以及指令执行的具体状态。
  • 通过 Managed Cluster View 咱们能够被动将被纳管集群中的资源“投射”到多集群联邦中枢系统中，通过读取这些资源在中枢中的“投影”，咱们能够在联邦零碎中进行更动静精确的决策。

​

OCM 在蚂蚁团体的实际

​

OCM 技术曾经利用到蚂蚁团体的基础设施中，作为第一步，通过使用一些相似与社区 Cluster API 的运维伎俩将 OCM Klusterlet 一一部署到被治理的集群中去，从而把蚂蚁域内几十个线上线下集群的元信息对立接入到了 OCM 中。这些 OCM Klusterlet 为下层的产品平台提供了多集群治理运维的根底能力不便当前的性能扩大。具体来讲 OCM 第一步的落地内容包含以下方面：

  • 无证书化： 在传统的多集群联邦零碎中，咱们往往须要给各个集群的元数据配置上对应的集群拜访证书，这也是 KubeFed v2 的集群元数据模型里的必须字段。因为 OCM 整体采纳了 Pull 的架构，由部署在各个集群中的 Agent 从中枢拉取工作并不存在中枢被动拜访理论集群的过程，所以每份集群的元数据都只是彻底“脱敏”的占位符。同时因为证书信息不须要进行存储所以在 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 社区、Oracle、Microsoft 等合作伙伴一起，进一步欠缺 KubeVela 面向混合环境的利用编排、交付与运维能力，让云原生时代的微服务利用交付与治理真正做到“既快、又好”。
​

退出社区

​

目前 OCM 社区还处在疾速开发的晚期，十分欢送有趣味的企业、组织、学校和集体参加。在这里，你能够和蚂蚁团体、RedHat、和阿里云的技术专家们以及 Kubernetes 外围 Contributor 成为搭档，一起学习、搭建和推动 OCM 的遍及。

  • GitHub 地址（https://github.com/open-cluster-management-io）
  • 通过视频理解 OCM（https://www.youtube.com/channel/UC7xxOh2jBM5Jfwt3fsBzOZw）
  • 来社区周会意识大家（https://docs.google.com/document/d/1CPXPOEybBwFbJx9F03QytSzsFQImQxeEtm8UjhqYPNg）
  • 在 Kubernetes Slack 频道 # open-cluster-mgmt 自在交换（https://slack.k8s.io/）
  • 退出邮件组浏览要害探讨（https://groups.google.com/g/open-cluster-management）
  • 拜访社区官网获取更多信息（https://open-cluster-management.io/）

往年 9 月 10 日 INCLUSION·外滩大会将如期举行，作为寰球金融科技盛会，它将持续放弃科技·让技术更普惠的初心。11 日下午的多集群、混合云架构开源专场，OCM 社区的次要开发人员会为大家带来围绕 OCM 构建的多集群、混合云最佳实际，欢送你届时线下加入，面对面交换。

感激你对 OCM 的关注与参加，欢送分享给有同样需要的更多敌人，让咱们独特为多集群、混合云的应用体验更进一步而添砖加瓦！

版权申明： 本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

退出移动版