etcd 原理与运维
本文缩写（英文全称与中文含义）
| 缩写 | 英文全称／名称 | 中文含义 |
|---|---|---|
| API | Application Programming Interface | 应用程序编程接口 |
| CRD | Custom Resource Definition | Kubernetes 自定义资源定义 |
| EKS | Elastic Kubernetes Service | AWS 托管 Kubernetes 服务 |
| I/O | Input/Output | 输入／输出 |
| KMS | Key Management Service | 密钥管理服务 |
| PKI | Public Key Infrastructure | 公钥基础设施 |
| PV | Persistent Volume | 持久卷 |
| PVC | Persistent Volume Claim | 持久卷申领 |
| RBAC | Role-Based Access Control | 基于角色的访问控制 |
| SSD | Solid-State Drive | 固态硬盘 |
| TLS | Transport Layer Security | 传输层安全协议 |
etcd 是 Kubernetes 控制面的分布式键值存储，保存集群对象及其状态。API Server 读写 etcd，其他组件通过 Kubernetes API 操作对象。
阅读路径#
| 文档 | 内容 |
|---|---|
| 为什么选择 etcd | 控制面需求、数据库对比、替代方案与常见误区 |
| Hands-on | 独立实验、读写、Watch、Lease、快照与恢复 |
| Kubernetes 运维与灾备 | TLS 巡检、备份、三节点恢复、扩容维护、排障 |
本文命令采用 etcd 3.6 接口，独立实验固定使用 3.6.5，便于复现；这不是生产版本推荐。生产版本由 Kubernetes 发行版的兼容要求和安全更新决定，etcdctl、etcdutl 优先与服务端使用相同版本。
保存什么#
| 内容 | 是否在 etcd 中 |
|---|---|
| Deployment、Service、ConfigMap、Secret、RBAC、CRD 及自定义资源对象 | 是 |
| PV/PVC 对象、Pod 状态 | 是 |
| PV 中的文件、数据库数据、容器镜像、节点日志 | 否，需要各自备份 |
| API Server 的加密配置、外部 KMS 密钥、节点上的 PKI 文件 | 不由 etcd 快照完整保护，需单独管理 |
Secret 的 Base64 编码不等于加密。应为敏感资源配置静态加密，并保护解密密钥及备份。持有 etcd 客户端凭据可绕过 Kubernetes RBAC，因此只授予控制面与受控运维任务。
关键概念#
| 概念 | 运维含义 |
|---|---|
| Raft / Leader | 通过多数投票成员达成一致，Leader 变更可能造成短暂延迟 |
| Quorum | floor(N/2)+1；3 个投票成员容忍 1 个故障，5 个容忍 2 个 |
| Revision | 键空间修改产生的逻辑版本，用于历史读取、Watch 和并发控制 |
| Watch | 订阅对象变化；历史被压缩后，客户端需重新读取并建立 Watch |
| Lease | 有期限的租约，可关联键；到期或撤销后关联键被删除 |
| Compaction / Defrag | 前者清理历史版本；后者回收数据库文件的空闲空间 |
API 语义见 etcd API。不要将 etcd 当业务缓存使用，也不要直接修改 Kubernetes 的 /registry/ 键。
部署与可用性#
- Stacked etcd：与控制面节点共存，kubeadm 常见模式；节点故障会同时影响 API Server 和 etcd 成员。
- External etcd：独立节点部署，故障与资源隔离更好，但需单独维护证书、网络与升级。
- 托管 Kubernetes：如 EKS，用户通常不直接管理控制面 etcd；按平台能力恢复集群，并单独保护资源配置、PV 与外部数据库。
生产通常部署 3 个投票成员，分散到低延迟的故障域；使用 SSD，避免与高 I/O 业务争抢磁盘。客户端端口为 2379，成员通信为 2380，两者启用 TLS 并限制来源。跨地域灾备优先使用备份恢复，不把高延迟地域强行接入同一 Raft 集群。参考 Kubernetes 运维说明与 etcd 硬件建议。
失去多数成员后，集群无法正常提交写入。现有容器可能继续运行，但调度、扩缩容和控制器协调会受影响；“业务暂时可访问”不能证明控制面正常。