3. etcd 集群部署模式：单节点、多节点、跨AZ部署、TLS安全配置

etcd 作为 Kubernetes 控制平面的核心数据存储，其部署模式直接决定了集群的容灾能力、可用性与安全性。在生产环境中，etcd 的部署架构需要根据业务对 RPO（恢复点目标）和 RTO（恢复时间目标）的要求进行选择。本章将系统梳理四种典型的部署模式，并重点分析跨可用区（AZ）部署与 TLS 安全配置的最佳实践。

3.1 部署模式对比总览

下表从节点数量、容灾能力、适用场景三个维度对四种部署模式进行横向对比：

部署模式 节点数量 容灾能力 典型适用场景
单节点 1 无（单点故障） 开发/测试环境、本地学习
多节点（同AZ） 3 / 5（奇数） 容忍 N-1/2 节点故障 同机房生产集群、中小规模业务
跨AZ部署 3 / 5（跨AZ分布） 容忍 AZ 级故障 高可用生产集群、金融/核心业务
TLS安全配置 任意（叠加模式） 防止中间人攻击与未授权访问 所有生产环境、合规要求场景
关键原则：etcd 集群必须使用奇数节点（3、5、7），以保证 Raft 共识算法能够选出 Leader。偶数节点不仅浪费资源，还会降低故障容忍度。

3.2 单节点部署

单节点 etcd 是最简单的部署形式，通常用于本地开发、功能验证或 CI/CD 流水线。该模式下不存在 Leader 选举与数据复制，所有写入直接落盘。

  • 优点：部署简单、资源占用低、启动速度快。
  • 缺点：无任何容灾能力，节点宕机即导致控制平面不可用。
  • 恢复方式：只能依赖定期备份进行全量恢复，无法实现零 RPO。
# 单节点启动示例（非生产）
etcd --name etcd-single \
  --data-dir /var/lib/etcd \
  --listen-client-urls http://0.0.0.0:2379 \
  --advertise-client-urls http://192.168.1.10:2379

3.3 多节点（同AZ）部署

多节点部署是生产环境的最低要求。3 节点集群可容忍 1 个节点故障，5 节点集群可容忍 2 个节点故障。所有节点部署在同一个可用区（AZ）内，网络延迟低，Raft 性能最优。

性能提示：同AZ部署时，建议将 etcd 节点部署在独立的物理机或专用实例上，避免与业务容器争抢磁盘 IO 和网络带宽。etcd 对磁盘写入延迟极为敏感，推荐使用 NVMe SSD。 
# 3节点集群初始配置（member 1）
etcd --name etcd-1 \
  --initial-advertise-peer-urls http://192.168.1.11:2380 \
  --listen-peer-urls http://0.0.0.0:2380 \
  --listen-client-urls http://0.0.0.0:2379 \
  --advertise-client-urls http://192.168.1.11:2379 \
  --initial-cluster- etcd-cluster-1 \
  --initial-cluster etcd-1=http://192.168.1.11:2380,etcd-2=http://192.168.1.12:2380,etcd-3=http://192.168.1.13:2380 \
  --initial-cluster-state new

3.4 跨AZ部署

跨可用区部署是生产高可用的标准形态。etcd 节点分散在 3 个不同的 AZ 中，即使整个 AZ 断电或网络中断，集群仍能通过剩余节点继续提供服务。

下图展示了跨 3 个 AZ 部署的 etcd 集群架构：

跨AZ etcd 集群部署架构 可用区 AZ-1 etcd-1 Leader / Follower etcd-4（可选） Follower 可用区 AZ-2 etcd-2 Follower etcd-5（可选） Follower 可用区 AZ-3 etcd-3 Follower Raft 共识：跨 AZ 复制日志，容忍 1 个 AZ 完全故障 推荐 3 节点（每 AZ 1 节点）或 5 节点（2+2+1 分布）
跨AZ部署注意事项：
  • AZ 间网络延迟应控制在 10ms 以内，否则 Raft 心跳超时可能导致频繁 Leader 选举。
  • 建议将 etcd 节点部署在独立的子网和安全组中，仅开放 2379（客户端）和 2380（对等）端口。
  • 跨 AZ 带宽成本较高，需提前评估流量预算。

3.5 TLS 安全配置

生产环境必须启用 TLS 加密，以防止中间人攻击、数据泄露和未授权节点加入集群。etcd 支持双向 TLS（mTLS）认证，即客户端和服务端都需要出示有效证书。

下图展示了 TLS 加密下的 etcd 通信模型：

etcd TLS 双向认证通信模型 K8s API Server （客户端证书） etcd 集群（服务端） etcd-1 (server.crt) etcd-2 (server.crt) etcd-3 (server.crt) mTLS 加密通道 TLS 证书体系 CA 根证书 → 服务端证书（server.crt + server.key） CA 根证书 → 客户端证书（client.crt + client.key）

3.5.1 关键证书文件

证书文件 用途 分发范围
ca.crt CA 根证书，用于验证所有证书的签发者 所有 etcd 节点 + 所有客户端
server.crt + server.key etcd 服务端证书，用于对客户端证明身份 每个 etcd 节点
client.crt + client.key 客户端证书，用于向 etcd 证明身份 API Server、etcdctl、备份工具
peer.crt + peer.key 节点间对等通信证书（可选，推荐启用） 每个 etcd 节点

3.5.2 启动参数示例（启用 TLS）

# etcd 节点启动参数（启用客户端与对等 TLS）
etcd --name etcd-1 \
  --data-dir /var/lib/etcd \
  --cert-file /etc/etcd/pki/server.crt \
  --key-file /etc/etcd/pki/server.key \
  --client-cert-auth \
  --trusted-ca-file /etc/etcd/pki/ca.crt \
  --peer-cert-file /etc/etcd/pki/peer.crt \
  --peer-key-file /etc/etcd/pki/peer.key \
  --peer-client-cert-auth \
  --peer-trusted-ca-file /etc/etcd/pki/ca.crt \
  --initial-cluster etcd-1=https://192.168.1.11:2380,etcd-2=https://192.168.1.12:2380,etcd-3=https://192.168.1.13:2380 \
  --initial-cluster-state new \
  --initial-cluster- etcd-cluster-tls
最佳实践：
  • 证书有效期建议设置为 1-2 年，并建立自动续期机制（如 cert-manager）。
  • 生产环境务必启用 --client-cert-auth 和 --peer-client-cert-auth，仅允许持有合法证书的客户端和节点接入。
  • etcd 的 --listen-* 地址应使用 https:// 协议，而非 http://。

3.6 部署模式选择决策树

在实际项目中，可根据以下条件快速确定 etcd 部署模式：

  1. 是否为生产环境？ 否 → 单节点；是 → 进入下一步。
  2. 是否要求跨 AZ 容灾？ 否 → 同 AZ 多节点（3 节点起步）；是 → 进入下一步。
  3. AZ 数量是否 ≥ 3？ 否 → 考虑同 AZ 多节点 + 异地备份；是 → 跨 AZ 3 节点部署。
  4. 是否启用 TLS？ 所有生产环境必须启用，无例外。
← 上一章 📖 返回目录 下一章 →