万级规模 K8s 如何管理？蚂蚁双11核心技术公开

阿里妹导读：Kubernetes 大幅下降了容器化应用部署的门槛，并以其超前的设计理念和优秀的技术架构，在容器编排领域拔得头筹。愈来愈多的公司开始在生产环境部署实践。本文将分享蚂蚁金服是如何有效可靠地管理大规模 Kubernetes 集群的，并会详细介绍集群管理系统核心组件的设计。

系统概览

Kubernetes 集群管理系统须要具有便捷的集群生命周期管理能力，完成集群的建立、升级和工做节点的管理。在大规模场景下，集群变动的可控性直接关系到集群的稳定性，所以管理系统可监控、可灰度、可回滚的能力是系统设计的重点之一。

除此以外，超大规模集群中，节点数量已经达到 10K 量级，节点硬件故障、组件异常等问题会常态出现。面向大规模集群的管理系统在设计之初就须要充分考虑这些异常场景，并可以从这些异常场景中自恢复。

设计模式

基于这些背景，咱们设计了一个面向终态的集群管理系统。系统定时检测集群当前状态，判断是否与目标状态一致，出现不一致时，Operators 会发起一系列操做，驱动集群达到目标状态。

这一设计参考控制理论中常见的负反馈闭环控制系统，系统实现闭环，能够有效抵御系统外部的干扰，在咱们的场景下，干扰对应于节点软硬件故障。

架构设计

如上图，元集群是一个高可用的 Kubernetes 集群，用于管理 N 个业务集群的 Master 节点。业务集群是一个服务生产业务的 Kubernetes 集群。SigmaBoss 是集群管理入口，为用户提供便捷的交互界面和可控的变动流程。

元集群中部署的 Cluster-Operator 提供了业务集群集群建立、删除和升级能力，Cluster-Operator 面向终态设计，当业务集群 Master 节点或组件异常时，会自动隔离并进行修复，以保证业务集群 Master 节点达到稳定的终态。这种采用 Kubernetes 管理 Kubernetes 的方案，咱们称做 Kube on Kube 方案，简称 KOK 方案。

业务集群中部署有 Machine-Operator 和节点故障自愈组件用于管理业务集群的工做节点，提供节点新增、删除、升级和故障处理能力。在 Machine-Operator 提供的单节点终态保持的能力上，SigmaBoss 上构建了集群维度灰度变动和回滚能力。

核心组件

集群终态保持器

基于 K8s CRD，在元集群中定义了 Cluster CRD 来描述业务集群终态，每一个业务集群对应一个 Cluster 资源，建立、删除、更新 Cluster 资源对应于实现业务集群建立、删除和升级。Cluster-Operator watch Cluster 资源，驱动业务集群 Master 组件达到 Cluster 资源描述的终态。

业务集群 Master 组件版本集中维护在 ClusterPackageVersion CRD 中，ClusterPackageVersion 资源记录了 Master 组件（如：api-server、controller-manager、scheduler、operators 等）的镜像、默认启动参数等信息。

Cluster 资源惟一关联一个 ClusterPackageVersion，修改 Cluster CRD 中记录的 ClusterPackageVersion 版本便可完成业务集群 Master 组件发布和回滚。

节点终态保持器

Kubernetes 集群工做节点的管理任务主要有：

• 节点系统配置、内核补丁管理；
• docker / kubelet 等组件安装、升级、卸载；
• 节点终态和可调度状态管理（如关键 DaemonSet 部署完成后才容许开启调度）；
• 节点故障自愈。

为实现上述管理任务，在业务集群中定义了 Machine CRD 来描述工做节点终态，每个工做节点对应一个 Machine 资源，经过修改 Machine 资源来管理工做节点。

Machine CRD 定义以下图所示，spec 中描述了节点须要安装的组件名和版本，status 中记录有当前这个工做节点各组件安装运行状态。除此以外，Machine CRD 还提供了插件式终态管理能力，用于与其它节点管理 Operators 协做，这部分会在后文详细介绍。

工做节点上的组件版本管理由 MachinePackageVersion CRD 完成。MachinePackageVersion 维护了每一个组件的 rpm 版本、配置和安装方法等信息。一个 Machine 资源会关联 N 个不一样的 MachinePackageVersion，用来实现安装多个组件。

