本文說明如何備份及還原已啟用進階叢集的 Google Distributed Cloud 1.32 以上版本管理員和使用者叢集。備份及還原功能在 1.32 版為預先發布版,1.33 以上版本則為正式發布版。
gkectl
備份和還原程序不包含永久磁碟區。本機磁碟區佈建工具 (LVP) 建立的磁碟區不會受到影響。
備份叢集
gkectl backup cluster
指令會將 etcd 存放區中的叢集資訊,以及指定叢集的 PKI 憑證新增至 tar 檔案。etcd 儲存庫是 Kubernetes 的後端儲存庫,用於存放所有叢集資料,並包含管理叢集狀態所需的所有 Kubernetes 物件和自訂物件。PKI 憑證用於透過傳輸層安全標準 (TLS) 進行驗證。這項資料是從叢集的控制層備份,或是從高可用性 (HA) 部署作業的其中一個控制層備份。
備份 tar 檔案包含私密憑證,包括服務帳戶金鑰和 SSH 金鑰。將備份檔案儲存在安全的位置。為避免檔案意外曝光,備份程序只會使用記憶體內檔案。
定期備份叢集,確保快照資料相對較新。請根據叢集重大變更的頻率,調整備份頻率。
開始前,請確認叢集運作正常,且所有節點的憑證和 SSH 連線都正常運作。備份程序的目的是擷取叢集已知的良好狀態,以便在發生災難性故障時還原作業。
如要備份叢集,請按照下列步驟操作:
執行下列指令來檢查叢集:
gkectl diagnose cluster --cluster-name CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG
更改下列內容:
CLUSTER_NAME:您打算備份的叢集名稱。
ADMIN_KUBECONFIG:管理員叢集的 kubeconfig 檔案路徑。
執行適用的指令來備份叢集:
管理員叢集
gkectl backup admin --kubeconfig ADMIN_KUBECONFIG
使用者叢集
gkectl backup cluster --cluster-name CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG
根據預設,備份 tar 檔案會儲存在管理員工作站的 gkectl-workspace/backups
目錄中。tar 檔案的名稱為 CLUSTER_NAME_backup_TIMESTAMP.tar.gz
,其中 CLUSTER_NAME
是要備份的叢集名稱,而 TIMESTAMP
是備份作業的日期和時間。舉例來說,如果叢集名稱為 testuser
,備份檔案的名稱會類似 testuser_backup_2025-08-23T150405Z0700.tar.gz
。
(選用) 您可以使用 --backup-file
標記,為備份檔案指定其他名稱和位置,例如:
gkectl backup cluster testuser \
--kubeconfig admin-cluster/kubeconfig \
--backup-file cluster-backups/testuser-backup-aug-23-2025.tar.gz
備份檔案會在一年後過期,叢集還原程序無法處理過期的備份檔案。
備份至 vSphere
如要設定備份,讓管理員和使用者叢集的備份檔案上傳至 vSphere,並儲存在管理員工作站,請執行下列操作:
在管理員叢集設定檔中新增 clusterBackup.datastore 欄位:
clusterBackup: datastore: DATASTORE
請將
DATASTORE
改為要儲存備份的資料存放區。資料存放區必須與管理員叢集位於同一個資料中心。備份檔位於指定資料儲存區的anthos/CLUSTER_NAME/backup
目錄中。更新管理員叢集:
gkectl update admin --kubeconfig ADMIN_KUBECONFIG \ --config ADMIN_CONFIG
更改下列內容:
ADMIN_KUBECONFIG
:管理員叢集的 kubeconfig 檔案路徑。ADMIN_CONFIG
:管理員叢集設定檔的路徑。
根據預設,gkectl backup
指令會在 vSphere 中儲存最近的三個備份檔案,並刪除較舊的備份檔案。如要保留舊版備份檔案,請新增 --keep-all-backups
標記 (適用於 1.32.100 以上版本)。
還原叢集
從備份還原叢集是最後手段,只有在叢集發生嚴重故障,且無法以其他方式恢復服務時,才應使用這項功能。舉例來說,etcd 資料已損毀,或 etcd Pod 處於當機迴圈。
只有在所有三個控制層節點都失敗時,才使用 gkectl restore
指令。
如果只有一個節點發生故障,且管理員叢集設定檔中的
autoRepair.enabled
設為true
,系統就會自動修復故障的節點。如果未設定autoRepair.enabled
,請將其新增至管理員叢集設定檔,然後執行gkectl update admin
。更新完成後,節點會自動重新建立。如果兩個控制層節點都發生故障,請參閱本頁面的「還原法定人數」一節。
備份 tar 檔案包含私密憑證,包括服務帳戶金鑰和 SSH 金鑰。為避免檔案遭到意外公開,Google Distributed Cloud 還原程序只會使用記憶體內檔案。
還原叢集前,請確認符合下列條件:
- 備份時可供叢集使用的所有控制層節點機器,都運作正常且可連線。
- 節點之間的 SSH 連線會使用備份時的 SSH 金鑰。這些 SSH 金鑰會在還原程序中恢復。
- 備份時使用的服務帳戶金鑰仍為有效狀態。這些服務帳戶金鑰會還原至還原的叢集。
如要還原叢集,請按照下列步驟操作:
執行適用的指令來還原叢集:
管理員叢集
gkectl restore admin --backup-file BACKUP_FILE \ --config ADMIN_CONFIG
更改下列內容:
BACKUP_FILE
:您使用的備份檔案路徑和名稱。ADMIN_CONFIG
:管理員叢集設定檔的路徑。
使用者叢集
gkectl restore cluster --cluster-name CLUSTER_NAME \ --backup-file BACKUP_FILE \ --kubeconfig ADMIN_KUBECONFIG
更改下列內容:
CLUSTER_NAME
:要還原的叢集名稱。BACKUP_FILE
:您使用的備份檔案路徑和名稱。ADMIN_KUBECONFIG
:管理員叢集 kubeconfig 檔案的路徑。
還原程序完成後,系統會在工作區目錄
gkectl-workspace
中,為還原的叢集產生新的 kubeconfig 檔案。還原作業完成後,請執行下列指令,確認作業是否成功:
gkectl diagnose cluster --cluster-name CLUSTER_NAME \ --kubeconfig GENERATED_KUBECONFIG
將
GENERATED_KUBECONFIG
替換為產生的 kubeconfig 檔案。
還原仲裁
如果叢集中有兩個控制層節點發生故障,可以使用 gkectl restore
指令還原法定人數。還原仲裁時,請指定運作中控制層節點的 IP 位址,而不是在 gkectl restore
指令中指定備份檔案。
執行指令前,請確認符合下列條件:
- 只有一個控制層節點在運作。
- 您可以使用 SSH 金鑰存取運作中的控制層節點。詳情請參閱使用 SSH 連線至叢集節點一文。
如要還原法定人數,請為叢集類型執行適用的指令:
管理員叢集
gkectl restore admin --kubeconfig ADMIN_KUBECONFIG \
--config ADMIN_CONFIG \
--control-plane-node WORKING_NODE_IP \
--ssh-key ADMIN_SSH_KEY_PATH
更改下列內容:
ADMIN_KUBECONFIG
:管理員叢集的 kubeconfig 檔案路徑。ADMIN_CONFIG
:管理員叢集設定檔的路徑。WORKING_NODE_IP
:運作中控制層節點的 IP 位址。ADMIN_SSH_KEY_PATH
:管理員叢集安全殼層金鑰路徑。
使用者叢集
gkectl restore cluster --cluster-name CLUSTER_NAME \
--kubeconfig ADMIN_KUBECONFIG \
--control-plane-node WORKING_NODE_IP \
--ssh-key USER_SSH_KEY_PATH
更改下列內容:
CLUSTER_NAME
:要還原的叢集名稱。ADMIN_KUBECONFIG
:管理員叢集 kubeconfig 檔案的路徑。WORKING_NODE_IP
:運作中控制層節點的 IP 位址。USER_SSH_KEY_PATH
:使用者叢集安全殼層金鑰路徑。
疑難排解
如果備份或還原程序發生問題,請參閱下列章節排解問題。
如需其他協助,請與 Cloud Customer Care 團隊聯絡。
備份或還原期間記憶體不足
如果執行 gkectl
指令的工作站 RAM 不多,您可能沒有足夠的記憶體來執行備份或還原程序。如有需要,請建立並使用暫時的暫存磁碟,透過備份指令中的 --use-disk
參數處理備份或還原作業。為保留檔案權限,這個參數會修改檔案權限,因此您必須以根使用者身分執行指令 (或使用 sudo
)。
備份後重新整理 SSH 金鑰會導致還原程序中斷
如果 SSH 金鑰在備份完成後重新整理,還原程序期間的 SSH 相關作業可能會失敗。在這種情況下,新的 SSH 金鑰會對還原程序失效。如要解決這個問題,可以暫時加回原始 SSH 金鑰,然後執行還原作業。還原程序完成後,您就可以輪替安全殼層金鑰。