2. etcd 选型与部署:etcd 架构与 Raft 协议、集群规划、TLS 配置与启动

2.1 etcd 架构与 Raft 协议核心

etcd 是 Kubernetes 控制平面的唯一持久化状态存储,所有集群对象(Pod、Service、ConfigMap 等)的创建、更新、删除均需通过 etcd 的写入确认。etcd 基于 Raft 共识算法 实现强一致性,其架构可抽象为三层:

  • Client 层:gRPC API 接口,支持 v3 版本的事务、Watch、Lease 等操作。
  • Raft 层:Leader 选举、日志复制、安全性保证,是 etcd 一致性的核心。
  • 存储层:基于 BoltDB(现为 bbolt)的持久化键值存储,支持 MVCC 和压缩。
关键认知:etcd 的写入延迟直接决定 Kubernetes API Server 的响应时间。Raft 要求多数节点(N/2+1)确认写入后才返回成功,因此网络延迟和磁盘 I/O 是性能瓶颈。
etcd 三层架构与 Raft 数据流 Client 层 — gRPC API (v3) KV / Watch / Lease / Txn / Cluster / Maintenance Raft 共识层 Leader 选举 | 日志复制 | 安全性 | 成员变更 Term / Entry / Snapshot / Cluster Membership 存储层 — bbolt (MVCC) 持久化键值存储 | 事务 | 压缩 | 快照 Raft 保证:只要多数节点存活,集群即可对外提供一致服务

2.2 etcd 集群规划:节点数与磁盘选型

etcd 集群的节点数直接影响可用性和性能。下表列出常见规模下的推荐配置:

集群规模 节点数 容忍故障数 推荐磁盘类型 典型场景
小 3 1 SSD (NVMe) 开发/测试、边缘集群
中 5 2 SSD (NVMe) 生产环境、<1000 节点
大 7 3 NVMe + 独立数据盘 大规模生产、>1000 节点
磁盘选型硬性要求:etcd 对磁盘延迟极其敏感。必须使用 SSD(推荐 NVMe),避免使用 HDD 或网络存储(NFS/iSCSI)。官方建议磁盘的 99% 写入延迟低于 10ms,否则可能导致 Leader 频繁切换。

2.3 etcd TLS 证书配置

生产环境必须启用 etcd 的 TLS 双向认证,防止未授权访问和数据泄露。证书体系包含三类:

  • CA 证书:自建或企业 CA,用于签发所有组件证书。
  • Server 证书:etcd 节点对外提供服务的身份凭证。
  • Client 证书:Kubernetes API Server 连接 etcd 时使用的客户端证书。

以下为使用 cfssl 工具生成证书的典型步骤:

# 1. 生成 CA 配置和证书
cfssl gencert -initca ca-csr.json | cfssljson -bare ca

# 2. 生成 etcd Server 证书(需包含所有节点 IP 和域名)
cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=server \
  server.json | cfssljson -bare etcd-server

# 3. 生成 Client 证书(供 API Server 使用)
cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=client \
  client.json | cfssljson -bare etcd-client
证书文件清单:每个 etcd 节点需要 ca.pem、etcd-server.pem、etcd-server-key.pem;API Server 需要 ca.pem、etcd-client.pem、etcd-client-key.pem。

2.4 etcd 启动配置与参数详解

etcd 启动时需指定集群成员、数据目录、TLS 证书路径等关键参数。以下为 3 节点集群的启动示例:

# 节点 1 (etcd-1, 10.0.0.1)
etcd \
  --name etcd-1 \
  --data-dir /var/lib/etcd \
  --initial-advertise-peer-urls https://10.0.0.1:2380 \
  --listen-peer-urls https://0.0.0.0:2380 \
  --advertise-client-urls https://10.0.0.1:2379 \
  --listen-client-urls https://0.0.0.0:2379 \
  --initial-cluster- etcd-cluster-1 \
  --initial-cluster etcd-1=https://10.0.0.1:2380,etcd-2=https://10.0.0.2:2380,etcd-3=https://10.0.0.3:2380 \
  --initial-cluster-state new \
  --client-cert-auth \
  --trusted-ca-file=/etc/etcd/ca.pem \
  --cert-file=/etc/etcd/etcd-server.pem \
  --key-file=/etc/etcd/etcd-server-key.pem \
  --peer-client-cert-auth \
  --peer-trusted-ca-file=/etc/etcd/ca.pem \
  --peer-cert-file=/etc/etcd/etcd-server.pem \
  --peer-key-file=/etc/etcd/etcd-server-key.pem

节点 2 和节点 3 只需替换 --name、--initial-advertise-peer-urls、--advertise-client-urls 中的 IP 地址,其余参数保持一致。

2.5 启动后验证与健康检查

集群启动后,使用 etcdctl 验证成员列表和健康状态:

# 查看成员列表
etcdctl --endpoints=https://10.0.0.1:2379,https://10.0.0.2:2379,https://10.0.0.3:2379 \
  --cacert=/etc/etcd/ca.pem \
  --cert=/etc/etcd/etcd-client.pem \
  --key=/etc/etcd/etcd-client-key.pem \
  member list

# 检查集群健康状态
etcdctl --endpoints=https://10.0.0.1:2379,https://10.0.0.2:2379,https://10.0.0.3:2379 \
  --cacert=/etc/etcd/ca.pem \
  --cert=/etc/etcd/etcd-client.pem \
  --key=/etc/etcd/etcd-client-key.pem \
  endpoint health --cluster
etcd 3 节点集群 TLS 通信示意 etcd-1 10.0.0.1:2379 10.0.0.1:2380 etcd-2 10.0.0.2:2379 10.0.0.2:2380 etcd-3 10.0.0.3:2379 10.0.0.3:2380 Kubernetes API Server 所有通信均使用 TLS 双向认证:客户端→2379(Client 端口),节点间→2380(Peer 端口)
生产建议:etcd 集群应部署在独立的专用节点上,避免与 Kubernetes 工作负载争抢 CPU/内存/磁盘 I/O。数据目录建议使用独立的 NVMe 磁盘分区,并定期执行 etcdctl defrag 回收存储空间。