etcd
1、是什么
- Etcd是一个高可用的键值存储系统，主要用于共享配置和服务发现，它通过Raft一致性算法处理日志复制以保证强一致性，我们可以理解它为一个高可用强一致性的服务发现存储仓库
- 在kubernetes集群中，etcd主要用于配置共享和服务发现
- Etcd主要解决的是分布式系统中数据一致性的问题，而分布式系统中的数据分为控制数据和应用数据，etcd处理的数据类型为控制数据，对于很少量的应用数据也可以进行处理
- 简单：go语言编写，部署简单，使用HTTP作为接口使用简单，使用raft算法保证强一致性。
- 数据持久化：etcd默认数据一更新就进行持久化
- 安全：etcd支持ssl客户端安全认证
2、etcd架构及工作原理
image.png
(1) 数据流程
一个用户的请求发送过来，会经过HTTP Server转发给store进行具体事务处理，如果涉及到节点的修改，则需要交给raft模块进行状态的变更，日志的记录，然后再同步给别的etcd节点确认数据提交，最后进行数据提交，再次同步
(2)工作原理
Etcd使用Raft协议来维护集群内各个节点状态的一致性。简单说，ETCD集群是一个分布式系统，由多个节点相互通信构成整体对外服务，每个节点都存储了完整的数据，并且通过Raft协议保证每个节点维护的数据是一致的
(3) 主要组成部分
- HTTP Server： 用于处理用户发送的API请求以及其他etcd节点的同步与心跳信息请求
- Store: 用于处理 etcd 支持的各类功能的事务，包括数据索引、节点状态变更、监控与反馈、事件处理与执行等等，是 etcd 对用户提供的大多数 API 功能的具体实现。
- Raft： Raft 强一致性算法的具体实现，是 etcd 的核心
- WAL：Write Ahead Log（预写式日志/日志先行），是 etcd 的数据存储方式，也是一种实现事务日志的标准方法。etcd通过 WAL 进行持久化存储，所有的数据提交前都会事先记录日志
(4)etcd集群中的术语
- Raft: etcd所采用的保证分布式系统强一致的算法，分为三部分，Leader选举，日志复制和安全性
- Node: 一个Raft状态实例
- Member: 一个etcd实例,管理一个Node，可以为客户端请求提供服务
- Cluster: 多个Member构成的可以协同工作的etcd集群
- Peer: 同一个集群中，其他Member的称呼
- Client: 向etcd集群发送HTTP请求的客户端
- WAL: 预写日志，是etcd用于持久化存储的日志格式
- Snapshot: etcd防止WAL文件过多而设置的快照，存储etcd数据状态
- Proxy: etcd的一种模式，可以为etcd提供反向代理服务
- Leader: Raft算法中通过竞选而产生的处理所有数据提交的节点
- Follower: Raft算法中竞选失败的节点，作为从属节点，为算法提供强一致性保证
- Candidate: Follower超过一定时间接收不到Leader节点的心跳的时候，会转变为Candidate(候选者)开始Leader竞选
- Term: 某个节点称为Leader到下一次竞选开始的时间周期,称为Term(任界，任期)
- Index: 数据项编号, Raft中通过Term和Index来定位数据
3、k8s中的etcd
(1)etcd在k8s中的作用：etcd在kubernetes集群是用来存放数据并通知变动的
(2)为什么k8s选择etcd：
- etcd有一个特别好用的特性，可以调用它的api监听其中的数据，一旦数据发生变化了，就会收到通知。有了这个特性之后，kubernetes中的每个组件只需要监听etcd中数据，就可以知道自己应该做什么
- kubernetes没有选用mq而是选用etcd呢？mq和etcd是本质上完全不同的系统，mq的作用消息传递，不储存数据****（消息积压不算储存，因为没有查询的功能），etcd是个分布式存储（它的设计目标是分布式锁，顺带有了存储功能），是一个带有订阅功能的key-value存储****。如果使用mq，那么还需要引入数据库，在数据库中存放状态数据
- 选择etcd还有一个好处，etcd使用raft协议实现一致性，它是一个分布式锁，可以用来做选举。如果在kubernetes中部署了多个kube-schdeuler，那么同一时刻只能有一个kube-scheduler在工作，否则各自安排各自的工作，就乱套了。怎样保证只有一个kube-schduler在工作呢？那就是前文说到的通过etcd选举出一个leader
k8s 持久化存储方案
- pv(PersistentVolume静态PV)只能是网络存储
image.png
- pvc(PersistentVolumeClainm动态PV)
image.png
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 即可：
kind: PersistentVolumeClaim
apiVersion : vl
metadata:
name: myclaim
spec:
accessModes :
- ReadWriteOnce
resources :
requests:
storage: 8Gi
volumes:
- name: mypd
persistentvolumeClaim:
claimName : myclaim
