4. etcd 集群部署模式对比
在 Kubernetes 集群生命周期中，etcd 的部署模式直接影响集群的可用性、运维复杂度与故障恢复策略。根据生产环境规模与可靠性要求，etcd 通常采用以下三种部署模式：单节点 etcd、多节点高可用 etcd 集群、外部 etcd 与自托管 etcd。本章从架构、可用性、运维、备份恢复等维度进行系统对比。
4.1 单节点 etcd
单节点 etcd 是最简单的部署形式，通常用于开发、测试或非关键业务场景。所有 etcd 数据仅存储在一个实例上，不提供冗余能力。
适用场景： 本地开发环境、CI/CD 测试集群、边缘小规模集群（节点数 < 10）。
| 维度 | 说明 |
|---|---|
| 可用性 | 无高可用，节点故障即服务中断 |
| 数据一致性 | 单点写入，无 Raft 共识开销 |
| 备份策略 | 直接备份数据目录或使用 etcdctl snapshot save |
| 恢复方式 | 停止 etcd → 替换数据目录 → 启动 |
| 运维复杂度 | 极低，适合快速验证 |
4.2 多节点高可用 etcd 集群
生产环境推荐部署 3 或 5 节点 的 etcd 集群，利用 Raft 共识算法保证强一致性与高可用。多数节点（Quorum）存活即可正常服务。
推荐节点数： 3 节点（容忍 1 节点故障）或 5 节点（容忍 2 节点故障）。不建议使用偶数节点，因为 Raft 要求多数派，偶数节点会降低故障容错比。
| 维度 | 说明 |
|---|---|
| 可用性 | 高可用，容忍少数节点故障 |
| 数据一致性 | Raft 强一致性，写入需多数节点确认 |
| 备份策略 | 在任意健康节点执行快照，建议定期 + 增量 |
| 恢复方式 | 单节点恢复或全集群重建，需更新成员列表 |
| 运维复杂度 | 中等，需管理成员、监控 Leader 切换 |
4.3 外部 etcd 与自托管 etcd
根据 etcd 集群与 Kubernetes 控制面的部署关系，可分为 外部 etcd 和 自托管 etcd 两种模式。
4.3.1 外部 etcd
外部 etcd 指 etcd 集群独立部署在 Kubernetes 集群之外，由专门的运维团队或基础设施管理。K8s API Server 通过配置 --etcd-servers 指向外部 etcd 地址。
- 优点： etcd 与控制面解耦，升级 K8s 不影响 etcd；可独立扩缩容；适合大规模、多集群共享 etcd。
- 缺点： 网络延迟增加；需要额外维护 etcd 集群；备份恢复需单独规划。
4.3.2 自托管 etcd
自托管 etcd 指 etcd 以 Static Pod 或 DaemonSet 形式运行在 K8s 集群内部，与 API Server、Controller Manager 等控制面组件部署在同一组节点上。这是 kubeadm 默认部署方式。
- 优点： 部署简单，kubeadm 一键初始化；etcd 与控制面共享节点资源；网络通信延迟低。
- 缺点： 控制面节点故障可能同时影响 etcd；升级 K8s 时需同步升级 etcd；备份恢复需在容器内执行。
关键提醒： 自托管 etcd 的备份恢复操作必须在 etcd Pod 内或通过
kubectl exec 执行，且需注意 etcd 数据目录的持久化卷映射。外部 etcd 则直接操作宿主机上的 etcd 进程。
| 对比维度 | 外部 etcd | 自托管 etcd |
|---|---|---|
| 部署方式 | 独立部署，手动或工具管理 | kubeadm / Static Pod 自动部署 |
| 升级影响 | etcd 升级独立，不影响 K8s | etcd 升级通常随 K8s 版本绑定 |
| 网络延迟 | 跨节点/跨机房，延迟较高 | 同节点通信，延迟低 |
| 备份恢复 | 直接操作 etcd 进程 | 需进入容器或操作宿主机挂载点 |
| 运维复杂度 | 较高，需独立监控 | 较低，随集群统一管理 |
| 适用规模 | 大型生产集群、多集群共享 | 中小型集群、标准 kubeadm 部署 |
4.4 部署模式选择建议
生产环境推荐： 3 节点自托管 etcd（kubeadm 默认）适用于大多数场景；超大规模或严格隔离需求选择外部 etcd；单节点仅用于开发测试。
4.5 备份恢复要点对比
| 部署模式 | 备份命令示例 | 恢复关键步骤 |
|---|---|---|
| 单节点 etcd | etcdctl snapshot save /backup/snapshot.db |
停止 etcd → 替换数据目录 → 启动 |
| 自托管 3 节点 | kubectl exec -n kube-system etcd-pod -- etcdctl snapshot save /var/lib/etcd/snapshot.db |
停止所有 etcd Pod → 恢复数据 → 更新成员 → 启动 |
| 外部 etcd 集群 | ETCDCTL_ENDPOINTS=https://10.0.0.1:2379 etcdctl snapshot save /backup/snapshot.db |
在任意节点执行快照 → 恢复时需指定初始集群状态 |
最佳实践： 无论哪种部署模式，都应启用 etcd 的
--auto-compaction-retention 自动压缩历史版本，并定期执行 defrag 碎片整理，以控制数据目录大小，提升备份恢复效率。