文|金敏（蚂蚁团体技术专家 )\ 邱见（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 日退出云原生计算基金会和云原生社区。
🔗「原文链接」：
https://containerjournal.com/features/the-next-kubernetes-frontier-multicluster-management/
本周举荐浏览
- 攀登规模化的顶峰 – 蚂蚁团体大规模 Sigma 集群 ApiServer 优化实际
- SOFAJRaft 在同程游览中的实际
- MOSN 子项目 Layotto：开启服务网格 + 利用运行时新篇章
- 蚂蚁智能监控