Kubernetes 平面组件 etcd

etcd

---

etcd 是高可用的键值对的分布式安全存储系统，用于持久化存储集群中所有的资源对象，例如集群中的Node、Service、Pod 的状态和元数据，以及配置数据等。为了持久性和高可用性，生产环境中的etcd 集群成员需分别在多个节点上运行，并定期对其进行备份。

如图 1-10 所示，在多个 etcd 成员组成的 etcd 集群中， etcd 成员间使用 Raft 共识算法复制请

求并达成协议。

对于 etcd ，这里有几个概念：领导者、选举和任期。任何 etcd 集群成员都可以处理读请求，不需要共识。但只有领导者才能处理写请求，包括更改、新增、删除等。

如图1-10所示，当来自客户端API Server 的写请求被提交到 etcd 成员处时，如果它不是领导者，那么它会将此请求转移给领导者。领导者会将请求复制到集群的其他成员中进行仲裁，当超 过半数成员同意更改时，领导者才将更改后的新值提交到日志 wal 中，并通知集群成员进 行相应的写操作，将日志中的新值写入磁盘中。

每个集群在任何给定时间都只能有一个领导者。如果领导者不再响应，那么其余成员在预定的选举计时器超时后会开始新的选举，将自己标记为候选者，并请求其他节点投票来开始新的选举。每个节点为请求其投票的第一个候选者投票。

如果候选人从集群中的大多数节点获得投票，那么它将成为新的领导者。每个节点维护的选举计时器的超时时间不同，因此第一个候选人通常会成为新的领导者。

但是，如果存在多个候选人并获得相同数目的选票，则现有的选举任期将在没有领导人的情况下结束 ，而新任期将以新的随机选举计时器开始。因此，我们建议在部署etcd 集群时采用奇数个

成员为佳。

根据 Raft 的工作机制，每个写请求需要集群中的每个成员做仲裁，因此我们建议etcd 集群成员数量不要超过 7 个，推荐是 5 个，个数越多仲裁时间会越多，写的吞吐量会越低。

如果集群中的某个成员处理请求特别慢，就会让整个etcd 集群不稳定，且性能受到限制。因此，我们要实时监测每个etcd 成员的性能，及时修复或者移除性能差的成员。

etcd 高可用保证

---

可以说etcd 是Kubernetes 控制平面组件中唯一的有状态应用。它是Kubernetes 的唯一数据库，存储了所有资源对象的配置数据、状态和元数据。因此etcd 是否高可用直接影响到整个集群的高可用性。

etcd 本身是分布式键值存储数据库。etcd 集群可以有多个成员，成员间采用raft 一致性协议来保证自身数据的一致性和可用性。多个成员可在不同服务器上同时运行，各自都维护了集群上的所有数据。不同于传统的以表格形式存储数据的数据库，etcd 为每个记录创建一个数据页面，在更新一个记录时不会妨碍其他记录的读取和更新。如图3-5 所示。

etcd 中有3 个数据，即3 个键值对，其键分别是 “/foo”“/bar/this”“/bar/that”，对应的值分别是数组[“i”,“am”,” array”]、整数42 和字符串 “i am a string”。客户端可利用restful API（通过数据的地址链接）对这些数据进行同步更新，而不会相互影响。这使etcd 非常容易应对高并发写请求的应用场景。

etcd 高可用拓扑

---

针对etcd 集群部署，社区推荐了两种可选的拓扑方案：堆叠式etcd 集群的高可用拓扑 （Stacked etcd Topology）和外部etcd 集群的高可用拓扑（External etcd Topology）。在构建etcd 集群时，应充分考虑每个拓扑的优缺点。

堆叠式etcd 集群的高可用拓扑

---

如图3-6 所示，堆叠式是指etcd 堆叠在运行控制平面组件的管理节点（也就是常说的Master 节点）之上。每个Master 节点上都运行了etcd、API Server、Controller Manager 和Scheduler 的实例。所有Master 节点上的etcd 实例组成etcd 集群，但API Server 仅与此节点本地的etcd 成员通信。

