實(shí)戰(zhàn)：etcd快照與Velero雙保險(xiǎn)方案)
自打開(kāi)始正經(jīng)維護(hù) Kubernetes 集群之后我?guī)缀趺刻於紩?huì)被同一個(gè)問(wèn)題敲打如果哪天 etcd 數(shù)據(jù)盤壞了、誤刪了一個(gè) namespace或者整臺(tái) Master 節(jié)點(diǎn)被清空你到底能不能把集群拉回來(lái)我相信絕大多數(shù)人的第一反應(yīng)是有資源清單啊丟了重建不就行了。但真正經(jīng)歷過(guò)故障的人會(huì)明白這種想法在單機(jī)實(shí)驗(yàn)環(huán)境勉強(qiáng)成立放到生產(chǎn)環(huán)境里基本等于裸奔。因?yàn)榧豪锍?Deployment、Service 這些能kubectl get出來(lái)的對(duì)象還有大量的配置、密鑰、PVC 里的業(yè)務(wù)數(shù)據(jù)、CRD 資源、RBAC 授權(quán)關(guān)系這些東西一旦丟失想靠人工重建幾乎是不可能完成的任務(wù)。這篇博客就圍繞 Kubernetes 集群備份與恢復(fù)的完整配置與實(shí)踐展開(kāi)。我會(huì)從備份思路講起逐步拆解 etcd 快照和 Velero 這兩套主流方案把命令、參數(shù)、常見(jiàn)坑、恢復(fù)演練的步驟全部攤開(kāi)講。不管你是在自己搭的測(cè)試集群上做實(shí)驗(yàn)還是正在為生產(chǎn)集群設(shè)計(jì)容災(zāi)方案這篇內(nèi)容都能幫你在腦子里建立起一套清晰的備份恢復(fù)框架。先說(shuō)明一點(diǎn)本文所有操作都基于我實(shí)際在用的集群環(huán)境驗(yàn)證過(guò)但版本差異會(huì)帶來(lái)細(xì)節(jié)上的變化閱讀時(shí)請(qǐng)結(jié)合你自己的集群版本做微調(diào)。1. 備份前先把思路理清楚到底要備份什么在動(dòng)手配置任何工具之前我建議你先完成一輪“靈魂拷問(wèn)”。因?yàn)閭浞莘桨傅脑O(shè)計(jì)本質(zhì)上是對(duì)集群資產(chǎn)做分類分類做不清楚后面所有備份動(dòng)作都是盲目的。1.1 先問(wèn)自己三個(gè)關(guān)鍵問(wèn)題第一個(gè)問(wèn)題如果集群徹底無(wú)法恢復(fù)你能否在 24 小時(shí)內(nèi)重建出所有業(yè)務(wù)這里說(shuō)的業(yè)務(wù)不只是工作負(fù)載還包括它依賴的配置中心數(shù)據(jù)、數(shù)據(jù)庫(kù)內(nèi)容、消息隊(duì)列里的積壓消息、對(duì)象存儲(chǔ)桶以及 K8s 集群中的各種自定義資源。第二個(gè)問(wèn)題你的備份是否被人為驗(yàn)證過(guò)備份文件存在那里沒(méi)有任何意義只有定期做恢復(fù)演練、并且演練成功過(guò)備份才算真正有效。第三個(gè)問(wèn)題萬(wàn)一發(fā)生誤刪操作你允許的數(shù)據(jù)丟失時(shí)間窗口是多久這個(gè) RPORecovery Point Objective直接決定了你的備份頻率和備份方式。我把這些問(wèn)題拿出來(lái)說(shuō)是因?yàn)槲乙?jiàn)過(guò)太多人把備份等同于“對(duì) etcd 做一個(gè)快照”。實(shí)際上etcd 快照只覆蓋 Kubernetes 控制面存儲(chǔ)的狀態(tài)它根本不包含業(yè)務(wù)容器寫(xiě)入 PV 的數(shù)據(jù)。如果你跑的是 MySQL、Redis 這類有狀態(tài)服務(wù)PV 數(shù)據(jù)丟了etcd 再完整也只能幫你恢復(fù)出一個(gè)空殼數(shù)據(jù)庫(kù)。1.2 把資產(chǎn)拆成三個(gè)層次來(lái)看待我習(xí)慣把一個(gè)集群需要保護(hù)的資產(chǎn)分成三個(gè)層次。第一層是集群狀態(tài)層對(duì)應(yīng) etcd 中保存的幾乎所有 Kubernetes 對(duì)象包括 Deployment、Service、ConfigMap、Secret、Namespace、RBAC 規(guī)則、CRD 實(shí)例等。這一層的特點(diǎn)是數(shù)據(jù)量通常不大但變化極其頻繁任何一次kubectl apply都會(huì)改動(dòng)它。第二層是持久化數(shù)據(jù)層也就是 PV/PVC 背后真正存儲(chǔ)的業(yè)務(wù)文件、數(shù)據(jù)庫(kù)文件這一層通常由云盤、NFS、Ceph 等外部存儲(chǔ)系統(tǒng)承載Kubernetes 自身并不知道里面裝了什么。第三層是外部依賴層比如鏡像倉(cāng)庫(kù)里的鏡像、Helm Chart 倉(cāng)庫(kù)、GitOps 倉(cāng)庫(kù)里的部署清單這些資源往往不在集群內(nèi)卻是重建集群時(shí)必不可少的輸入。有了這三層視角之后你的備份策略就非常清晰了集群狀態(tài)層用 etcd 快照解決持久化數(shù)據(jù)層用 Velero 這類工具配合存儲(chǔ)驅(qū)動(dòng)解決外部依賴層則靠日常的版本管理和倉(cāng)庫(kù)鏡像同步解決。三者缺一不可。1.3 方案選型etcd 快照與 Velero 并不沖突我經(jīng)常在社區(qū)里看到有人爭(zhēng)論“備份到底該用 etcd 快照還是 Velero”這個(gè)問(wèn)題本身就問(wèn)錯(cuò)了。這兩種工具解決的不是同一個(gè)問(wèn)題放在一起使用才是一套完整的方案。etcd 快照負(fù)責(zé)兜底適合應(yīng)對(duì)集群級(jí)災(zāi)難比如 Master 節(jié)點(diǎn)不可用、etcd 數(shù)據(jù)全部損壞、誤刪了整個(gè) Namespace 且資源無(wú)法重建。Velero 負(fù)責(zé)精細(xì)化和應(yīng)用級(jí)備份適合做資源遷移、版本回滾、按命名空間恢復(fù)還能借助 restic 或 Kopia 備份 PV 數(shù)據(jù)。如果你的集群所有數(shù)據(jù)都有外部備份并且一切皆代碼那你可以只依賴 GitOps 方式重建但大多數(shù)團(tuán)隊(duì)還沒(méi)做到這個(gè)程度因此快照依然是必需品?？吹竭@里你基本明白了我不是讓你二選一而是建議你用“雙保險(xiǎn)”思路搭建備份體系。后面幾節(jié)我會(huì)把兩條路線都走一遍你可以直接照抄配置。2. 動(dòng)手前的環(huán)境準(zhǔn)備與配置項(xiàng)梳理不管用 etcd 快照還是 Velero集群本身需要滿足一些最基本的條件。這一節(jié)先把環(huán)境準(zhǔn)備和核心配置項(xiàng)講清楚避免后面實(shí)操時(shí)卡在一些莫名其妙的地方。2.1 確認(rèn)集群部署方式與 etcd 形態(tài)首先要確認(rèn)你的 etcd 是怎么部署的。不同集群形態(tài)會(huì)導(dǎo)致 etcd 的訪問(wèn)方式完全不同這一點(diǎn)是新手最容易栽跟頭的地方。kubeadm 部署的集群etcd 以靜態(tài) Pod 方式運(yùn)行在 Master 節(jié)點(diǎn)上通過(guò)/etc/kubernetes/manifests/etcd.yaml定義證書(shū)和配置集中在/etc/kubernetes/pki/etcd/目錄。二進(jìn)制方式部署的集群etcd 通常以 systemd 服務(wù)運(yùn)行數(shù)據(jù)目錄、證書(shū)路徑、監(jiān)聽(tīng)地址全部由你自定義快照時(shí)需要手動(dòng)拼接參數(shù)。云廠商托管的集群如 EKS、ACK、TKE控制面 etcd 基本由云廠商管理用戶無(wú)法直接接觸此時(shí)你更需要依賴 Velero 或云廠商自帶的集群快照能力做應(yīng)用級(jí)備份。定位好你自己的集群形態(tài)后面的命令才能跑通。我下面的實(shí)踐示例基于 kubeadm 部署的集群來(lái)展開(kāi)這也是社區(qū)里最常見(jiàn)的自建集群方式。2.2 為備份賬號(hào)準(zhǔn)備必要的權(quán)限配置如果你要用 Velero它需要一個(gè)專用的服務(wù)賬號(hào)并且這個(gè)賬號(hào)需要有足夠權(quán)限讀取集群中的所有資源。Velero 安裝時(shí)默認(rèn)會(huì)創(chuàng)建velero命名空間并部署一組 RBAC 規(guī)則正常情況下不用手動(dòng)造輪子。但有一點(diǎn)容易忽略當(dāng)你計(jì)劃備份自定義資源CRD時(shí)需要確保 Velero 的服務(wù)賬號(hào)對(duì)相關(guān) CRD 有 get、list、watch 權(quán)限。如果某天你發(fā)現(xiàn)備份任務(wù)顯示成功但恢復(fù)后 CRD 實(shí)例丟了優(yōu)先檢查是不是權(quán)限不足導(dǎo)致 Velero 無(wú)法枚舉資源。這里給出一個(gè)排查用的最小 RBAC 配置它授予了備份操作所需的粗粒度權(quán)限。如果你對(duì)安全要求比較高建議按需收縮到具體資源apiVersion: v1 kind: ServiceAccount metadata: name: velero namespace: velero --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: velero-admin roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: velero namespace: velero這個(gè)配置看起來(lái)比較粗暴但它能保證 Velero 不會(huì)因?yàn)闄?quán)限問(wèn)題而跳過(guò)資源。生產(chǎn)環(huán)境建議結(jié)合 Velero 官方文檔中的 RBAC 模板做進(jìn)一步裁剪。2.3 準(zhǔn)備一套獨(dú)立的對(duì)象存儲(chǔ)用于存放備份Velero 的備份文件需要落到對(duì)象存儲(chǔ)中。如果你已經(jīng)在用 AWS S3、阿里云 OSS、MinIO 這類兼容 S3 協(xié)議的服務(wù)那可以直接復(fù)用。如果還沒(méi)有我強(qiáng)烈建議你在內(nèi)網(wǎng)部署一個(gè) MinIO專門用于存放備份。它的部署非常簡(jiǎn)單單機(jī)版用 Docker 幾分鐘就能跑起來(lái)。用 MinIO 主要是為了兩個(gè)目的一是讓備份文件集中管理不會(huì)被隨意清理二是 Velero 官方對(duì) S3 API 的兼容性很好選它省去很多兼容性適配的麻煩。存儲(chǔ)桶創(chuàng)建好后記錄下 endpoint 地址、access key、secret key后面配置 Velero 時(shí)要用到。下面是我的 MinIO 初始化命令示例實(shí)際使用時(shí)請(qǐng)?zhí)鎿Q成你自己的賬號(hào)密碼docker run -d \ --name minio \ -p 9000:9000 \ -p 9001:9001 \ -e MINIO_ROOT_USERvelero_backup \ -e MINIO_ROOT_PASSWORDYourStrongPass2026 \ -v /data/minio:/data \ minio/minio server /data --console-address :9001啟動(dòng)后到控制臺(tái)創(chuàng)建一個(gè)名為velero-backup的 bucket并且建議開(kāi)啟版本控制。原因很簡(jiǎn)單版本控制能防止備份對(duì)象被誤刪或覆蓋相當(dāng)于給備份又加了一層保險(xiǎn)。3. etcd 快照備份與恢復(fù)的完整實(shí)踐etcd 快照是整個(gè)集群備份體系的第一塊基石也是恢復(fù)集群控制面數(shù)據(jù)的終極手段。我不敢說(shuō)它難但操作過(guò)程中稍有不慎就會(huì)造成數(shù)據(jù)不一致所以接下來(lái)我會(huì)把每一步拆得很細(xì)。3.1 配置 etcd 客戶端證書(shū)環(huán)境變量使用etcdctl做快照通常需要 TLS 證書(shū)認(rèn)證。kubeadm 部署的集群中etcd 證書(shū)位于 Master 節(jié)點(diǎn)的/etc/kubernetes/pki/etcd/目錄你需要在執(zhí)行命令前導(dǎo)出環(huán)境變量否則會(huì)提示證書(shū)校驗(yàn)失敗。我的做法是先把以下內(nèi)容寫(xiě)到/etc/profile.d/etcdctl.sh中簡(jiǎn)化后續(xù)操作export ETCDCTL_API3 export ETCDCTL_CACERT/etc/kubernetes/pki/etcd/ca.crt export ETCDCTL_CERT/etc/kubernetes/pki/etcd/server.crt export ETCDCTL_KEY/etc/kubernetes/pki/etcd/server.key export ETCDCTL_ENDPOINTShttps://127.0.0.1:2379關(guān)于證書(shū)文件有一個(gè)細(xì)節(jié)值得說(shuō)明server.crt和server.key是 etcd 服務(wù)端證書(shū)用于 etcd 各成員之間通信同時(shí)也被 etcdctl 作為客戶端證書(shū)使用。如果你在某個(gè)節(jié)點(diǎn)上找不到server.*文件也可以嘗試用peer.crt和peer.key替代但首選仍是 server 證書(shū)。執(zhí)行source /etc/profile.d/etcdctl.sh后可用一條簡(jiǎn)單的etcdctl endpoint health命令驗(yàn)證連接是否正常。3.2 執(zhí)行手動(dòng)快照與定時(shí)備份完成認(rèn)證配置后做一次手動(dòng)快照就非常簡(jiǎn)單了mkdir -p /backup/etcd etcdctl snapshot save /backup/etcd/snapshot-$(date %Y%m%d-%H%M%S).db執(zhí)行成功后會(huì)輸出類似Snapshot saved at /backup/etcd/snapshot-xxxx.db的信息。此時(shí)你可以用校驗(yàn)命令確認(rèn)快照文件沒(méi)有損壞etcdctl snapshot status /backup/etcd/snapshot-xxxx.db該命令會(huì)返回快照的版本、數(shù)據(jù)大小、hash 值等信息。我每次做完快照都會(huì)順手跑一次這條命令它雖然不能百分百保證恢復(fù)成功但至少能從哈希層面排除文件在落盤過(guò)程中出現(xiàn)損壞的可能。手動(dòng)快照只能救急不能作為常態(tài)化機(jī)制。更合理的做法是寫(xiě)一個(gè)定時(shí)任務(wù)腳本每天在業(yè)務(wù)低峰期自動(dòng)執(zhí)行快照并清理三天前的舊文件。下面是我實(shí)際在用的腳本你拿走改成自己的備份目錄就能用#!/bin/bash BACKUP_DIR/backup/etcd RETENTION_DAYS3 source /etc/profile.d/etcdctl.sh mkdir -p ${BACKUP_DIR} etcdctl snapshot save ${BACKUP_DIR}/snapshot-$(date %Y%m%d-%H%M%S).db find ${BACKUP_DIR} -name snapshot-*.db -mtime ${RETENTION_DAYS} -exec rm -f {} \;用crontab -e添加定時(shí)任務(wù)以每天凌晨 2 點(diǎn)執(zhí)行為例0 2 * * * /opt/scripts/etcd-backup.sh /var/log/etcd-backup.log 21關(guān)于快照保留周期我建議根據(jù)自己的數(shù)據(jù)量決定。etcd 快照文件一般不會(huì)很大幾百 MB 到幾個(gè) GB 都很常見(jiàn)所以你完全可以把保留周期設(shè)置得長(zhǎng)一些比如保留 7 份每日快照外加每周快照。丟失數(shù)據(jù)這件事寧可多留不可少留。3.3 恢復(fù)實(shí)操?gòu)目煺者€原到單機(jī)集群恢復(fù) etcd 是整個(gè)集群恢復(fù)流程中最容易手忙腳亂的部分因?yàn)槟阈枰岩粋€(gè)“已經(jīng)存在的故障集群”先停下來(lái)再手動(dòng)去重建數(shù)據(jù)目錄。這里強(qiáng)調(diào)一下恢復(fù)操作必須在所有 etcd 節(jié)點(diǎn)上協(xié)調(diào)進(jìn)行不建議只對(duì)單節(jié)點(diǎn)操作而讓其他節(jié)點(diǎn)繼續(xù)運(yùn)行。下面以單節(jié)點(diǎn) etcd 為例展開(kāi)。第一步停掉 kube-apiserver 和 etcd。如果是靜態(tài) Pod 方式部署最直接的做法是把/etc/kubernetes/manifests/下的etcd.yaml移走并用kubelet的靜態(tài) Pod 機(jī)制讓它自動(dòng)停掉。但更穩(wěn)妥的順序是先把 apiserver 停掉避免 apiserver 在 etcd 恢復(fù)期間不斷寫(xiě)入數(shù)據(jù)導(dǎo)致快照還原后的數(shù)據(jù)被再次污染。mv /etc/kubernetes/manifests/etcd.yaml /root/backup-manifests/ mv /etc/kubernetes/manifests/kube-apiserver.yaml /root/backup-manifests/ sleep 30第二步備份并清空舊的 etcd 數(shù)據(jù)目錄。默認(rèn)數(shù)據(jù)目錄是/var/lib/etcd我建議先把它整個(gè)移動(dòng)到一個(gè)備份位置而不是直接刪除防止恢復(fù)失敗時(shí)還有后悔藥可吃mv /var/lib/etcd /var/lib/etcd.bak.$(date %Y%m%d)第三步用快照文件恢復(fù)數(shù)據(jù)目錄。etcdctl 的snapshot restore命令會(huì)生成一個(gè)新的數(shù)據(jù)目錄你需要通過(guò)--data-dir參數(shù)指定位置并傳入與舊集群一致的名稱和證書(shū)參數(shù)etcdctl snapshot restore /backup/etcd/snapshot-xxxx.db \ --name etcd-1 \ --initial-cluster etcd-1https://127.0.0.1:2380 \ --initial-cluster-token etcd-cluster \ --initial-advertise-peer-urls https://127.0.0.1:2380 \ --data-dir /var/lib/etcd這里有一個(gè)關(guān)鍵點(diǎn)--initial-cluster-token的值必須和原來(lái)的集群保持一致或者干脆隨意指定一個(gè)全新值。后者其實(shí)更常見(jiàn)因?yàn)槟阍谧龌謴?fù)時(shí)通常是想啟動(dòng)一個(gè)全新的 etcd 數(shù)據(jù)實(shí)例。但如果你希望恢復(fù)后的 etcd 能重新加入原有集群拓?fù)淠蔷捅仨毐３?peer URL 與集群配置一致否則其他節(jié)點(diǎn)會(huì)認(rèn)為這是一個(gè)陌生成員。第四步把etcd.yaml和kube-apiserver.yaml移回靜態(tài) Pod 目錄等待 kubelet 自動(dòng)拉起 etcd 和 apiservermv /root/backup-manifests/etcd.yaml /etc/kubernetes/manifests/ mv /root/backup-manifests/kube-apiserver.yaml /etc/kubernetes/manifests/ sleep 60最后驗(yàn)證集群狀態(tài)kubectl get nodes kubectl get pods -A如果看到 Node 狀態(tài)正常、之前的資源都回來(lái)了說(shuō)明恢復(fù)成功。如果 apiserver 啟動(dòng)失敗先去看 kubelet 日志和 etcd 日志絕大多數(shù)問(wèn)題出在證書(shū)路徑不匹配或數(shù)據(jù)目錄權(quán)限不對(duì)上。3.4 恢復(fù)操作中的風(fēng)險(xiǎn)控制與注意事項(xiàng)關(guān)于 etcd 恢復(fù)我吃過(guò)不少虧挑幾個(gè)最典型的提醒一下。第一恢復(fù)操作前必須停止所有寫(xiě)入方。不只是 kube-apiserver如果集群里還有其他組件直接通過(guò) etcd 客戶端接口讀寫(xiě)數(shù)據(jù)比如某些定制 Operator也要一并停止。否則很可能出現(xiàn)恢復(fù)后一部分舊數(shù)據(jù)被新數(shù)據(jù)覆蓋或沖突的情況表現(xiàn)為資源狀態(tài)詭異、對(duì)象反復(fù)重建。第二不要在生產(chǎn)集群上邊跑業(yè)務(wù)邊恢復(fù)。即便恢復(fù)的是單節(jié)點(diǎn) etcd也強(qiáng)烈建議先摘掉業(yè)務(wù)流量因?yàn)榛謴?fù)過(guò)程中 kubelet 可能會(huì)根據(jù)舊數(shù)據(jù)重新創(chuàng)建 Pod造成未知影響。第三etcd 快照不保證包含最近幾秒的寫(xiě)入。etcd 的 snapshot 是某一時(shí)間點(diǎn)的存儲(chǔ)狀態(tài)自快照時(shí)間點(diǎn)之后發(fā)生的變更都會(huì)丟失。這決定了你的 RPO 不可能為零如果你的業(yè)務(wù)對(duì)數(shù)據(jù)極其敏感需要在上層做更細(xì)粒度的備份或同步。4. Velero 應(yīng)用級(jí)備份與恢復(fù)實(shí)操etcd 快照能保住控制面但它無(wú)法備份 PVC 里的數(shù)據(jù)。所以當(dāng)業(yè)務(wù)真正跑起來(lái)之后它用的數(shù)據(jù)庫(kù)文件、上傳的文件、生成的臨時(shí)數(shù)據(jù)全都在 PV 里面這時(shí)候必須請(qǐng)出 Velero。4.1 Velero 的核心架構(gòu)與備份原理Velero 的工作機(jī)制可以簡(jiǎn)單概括為兩部分一方面通過(guò) Kubernetes API 讀取集群中的資源對(duì)象打包后上傳到對(duì)象存儲(chǔ)另一方面通過(guò)文件系統(tǒng)備份組件如 restic 或 Kopia讀取 PVC 掛載的數(shù)據(jù)卷內(nèi)容將其一并上傳。它不需要在集群里安裝特權(quán) DaemonSet 之外的 agent備份動(dòng)作由 Velero Server 組件部署在集群內(nèi)和 Velero CLI 客戶端協(xié)同完成。CLI 下發(fā)備份指令后Velero Server 會(huì)在集群中創(chuàng)建 Backup 資源隨后 Backup Controller 負(fù)責(zé)執(zhí)行具體任務(wù)。你在使用過(guò)程中會(huì)經(jīng)?？吹?Backup、Restore、Schedule、BackupStorageLocation 這幾類 CRD它們都是 Velero 的核心抽象。理解它們的層級(jí)關(guān)系對(duì)排查問(wèn)題很有幫助BackupStorageLocation 定義備份文件存放位置Schedule 定義周期巡檢任務(wù)Backup 是一次具體備份動(dòng)作的記錄Restore 是一次恢復(fù)動(dòng)作的記錄?？慈罩緯r(shí)只需要找到對(duì)應(yīng) Backup 或 Restore 資源然后通過(guò)velero backup logs name查看詳細(xì)日志即可。4.2 安裝 Velero 并配置對(duì)象存儲(chǔ)安裝 Velero 的工具本身并不復(fù)雜核心是把云廠商存儲(chǔ)的訪問(wèn)憑證準(zhǔn)備好。以 MinIO 為例首先創(chuàng)建一個(gè)包含訪問(wèn)密鑰的文件cat credentials-velero EOF [default] aws_access_key_id velero_backup aws_secret_access_key YourStrongPass2026 EOF然后執(zhí)行安裝命令velero install \ --provider aws \ --plugins velero/velero-plugin-for-aws:v1.9.0 \ --bucket velero-backup \ --secret-file ./credentials-velero \ --backup-location-config regionminio,s3ForcePathStyletrue,s3Urlhttp://minio.velero.svc.cluster.local:9000 \ --snapshot-location-config regionminio \ --use-restic \ --use-volume-snapshotsfalse \ --wait拆解一下這條命令中幾個(gè)容易出錯(cuò)的參數(shù)--provider aws這里不是說(shuō)你必須用 AWS而是 Velero 用 AWS S3 兼容協(xié)議去對(duì)接對(duì)象存儲(chǔ)MinIO、OSS、COS 都支持這種協(xié)議。--plugins velero/velero-plugin-for-aws:v1.9.0插件版本要和 Velero 主版本接近否則可能出現(xiàn) API 不兼容的問(wèn)題。s3ForcePathStyletrueMinIO 這類私有對(duì)象存儲(chǔ)要求路徑風(fēng)格 URL不加這個(gè)參數(shù)會(huì)導(dǎo)致 Velero 無(wú)法找到桶。--use-restic啟用文件系統(tǒng)備份能力用來(lái)備份 PVC 數(shù)據(jù)。--use-volume-snapshotsfalse如果存儲(chǔ)后端沒(méi)有實(shí)現(xiàn) CSI 快照能力就關(guān)掉卷快照功能避免 Velero 一直嘗試調(diào)用不存在的快照接口。安裝完成后查看 velero 命名空間下的 Pod 狀態(tài)確保velero和restic相關(guān) Pod 都正常運(yùn)行kubectl get pods -n velero4.3 按命名空間備份先從小范圍開(kāi)始Velero 上手最好的方式不是一上來(lái)就全集群備份而是先挑一個(gè)測(cè)試命名空間做驗(yàn)證。比如我需要備份wordpress命名空間下的所有資源以及 PVC 數(shù)據(jù)可以執(zhí)行velero backup create wordpress-backup \ --include-namespaces wordpress \ --default-volumes-to-restic \ --ttl 168h0m0s參數(shù)說(shuō)明--include-namespaces只備份指定命名空間。--default-volumes-to-restic對(duì) PVC 數(shù)據(jù)啟用 restic 備份。--ttl備份文件在對(duì)象存儲(chǔ)中的保留時(shí)間這里設(shè)置了 7 天。執(zhí)行后可能會(huì)等待一段時(shí)間你可以用velero backup get查看狀態(tài)從 New 變成 Completed 就說(shuō)明備份成功了。然后模擬一次災(zāi)難直接刪掉wordpress命名空間kubectl delete namespace wordpress等命名空間完全清理干凈后執(zhí)行恢復(fù)velero restore create --from-backup wordpress-backup恢復(fù)完成后進(jìn)入命名空間檢查資源確認(rèn) Pod、PVC、Service、Ingress 都回來(lái)了。如果 PVC 里的數(shù)據(jù)文件已經(jīng)通過(guò) restic 重新灌入新恢復(fù)的 PV 中那業(yè)務(wù)一般能無(wú)縫拉起。4.4 整個(gè)集群與全量備份策略如果你想把整個(gè)集群的所有資源都備份起來(lái)需要更加謹(jǐn)慎。我先提醒一句全集群備份并備份 PVC 數(shù)據(jù)是代價(jià)最大的方案耗時(shí)和存儲(chǔ)成本都不可小覷所以不要?jiǎng)硬粍?dòng)就跑全量備份。Velero 默認(rèn)在velero backup create時(shí)如果不加任何篩選參數(shù)實(shí)際上就已經(jīng)備份了所有非系統(tǒng)命名空間的資源。但要注意它默認(rèn)不會(huì)備份velero、kube-system、kube-public、kube-node-lease這些系統(tǒng)級(jí)命名空間。這樣設(shè)計(jì)是合理的因?yàn)檫@些命名空間里的組件大多可以通過(guò)重建或重新安裝還原備份它們意義不大。設(shè)置了清理系統(tǒng)命名空間后如果需要做“全集群模擬恢復(fù)驗(yàn)證”可以用以下命令初始化一個(gè) full backup 作業(yè)把白名單和黑名單調(diào)整清楚velero backup create full-backup \ --exclude-namespaces kube-system,kube-public,kube-node-lease,velero \ --exclude-resources events,events.events.k8s.io \ --default-volumes-to-restic \ --ttl 336h0m0s排除了 events 的原因是事件數(shù)據(jù)通常量大且無(wú)恢復(fù)價(jià)值既浪費(fèi)時(shí)間又浪費(fèi)存儲(chǔ)空間。實(shí)際需求中你再結(jié)合是否要排除一些臨時(shí)緩存類資源根據(jù)業(yè)務(wù)情況調(diào)整。4.5 跨集群遷移Velero 的高階玩法Velero 備份文件存儲(chǔ)在對(duì)象存儲(chǔ)里這意味著它天然支持跨集群恢復(fù)。假如你有 A、B 兩個(gè)集群對(duì)象存儲(chǔ)是同一個(gè) MinIO那么在 A 集群做好備份后到 B 集群執(zhí)行一條恢復(fù)命令就能完成資源遷移。我在做環(huán)境遷移時(shí)常用一套組合拳A 集群創(chuàng)建備份B 集群配置相同的 BackupStorageLocation 和 credentials然后執(zhí)行恢復(fù)。步驟上你先要在 B 集群上安裝 Velero使用同樣的 MinIO 配置參數(shù)velero install \ --provider aws \ --plugins velero/velero-plugin-for-aws:v1.9.0 \ --bucket velero-backup \ --secret-file ./credentials-velero \ --backup-location-config regionminio,s3ForcePathStyletrue,s3Urlhttp://minio.velero.svc.cluster.local:9000 \ --snapshot-location-config regionminio \ --wait然后你要保證 B 集群能夠讀到一個(gè)備份名。執(zhí)行velero backup get看到 A 集群創(chuàng)建的那個(gè)備份名稱后直接執(zhí)行恢復(fù)即可。如果目標(biāo)集群中沒(méi)有對(duì)應(yīng)的 StorageClass 或不支持同樣的存儲(chǔ)協(xié)議PVC 可能會(huì)恢復(fù)失敗。此時(shí)可以通過(guò) Velero 的存儲(chǔ)類映射功能在恢復(fù)時(shí)把源存儲(chǔ)類替換為目標(biāo)集群的存儲(chǔ)類。5. 自動(dòng)化定時(shí)備份與恢復(fù)演練經(jīng)驗(yàn)手動(dòng)備份能保一時(shí)備份體系的真正價(jià)值在于自動(dòng)化。一個(gè)無(wú)法自動(dòng)運(yùn)行的備份機(jī)制最終一定會(huì)被日常工作節(jié)奏擠掉。5.1 使用 Velero Schedule 實(shí)現(xiàn)定時(shí)備份Velero 內(nèi)置了 Schedule 概念創(chuàng)建它之后Velero 會(huì)按照 Cron 表達(dá)式周期性地生成新的 Backup。它的最大優(yōu)點(diǎn)是把備份動(dòng)作納入了集群內(nèi)部狀態(tài)管理你隨時(shí)可以通過(guò) CRD 查看備份計(jì)劃。創(chuàng)建每日全量備份計(jì)劃保留 7 天命令如下velero schedule create daily-full-backup \ --schedule0 2 * * * \ --include-namespaces wordpress,default \ --default-volumes-to-restic \ --ttl 168h0m0s你可以用velero schedule get查看調(diào)度計(jì)劃狀態(tài)用velero backup get查看它自動(dòng)觸發(fā)的 Backup 是否成功。如果其中一個(gè) Backup 失敗了Schedule 會(huì)繼續(xù)保留并不會(huì)影響下一次觸發(fā)。這種解耦設(shè)計(jì)很實(shí)用至少我不會(huì)因?yàn)橐淮问《┑艉罄m(xù)備份。關(guān)于 Cron 表達(dá)式我建議結(jié)合業(yè)務(wù)低谷期來(lái)設(shè)置。如果集群和對(duì)象存儲(chǔ)都相對(duì)空閑凌晨 2 點(diǎn)到 4 點(diǎn)之間跑備份是比較通用的選擇。如果備份數(shù)據(jù)量很大可能單次執(zhí)行超過(guò) 30 分鐘你還要注意 Schedule 的時(shí)間窗口不能與下一次調(diào)度重疊否則會(huì)形成備份任務(wù)堆積。5.2 對(duì)象存儲(chǔ)側(cè)的備份生命周期管理備份文件生成之后對(duì)象存儲(chǔ)側(cè)同樣要有生命周期管理規(guī)則。MinIO 提供了生命周期配置可以為 bucket 配置過(guò)期刪除規(guī)則所以 Velero 里的--ttl并不是唯一的清理機(jī)制。我的建議是兩側(cè)都設(shè)但以 Velero 的 ttl 為主MinIO 生命周期為輔。假設(shè) Velero 設(shè)置了 7 天 TTLMinIO 生命周期規(guī)則設(shè)置為 10 天過(guò)期這樣能有效防止因 Velero 控制器異常導(dǎo)致備份文件無(wú)限堆積。配置 CapEx 時(shí)應(yīng)考慮到存儲(chǔ)成本不要把周期設(shè)得太長(zhǎng)也不要設(shè)得太短。比較穩(wěn)妥的做法是“本地 7 天 異地副本 30 天”這部分需要根據(jù)你公司對(duì)數(shù)據(jù)安全的要求調(diào)整。5.3 每季度做一次真實(shí)的恢復(fù)演練我沒(méi)見(jiàn)過(guò)哪個(gè)團(tuán)隊(duì)的備份策略是第一次就能做完美的。真正的分水嶺在于是否做了恢復(fù)演練而且不是演練一次就結(jié)束是每季度或半年固定做一次。我自己的做法是準(zhǔn)備一個(gè)獨(dú)立的演練集群這個(gè)集群規(guī)模不需要很大但安裝的 K8s 版本和插件配置盡量與生產(chǎn)一致。然后我每個(gè)月從對(duì)象存儲(chǔ)中隨機(jī)挑一個(gè)備份把資源恢復(fù)到演練集群再驗(yàn)證幾個(gè)核心業(yè)務(wù)是否能正常工作。曾有一次演練暴露過(guò)大問(wèn)題一切資源恢復(fù)成功但業(yè)務(wù)無(wú)法啟動(dòng)原因是 Secret 中的密碼在源集群里已經(jīng)輪換過(guò)而 ConfigMap 中引用的配置仍舊是舊值。如果沒(méi)做演練等真實(shí)災(zāi)難發(fā)生時(shí)這個(gè)問(wèn)題會(huì)變成生產(chǎn)事故的原因。所以我說(shuō)演練不是額外負(fù)擔(dān)它是備份體系中最有價(jià)值的一環(huán)。6. 常見(jiàn)故障與排查技巧備份恢復(fù)大概率不是一次就能順利跑通的。我把這兩年遇到的高頻問(wèn)題整理成了一張速查表供你定位問(wèn)題。癥狀可能原因解決方案etcdctl snapshot save 報(bào)證書(shū)錯(cuò)誤未正確加載 ETCDCTL_CERT / ETCDCTL_KEY 環(huán)境變量重新 source 環(huán)境變量文件檢查證書(shū)路徑etcd snapshot restore 后 apiserver 起不來(lái)數(shù)據(jù)目錄權(quán)限不對(duì)或新舊集群 token 不一致確認(rèn)/var/lib/etcd屬主為 etcd 用戶檢查 apiserver 日志Velero backup 狀態(tài)一直停留在 NewBackupStorageLocation 無(wú)效或插件版本不匹配查看 velero 日志檢查存儲(chǔ)桶是否可訪問(wèn)Velero 備份完成但恢復(fù)后 PVC 為空沒(méi)有啟用 restic / 卷快照被顯式關(guān)閉恢復(fù)動(dòng)作加上--default-volumes-to-restic并確認(rèn) restic Pod 運(yùn)行恢復(fù)時(shí)提示 storageclass 不存在目標(biāo)集群缺少源集群的 StorageClass創(chuàng)建同名 StorageClass或用--storage-class-mapping參數(shù)做替換定時(shí)備份連續(xù)失敗但你完全沒(méi)發(fā)現(xiàn)缺少失敗告警機(jī)制為 Velero 配置監(jiān)控告警或檢查日志工具備份文件在 MinIO 中被誤刪bucket 沒(méi)有開(kāi)啟版本控制開(kāi)啟 bucket 版本控制并配置生命周期規(guī)則除了表格里的問(wèn)題我再補(bǔ)充三個(gè)比較隱秘但很重要的經(jīng)驗(yàn)。第一Velero 備份過(guò)程中如果集群正在發(fā)生大量資源變更可能出現(xiàn)部分資源處于中間狀態(tài)導(dǎo)致恢復(fù)回來(lái)后資源版本沖突或字段不完整。對(duì)于核心數(shù)據(jù)庫(kù)這類服務(wù)我建議備份前先將應(yīng)用置于只讀或停寫(xiě)狀態(tài)至少也要接受 PVC 數(shù)據(jù)本身的一致性由應(yīng)用層保證。第二restic 備份模式對(duì) PVC 數(shù)據(jù)的備份速度較慢。如果 PVC 體積達(dá)到 TB 級(jí)別全量備份耗時(shí)可能數(shù)小時(shí)。這時(shí)候需要考慮文件系統(tǒng)層面的定期快照比如云廠商磁盤快照或數(shù)據(jù)庫(kù)自身備份工具而不是一味依賴 Velero 的每個(gè)卷備份。第三恢復(fù)時(shí)注意資源間的依賴順序。Velero 會(huì)盡力做依賴排序但有些自定義資源需要先創(chuàng)建 CRD再創(chuàng)建 CRD 實(shí)例。如果恢復(fù)后自定義資源沒(méi)有正常出現(xiàn)優(yōu)先檢查 CRD 是否已經(jīng)注冊(cè)必要時(shí)手動(dòng)應(yīng)用 CRD 定義。還有一個(gè)小技巧恢復(fù)前把目標(biāo)集群的命名空間先清空或者使用一個(gè)新的命名空間做恢復(fù)驗(yàn)證避免與現(xiàn)有資源產(chǎn)生沖突。這個(gè)操作能幫你把問(wèn)題邊界縮小少在環(huán)境干擾上浪費(fèi)時(shí)間。說(shuō)一個(gè)我印象最深的教訓(xùn)。某次我把 etcd 快照恢復(fù)做完了節(jié)點(diǎn)全部 ReadyPod 也全部 Running表面上一切完美。結(jié)果第二天業(yè)務(wù)反饋數(shù)據(jù)缺失一查發(fā)現(xiàn)備份時(shí)間點(diǎn)在業(yè)務(wù)高峰期前一小時(shí)隨后一小時(shí)內(nèi)的寫(xiě)入全部丟掉了。從此以后我在設(shè)計(jì)備份策略時(shí)都會(huì)先問(wèn)一句業(yè)務(wù)能否接受這個(gè) RPO如果能承受小時(shí)級(jí)丟失則每日備份足夠如果不能那就需要借助數(shù)據(jù)庫(kù)層的 binlog 同步或存儲(chǔ)層的實(shí)時(shí)快照來(lái)縮短丟失窗口。備份恢復(fù)這件事看起來(lái)只是幾條命令但真正把它做扎實(shí)需要你對(duì)集群的部署形態(tài)、業(yè)務(wù)的數(shù)據(jù)特性、存儲(chǔ)后端的接口能力都有清晰認(rèn)知。希望這篇基于配置與實(shí)踐的梳理能讓你在構(gòu)建自己的備份方案時(shí)少走一些彎路。下一次遇到故障時(shí)希望你想到的不是后悔沒(méi)備份而是從容地執(zhí)行演練過(guò)無(wú)數(shù)遍的恢復(fù)流程。 Kubernetes集群備份與恢復(fù)實(shí)戰(zhàn)：etcd快照與Velero雙保險(xiǎn)方案
自打開(kāi)始正經(jīng)維護(hù) Kubernetes 集群之后我?guī)缀趺刻於紩?huì)被同一個(gè)問(wèn)題敲打如果哪天 etcd 數(shù)據(jù)盤壞了、誤刪了一個(gè) namespace或者整臺(tái) Master 節(jié)點(diǎn)被清空你到底能不能把集群拉回來(lái)我相信絕大多數(shù)人的第一反應(yīng)是有資源清單啊丟了重建不就行了。但真正經(jīng)歷過(guò)故障的人會(huì)明白這種想法在單機(jī)實(shí)驗(yàn)環(huán)境勉強(qiáng)成立放到生產(chǎn)環(huán)境里基本等于裸奔。因?yàn)榧豪锍?Deployment、Service 這些能kubectl get出來(lái)的對(duì)象還有大量的配置、密鑰、PVC 里的業(yè)務(wù)數(shù)據(jù)、CRD 資源、RBAC 授權(quán)關(guān)系這些東西一旦丟失想靠人工重建幾乎是不可能完成的任務(wù)。這篇博客就圍繞 Kubernetes 集群備份與恢復(fù)的完整配置與實(shí)踐展開(kāi)。我會(huì)從備份思路講起逐步拆解 etcd 快照和 Velero 這兩套主流方案把命令、參數(shù)、常見(jiàn)坑、恢復(fù)演練的步驟全部攤開(kāi)講。不管你是在自己搭的測(cè)試集群上做實(shí)驗(yàn)還是正在為生產(chǎn)集群設(shè)計(jì)容災(zāi)方案這篇內(nèi)容都能幫你在腦子里建立起一套清晰的備份恢復(fù)框架。先說(shuō)明一點(diǎn)本文所有操作都基于我實(shí)際在用的集群環(huán)境驗(yàn)證過(guò)但版本差異會(huì)帶來(lái)細(xì)節(jié)上的變化閱讀時(shí)請(qǐng)結(jié)合你自己的集群版本做微調(diào)。1. 備份前先把思路理清楚到底要備份什么在動(dòng)手配置任何工具之前我建議你先完成一輪“靈魂拷問(wèn)”。因?yàn)閭浞莘桨傅脑O(shè)計(jì)本質(zhì)上是對(duì)集群資產(chǎn)做分類分類做不清楚后面所有備份動(dòng)作都是盲目的。1.1 先問(wèn)自己三個(gè)關(guān)鍵問(wèn)題第一個(gè)問(wèn)題如果集群徹底無(wú)法恢復(fù)你能否在 24 小時(shí)內(nèi)重建出所有業(yè)務(wù)這里說(shuō)的業(yè)務(wù)不只是工作負(fù)載還包括它依賴的配置中心數(shù)據(jù)、數(shù)據(jù)庫(kù)內(nèi)容、消息隊(duì)列里的積壓消息、對(duì)象存儲(chǔ)桶以及 K8s 集群中的各種自定義資源。第二個(gè)問(wèn)題你的備份是否被人為驗(yàn)證過(guò)備份文件存在那里沒(méi)有任何意義只有定期做恢復(fù)演練、并且演練成功過(guò)備份才算真正有效。第三個(gè)問(wèn)題萬(wàn)一發(fā)生誤刪操作你允許的數(shù)據(jù)丟失時(shí)間窗口是多久這個(gè) RPORecovery Point Objective直接決定了你的備份頻率和備份方式。我把這些問(wèn)題拿出來(lái)說(shuō)是因?yàn)槲乙?jiàn)過(guò)太多人把備份等同于“對(duì) etcd 做一個(gè)快照”。實(shí)際上etcd 快照只覆蓋 Kubernetes 控制面存儲(chǔ)的狀態(tài)它根本不包含業(yè)務(wù)容器寫(xiě)入 PV 的數(shù)據(jù)。如果你跑的是 MySQL、Redis 這類有狀態(tài)服務(wù)PV 數(shù)據(jù)丟了etcd 再完整也只能幫你恢復(fù)出一個(gè)空殼數(shù)據(jù)庫(kù)。1.2 把資產(chǎn)拆成三個(gè)層次來(lái)看待我習(xí)慣把一個(gè)集群需要保護(hù)的資產(chǎn)分成三個(gè)層次。第一層是集群狀態(tài)層對(duì)應(yīng) etcd 中保存的幾乎所有 Kubernetes 對(duì)象包括 Deployment、Service、ConfigMap、Secret、Namespace、RBAC 規(guī)則、CRD 實(shí)例等。這一層的特點(diǎn)是數(shù)據(jù)量通常不大但變化極其頻繁任何一次kubectl apply都會(huì)改動(dòng)它。第二層是持久化數(shù)據(jù)層也就是 PV/PVC 背后真正存儲(chǔ)的業(yè)務(wù)文件、數(shù)據(jù)庫(kù)文件這一層通常由云盤、NFS、Ceph 等外部存儲(chǔ)系統(tǒng)承載Kubernetes 自身并不知道里面裝了什么。第三層是外部依賴層比如鏡像倉(cāng)庫(kù)里的鏡像、Helm Chart 倉(cāng)庫(kù)、GitOps 倉(cāng)庫(kù)里的部署清單這些資源往往不在集群內(nèi)卻是重建集群時(shí)必不可少的輸入。有了這三層視角之后你的備份策略就非常清晰了集群狀態(tài)層用 etcd 快照解決持久化數(shù)據(jù)層用 Velero 這類工具配合存儲(chǔ)驅(qū)動(dòng)解決外部依賴層則靠日常的版本管理和倉(cāng)庫(kù)鏡像同步解決。三者缺一不可。1.3 方案選型etcd 快照與 Velero 并不沖突我經(jīng)常在社區(qū)里看到有人爭(zhēng)論“備份到底該用 etcd 快照還是 Velero”這個(gè)問(wèn)題本身就問(wèn)錯(cuò)了。這兩種工具解決的不是同一個(gè)問(wèn)題放在一起使用才是一套完整的方案。etcd 快照負(fù)責(zé)兜底適合應(yīng)對(duì)集群級(jí)災(zāi)難比如 Master 節(jié)點(diǎn)不可用、etcd 數(shù)據(jù)全部損壞、誤刪了整個(gè) Namespace 且資源無(wú)法重建。Velero 負(fù)責(zé)精細(xì)化和應(yīng)用級(jí)備份適合做資源遷移、版本回滾、按命名空間恢復(fù)還能借助 restic 或 Kopia 備份 PV 數(shù)據(jù)。如果你的集群所有數(shù)據(jù)都有外部備份并且一切皆代碼那你可以只依賴 GitOps 方式重建但大多數(shù)團(tuán)隊(duì)還沒(méi)做到這個(gè)程度因此快照依然是必需品?？吹竭@里你基本明白了我不是讓你二選一而是建議你用“雙保險(xiǎn)”思路搭建備份體系。后面幾節(jié)我會(huì)把兩條路線都走一遍你可以直接照抄配置。2. 動(dòng)手前的環(huán)境準(zhǔn)備與配置項(xiàng)梳理不管用 etcd 快照還是 Velero集群本身需要滿足一些最基本的條件。這一節(jié)先把環(huán)境準(zhǔn)備和核心配置項(xiàng)講清楚避免后面實(shí)操時(shí)卡在一些莫名其妙的地方。2.1 確認(rèn)集群部署方式與 etcd 形態(tài)首先要確認(rèn)你的 etcd 是怎么部署的。不同集群形態(tài)會(huì)導(dǎo)致 etcd 的訪問(wèn)方式完全不同這一點(diǎn)是新手最容易栽跟頭的地方。kubeadm 部署的集群etcd 以靜態(tài) Pod 方式運(yùn)行在 Master 節(jié)點(diǎn)上通過(guò)/etc/kubernetes/manifests/etcd.yaml定義證書(shū)和配置集中在/etc/kubernetes/pki/etcd/目錄。二進(jìn)制方式部署的集群etcd 通常以 systemd 服務(wù)運(yùn)行數(shù)據(jù)目錄、證書(shū)路徑、監(jiān)聽(tīng)地址全部由你自定義快照時(shí)需要手動(dòng)拼接參數(shù)。云廠商托管的集群如 EKS、ACK、TKE控制面 etcd 基本由云廠商管理用戶無(wú)法直接接觸此時(shí)你更需要依賴 Velero 或云廠商自帶的集群快照能力做應(yīng)用級(jí)備份。定位好你自己的集群形態(tài)后面的命令才能跑通。我下面的實(shí)踐示例基于 kubeadm 部署的集群來(lái)展開(kāi)這也是社區(qū)里最常見(jiàn)的自建集群方式。2.2 為備份賬號(hào)準(zhǔn)備必要的權(quán)限配置如果你要用 Velero它需要一個(gè)專用的服務(wù)賬號(hào)并且這個(gè)賬號(hào)需要有足夠權(quán)限讀取集群中的所有資源。Velero 安裝時(shí)默認(rèn)會(huì)創(chuàng)建velero命名空間并部署一組 RBAC 規(guī)則正常情況下不用手動(dòng)造輪子。但有一點(diǎn)容易忽略當(dāng)你計(jì)劃備份自定義資源CRD時(shí)需要確保 Velero 的服務(wù)賬號(hào)對(duì)相關(guān) CRD 有 get、list、watch 權(quán)限。如果某天你發(fā)現(xiàn)備份任務(wù)顯示成功但恢復(fù)后 CRD 實(shí)例丟了優(yōu)先檢查是不是權(quán)限不足導(dǎo)致 Velero 無(wú)法枚舉資源。這里給出一個(gè)排查用的最小 RBAC 配置它授予了備份操作所需的粗粒度權(quán)限。如果你對(duì)安全要求比較高建議按需收縮到具體資源apiVersion: v1 kind: ServiceAccount metadata: name: velero namespace: velero --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: velero-admin roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: velero namespace: velero這個(gè)配置看起來(lái)比較粗暴但它能保證 Velero 不會(huì)因?yàn)闄?quán)限問(wèn)題而跳過(guò)資源。生產(chǎn)環(huán)境建議結(jié)合 Velero 官方文檔中的 RBAC 模板做進(jìn)一步裁剪。2.3 準(zhǔn)備一套獨(dú)立的對(duì)象存儲(chǔ)用于存放備份Velero 的備份文件需要落到對(duì)象存儲(chǔ)中。如果你已經(jīng)在用 AWS S3、阿里云 OSS、MinIO 這類兼容 S3 協(xié)議的服務(wù)那可以直接復(fù)用。如果還沒(méi)有我強(qiáng)烈建議你在內(nèi)網(wǎng)部署一個(gè) MinIO專門用于存放備份。它的部署非常簡(jiǎn)單單機(jī)版用 Docker 幾分鐘就能跑起來(lái)。用 MinIO 主要是為了兩個(gè)目的一是讓備份文件集中管理不會(huì)被隨意清理二是 Velero 官方對(duì) S3 API 的兼容性很好選它省去很多兼容性適配的麻煩。存儲(chǔ)桶創(chuàng)建好后記錄下 endpoint 地址、access key、secret key后面配置 Velero 時(shí)要用到。下面是我的 MinIO 初始化命令示例實(shí)際使用時(shí)請(qǐng)?zhí)鎿Q成你自己的賬號(hào)密碼docker run -d \ --name minio \ -p 9000:9000 \ -p 9001:9001 \ -e MINIO_ROOT_USERvelero_backup \ -e MINIO_ROOT_PASSWORDYourStrongPass2026 \ -v /data/minio:/data \ minio/minio server /data --console-address :9001啟動(dòng)后到控制臺(tái)創(chuàng)建一個(gè)名為velero-backup的 bucket并且建議開(kāi)啟版本控制。原因很簡(jiǎn)單版本控制能防止備份對(duì)象被誤刪或覆蓋相當(dāng)于給備份又加了一層保險(xiǎn)。3. etcd 快照備份與恢復(fù)的完整實(shí)踐etcd 快照是整個(gè)集群備份體系的第一塊基石也是恢復(fù)集群控制面數(shù)據(jù)的終極手段。我不敢說(shuō)它難但操作過(guò)程中稍有不慎就會(huì)造成數(shù)據(jù)不一致所以接下來(lái)我會(huì)把每一步拆得很細(xì)。3.1 配置 etcd 客戶端證書(shū)環(huán)境變量使用etcdctl做快照通常需要 TLS 證書(shū)認(rèn)證。kubeadm 部署的集群中etcd 證書(shū)位于 Master 節(jié)點(diǎn)的/etc/kubernetes/pki/etcd/目錄你需要在執(zhí)行命令前導(dǎo)出環(huán)境變量否則會(huì)提示證書(shū)校驗(yàn)失敗。我的做法是先把以下內(nèi)容寫(xiě)到/etc/profile.d/etcdctl.sh中簡(jiǎn)化后續(xù)操作export ETCDCTL_API3 export ETCDCTL_CACERT/etc/kubernetes/pki/etcd/ca.crt export ETCDCTL_CERT/etc/kubernetes/pki/etcd/server.crt export ETCDCTL_KEY/etc/kubernetes/pki/etcd/server.key export ETCDCTL_ENDPOINTShttps://127.0.0.1:2379關(guān)于證書(shū)文件有一個(gè)細(xì)節(jié)值得說(shuō)明server.crt和server.key是 etcd 服務(wù)端證書(shū)用于 etcd 各成員之間通信同時(shí)也被 etcdctl 作為客戶端證書(shū)使用。如果你在某個(gè)節(jié)點(diǎn)上找不到server.*文件也可以嘗試用peer.crt和peer.key替代但首選仍是 server 證書(shū)。執(zhí)行source /etc/profile.d/etcdctl.sh后可用一條簡(jiǎn)單的etcdctl endpoint health命令驗(yàn)證連接是否正常。3.2 執(zhí)行手動(dòng)快照與定時(shí)備份完成認(rèn)證配置后做一次手動(dòng)快照就非常簡(jiǎn)單了mkdir -p /backup/etcd etcdctl snapshot save /backup/etcd/snapshot-$(date %Y%m%d-%H%M%S).db執(zhí)行成功后會(huì)輸出類似Snapshot saved at /backup/etcd/snapshot-xxxx.db的信息。此時(shí)你可以用校驗(yàn)命令確認(rèn)快照文件沒(méi)有損壞etcdctl snapshot status /backup/etcd/snapshot-xxxx.db該命令會(huì)返回快照的版本、數(shù)據(jù)大小、hash 值等信息。我每次做完快照都會(huì)順手跑一次這條命令它雖然不能百分百保證恢復(fù)成功但至少能從哈希層面排除文件在落盤過(guò)程中出現(xiàn)損壞的可能。手動(dòng)快照只能救急不能作為常態(tài)化機(jī)制。更合理的做法是寫(xiě)一個(gè)定時(shí)任務(wù)腳本每天在業(yè)務(wù)低峰期自動(dòng)執(zhí)行快照并清理三天前的舊文件。下面是我實(shí)際在用的腳本你拿走改成自己的備份目錄就能用#!/bin/bash BACKUP_DIR/backup/etcd RETENTION_DAYS3 source /etc/profile.d/etcdctl.sh mkdir -p ${BACKUP_DIR} etcdctl snapshot save ${BACKUP_DIR}/snapshot-$(date %Y%m%d-%H%M%S).db find ${BACKUP_DIR} -name snapshot-*.db -mtime ${RETENTION_DAYS} -exec rm -f {} \;用crontab -e添加定時(shí)任務(wù)以每天凌晨 2 點(diǎn)執(zhí)行為例0 2 * * * /opt/scripts/etcd-backup.sh /var/log/etcd-backup.log 21關(guān)于快照保留周期我建議根據(jù)自己的數(shù)據(jù)量決定。etcd 快照文件一般不會(huì)很大幾百 MB 到幾個(gè) GB 都很常見(jiàn)所以你完全可以把保留周期設(shè)置得長(zhǎng)一些比如保留 7 份每日快照外加每周快照。丟失數(shù)據(jù)這件事寧可多留不可少留。3.3 恢復(fù)實(shí)操?gòu)目煺者€原到單機(jī)集群恢復(fù) etcd 是整個(gè)集群恢復(fù)流程中最容易手忙腳亂的部分因?yàn)槟阈枰岩粋€(gè)“已經(jīng)存在的故障集群”先停下來(lái)再手動(dòng)去重建數(shù)據(jù)目錄。這里強(qiáng)調(diào)一下恢復(fù)操作必須在所有 etcd 節(jié)點(diǎn)上協(xié)調(diào)進(jìn)行不建議只對(duì)單節(jié)點(diǎn)操作而讓其他節(jié)點(diǎn)繼續(xù)運(yùn)行。下面以單節(jié)點(diǎn) etcd 為例展開(kāi)。第一步停掉 kube-apiserver 和 etcd。如果是靜態(tài) Pod 方式部署最直接的做法是把/etc/kubernetes/manifests/下的etcd.yaml移走并用kubelet的靜態(tài) Pod 機(jī)制讓它自動(dòng)停掉。但更穩(wěn)妥的順序是先把 apiserver 停掉避免 apiserver 在 etcd 恢復(fù)期間不斷寫(xiě)入數(shù)據(jù)導(dǎo)致快照還原后的數(shù)據(jù)被再次污染。mv /etc/kubernetes/manifests/etcd.yaml /root/backup-manifests/ mv /etc/kubernetes/manifests/kube-apiserver.yaml /root/backup-manifests/ sleep 30第二步備份并清空舊的 etcd 數(shù)據(jù)目錄。默認(rèn)數(shù)據(jù)目錄是/var/lib/etcd我建議先把它整個(gè)移動(dòng)到一個(gè)備份位置而不是直接刪除防止恢復(fù)失敗時(shí)還有后悔藥可吃mv /var/lib/etcd /var/lib/etcd.bak.$(date %Y%m%d)第三步用快照文件恢復(fù)數(shù)據(jù)目錄。etcdctl 的snapshot restore命令會(huì)生成一個(gè)新的數(shù)據(jù)目錄你需要通過(guò)--data-dir參數(shù)指定位置并傳入與舊集群一致的名稱和證書(shū)參數(shù)etcdctl snapshot restore /backup/etcd/snapshot-xxxx.db \ --name etcd-1 \ --initial-cluster etcd-1https://127.0.0.1:2380 \ --initial-cluster-token etcd-cluster \ --initial-advertise-peer-urls https://127.0.0.1:2380 \ --data-dir /var/lib/etcd這里有一個(gè)關(guān)鍵點(diǎn)--initial-cluster-token的值必須和原來(lái)的集群保持一致或者干脆隨意指定一個(gè)全新值。后者其實(shí)更常見(jiàn)因?yàn)槟阍谧龌謴?fù)時(shí)通常是想啟動(dòng)一個(gè)全新的 etcd 數(shù)據(jù)實(shí)例。但如果你希望恢復(fù)后的 etcd 能重新加入原有集群拓?fù)淠蔷捅仨毐３?peer URL 與集群配置一致否則其他節(jié)點(diǎn)會(huì)認(rèn)為這是一個(gè)陌生成員。第四步把etcd.yaml和kube-apiserver.yaml移回靜態(tài) Pod 目錄等待 kubelet 自動(dòng)拉起 etcd 和 apiservermv /root/backup-manifests/etcd.yaml /etc/kubernetes/manifests/ mv /root/backup-manifests/kube-apiserver.yaml /etc/kubernetes/manifests/ sleep 60最后驗(yàn)證集群狀態(tài)kubectl get nodes kubectl get pods -A如果看到 Node 狀態(tài)正常、之前的資源都回來(lái)了說(shuō)明恢復(fù)成功。如果 apiserver 啟動(dòng)失敗先去看 kubelet 日志和 etcd 日志絕大多數(shù)問(wèn)題出在證書(shū)路徑不匹配或數(shù)據(jù)目錄權(quán)限不對(duì)上。3.4 恢復(fù)操作中的風(fēng)險(xiǎn)控制與注意事項(xiàng)關(guān)于 etcd 恢復(fù)我吃過(guò)不少虧挑幾個(gè)最典型的提醒一下。第一恢復(fù)操作前必須停止所有寫(xiě)入方。不只是 kube-apiserver如果集群里還有其他組件直接通過(guò) etcd 客戶端接口讀寫(xiě)數(shù)據(jù)比如某些定制 Operator也要一并停止。否則很可能出現(xiàn)恢復(fù)后一部分舊數(shù)據(jù)被新數(shù)據(jù)覆蓋或沖突的情況表現(xiàn)為資源狀態(tài)詭異、對(duì)象反復(fù)重建。第二不要在生產(chǎn)集群上邊跑業(yè)務(wù)邊恢復(fù)。即便恢復(fù)的是單節(jié)點(diǎn) etcd也強(qiáng)烈建議先摘掉業(yè)務(wù)流量因?yàn)榛謴?fù)過(guò)程中 kubelet 可能會(huì)根據(jù)舊數(shù)據(jù)重新創(chuàng)建 Pod造成未知影響。第三etcd 快照不保證包含最近幾秒的寫(xiě)入。etcd 的 snapshot 是某一時(shí)間點(diǎn)的存儲(chǔ)狀態(tài)自快照時(shí)間點(diǎn)之后發(fā)生的變更都會(huì)丟失。這決定了你的 RPO 不可能為零如果你的業(yè)務(wù)對(duì)數(shù)據(jù)極其敏感需要在上層做更細(xì)粒度的備份或同步。4. Velero 應(yīng)用級(jí)備份與恢復(fù)實(shí)操etcd 快照能保住控制面但它無(wú)法備份 PVC 里的數(shù)據(jù)。所以當(dāng)業(yè)務(wù)真正跑起來(lái)之后它用的數(shù)據(jù)庫(kù)文件、上傳的文件、生成的臨時(shí)數(shù)據(jù)全都在 PV 里面這時(shí)候必須請(qǐng)出 Velero。4.1 Velero 的核心架構(gòu)與備份原理Velero 的工作機(jī)制可以簡(jiǎn)單概括為兩部分一方面通過(guò) Kubernetes API 讀取集群中的資源對(duì)象打包后上傳到對(duì)象存儲(chǔ)另一方面通過(guò)文件系統(tǒng)備份組件如 restic 或 Kopia讀取 PVC 掛載的數(shù)據(jù)卷內(nèi)容將其一并上傳。它不需要在集群里安裝特權(quán) DaemonSet 之外的 agent備份動(dòng)作由 Velero Server 組件部署在集群內(nèi)和 Velero CLI 客戶端協(xié)同完成。CLI 下發(fā)備份指令后Velero Server 會(huì)在集群中創(chuàng)建 Backup 資源隨后 Backup Controller 負(fù)責(zé)執(zhí)行具體任務(wù)。你在使用過(guò)程中會(huì)經(jīng)?？吹?Backup、Restore、Schedule、BackupStorageLocation 這幾類 CRD它們都是 Velero 的核心抽象。理解它們的層級(jí)關(guān)系對(duì)排查問(wèn)題很有幫助BackupStorageLocation 定義備份文件存放位置Schedule 定義周期巡檢任務(wù)Backup 是一次具體備份動(dòng)作的記錄Restore 是一次恢復(fù)動(dòng)作的記錄?？慈罩緯r(shí)只需要找到對(duì)應(yīng) Backup 或 Restore 資源然后通過(guò)velero backup logs name查看詳細(xì)日志即可。4.2 安裝 Velero 并配置對(duì)象存儲(chǔ)安裝 Velero 的工具本身并不復(fù)雜核心是把云廠商存儲(chǔ)的訪問(wèn)憑證準(zhǔn)備好。以 MinIO 為例首先創(chuàng)建一個(gè)包含訪問(wèn)密鑰的文件cat credentials-velero EOF [default] aws_access_key_id velero_backup aws_secret_access_key YourStrongPass2026 EOF然后執(zhí)行安裝命令velero install \ --provider aws \ --plugins velero/velero-plugin-for-aws:v1.9.0 \ --bucket velero-backup \ --secret-file ./credentials-velero \ --backup-location-config regionminio,s3ForcePathStyletrue,s3Urlhttp://minio.velero.svc.cluster.local:9000 \ --snapshot-location-config regionminio \ --use-restic \ --use-volume-snapshotsfalse \ --wait拆解一下這條命令中幾個(gè)容易出錯(cuò)的參數(shù)--provider aws這里不是說(shuō)你必須用 AWS而是 Velero 用 AWS S3 兼容協(xié)議去對(duì)接對(duì)象存儲(chǔ)MinIO、OSS、COS 都支持這種協(xié)議。--plugins velero/velero-plugin-for-aws:v1.9.0插件版本要和 Velero 主版本接近否則可能出現(xiàn) API 不兼容的問(wèn)題。s3ForcePathStyletrueMinIO 這類私有對(duì)象存儲(chǔ)要求路徑風(fēng)格 URL不加這個(gè)參數(shù)會(huì)導(dǎo)致 Velero 無(wú)法找到桶。--use-restic啟用文件系統(tǒng)備份能力用來(lái)備份 PVC 數(shù)據(jù)。--use-volume-snapshotsfalse如果存儲(chǔ)后端沒(méi)有實(shí)現(xiàn) CSI 快照能力就關(guān)掉卷快照功能避免 Velero 一直嘗試調(diào)用不存在的快照接口。安裝完成后查看 velero 命名空間下的 Pod 狀態(tài)確保velero和restic相關(guān) Pod 都正常運(yùn)行kubectl get pods -n velero4.3 按命名空間備份先從小范圍開(kāi)始Velero 上手最好的方式不是一上來(lái)就全集群備份而是先挑一個(gè)測(cè)試命名空間做驗(yàn)證。比如我需要備份wordpress命名空間下的所有資源以及 PVC 數(shù)據(jù)可以執(zhí)行velero backup create wordpress-backup \ --include-namespaces wordpress \ --default-volumes-to-restic \ --ttl 168h0m0s參數(shù)說(shuō)明--include-namespaces只備份指定命名空間。--default-volumes-to-restic對(duì) PVC 數(shù)據(jù)啟用 restic 備份。--ttl備份文件在對(duì)象存儲(chǔ)中的保留時(shí)間這里設(shè)置了 7 天。執(zhí)行后可能會(huì)等待一段時(shí)間你可以用velero backup get查看狀態(tài)從 New 變成 Completed 就說(shuō)明備份成功了。然后模擬一次災(zāi)難直接刪掉wordpress命名空間kubectl delete namespace wordpress等命名空間完全清理干凈后執(zhí)行恢復(fù)velero restore create --from-backup wordpress-backup恢復(fù)完成后進(jìn)入命名空間檢查資源確認(rèn) Pod、PVC、Service、Ingress 都回來(lái)了。如果 PVC 里的數(shù)據(jù)文件已經(jīng)通過(guò) restic 重新灌入新恢復(fù)的 PV 中那業(yè)務(wù)一般能無(wú)縫拉起。4.4 整個(gè)集群與全量備份策略如果你想把整個(gè)集群的所有資源都備份起來(lái)需要更加謹(jǐn)慎。我先提醒一句全集群備份并備份 PVC 數(shù)據(jù)是代價(jià)最大的方案耗時(shí)和存儲(chǔ)成本都不可小覷所以不要?jiǎng)硬粍?dòng)就跑全量備份。Velero 默認(rèn)在velero backup create時(shí)如果不加任何篩選參數(shù)實(shí)際上就已經(jīng)備份了所有非系統(tǒng)命名空間的資源。但要注意它默認(rèn)不會(huì)備份velero、kube-system、kube-public、kube-node-lease這些系統(tǒng)級(jí)命名空間。這樣設(shè)計(jì)是合理的因?yàn)檫@些命名空間里的組件大多可以通過(guò)重建或重新安裝還原備份它們意義不大。設(shè)置了清理系統(tǒng)命名空間后如果需要做“全集群模擬恢復(fù)驗(yàn)證”可以用以下命令初始化一個(gè) full backup 作業(yè)把白名單和黑名單調(diào)整清楚velero backup create full-backup \ --exclude-namespaces kube-system,kube-public,kube-node-lease,velero \ --exclude-resources events,events.events.k8s.io \ --default-volumes-to-restic \ --ttl 336h0m0s排除了 events 的原因是事件數(shù)據(jù)通常量大且無(wú)恢復(fù)價(jià)值既浪費(fèi)時(shí)間又浪費(fèi)存儲(chǔ)空間。實(shí)際需求中你再結(jié)合是否要排除一些臨時(shí)緩存類資源根據(jù)業(yè)務(wù)情況調(diào)整。4.5 跨集群遷移Velero 的高階玩法Velero 備份文件存儲(chǔ)在對(duì)象存儲(chǔ)里這意味著它天然支持跨集群恢復(fù)。假如你有 A、B 兩個(gè)集群對(duì)象存儲(chǔ)是同一個(gè) MinIO那么在 A 集群做好備份后到 B 集群執(zhí)行一條恢復(fù)命令就能完成資源遷移。我在做環(huán)境遷移時(shí)常用一套組合拳A 集群創(chuàng)建備份B 集群配置相同的 BackupStorageLocation 和 credentials然后執(zhí)行恢復(fù)。步驟上你先要在 B 集群上安裝 Velero使用同樣的 MinIO 配置參數(shù)velero install \ --provider aws \ --plugins velero/velero-plugin-for-aws:v1.9.0 \ --bucket velero-backup \ --secret-file ./credentials-velero \ --backup-location-config regionminio,s3ForcePathStyletrue,s3Urlhttp://minio.velero.svc.cluster.local:9000 \ --snapshot-location-config regionminio \ --wait然后你要保證 B 集群能夠讀到一個(gè)備份名。執(zhí)行velero backup get看到 A 集群創(chuàng)建的那個(gè)備份名稱后直接執(zhí)行恢復(fù)即可。如果目標(biāo)集群中沒(méi)有對(duì)應(yīng)的 StorageClass 或不支持同樣的存儲(chǔ)協(xié)議PVC 可能會(huì)恢復(fù)失敗。此時(shí)可以通過(guò) Velero 的存儲(chǔ)類映射功能在恢復(fù)時(shí)把源存儲(chǔ)類替換為目標(biāo)集群的存儲(chǔ)類。5. 自動(dòng)化定時(shí)備份與恢復(fù)演練經(jīng)驗(yàn)手動(dòng)備份能保一時(shí)備份體系的真正價(jià)值在于自動(dòng)化。一個(gè)無(wú)法自動(dòng)運(yùn)行的備份機(jī)制最終一定會(huì)被日常工作節(jié)奏擠掉。5.1 使用 Velero Schedule 實(shí)現(xiàn)定時(shí)備份Velero 內(nèi)置了 Schedule 概念創(chuàng)建它之后Velero 會(huì)按照 Cron 表達(dá)式周期性地生成新的 Backup。它的最大優(yōu)點(diǎn)是把備份動(dòng)作納入了集群內(nèi)部狀態(tài)管理你隨時(shí)可以通過(guò) CRD 查看備份計(jì)劃。創(chuàng)建每日全量備份計(jì)劃保留 7 天命令如下velero schedule create daily-full-backup \ --schedule0 2 * * * \ --include-namespaces wordpress,default \ --default-volumes-to-restic \ --ttl 168h0m0s你可以用velero schedule get查看調(diào)度計(jì)劃狀態(tài)用velero backup get查看它自動(dòng)觸發(fā)的 Backup 是否成功。如果其中一個(gè) Backup 失敗了Schedule 會(huì)繼續(xù)保留并不會(huì)影響下一次觸發(fā)。這種解耦設(shè)計(jì)很實(shí)用至少我不會(huì)因?yàn)橐淮问《┑艉罄m(xù)備份。關(guān)于 Cron 表達(dá)式我建議結(jié)合業(yè)務(wù)低谷期來(lái)設(shè)置。如果集群和對(duì)象存儲(chǔ)都相對(duì)空閑凌晨 2 點(diǎn)到 4 點(diǎn)之間跑備份是比較通用的選擇。如果備份數(shù)據(jù)量很大可能單次執(zhí)行超過(guò) 30 分鐘你還要注意 Schedule 的時(shí)間窗口不能與下一次調(diào)度重疊否則會(huì)形成備份任務(wù)堆積。5.2 對(duì)象存儲(chǔ)側(cè)的備份生命周期管理備份文件生成之后對(duì)象存儲(chǔ)側(cè)同樣要有生命周期管理規(guī)則。MinIO 提供了生命周期配置可以為 bucket 配置過(guò)期刪除規(guī)則所以 Velero 里的--ttl并不是唯一的清理機(jī)制。我的建議是兩側(cè)都設(shè)但以 Velero 的 ttl 為主MinIO 生命周期為輔。假設(shè) Velero 設(shè)置了 7 天 TTLMinIO 生命周期規(guī)則設(shè)置為 10 天過(guò)期這樣能有效防止因 Velero 控制器異常導(dǎo)致備份文件無(wú)限堆積。配置 CapEx 時(shí)應(yīng)考慮到存儲(chǔ)成本不要把周期設(shè)得太長(zhǎng)也不要設(shè)得太短。比較穩(wěn)妥的做法是“本地 7 天 異地副本 30 天”這部分需要根據(jù)你公司對(duì)數(shù)據(jù)安全的要求調(diào)整。5.3 每季度做一次真實(shí)的恢復(fù)演練我沒(méi)見(jiàn)過(guò)哪個(gè)團(tuán)隊(duì)的備份策略是第一次就能做完美的。真正的分水嶺在于是否做了恢復(fù)演練而且不是演練一次就結(jié)束是每季度或半年固定做一次。我自己的做法是準(zhǔn)備一個(gè)獨(dú)立的演練集群這個(gè)集群規(guī)模不需要很大但安裝的 K8s 版本和插件配置盡量與生產(chǎn)一致。然后我每個(gè)月從對(duì)象存儲(chǔ)中隨機(jī)挑一個(gè)備份把資源恢復(fù)到演練集群再驗(yàn)證幾個(gè)核心業(yè)務(wù)是否能正常工作。曾有一次演練暴露過(guò)大問(wèn)題一切資源恢復(fù)成功但業(yè)務(wù)無(wú)法啟動(dòng)原因是 Secret 中的密碼在源集群里已經(jīng)輪換過(guò)而 ConfigMap 中引用的配置仍舊是舊值。如果沒(méi)做演練等真實(shí)災(zāi)難發(fā)生時(shí)這個(gè)問(wèn)題會(huì)變成生產(chǎn)事故的原因。所以我說(shuō)演練不是額外負(fù)擔(dān)它是備份體系中最有價(jià)值的一環(huán)。6. 常見(jiàn)故障與排查技巧備份恢復(fù)大概率不是一次就能順利跑通的。我把這兩年遇到的高頻問(wèn)題整理成了一張速查表供你定位問(wèn)題。癥狀可能原因解決方案etcdctl snapshot save 報(bào)證書(shū)錯(cuò)誤未正確加載 ETCDCTL_CERT / ETCDCTL_KEY 環(huán)境變量重新 source 環(huán)境變量文件檢查證書(shū)路徑etcd snapshot restore 后 apiserver 起不來(lái)數(shù)據(jù)目錄權(quán)限不對(duì)或新舊集群 token 不一致確認(rèn)/var/lib/etcd屬主為 etcd 用戶檢查 apiserver 日志Velero backup 狀態(tài)一直停留在 NewBackupStorageLocation 無(wú)效或插件版本不匹配查看 velero 日志檢查存儲(chǔ)桶是否可訪問(wèn)Velero 備份完成但恢復(fù)后 PVC 為空沒(méi)有啟用 restic / 卷快照被顯式關(guān)閉恢復(fù)動(dòng)作加上--default-volumes-to-restic并確認(rèn) restic Pod 運(yùn)行恢復(fù)時(shí)提示 storageclass 不存在目標(biāo)集群缺少源集群的 StorageClass創(chuàng)建同名 StorageClass或用--storage-class-mapping參數(shù)做替換定時(shí)備份連續(xù)失敗但你完全沒(méi)發(fā)現(xiàn)缺少失敗告警機(jī)制為 Velero 配置監(jiān)控告警或檢查日志工具備份文件在 MinIO 中被誤刪bucket 沒(méi)有開(kāi)啟版本控制開(kāi)啟 bucket 版本控制并配置生命周期規(guī)則除了表格里的問(wèn)題我再補(bǔ)充三個(gè)比較隱秘但很重要的經(jīng)驗(yàn)。第一Velero 備份過(guò)程中如果集群正在發(fā)生大量資源變更可能出現(xiàn)部分資源處于中間狀態(tài)導(dǎo)致恢復(fù)回來(lái)后資源版本沖突或字段不完整。對(duì)于核心數(shù)據(jù)庫(kù)這類服務(wù)我建議備份前先將應(yīng)用置于只讀或停寫(xiě)狀態(tài)至少也要接受 PVC 數(shù)據(jù)本身的一致性由應(yīng)用層保證。第二restic 備份模式對(duì) PVC 數(shù)據(jù)的備份速度較慢。如果 PVC 體積達(dá)到 TB 級(jí)別全量備份耗時(shí)可能數(shù)小時(shí)。這時(shí)候需要考慮文件系統(tǒng)層面的定期快照比如云廠商磁盤快照或數(shù)據(jù)庫(kù)自身備份工具而不是一味依賴 Velero 的每個(gè)卷備份。第三恢復(fù)時(shí)注意資源間的依賴順序。Velero 會(huì)盡力做依賴排序但有些自定義資源需要先創(chuàng)建 CRD再創(chuàng)建 CRD 實(shí)例。如果恢復(fù)后自定義資源沒(méi)有正常出現(xiàn)優(yōu)先檢查 CRD 是否已經(jīng)注冊(cè)必要時(shí)手動(dòng)應(yīng)用 CRD 定義。還有一個(gè)小技巧恢復(fù)前把目標(biāo)集群的命名空間先清空或者使用一個(gè)新的命名空間做恢復(fù)驗(yàn)證避免與現(xiàn)有資源產(chǎn)生沖突。這個(gè)操作能幫你把問(wèn)題邊界縮小少在環(huán)境干擾上浪費(fèi)時(shí)間。說(shuō)一個(gè)我印象最深的教訓(xùn)。某次我把 etcd 快照恢復(fù)做完了節(jié)點(diǎn)全部 ReadyPod 也全部 Running表面上一切完美。結(jié)果第二天業(yè)務(wù)反饋數(shù)據(jù)缺失一查發(fā)現(xiàn)備份時(shí)間點(diǎn)在業(yè)務(wù)高峰期前一小時(shí)隨后一小時(shí)內(nèi)的寫(xiě)入全部丟掉了。從此以后我在設(shè)計(jì)備份策略時(shí)都會(huì)先問(wèn)一句業(yè)務(wù)能否接受這個(gè) RPO如果能承受小時(shí)級(jí)丟失則每日備份足夠如果不能那就需要借助數(shù)據(jù)庫(kù)層的 binlog 同步或存儲(chǔ)層的實(shí)時(shí)快照來(lái)縮短丟失窗口。備份恢復(fù)這件事看起來(lái)只是幾條命令但真正把它做扎實(shí)需要你對(duì)集群的部署形態(tài)、業(yè)務(wù)的數(shù)據(jù)特性、存儲(chǔ)后端的接口能力都有清晰認(rèn)知。希望這篇基于配置與實(shí)踐的梳理能讓你在構(gòu)建自己的備份方案時(shí)少走一些彎路。下一次遇到故障時(shí)希望你想到的不是后悔沒(méi)備份而是從容地執(zhí)行演練過(guò)無(wú)數(shù)遍的恢復(fù)流程。