このページでは、ベアメタル版 Anthos クラスタを使用して作成したクラスタをバックアップおよび復元する方法について説明します。以下の手順は、ベアメタル版 Anthos クラスタでサポートされているすべてのクラスタタイプに適用されます。
クラスタをバックアップする
バックアップ プロセスは 2 つの要素で構成されています。まず、スナップショットが etcd ストアから作成されます。次に、関連する PKI 証明書が tar ファイルに保存されます。etcd ストアは、すべてのクラスタデータ用の Kubernetes バッキング ストアであり、クラスタの状態の管理に必要なすべての Kubernetes オブジェクトとカスタム オブジェクトを格納しています。PKI 証明書は TLS での認証に使用されます。このデータは、クラスタのコントロール プレーンか、高可用性(HA)デプロイメントのコントロール プレーンの 1 つからバックアップされます。
クラスタは定期的にバックアップして、スナップショット データを比較的最新の状態に保つことをおすすめします。バックアップの頻度は、クラスタに大きな変更が発生する頻度によります。
etcd ストアのスナップショットを作成する
ベアメタル版 Anthos クラスタでは、kube-system Namespace 内の etcd-CONTROL_PLANE_NAME
という名前の Pod が、そのコントロール プレーンの etcd を実行します。クラスタの etcd ストアをバックアップするには、管理ワークステーションから次の手順を行います。
kubectl get po
を使用して、etcd Pod を特定します。kubectl --kubeconfig CLUSTER_KUBECONFIG get po -n kube-system \ -l 'component=etcd,tier=control-plane'
レスポンスには、etcd Pod 名とステータスが含まれます。
kubectl describe pod
を使用して、etcd Pod で実行されているコンテナ(etcd コンテナを含む)を確認します。kubectl --kubeconfig CLUSTER_KUBECONFIG describe pod ETCD_POD_NAME -n kube-system
etcd コンテナで Bash シェルを実行します。
kubectl --kubeconfig CLUSTER_KUBECONFIG exec -it \ ETCD_POD_NAME --container etcd --namespace kube-system \ -- bin/sh
etcd コンテナ内のシェルから、
etcdctl
(API のバージョン 3)を使用して、etcd ストアのスナップショットであるsnapshot.db
を保存します。ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/peer.crt \ --key=/etc/kubernetes/pki/etcd/peer.key \ snapshot save /tmp/snapshotDATESTAMP.db
DATESTAMP は、現在の日付に置き換えて、後続のスナップショットが上書きされないようにします。
コンテナ内のシェルを終了し、次のコマンドを実行して、スナップショット ファイルを管理ワークステーションにコピーします。
kubectl --kubeconfig CLUSTER_KUBECONFIG cp \ kube-system/ETCD_POD_NAME:/tmp/snapshot.db \ --container etcd snapshot.db
etcd Pod から
etcdctl
バイナリをコピーして、復元プロセス中に同じバイナリを使用できるようにします。kubectl --kubeconfig CLUSTER_KUBECONFIG cp \ kube-system/ETCD_POD_NAME:/usr/local/bin/etcdctl \ --container etcd etcdctl
クラスタの外部でクラスタの運用の影響を受けない場所に、スナップショット ファイルと
etcdctl
バイナリを保存します。
PKI 証明書をアーカイブする
バックアップされる証明書は、コントロール プレーンの /etc/kubernetes/pki
ディレクトリにあります。コントロール プレーンが完全にダウンした場合、クラスタを復元するには、PID 証明書と etcd ストアの snapshot.db
ファイルが必要です。次の手順では、PKI 証明書を含む tar ファイルを作成します。
ssh
を使用して、クラスタのコントロール プレーンに root として接続します。ssh root@CONTROL_PLANE_NAME
コントロール プレーンで、
/etc/kubernetes/pki
ディレクトリの内容を含む tar ファイルcerts_backup.tar.gz
を作成します。tar -czvf certs_backup.tar.gz -C /etc/kubernetes/pki .
コントロール プレーン内から tar ファイルの作成を行うと、すべての証明書ファイルの権限が保持されます。
コントロール プレーンを終了し、ワークステーションで証明書を含む tar ファイルをワークステーションの任意の場所にコピーします。
sudo scp root@CONTROL_PLANE_NAME:certs_backup.tar.gz BACKUP_PATH
クラスタを復元する
バックアップからのクラスタの復元は最後の手段です。クラスタにおいて重大な障害が発生したため、他の方法ではサービスに戻ることができない場合に使用する必要があります。たとえば、etcd データが破損している、etcd Pod がクラッシュ ループの状態にある場合に使用します。
クラスタの復元プロセスは 2 つの要素で構成されています。まず、PKI 証明書がコントロール プレーンで復元されます。その後、etcd ストアデータが復元されます。
PKI 証明書を復元する
PKI 証明書をアーカイブするの説明に沿って PKI 証明書をバックアップしたことを前提として、次の手順では、tar ファイルからコントロール プレーンに証明書を復元する方法について説明します。
PKI 証明書の tar ファイル
certs_backup.tar.gz
をワークステーションからクラスタのコントロール プレーンにコピーします。sudo scp -r BACKUP_PATH/certs_backup.tar.gz root@CONTROL_PLANE_NAME:~/
ssh
を使用して、クラスタのコントロール プレーンに root として接続します。ssh root@CONTROL_PLANE_NAME
コントロール プレーンから、
/etc/kubernetes/pki
ディレクトリに tar ファイルの内容を抽出します。tar -xzvf certs_backup.tar.gz -C /etc/kubernetes/pki/
コントロール プレーンを終了します。
etcd ストアを復元する
etcd ストアを復元する場合、このプロセスは、クラスタが高可用性(HA)モードで実行されているかどうかによって異なります。HA モードで実行されている場合は、クォーラムが保持されているかどうかによって異なります。特定のクラスタ障害が発生した場合は、次のガイドを使用して etcd ストアを復元してください。
失敗したクラスタが HA モードで実行されていない場合は、次の手順に沿ってコントロール プレーンの etcd ストアを復元します。
クラスタが HA モードで実行されており、クォーラムが保持されている場合は何も操作しません。クォーラムが保持されている限り、障害が発生したクラスタを復元する必要はありません。
クラスタが HA モードで動作している際にクォーラムを失った場合は、次の手順を繰り返して、障害が発生したメンバーごとに etcd ストアを復元してください。
ワークステーションでコントロール プレーンの etcd ストアを削除して復元するには、以下の手順に沿って操作します。
/backup
ディレクトリを、コントロール プレーンのルート ディレクトリに作成します。ssh root@CONTROL_PLANE_NAME "mkdir /backup"
このステップは厳密に必須ではありませんが、行っていただくことをおすすめします。次の手順では、
/backup
ディレクトリを作成済みであることを前提としています。etcd スナップショット ファイル、
snapshot.db
およびetcdctl
バイナリをワークステーションからクラスタ コントロール プレーンのbackup
ディレクトリにコピーします。sudo scp snapshot.db root@CONTROL_PLANE_NAME:/backup sudo scp etcdctl root@CONTROL_PLANE_NAME:/backup
SSH を使用して管理コントロール プレーンノードに接続します。
ssh root@CONTROL_PLANE_NAME
マニフェスト ファイルを
/etc/kubernetes/manifests
ディレクトリから/backup
ディレクトリに移動して、etcd と kube-apiserver の静的 Pod を停止します。sudo mv /etc/kubernetes/manifests/etcd.yaml /backup/etcd.yaml sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml /backup/kube-apiserver.yaml
etcd データ ディレクトリを削除します。
rm -rf /var/lib/etcd/
保存したバイナリを使用して、
etcdctl
のスナップショットの復元を実行します。sudo chmod +x /backup/etcdctl sudo ETCDCTL_API=3 /backup/etcdctl \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ --data-dir=/var/lib/etcd \ --name=CONTROL_PLANE_NAME \ --initial-advertise-peer-urls=https://CONTROL_PLANE_IP:2380 \ --initial-cluster=CONTROL_PLANE_NAME=https://CONTROL_PLANE_IP:2380 \ snapshot restore /backup/snapshot.db
--name
、--initial-advertise-peer-urls
、--initial-cluster
の項目は、/backup
ディレクトリに移動されたetcd.yaml
マニフェスト ファイルにあります。/var/lib/etcd
が再作成され、/var/lib/etcd/member
に新しいメンバーが作成されたことを確認します。/var/lib/etcd/member
ディレクトリのオーナーを2003
に変更します。ベアメタル リリース1.10.0
の Anthos クラスタ以降では、etcd
コンテナは UID と GID が2003
である root 以外のユーザーとして実行されます。sudo chown -R 2003:2003 /var/lib/etcd
静的 Pod が再起動できるように、etcd および kube-apiserver マニフェストを
/manifests
ディレクトリに戻します。sudo mv /backup/etcd.yaml /etc/kubernetes/manifests/etcd.yaml sudo mv /backup/kube-apiserver.yaml /etc/kubernetes/manifests/kube-apiserver.yaml
etcd コンテナで Bash シェルを実行します。
kubectl --kubeconfig CLUSTER_KUBECONFIG exec -it \ ETCD_POD_NAME --container etcd --namespace kube-system \ -- bin/sh
etcdctl
を使用して、追加したメンバーが正常に機能していることを確認します。
ETCDCTL_API=3 etcdctl --cert=/etc/kubernetes/pki/etcd/peer.crt \ --key=/etc/kubernetes/pki/etcd/peer.key \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --endpoints=CONTROL_PLANE_IP:2379 \ endpoint health
エラーが発生した複数のメンバーを復元する場合は、エラーが発生したメンバーをすべて復元したら、「--endpoints」フィールドにすべての復元済みメンバーのコントロール プレーンの IP アドレスを指定してコマンドを実行します。
例:
ETCDCTL_API=3 etcdctl --cert=/etc/kubernetes/pki/etcd/peer.crt \ --key=/etc/kubernetes/pki/etcd/peer.key \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --endpoints=10.200.0.3:2379,10.200.0.4:2379,10.200.0.5:2379 \ endpoint health
各エンドポイントで成功した場合は、クラスタは適切に機能しています。