使用 bmctl 備份及還原叢集

本頁說明如何使用 bmctl 備份及還原在裸機上以 Google Distributed Cloud (僅限軟體) 建立的叢集。這些操作說明適用於所有叢集類型。

bmctl備份及還原程序不包含永久磁碟區。本機磁碟區佈建工具 (LVP) 建立的任何磁碟區都不會變更。

如需其他協助，請與 Cloud Customer Care 團隊聯絡。如要進一步瞭解支援資源，包括下列項目，請參閱「取得支援」：

備份叢集

bmctl backup cluster 指令會將 etcd 存放區中的叢集資訊，以及指定叢集的 PKI 憑證新增至 tar 檔案。etcd 儲存空間是 Kubernetes 的後端儲存空間，用於儲存所有叢集資料，並包含管理叢集狀態所需的所有 Kubernetes 物件和自訂物件。PKI 憑證用於透過 TLS 進行驗證。這項資料會從叢集的控制層備份，或是從高可用性 (HA) 部署作業的其中一個控制層備份。

備份 tar 檔案包含私密憑證，包括服務帳戶金鑰和 SSH 金鑰。將備份檔案儲存在安全的位置。為避免檔案遭到未經授權的存取，Google Distributed Cloud 備份程序只會使用記憶體內檔案。

定期備份叢集，確保快照資料相對較新。請根據叢集重大變更的頻率，調整備份頻率。

用來備份叢集的 bmctl 版本必須與管理叢集的版本相符。

如要備份叢集，請按照下列步驟操作：

  1. 請確認叢集運作正常，且所有節點的憑證和 SSH 連線都正常運作。

    備份程序的目的是擷取叢集已知的良好狀態，以便在發生災難性故障時還原作業。

    使用下列指令檢查叢集：

    bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    更改下列內容：

    • CLUSTER_NAME：您打算備份的叢集名稱。
    • ADMIN_KUBECONFIG：管理員叢集的 kubeconfig 檔案路徑。

  2. 執行下列指令，確保目標叢集未處於協調狀態：

    kubectl describe cluster CLUSTER_NAME -n CLUSTER_NAMESPACE --kubeconfig ADMIN_KUBECONFIG

    更改下列內容：

    • CLUSTER_NAME：要備份的叢集名稱。
    • CLUSTER_NAMESPACE：叢集的命名空間。根據預設，Google Distributed Cloud 的叢集命名空間是叢集名稱，並以 cluster- 為前置字元。舉例來說，如果將叢集命名為 test，命名空間的名稱會類似 cluster-test。
    • ADMIN_KUBECONFIG：管理員叢集的 kubeconfig 檔案路徑。

  3. 在指令輸出內容中，查看 Status 區段的 Conditions，確認類型為 Reconciling。

    如下列範例所示，如果這些 Conditions 的狀態為 False，表示叢集穩定且可備份。

    ...
Status:
  ...
  Cluster State:  Running
  ...
  Control Plane Node Pool Status:
    ...
    Conditions:
      Last Transition Time:  2023-11-03T16:37:15Z
      Observed Generation:   1
      Reason:                ReconciliationCompleted
      Status:                False
      Type:                  Reconciling
  ...

  4. 執行下列指令來備份叢集：

    bmctl backup cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    更改下列內容：

    • CLUSTER_NAME：要備份的叢集名稱。
    • ADMIN_KUBECONFIG：管理員叢集 kubeconfig 檔案的路徑。

    根據預設，備份 tar 檔案會儲存至管理員工作站的工作區目錄 (預設為 bmctl-workspace)。tar 檔案名為 CLUSTER_NAME_backup_TIMESTAMP.tar.gz，其中 CLUSTER_NAME 是要備份的叢集名稱，TIMESTAMP 則是備份的日期和時間。舉例來說，如果叢集名稱是 testuser，備份檔案的名稱會類似 testuser_backup_2006-01-02T150405Z0700.tar.gz。

    如要為備份檔案指定其他名稱和位置，請使用 --backup-file 標記。

備份檔案會在一年後過期，叢集還原程序無法處理過期的備份檔案。

還原叢集

從備份還原叢集是最後手段，只有在叢集發生嚴重故障，且無法以其他方式恢復服務時才應使用。舉例來說，etcd 資料已損毀，或 etcd Pod 處於當機迴圈。

備份 tar 檔案包含私密憑證，包括服務帳戶金鑰和 SSH 金鑰。為避免檔案遭到意外公開，Google Distributed Cloud 還原程序只會使用記憶體內檔案。

