bmctl を使用したクラスタのバックアップと復元

このページでは、GDCV for Bare Metal で作成したクラスタのバックアップや復元を、bmctl を使用して行う方法について説明します。以下の手順は、GKE on Bare Metal でサポートされているすべてのクラスタタイプに適用されます。

bmctl のバックアップと復元のプロセスには永続ボリュームは含まれません。ローカル ボリューム プロビジョナー（LVP）によって作成された Volume は、変更されません。

クラスタをバックアップする

bmctl backup cluster コマンドは、etcd ストアからのクラスタ情報と、指定したクラスタの PKI 証明書を tar ファイルに追加します。etcd ストアは、すべてのクラスタデータ用の Kubernetes バッキング ストアであり、クラスタの状態の管理に必要なすべての Kubernetes オブジェクトとカスタム オブジェクトを格納しています。PKI 証明書は TLS での認証に使用されます。このデータは、クラスタのコントロール プレーンか、高可用性（HA）デプロイメントのコントロール プレーンの 1 つからバックアップされます。

バックアップ tar ファイルには、サービス アカウント キーと SSH 認証鍵を含む機密性の高い認証情報が含まれています。バックアップ ファイルを安全な場所に保存してください。意図しないファイルの公開を防ぐため、GKE on Bare Metal のバックアップ プロセスは、メモリ内ファイルのみを使用します。

クラスタは定期的にバックアップして、スナップショット データが比較的新しくなるようにしてください。バックアップの頻度は、クラスタへの大きな変更の頻度が反映されるように調整します。

クラスタのバックアップに使用する bmctl バージョンは、管理するクラスタのバージョンと一致する必要があります。

クラスタをバックアップするには:

  1. すべてのノードでの使用中の認証情報と SSH 接続で、クラスタが正常に動作していることを確認します。

    バックアップ プロセスの目的は、既知の正常な状態にあるクラスタをキャプチャして、重大な障害が発生した場合に運用を再開できるようにすることです。

    次のコマンドを使用してクラスタを確認します。

    bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBEONFIG

    次のように置き換えます。

    • CLUSTER_NAME: バックアップを計画するクラスタの名前。
    • ADMIN_KUBEONFIG: 管理クラスタの kubeconfig ファイルのパス。

  2. 次のコマンドを実行して、ターゲット クラスタが整合化状態ではないことを確認します。

    kubectl describe cluster CLUSTER_NAME -n CLUSTER_NAMESPACE --kubeconfig ADMIN_KUBEONFIG

    次のように置き換えます。

    • CLUSTER_NAME: バックアップするクラスタの名前。
    • CLUSTER_NAMESPACE: クラスタの名前空間。デフォルトでは GKE on Bare Metal のクラスタ名前空間は、先頭に cluster- が付いたクラスタの名前です。たとえば、クラスタに test という名前を付けると、名前空間の名前は cluster-test のようになります。
    • ADMIN_KUBEONFIG: 管理クラスタの 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_KUBEONFIG

    次のように置き換えます。

    • CLUSTER_NAME: バックアップするクラスタの名前。
    • ADMIN_KUBEONFIG: 管理クラスタの kubeconfig ファイルのパス。

    デフォルトでは、管理ワークステーションのワークスペース ディレクトリ（デフォルトでは bmctl-workspace）に保存されたバックアップ tar ファイルです。tar ファイルの名前は CLUSTER_NAME_backup_TIMESTAMP.tar.gz です。ここで、CLUSTER_NAME はバックアップされるクラスタの名前、TIMESTAMP はバックアップが実行された日時です。たとえば、クラスタ名が testuser の場合、バックアップ ファイルの名前は testuser_backup_2006-01-02T150405Z0700.tar.gz のようになります。

    バックアップ ファイルに異なる名前と場所を指定するには、--backup-file フラグを使用します。

バックアップ ファイルは 1 年経つと期限切れになり、クラスタ復元プロセスは期限切れのバックアップ ファイルでは動作しません。

クラスタを復元する

バックアップからのクラスタの復元は最後の手段です。クラスタにおいて重大な障害が発生したため、他の方法ではサービスに戻ることができない場合に使用する必要があります。たとえば、etcd データが破損している、etcd Pod がクラッシュ ループの状態にある場合に使用します。

バックアップ tar ファイルには、サービス アカウント キーと SSH 認証鍵を含む機密性の高い認証情報が含まれています。意図しないファイルの公開を防ぐため、GKE on Bare Metal の復元プロセスは、メモリ内ファイルのみを使用します。

クラスタの復元に使用する 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_KUBEONFIG

    次のように置き換えます。

    • CLUSTER_NAME: 復元するクラスタの名前。
    • BACKUP_FILE: 使用しているバックアップ ファイルのパスと名前。
    • ADMIN_KUBEONFIG: 管理クラスタの kubeconfig ファイルのパス。

復元プロセスの最後には、復元されたクラスタ用に新しい kubeconfig ファイルが生成されます。

トラブルシューティング

バックアップまたは復元のプロセスに問題がある場合は、以降のセクションが問題のトラブルシューティングに役立つことがあります。

さらにサポートが必要な場合は、Google サポートにお問い合わせください。

バックアップまたは復元中のメモリ不足

バックアップや復元プロセス中に、次のステップで自明または明確でないエラー メッセージが表示されることがあります。bmctl コマンドを実行するワークステーションの RAM が不足している場合は、バックアップまたは復元プロセスを行うためのメモリが不足している可能性があります。

GDCV for Bare Metal のバージョン 1.13 以降では、バックアップ コマンドに --use-disk パラメータを使用できます。ファイル権限を保持するために、このパラメータによってファイルの権限が変更されるため、コマンドを実行するユーザーは root ユーザーである必要があります（または sudo を使用します）。

復元中にファイルへの権限がない

復元タスクが正常に終了すると、ブートストラップの削除が、次のようなエラーメッセージで失敗する場合があります。

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

このエラーによって、復元に必要な一部のディレクトリが書き込みできない可能性があります。

GDCV for Bare Metal バージョン 1.14 以降では、書き込み可能なディレクトリに関するエラー メッセージがより明確になっています。報告されたディレクトリが書き込み可能であることを確認し、必要に応じてディレクトリの権限を更新してください。

バックアップで復元プロセスが中断した後に SSH 認証鍵を更新する

バックアップが行われたに SSH 認証鍵が更新されると、復元プロセス中の SSH 関連のオペレーションが失敗することがあります。この場合、復元プロセスで新しい SSH 認証鍵は無効になります。

この問題を解決するには、元の SSH 認証鍵を一時的に追加してから、復元を実行します。復元プロセスが完了したら、SSH 認証鍵をローテーションできます。