etcd 是 Kubernetes 集群中最关键的一部分。这一点从 etcd 在整个集群中引发的、以不同方式表现出来的大量问题可以看出来。经过非常仔细的研究，我们才找到根本原因，并扩展 etcd 以匹配我们预期的规模。

在扩展过程中，许多 Raft proposal 开始失败。

通过调查分析，我们发现，GCP 将 PD-SSD 磁盘的吞吐量限制在每秒 100MB 左右（如下图所示），我们的磁盘大小为 100G。GCP 没有提供增加吞吐量限制的方法——它只 随着磁盘的大小增加。尽管 etcd 节点只需要不到 10G 的空间，我们首先尝试了 1TB PD-SSD。然而，当所有 4k 个节点同时加入 Kubernetes 控制平面时，磁盘再大也会成为一个 瓶颈。我们决定使用本地 SSD，它的吞吐量非常高，代价是在出现故障时丢失数据的几率略高，因为它 不是持久化的。

在迁移到本地 SSD 后，我们并没有看到最快的 SSD 带来了预期的性能。我们用 FIO 直接在磁盘上做了一些基准测试，数值在意料之中。但是，对于所有成员的写入并发，etcd 基准测试讲述了一个不同的故事：本地 SSD 的表现更差！

经过深入调查，这是由 ext4 文件系统的写屏障缓存提交导致的。由于 etcd 使用写前日志，并在每次提交到 Raft 日志时调用 fsync，所以可以禁用写屏障。此外，我们在文件系统级和应用程序级有 DB 备份作业，用于 DR。在这样修改之后，使用本地 SSD 的数值提高到了与 PD-SSD 相当的程度。

这一改进的效果在 etcd 的 WAL 同步持续时间和后端提交延迟上体现了出来。

etcd 中默认的 MVCC 数据库大小为 2GB。在 DB 空间不足的告警被触发时，这个大小最大会增加到 8GB。由于该数据库的 利用率约为 60%，所以我们能够扩展到 20 万个无状态 Pod。

经过上述这些优化，在预期的规模下，集群更加稳定了，然而，在 API 延迟方面，我们的 SLI 还差很多。

etcd 服务器还会偶尔重启，仅一次重启就会破坏基准测试结果，尤其是 P99 值。仔细观察发现，v1.20 版的 etcd YAML 中有一个存活探针 Bug。为了解决这个问题，我们采用了一个变通办法，即增加失败阈值的计数。

在用尽所有方法对 etcd 进行了垂直扩展之后，主要是在资源方面（CPU、内存、磁盘），我们发现，etcd 的性能受到范围查询的影响。当范围查询很多时，etcd 的表现并不好，对 Raft 日志的写入也受到影响，增加了集群的延迟。

由于这些查询很耗时，etcd 的后端延迟受到了很大的影响。在事件资源上对 etcd 服务器进行分片管理后，我们看到，在 Pod 高度竞争的情况下，集群的稳定性有所提高。将来，还可以进一步在 Pod 资源上对 etcd 集群进行分片。配置 API 服务器联系相关的 etcd 以与分片的资源进行交互很容易。

rafthttp: request cluster ID mismatch (got m want n)

rafthttp: request cluster ID mismatch (got a want b) after usage of ETCD_FORCE_NEW_CLUSTER #8169

在集群的「Master II」节点彻底损坏之后，重新初始化，但是etcd服务无法启动，产生如下错误：

rafthttp: request cluster ID mismatch (got 32f4d58037328e28 want 77563532327fd30f)

问题原因

问题原因可能有很多。我的原因是启动etcd参数不对。

解决办法

首先确保etcd容器已经停止。

然后将/var/lib/etcd目录备份，然后新建。（目的是清空目录）

再修改/etc/kubernetes/manifests/etcd.yaml配置文件，将--initial-cluster-state=new修改为--initial-cluster-state=existing即可。

最后，重启kubelet服务。