蚂蚁金服是如何管理大规模的Kubernetes集群的？

2 年 ago

科, 颖

1 minute

本文介绍了Ant Financial如何高效且可靠地管理大规模的Kubernetes集群，并对构建集群管理系统的核心组件进行了思考。

这个博客是从英文版翻译过来的，您可以在这里查看原文。我们部分使用了机器翻译，如果有翻译错误，请您指出，不胜感激。

前言

Kubernetes具备先进的设计理念和优秀的技术架构，在容器编排领域处于领先地位。越来越多的企业开始在生产环境中引入和实践Kubernetes。特别是阿里巴巴和蚂蚁金服也广泛采用Kubernetes来部署生产环境。Kubernetes能够极大地简化容器化应用的部署，使开发人员能够轻松运维复杂的分布式系统。然而，维护高可用性的生产环境Kubernetes集群仍然是一项具有挑战性的任务。本文将介绍蚂蚁金服如何高效可靠地管理大规模的Kubernetes集群，并详细介绍设计集群管理系统的核心组件的方法。

系统概述

Kubernetes集群管理系统需要提供功能，以便方便地管理集群的生命周期，包括创建和升级Kubernetes集群，以及管理工作节点。在大规模场景中，能否控制集群的变更直接影响着集群的稳定性。因此，在管理系统的设计中，需要确保它支持监控、金丝雀发布和回滚等功能。此外，在超大规模的数千节点集群中，节点的硬件故障和组件的异常等问题经常发生。因此，在设计大规模集群管理系统时，必须考虑这些异常情况，并确保系统能够自动从异常中恢复。

设计模式

基于这种背景，我们设计了一个以最终状态为目标的集群管理系统。在这个系统中，会定期检查集群的当前状态是否与目标状态相符。如果状态不匹配，操作员将开始一系列操作，使集群达到目标状态。这个设计借鉴了控制理论中常见的负反馈闭环控制系统。该系统实现了闭环，并能有效地防御干扰。在我们的场景中，干扰指的是节点的软件和硬件故障。

建筑设计

如下图所示，元类是指由N个业务类组成的具有高可用性的Kubernetes集群，用于管理主节点。业务集群是用于提供生产服务的Kubernetes集群。Sigma Boss是用于集群管理的门户，提供方便的与用户交互的界面和可控的变更流程。

在元数据集群上配置的集群操作者为业务集群提供创建、删除和升级功能。集群操作者旨在达到最终状态。如果业务集群的主节点或组件出现异常，集群操作者会自动隔离和恢复异常的主节点或组件，以使业务集群的主节点达到稳定的最终状态。这种解决方案使用Kubernetes来管理Kubernetes，被称为Kube on Kube（KOK）。

此外，为了管理业务群集中的工作节点，将机器操作员和节点故障自恢复组件部署在业务群集内。通过使用这些组件，可以进行工作节点的添加、删除、升级和处理节点故障。基于机器操作员具有维护单个节点的最终状态的能力，Sigma Boss支持群集的金丝雀发布和回滚。

核心组件

集群维持最终状态

基于Kubernetes的自定义资源定义（CRD），我们在元集群中定义了一个Cluster CRD，以描述业务集群的最终状态。每个业务集群都映射到一个集群资源。创建、删除和更新集群资源意味着创建、删除和升级业务集群。集群运营商监视集群资源，驱动业务集群的主要组件，以达到CRD定义的最终状态。

ビジネス・クラスタ内のマスター・コンポーネントのバージョンは、ClusterPackageVersion CRDを通じて統一的に管理されます。ClusterPackageVersionリソースは、APIサーバー、コントローラーマネージャー、スケジューラー、オペレーターなどのマスターコンポーネントのイメージやデフォルトの起動パラメータなどの情報を記録します。クラスターリソースは、ユニークなClusterPackageVersionと関連付けられます。クラスタCrdに記録されているClusterPackageVersionのバージョンを変更することで、ビジネスクラスタのマスターコンポーネントのリリースやロールバックが可能になります。

保留节点的最终状态

要在Kubernetes集群中管理工作节点，需要执行以下步骤。

ノードが障害から自動的に回復するようにする。

为了完成前述的管理任务，我们在业务集群中定义了一个用于描述工作节点最终状态的机器CRD。每个工作节点都会映射到一个机器资源上。通过改变机器资源，我们可以管理工作节点。

以下的图表显示了Machine CRD，其中spec部分描述了要安装在节点上的组件名称和版本，status部分记录了每个组件在当前工作节点上的安装状态和运行状态。此外，Machine CRD还支持与其他节点管理运营商协作以进行插件式的最终状态管理。关于这一部分将在后面详细解释。

