2. etcd 集群部署策略：节点规划、网络拓扑、TLS 配置、集群初始化与成员管理

etcd 作为 Kubernetes 控制面的核心数据存储，其部署策略直接决定集群的可用性、一致性与安全性。本节从节点规划、网络拓扑、TLS 配置、集群初始化与成员管理四个维度，给出生产级部署的标准化方案与避坑指南。

2.1 节点规划：奇数节点与故障域隔离

集群规模 节点数 最大容忍故障 适用场景
最小生产 3 1 开发/测试、边缘集群
标准生产 5 2 中小规模生产集群
大规模生产 7 3 超大规模、跨可用区部署
核心原则：始终使用奇数节点，避免脑裂场景下出现平票（split-brain tie）。5 节点集群比 3 节点集群多容忍 1 个故障，但写入延迟增加约 10-15%，需根据业务 SLA 权衡。

故障域隔离策略：

  • 物理机/VM 级别：每个 etcd 实例部署在不同宿主机，避免单机故障导致多数节点丢失。
  • 机架/交换机级别：跨机架部署，防止 ToR 交换机故障导致集群失联。
  • 可用区（AZ）级别：跨 AZ 部署时，确保每个 AZ 内节点数 ≤ 总节点数的一半（如 5 节点：2-2-1 分布），避免单个 AZ 故障导致仲裁丢失。

2.2 网络拓扑与延迟约束

etcd 对网络延迟高度敏感，Raft 心跳与日志复制依赖稳定低延迟的 TCP 连接。

网络指标 推荐值 警告阈值 影响
节点间 RTT < 10ms > 50ms 心跳超时、Leader 频繁选举
带宽 > 1 Gbps < 100 Mbps 快照传输阻塞、写入延迟飙升
丢包率 < 0.01% > 0.1% Raft 日志重试、吞吐量下降
重要：etcd 集群节点之间应使用独立的高带宽低延迟网络（如 Kubernetes 的 Node Network，而非 Pod Network），避免与业务流量争抢带宽。跨 AZ 部署时，务必实测 AZ 间 RTT，若超过 20ms 建议使用 5 节点并调大 --heartbeat-interval（默认 100ms）至 200-300ms。
etcd 集群网络拓扑（跨可用区 5 节点） 可用区 A etcd-0 (Leader) etcd-1 (Follower) 备用节点（可选） 可用区 B etcd-2 (Follower) etcd-3 (Follower) 可用区 C etcd-4 (Follower) 说明：Leader 与 Follower 之间通过 Raft 协议同步日志；跨 AZ 延迟需 < 20ms，每个 AZ 内节点数 ≤ 总节点数的一半

2.3 TLS 配置：双向认证与证书体系

生产环境必须启用 etcd 的 TLS 双向认证（mTLS），防止中间人攻击与未授权访问。

证书体系结构：

  • CA 证书（ca.crt）：自建内部 CA，用于签发所有组件证书，有效期建议 5-10 年。
  • 服务端证书（server.crt / server.key）：用于 etcd 节点间通信，CN 必须包含节点 IP 或 DNS 名称。
  • 客户端证书（client.crt / client.key）：用于 etcdctl、Kubernetes API Server 等客户端访问。
  • 对等证书（peer.crt / peer.key）：用于 etcd 节点之间的 Raft 通信，CN 需匹配每个节点的 hostname。
证书类型 用途 CN 示例 有效期建议
CA 签发所有证书 etcd-ca 5-10 年
Server 客户端→etcd 加密 etcd-server 1-2 年
Peer etcd 节点间通信 etcd-0.example.com 1-2 年
Client API Server 访问 etcd kube-apiserver 1-2 年
最佳实践：使用 cfssl 或 openssl 生成证书时，务必在 server 证书的 SAN（Subject Alternative Name）中同时加入节点 IP、DNS 名称和 127.0.0.1，避免后续 IP 变更导致证书不可用。证书轮换前需确认所有客户端已加载新 CA 证书，否则会导致连接中断。

