你想了解的关于ETCD都在这了 - 屌丝逆袭记
内容提要
etcd是Kubernetes集群存储配置与状态的核心数据库，其高可用是集群高可用的前提。etcd基于Raft算法保证一致性，性能受网络和磁盘IO延迟影响，建议配置2-4核CPU、8GB内存及SSD磁盘。v3版本引入gRPC、租约、MVCC和BoltDB，支持历史版本查询与高效并发读写。运维操作包括集群备份、快照恢复、节点增删、证书续期及空间超限处理。
延伸解读
etcd 高可用部署的关键考量
文章指出 etcd 是 Kubernetes 集群的数据中心，其高可用是集群高可用的前提。常见部署方案有 Docker 部署和独立部署，官方更推荐独立部署。使用独立部署时，API Server 可通过负载均衡器或直接指定多个 etcd 地址（如 --etcd-servers=$IP1:2379,$IP2:2379）来连接。通常采用 3 个 etcd 节点组成集群，节点间会进行数据同步和探活，确保一致性。
影响 etcd 性能的物理约束
etcd 基于 Raft 算法保证一致性，其性能受限于网络 IO 延迟和磁盘 IO 延迟。完成一个请求的最小时间是成员间的网络往返时延加上数据持久化的 fdatasync 时间。为提高吞吐量，etcd 会将多个请求批量提交给 Raft。因此，低延迟网络和高速磁盘（如 SSD）对 etcd 至关重要，慢磁盘可能导致心跳超时，触发选举，破坏集群稳定性。
etcd v3 的核心优化与运维要点
etcd v3 引入 gRPC、租约、MVCC 和 BoltDB，解决了 v2 中客户端频繁通信、watch 不可靠、历史版本查询受限等问题。租约机制通过统一 TTL 管理键的过期，MVCC 支持多版本并发控制，提升读多写少场景的并发性能。运维方面，需定期备份快照，掌握恢复流程，并注意默认 2GB 存储限制，超限时需压缩历史版本并整理碎片。
Q&A
etcd在Kubernetes集群中扮演什么角色？为什么它如此重要？
etcd是Kubernetes集群的数据中心，用于存放集群的配置和状态信息。如果etcd数据丢失，集群将无法恢复，因此高可用集群部署首先要求etcd是高可用的。
etcd集群对服务器硬件有什么要求？
etcd通常需要2-4个CPU，8GB内存，以及SSD磁盘。高负载集群可能需要8-16个CPU和16-64GB内存。磁盘应能稳定达到50 IOPS，高负载推荐500 IOPS。网络方面，1Gb网络可满足常见场景，大型集群建议10Gb网络。
etcd v3相比v2有哪些重要改进？
etcd v3的主要改进包括：使用gRPC+protobuf替代HTTP+JSON，提升通信效率；引入租约机制替代TTL，简化键过期管理；支持MVCC，保存键的历史版本，实现无锁并发读写；使用BoltDB作为磁盘存储引擎，替代纯内存数据库；支持连接复用的watch，减少资源消耗。
etcd如何保证数据一致性？请简要描述Raft算法的工作流程。
etcd使用Raft一致性算法。集群中节点状态分为Leader、Follower和Candidate。正常时只有一个Leader，所有写请求由Leader处理。Leader将请求作为日志条目复制到Follower，当多数节点确认后，日志被提交并应用到状态机。如果Leader失效，Follower会超时并发起选举，获得多数投票的节点成为新Leader。
如何备份和恢复etcd数据？
备份：使用etcdctl snapshot save命令生成快照文件，例如：ETCDCTL_API=3 etcdctl snapshot save snapshotdb。恢复：先停止所有Master节点的kube-apiserver和etcd，然后使用etcdctl snapshot restore命令恢复快照，指定--name、--initial-cluster等参数，最后重启服务。
etcd数据库空间超出限制（如2GB）导致无法写入，该如何处理？
首先使用snapshot save备份数据。然后获取当前revision，执行compact压缩旧版本，再执行defrag整理碎片。最后执行alarm disarm解除警报。这些操作可以释放空间，恢复集群写入能力。
