クラスタのバックアップと復元

このページでは、ベアメタル版 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/healthcheck-client.crt \
    --key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
    snapshot save snapshotDATESTAMP.db
```
DATESTAMP は、現在の日付に置き換えて、後続のスナップショットが上書きされないようにします。
コンテナ内のシェルを終了し、次のコマンドを実行して、スナップショットファイルを管理ワークステーションにコピーします。
```
kubectl --kubeconfig CLUSTER_KUBECONFIG cp \
    kube-system/ETCD_POD_NAME:snapshot.db \
    --container etcd snapshot.db
```
スナップショットファイルをクラスタの外部に存在し、クラスタのオペレーションに依存しない場所に保存してください。

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）をワークステーションからクラスタコントロールプレーンの backup ディレクトリにコピーします。
```
sudo scp snapshot.db 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/
```

docker を使用して etcdctl のスナップショットの復元を実行します。

sudo docker run --rm -t \
    -v /var/lib:/var/lib \
    -v /etc/kubernetes/pki/etcd:/etc/kubernetes/pki/etcd \
    -v /backup:/backup \
    --env ETCDCTL_API=3 \
    k8s.gcr.io/etcd:3.2.24 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 に新しいメンバーが作成されたことを確認します。

静的 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/healthcheck-client.crt  \
    --key=/etc/kubernetes/pki/etcd/healthcheck-client.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/healthcheck-client.crt  \
    --key=/etc/kubernetes/pki/etcd/healthcheck-client.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

各エンドポイントで成功した場合は、クラスタは適切に機能しています。