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

蚂蚁集团运维着可能是全球最大的 k8s 集群：k8s 官方以 5k node 作为 k8s 规模化的顶峰，而蚂蚁集团事实上运维着规模达到 10k node 规模的 k8s 集群。一个形象的比喻就是，如果官方以及跟着官方的 k8s 使用者能想象到的 k8s 的集群规模是泰山，那么蚂蚁集团在官方的解决方案之上已经实现了一个珠穆朗玛峰，引领了 k8s 规模化技术的提升。 

这个量级的差异，不仅仅是量的差异，更是 k8s 管理维护的质的提升。能维护有如此巨大挑战巨量规模的 k8s 集群，其背后原因是蚂蚁集团付出了远大于 k8s 官方的优化努力。

所谓万丈高楼平地起，本文着重讨论下蚂蚁集团的在 k8s 的基石 --- etcd 层面做出的高可用建设工作：只有 etcd 这个基石稳当了，k8s 这栋高楼大厦才保持稳定性，有 tidb 大佬黄东旭朋友圈佐证【图片已获黄总授权】。

面临的挑战

etcd 首先是 k8s 集群的 KV 数据库。 

从数据库的角度来看，k8s 整体集群架构各个角色如下：

• etcd 集群的数据库

• kube-apiserver etcd 的 API 接口代理、数据缓存层

• kubelet 数据的生产者和消费者

• kube-controller-manager 数据的消费者和生产者

• kube-scheduler 数据的消费者和生产者

etcd 本质是一个 KV 数据库，存储了 k8s 自身资源 、用户自定义的 CRD 以及 k8s 系统的 event 等数据。每种数据的一致性和数据安全性要求不一致，如 event 数据的安全性小于 k8s 自身的资源数据以及 CRD 数据。

k8s 的早期拥护者在推广 k8s 时，宣称其比 OpenStack 的优势之一是 k8s 没有使用消息队列，其延迟比 OpenStack 低。这其实是一个误解，无论是 etcd 提供的 watch 接口，还是 k8s client 包中的 informer 机制，无不表明 k8s 是把 etcd 当做了消息队列，k8s 消息的载体很多，譬如 k8s event。

从消息队列的角度来看，k8s 整体集群架构各个角色如下：

• etcd 消息路由器

• kube-apiserver etcd 生产者消息代理和消息广播【或者成为次级消息路由器、消费者代理】

• kubelet 消息的生产者和消费者

• kube-controller-manager 消息的消费者和生产者

• kube-scheduler 消息的消费者和生产者

etcd 是推模式的消息队列。etcd 是 k8s 集群的 KV 数据库和消息路由器，充当了 OpenStack 集群中的 MySQL 和 MQ 两个角色，这样的实现貌似简化了集群的结构，但其实不然。在 large scale 规模 k8s 集群中，一般经验，首先都会使用一个单独 etcd 集群存储 event 数据：把 KV 数据和一部分 MQ 数据物理隔离开，实现了 KV 和 MQ 角色的部分分离。 如 参考文档 2 中提到美团 “针对 etcd 的运营，通过拆分出独立的 event 集群降低主库的压力”。

当 k8s 集群规模扩大时，etcd 承载着 KV 数据剧增、event 消息暴增以及消息写放大的三种压力。为了证明所言非虚，特引用部分数据为佐证：

• etcd KV 数据量级在 100 万以上；

• etcd event 数据量在 10 万以上；

• etcd 读流量压力峰值在 30 万 pqm 以上，其中读 event 在 10k qpm 以上；

• etcd 写流量压力峰值在 20 万 pqm 以上，其中写 event 在 15k qpm 以上；

• etcd CPU 经常性飙升到 900% 以上；

• etcd 内存 RSS 在 60 GiB 以上；

• etcd 磁盘使用量可达 100 GiB 以上；

• etcd 自身的 goroutine 数量 9k 以上；

• etcd 使用的用户态线程达 1.6k 以上；

• etcd gc 单次耗时常态下可达 15ms。

使用 Go 语言实现的 etcd 管理这些数据非常吃力，无论是 CPU、内存、gc、goroutine 数量还是线程使用量，基本上都接近 go runtime 管理能力极限：经常在 CPU profile 中观测到 go runtime 和 gc 占用资源超过 50% 以上。

蚂蚁的 k8s 集群在经历高可用项目维护之前，当集群规模突破 7 千节点规模时，曾出现如下性能瓶颈问题：

• etcd 出现大量的读写延迟，延迟甚至可达分钟级；

• kube-apiserver 查询 pods / nodes / configmap / crd 延时很高，导致 et