このページでは、bmctl を使用して、ベアメタル上の Google Distributed Cloud（ソフトウェアのみ）で作成したクラスタをバックアップおよび復元する方法について説明します。これらの手順は、すべてのクラスタタイプに適用されます。
bmctl のバックアップと復元のプロセスには永続ボリュームは含まれません。ローカル ボリューム プロビジョナー（LVP）によって作成されたボリュームは変更されません。
クラスタをバックアップする
bmctl backup cluster コマンドは、etcd ストアからのクラスタ情報と、指定したクラスタの PKI 証明書を tar ファイルに追加します。etcd ストアは、すべてのクラスタデータ用の Kubernetes バッキング ストアであり、クラスタの状態の管理に必要なすべての Kubernetes オブジェクトとカスタム オブジェクトを格納しています。PKI 証明書は TLS での認証に使用されます。このデータは、クラスタのコントロール プレーンか、高可用性（HA）デプロイメントのコントロール プレーンの 1 つからバックアップされます。
バックアップ tar ファイルには、サービス アカウント キーと SSH 認証鍵を含む機密性の高い認証情報が含まれています。バックアップ ファイルを安全な場所に保存してください。意図しないファイルの公開を防ぐため、Google Distributed Cloud のバックアップ プロセスは、メモリ内ファイルのみを使用します。
クラスタは定期的にバックアップして、スナップショット データが比較的新しくなるようにしてください。バックアップの頻度は、クラスタへの大きな変更の頻度が反映されるように調整します。
クラスタのバックアップに使用する bmctl バージョンは、管理するクラスタのバージョンと一致する必要があります。
クラスタをバックアップするには:
すべてのノードでの使用中の認証情報と SSH 接続で、クラスタが正常に動作していることを確認します。
バックアップ プロセスの目的は、既知の正常な状態にあるクラスタをキャプチャして、重大な障害が発生した場合に運用を再開できるようにすることです。
次のコマンドを使用してクラスタを確認します。
bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG次のように置き換えます。
CLUSTER_NAME: バックアップを計画するクラスタの名前。ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。
次のコマンドを実行して、ターゲット クラスタが調整状態ではないことを確認します。
kubectl describe cluster CLUSTER_NAME -n CLUSTER_NAMESPACE --kubeconfig ADMIN_KUBECONFIG次のように置き換えます。
CLUSTER_NAME: バックアップするクラスタの名前。CLUSTER_NAMESPACE: クラスタの Namespace。デフォルトでは、Google Distributed Cloud のクラスタの Namespace は、先頭にcluster-が付いたクラスタの名前です。たとえば、クラスタにtestという名前を付けると、名前空間の名前はcluster-testのようになります。ADMIN_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。
コマンド出力の
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 ...次のコマンドを実行して、クラスタをバックアップします。
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 認証鍵を含む機密性の高い認証情報が含まれています。意図しないファイルの公開を防ぐため、Google Distributed Cloud の復元プロセスは、メモリ内ファイルのみを使用します。
クラスタの復元に使用する 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 ファイルが生成されます。
復元が完了したら、次の手順で復元が成功したことを確認します。
次のコマンドを実行して、生成された kubeconfig ファイルでノードの準備状況とシステム Pod が実行されていることを確認します。
etcd Pod には次の 2 種類があります。
etcd-HOST_NAME（メインのetcdPod に対応）etcd-events-HOST_NAME（etcd-eventsPod に対応）
kubectl get pods -n kube-system --kubeconfig GENERATED_KUBECONFIG kubectl get nodes --kubeconfig GENERATED_KUBECONFIG各 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各
etcd-eventsPod に対して、次のコマンドを実行して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 パラメータを使用できます。ファイル権限を保持するために、このパラメータによってファイルの権限が変更されるため、コマンドを実行するユーザーは root ユーザーである必要があります（または sudo を使用します）。
復元中にファイルへの権限がない
復元タスクが正常に終了すると、ブートストラップの削除が、次のようなエラーメッセージで失敗する場合があります。
Error: failed to restore node config files: sftp: "Failure" (SSH_FX_FAILURE)
このエラーによって、復元に必要な一部のディレクトリが書き込みできない可能性があります。
Google Distributed Cloud バージョン 1.14 以降では、書き込み可能なディレクトリに関するエラー メッセージがより明確になっています。報告されたディレクトリが書き込み可能であることを確認し、必要に応じてディレクトリの権限を更新してください。
バックアップ後に SSH 鍵を更新すると、復元プロセスが中断される
バックアップが行われたに SSH 認証鍵が更新されると、復元プロセス中の SSH 関連のオペレーションが失敗することがあります。この場合、復元プロセスで新しい SSH 認証鍵は無効になります。
この問題を解決するには、元の SSH 認証鍵を一時的に追加してから、復元を実行します。復元プロセスが完了したら、SSH 認証鍵をローテーションできます。