Etcd是CoreOS基于Raft开发的分布式key-value存储,可用于服务发现、共享配置以及一致性 保障(如数据库选主、分布式锁等)。
在分布式系统中,如何管理节点间的状态一直是一个难题,etcd像是专门为集群环境的服务发现 和注册而设计,它提供了数据TTL失效、数据改变监视、多值、目录监听、分布式锁原子操作等 功能,可以方便的跟踪并管理集群节点的状态。
etcd是一个 键值存储 的组件,其他的应用都是基于其键值存储的功能展开。
下载安装包,参考https://github.com/etcd-io/etcd/releases
更多信息
https://github.com/cncamp/101/blob/master/module5/1.etcd-member-list.MD
目前有很多支持etcd的库和客户端工具
查看集群成员状态
etcdctlmember list --write-out=table
+------------------+---------+---------+-----------------------+-----------------------+------------+
| ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | IS LEARNER |
+------------------+---------+---------+-----------------------+-----------------------+------------+
| 8e9e05c52164694d | started | default | http://localhost:2380 | http://localhost:2379 | false |
+------------------+---------+---------+-----------------------+-----------------------+------------+
基本的数据读写操作
etcdctl--endpoints=localhost:12379 put /a b
OK
etcdctl--endpoints=localhost:12379 get /a
/a
b
etcdctl--endpoints=localhost:12379 get --prefix /
etcdctl--endpoints=localhost:12379 get --prefix / --keys-only--debug
TTL(timeto live)指的是给一个key设置一个有效期,到期后这个key就会被自动删掉,这在 很多分布式锁的实现上都会用到,可以保证锁的实时有效性。
Atomic Compare-and-Swap(CAS)指的是在对key进行赋值的时候,客户端需要提供一些条 件,当这些条件满足后,才能赋值成功。这些条件包括:
这样的话,key的设置是有前提的,需要知道这个key当前的具体情况才可以对其设置。
Raft协议基于quorum机制,即大多数同意原则,任何的变更都需超过半数的成员确认
http://thesecretlivesofdata.com/raft/
Raft 4.2.1引入的新角色
当出现一个etcd集群需要增加节点时,新节点与 Leader的数据差异较大,需要较多数据同步才能跟 上leader的最新的数据。
此时Leader的网络带宽很可能被用尽,进而使得 leader无法正常保持心跳。
进而导致follower重新发起投票。
进而可能引发etcd集群不可用。
Learner角色只接收数据而不参与投票,因此增加 learner节点时,集群的quorum不变。
选举方法
当接Leader收到客户端的日志(事务请求)后先把该日志追加到本地的Log中,然后通过 heartbeat把该Entry同步给其他Follower,Follower接收到日志后记录日志然后向Leader发送 ACK,当Leader收到大多数(n/2+1)Follower的ACK信息后将该日志设置为已提交并追加到 本地磁盘中,通知客户端并在下个heartbeat中Leader将通知所有的Follower将该日志存储在自 己的本地磁盘中。
安全性是用于保证每个节点都执行相同序列的安全机制,如当某个Follower在当前Leader commit Log时变得不可用了,稍后可能该Follower又会被选举为Leader,这时新Leader可能 会用新的Log覆盖先前已committed的Log,这就是导致节点执行不同序列;Safety就是用于保 证选举出来的Leader一定包含先前committed Log的机制;
选举安全性(Election Safety):每个任期(Term)只能选举出一个Leader
Leader完整性(Leader Completeness):指Leader日志的完整性,当Log在任期Term1被 Commit后,那么以后任期Term2、Term3...等的Leader必须包含该Log;Raft在选举阶段就使 用Term的判断用于保证完整性:当请求投票的该Candidate的Term较大或Term相同Index更大 则投票,否则拒绝该请求。
2 )follower节点不可用:follower 节点不可用的情况相对容易解决。因为集群中的日志内容始 终是从leader 节点同步的,只要这一节点再次加入集群时重新从 leader 节点处复制日志即可。
3 )多个candidate:冲突后candidate将随机选择一个等待间隔(150ms ~ 300ms)再次发起 投票,得到集群中半数以上follower接受的candidate将成为leader
wal日志是二进制的,解析出来后是以上数据结构LogEntry。其中第一个字段type,只有两种, 一种是 0 表示Normal, 1 表示ConfChange(ConfChange表示 Etcd本身的配置变更同步,比 如有新的节点加入等)。第二个字段是term,每个term代表一个主节点的任期,每次主节点变 更term就会变化。第三个字段是index,这个序号是严格有序递增的,代表变更序号。第四个字 段是二进制的data,将raft request对象的pb结构整个保存下。etcd 源码下有个tools/etcd- dump-logs,可以将wal日志dump成文本查看,可以协助分析Raft协议。
Raft协议本身不关心应用数据,也就是data中的部分,一致性都通过同步wal日志来实现,每个 节点将从主节点收到的data apply到本地的存储,Raft只关心日志的同步状态,如果本地存储实 现的有bug,比如没有正确的将data apply到本地,也可能会导致数据不一致。
etcdv3 store 分为两部分,一部分是内存中的索引,kvindex,是基于Google开源的一个 Golang的btree实现的,另外一部分是后端存储。按照它的设计,backend可以对接多种存储, 当前使用的boltdb。boltdb是一个单机的支持事务的kv存储,etcd 的事务是基于boltdb的事务 实现的。etcd 在boltdb中存储的key是reversion,value是 etcd 自己的key-value组合,也就 是说etcd 会在boltdb中把每个版本都保存下,从而实现了多版本机制。
reversion主要由两部分组成,第一部分main rev,每次事务进行加一,第二部分sub rev,同一 个事务中的每次操作加一。
etcd 提供了命令和设置选项来控制compact,同时支持put操作的参数来精确控制某个key的历 史版本数。
内存kvindex保存的就是key和reversion之前的映射关系,用来加速查询。
etcdv3 的watch机制支持watch某个固定的key,也支持watch一个范围(可以用于模拟目录的 结构的watch),所以 watchGroup包含两种watcher,一种是 key watchers,数据结构是每 个key对应一组watcher,另外一种是 range watchers, 数据结构是一个IntervalTree,方便通 过区间查找到对应的watcher。
同时,每个WatchableStore 包含两种 watcherGroup,一种是synced,一种是unsynced, 前者表示该group的watcher数据都已经同步完毕,在等待新的变更,后者表示该group的 watcher数据同步落后于当前最新变更,还在追赶。
当etcd 收到客户端的watch请求,如果请求携带了revision参数,则比较请求的revision和 store当前的revision,如果大于当前revision,则放入synced组中,否则放入unsynced组。同 时etcd会启动一个后台的goroutine持续同步unsynced的watcher,然后将其迁移到synced组。 也就是这种机制下,etcd v3 支持从任意版本开始watch,没有v2的 1000 条历史event表限制的 问题(当然这是指没有compact的情况下)
查看集群成员状态
etcdctlmember list --write-out=table
+------------------+---------+---------+-----------------------+-----------------------+----- -------+
| ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | IS LEARNER |
+------------------+---------+---------+-----------------------+-----------------------+----- -------+
| 8e9e05c52164694d | started | default | http://localhost:2380 | http://localhost:2379 | false |
+------------------+---------+---------+-----------------------+-----------------------+----- -------+
docker run -d registry.aliyuncs.com/google_containers/etcd:3.5.0-0 /usr/local/bin/etcd
dockerps|grepetcd
docker exec –it sh
etcdctlput x 0
etcdctlget x -w=json
{"header":{"cluster_id":14841639068965178418,"member_id":10276657743932975437,"r evision":2,"raft_term":2},"kvs":[{"key":"eA==","create_revision":2,"mod_revision":2,"versi on":1,"value":"MA=="}],"count":1}
etcdctlput x 1
etcdctlget x
x
1
etcdctlget x --rev=2
x
0
成员相关参数
--name 'default'
Human-readable name for this member.
--data-dir'${name}.etcd'
Path to the data directory.
--listen-peer-urls 'http://localhost:2380'
List of URLs to listen on for peer traffic.
--listen-client-urls 'http://localhost:2379'
List of URLs to listen on for client traffic.
集群相关参数
--initial-advertise-peer-urls 'http://localhost:2380'
List of this member's peer URLs to advertise to the rest of the cluster.
--initial-cluster 'default=http://localhost:2380'
Initial cluster configuration for bootstrapping.
--initial-cluster-state 'new'
Initial cluster state ('new' or 'existing').
--initial-cluster-token 'etcd-cluster'
Initial cluster token for the etcd cluster during bootstrap.
--advertise-client-urls 'http://localhost:2379'
List of this member's client URLs to advertise to the public.
etcd安全相关参数
--cert-file ''
Path to the client server TLS cert file.
--key-file ''
Path to the client server TLS key file.
--client-crl-file ''
Path to the client certificate revocation list file.
--trusted-ca-file ''
Path to the client server TLS trusted CA cert file.
--peer-cert-file ''
Path to the peer server TLS cert file.
--peer-key-file ''
Path to the peer server TLS key file.
--peer-trusted-ca-file ''
Path to the peer server TLS trusted CA file.
etcdctl--endpoints https://127.0.0.1:3379 --cert /tmp/etcd-certs/certs/127.0.0.1.pem --
key /tmp/etcd-certs/certs/127.0.0.1-key.pem --cacert/tmp/etcd-certs/certs/ca.pem
snapshot save snapshot.db
etcdctlsnapshot restore snapshot.db\
--name infra2 \
--data-dir=/tmp/etcd/infra2 \
--initial-cluster
infra0=http://127.0.0.1:3380,infra1=http://127.0.0.1:4380,infra2=http://127.0.0.1:5380 \
--initial-cluster-token etcd-cluster- 1 \
--initial-advertise-peer-urls http://127.0.0.1:5380
单个对象不建议超过1.5M
默认容量2G
不建议超过8G
$ etcd--quota-backend-bytes =$((16 * 1024 * 1024))
$ while [ 1 ]; do dd if=/dev/urandombs=1024 count=1024 | ETCDCTL_API=3 etcdctlput key || break; done
$ ETCDCTL_API =3 etcdctl--write-out = table endpoint status
$ ETCDCTL_API =3 etcdctlalarm list
$ ETCDCTL_API =3 etcdctldefrag
$ ETCDCTL_API =3 etcdctlalarm disarm
//keep one hour of history
$ etcd --auto-compaction-retention=1
//compact up to revision 3
$ etcdctlcompact 3
$ etcdctl defrag
Finished defragmenting etcd member [127.0.0.1:2379]
etcd-operator: coreos开源的,基于kubernetes CRD完成etcd集群配置。Archived
https://github.com/coreos/etcd-operator
Etcdstatefulset Helm chart: Bitnami(powered by vmware)
https://bitnami.com/stack/etcd/helm
https://github.com/bitnami/charts/blob/master/bitnami/etcd
https://github.com/coreos/etcd-operator.git
https://github.com/helm/helm/releases
helm repo add bitnamihttps://charts.bitnami.com/bitnami
helm install my-release bitnami/etcd
kubectlrun my-release-etcd-client --restart='Never' --image docker.io/bitnami/etcd:3.5.0-debian- 10 - r94 --env ROOT_PASSWORD=$(kubectlget secret --namespace default my-release-etcd -o jsonpath="{.data.etcd-root-password}" | base64 --decode) --env ETCDCTL_ENDPOINTS="my-release- etcd.default.svc.cluster.local:2379" --namespace default --command --sleep infinity
etcd是kubernetes的后端存储
对于每一个kubernetesObject,都有对应的storage.go负责对象的存储操作
API server 启动脚本中指定etcdservers集群
spec:
containers:
- command:
- kube-apiserver
- --advertise-address=192.168.34.2
- --enable-bootstrap-token-auth=true
- --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
- --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
- --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key
- --etcd-servers=https://127.0.0.1:2379
早期APIserver 对etcd做简单的Ping check,现在已经改为真实的etcd api call
ksexec -it etcd-cadmin sh
ETCDCTL_API=3
alias ectl='etcdctl --endpoints https://127.0.0.1:2379
--cacert/etc/kubernetes/pki/etcd/ca.crt
--cert /etc/kubernetes/pki/etcd/server.crt
--key /etc/kubernetes/pki/etcd/server.key
ectlget --prefix --keys-only / /registry/namespaces/calico-apiserver /registry/networkpolicies/calico-apiserver/allow-apiserver /registry/operator.tigera.io/tigerastatuses/apiserver /registry/pods/calico-apiserver/calico-apiserver-77dffffcdf-g2tcx /registry/pods/default/toolbox-68f79dd5f8-4664n
etcd是kubernetes的后端存储
对于每一个kubernetes Object,都有对应的storage.go 负责对象的存储操作
API server 启动脚本中指定etcd servers集群
多少个peer最适合?
保证apiserver和etcd之间的高效性通讯
➢ peer和peer之间的通讯加密 ➢ 是否有需求 ➢ TLS的额外开销 ➢ 运营复杂度增加 ➢ 数据加密 ➢ 是否有需求? ➢ Kubernetes提供了针对secret的加密 ➢ https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
事件分离
如何监控?
减少网络延迟
对于磁盘延迟,典型的旋转磁盘写延迟约为 10 毫秒。对于SSD(Solid State Drives,固态硬 盘),延迟通常低于 1 毫秒。HDD(Hard Disk Drive,硬盘驱动器)或者网盘在大量数据读写 操作的情况下延时会不稳定。因此强烈建议使用SSD。
同时为了降低其他应用程序的I/O操作对etcd的干扰,建议将etcd的数据存放在单独的磁盘内。 也可以将不同类型的对象存储在不同的若干个etcd集群中,比如将频繁变更的event对象从主 etcd集群中分离出来,以保证主集群的高性能。在APIServer处这是可以通过参数配置的。这些 etcd集群最好也分别能有一块单独的存储磁盘。
如果不可避免地,etcd和其他的业务共享存储磁盘,那么就需要通过下面ionice命令对etcd服务 设置更高的磁盘I/O优先级,尽可能避免其他进程的影响。
$ ionice -c2 -n0 -p 'pgrepetcd'
etcd以日志的形式保存数据,无论是数据创建还是修改,它都将操作追加到日志文件,因此日志 文件大小会随着数据修改次数而线性增长。
当Kubernetes集群规模较大时,其对etcd集群中的数据更改也会很频繁,集群日记文件会迅速 增长。
为了有效降低日志文件大小,etcd会以固定周期创建快照保存系统的当前状态,并移除旧日志文 件。另外当修改次数累积到一定的数量(默认是 10000 ,通过参数“--snapshot-count”指 定),etcd也会创建快照文件。
如果etcd的内存使用和磁盘使用过高,可以先分析是否数据写入频度过大导致快照频度过高,确 认后可通过调低快照触发的阈值来降低其对内存和磁盘的使用。
存储空间的配额用于控制etcd数据空间的大小。合理的存储配额可保证集群操作的可靠性。如果 没有存储配额,也就是etcd可以利用整个磁盘空间,etcd的性能会因为存储空间的持续增长而 严重下降,甚至有耗完集群磁盘空间导致不可预测集群行为的风险。如果设置的存储配额太小, 一旦其中一个节点的后台数据库的存储空间超出了存储配额,etcd就会触发集群范围的告警,并 将集群置于只接受读和删除请求的维护模式。只有在释放足够的空间、消除后端数据库的碎片和 清除存储配额告警之后,集群才能恢复正常操作。
etcd会为每个键都保存了历史版本。为了避免出现性能问题或存储空间消耗完导致写不进去的问 题,这些历史版本需要进行周期性地压缩。压缩历史版本就是丢弃该键给定版本之前的所有信息, 节省出来的空间可以用于后续的写操作。etcd支持自动压缩历史版本。在启动参数中指定参数 “--auto-compaction”,其值以小时为单位。也就是etcd会自动压缩该值设置的时间窗口之 前的历史版本。
压缩历史版本,相当于离散地抹去etcd存储空间某些数据,etcd存储空间中将会出现碎片。这 些碎片无法被后台存储使用,却仍占据节点的存储空间。因此定期消除存储碎片,将释放碎片化 的存储空间,重新调整整个存储空间。
当网络延迟和磁盘延迟固定的情况下,可以优化etcd运行参数来提升集群的工作效率。etcd基于Raft 协议进行Leader选举,当Leader选定以后才能开始数据读写操作,因此频繁的Leader选举会导致数 据读写性能显著降低。可以通过调整心跳周期(HeatbeatInterval)和选举超时时间(Election Timeout),来降低Leader选举的可能性。
心跳周期是控制Leader以何种频度向Follower发起心跳通知。心跳通知除表明Leader活跃状态之外, 还带有待写入数据信息,Follower依据心跳信息进行数据写入,默认心跳周期是100ms。选举超时时 间定义了当Follower多久没有收到Leader心跳,则重新发起选举,该参数的默认设置是1000ms。
如果etcd集群的不同实例部署在延迟较低的相同数据中心,通常使用默认配置即可。如果不同实例部 署在多数据中心或者网络延迟较高的集群环境,则需要对心跳周期和选举超时时间进行调整。建议心 跳周期参数推荐设置为接近etcd多个成员之间平均数据往返周期的最大值,一般是平均RTT的0.55- 1.5倍。如果心跳周期设置得过低,etcd会发送很多不必要的心跳信息,从而增加CPU和网络的负担。 如果设置得过高,则会导致选举频繁超时。选举超时时间也需要根据etcd成员之间的平均RTT时间来 设置。选举超时时间最少设置为etcd成员之间RTT时间的 10 倍,以便对网络波动。
心跳间隔和选举超时时间的值必须对同一个etcd集群的所有节点都生效,如果各个节点配置不同,就 会导致集群成员之间协商结果不可预知而不稳定。
etcd的默认工作目录下会生成两个子目录:wal和snap。wal是用于存放预写式日志,其最大的 作用是记录整个数据变化的全部历程。所有数据的修改在提交前,都要先写入wal中。
snap是用于存放快照数据。为防止wal文件过多,etcd会定期(当wal中数据超过 10000 条记录 时,由参数“--snapshot-count”设置)创建快照。当快照生成后,wal中数据就可以被删除了。
如果数据遭到破坏或错误修改需要回滚到之前某个状态时,方法就有两个:一是从快照中恢复数 据主体,但是未被拍入快照的数据会丢失;而是执行所有WAL中记录的修改操作,从最原始的 数据恢复到数据损坏之前的状态,但恢复的时间较长。
官方推荐etcd集群的备份方式是定期创建快照。和etcd内部定期创建快照的目的不同,该备份方式依赖外部 程序定期创建快照,并将快照上传到网络存储设备以实现etcd数据的冗余备份。上传到网络设备的数据,都 应进行了加密。即使当所有etcd实例都丢失了数据,也能允许etcd集群从一个已知的良好状态的时间点在任 一地方进行恢复。根据集群对etcd备份粒度的要求,可适当调节备份的周期。在生产环境中实测,拍摄快照 通常会影响集群当时的性能,因此不建议频繁创建快照。但是备份周期太长,就可能导致大量数据的丢失。
这里可以使用增量备份的方式。如图 3 - 8 所示,备份程序每 30 分钟触发一次快照的拍摄。紧接着它从快照结 束的版本(Revision)开始,监听etcd集群的事件,并每 10 秒钟将事件保存到文件中,并将快照和事件文件 上传到网络存储设备中。 30 分钟的快照周期对集群性能影响甚微。当大灾难来临时,也至多丢失 10 秒的数据。 至于数据修复,首先把数据从网络存储设备中下载下来,然后从快照中恢复大块数据,并在此基础上依次应 用存储的所有事件。这样就可以将集群数据恢复到灾难发生前。
保证apiserver和etcd之间的高效性通讯
➢ https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
apiVersion: API Server.config.k 8 s.io/v 1
kind: EncryptionConfiguration
resources:
- secrets
providers:
- identity: {}
- aesgcm:
keys:
- name: key 1
secret: c 2 VjcmV 0 IGlzIHNlY 3 VyZQ==
- name: key 2
secret: dGhpcyBpcyBwYXNzd 29 yZA==
- aescbc:
keys:
- name: key 1
secret: c 2 VjcmV 0 IGlzIHNlY 3 VyZQ==
- secretbox:
keys:
- name: key 1
secret: YWJjZGVmZ 2 hpamtsbW 5 vcHFyc 3 R 1 dnd 4 eXoxMjM 0 NTY=
- kms:
name : myKmsPlugin
endpoint: unix:///tmp/socketfile.sock
cachesize: 100
/usr/local/bin/kube-apiserver--etcd-servers=https://localhost:4001 --etcd- cafile=/etc/ssl/kubernetes/ca.crt--storage-backend=etcd3 --etcd-servers- overrides=/events#https://localhost:4002
返回某namespace中的所有Pod
GET /api/v1/namespaces/test/pods
200 OK
Content-Type: application/json
{ "kind": "PodList", "apiVersion": "v1", "metadata": {"resourceVersion":"10245"}, "items": [...] }
200 OK Transfer-Encoding: chunked
Content-Type: application/json
{ "type": "ADDED", "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "10596", ...}, ...}
} { "type": "MODIFIED", "object": {"kind": "Pod", "apiVersion": "v1", "metadata": {"resourceVersion": "11020", ...}, ...} } ...
200 OK Content-Type: application/json
{
"kind": "PodList", "apiVersion": "v1", "metadata": { "resourceVersion":"10245", "continue": "ENCODED_CONTINUE_TOKEN", }, "items": [...] // returns pods 1- 500 }
200 OK Content-Type: application/json
{ "kind": "PodList", "apiVersion": "v1", "metadata": { "resourceVersion":"10245", "continue": "ENCODED_CONTINUE_TOKEN_2", }, "items": [...] // returns pods 501- 1000 }
频繁的leaderelection
etcd 分裂
etcd 不响应
与apiserver之间的链路阻塞
磁盘暴涨
Case: 网络分区出现 Group#1: master-1, master- 2 Group#2: master-3, master-4, master- 5
B树和B+树
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。