3. etcd 运维与调优：备份恢复、性能调优与集群监控

etcd 作为 Kubernetes 控制平面的唯一持久化存储层，其稳定性直接决定集群的可用性。本章聚焦 etcd 的三大核心运维场景：备份与恢复（灾难恢复基石）、性能调优（磁盘 IO 与网络延迟瓶颈）、集群监控（metrics 采集与告警）。掌握这些技能是 SRE 保障集群数据安全与响应延迟的关键。

3.1 etcd 备份与恢复（Snapshot）

etcd 提供基于 snapshot（快照） 的备份机制，支持全量数据导出与导入。备份是应对数据损坏、误操作、集群故障的最后防线。

3.1.1 创建快照（备份）

使用 etcdctl snapshot save 命令创建一致性快照。建议在集群低负载窗口执行，并定期轮转备份文件。

# 设置环境变量（根据实际端点与证书路径调整）
export ETCDCTL_API=3
ENDPOINTS=https://127.0.0.1:2379
CACERT=/etc/kubernetes/pki/etcd/ca.crt
CERT=/etc/kubernetes/pki/etcd/server.crt
KEY=/etc/kubernetes/pki/etcd/server.key

# 创建快照
etcdctl --endpoints=$ENDPOINTS \
  --cacert=$CACERT --cert=$CERT --key=$KEY \
  snapshot save /backup/etcd-snapshot-$(date +%Y%m%d-%H%M%S).db

# 验证快照文件
etcdctl --write-out=table snapshot status /backup/etcd-snapshot-20250315-120000.db

3.1.2 从快照恢复

恢复操作通常在新节点或空数据目录上执行。恢复后需手动启动 etcd 并验证成员状态。

# 停止 etcd 服务（所有成员节点）
systemctl stop etcd

# 备份旧数据目录（可选）
mv /var/lib/etcd /var/lib/etcd.bak

# 使用快照恢复数据到新目录
etcdctl snapshot restore /backup/etcd-snapshot-20250315-120000.db \
  --name=etcd-0 \
  --initial-cluster=etcd-0=http://10.0.0.1:2380 \
  --initial-cluster-=etcd-cluster-1 \
  --initial-advertise-peer-urls=http://10.0.0.1:2380 \
  --data-dir=/var/lib/etcd

# 启动 etcd 服务
systemctl start etcd

# 验证集群健康
etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=$CACERT --cert=$CERT --key=$KEY \
  endpoint health

3.1.3 备份策略对比

3.2 etcd 性能调优

etcd 性能瓶颈通常集中在 磁盘 IO 和 网络延迟 两个维度。调优目标是降低写入延迟（p99 < 10ms）并维持集群吞吐量。

3.2.1 磁盘 IO 调优

etcd 对磁盘延迟极其敏感，尤其是 WAL（预写日志）的 fsync 操作。推荐使用 SSD/NVMe 并独立挂载数据盘。

• 使用高性能存储：避免使用共享存储（NFS/Ceph RBD），优先本地 NVMe SSD。
• 调整 fsync 行为：通过 --wal-fsync 和 --backend-bbolt-fsync 控制同步策略。生产环境保持默认 true，测试环境可设为 false 提升性能。
• 磁盘 IO 隔离：使用 cgroups 或 systemd 限制其他进程对 etcd 数据盘的 IO 争抢。
• 监控 IO 延迟：关注 etcd_disk_wal_fsync_duration_seconds 指标，p99 应低于 10ms。

# 使用 iostat 监控磁盘延迟
iostat -x 1 /dev/nvme0n1

# 使用 fio 测试磁盘性能（4KB 随机写入）
fio --name=etcd-test --ioengine=libaio --rw=randwrite --bs=4k \
    --size=1G --numjobs=1 --iodepth=1 --runtime=60 --direct=1

3.2.2 网络延迟调优

etcd 使用 Raft 协议，网络延迟直接影响领导者选举和日志复制速度。集群节点间 RTT 应小于 10ms。

• 节点部署拓扑：将 etcd 成员部署在同一可用区或物理机架内，避免跨地域部署。
• 调整心跳间隔：通过 --heartbeat-interval（默认 100ms）和 --election-timeout（默认 1000ms）适应网络延迟。高延迟环境可适当增大。
• 启用 TLS 会话复用：减少 TLS 握手开销，使用 --peer-tls-session-cache-size 提升连接复用率。
• 网络带宽保障：确保 etcd 节点间带宽不低于 1Gbps，避免与其他高带宽应用共享网卡。

3.2.3 关键性能参数速查

3.3 etcd 集群监控（Metrics）

etcd 通过 /metrics 端点暴露 Prometheus 格式指标，涵盖 Raft 状态、磁盘延迟、请求延迟、存储容量等核心维度。监控是发现性能瓶颈和故障前兆的第一手段。

3.3.1 核心监控指标

3.3.2 监控架构与采集配置

推荐使用 Prometheus + Grafana 搭建 etcd 监控栈。etcd 默认在 2379 端口暴露 metrics，无需额外配置。

# Prometheus scrape 配置示例
scrape_configs:
  - job_name: 'etcd'
    scheme: https
    tls_config:
      ca_file: /etc/kubernetes/pki/etcd/ca.crt
      cert_file: /etc/kubernetes/pki/etcd/server.crt
      key_file: /etc/kubernetes/pki/etcd/server.key
    static_configs:
      - targets:
        - '10.0.0.1:2379'
        - '10.0.0.2:2379'
        - '10.0.0.3:2379'

3.3.3 常见故障模式与告警规则

• 领导者频繁切换：通常由网络分区或磁盘 IO 抖动引起。告警规则：rate(etcd_server_leader_changes_seen_total[15m]) > 0.5。
• 磁盘延迟飙升：WAL fsync 延迟超过 100ms 会导致 Raft 心跳超时。告警规则：histogram_quantile(0.99, rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m])) > 0.1。
• 数据库空间不足：当 etcd 数据库大小接近 quota 时，写入会失败。告警规则：etcd_mvcc_db_total_size_in_bytes / etcd_server_quota_backend_bytes > 0.8。
• 提案失败：提案失败通常意味着集群不可写入。告警规则：rate(etcd_server_proposals_failed_total[5m]) > 0。

3.4 本章小结