文｜金敏（蚂蚁集团技能专家)\邱见（Red Hat)
校对｜ 冯泳（蚂蚁集团资深技能专家)
本文 3311 字 阅览 6 分钟
从开始 Kubernetes 技能问世，业界一遍一遍的质疑它能否能经得住出产级的检测，到今天许多大型企业现已选用 Kubernetes 技能“云化”之前大规模的基础设施，在企业内部创立了数十个甚至数百个集群。
Kubernetes 原生的办理才能现在依然停留在单集群等级。每一个集群能够稳定地自治运转，但是却缺乏横贯多个集群的统筹办理才能。基础设施的建立者需求和谐分散在遍地的办理组件，形成一个一致的办理渠道。
经过它，运维办理人员能够获悉多集群水位的变化，节点健康状况的震动等信息；事务运用负责人能够决策如何分配运用服务在各个集群中的布置散布；运用的运维人员能够获悉服务状况，下发腾挪的战略。
与多集群相关的立异正在不断涌现。例如 ClusterAPI 和 Submariner 便是处理特定多集群办理问题比较成功的项目。
而本文要讨论的是那些试图解决企业在面临多集群办理时遇到的所有问题的技能探究。
在过去五年中，我国的技能公司蚂蚁集团在多集群办理的考虑、运用和施行等方面学习到了许多名贵的经历。
蚂蚁集团办理着遍布全球的数十个 Kubernetes 集群，每个集群均匀拥有数千个节点（服务器）。他们将运用程序及其所需组件（包含中间件，数据库，负载均衡等等）在架构层面组织成逻辑数据中心（LDC）的弹性逻辑单元中，并将它们规划布置到物理基础设施上。这种架构设计帮助他们完成基础设施运维的两个关键方针：高可用性和事务性。
- 首先，布置在某个 LDC 上的事务运用的可用性在所属 LDC 内能够得到保障。
- 其次，布置在 LDC 内的运用组件能够被验证，并在毛病发生时，能够被回滚。
蚂蚁集团 PaaS 团队的资深技能专家冯泳表明：
“蚂蚁集团拥有数十个 Kubernetes 集群、数十万个节点和数千个关键运用的基础设施。在这样的云原生基础设施中，每天都会有数以万计的 Pod 被创立和删去。构建一个高度可用、可扩展且安全的渠道来办理这些集群和运用程序是一项应战。”
PART. 1 始于 KubeFed
在 Kubernetes 项目生态中，多集群功用主要由与之同名的 SIG-Multicluster 团队处理。这个团队在 2017 年开发了一个集群联邦技能叫做 KubeFed。
联邦开始被以为是 Kubernetes 的一个内置特性，但很快就遇到了完成以及用户诉求割裂的问题，Federation v1 能够将服务分发到多个 Kubernetes 集群，但不能处理其他类型的目标，也不能真实的以任何办法“办理”集群。一些有相当专业需求的用户——尤其是几个学术实验室——仍在运用它，但该项目已被 Kubernetes 归档，从未成为核心功用。
然后，Federation v1 很快被一种名为“ KubeFed v2 ”的重构设计所取代，世界各地的运营人员都在运用该设计。它答应单个 Kubernetes 集群将多种目标布置到多个其他 Kubernetes 集群。KubeFed v2 还答应“操控平面”主集群办理其他集群，包含它们的许多资源和战略。这是蚂蚁集团多集群办理渠道的第一代方案。
蚂蚁集团运用多集群联邦的首要任务之一是资源弹性，不止包含节点等级弹性也包含站点等级弹性。经过在需求时添加节点和整个集群起到进步功率和扩展体系的才能。例如年度性的资源弹性，每年 11 月 11 日是我国一年一度的光棍节，蚂蚁集团一般需求快速布置许多额外容量来支撑顶峰在线购物作业负载。然而，惋惜的是正如他们发现的那样 KubeFed 添加新集群的速度很慢，并且在办理许多集群方面功率低下。
在 KubeFed v2 集群中，一个中枢 Kubernetes 集群会充当所有其他集群的单一“操控平面”。蚂蚁集团发现，在办理托管集群和托管集群中运用程序的时候，中枢集群的资源运用率都十分高。
在办理仅占蚂蚁集团总量 3% 的运用程序作业负载的测验中，他们发现由中等规模的云实例构成的中枢集群就现已饱和了，并且响应时刻很差。因此，他们从未在 KubeFed 上运转悉数作业负载。
第二个限制与 Kubernetes 的扩展功用有关，称为自界说资源界说或 CRD。类似蚂蚁集团这样的“高级用户”往往会开发众多的自界说资源来扩充办理才能。为了要在多集群间分发 CRD，KubeFed 要求为每个 CRD 都创立一个“联合 CRD”。这不仅使集群中的目标数量增加了一倍，也为在集群间维护 CRD 版别和 API 版别一致性方面带来了严峻的问题，并且会形成运用程序由于不能兼容不同的 DRD 或者 API 版别而无法顺畅升级。
CRD 的这种数量激增也导致了严峻的毛病排除问题，同时 CRD 的运用界说不标准/字段改变随意等坏习惯会使 KubeFed 操控面的鲁棒性雪上加霜。在本地集群有自界说资源的地方，联邦操控平面上也有一个代表该本地集群资源的图形聚合视图。但是如果本地集群出现问题，很难从联邦操控平面开始知道问题出在哪里。本地集群上的操作日志和资源事件在联邦等级也是不可见的。
PART. 2 转向 Open Cluster Management
Open Cluster Management 项目（OCM）是由 IBM 开始研制，并由红帽在去年开源。OCM 在蚂蚁集团和其他合作伙伴的经历基础上，改进了多集群办理的办法。它将办理开销从中枢集群下放到每个被办理集群上的署理（Agent）上，让它在整个基础设施中散布式自治并维护稳定。这使得 OCM 理论上能办理的集群数量至少比 KubeFed 多一个数量级。到现在为止，用户现已测验了同时办理多达 1000 个集群。
OCM 还能够利用 Kubernetes 本身的发展来进步自身的才能。例如，那些以 CRD 封装的才能扩展能够运用 OCM 的 WorkAPI（一个正在向 SIG-Multicluster 提议的子项目）在集群之间分发 Kubernetes 目标。WorkAPI 将本地 Kubernetes 资源的子集嵌入其中，作为要布置的目标的界说，并将其留给署理进行布置。此模型愈加灵敏，并且最大限度地减少了对任何中心操控平面的布置需求。WorkAPI 能够一同界说一个资源的多个版别，支撑运用程序的升级途径。同时 WorkAPI 统筹了中枢集群和被办理集群网络链接毛病时的状况保持问题，并能够在重连的情况下保障资源状况的终究一致性。
最重要的是，OCM 在集群布置中完成了更多的自动化。在 KubeFed 中，集群的纳管是一个“双向握手”的进程，以中枢集群和被办理集群之间“零信任”作为基础，在此进程中涉及许多手动过程来保障安全性。新渠道能够简化这一进程。例如，由于它在 “PULL” 的基础上运转，不再需求多阶段手动证书注册，也不需求任何明文的 KubeConfig 证书的流通，就能够做到让被办理集群获取中枢集群的办理指令。
尽管注册的流程重视双向的“信固执”，但是在 OCM 中添加新集群只需求很少的操作；作业人员能够简单地在方针 Kubernetes 集群上布置 “Klusterlet” 署理完成自动纳管。这不仅对办理员来说愈加容易，并且也意味着蚂蚁集团为双十一预备更多新集群的布置愈加快速。
PART. 3 Kubernetes 多集群的下一步是什么？
在短短四年内，Kubernetes 社区的多集群办理才能迅速发展，从 Federation v1 到 KubeFed v2 再到 Open Cluster Management。
经过在内部爱好组 SIG-Multicluster 和外部项目（OCM、Submariner 等）作业的那些才华横溢的工程师的技能才能，多集群支撑的办理规模和办理功用都比以前进步了许多。
未来是否还会有一个新的渠道来进一步发展多集群功用，或者 OCM 便是终究的完成办法？
冯泳是这么以为的：
“展望未来，在红帽、蚂蚁集团、阿里云等参与者的共同努力下，Open Cluster Management 项目将成为构建根据 Kubernetes 的多集群解决方案的标准和背板”。
无论如何，有一件事很清楚：
您现在能够在 Kubernetes 上运转整个星球
要了解有关云原生主题的更多信息，请在KubeCon+CloudNativeCon North America ，2021 – 2021 年 10 月 11-15 日参加云原生计算基金会和云原生社区。
「原文链接」： containerjournal.com/features/th…
本周引荐阅览
-
攀爬规模化的顶峰 – 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践
-
SOFAJRaft 在同程旅行中的实践
-
MOSN 子项目 Layotto：敞开服务网格+运用运转时新篇章
-
蚂蚁智能监控