在WorkNode中，组件的版本通过MachinePackageVersion CRD进行管理。MachinePackageVersion存储了每个组件的Redhat Package Manager（RPM）版本、配置和安装方法等信息。一个机器资源可以与N个MachinePackageVersion关联，以便可以安装多个组件。

基于机器资源和MachinePackageVersion CRD，设计并实现了作为节点最终状态控制器的Machine Operator。Machine Operator负责监控机器资源，解析MachinePackageVersion，执行节点的运维操作，使节点达到最终状态，并持续保持最终状态。

节点最终状态管理

在不断变化的商业需求中，节点管理不再仅限于安装Docker或Kubelet等组件。需要满足如在部署了日志收集DaemonSet后开始调度等要求。此外，类似的需求也在增加。如果所有最终状态由机器操作员管理，则机器操作员与其他组件的耦合增加，系统的可扩展性降低。因此，我们设计了与机器操作员和其他节点的O&M操作员协同工作来管理节点最终状态的机制。设计过程如下图所示。

Condition ConfigMapは、各ノードのO&Mオペレータの最終的な状態をConfigMapに報告する。

机械操作员和其他节点的运维操作员之间的协调关系如下所示。

1、外部节点的O&M操作员将检测自身的子最终状态，并报告给相应的Condition ConfigMap。
2、机器操作员通过使用标签从Condition ConfigMap中获取节点的所有子最终状态，并将其与机器内的状态下的条件进行同步。
3、机械操作员基于记录在完整ReadinessGates中的条件列表，检查节点是否达到了最终状态。如果节点尚未达到最终状态，机械操作员将禁用调度。

节点故障自动恢复 (Node failure auto-recovery)

正如您所知，物理机器的硬件有时会发生故障，这是有一定概率的。随着集群中节点数量的增加，故障节点在集群内变得更为普遍。当集群中的节点增多时，故障节点在集群内存在的可能性也会增加。

为了解决这个问题，我们设计了一个闭环自恢复系统，用于发现、隔离和修复障碍。

通过代理的报告和故障检测器的自动检测，在图下所示的情况下，可以发现故障，从而确保故障发现的及时性和可靠性。具体而言，代理的报告可以确保更高的及时性，而故障检测器的自动检测可以覆盖代理未报告的异常情况。所有的故障信息都存储在事件中心中。可能受到集群故障影响的组件和系统可以通过订阅事件中心的事件来获取故障信息。

节点故障的自我恢复系统会根据故障的类型创建不同的维护流程，例如硬件维护流程和系统重新安装流程。在维护流程中，系统会通过停止节点调度来隔离出有故障的节点，并在节点上的Pod上标记为”to be migrated”，通知给平台作为服务（PAAS）或MigrateController进行Pod的迁移。一旦准备工作完成，系统会尝试修复硬件或重新安装操作系统等来恢复节点。当节点恢复后，系统将重新启用节点调度。如果系统在长时间内无法自动恢复节点，可以尝试手动恢复节点。

风险预防

基于机器操作员提供的原子能力，设计旨在支持金丝雀发布和集群回滚。此外，为了进一步降低变更的风险，操作员会在实际开始变更之前评估风险。以下图示了架构。

高风险的操作，例如删除节点或重新安装系统，将记录在统一的费用限制中心。速率限制中心管理各种操作的速率限制策略。如果变更触发了速率限制，系统将停止变更。

为了评估变更过程是否正常，将在变更前后进行组件的健康检查。通过组件的健康检查，可以发现大多数异常情况，但可能存在未涵盖特定异常场景的情况。为了克服这个弱点，系统会在风险评估期间获取集群业务指标，如Pod创建成功率等，从事件中心或故障检测器。如果指标异常，系统会自动停止变更。

总结

在这篇文章中，我们分享了Ant Financial公司目前使用的Kubernetes集群管理系统的核心设计。核心组件使用了许多运算符来管理最终状态。这个面向最终状态的集群管理系统已在今年的双十一准备中成功通过了性能和稳定性测试。

一个完善的集群管理系统不仅要确保集群的稳定性和运维效率，还需要提高整个集群的资源利用率。未来，我们将增加在线节点的比例，减少空闲节点的比例，以提高蚂蚁金融生产级集群的资源利用率。同时，蚂蚁金融的系统资源调度团队正在招募优秀的人才。让我们一起解决具有全球影响力的问题吧。

常见的问题

Q1: 目前，我們公司的大部分應用程式都是使用 Docker 進行部署的。要轉移到 Kubernetes，應該怎麼做？另外，是否有相關的案例可以學習？

A1: 我在蚂蚁金服已经工作了近5年。蚂蚁金服的服务最初是在Xen虚拟机上运行的，但现在已经转为使用Docker，并由Kubernetes进行调度。可以看出几乎每年都会进行创新。Kubernetes是一个开放的PaaS（Platform as a Service）框架。如果使用Docker部署Kubernetes，应用程序就是”云原生”的，理论上可以平稳地迁移到Kubernetes上。考虑到蚂蚁金服以往的重负载工作，我们实际上通过加强Kubernetes来符合服务需求，以确保服务能够顺利地迁移到Kubernetes上。