这种拓扑将相同节点上的控制平面和etcd 成员耦合在一起。优点在于建立起来非常容易，并且对副本的管理也更容易。但是，堆叠式存在耦合失败的风险。如果一个节点发生故障，则etcd 成员和控制平面实例都会丢失，并且集群冗余也会受到损害。可以通过添加更多控制平面节点来减轻这种风险。因此，为实现集群高可用应该至少运行三个堆叠的Master 节点。

外部etcd 集群的高可用拓扑

---

如图3-7 所示，外部etcd 集群的高可用拓扑是指etcd 集群位于运行控制平面组件的Master 节点之外。Master 节点上仅运行了API Server、Controller Manager 和Scheduler 的实例，etcd 成员则在其他单独主机上运行，组成存储集群。API Server 可与etcd 集群中任意一个etcd 成员进行通信。

这里 API Server 有两种 etcd 地址的配置方式：

第一种是配置 etcd 集群的负载均衡器的VIP 地址，具体连接到哪个 etcd 实例由负载均衡策略决定。

第二种是配置多个 etcd 实例的 地址，用逗号隔开，API Server 会按顺序依次尝试连接。

如果采用第二种方式，那么为了均衡etcd 集群的流量，每个 API Server 处 etcd 实例地址的顺序配置应略有不同。

该拓扑将控制平面和etcd 成员解耦。丢失一个Master 节点对etcd 成员的影响较小，不会像堆叠式拓扑那样对集群冗余产生太大影响。但是，此拓扑所需的主机数量是堆叠式拓扑的两倍。具有此拓扑的集群至少需要三个主机用于控制平面节点，三个主机用于etcd集群。

为什么不管哪种拓扑结构都至少需要 3 个 etcd 实例呢？原因有两个。

第一，如果 etcd 集群仅有一个成员，那么一旦这个成员出现故障，会导致整个 Kubernetes 集群不可用。

第二，基于 raft 协议的 etcd 的 Leader 选举和数据写入都需要半数以上的成员投票通过确认，因此，集群最好由奇数个成员组成，以确保集群内部一定能够产生多数投票通过的场景。这也就是为什么etcd 集群至少需要 3 个以上的成员。

建议 etcd 集群成员数量不要超过7 个，推荐是 3 个或 5 个。个数越多，投票所需时间就越多，写的吞吐量会越低。虽然提高了读的性能和可用性，但是极大损伤了写的性能。具体应该是3 个还是

5 个呢？

etcd 集群是有一定的容灾能力的，并且能够自动从临时故障中恢复（例如节点重启）。对于一个N 节点的集群，允许最多出现在 (N-1)/2 个节点发生永久性故障（比如硬件故障或磁盘损耗）之后还能正常对外服务。当永久性故障的节点个数超过 (N-1)/2 时，就会陷入不可逆的失去仲裁的境地。一旦仲裁丢失，集群就无法保证一致性，因此集群就会置为只读模式，无法再接收更新请求了。

3 个成员的 etcd 集群是高可用的最低需求。 etcd 实例的数目越少，其维护成本越低，并且只需2 个成员投票即可将数据写入，因此具有较高的效率。

仅允许 1 个成员发生故障。发生故障后，需要运维人员立即介入。如若另一个成员再发生故障，集群将会变成只读的。只读的集群表象是平台变为静止。但因为集群中所有节点的kubelet 都无法不汇报状 态，所以 Controller Manager 中的 Pod 驱逐控制器会将所有节点上的 Pod 放入驱逐队列，一旦etcd 恢复，会导致大量 Pod 被同时驱逐，从而造成服务器过载、服务不可用等事故。

5 个成员的 etcd 集群是一种常见的配置，此配置具有更高的可用性。只有当超过两个成员出现故障时，集群才变成只读的。因此，当第一个成员出现故障时，管理员无须立即介入。对运维响应速度的要求降低了，这是以管理复杂度换取运维响应时间的常规手段。