kubernetes控制平面组件：etcd

--listen-peer-urls

--listen-client-urls

--initial-advertise-peer-urls

--initial-cluster

--initial-cluster-state

--advertise-client-urls

1.code

headless svc, 像DNS RR ClusterIP:None

kubectl -n stg1 get endpoints

client 怎么访问：

2.配置文件

3.apply

官方的code有两个问题

本地访问

扩容

利用反亲和性 分布etcd pod到不同节点

~ ❯❯❯ etcdctl get / --prefix

从 etcd 的架构图中我们可以看到，etcd 主要分为四个部分。

etcd 目前支持 V2 和 V3 两个大版本，这两个版本在实现上有比较大的不同，一方面是对外提供接口的方式，另一方面就是底层的存储引擎，V2 版本的实例是一个纯内存的实现，所有的数据都没有存储在磁盘上，而 V3 版本的实例就支持了数据的持久化。

v3默认boltdb

consortium etcd2+mysql

数据默认会存放在 /var/lib/etcd/default/ 目录。我们会发现数据所在的目录，会被分为两个文件夹中，分别是 snap 和 wal目录。

解决三个问题：节点选举、日志复制以及安全性 。

每一个 Raft 集群中都包含多个服务器，在任意时刻，每一台服务器只可能处于 Leader 、 Follower 以及 Candidate 三种状态；在处于正常的状态时，集群中只会存在一个 Leader 状态，其余的服务器都是 Follower 状态。

所有的 Follower 节点都是被动的，它们不会主动发出任何的请求 ，只会响应 Leader 和 Candidate 发出的请求。对于每一个用户的可变 *** 作，都会被路由给 Leader 节点进行处理，除了 Leader 和 Follower 节点之外，Candidate 节点其实只是集群运行过程中的一个临时状态。

每一个服务器都会存储当前集群的最新任期，它就像是一个单调递增的逻辑时钟，能够同步各个节点之间的状态，当前节点持有的任期会随着每一个请求被传递到其他的节点上。Raft 协议在每一个任期的开始时都会从一个集群中选出一个节点作为集群的 Leader 节点，这个节点会负责集群中的日志的复制以及管理工作。

客户端通过 监听指定的key可以迅速感知key的变化并作出相应处理 ，watch机制的实现依赖于 资源版本号revision的设计 ，每一次key的更新都会使得revision原子递增，因此根据不同的版本号revision的对比就可以感知新事件的发生。etcd watch机制有着广泛的应用，比如利用etcd实现分布式锁； k8s中监听各种资源的变化 ，从而实现各种controller逻辑等。

watch机制的实现主要可分为三个部分

client使用 watchClient 的watch接口发起watch请求，与server端建立一个 gRPCStream 连接。

server端会为每个client生成唯一一个watch id，并记录每个client也就是watcher监听的key或者key range，通过recvLoop接收client请求，通过sendLoop发送请求，server端只负责收发请求和响应。

主要的实现都放在了watchalbStore层，watchalbStore会监听key的变化，然后通过syncWatchersLoop和syncVictimsLoop两个处理流程将key的更新变化包装成event，通过channel发送给gRPC server。

MVCC（Multiversion Concurrency Control）多版本并发控制机制

场景1:

这就是悲观锁

悲观锁：悲观得认为并发事务会冲突，所以要先拿锁，拿到锁的作修改 *** 作

场景2

数据库：写回磁盘，A写好了。哎，B和C都是version 13，我咋写？算了，报错吧。。

就是乐观锁，默认不加锁，你尽管写，冲突我认怂！乐观锁其实不是锁，只是相对悲观锁来定义，适合读多写少。

乐观锁：乐观得认为数据不会冲突，但发生冲突时要能检测到。

场景3

这就是MVCC，在 MVCC 数据库中，你更新一个 key-value 数据的时候，它并不会直接覆盖原数据，而是 新增一个版本来存储新的数据，每个数据都有一个版本号 ，版本号是一个逻辑时钟，不会因为服务器时间的差异而受影响。

MVCC不等于乐观锁！

--rev 查的是main

在底层boltdb里，实际分布是这样的：

底层的key是revision，/奥特曼是用户key，“他很帅”就是用户value

删除

之前有delete动作，但是依然有版本记录。为什么？

删除这个动作，其实etcd是在blotdb里写了一条，“删除用户/奥特曼”

此时有个问题：用户说我的确删除了啊，真的不要了！请把空间还给我啊！

回收 compact（压缩）

etcdctl compact {version}

compact 需要一个版本号。这个版本号就是写事务递增的那个版本号，compact 12345，就是说把版本12345以前的 标记删除了的数据 释放掉，用户没删除的数据肯定不能回收。

如何压缩：

注意修改go.mod

Watch

服务发现要解决的也是分布式系统中最常见的问题之一，即在同一个分布式集群中的进程或服务，要如何才能找到对方并建立连接。本质上来说，服务发现就是想要了解集群中是否有进程在监听 udp 或 tcp 端口，并且通过名字就可以查找和连接。

需要实现的功能；

discover.go

eBay payment

ebay kubernetes 控制面架构

问题

etcd是典型的读多写少存储。

在etcd v3.4.9版本中,etcdctl是通过clientv3库中访问ectd server的, client v3库基于gRPC client API封装了 *** 作etcd KVServer、Cluster、

Auth、Lease、Watch等模块的API，同时包含了负载均衡、健康探测和故障切换等特性。

负载均衡算法:

etcd通过拦截器提供了丰富的metrics、日志、请求行为检查等机制，可记录所有请求的执行耗时及错误码、来源IP等，也可控制请求是否允许通过。

etcd 实现了一些特性:

串行读过程:

client发送请求到etcd server-->Leader 节点收到请求之后,持久化到WAL日志-->广播给各个节点,等到一半以上节点上持久化成功-->将请求标记为已提交

-->ectd server 模块异步从Raft模块获取已提交的日志条目,应用到状态机。

线性读是通过ReadIndex机制保证数据一致性原理。

线性读过程:

KVServer模块收到线性读请求后,向Raft模块发起ReadIndex请求,Raft模块将Leader最新的已提交日志索引封装在ReadState结构块,通过channel

层层返回给线性读模块,线性读模块等待本节点状态机追赶上Leader进度,追赶完成后,通知KVServer模块,与状态机中的MVCC模块进行交互。

串行读具有低延时、高吞吐量的特点,适合对数据一致性要求不高的场景。

线性读解决读数据一致性要求高的场景。

MVCC的核心由内存树形索引模块和嵌入式的KV持久化存储库boltdb组成。

boltdb是基于B+ tree实现的k-v键值库,支持事物,提供GET/PUT等简易API给etcd *** 作。

etcd如何基于boltdb保存一个key的多个版本:

treeIndex是基于btree实现的。treeIndex模块只会保存用户的key和用户版本号信息,用户的key的value数据存储在boltdb里面。

从treeIndex模块中获取hello这个key对应的版本号信息,treeIndex模块基于B-tree快速查找此key, 返回此key对应的索引项keyIndex即可。

获取版本号之后,可以从boltdb模块中获取用户的key-value数据了。在访问boltdb前,首先会从一个内存读事物buffer中，

二分查找要访问key是否存在，如果命中则直接返回。

boltdb是使用bucket隔离集群元数据和用户数据,bucket就是MySQL的一个表,用户的key数据存放真的bucket名字的是key,

etcd MVCC元数据存放的bucket是meta。

Getting Started with Kubernetes | etcd

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是否产生了主缺页中断。

---