用於還原叢集的 bmctl 版本必須與管理叢集的版本相符。

如要還原叢集，請按照下列步驟操作：

  1. 確認備份時叢集可用的所有節點機器運作正常，且可連線。

  2. 確認節點之間的 SSH 連線可搭配備份時使用的 SSH 金鑰運作。

    這些 SSH 金鑰會在還原程序中恢復。

  3. 確認備份時使用的服務帳戶金鑰仍處於啟用狀態。

    系統會為還原的叢集恢復這些服務帳戶金鑰。

  4. 如要還原管理員、混合式或獨立叢集，請執行下列指令：

    bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE

    更改下列內容：

    • CLUSTER_NAME：要還原的叢集名稱。
    • BACKUP_FILE：您使用的備份檔案路徑和名稱。

  5. 如要還原使用者叢集，請執行下列指令：

    bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE \
    --kubeconfig ADMIN_KUBECONFIG

    更改下列內容：

    • CLUSTER_NAME：要還原的叢集名稱。
    • BACKUP_FILE：您使用的備份檔案路徑和名稱。
    • ADMIN_KUBECONFIG：管理員叢集 kubeconfig 檔案的路徑。

還原程序完成後，系統會為還原的叢集產生新的 kubeconfig 檔案。

還原完成後，請按照下列步驟確認是否成功：

  1. 執行下列指令，使用產生的 kubeconfig 檔案驗證節點就緒狀態和執行的系統 Pod：

    etcd Pod 分為兩種類型：

    • etcd-HOST_NAME，對應於主要 etcd Pod
    • etcd-events-HOST_NAME，對應於 etcd-events Pod
    kubectl get pods -n kube-system --kubeconfig GENERATED_KUBECONFIG
kubectl get nodes --kubeconfig GENERATED_KUBECONFIG

  2. 針對每個 etcd Pod，執行下列指令來驗證 etcd 健康狀態：

    kubectl exec ETCD_POD_NAME -n kube-system \
    --kubeconfig GENERATED_KUBECONFIG \
    -- /bin/sh -c 'ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/peer.key \
    --cert=/etc/kubernetes/pki/etcd/peer.crt endpoint health'

    如果 etcd 成員運作正常，回應應如下所示：

    https://127.0.0.1:2379 is healthy: successfully committed proposal: took = 11.514177ms

  3. 針對每個 etcd-events Pod，執行下列指令來驗證 etcd-events 健康狀態：

    kubectl exec ETCD_EVENTS_POD_NAME -n kube-system \
    --kubeconfig GENERATED_KUBECONFIG \
    -- /bin/sh -c 'ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2382 \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/peer.key \
    --cert=/etc/kubernetes/pki/etcd/peer.crt endpoint health'

    如果 etcd-events 成員運作正常，回應內容應如下所示：

    https://127.0.0.1:2382 is healthy: successfully committed proposal: took = 14.308148ms

疑難排解

如果備份或還原程序發生問題，請參閱下列章節排解問題。

如需其他協助，請與 Google 支援團隊聯絡。

備份或還原期間記憶體不足

備份或還原程序可能會顯示錯誤訊息，但這些訊息不一定能清楚說明問題或後續步驟。如果執行 bmctl 指令的工作站 RAM 不足，您可能無法順利完成備份或還原程序。

Google Distributed Cloud 1.13 以上版本可以在備份指令中使用 --use-disk 參數。為保留檔案權限，這個參數會修改檔案權限，因此執行指令的使用者必須是根使用者 (或使用 sudo)。

還原檔案時缺少權限

成功還原工作後，刪除 Bootstrap 可能會失敗，並顯示類似以下範例的錯誤訊息：

Error: failed to restore node config files: sftp: "Failure" (SSH_FX_FAILURE)

這項錯誤可能表示還原作業所需的某些目錄無法寫入。

Google Distributed Cloud 1.14 以上版本會顯示更清楚的錯誤訊息，說明哪些目錄必須可寫入。請確認報告中列出的目錄可供寫入，並視需要更新目錄權限。

備份後重新整理 SSH 金鑰會導致還原程序中斷

如果在執行備份後重新整理 SSH 金鑰，還原程序期間與 SSH 相關的作業可能會失敗。在這種情況下，新的 SSH 金鑰會失效，無法用於還原程序。

如要解決這個問題，可以暫時加回原始 SSH 金鑰，然後執行還原作業。還原程序完成後，即可輪替 SSH 金鑰。