このドキュメントでは、高度なクラスタが有効になっている Google Distributed Cloud バージョン 1.32 以降の管理クラスタとユーザー クラスタをバックアップして復元する方法について説明します。
gkectl
のバックアップと復元のプロセスに永続ボリュームは含まれません。ローカル ボリューム プロビジョナー(LVP)によって作成されたボリュームは変更されません。
クラスタをバックアップする
gkectl backup cluster
コマンドによって、etcd ストアからのクラスタ情報と、指定したクラスタの PKI 証明書が tar ファイルに追加されます。etcd ストアは、すべてのクラスタデータ用の Kubernetes バッキング ストアであり、クラスタの状態の管理に必要なすべての Kubernetes オブジェクトとカスタム オブジェクトを格納しています。PKI 証明書は、Transport Layer Security(TLS)での認証に使用されます。このデータは、クラスタのコントロール プレーンか、高可用性(HA)デプロイメントのコントロール プレーンの 1 つからバックアップされます。
バックアップ 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_2006-01-02T150405Z0700.tar.gz
のようになります。バックアップ ファイルに異なる名前と場所を指定するには、--backup-file
フラグを使用します。
バックアップ ファイルは 1 年経つと期限切れになり、クラスタ復元プロセスは期限切れのバックアップ ファイルでは動作しません。
次のセクションが管理クラスタ構成ファイル: clusterBackup に構成されている場合は、バックアップ ファイルを vCenter Server にアップロードすることもできます。
datastore: DATASTORE
DATASTORE
は、バックアップを保存するデータストアに置き換えます。データストアは管理クラスタと同じデータセンター内にある必要があります。バックアップは、指定したデータストアの anthos/CLUSTER_NAME/backup
ディレクトリにあります。
クラスタを復元する
バックアップからクラスタを復元するのは最後の手段であり、クラスタに重大な障害が発生し、他の方法ではサービスを復旧できない場合にのみ行うべきです。たとえば、etcd データが破損している、あるいは Pod がクラッシュ ループの状態にある場合に使用します。
バックアップ 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 ファイルのパス。
復元プロセスの最後に、復元されたクラスタ用に新しい kubeconfig ファイルがワークスペース ディレクトリ
gkectl-workspace
に生成されます。復元が完了したら、次のコマンドを実行して、復元が成功したことを確認します。
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 認証鍵をローテーションできます。