etcd 在集群里的位置
etcd 是集群唯一的状态存储：所有对象、事件与配置都放在这里，apiserver 是唯一直接读写它的组件。etcd 不可用时，集群无法创建或更新任何资源，已运行的 Pod 照旧工作但控制面等于瘫痪。它对磁盘延迟极其敏感，官方建议使用 SSD 并单独挂盘。日常运维集中在三件事：成员是否都在、端点是否健康、磁盘与配额水位是否安全。
基本信息
| 适用平台 | Kubernetes 控制面组件，kubeadm 集群以静态 Pod 形式运行 |
|---|---|
| 默认端口 | 2379 客户端通信，2380 成员之间通信 |
| 关键证书 | /etc/kubernetes/pki/etcd/ 下的 ca.crt、server.crt、server.key |
| 常用子命令 | endpoint health、endpoint status、member list、snapshot save |
| 关注信号 | leader 切换次数、数据库大小、fsync 延迟 |
典型使用场景
- 控制面变慢或 apiserver 报超时时，先确认 etcd 端点健康与磁盘延迟
- 扩容控制面：以奇数成员数评估集群规格，避免脑裂风险
- 升级前做快照并验证恢复流程，保证有可回退的状态副本
- 容量巡检：看数据库大小与配额水位，提前安排压缩整理
- 排查 leader 频繁切换：定位到磁盘 IO 抖动或网络问题
kubeadm 环境示例（控制面节点执行）
kubeadm 环境示例（控制面节点执行）
kubectl -n kube-system exec etcd-<node> -- etcdctl \
--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 \
endpoint health # 每个成员都应返回 healthy
# 成员与数据库状态
etcdctl --endpoints=https://127.0.0.1:2379 --cacert=... --cert=... --key=... \
member list --write-out=table
etcdctl --endpoints=https://127.0.0.1:2379 --cacert=... --cert=... --key=... \
endpoint status --write-out=table # 关注 DB SIZE 与 IS LEADER 两列巡检项与判读
| 检查项 | 入口 | 判读要点 |
|---|---|---|
| 端点健康 | endpoint health | 全部成员健康；有异常先看网络与证书 |
| 成员列表 | member list | 成员数应为奇数，成员地址与控制面一致 |
| 数据库大小 | endpoint status 的 DB SIZE | 接近配额时报空间告警，需要压缩整理 |
| 写延迟 | status 中的 WAL 与 backend 指标 | 延迟上升通常先查磁盘 IO 与共享盘的干扰 |
用 kubectl exec 进 etcd 容器执行 etcdctl 必须带齐证书参数，kubeadm 默认把它们放在 /etc/kubernetes/pki/etcd 下；多成员集群要把 endpoints 写成全部成员的地址才能看到完整状态。
不要绕过 apiserver 直接修改 etcd 里的数据：跳过校验与准入后，对象状态与控制器认知会不一致，后续排障几乎无法复原现场。