万级K8s集群背后etcd稳定性及性能优化实践

背景与挑战

随着腾讯自研上云及公有云用户的迅速增长，一方面，腾讯云容器服务TKE服务数量和核数大幅增长, 另一方面我们提供的容器服务类型（TKE托管及独立集群、EKS弹性集群、edge边缘计算集群、mesh服务网格、serverless knative）也越来越丰富。各类容器服务类型背后的核心都是K8s，K8s核心的存储etcd又统一由我们基于K8s构建的etcd平台进行管理。基于它我们目前管理了千级etcd集群，背后支撑了万级K8s集群。

在万级K8s集群规模下的我们如何高效保障etcd集群的稳定性?

etcd集群的稳定性风险又来自哪里？

我们通过基于业务场景、历史遗留问题、现网运营经验等进行稳定性风险模型分析，风险主要来自旧TKE etcd架构设计不合理、etcd稳定性、etcd性能部分场景无法满足业务、测试用例覆盖不足、变更管理不严谨、监控是否全面覆盖、隐患点是否能自动巡检发现、极端灾难故障数据安全是否能保障。

前面所描述的etcd平台已经从架构设计上、变更管理上、监控及巡检、数据迁移、备份几个方面程度解决了我们管理的各类容器服务的etcd可扩展性、可运维性、可观测性以及数据安全性，因此本文将重点描述我们在万级K8s场景下面临的etcd内核稳定性及性能挑战，比如:

• 数据不一致
• 内存泄露
• 死锁
• 进程Crash
• 大包请求导致etcd OOM及丢包
• 较大数据量场景下启动慢
• 鉴权及查询key数量、查询指定数量记录接口性能较差

本文将简易描述我们是如何发现、分析、复现、解决以上问题及挑战，以及从以上过程中我们获得了哪些经验及教训，并将之应用到我们的各类容器服务存储稳定性保障中。

同时，我们将解决方案全部贡献、回馈给etcd开源社区， 截止目前我们贡献的30+ pr已全部合并到社区。腾讯云TKE etcd团队是etcd社区2020年上半年最活跃的贡献团队之一, 为etcd的发展贡献我们的一点力量, 在这过程中特别感谢社区AWS、Google、Ali等maintainer的支持与帮助。

稳定性优化案例剖析

从GitLab误删主库丢失部分数据到GitHub数据不一致导致中断24小时，再到号称"不沉航母"的AWS S3故障数小时等，无一例外都是存储服务。稳定性对于一个存储服务、乃至一个公司的口碑而言至关重要，它决定着一个产品生与死。稳定性优化案例我们将从数据不一致的严重性、两个etcd数据不一致的bug、lease内存泄露、mvcc 死锁、wal crash方面阐述，我们是如何发现、分析、复现、解决以上case，并分享我们从每个case中的获得的收获和反思，从中汲取经验，防患于未然。

数据不一致（Data Inconsistency）

谈到数据不一致导致的大故障，就不得不详细提下GitHub在18年一次因网络设备的例行维护工作导致的美国东海岸网络中心与东海岸主要数据中心之间的连接断开。虽然网络的连通性在43秒内得以恢复，但是短暂的中断引发了一系列事件，最终导致GitHub 24小时11分钟的服务降级，部分功能不可用。

GitHub使用了大量的MySQL集群存储GitHub的meta data,如issue、pr、page等等，同时做了东西海岸跨城级别的容灾。故障核心原因是网络异常时GitHub的MySQL仲裁服务Orchestrator进行了故障转移，将写入数据定向到美国西海岸的MySQL集群(故障前primary在东海岸)，然而美国东海岸的MySQL包含一小段写入，尚未复制到美国西海岸集群，同时故障转移后由于两个数据中心的集群现在都包含另一个数据中心中不存在的写入，因此又无法安全地将主数据库故障转移回美国东海岸。

最终, 为了保证保证用户数据不丢失，GitHub不得不以24小时的服务降级为代价来修复数据一致性。

数据不一致的故障严重性不言而喻，然而etcd是基于raft协议实现的分布式高可靠存储系统，我们也并未做跨城容灾，按理数据不一致这种看起来高大上bug我们是很难遇到的。然而梦想是美好的，现实是残酷的，我们不仅遇到了不可思议的数据不一致bug, 还一踩就是两个，一个是重启etcd有较低的概率触发，一个是升级etcd版本时如果开启了鉴权，在K8s场景下较大概率触发。在详细讨论这两个bug前，我们先看看在K8s场景下etcd数据不一致会导致哪些问题呢？

• 数据不一致最恐怖之处在于client写入是成功的，但可能在部分节点读取到空或者是旧数据,client无法感知到写入在部分节点是失败的和可能读到旧数据
• 读到空可能会导致业务Node消失、Pod消失、Node上Service路由规则消失，一般场景下，只会影响用户变更的服务
• 读到老数据会导致业务变更不生效，如服务扩缩容、Service rs替换、变更镜像异常等待，一般场景下，只会影响用户变更的服务
• 在etcd平台迁移场景下，client无法感知到写入失败，若校验数据一致性也无异常时（校验时连接到了正常节点），会导致迁移后整个集群全面故障（apiserver连接到了异常节点），用户的Node、部署的服务、lb等会被全部删除，严重影响用户业务

首先第一个不一致bug是重启etcd过程中遇到的，人工尝试复现多次皆失败，分析、定位、复现、解决这个bug之路几经波折，过程很有趣并充满挑战，最终通过我对关键点增加debug日志，编写chaos monkey模拟各种异常场景、边界条件，实现复现成功。最后的真凶竟然是一个授权接口在重启后重放导致鉴权版本号不一致，然后放大导致多版本数据库不一致, 部分节点无法写入新数据, 影响所有v3版本的3年之久bug。

随后我们提交若干个相关pr到社区, 并全部合并了, 最新的etcd v3.4.9[1]，v3.3.22[2]已修复此问题, 同时google的jingyih也已经提K8s issue和pr[3]将K8s 1.19的etcd client及server版本升级到最新的v3.4.9。此bug详细可参考超凡同学写的文章