gkectl を使用して高度なクラスタをバックアップして復元する

このドキュメントでは、高度なクラスタが有効になっている Google Distributed Cloud バージョン 1.32 以降の管理クラスタとユーザー クラスタをバックアップして復元する方法について説明します。

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

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

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

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

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

始める前に、すべてのノードでの使用中の認証情報と SSH 接続で、クラスタが正常に動作していることを確認します。バックアップ プロセスの目的は、既知の正常な状態にあるクラスタをキャプチャして、重大な障害が発生した場合に運用を再開できるようにすることです。

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

  1. 次のコマンドを実行してクラスタを確認します。

    gkectl diagnose cluster --cluster-name CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG

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

    • CLUSTER_NAME: バックアップを計画するクラスタの名前。

    • ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。

  2. 該当するコマンドを実行して、クラスタをバックアップします。

    管理クラスタ

    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_2006-01-02T150405Z0700.tar.gz のようになります。バックアップ ファイルに異なる名前と場所を指定するには、--backup-file フラグを使用します。

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

管理クラスタ構成ファイル: clusterBackup に次のセクションが構成されている場合は、バックアップ ファイルを vCenter Server にアップロードすることもできます。

datastore: DATASTORE

DATASTORE は、バックアップを保存するデータストアに置き換えます。データストアは、管理クラスタと同じデータセンター内にある必要があります。バックアップは、指定したデータストアの anthos/CLUSTER_NAME/backup ディレクトリにあります。

クラスタを復元する

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

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

クラスタを復元する前に、次の条件を満たしていることを確認してください。

  • バックアップを作成したときにクラスタで使用可能だったすべてのコントロール プレーン ノードマシンが正しく動作し、到達可能であることを確認します。
  • ノード間の SSH 接続がバックアップ時に使用された SSH 認証鍵で動作することを確認します。これらの SSH 認証鍵は、復元プロセスの一環として復元されます。
  • バックアップ時に使用されたサービス アカウント キーがまだ有効であることを確認します。これらのサービス アカウント キーは、復元されたクラスタのために復元されます。

クラスタを復元するには:

  1. 該当するコマンドを実行してクラスタを復元します。

    管理クラスタ

    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 ファイルのパス。

    復元プロセスの最後に、復元されたクラスタ用に新しい kubeconfig ファイルがワークスペース ディレクトリ gkectl-workspace に生成されます。

  2. 復元が完了したら、次のコマンドを実行して復元が成功したことを確認します。

    gkectl diagnose cluster --cluster-name CLUSTER_NAME \
    --kubeconfig GENERATED_KUBECONFIG

    GENERATED_KUBECONFIG は、生成された kubeconfig ファイルに置き換えます。

トラブルシューティング

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

ご不明な点がございましたら、Cloud カスタマーケア チームまでお問い合わせください。

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

gkectl コマンドを実行するワークステーションの RAM が不足している場合は、バックアップまたは復元プロセスを行うためのメモリが不足している可能性があります。必要に応じて、バックアップ コマンドの --use-disk パラメータを使用して一時的なスクラッチ ディスクを作成し、バックアップまたは復元オペレーションを処理します。ファイル権限を保持するために、このパラメータによってファイルの権限が変更されるため、コマンドを root ユーザーとして実行する必要があります（または sudo を使用します）。

バックアップ後に SSH 鍵を更新すると、復元プロセスが中断される

バックアップが行われたに SSH 認証鍵が更新されると、復元プロセス中の SSH 関連のオペレーションが失敗することがあります。この場合、復元プロセスで新しい SSH 認証鍵は無効になります。この問題を解決するには、元の SSH 認証鍵を一時的に追加してから、復元を実行します。復元プロセスが完了したら、SSH 認証鍵をローテーションできます。