在 Machine、MachinePackageVersion CRD 基础上，设计实现了节点终态控制器 Machine-Operator。Machine-Operator watch Machine 资源，解析 MachinePackageVersion，在节点上执行运维操做来驱动节点达到终态，并持续守护终态。

节点终态管理

随着业务诉求的变化，节点管理已再也不局限于安装 docker / kubelet 等组件，咱们须要实现如等待日志采集 DaemonSet 部署完成才能够开启调度的需求，并且这类需求变得愈来愈多。

若是将终态统一交由 Machine-Operator 管理，势必会增长 Machine-Operator 与其它组件的耦合性，并且系统的扩展性会受到影响。所以，咱们设计了一套节点终态管理的机制，来协调 Machine-Operator 和其它节点运维 Operators。

设计以下图所示：

• 全量 ReadinessGates: 记录节点可调度须要检查的 Condition 列表；
• Condition ConfigMap: 各节点运维 Operators 终态状态上报 ConfigMap；

协做关系：

1. 外部节点运维 Operators 检测并上报与本身相关的子终态数据至对应的 Condition ConfigMap；
2. Machine-Operator 根据标签获取节点相关的全部子终态 Condition ConfigMap，并同步至 Machine status 的 conditions 中；
3. Machine-Operator 根据全量 ReadinessGates 中记录的 Condition 列表，检查节点是否达到终态，未达到终态的节点不开启调度。

节点故障自愈

咱们都知道物理机硬件存在必定的故障几率，随着集群节点规模的增长，集群中会常态出现故障节点，若是不及时修复上线，这部分物理机的资源将会被闲置。

为解决这一问题，咱们设计了一套故障发现、隔离、修复的闭环自愈系统。

以下图所示，故障发现方面，采起 Agent 上报和监控系统主动探测相结合的方式，保证了故障发现的实时性和可靠性（Agent 上报实时性比较好，监控系统主动探测能够覆盖 Agent 异常未上报场景）。故障信息统一存储于事件中心，关注集群故障的组件或系统均可以订阅事件中心事件拿到这些故障信息。

节点故障自愈系统会根据故障类型建立不一样的维修流程，例如：硬件维系流程、系统重装流程等。

维修流程中优先会隔离故障节点（暂停节点调度），而后将节点上 Pod 打上待迁移标签来通知 PaaS 或 MigrateController 进行 Pod 迁移，完成这些前置操做后，会尝试恢复节点（硬件维修、重装操做系统等），修复成功的节点会从新开启调度，长期未自动修复的节点由人工介入排查处理。

风险防范

在 Machine-Operator 提供的原子能力基础上，系统中设计实现了集群维度的灰度变动和回滚能力。此外，为了进一步下降变动风险，Operators 在发起真实变动时都会进行风险评估，架构示意图以下。

高风险变动操做（如：删除节点、重装系统）接入统一限流中心，限流中心维护了不一样类型操做的限流策略，若触发限流，则熔断变动。

为了评估变动过程是否正常，咱们会在变动先后，对各组件进行健康检查，组件的健康检查虽然可以发现大部分异常，但不能覆盖全部异常场景。因此，风险评估过程当中，系统会从事件中心、监控系统中获取集群业务指标（如：Pod 建立成功率），若是出现异常指标，则自动熔断变动。

结束语

本文主要和你们分享了现阶段蚂蚁金服 Kubernetes 集群管理系统的核心设计，核心组件大量使用 Operator 面向终态设计模式。这套面向终态的集群管理系统在今年备战双 11 过程当中，经受了性能和稳定性考验。

一个完备的集群管理系统除了保证集群稳定性和运维效率外，还应该提高集群总体资源利用率。接下来，咱们会从提高节点在线率、下降节点闲置率等方面出发，来提高蚂蚁金服生产集群的资源利用率。

Q & A

Q1：目前公司绝大多数应用已部署在 Docker 中 ，如何向 K8s 转型？是否有案例能够借鉴？

