k8s相关服务etcd原理

k8s相关服务etcd原理

ETCD

Etcd v2版本存储在memory（注意备份）1.11版本已弃用

V3版本本地卷持久化

采用，wal预写日志定时将日志(完整+临时)备份snapshot

增量备份，，，一定时间完整备份，将日志实时写入本地持久化存储

1、etcd 被设计为提供高可用、强一致的小型 keyvalue 数据存储服务。

2、​在 etcd 整个架构中，有一个非常关键的概念叫做 quorum，quorum 的定义是 （n+1）/2，也就是说超过集群中半数节点组成的一个团体，在 3 个节点的集群中，etcd 可以容许 1 个节点故障，也就是只要有任何 2 个节点可用，etcd 就可以继续提供服务。同理，在 5 个节点的集群中，只要有任何 3 个节点可用，etcd 就可以继续提供服务，这也是 etcd 集群高可用的关键。

​在允许部分节点故障之后继续提供服务，就需要解决一个非常复杂的问题：分布式一致性。在 etcd 中，该分布式一致性算法由 Raft 一致性算法完成

​接下来我们看一下 etcd 提供的接口，这里将 etcd 的接口分为了 5 组：

​第一组是 Put 与 Delete。上图可以看到 put 与 delete 的操作都非常简单，只需要提供一个 key 和一个 value，就可以向集群中写入数据了，删除数据的时候只需要指定 key 即可； 第二组是查询操作。etcd 支持两种类型的查询：第一种是指定单个 key 的查询，第二种是指定的一个 key 的范围； 第三组是数据订阅。etcd 提供了 Watch 机制，我们可以利用 watch 实时订阅到 etcd 中增量的数据更新，watch 支持指定单个 key，也可以指定一个 key 的前缀，在实际应用场景中的通常会采用第二种形势； 第四组事务操作。etcd 提供了一个简单的事务支持，用户可以通过指定一组条件满足时执行某些动作，当条件不成立的时候执行另一组操作，类似于代码中的 if else 语句，etcd 确保整个操作的原子性； 第五组是 Leases 接口。Leases 接口是分布式系统中常用的一种设计模式，其用法后面会具体展开。​数据版本机制要正确使用 etcd 的 API，必须要知道内部对应数据版本号的基本原理。首先 etcd 中有个 term 的概念，代表的是整个集群 Leader 的任期。当集群发生 Leader 切换，term 的值就会 +1。在节点故障，或者 Leader 节点网络出现问题，再或者是将整个集群停止后再次拉起，都会发生 Leader 的切换。第二个版本号叫做 revision，revision 代表的是全局数据的版本。当数据发生变更，包括创建、修改、删除，其 revision 对应的都会 +1。特别的，在集群中跨 Leader 任期之间，revision 都会保持全局单调递增。正是 revision 的这一特性，使得集群中任意一次的修改都对应着一个唯一的 revision，因此我们可以通过 revision 来支持数据的 MVCC，也可以支持数据的 Watch。对于每一个 KeyValue 数据节点，etcd 中都记录了三个版本：第一个版本叫做 create_revision，是 KeyValue 在创建时对应的 revision；第二个叫做 mod_revision，是其数据被操作的时候对应的 revision；第三个 version 就是一个计数器，代表了 KeyValue 被修改了多少次。典型的使用场景​元数据存储Kubernetes 将自身所用的状态存储在 etcd 中，其状态数据的高可用交给 etcd 来解决，Kubernetes 系统自身不需要再应对复杂的分布式系统状态处理，自身的系统架构得到了大幅的简化。​Server Discovery （Naming Service）第二个场景是 Service Discovery，也叫做名字服务。在分布式系统中，通常会出现的一个模式就是需要多个后端（可能是成百上千个进程）来提供一组对等的服务，比如说检索服务、推荐服务。​

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。