1
? ?
5 步實現 etcd 精確恢復
將快照恢復到本地 etcd 數據目錄。
使用恢復的數據啟動本地 etcd 實例。
使用 etcdctl 查詢特定鍵（例如，ConfigMap）。
使用 auger 解碼以提取干凈的 YAML。
使用 kubectl 申請恢復到您的實時集群。
本指南將指導您從 etcd 快照中精準地恢復資源，而無需觸發完整的集群恢復。無論您是要排除意外刪除故障，還是進行取證調試，這種輕量級且有針對性的方法都能最大程度地減少停機時間。#Kubernetes
2
? ?
引言：🩺Kubernetes 操作里的緊急情況
etcd 是 Kubernetes 集群的核心，它是一個分布式鍵值存儲系統，忠實地維護系統內每個對象的狀態。但是，如果某個資源（例如 ConfigMap、Secret 或 Deployment）被刪除或損壞，會發生什么情況呢？
啟動完整的集群恢復就像進行心臟手術來修復紙張劃傷一樣。它具有破壞性、風險性，而且通常沒有必要。
這就是手術精度發揮作用的地方。
想象一下，您的生產環境陷入危機——一個重要的 ConfigMap 消失了，Pod 崩潰了，用戶只能盯著錯誤頁面。完全回滾會比問題本身造成更大的損失。您需要的是一個“外科醫生”式的方案：只修復損壞的部分，其他部分一概不做。
在本博客中，您將了解如何：
從 etcd 快照中隔離并提取特定資源
僅將所需內容直接恢復到實時 Kubernetes 集群中
避免不必要的停機并保持集群穩定性
非常適合重視最小影響恢復的 DevOps、SRE 和 Kubernetes 管理員。
3
? ?
先決條件🔧
為了繼續操作，請確保您已具備：
etcd v3.4+ — etcd 服務器二進制文件可在此處獲取
etcdctl — 與 etcd 交互的 CLI
auger — CLI 工具，用于將 etcd 的二進制有效負載解碼為 YAML
kubectl — CLI 用于將資源應用于 Kubernetes 集群
快照文件— 例如 live-cluster-snapshot.db
始終先在暫存環境中工作。從干凈的快照開始：
etcdctl snapshot save live-cluster-snapshot.db
4
? ?
恢復過程🏥
假設 production 命名空間中一個關鍵的 ConfigMap app-config 被意外刪除了。以下是如何將其恢復：
4.1
? ?
🧬 步驟 1：準備快照
如果壓縮，請解壓縮快照：
gunzip live-cluster-snapshot.db.gz
然后恢復它：
etcdctl snapshot restore live-cluster-snapshot.db --data-dir=recovery-etcd
4.2
? ?
🩻 第 2 步：啟動本地 etcd 實例
etcd --data-dir=recovery-etcd --listen-client-urls=http://localhost:2379
核實：
etcdctl --endpoints=localhost:2379 endpoint status4.3
? ?
🔍 步驟 3：定位并提取資源
Kubernetes 將 ConfigMap 存儲在類似 /registry/configmaps//的鍵中。列出生產命名空間中的鍵：
etcdctl --endpoints=localhost:2379 get --prefix "/registry/configmaps/production" --keys-only你會看到類似這樣的內容：
/registry/configmaps/production/app-config提取并解碼 ConfigMap：
etcdctl --endpoints=localhost:2379 get /registry/configmaps/production/app-config --print-value-only | auger decode > app-config.yaml
生成的 app-config.yaml 可能如下所示：
apiVersion: v1? kind: ConfigMap? metadata:? ? name: app-config? ? namespace: production? data:? ? api-url: "https://api.example.com"? ? log-level: "debug"
4.4
? ?
步驟 4：恢復到集群
通過試運行來測試修復效果：
kubectl apply -f app-config.yaml --dry-run=server
如果一切檢查無誤，則應用它：
kubectl apply -f app-config.yaml
輸出：
configmap/app-config created
4.5
? ?
🧹 步驟 5：清理
pkill etcdrm -rf recovery-etcd app-config.yaml5
? ?
高級場景🔍
5.1
? ?
💠 跨命名空間恢復
cat app-config.yaml | yq eval '.metadata.namespace = "dev"' | kubectl apply -f -
5.2
? ?
🔐 加密集群 (KMS)
使用 etcdctl 并根據 etcd 加密指南配置解密密鑰。📦批量恢復?
etcdctl --endpoints=localhost:2379 get --prefix "/registry/configmaps/production" --print-value-only | auger decode > all-cm.yaml6
? ?
總結
最后的想法💡Kubernetes 管理員經常為災難性故障做準備，但忽略了精確恢復的價值。能夠精準地提取和恢復資源，并減少停機時間、防止附帶損害、增強對事件響應的信心。當下次災難來臨時，您不會手忙腳亂，而是會采取行動。
隨手關注或者”在看“，誠摯感謝！
