为什么Kubernetes使用Etcd

2013 年，有一个叫 CoreOS 的创业团队，他们构建了一个产品，Container Linux，它是一个开源、轻量级的操作系统，侧重自动化、快速部署应用服务，并要求应用程序都在容器中运行，同时提供集群化的管理方案，用户管理服务就像单机一样方便。
他们希望在重启任意一节点的时候，用户的服务不会因此而宕机，导致无法提供服务，因此需要运行多个副本。但是多个副本之间如何协调，如何避免变更的时候所有副本不可用呢？
需要一个协调服务来存储服务配置信息、提供分布式锁等能力。怎么办呢？当然是分析业务场景、痛点、核心目标，然后是基于目标进行方案选型，评估是选择社区开源方案还是自己造轮子。这其实就是我们遇到棘手问题时的通用解决思路，CoreOS 团队同样如此。

  1. 可用性角度：高可用。协调服务作为集群的控制面存储，它保存了各个服务的部署、运行信息。若它故障，可能会导致集群无法变更、服务副本数无法协调。业务服务若此时出现故障，无法创建新的副本，可能会影响用户数据面。
  2. 数据一致性角度：提供读取“最新”数据的机制。既然协调服务必须具备高可用的目标，就必然不能存在单点故障（single point of failure），而多节点又引入了新的问题，即多个节点之间的数据一致性如何保障？比如一个集群 3 个节点 A、B、C，从节点 A、B 获取服务镜像版本是新的，但节点 C 因为磁盘 I/O 异常导致数据更新缓慢，若控制端通过 C 节点获取数据，那么可能会导致读取到过期数据，服务镜像无法及时更新。
  3. 容量角度：低容量、仅存储关键元数据配置。协调服务保存的仅仅是服务、节点的配置信息（属于控制面配置），而不是与用户相关的数据。所以存储上不需要考虑数据分片，无需过度设计。
  4. 功能：增删改查，监听数据变化的机制。协调服务保存了服务的状态信息，若服务有变更或异常，相比控制端定时去轮询检查一个个服务状态，若能快速推送变更事件给控制端，则可提升服务可用性、减少协调服务不必要的性能开销。
  5. 运维复杂度：可维护性。在分布式系统中往往会遇到硬件 Bug、软件 Bug、人为操作错误导致节点宕机，以及新增、替换节点等运维场景，都需要对协调服务成员进行变更。若能提供 API 实现平滑地变更成员节点信息，就可以大大降低运维复杂度，减少运维成本，同时可避免因人工变更不规范可能导致的服务异常。

不选择zookeeper的原因:
从高可用性、数据一致性、功能这三个角度来说，ZooKeeper 是满足 CoreOS 诉求的。然而当时的 ZooKeeper 不支持通过 API 安全地变更成员，需要人工修改一个个节点的配置，并重启进程。
若变更姿势不正确，则有可能出现脑裂等严重故障。适配云环境、可平滑调整集群规模、在线变更运行时配置是 CoreOS 的期望目标，而 ZooKeeper 在这块的可维护成本相对较高。
其次 ZooKeeper 是用 Java 编写的，部署较繁琐，占用较多的内存资源，同时 ZooKeeper RPC 的序列化机制用的是 Jute，自己实现的 RPC API。无法使用 curl 之类的常用工具与之互动，CoreOS 期望使用比较简单的 HTTP + JSON。

etcd基于Go语言实现。
目标是构建一个高可用的分布式键值(key-value)数据库。etcd内部采用raft协议作为一致性算法

etcd作为服务发现系统，有以下的特点：

  • 简单：安装配置简单，而且提供了HTTP API进行交互，使用也很简单
  • 安全：支持SSL证书验证
  • 快速：根据官方提供的benchmark数据，单实例支持每秒2k+读操作
  • 可靠：采用raft算法，实现分布式系统数据的可用性和一致性

etcd项目地址：https://github.com/coreos/etcd/

性能:
按照官网给出的数据， 在 2CPU，1.8G 内存，SSD 磁盘这样的配置下，单节点的写性能可以达到 16K QPS, 而先写后读也能达到12K QPS。这个性能还是相当可观。

Raft 协议

etcd集群使用raft一致性算法处理日志复制，保证多节点数据的强一致性。
todo:

  • 选举
  • 日志复制机制
  • 异常处理(脑裂)

  • [ ] 与 zookeeper 差别

    应用场景

    1. 服务注册发现

    (k8s)

    2. 配置共享

    分布式, 强一致
    image.png

    3. 分布式锁

    image.png

  • 选主

  • 应用调度

    4. 分布式队列

    比较Zookeeper/consul

    Etcd 和 Zookeeper 提供的能力非常相似，都是通用的一致性元信息存储，都提供watch机制用于变更通知和分发，也都被分布式系统用来作为共享信息存储
  1. zookeeper 部署非常复杂(jvm), Paxos 强一致性算法难理解
  2. 需要安装客户端, 官方只提供了 java 和 c 的接口, 由 java 编写,依赖多 , 是重型应用

  3. 发展缓慢

  4. etcd 部署简单, 二进制文件, etcd 提供 HTTP+JSON, gRPC 接口

  5. 默认数据一更新就做持久化
  6. 支持 SSL客户端安全认证,

Consul 则以服务发现和配置变更为主要目标，同时附带了kv存储。

架构图

image.png

  • http：负责对外提供http访问接口和http client
  • raft 状态机[核心]：根据接受的raft消息进行状态转移，调用各状态下的动作。
  • wal预写式日志 日志存储：持久化存储日志条目。
  • kv数据存储：kv数据的存储引擎，v3支持不同的后端存储，当前采用boltdb。通过boltdb支持事务操作。

Etcd 集群

天生为集群化设计,推荐是单数个节点,3, 5, 7,

基本操作

put key value
get key

del key
watch key

引用文章 作者：Austin_Brant 链接：https://www.jianshu.com/p/f68028682192