A1：我在蚂蚁工做了将近 5 年，蚂蚁的业务由最先跑在 xen 虚拟机中，到如今跑在 Docker 里由 K8s 调度，基本上每一年都在迭代。K8s 是一个很是开放的 “PaaS” 框架，若是已经部署在 Docker 中，符合“云原生”应用特性，迁移 K8s 理论上会比较平滑。蚂蚁因为历史包袱比较重，在实践过程当中，为了兼容业务需求，对 K8s 作了一些加强，保证业务能平滑迁移过来。

Q2：应用部署在 K8s 及 Docker 中会影响性能吗？例如大数据处理相关的任务是否建议部署到 K8s 中？

A2：我理解 Docker 是容器，不是虚拟机，对性能的影响是有限的。蚂蚁大数据、AI 等业务都已经在迁移 K8s 与在线应用混部。大数据类对时间不敏感业务，能够很好地利用集群空闲资源，混部后可大幅下降数据中心成本。

Q3：K8s 集群和传统的运维环境怎么更好的结合？如今公司确定不会所有上 K8s。

A3：基础设施不统一会致使资源没有办法统一进行调度，另外维护两套相对独立的运维系统，代价是很是大的。蚂蚁在迁移过程当中实现了一个“Adapter”，将传统建立容器或发布的指令转换成 K8s 资源修改来作“桥接”。

Q4：Node 监控是怎么作的，Node 挂掉会迁移 Pod 吗？业务不容许自动迁移呢？

A4：Node 监控分为硬件、系统级、组件级，硬件监控数据来自 IDC，系统级监控使用内部自研监控平台，组件（kubelet/pouch 等）监控咱们扩展 NPD，提供 exporter 暴露接口给监控系统采集。Node 出现异常，会自动迁移 Pod。有些带状态的业务，业务方本身定制 operator 来实现 Pod 自动迁移。不具有自动迁移能力的 Pod, 超期后会自动销毁。

Q5：整个 K8s 集群将来是否会对开发透明，使用代码面向集群编程或编写部署文件，再也不须要按容器去写应用及部署，是否有这种规划？

A5：K8s 提供了很是多构建 PaaS 平台的扩展能力，但如今直接面向 K8s 去部署应用的确很是困难。我以为采用某种 DSL 去部署应用是将来的趋势，K8s 会成为这些基础设施的核心。

Q6：咱们目前采用 kube-to-kube 的方式管理集群，kube-on-kube 相比 kube-to-kube 的优点在哪？在大规模场景下，K8s 集群的节点伸缩过程当中，性能瓶颈在哪？是如何解决的？

A6：目前已经有很是多的 CI/CD 流程跑在 K8s 之上。采用 kube-on-kube 方案，咱们能够像管理普通业务 App 那样管理业务集群的管控。节点上除运行 kubelet pouch 外，还会额外运行不少 daemonset pod，大规模新增节点时，节点组件会对 apiserver 发起大量 list/watch 操做，咱们的优化主要集中在 apiserver 性能提高，和配合 apiserver 下降节点全量 list/watch。

Q7：由于咱们公司尚未上 K8s，全部我想请教如下几个问题：K8s 对咱们有什么好处？可以解决当前的什么问题？优先在哪些业务场景、流程环节使用？现有基础设施可否平滑切换到 Kubernetes？

A7：我以为 K8s 最大的不一样在于面向终态的设计理念，再也不是一个一个运维动做。这对于复杂的运维场景来讲，很是有益。从蚂蚁的升级实践看，平滑是能够作到的。

Q8：cluster operator 是 Pod 运行，用 Pod 启动业务集群 master，而后 machine operator 是物理机运行？

A8：operator 都运行在 Pod 里面的，cluster operator 将业务集群的 machine operator 拉起来。

Q9：为应对像双十一这样的高并发场景，多少许级的元集群的规模对应管理多少许级的业务集群合适？就个人理解，cluster operator 应该是对资源的 list watch，面对大规模的并发场景，大家作了哪些方面的优化？

A9：一个集群能够管理万级节点，因此元集群理论上能够管理 3K+ 业务集群。

Q10：节点若是遇到系统内核、Docker、K8s 异常，如何从软件层面最大化保证系统正常？

A10：具有健康检查能力，主动退出，由 K8s 发现，并从新在其它节点拉起。

---

本文做者：沧漠

阅读原文

本文来自云栖社区合做伙伴“阿里技术”，如需转载请联系原做者。