k8s etcd 与持久化存储

1、是什么

2、etcd架构及工作原理

(1) 数据流程

一个用户的请求发送过来，会经过HTTP Server转发给store进行具体事务处理，如果涉及到节点的修改，则需要交给raft模块进行状态的变更，日志的记录，然后再同步给别的etcd节点确认数据提交，最后进行数据提交，再次同步

(2)工作原理

Etcd使用 Raft协议 来维护集群内各个节点状态的 一致性 。简单说，ETCD集群是一个分布式系统，由多个节点相互通信构成整体对外服务， 每个节点都存储了完整的数据 ，并且通过Raft协议保证每个节点维护的数据是一致的

(3) 主要组成部分

(4)etcd集群中的术语

3、k8s中的etcd

(1)etcd在k8s中的作用： etcd在kubernetes集群是用来存放数据并通知变动的

(2)为什么k8s选择etcd：

PV 目前支持的类型包括：gcePersistentDisk 、AWSElasticBlockStore 、AzureFile 、AzureDisk 、FC ( Fibre Channel ） 、Flocker、NFS 、iSCSI 、RBD (Rados Block Device ）、CephFS 、Cinder、GlusterFS 、V sphere Volume 、Quobyte Volumes 、VMware Photon 、Portwonc

Volumes 、ScaleIO Volumes 和HostPath （仅供单机测试）。

如果某个Pod 想申请某种类型的PY ，则首先需要定义一个PersistentVolurneClaim ( PVC )对象，然后，在Pod 的Volume 定义中引用上述PVC 即可：

etcd是一个高可用的键值存储系统，主要用于共享配置和服务发现。

etcd是由CoreOS开发并维护的，灵感来自于 Zo好eeper 和 Doozer，它使用Go语言编写，并通过Raft一致性算法处理日志复制以保证强一致性。

Raft是一个来自Stanford的新的一致性算法，适用于分布式系统的日志复制，Raft通过选举的方式来实现一致性，在Raft中，任何一个节点都可能成为Leader。

Google的容器集群管理系统Kubernetes、开源PaaS平台Cloud Foundry和CoreOS的Fleet都广泛使用了etcd。

etcd 集群的工作原理基于 raft 共识算法 （The Raft Consensus Algorithm）。

etcd 在 0.5.0 版本中重新实现了 raft 算法，而非像之前那样依赖于第三方库 go-raft 。

raft 共识算法的优点在于可以在高效的解决分布式系统中各个节点日志内容一致性问题的同时，也使得集群具备一定的容错能力。

即使集群中出现部分节点故障、网络故障等问题，仍可保证其余大多数节点正确的步进。

甚至当更多的节点（一般来说超过集群节点总数的一半）出现故障而导致集群不可用时，依然可以保证节点中的数据不会出现错误的结果。

etcdserver:mvcc:database space exceeded错误:

etcd server收到put/txn等写请求的时候,会首先检查当前etcd db大小加上请求的key-value大小只是否超过了配额。

如果超过配额,会产生一个告警请求,告警类型为NO SPACE,并通过Raft日志同步给其他节点,告知db无空间,并将告警持久化

到db中。

etcd设置建议配额不超过8G。APPLY模块在执行每个命令的时候,都会去检查当前是否存在NO SPACE告警,如果有则拒绝写入。

在调大配额之后,需要发送一个取消告警的命令,以消除所有告警。

检查etcd的压缩是否开启、配置是否合理。在配置etcd db配额,就不要设置小于0的,这样是禁用配额功能。

为了保证集群稳定性,避免雪崩,任何提交到raft模块的请求,都会做一些简单的限速判断。

在经过检查之后,会生成一个唯一的ID,将此请求关联到一个对应的消息通知channel,然后raft模块发起Propose一个提案,向raft模块发起的提案后,

KVServer模块会等待此put请求,等待写入结果通过消息通知channel返回或者超时。etcd默认超时时间是7秒,如果一个请求超时未返回结果,则可能会出现你熟悉的

Raft模块收到提案后,如果当前节点是Follower,它会转发给Leader,只有Leader才能处理写请求,Leader收到提案后,通过Raft模块输出待转发给Follower

节点的消息和待持久化的日志条目。

etcdserver 从Raft模块获取到以上消息和日志条目后,作为Leader,它会将put提案消息广播给集群各个节点,同时需要把集群Leader任期号、投票信息、

以提交索引、提案内容持久化到一个WAL日志文件中,用于保证集群的一致性，可恢复性。

WAL记录是按照顺序追加写入组成,每个记录由类型(Type)、数据(Data)、循环冗余校验码(CRC)组成。

WAL记录类型目前支持5种,分别是文件元数据记录、日志条目记录、状态信息记录、CRC记录、快照记录:

WAL模块是如何持久化一个put提案的日志条目记录:

每个提案被提交前都会被持久化到WAL文件中,以保证集群的一致性和可恢复性。

etcd的幂等性是根据Raft日志条目中的索引字段。etcd通过引入consistent index字段,来存储系统当前已经执行过的日志条目索引,实现幂等性。

Apply模块基于consistent index和事务实现了幂等性。

MVCC主要是由两部分组成,一个是内存索引模块treeIndex,保存key的历史版本信息,另一个是boltdb模块,用来持久化存储key-value数据。

版本号在etcd里面发挥着重大作用,它是etcd的逻辑时钟。etcd启动的时候默认版本号是1,从最小值1开始枚举到最大值,未读到数据的数据则结束,最后读出来的

版本号即时当前etcd的最大版本号currentRevision。

boltdb是一个基于B+tree实现的key-value嵌入式db,通过提供桶机制实现类似于MySQL表的逻辑隔离。

将修改的数据放入到一个名为key的桶里,在启动etcd时自动创建。

boltdb value的值是将包含key名称、key创建是时版本号、最后一次修改的版本号、修改菜蔬、value值、租赁信息序列化为二进制数据。

etcd使用合并再合并解决写性能差的问题:

etcd在启动时候通过mmap机制将etcd db文件映射到etcd进程地址空间,并设置mmap的MAP_POPULATE flag,它会告诉Linux内核预读文件,Linux就会将文件内容

拷贝到物理内存中,此时会产生磁盘I/O。节点在内存足够的请求下,后续处理读请求过程中就不会产生磁盘I/O了。

如果etcd节点内存不足时,可能会导致db文件对应的内存页被换出,当读请求命中的文件未在内存中时,就会产生缺页异常,导致读过程中产生磁盘IO,

可以通过观察etcd进程

可以通过观察etcd进程的majflt字段来判断etcd是否产生了主缺页中断。

---