etcd的增删改查

Kubernetes生产实战：etcd数据变更的禁忌与正道

在Kubernetes集群中，直接操作etcd就像打开潘多拉魔盒——看似能解决一切问题，实则暗藏致命风险。本文将揭示etcd数据变更的正确姿势与死亡陷阱，带你绕过生产环境的那些"坑"！

---

一、etcd数据变更的三大正规途径

1. 通过Kubernetes API操作（推荐指数⭐⭐⭐⭐⭐）

# 创建Pod（间接写入etcd）
kubectl apply -f pod.yaml

# 更新Deployment镜像（触发etcd数据变更）
kubectl set image deployment/nginx nginx=nginx:1.23

# 删除Service（移除etcd记录）
kubectl delete svc my-service

✅ 优点：天然事务性，自动触发控制器协调
❌ 风险：无（只要遵守K8S规范）

2. 控制器自动协调（无人值守变更）
场景示例：

• HPA自动扩容Deployment副本数
• Node故障后DaemonSet重建Pod
• Job完成后触发状态更新

监控技巧：

watch -n 1 'etcdctl get /registry/pods --prefix | wc -l'

3. 运维维护操作（谨慎使用）

# 压缩历史版本（释放存储空间）
etcdctl compact 100000

# 数据碎片整理
etcdctl defrag --cluster

⚠️ 注意：需在维护窗口操作，避开业务高峰

---

二、直接修改etcd数据的六大死亡姿势

作死操作1：手动删除僵尸资源

etcdctl del /registry/pods/default/my-zombie-pod

💥 后果：控制器无法感知，可能引发副本雪崩
🛡️ 正确做法：

kubectl delete pod my-zombie-pod --force --grace-period=0

作死操作2：强行修改Deployment状态

etcdctl put /registry/deployments/default/my-deploy '{"spec":{"replicas":10}}'

💥 后果：与apiserver缓存不一致，导致状态回滚
🛡️ 正确做法：

kubectl scale deploy my-deploy --replicas=10

作死操作3：绕过RBAC直接写权限

etcdctl put /registry/roles/default/admin '{"rules":[{"verbs":["*"]}]}'

💥 后果：安全策略失效，集群完全暴露
🛡️ 正确做法：

kubectl apply -f role.yaml

---

三、生死攸关：etcd数据变更流程图

graph TD A[用户/控制器发起变更] --> B{K8S API Server} B --> C[认证/鉴权] C --> D[准入控制] D --> E[资源校验] E --> F[写入etcd] F --> G[返回响应] G --> H[控制器响应变更] H --> I[集群状态协调] style A fill:#f9f,stroke:#333 style F fill:#f96,stroke:#333

关键路径解析：

1. 认证关卡：X509证书/Bearer Token验证
2. 准入控制：MutatingWebhook/ValidatingWebhook
3. 资源校验：OpenAPI Schema检查
4. 数据持久化：Raft协议确保集群一致性

---

四、生产环境紧急操作指南

场景1：误删Namespace

# 1. 立即停止apiserver（防止GC清理资源）
systemctl stop kube-apiserver

# 2. 从备份恢复（必须有定期快照！）
etcdctl snapshot restore backup.db \
  --data-dir /var/lib/etcd-restore

# 3. 重启etcd集群
systemctl restart etcd

场景2：证书过期导致无法写入

# 1. 检查过期证书
openssl x509 -in /etc/kubernetes/pki/etcd/server.crt -noout -dates

# 2. 快速续期（kubeadm集群）
kubeadm certs renew etcd-server
systemctl restart etcd

场景3：etcd空间爆满

# 1. 紧急压缩
etcdctl compact $(date -d "1 hour ago" +%s)

# 2. 碎片整理（逐个节点执行）
etcdctl --endpoints=https://etcd1:2379 defrag

---

五、监控变更的六道防火墙

1. 变更审计：

   # audit-policy.yaml
   rules:
   - level: Metadata
     resources:
     - group: ""
       resources: ["secrets", "configmaps"]
   

2. 实时告警：

   • Prometheus规则示例：

     - alert: EtcdHighWriteLatency
       expr: histogram_quantile(0.99, rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m])) > 0.5
     

3. 版本对比：

   # 每小时快照对比
   diff <(etcdctl get --prefix /) <(etcdctl get --prefix / --rev=12345)
   

---

六、灵魂拷问：你真的需要碰etcd吗？

✅ 合法场景：

• 集群灾难恢复
• 证书更新维护
• etcd自身扩缩容
• 底层性能调优

❌ 禁止场景：

• 直接修改业务资源
• 调整控制器状态
• 绕过K8S安全策略
• 手动清理资源

---

结语

记住这三条黄金法则：

1. 能通过kubectl操作的，绝不碰etcd
2. 必须操作etcd时，先备份再动手
3. 所有变更可审计，所有操作可回滚

etcd是Kubernetes集群的"圣杯"，对待它的正确态度应该是：
🔧 如无必要，勿增实体
🛡️ 必要操作，如履薄冰
📚 变更留痕，责任到人

现在，立刻检查你的etcd备份是否有效，审计日志是否开启！下一次危机来临时，你会感谢今天的准备。