第4章 etcd データのバックアップと復元
4.1. etcd データのバックアップと復元 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform のキー値ストアとして、etcd はすべてのリソースオブジェクトの状態を保持します。
クラスターの etcd データを定期的にバックアップし、セキュアな場所 (理想的には OpenShift Container Platform 環境の外部) に保存します。インストールの 24 時間後に行われる最初の証明書のローテーションが完了するまで etcd のバックアップを実行することはできません。ローテーションの完了前に実行すると、バックアップに期限切れの証明書が含まれることになります。etcd スナップショットは I/O コストが高いため、ピーク使用時間以外に etcd バックアップを取得することも推奨します。
クラスターを更新する前に、必ず etcd のバックアップを作成してください。クラスターを復元するときに、同じ z-stream リリースから取得した etcd バックアップを使用する必要があるため、更新する前にバックアップを作成することが重要です。たとえば、OpenShift Container Platform 4.17.5 クラスターでは、4.17.5 から取得した etcd バックアップを使用する必要があります。
コントロールプレーンホストでバックアップスクリプトの単一の呼び出しを実行して、クラスターの etcd データをバックアップします。各コントロールプレーンホストのバックアップを取得しないでください。
etcd のバックアップを作成した後に、クラスターの直前の状態への復元 を実行できます。
4.1.1. etcd データのバックアップ リンクのコピーリンクがクリップボードにコピーされました!
以下の手順に従って、etcd スナップショットを作成し、静的 Pod のリソースをバックアップして etcd データをバックアップします。このバックアップは保存でき、etcd を復元する必要がある場合に後で使用することができます。
単一のコントロールプレーンホストからのバックアップのみを保存します。クラスター内の各コントロールプレーンホストからのバックアップは取得しないでください。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 クラスター全体のプロキシーが有効になっているかどうかを確認している。
ヒントoc get proxy cluster -o yamlの出力を確認して、プロキシーが有効にされているかどうかを確認できます。プロキシーは、httpProxy、httpsProxy、およびnoProxyフィールドに値が設定されている場合に有効にされます。
手順
コントロールプレーンノードの root としてデバッグセッションを開始します。
$ oc debug --as-root node/<node_name>デバッグシェルで root ディレクトリーを
/hostに変更します。sh-4.4# chroot /hostクラスター全体のプロキシーが有効になっている場合は、次のコマンドを実行して、
NO_PROXY、HTTP_PROXY、およびHTTPS_PROXY環境変数をエクスポートします。$ export HTTP_PROXY=http://<your_proxy.example.com>:8080$ export HTTPS_PROXY=https://<your_proxy.example.com>:8080$ export NO_PROXY=<example.com>デバッグシェルで
cluster-backup.shスクリプトを実行し、バックアップの保存先となる場所を渡します。ヒントcluster-backup.shスクリプトは etcd Cluster Operator のコンポーネントとして維持され、etcdctl snapshot saveコマンドに関連するラッパーです。sh-4.4# /usr/local/bin/cluster-backup.sh /home/core/assets/backupスクリプトの出力例
found latest kube-apiserver: /etc/kubernetes/static-pod-resources/kube-apiserver-pod-6 found latest kube-controller-manager: /etc/kubernetes/static-pod-resources/kube-controller-manager-pod-7 found latest kube-scheduler: /etc/kubernetes/static-pod-resources/kube-scheduler-pod-6 found latest etcd: /etc/kubernetes/static-pod-resources/etcd-pod-3 ede95fe6b88b87ba86a03c15e669fb4aa5bf0991c180d3c6895ce72eaade54a1 etcdctl version: 3.4.14 API version: 3.4 {"level":"info","ts":1624647639.0188997,"caller":"snapshot/v3_snapshot.go:119","msg":"created temporary db file","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db.part"} {"level":"info","ts":"2021-06-25T19:00:39.030Z","caller":"clientv3/maintenance.go:200","msg":"opened snapshot stream; downloading"} {"level":"info","ts":1624647639.0301006,"caller":"snapshot/v3_snapshot.go:127","msg":"fetching snapshot","endpoint":"https://10.0.0.5:2379"} {"level":"info","ts":"2021-06-25T19:00:40.215Z","caller":"clientv3/maintenance.go:208","msg":"completed snapshot read; closing"} {"level":"info","ts":1624647640.6032252,"caller":"snapshot/v3_snapshot.go:142","msg":"fetched snapshot","endpoint":"https://10.0.0.5:2379","size":"114 MB","took":1.584090459} {"level":"info","ts":1624647640.6047094,"caller":"snapshot/v3_snapshot.go:152","msg":"saved","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db"} Snapshot saved at /home/core/assets/backup/snapshot_2021-06-25_190035.db {"hash":3866667823,"revision":31407,"totalKey":12828,"totalSize":114446336} snapshot db and kube resources are successfully saved to /home/core/assets/backupこの例では、コントロールプレーンホストの
/home/core/assets/backup/ディレクトリーにファイルが 2 つ作成されます。-
snapshot_<datetimestamp>.db: このファイルは etcd スナップショットです。cluster-backup.shスクリプトで、その有効性を確認します。 static_kuberesources_<datetimestamp>.tar.gz: このファイルには、静的 Pod のリソースが含まれます。etcd 暗号化が有効にされている場合、etcd スナップショットの暗号化キーも含まれます。注記etcd 暗号化が有効にされている場合、セキュリティー上の理由から、この 2 つ目のファイルを etcd スナップショットとは別に保存することが推奨されます。ただし、このファイルは etcd スナップショットから復元するために必要になります。
etcd 暗号化はキーではなく値のみを暗号化することに注意してください。つまり、リソースタイプ、namespace、およびオブジェクト名は暗号化されません。
-
4.1.2. 自動 etcd バックアップの作成 リンクのコピーリンクがクリップボードにコピーされました!
etcd の自動バックアップ機能は、繰り返しバックアップとシングルバックアップの両方をサポートします。繰り返しバックアップでは、ジョブがトリガーされるたびにシングルバックアップを開始する cron ジョブが作成されます。
etcd バックアップの自動化はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、以下のリンクを参照してください。
etcd の自動バックアップを有効にするには、次の手順を実行します。
クラスターで TechPreviewNoUpgrade 機能セットを有効にすると、マイナーバージョンの更新ができなくなります。TechPreviewNoUpgrade 機能セットは無効にできません。実稼働クラスターではこの機能セットを有効にしないでください。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc) にアクセスできる。
手順
次の内容で、
enable-tech-preview-no-upgrade.yamlという名前のFeatureGateカスタムリソース (CR) ファイルを作成します。apiVersion: config.openshift.io/v1 kind: FeatureGate metadata: name: cluster spec: featureSet: TechPreviewNoUpgradeCR を適用し、自動バックアップを有効にします。
$ oc apply -f enable-tech-preview-no-upgrade.yaml関連する API を有効にするのに時間がかかります。次のコマンドを実行して、カスタムリソース定義 (CRD) が作成されたことを確認します。
$ oc get crd | grep backup出力例
backups.config.openshift.io 2023-10-25T13:32:43Z etcdbackups.operator.openshift.io 2023-10-25T13:32:04Z
4.1.2.1. 単一の自動化された etcd バックアップの作成 リンクのコピーリンクがクリップボードにコピーされました!
次の手順でカスタムリソース (CR) を作成して適用することで、シングル etcd バックアップを作成します。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc) にアクセスできる。
手順
動的にプロビジョニングされたストレージが利用可能な場合は、次の手順を実行して、単一の自動 etcd バックアップを作成します。
次の例のような内容で、
etcd-backup-pvc.yamlという名前の永続ボリューム要求 (PVC) を作成します。kind: PersistentVolumeClaim apiVersion: v1 metadata: name: etcd-backup-pvc namespace: openshift-etcd spec: accessModes: - ReadWriteOnce resources: requests: storage: 200Gi1 volumeMode: Filesystem以下のコマンドを実行して PVC を適用します。
$ oc apply -f etcd-backup-pvc.yaml次のコマンドを実行して、PVC が作成されたことを確認します。
$ oc get pvc出力例
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE etcd-backup-pvc Bound 51s注記動的 PVC は、マウントされるまで
Pending状態から遷移しません。次の例のような内容で、
etcd-single-backup.yamlという名前の CR ファイルを作成します。apiVersion: operator.openshift.io/v1alpha1 kind: EtcdBackup metadata: name: etcd-single-backup namespace: openshift-etcd spec: pvcName: etcd-backup-pvc1 - 1
- バックアップを保存する PVC の名前。この値は、使用している環境に応じて調整してください。
CR を適用してシングルバックアップを開始します。
$ oc apply -f etcd-single-backup.yaml
動的にプロビジョニングされたストレージが利用できない場合は、次の手順を実行して、単一の自動 etcd バックアップを作成します。
次の内容で、
etcd-backup-local-storage.yamlという名前のStorageClassCR ファイルを作成します。apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: etcd-backup-local-storage provisioner: kubernetes.io/no-provisioner volumeBindingMode: Immediate次のコマンドを実行して、
StorageClassCR を適用します。$ oc apply -f etcd-backup-local-storage.yaml次の例のような内容の
etcd-backup-pv-fs.yamlという名前の PV を作成します。apiVersion: v1 kind: PersistentVolume metadata: name: etcd-backup-pv-fs spec: capacity: storage: 100Gi1 volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: etcd-backup-local-storage local: path: /mnt nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - <example_master_node>2 次のコマンドを実行して、PV が作成されたことを確認します。
$ oc get pv出力例
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE etcd-backup-pv-fs 100Gi RWO Retain Available etcd-backup-local-storage 10s次の例のような内容で、
etcd-backup-pvc.yamlという名前の PVC を作成します。kind: PersistentVolumeClaim apiVersion: v1 metadata: name: etcd-backup-pvc namespace: openshift-etcd spec: accessModes: - ReadWriteOnce volumeMode: Filesystem resources: requests: storage: 10Gi1 - 1
- PVC に利用できるストレージの量。この値は、要件に合わせて調整します。
以下のコマンドを実行して PVC を適用します。
$ oc apply -f etcd-backup-pvc.yaml次の例のような内容で、
etcd-single-backup.yamlという名前の CR ファイルを作成します。apiVersion: operator.openshift.io/v1alpha1 kind: EtcdBackup metadata: name: etcd-single-backup namespace: openshift-etcd spec: pvcName: etcd-backup-pvc1 - 1
- バックアップを保存する永続ボリューム要求 (PVC) の名前。この値は、使用している環境に応じて調整してください。
CR を適用してシングルバックアップを開始します。
$ oc apply -f etcd-single-backup.yaml
4.1.2.2. 定期的な自動 etcd バックアップの作成 リンクのコピーリンクがクリップボードにコピーされました!
etcd の自動繰り返しバックアップを作成するには、次の手順に従います。
可能であれば、動的にプロビジョニングされたストレージを使用して、作成された etcd バックアップデータを安全な外部の場所に保存します。動的にプロビジョニングされたストレージが利用できない場合は、バックアップの復元にアクセスしやすくするために、バックアップデータを NFS 共有に保存することを検討してください。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc) にアクセスできる。
手順
動的にプロビジョニングされたストレージが利用可能な場合は、次の手順を実行して、自動化された繰り返しバックアップを作成します。
次の例のような内容で、
etcd-backup-pvc.yamlという名前の永続ボリューム要求 (PVC) を作成します。kind: PersistentVolumeClaim apiVersion: v1 metadata: name: etcd-backup-pvc namespace: openshift-etcd spec: accessModes: - ReadWriteOnce resources: requests: storage: 200Gi1 volumeMode: Filesystem storageClassName: etcd-backup-local-storage- 1
- PVC に利用できるストレージの量。この値は、要件に合わせて調整します。
注記次の各プロバイダーでは、
accessModesキーとstorageClassNameキーを変更する必要があります。Expand Provider accessModes値storageClassName値versioned-installer-efc_operator-ciプロファイルを持つ AWS- ReadWriteManyefs-scGoogle Cloud
- ReadWriteManyfilestore-csiMicrosoft Azure
- ReadWriteManyazurefile-csi以下のコマンドを実行して PVC を適用します。
$ oc apply -f etcd-backup-pvc.yaml次のコマンドを実行して、PVC が作成されたことを確認します。
$ oc get pvc出力例
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE etcd-backup-pvc Bound 51s注記動的 PVC は、マウントされるまで
Pending状態から遷移しません。
動的にプロビジョニングされたストレージが使用できない場合は、次の手順を実行してローカルストレージ PVC を作成します。
警告保存されているバックアップデータが格納されたノードを削除するか、該当ノードへのアクセスを失うと、データが失われる可能性があります。
次の内容で、
etcd-backup-local-storage.yamlという名前のStorageClassCR ファイルを作成します。apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: etcd-backup-local-storage provisioner: kubernetes.io/no-provisioner volumeBindingMode: Immediate次のコマンドを実行して、
StorageClassCR を適用します。$ oc apply -f etcd-backup-local-storage.yaml適用された
StorageClassから、次の例のような内容のetcd-backup-pv-fs.yamlという名前の PV を作成します。apiVersion: v1 kind: PersistentVolume metadata: name: etcd-backup-pv-fs spec: capacity: storage: 100Gi1 volumeMode: Filesystem accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Delete storageClassName: etcd-backup-local-storage local: path: /mnt/ nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - <example_master_node>2 ヒント次のコマンドを実行して、使用可能なノードのリストを表示します。
$ oc get nodes次のコマンドを実行して、PV が作成されたことを確認します。
$ oc get pv出力例
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE etcd-backup-pv-fs 100Gi RWX Delete Available etcd-backup-local-storage 10s次の例のような内容で、
etcd-backup-pvc.yamlという名前の PVC を作成します。kind: PersistentVolumeClaim apiVersion: v1 metadata: name: etcd-backup-pvc spec: accessModes: - ReadWriteMany volumeMode: Filesystem resources: requests: storage: 10Gi1 storageClassName: etcd-backup-local-storage- 1
- PVC に利用できるストレージの量。この値は、要件に合わせて調整します。
以下のコマンドを実行して PVC を適用します。
$ oc apply -f etcd-backup-pvc.yaml
etcd-recurring-backups.yamlという名前のカスタムリソース定義 (CRD) ファイルを作成します。作成された CRD の内容は、自動化されたバックアップのスケジュールと保持タイプを定義します。15 個のバックアップを保持する
RetentionNumberのデフォルトの保持タイプでは、次の例のような内容を使用します。apiVersion: config.openshift.io/v1alpha1 kind: Backup metadata: name: etcd-recurring-backup spec: etcd: schedule: "20 4 * * *"1 timeZone: "UTC" pvcName: etcd-backup-pvc- 1
- 定期的なバックアップの
CronTabスケジュール。この値は、必要に応じて調整します。
バックアップの最大数に基づいて保持を使用するには、次のキーと値のペアを
etcdキーに追加します。spec: etcd: retentionPolicy: retentionType: RetentionNumber1 retentionNumber: maxNumberOfBackups: 52 警告既知の問題により、保持されるバックアップの数が設定された値に 1 を加えた数になります。
バックアップのファイルサイズに基いて保持する場合は、以下を使用します。
spec: etcd: retentionPolicy: retentionType: RetentionSize retentionSize: maxSizeOfBackupsGb: 201 - 1
- 保持するバックアップの最大ファイルサイズ (ギガバイト単位)。この値は、必要に応じて調整します。指定しない場合、デフォルトは 10 GB になります。
警告既知の問題により、保持されるバックアップの最大サイズが設定値より最大 10 GB 大きくなります。
次のコマンドを実行して、CRD で定義される cron ジョブを作成します。
$ oc create -f etcd-recurring-backup.yaml作成された cron ジョブを検索するには、次のコマンドを実行します。
$ oc get cronjob -n openshift-etcd