非云环境中Kubernetes的配置和运行：etcd-InfoQ

这是非云环境中Kubernetes的配置和运行系列的第六篇文章，本文将详细阐释etcd的技术细节，及其在Kubernetes集群中的作用。

etcd 是一种为集群内各机器提供可靠数据存储的分布式键值存储。etcd 开源提供在 GitHub 上，它很好地解决了网络分区期间领导者的选举问题，可容忍包括领导者节点在内的节点故障。

引用自： https://coreos.com/etcd/docs/latest/

etcd 以驻留内存进程形式运行在集群中的每台机器上，提供动态配置的记录，支持以简单方式在集群成员间共享多种配置数据。

etcd 以键值方式存储数据，它是分布式的，支持自动复制和领导者自动选举产生。对存储数据的所有更改，会自动反映到整个集群。

etcd 还提供发现服务，支持“已部署的”应用向集群所有成员广播其所提供的服务。

etcd 使用基于 HTTP 的 JSON 方式通过 API 调用实现通信。API 可直接通过 curl 或 wget 等方式使用，也可以通过 etcdctl 间接使用。

参考资料： https://etcd.io/

容错能力

推荐奇数个集群成员，即维持奇数规模的集群成员。无需更改获得多数所需的成员，但额外添加成员可增加对失败的容忍。对于集群成员应选奇数还是偶数时，实践出真知。

参考资料： https://coreos.com/etcd/docs/latest/v2/admin_guide.html

复制能力

在计算机科学中，状态机复制（也称为“状态机方法”）是一种通过服务器复制并协调客户与服务器间的副本交互实现容错服务的通用方法。该方法还为副本管理协议的理解和设计提供了框架。

参考文献： https://en.wikipedia.org/wiki/State_machine_replication

活动副本

所有节点实现为一种有限状态机。
节点在各自Quorum投票操作顺序上达成一致，并在本地执行。

非活动副本

指定一个节点为领导者（如下图动画所示），接收所有写入命令。
领导者节点对大多数副本有效执行Quorum投票操作。
领导者节点负责将复制状态分发给其它副本。

Raft 共识

Raft共识算法在设计上易于理解，它具有和Paxos一样的容错和性能。不同之处在于，Raft将问题分解为相对独立的子问题，并很好地解决了系统运行实际所需的关键问题。我们希望Raft共识能得到更广泛的采用，进而开发出更多基于共识的高质量系统，满足当前的需求。

参考链接： https://raft.github.io/

什么是分布式共识算法？

支持一组进程就某个值达成一致的算法；
支持对分布式进程的协调；
随着复制状态机一并提出。
共识算法在构建大规模可靠分布式系统中具有重要作用。

一个用于概念理解的小比喻

从前有个王国，称为“集群之地”（Cluster Land）。王国由一位非常民主的国王统治，他受由九位非常智慧、忠诚的智者团的支持。
一旦有王国的臣民向国王提出请求，国王都会先与他的智者团商议，然后再决定是否批准该请求。如果多数智者都投了赞成票，那么该请求将获得批准。否则，将被拒绝。

上面简单比喻了 Raft 算法将事务提交到日志的做法。所有请求均由领导者（即国王）处理，并且仅在得到多数智者（集群中的其他节点）赞成后才能提交。

一天，国王在与一条可怕的龙作战时殉国。智者团决定无需等待任何哀悼期，应立刻选举他们中的一位作为新的国王统治者。九位智者中，有两位（暂称为其为五号和七号）申请成为新国王。在经过快速选举后，有四位智者投票赞成五号，而三位投票赞成七号。这样，五号就成为了新的国王，开始继续执行与上任国王相同的政策。

这大致说明了 Raft 算法中时如何进行领导者选举的。

一段时间后，由于对新统治者治理王国的方式产生了不满，一些智者发动了叛乱，最终原王国一分为二。由五号统治的“集群北地”，和由七号统治的“集群南地”，每个王国具有自己的国王和智者。原臣民生活在其中一个王国，并向各自的国王提出请求。分裂的王国依然延用相同的统治方法，即请求直接提交国王，并由各自智囊团进行磋商达成决议。
多年后，两位国王达成协议，王国得到统一。“集群之地”再次成为一个王国，由五号重新统治。不幸的是，在分裂期间，每个王国都制定了一些相互抵触的法律。为解决这个问题，智囊们同意通过遵循最新颁布的相应法律，解决所有的法律冲突。

这部分故事比喻了发生网络分区的情况。这时集群被拆分，每个新集群都有其自己的领导者和节点。冲突的请求可由各个的集群在不同的时间处理。当集群再次合并时，需要给出解决冲突值的方法。在 Raft 中，引入了 Term 概念解决分区一致性问题。