如果在Kubernetes和Docker上部署应用程序，性能是否会下降？例如，推荐将与大数据处理相关的作业部署到Kubernetes吗？

据我所知，Docker是容器而不是虚拟机。因此，它对性能的影响是有限的。蚂蚁金服的大数据和人工智能（AI）等服务已经迁移到了Kubernetes上，并与在线应用程序一起以混合方式部署。大数据服务有时间限制，可以充分利用空闲状态的集群资源。此外，混合部署还可以大幅降低数据中心的成本。

Q3: Kubernetes集群在传统的O&M环境中是如何运作的？目前来看，只部署Kubernetes集群绝对是不错的选择。

A3: 使用不同基础设施时，无法集中调度资源。同时，维护相对独立的两个运维系统成本很高。在蚂蚁金服，我们在迁移过程中通过将传统容器创建和发布指令转换为Kubernetes资源变更指令，实现了一个”适配器”来形成”桥梁”。

Q4：节点如何被监视？如果节点发生故障，Pod是否会迁移？如果服务不支持自动迁移，应该怎么处理？

A4：节点将在硬件级别、系统级别和组件级别上进行监控。硬件级别的监控数据将从互联网数据中心（IDC）获取。系统级别的监控将由阿里云内部监控平台进行。为了监控Kubelet和Pouch等组件，我们通过扩展节点问题检测器（NPD）来提供监控系统收集数据的导出接口。如果节点发生故障，系统将自动迁移节点内的Pod。对于有状态服务，服务提供商可以自定义自动迁移Pod的操作程序。无法自动迁移的Pod将由系统丢弃。

Q5: 未来是否有计划使Kubernetes集群对开发者来说更加透明化，使开发者可以使用代码编写和编译集群部署文件，而不是基于容器开发和部署应用程序？

A5：Kubernetes为构建PaaS平台提供了许多扩展功能。但是，目前直接部署应用程序到Kubernetes集群确实非常困难。未来，使用特定领域特定语言（DSL）来部署应用程序将成为趋势，而Kubernetes将成为这些基础设施的核心。

Q6: 现在，我们使用kube-to-kube方式管理集群。与kube-to-kube相比，kube-on-kube的优点是什么？另外，在大规模部署Kubernetes集群时，节点扩展可能会导致性能瓶颈。如何解决这个问题？

A6：目前，在Kubernetes集群中运行着许多持续集成和持续交付（CI/CD）流程。通过使用kube-on-kube，可以将业务集群作为共享的业务应用程序进行管理。除了Kubelet和Pouch之外，还有许多DaemonSet和pod在节点上运行。当节点数量增多时，节点内的组件会开始对API服务器进行大量的列表操作和监听操作。我们的优化工作主要关注提高API服务器性能，并减少与API服务器的协作时节点的列表操作和监听操作的总数。

Q7：我们还没有部署Kubernetes集群。我有几个问题想问一下。Kubernetes有哪些优点？它可以解决哪些现有问题？希望能够使用Kubernetes的业务场景和流程是怎样的？是否可以顺利将现有基础设施的数据迁移到Kubernetes上？

A7: 在我看来，Kubernetes与运维操作不同，它采用了最终状态导向的设计理念。这在复杂的运维场景中是非常有用的。根据蚂蚁金服的升级实践，可以顺利将现有基础设施的数据迁移到Kubernetes上。

问8：集群提供商是否在Pod上运行？业务群集的主节点是否在Pod上运行？机器操作员是否在物理机上执行？

A8: 每个运营者都在容器中运行。集群运营者将提升业务集群内的机器运营者的级别。

Q9: 嗨！请告诉我为了应对类似双十一的高并发场景，建议使用的元集群大小以及每个业务集群的推荐大小。据我所知，集群运算符被用于资源列表化和监视。在大规模高并发场景中，有哪些改进措施呢？

答案：A9：集群能够管理数万个节点。因此，元集群理论上可以管理3,000个以上的业务集群。

Q10: 如果在节点内有系统内核、Docker、Kubernetes方面的异常情况，要通过软件来最大化系统的正常性能，应该怎么做呢？

A10: Kubernetes能够自动检查节点的健康情况。在有故障的节点自动终止后，Kubernetes会发现该节点并将其迁移到另一个节点上。

阿里巴巴云拥有两个数据中心在日本，并且拥有超过60个可用区，在亚太地区是2019年的 No.1云基础设施提供商（根据Gartner）。请点击此处查看有关阿里巴巴云的详细信息。阿里巴巴云日本官方网页。