如何有效可靠地管理大规模Kubernetes集群？

前言

Kubernetes 以其超前的设计理念和优秀的技术架构，在容器编排领域拔得头筹。愈来愈多的公司开始在生产环境部署实践 Kubernetes，在阿里巴巴和蚂蚁金服 Kubernetes 已被大规模用于生产环境。

Kubernetes 的出现使得广大开发同窗也能运维复杂的分布式系统，它大幅下降了容器化应用部署的门槛，但运维和管理一个生产级的高可用 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 面向终态设计模式。

将来咱们会尝试将集群规模变动切换为 Operator 面向终态设计模式，探索如何在面向终态的模式下，作到变动的可监控、可灰度和可回滚，实现变动的无人值守。

若是你对蚂蚁金服 Kubernetes 集群感兴趣，能够阅读这篇文章：从零到破万节点！支撑618大促背后的蚂蚁金服Kubernetes集群