01 | etcd的前世今生：为什么Kubernetes使用etcd？

唐聪



该思维导图由 AI 生成，仅供参考

你好，我是唐聪。
今天是专栏课程的第一讲，我们就从 etcd 的前世今生讲起。让我们一起穿越回 2013 年，看看 etcd 最初是在什么业务场景下被设计出来的？
2013 年，有一个叫 CoreOS 的创业团队，他们构建了一个产品，Container Linux，它是一个开源、轻量级的操作系统，侧重自动化、快速部署应用服务，并要求应用程序都在容器中运行，同时提供集群化的管理方案，用户管理服务就像单机一样方便。
他们希望在重启任意一节点的时候，用户的服务不会因此而宕机，导致无法提供服务，因此需要运行多个副本。但是多个副本之间如何协调，如何避免变更的时候所有副本不可用呢？
为了解决这个问题，CoreOS 团队需要一个协调服务来存储服务配置信息、提供分布式锁等能力。怎么办呢？当然是分析业务场景、痛点、核心目标，然后是基于目标进行方案选型，评估是选择社区开源方案还是自己造轮子。这其实就是我们遇到棘手问题时的通用解决思路，CoreOS 团队同样如此。
假设你是 CoreOS 团队成员，你认为在这样的业务场景下，理想中的解决方案应满足哪些目标呢？
如果你有过一些开发经验，应该能想到一些关键点了，我根据自己的经验来总结一下，一个协调服务，理想状态下大概需要满足以下五个目标：

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

etcd是一个用于存储分布式配置信息的服务，最初由CoreOS团队在2013年开发。其设计目标包括高可用性、数据一致性、低容量、功能丰富以及可维护性。etcd采用了Raft算法确保数据一致性和高可用性，提供简单易用的REST API，以及低容量设计和良好的可维护性。随着版本的迭代，etcd不断完善，从v1到v2版本，逐步实现了数据一致性保证和功能丰富的API，成为Kubernetes等系统中重要的组件。随着Kubernetes项目的发展，etcd v2版本的瓶颈和缺陷逐渐暴露，导致Kubernetes社区呼吁支持新的存储。etcd v3应运而生，通过引入B-tree、boltdb实现一个MVCC数据库，使用gRPC API和Lease优化TTL机制，解决了v2版本的稳定性、扩展性、性能问题。etcd v3的发布标志着etcd进入了技术成熟期，成为云原生时代的首选元数据存储产品。文章介绍了etcd的前世今生，从诞生背景、目标、技术点到v3版本的优化，深入解读了为什么Kubernetes使用etcd。通过对etcd v2和v3的演进过程的详细介绍，读者能清晰了解etcd从HTTP/1.x API到gRPC API、单版本数据库到多版本数据库、内存树到boltdb、TTL到Lease、单key原子更新到支持多key事务的演进过程。这篇文章为读者提供了对etcd技术特点的全面了解，同时留下思考题，引发读者对自身项目中etcd版本选择和问题解决的思考。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《etcd 实战课》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(47)

最新
精选

jeffery
1.6版本默认自带v3版本，etcd 云原生的数据首选存储产品，老师能说下etcd 和reids 的区别吗？谢谢
作者回复: Redis是吧，区别挺大的，文章中我用了一副思维导图从数据复制、数据分片、存储引擎、API等方面总结etcd v2技术点，我简单从这些方面给你对比一下，数据复制上Redis是主备异步复制、etcd使用的是Raft，前者可能会丢数据，为了保证读写一致性，etcd读写性能相比Redis差距比较大。数据分片上Redis有各种集群版解决方案，可以承载上T数据，存储的一般是用户数据，而etcd定位是个低容量的关键元数据存储，db大小一般不超过8g。存储引擎和API上Redis内存实现了各种丰富数据结构，而etcd仅是kv API, 使用的是持久化存储boltdb。
2021-01-20
4
55
[小狗]
大佬，可以1周4期吗？等着面试用呢
作者回复: 感谢对专栏的支持，正如你所看到的，专栏27讲，每讲内容特别丰富，大部分5000到6000字，整个专栏至少15万字，写作不易，我也是在工作日的凌晨、周末业余时间为大家呈现一个etcd全方位特性解读，更新是固定的1周3篇，春节都在加班加点创作了，麻烦稍等哈，基础篇春节期间会更新完毕，你把基础篇的内容踏踏实实学完，动手做几个小实验，我相信面试哪个大厂，都无压力了哈。
2021-02-04
4
26
hxy
zookeeper的rpc api是thrift，这个感觉说错了吧，zk用的应该是jute
作者回复: 感谢你的细心和反馈，我查阅etcd官方资料写得也是的确有误，之前以为是很久之前zk使用的rpc api，看了下commit记录貌似一直都是juite，后面我们修正下，谢谢
2021-01-23

22
NICE
目前在使用etcd v3, 高可用，强一致性键值存储。关于etcd集群异地容灾同步目前用的make mirror，有更好的方案吗？哈哈😃
作者回复: 也有可能在部分场景出现不一致哈，后面实践篇会和大家分析。异地容灾建议使用raft learner特性，添加learner节点，make mirror是基于watch机制的，稳定性、可靠性等相比learner要差点，但是目前社区对learner限制太多，不支持快照等，我们自己做了定制化，大家使用上要等等，估计3.5版本才比较好用
2021-01-21
3
10
mckee
k8s list pod不带rev情况下，etcdserver key range会造成cpu和mem瞬间飙高，需要读取所有kv并排序
作者回复: 嗯，list pod太恐怖了，哈哈，线上大部分异常一般都是list pod，configmap，crd
2021-01-26
2
7
SecKiki
学习了，etcd与k8s 绝配
作者回复: 嗯，etcd与k8s相互影响、促进，etcd社区任何核心特性首先也是考虑是否有益于k8s场景等，新版本发布，也是拿k8s做性能稳定性测试
2021-01-20

4
范闲
etcd用来做服务发现，治理，分布式锁，还有配置信息存储很好用。缺点是异地多活不好用，延迟有点大。
作者回复: 是的，我们使用raft learner节点，跨城容灾，进行了一些定制化改造
2021-01-22

2
GAC·DU
读了两遍还是感觉很吃力，需要去恶补一下不懂的知识。有个疑问想让老师解惑一下，etcdV1和V2版本并没有ZK社区成熟功能也没有ZK强大，为什么K8S选择了和etcd一起成长，而不是等着etcd各方面完善和强大起来再从ZK切换到etcd？
作者回复: 我认为最主要的是还是Go语言和容器生态，zookeeper当时也没好用的go client库，watch特性也没etcd好用，核心还是文中说得，当时没一个项目满足k8s需求，只有coreos团队不停的推动etcd与k8s相互适配改造，维护k8s etcd代码，让k8s核心开发者有更多精力去开发更重要的特性开发。
2021-01-21

2
爪哇夜未眠
挺好的文章
作者回复: 感谢你的留言与支持
2021-01-20

2
saltedfish
爽啊，这种从诞生背景顺着发展路线讲下来的思路能让人真正理解为什么现在的etcd是这个样子的，感谢作者！
作者回复: 嗯，感谢支持，想深入了解更多的，可以翻一番早期etcd/kubernetes issue/pr
2022-04-24

1

收起评论