2.4 集群初始化：静态配置与发现机制

etcd 集群初始化支持两种方式：静态配置（适用于已知节点 IP 的固定集群）和 发现服务（适用于动态环境）。

静态配置示例（5 节点）：

# 节点 etcd-0 启动参数
etcd \
  --name etcd-0 \
  --initial-advertise-peer-urls https://10.0.1.10:2380 \
  --listen-peer-urls https://0.0.0.0:2380 \
  --advertise-client-urls https://10.0.1.10:2379 \
  --listen-client-urls https://0.0.0.0:2379 \
  --initial-cluster- etcd-cluster-1 \
  --initial-cluster etcd-0=https://10.0.1.10:2380,etcd-1=https://10.0.1.11:2380,etcd-2=https://10.0.1.12:2380,etcd-3=https://10.0.1.13:2380,etcd-4=https://10.0.1.14:2380 \
  --initial-cluster-state new \
  --peer-cert-file=/etc/etcd/pki/peer.crt \
  --peer-key-file=/etc/etcd/pki/peer.key \
  --peer-trusted-ca-file=/etc/etcd/pki/ca.crt \
  --peer-client-cert-auth=true \
  --cert-file=/etc/etcd/pki/server.crt \
  --key-file=/etc/etcd/pki/server.key \
  --trusted-ca-file=/etc/etcd/pki/ca.crt \
  --client-cert-auth=true
关键参数说明：
  • --initial-cluster-state new：首次初始化必须为 new，后续重启或扩容时改为 existing。
  • --initial-cluster-：同一集群所有节点必须一致，用于防止不同集群的节点误加入。
  • --peer-client-cert-auth=true：启用对等通信的 mTLS，生产环境必须开启。

2.5 成员管理：添加、移除与迁移

etcd 成员管理通过 etcdctl member 命令操作，所有变更必须遵循 Raft 一致性协议。

成员管理操作清单：

操作 命令示例 注意事项
列出成员 etcdctl member list --write-out=table 确认所有节点状态为 started
添加成员 etcdctl member add etcd-5 --peer-urls=https://10.0.1.15:2380 添加后需在新节点上以 --initial-cluster-state existing 启动
移除成员 etcdctl member remove <member-id> 先停止目标节点 etcd 进程，再执行移除；移除后需清理数据目录
更新成员 etcdctl member update <member-id> --peer-urls=https://10.0.2.10:2380 用于节点 IP 变更场景，需确保新 URL 可达
高危操作：切勿同时移除多个成员导致集群失去仲裁。例如 5 节点集群最多同时容忍 2 个节点故障，若一次性移除 3 个节点，集群将无法选举 Leader，数据不可读写。正确的做法是：先添加新节点，待数据同步完成后，再逐个移除旧节点。
etcd 成员变更流程（安全替换节点） 1. 添加新节点 member add etcd-5 2. 新节点加入 数据全量同步 3. 确认同步完成 endpoint status 4. 停止旧节点 systemctl stop etcd 5. 移除旧成员 member remove 6. 清理数据目录 rm -rf /var/lib/etcd 关键：每次只操作一个节点，等待新节点数据追赶完成后再进行下一步，确保集群始终拥有仲裁

2.6 部署策略检查清单

生产上线前逐项确认：
  1. 节点数为奇数（3/5/7），且跨故障域分布。
  2. 节点间 RTT < 10ms，带宽 > 1 Gbps，丢包率 < 0.01%。
  3. 所有 etcd 节点已启用 mTLS，证书 SAN 包含 IP 和 DNS。
  4. --initial-cluster-state 首次为 new，后续扩容为 existing。
  5. 数据目录使用独立 SSD 或高性能云盘，IOPS > 1000。
  6. 已配置定期快照备份（默认每 30 分钟自动创建快照）。
  7. 成员变更操作已制定回滚方案，避免误操作导致集群不可用。
← 上一章 📖 返回目录 下一章 →