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 是性能瓶颈。
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 集群应部署在独立的专用节点上,避免与 Kubernetes 工作负载争抢 CPU/内存/磁盘 I/O。数据目录建议使用独立的 NVMe 磁盘分区,并定期执行
etcdctl defrag 回收存储空间。