このページでは、ベアメタル版 Anthos クラスタで作成したクラスタを、bmctl を使用してバックアップおよび復元する方法について説明します。以下の手順は、ベアメタル版 Anthos クラスタでサポートされているすべてのクラスタタイプに適用されます。
bmctl のバックアップと復元のプロセスには永続ボリュームは含まれません。ローカル ボリューム プロビジョナー（LVP）によって作成された Volume は、変更されません。
クラスタをバックアップする
bmctl backup cluster コマンドは、etcd ストアからのクラスタ情報と、指定したクラスタの PKI 証明書を tar ファイルに追加します。etcd ストアは、すべてのクラスタデータ用の Kubernetes バッキング ストアであり、クラスタの状態の管理に必要なすべての Kubernetes オブジェクトとカスタム オブジェクトを格納しています。PKI 証明書は TLS での認証に使用されます。このデータは、クラスタのコントロール プレーンか、高可用性（HA）デプロイメントのコントロール プレーンの 1 つからバックアップされます。
バックアップ tar ファイルには、サービス アカウント キーと SSH 認証鍵を含む機密性の高い認証情報が含まれています。バックアップ ファイルを安全な場所に保存してください。意図しないファイルの公開を防ぐため、ベアメタル版 Anthos クラスタのバックアップは、メモリ内ファイルのみを使用します。
クラスタは定期的にバックアップして、スナップショット データが比較的新しくなるようにしてください。バックアップの頻度は、クラスタへの大きな変更の頻度が反映されるように調整します。
クラスタのバックアップに使用する bmctl バージョンは、管理するクラスタのバージョンと一致する必要があります。
クラスタをバックアップするには:
すべてのノードでの使用中の認証情報と SSH 接続で、クラスタが正常に動作していることを確認します。
バックアップ プロセスの目的は、既知の正常な状態にあるクラスタをキャプチャして、重大な障害が発生した場合に運用を再開できるようにすることです。
次のコマンドを使用してクラスタを確認します。
bmctl check cluster -c CLUSTER_NAMECLUSTER_NAMEは、バックアップするクラスタの名前に置き換えます。次のコマンドを実行して、ターゲット クラスタが整合化状態ではないことを確認します。
kubectl describe cluster CLUSTER_NAME -n CLUSTER_NAMESPACE次のように置き換えます。
CLUSTER_NAME: バックアップするクラスタの名前。CLUSTER_NAMESPACE: クラスタの名前空間。デフォルトでは、ベアメタル版 Anthos クラスタのクラスタ名前空間は、先頭にcluster-が付いたクラスタの名前です。たとえば、クラスタにtestという名前を付けると、名前空間の名前はcluster-testのようになります。
「調整中」タイプの
status.conditionsのコマンド出力を確認します。これらの
status.conditionsのステータスが「False」の場合、クラスタは安定していて、バックアップの準備が整っています。次のコマンドを実行して、クラスタをバックアップします。
bmctl backup cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG次のように置き換えます。
CLUSTER_NAME: バックアップするクラスタの名前。ADMIN_KUBECONFIG: 管理クラスタの 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 認証鍵を含む機密性の高い認証情報が含まれています。意図しないファイルの公開を防ぐため、ベアメタル版 Anthos クラスタの復元ではメモリ内ファイルのみを使用します。
クラスタの復元に使用する bmctl バージョンは、管理するクラスタのバージョンと一致している必要があります。
クラスタを復元するには:
バックアップを作成したときにクラスタで使用可能だったすべてのノードマシンが正しく動作し、到達可能であることを確認します。
ノード間の SSH 接続が、バックアップ時に使用した SSH 認証鍵で機能することを確認します。
これらの SSH 認証鍵は、復元プロセスの一環として復元されます。
バックアップ時に使用されたサービス アカウント キーがまだ有効であることを確認します。
これらのサービス アカウント キーは、復元されたクラスタのために復元されます。
スタンドアロン クラスタ、セルフマネージド管理クラスタ、またはハイブリッド クラスタを復元するには、次のコマンドを実行します。
bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE次のように置き換えます。
CLUSTER_NAME: 復元するクラスタの名前。BACKUP_FILE: 使用しているバックアップ ファイルのパスと名前。
セルフマネージドではないユーザー クラスタ、管理クラスタ、ハイブリッド クラスタを復元するには、次のコマンドを実行します。
bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE \ --kubeconfig ADMIN_KUBECONFIG次のように置き換えます。
CLUSTER_NAME: 復元するクラスタの名前。BACKUP_FILE: 使用しているバックアップ ファイルのパスと名前。ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。
復元プロセスの最後には、復元されたクラスタ用に新しい kubeconfig ファイルが生成されます。