戳蓝字“CSDN云计算”关注我们哦！
作者 |   沧漠
责编 | 阿秃

导读：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 面向终态设计模式。这套面向终态的集群管理系统在今年备战双 11 过程中，经受了性能和稳定性考验。
一个完备的集群管理系统除了保证集群稳定性和运维效率外，还应该提升集群整体资源利用率。接下来，我们会从提升节点在线率、降低节点闲置率等方面出发，来提升蚂蚁金服生产集群的资源利用率。
关注『阿里巴巴云原生』公众号，回复关键词“1024”，可获取本文 PPT。
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 发现，并重新在其它节点拉起。
扫描下方二维码，阅读作者大大原文哟

备战双 11！蚂蚁金服万级规模 K8s 集群管理系统如何设计？相关推荐

  1. 备战双 11！96秒，100亿，支付宝万级规模 K8s 集群管理系统如何设计？

    2019年双11来了.1分36秒100亿,5分25秒超过300亿,12分49秒超500亿--全球最大流量洪峰54.4万笔,阿里巴巴核心系统全部上云... 背后的技术支撑到底是怎么样的呢? 导读:Kub ...

  2. 备战双11 蚂蚁金服10k规模k8s集群管理设计分享笔记

    分享嘉宾:张勇(花名:沧漠)蚂蚁金服技术专家,主要负责蚂蚁金服 PaaS 平台.K8s 集群管理系统设计.长期关注云原生领域开源社区,目前聚焦于如何增强 Kubernetes Node 能力和提升集群 ...

  3. 蚂蚁集团万级规模 k8s 集群 etcd 高可用建设之路

    蚂蚁集团运维着可能是全球最大的 k8s 集群:k8s 官方以 5k node 作为 k8s 规模化的顶峰,而蚂蚁集团事实上运维着规模达到 10k node 规模的 k8s 集群.一个形象的比喻就是,如 ...

  4. 蚂蚁集团于雨：万级规模 K8S 集群 Etcd 高可用建设之路

    -     前言    - 蚂蚁集团运维着可能是全球最大的 k8s 集群:k8s 官方以 5k node 作为 k8s 规模化的顶峰,而蚂蚁集团事实上运维着规模达到 10k node 规模的 k8s ...

  5. 【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

    作者 |  韩堂.柘远.沉醉 来源 | 阿里巴巴云原生公众号 ​ 前言 台湾作家林清玄在接受记者采访的时候,如此评价自己 30 多年写作生涯:"第一个十年我才华横溢,'贼光闪现',令周边黯然 ...

  6. 【深度探讨】阿里巴巴万级规模 K8s 集群全局高可用体系之美

    简介:台湾作家林清玄在接受记者采访的时候,如此评价自己 30 多年写作生涯:"第一个十年我才华横溢,'贼光闪现',令周边黯然失色:第二个十年,我终于'宝光现形',不再去抢风头,反而与身边的美 ...

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

    阿里妹导读:Kubernetes 大幅降低了容器化应用部署的门槛,并以其超前的设计理念和优秀的技术架构,在容器编排领域拔得头筹.越来越多的公司开始在生产环境部署实践.本文将分享蚂蚁金服是如何有效可靠地 ...

  8. 蚂蚁金服亿级并发下的移动端到端网络接入架构解析

    为了与金融从业者.科技从业者共同探讨金融 + 业务的深层次问题,蚂蚁金服联手 TGO 鲲鹏会上海分会,在 12 月 8 日举办了「走进蚂蚁金服:双十一背后的蚂蚁金服技术支持」活动.蚂蚁金服高级技术专家 ...

  9. 蚂蚁金服金融级容器引擎实践之路

    小蚂蚁说: 在金融级分布式架构中使用容器,许多企业的开发者都面临许多挑战.在2018年ATEC蚂蚁金服技术探索大会上,蚂蚁金服高级技术专家盛延敏在演讲中分析了容器与云原生技术的本质,为容器在分布式架构 ...

最新文章

  1. Brilliant Programmers Show
  2. ASP.NET Core WebApi 返回统一格式参数
  3. What are current fashion trends in Sydney?
  4. Notepad++安装教程
  5. 屏幕广播系统_如何设计系统，而不是屏幕
  6. 使用 Python 切割图片
  7. 社区计算机基础知识,社区计算机基础知识试题及答案.doc
  8. （2.2）【窃密型木马-广外幽灵】简介、使用
  9. 如何让自己不再暴躁易怒
  10. E-mail营销介绍
  11. c++录屏、FFmpeg录屏、录屏格式转换
  12. OCR API身份证查验的原理
  13. 利用 CSS3 实现僵尸行走动画
  14. AUTOCAD——图纸歪了如何对齐
  15. 远程计算机或设备将不受连接（能联网QQ能上，但浏览器无法上网）
  16. 大一作业HTML网页作业 HTML CSS制作二十四节气网页
  17. 哪个论文查重软件能保证查重效果？
  18. 世界著名电影特效公司
  19. 使用Jenkins自动编译我的.net 项目
  20. 解析AUTOSAR Startup

热门文章

  1. vba 当前文件名_值得学习和珍藏的VBA常用编程代码语句
  2. matlab qtdecomp,Opencv图像识别从零到精通（25）------区域分裂与合并
  3. bootstrap 日历中文_bootstrap日期选择器本地化-中文
  4. php 数组 json字段去不全,json_encode – PHP给出了不完整的json字符串
  5. 大整数减法c语言_3.2 C语言运算符和表达式
  6. “AI女神”李飞飞：如果我获诺贝尔奖，我一定以中国人身份去领奖
  7. 2接口详解_java集合【2】——— Collection接口详解
  8. 流媒体通信协议HLS与DASH的对比
  9. hive避免MR的情况
  10. 根据经纬度求最近点的三种解法java实现