php从etcd获取数据 php etcd

ETCD中K8S的元数据

假设你已经通过kubeadm 安装好了K8S 和对应的etcd集群

成都创新互联公司-专业网站定制、快速模板网站建设、高性价比梧州网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式梧州网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖梧州地区。费用合理售后完善，十余年实体公司更值得信赖。

Kubenretes1.6中使用etcd V3版本的API，使用etcdctl直接ls的话只能看到/kube-centos一个路径。需要在命令前加上ETCDCTL_API=3这个环境变量才能看到kuberentes在etcd中保存的数据。

如果是使用 kubeadm 创建的集群，在 Kubenretes 1.11 中，etcd 默认使用 tls ，这时你可以在 master 节点上使用以下命令来访问 etcd ：

-w指定输出格式

将得到这样的json的结果：

使用--prefix可以看到所有的子目录，如查看集群中的namespace：

输出结果中可以看到所有的namespace。

key的值是经过base64编码，需要解码后才能看到实际值，如：

etcd中kubernetes的元数据

我们使用kubectl命令获取的kubernetes的对象状态实际上是保存在etcd中的，使用下面的脚本可以获取etcd中的所有kubernetes对象的key：

注意，我们使用了ETCD v3版本的客户端命令来访问etcd。

通过输出的结果我们可以看到kubernetes的原数据是按何种结构包括在kuberentes中的，输出结果如下所示：

我们可以看到所有的Kuberentes的所有元数据都保存在/registry目录下，下一层就是API对象类型（复数形式），再下一层是namespace，最后一层是对象的名字。

以下是etcd中存储的kubernetes所有的元数据类型：

转自

Etcd 读请求如何执行

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

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

etcd API-V2

V2版本的key在etcd是按照目录格式来存储的：

对于createdIndex 和 modifiedIndex两个值，基本上是一直相等的，当你-XPUT的时候，会同步更新这两个值，但delete和update的时候这两个值就会不同了，只有modifiedIndex会增加。

etcd的回复里面，包含了简单的消息头，里面的数据也比较重要。

数据读取比较简单，直接读取某个key就可以。

和设置一样，更改的时候用也是PUT操作

TTL就是给key设置一个timeout，时间到了之后，key会被自动删除，当然你可以在超时之前删除timeout，这样key就不会有超期了。同样的你也可以不断的去刷新key的timeout，这样可以起到看门狗的作用（可以用来探测etcd的存活）。

需要注意的一点是，timeout只会由leader来触发，如果一个instance(不是leader)因为某种原因退出集群了，那么该instance的超时key就不会删除了，除非它重新加入集群，leader会帮它删掉（个人认为这时候不再是timeout删除，而是raft底层的数据同步，会把删除操作append到节点，节点会删除数据.如果leader退出了，那么新的leader会执行timeout操作。

上面说过，在超时之前可以用命令重新更新key的ttl。

watch功能是etcd里面一个很重要的功能，现在有v2和v3两个版本。分别对应了不同的设计，可以参照下面的链接：

我们可以通过常轮训来监听key的变化，同时可以使用 recursive=true 参数来对子key（目录）监听。

注意：

etcd的watch智能保持100条记录（V2版本，v3没这个限制），所以收到通知之后应该将response交给其它线程去处理，不要在watch线程里处理，不然容易阻塞！！

前面已经说过etcd的v2版本只能保存1000个事件，如果已经事件丢失，我们需要先得到目前的状态，然后再开始监听。比如我们对一个key设置了2000次，那么etcd里面保存的直邮1000-2000的事件，如果这时候我们用下面命令：

那现在我们怎么开始监听这个key那，因为我们也不知道etcd里面保存的事件是从哪里开始的。所以我们可以使用下面命令得到etcd现在的状态。

前面已经解释过返回的信息的标志位的意思了。X-Etcd-Index代表的是etcd的状态，modifiedIndex代表的是上次修改这个key的index，X-Etcd-Index是大于等于modifiedIndex的，理论上来讲用两个index + 1是相同效果，但是用modifiedIndex可能会导致上面说的401error,所以我们一般都用X-Etcd-Index。

连接关闭指的是可能server还没来的及发送event，但由于超时或者server发生了关机，因为http的header是一旦接收到连接就会返回头部的，所以返回值会是200：ok和空的消息体。client需要自己处理这种情况。

在一个目录下使用POST可以创建出顺序的key，有时候这个功能很有用，比如需要严格按照顺序处理的事件。可以保证cleint可以公平的访问mutex锁（这个点没太搞懂）

创建一个顺序的key很简单：

这里的key的后缀是全局的etcd的index。

etcd的存储是以目录树的结构来的，所以我们可以对某个目录设置一个TTL。

目录的ttl超时的时候，如果有监听线程正在监听它下面的key，那么watch会收到一个expire的事件。

etcd主要通过三个标志位来对etcd的数据进行原子操作，注意etcd的原子操作只能针对key，不能针对目录，否则会返回102“Not a file” error。

1.prevValue - 检查key的上一个状态.

2.prevIndex -检查key的modifiedIndex.（保证没别的线程修改过）

3.prevExist - 如果是true，代表"update"请求，否则是create请求。

下面看几个例子：

etcd的删除操作也支持原子操作，标志位和上面的比少了prevExist。其它的是一样的。看例子：

在大多数情况下，目录都会在创建key的时候自动创建，但有时候我们需要自己去创建一个目录或者删除一个目录。用参数 dir=true 就可以了。

在etcd中，如果想获得目录下所有的key，可以用下面的命令：

如果没有recursive，那么只会显示目录，不会现在目录下面的key或者子目录。

删除etcd的目录的时候，如果目录下面有key或者别的目录存在，你删除的时候会返回下面的错误：

所以如果想直接删除整个目录，可以用下面的命令（recursive=true）：

etcd可以通过添加_前缀创建隐藏的key或者目录，这时候你通过GET指令是看不到这个node的。

etcd隐藏的node主要作用是为了安全性，特地去github上看了一下作者的解释。

就是说隐藏key你通过etcd的api是看不到的，除非你能登陆本地的disk，然后查看本地的存储文件。保密性高，我们可以将我们一些key放在里面。创建的指令如下：

我们可以用etcd存储一些小的配置文件。

大家都知道etcd的写操作是都要经过raft协议同步的，线性化读取也是同样的道理。如果 Get的时候使用参数 quorum=true ，那么GET操作也要走raft协议，不是本地直接返回。

我们可以查看etcd的一些内部统计信息来观察etcd的状态。主要就分为etcd的状态和存储状态。

每个标志位的含义：

etcd的存储的状态是存储在内存中的，所以重启之后是会重置各个参数。

掌握etcd的API是使用etcd的前提条件，所以把v2版本的按照个人理解和操作整理出来。后面会整理v3版本的API。

笔记本etcd什么意思

键值存储仓库，用于配置共享和服务发现。

扩展知识：etcd（读作 et-see-dee）是一种开源的分布式统一键值存储，用于分布式系统或计算机集群的共享配置、服务发现和的调度协调。etcd 有助于促进更加安全的自动更新，协调向主机调度的工作，并帮助设置容器的覆盖网络。

etcd 是许多其他项目的核心组件。最值得注意的是，它是 Kubernetes 的首要数据存储，也是容器编排的实际标准系统。使用 etcd，云原生应用可以保持更为一致的运行时间，而且在个别服务器发生故障时也能正常工作。应用从 etcd 读取数据并写入到其中；通过分散配置数据，为节点配置提供冗余和弹性。