本主題說明如何在 vSphere 上透過以下方法,備份和還原具有獨立管理叢集的 Tanzu Kubernetes Grid (TKG) 的叢集基礎結構:
附註
- VMware 不支援使用 Velero 來備份 TKG 獨立管理叢集。
- 如果在部署獨立管理叢集後重新設定該叢集,如同此處所述,重建該叢集不見得能全數復原其所有資源。
對於具有獨立管理叢集的 Tanzu Kubernetes Grid (TKG) 工作負載叢集,若要備份及還原其中所託管的工作負載和動態儲存磁碟區,請參閱備份和還原叢集工作負載。
若要備份和還原 vSphere with Tanzu 叢集 (包括主管叢集及其建立的工作負載叢集),請參閱 VMware vSphere 8.0 說明文件中的備份和還原 vSphere with Tanzu。
注意
- 此功能處於不受支援的技術預覽狀態;請參閱 TKG 功能狀態。
您可以使用 Velero (一種開放原始碼社群標準工具),來備份和還原 TKG 獨立管理叢集基礎結構和工作負載。
Velero 支援各種儲存區提供者以儲存其備份。Velero 還支援:
Tanzu Kubernetes Grid 訂閱包括對 VMware 測試的、相容的 Velero 發行版的支援,可從 Tanzu Kubernetes Grid 下載頁面取得。
若要備份和還原 TKG 叢集,您需要:
完成上述必備條件後,還可以使用 Velero 在叢集之間遷移工作負載。有關說明,請參見 Velero 文件中的叢集遷移和資源篩選。
注意如果已安裝 Velero CLI v1.9.x 或更早版本 (隨早期版本的 TKG 一起發行),則需要升級到 v1.10.3。較舊的 Velero 版本不能與 v1.9 及更新版本中使用的 CRD 一起使用。如需更多資訊,請參閱下面的升級 Velero。
若要安裝 Velero CLI v1.10.3,請執行以下動作:
.gz
檔案。其檔案名稱以 velero-linux-
、velero-mac-
或 velero-windows64-
開頭。使用 gunzip
命令或您選擇的解壓縮工具解壓縮二進位檔:
gzip -d <RELEASE-TARBALL-NAME>.gz
將適用於您的平台的 CLI 二進位檔重新命名為 velero
,確保它是可執行的,然後將其新增至 PATH
。
/usr/local/bin
資料夾並將其重新命名為 velero
。chmod +x /usr/local/bin/velero
Program Files\velero
資料夾並將二進位檔案複製到其中。velero.exe
。velero
資料夾上按一下滑鼠右鍵,選取內容 (Properties) > 安全性 (Security),並確定您的使用者帳戶具有完全控制 (Full Control) 權限。env
。Path
資料列,然後按一下編輯 (Edit)。velero
二進位檔的路徑。Velero v1.10.3 使用與 v1.9.x 不同的 CRD。此外,Velero v1.10 採用 Kopia with Restic 作為上傳程式,這導致元件和命令的命名以及 Velero 執行方式發生了一些變更。有關 v1.9.x 和 v1.10 之間的破壞性變更的詳細資訊,請參閱 Velero v1.10 Changelog 中的重大變更。如果安裝了具有先前版本的 TKG 的 Velero v1.9.x,則必須升級 Velero。
使用 Velero v1.10 二進位檔更新 CRD 定義。
velero install --crds-only --dry-run -o yaml | kubectl apply -f -
更新 Velero 部署和精靈集組態,以配合在 Velero v1.10 中的元件重新命名。
在以下命令中,uploader_type
可以是 restic
或 kopia
。
kubectl get deploy -n velero -ojson \
| sed "s#\"image\"\: \"velero\/velero\:v[0-9]*.[0-9]*.[0-9]\"#\"image\"\: \"velero\/velero\:v1.10.0\"#g" \
| sed "s#\"server\",#\"server\",\"--uploader-type=$uploader_type\",#g" \
| sed "s#default-volumes-to-restic#default-volumes-to-fs-backup#g" \
| sed "s#default-restic-prune-frequency#default-repo-maintain-frequency#g" \
| sed "s#restic-timeout#fs-backup-timeout#g" \
| kubectl apply -f -
(可選) 如果使用的是 restic
精靈集,請重新命名對應的元件。
echo $(kubectl get ds -n velero restic -ojson) \
| sed "s#\"image\"\: \"velero\/velero\:v[0-9]*.[0-9]*.[0-9]\"#\"image\"\: \"velero\/velero\:v1.10.0\"#g" \
| sed "s#\"name\"\: \"restic\"#\"name\"\: \"node-agent\"#g" \
| sed "s#\[ \"restic\",#\[ \"node-agent\",#g" \
| kubectl apply -f -
kubectl delete ds -n velero restic --force --grace-period 0
有關詳細資訊,請參閱 Velero 說明文件中的升級至 Velero 1.10。
若要備份 Tanzu Kubernetes Grid 工作負載叢集內容,您需要以下儲存區位置:
請參閱 Velero 說明文件中的備份儲存區位置和磁碟區快照位置。Velero 支援各種儲存區提供者,這些提供者可以是:
VMware 建議將唯一的儲存區值區專用於每個叢集。
若要設定 MinIO,請執行以下動作:
執行設有 MinIO 認證和儲存位置的 minio
容器映像,例如:
$ docker run -d --name minio --rm -p 9000:9000 -e "MINIO_ACCESS_KEY=minio" -e "MINIO_SECRET_KEY=minio123" -e "MINIO_DEFAULT_BUCKETS=mgmt" gcr.io/velero-gcp/bitnami/minio:2021.6.17-debian-10-r7
將認證儲存到本機檔案,以傳遞給 velero install
的 --secret-file
選項,例如:
[default]
aws_access_key_id=minio
aws_secret_access_key=minio123
在 vSphere 上,叢集物件儲存區備份和磁碟區快照將儲存到同一儲存區位置。此位置必須是 Amazon Web Services (AWS) 或 S3 提供者 (如 MinIO) 上與 S3 相容的外部儲存區。
若要為 vSphere 上的 Velero 設定儲存區,請參閱適用於 v1.5.1 外掛程式的 Vanilla Kubernetes 叢集中的 Velero Plugin for vSphere。
若要為 AWS 上的 Velero 設定儲存區,請依照適用於 AWS 存放庫的 Velero 外掛程式中的程序操作:
視需要為每個外掛程式設定 S3 儲存區。物件儲存外掛程式會儲存和擷取叢集物件備份,而磁碟區快照程式則會儲存和擷取資料磁碟區。
若要為 Azure 上的 Velero 設定儲存區,請依照適用於 Azure 存放庫的 Velero 外掛程式中的程序操作:
視需要為每個外掛程式設定 S3 儲存區。物件儲存外掛程式會儲存和擷取叢集物件備份,而磁碟區快照程式則會儲存和擷取資料磁碟區。
若要備份工作負載叢集物件,請將 Velero v1.10.3 伺服器安裝到獨立管理叢集並驗證安裝。
若要安裝 Velero,請執行具有下列選項的 velero install
:
--provider $PROVIDER
:例如,aws
--plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.6.2_vmware.1
--bucket $BUCKET
:S3 值區的名稱--backup-location-config region=$REGION
:值區所在的 AWS 區域--snapshot-location-config region=$REGION
:值區所在的 AWS 區域--kubeconfig
將 Velero 伺服器安裝到目前預設叢集以外的叢集。(選用) --secret-file ./VELERO-CREDS
授與 Velero 存取 S3 值區的一種方法是,將類似如下的本機 VELERO-CREDS
檔案傳遞給這個選項:
[default]
aws_access_key_id=<AWS_ACCESS_KEY_ID>
aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
如需其他選項,請參閱安裝並啟動 Velero。
執行 velero install
命令時,會在叢集上建立一個稱為 velero
的命名空間,並在其中放置一個名為 velero
的部署。
需要下列設定:
--plugins projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.2.0_vmware.1
附註您可以新增以逗號分隔的多個選項。例如:
--plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.6.2_vmware.1,projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.2.0_vmware.1
--snapshot-location-config
velero install
命令完成後,請確認 Velero 已安裝成功:
確認 Velero 網繭的狀態為 Running
:
kubectl -n velero get pod
NAME READY STATUS RESTARTS AGE
velero-78fdbcd446-v5cqr 1/1 Running 0 3h41m
確認備份位置處於 Available
階段:
velero backup-location get
NAME PROVIDER BUCKET/PREFIX PHASE LAST VALIDATED ACCESS MODE DEFAULT
default aws mgmt Available 2022-11-11 05:55:55 +0000 UTC ReadWrite true
若要備份由獨立管理叢集所管理的所有工作負載叢集物件,請執行:
velero backup create my-backup --exclude-namespaces tkg-system --include-resources cluster.cluster.x-k8s.io --wait
附註
--exclude-namespaces tkg-system
會排除管理叢集本身。
--include-resources cluster.cluster.x-k8s.io
會包含工作負載叢集物件VMware 建議您在進行任何結構變更 (例如垂直擴充或縮減) 後,就立即備份工作負載叢集。這可避免備份物件和實體基礎結構之間出現不相符情況,從而避免還原程序失敗。
如果在最近一次備份後變更了叢集物件,則還原後的系統狀態會與其想要的最新狀態不相符。此問題稱為「偏差」。如需如何從某些常見類型的偏差偵測和復原的相關資訊,請參閱以下的處理偏差小節。
為了將偏差減至最低,VMware 建議使用 Velero 來排程定期備份。例如,若要每天備份所有的工作負載叢集,且每個備份保留 14 天,請執行:
velero create schedule daily-bak --schedule="@every 24h" --exclude-namespaces tkg-system --include-resources cluster.cluster.x-k8s.io --ttl 336h0m0s
如需更多 Velero 排程選項,請參閱 Velero 說明文件中的排程備份。
kubeconfig
檔案使用 Velero 復原工作負載叢集後,需要將其新的 kubeconfig
檔案散發給使用該叢集的任何人員:
重新產生 kubeconfig
:
tanzu cluster kubeconfig get CLUSTER-NAME --namespace NAMESPACE
將上述命令的輸出散發給使用叢集的任何人員,以取代其舊的 kubeconfig
檔案。
kubeconfig
檔案不包含身分或認證,可以按照 Pinniped 說明文件中的瞭解使用 Pinniped 對 Kubernetes 叢集進行同盟驗證中所述安全地散發。如要還原獨立管理叢集及其管理的工作負載叢集物件,請從其組態檔重新建立管理叢集,使用 Velero 還原其工作負載叢集,並將新的 kubeconfig
檔案分發給使用這些檔案的人員:
如果懷疑工作負載叢集物件的最新備份與其目前執行狀態之間存在偏差,請使用偏差偵測器工具產生修復報告,如使用偏差偵測器中所述。
確保最初部署管理叢集後對管理叢集所做的任何組態更改都反映在其組態檔或環境變數中。否則,它不會還原到其最新狀態。
從組態檔 mgmt-cluster-config.yaml
重建管理叢集,如從組態檔來部署管理叢集中所述。
VSphereFailureDomain
和 VSphereDeploymentZone
物件定義的檔案,例如,藉由在 tanzu mc create
命令中包含 --az-file vsphere-zones.yaml
。一建立管理叢集後,就只應有一個 TKR:
tanzu kubernetes-release get
NAME VERSION COMPATIBLE ACTIVE UPDATES AVAILABLE
v1.26.8---vmware.2-tkg.1 v1.26.8+vmware.1-tkg.1 True True
請等待幾分鐘,直到所備份的工作負載叢集使用的所有 TKR 都變成可用:
tanzu kubernetes-release get
NAME VERSION COMPATIBLE ACTIVE UPDATES AVAILABLE
v1.24.17---vmware.2-tkg.2 v1.24.17+vmware.2-tkg.2 True True
v1.25.13---vmware.1-tkg.1 v1.25.13+vmware.1-tkg.1 True True
v1.26.8---vmware.2-tkg.1 v1.26.8+vmware.1-tkg.1 True True
遵循上述將 Velero 伺服器部署到叢集指示,在管理叢集上安裝 Velero。請確定認證和備份位置組態設定的值與執行備份時的值相同。
Velero 安裝後,請執行 velero backup get
,直到備份同步,且命令列出了您想使用的備份:
velero backup get
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
my-backup Completed 0 0 2022-12-07 17:10:42 +0000 UTC 24d default <none>
執行 velero restore create
,還原工作負載叢集資源。VMware 建議使用最新的備份:
velero restore create my-restore --from-backup my-backup --wait
還原完成後,叢集將處於 createdStalled
狀態:
tanzu cluster list
NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES PLAN TKR
tkg-vc-antrea default createdStalled 0/3 0/3 v1.26.8+vmware.1 <none> prod v1.26.8---vmware.2-tkg.1
修補叢集物件,以將其 paused
內容設定為 false
。這是必要的,因為會以 paused
狀態將叢集物件重建在新的管理叢集上,以防止其控制器嘗試協調:
若要在還原叢集後取消暫停它,請執行:
kubectl -n my-namespace patch cluster CLUSTER-NAME --type merge -p '{"spec":{"paused":false}}'
若要取消暫停多個命名空間中的所有叢集,請執行以下指令碼:
#!/bin/bash
for ns in $(kubectl get ns -o custom-columns=":metadata.name" | grep -v "tkg-system");
do
clusters=$(kubectl -n $ns get cluster -o name)
if [[ -n $clusters ]];then
kubectl -n $ns patch $clusters --type merge -p '{"spec":{"paused":false}}'
fi
done
確認所有工作負載叢集都處於 running
狀態,例如:
tanzu cluster list
NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES PLAN TKR
tkg-vc-antrea default running 3/3 3/3 v1.26.8+vmware.1 <none> prod v1.26.8---vmware.2-tkg.1
針對每個工作負載叢集,執行 tanzu cluster get CLUSTER-NAME
,以檢查所有元件是否都處於 running
狀態,例如:
tanzu cluster get tkg-vc-antrea
NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES TKR
tkg-vc-antrea default running 3/3 3/3 v1.26.8+vmware.1 <none> v1.26.8---vmware.2-tkg.1
Details:
NAME READY SEVERITY REASON SINCE MESSAGE
/tkg-vc-antrea True 4h14m
├─ClusterInfrastructure - VSphereCluster/tkg-vc-antrea-s6kl5 True 4h36m
├─ControlPlane - KubeadmControlPlane/tkg-vc-antrea-ch5hn True 4h14m
│ ├─Machine/tkg-vc-antrea-ch5hn-8gfvt True 4h14m
│ ├─Machine/tkg-vc-antrea-ch5hn-vdcrp True 4h23m
│ └─Machine/tkg-vc-antrea-ch5hn-x7nmm True 4h32m
└─Workers
├─MachineDeployment/tkg-vc-antrea-md-0-8b8zn True 4h23m
│ └─Machine/tkg-vc-antrea-md-0-8b8zn-798d5b8897-bnxn9 True 4h24m
├─MachineDeployment/tkg-vc-antrea-md-1-m6dvh True 4h24m
│ └─Machine/tkg-vc-antrea-md-1-m6dvh-79fb858b96-p9667 True 4h28m
└─MachineDeployment/tkg-vc-antrea-md-2-brm2m True 4h21m
└─Machine/tkg-vc-antrea-md-2-brm2m-6478cffc5f-tq5cn True 4h23m
當所有工作負載叢集都正在執行後,就可以使用 Tanzu CLI 來管理工作負載叢集。
如果在重新建立管理叢集之前執行偏差偵測器,請手動修復或調查偏差偵測器報告中標記的任何物件,如修復偏差中所述。
為管理叢集及其工作負載叢集重新產生並散發新的 kubeconfig
檔案:
重新產生管理叢集 kubeconfig
:
tanzu management-cluster kubeconfig get
對於每個工作負載叢集,重新產生其 kubeconfig
:
tanzu cluster kubeconfig get CLUSTER-NAME --namespace NAMESPACE
將上述命令的輸出散發給使用叢集的任何人員,以取代其舊的 kubeconfig
檔案。
kubeconfig
檔案不包含身分或認證,可以按照 Pinniped 說明文件中的瞭解使用 Pinniped 對 Kubernetes 叢集進行同盟驗證中所述安全地散發。若在最近一次備份後變更叢集物件發生偏差,則還原後的系統狀態會與其想要的最新狀態不相符。
為了將偏差減至最低,VMware 建議使用排程定期備份。
為了幫助偵測和修復偏差,可以使用以下各節中所述的偏差偵測器工具。
偏差偵測器是一個命令行工具,該工具可以:
重要偏差偵測器處於不受支援的實驗狀態。偏差很複雜,偏移偵測器可能無法偵測所有偏差執行個體。它僅應當作參考,不能取代定期備份。
有關如何安裝和使用偏差偵測器,請參閱 VMware 知識庫網站上的適用於 Tanzu Kubernetes Grid 管理叢集的偏差偵測器。整個程序如下:
從備份還原 TKG 之前,執行 drift-detector
命令以產生報告。
從最近的備份下載和還原 TKG。
請參閱偏差偵測器報告,按照 修復偏差中的指示對 TKG 的已還原狀態執行修復操作。
偏差情況可能很複雜,但如果您具有偏差偵測器報告或以其他方式偵測到上次備份後叢集物件狀態中的某些偏差,則可以按以下方式修復一些常見模式:
失效的工作節點:
Ghost 工作節點基礎結構:
緩解措施:
kubeconfig
,並將其設定為 kubectl
內容。比較下列 kubectl
和 tanzu
命令的輸出:
# Get the actual worker nodes of the workload cluster
$ kubectl --context tkg-vc-antrea-admin@tkg-vc-antrea get node
NAME STATUS ROLES AGE VERSION
tkg-vc-antrea-md-0-p9vn5-645498f59f-42qh9 Ready <none> 44m v1.26.8+vmware.1
tkg-vc-antrea-md-0-p9vn5-645498f59f-shrpt Ready <none> 114m v1.26.8+vmware.1
tkg-vc-antrea-wdsfx-2hkxp Ready control-plane 116m v1.26.8+vmware.1
# Get the worker nodes managed by the TKG
$ tanzu cluster get tkg-vc-antrea
NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES TKR
tkg-vc-antrea default running 1/1 1/1 v1.26.8+vmware.1 <none> v1.26.8---vmware.2-tkg.1-zshippable
Details:
NAME READY SEVERITY REASON SINCE MESSAGE
/tkg-vc-antrea True 13m
├─ClusterInfrastructure - VSphereCluster/tkg-vc-antrea-b7fr9 True 13m
├─ControlPlane - KubeadmControlPlane/tkg-vc-antrea-wdsfx True 13m
│ └─Machine/tkg-vc-antrea-wdsfx-2hkxp True 13m
└─Workers
└─MachineDeployment/tkg-vc-antrea-md-0-p9vn5 True 13m
└─Machine/tkg-vc-antrea-md-0-p9vn5-645498f59f-shrpt True 13m
對於 kubectl
所列出的工作節點,只要該工作節點並無 tanzu cluster get
中的 Workers
> Machine
清單,請執行下列動作:
將工作節點數量垂直擴充為預期值,例如:
tanzu cluster scale ${cluster_name} --worker-machine-count 2
kubeconfig
來清空 Ghost 節點,這會將其工作負載移至 TKG 所管理的節點:kubectl drain ${node_name} --delete-emptydir-data --ignore-daemonsets
從叢集中移除 Ghost 節點:
kubectl delete node ${node_name}
登入 vSphere 或其他基礎結構,然後手動移除虛擬機器。
控制平面上的失效節點和 Ghost 基礎結構
緩解措施:
kubeconfig
,並將其設定為 kubectl
內容。比較下列 kubectl
和 tanzu
命令的輸出:
# Get the actual control plane nodes of the workload cluster
$ kubectl --context wc-admin@wc get node
NAME STATUS ROLES AGE VERSION
wc-2cjn4-4xbf8 Ready control-plane 107s v1.26.8+vmware.1
wc-2cjn4-4zljs Ready control-plane 26h v1.26.8+vmware.1
wc-2cjn4-59v95 Ready control-plane 26h v1.26.8+vmware.1
wc-2cjn4-ncgxb Ready control-plane 25h v1.26.8+vmware.1
wc-md-0-nl928-5df8b9bfbd-nww2w Ready <none> 26h v1.26.8+vmware.1
wc-md-1-j4m55-589cfcd9d6-jxmvc Ready <none> 26h v1.26.8+vmware.1
wc-md-2-sd4ww-7b7db5dcbb-crwdv Ready <none> 26h v1.26.8+vmware.1
# Get the control plane nodes managed by the TKG
$ tanzu cluster get wc
NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES TKR
wc default updating 4/3 3/3 v1.26.8+vmware.1 <none> v1.26.8---vmware.2-tkg.1-zshippable
Details:
NAME READY SEVERITY REASON SINCE MESSAGE
/wc True 24m
├─ClusterInfrastructure - VSphereCluster/wc-9nq7v True 26m
├─ControlPlane - KubeadmControlPlane/wc-2cjn4 True 24m
│ ├─Machine/wc-2cjn4-4xbf8 True 24m
│ ├─Machine/wc-2cjn4-4zljs True 26m
│ └─Machine/wc-2cjn4-59v95 True 26m
└─Workers
├─MachineDeployment/wc-md-0-nl928 True 26m
│ └─Machine/wc-md-0-nl928-5df8b9bfbd-nww2w True 26m
├─MachineDeployment/wc-md-1-j4m55 True 26m
│ └─Machine/wc-md-1-j4m55-589cfcd9d6-jxmvc True 26m
└─MachineDeployment/wc-md-2-sd4ww True 26m
└─Machine/wc-md-2-sd4ww-7b7db5dcbb-crwdv True 26m
對於 kubectl
所列出的 control-plane
節點,只要該控制平面並無 tanzu cluster get
中的 ControlPlane
> Machine
清單,請執行下列動作:
刪除節點:
kubectl delete node ${node_name}