バックアップおよび復元
OpenShift Container Platform クラスターのバックアップおよび復元
概要
第1章 バックアップおよび復元
1.1. コントロールプレーンのバックアップおよび復元の操作
クラスター管理者は、OpenShift Container Platform クラスターを一定期間停止し、後で再起動する必要がある場合があります。クラスターを再起動する理由として、クラスターでメンテナンスを実行する必要がある、またはリソースコストを削減する必要がある、などが挙げられます。OpenShift Container Platform では、クラスターの正常なシャットダウン を実行して、後でクラスターを簡単に再起動できます。
クラスターをシャットダウンする前に etcd データをバックアップする 必要があります。etcd は OpenShift Container Platform のキーと値のストアであり、すべてのリソースオブジェクトの状態を保存します。etcd のバックアップは、障害復旧で重要なロールを果たします。OpenShift Container Platform では、正常でない etcd メンバーを置き換える こともできます。
クラスターを再度実行する場合は、クラスターを正常に再起動します。
クラスターの証明書は、インストール日から 1 年後に有効期限が切れます。証明書が有効である間は、クラスターをシャットダウンし、正常に再起動することができます。クラスターは、期限切れのコントロールプレーン証明書を自動的に取得しますが、証明書署名要求 (CSR) を承認する 必要があります。
以下のように、OpenShift Container Platform が想定どおりに機能しないさまざまな状況に直面します。
- ノードの障害やネットワーク接続の問題などの予期しない状態により、再起動後にクラスターが機能しない。
- 誤ってクラスターで重要なものを削除した。
- 大多数のコントロールプレーンホストが失われたため、etcd のクォーラム (定足数) を喪失した。
保存した etcd スナップショットを使用して、クラスターを以前の状態に復元して、障害状況から常に回復できます。
1.2. アプリケーションのバックアップおよび復元の操作
クラスター管理者は、OpenShift API for Data Protection (OADP) を使用して、OpenShift Container Platform で実行しているアプリケーションをバックアップおよび復元できます。
OADP は、Velero CLI ツールのダウンロード の表に従って、インストールする OADP のバージョンに適したバージョンの Velero を使用して、namespace のレベルで Kubernetes リソースと内部イメージをバックアップおよび復元します。OADP は、スナップショットまたは Restic を使用して、永続ボリューム (PV) をバックアップおよび復元します。詳細については、OADP の機能 を参照してください。
1.2.1. OADP 要件
OADP には以下の要件があります。
-
cluster-adminロールを持つユーザーとしてログインする必要があります。 次のストレージタイプのいずれかなど、バックアップを保存するためのオブジェクトストレージが必要です。
- OpenShift Data Foundation
- Amazon Web Services
- Microsoft Azure
- Google Cloud Platform
- S3 と互換性のあるオブジェクトストレージ
OCP 4.11 以降で CSI バックアップを使用する場合は、OADP 1.1.x をインストールします。
OADP 1.0.x は、OCP 4.11 以降での CSI バックアップをサポートしていません。OADP 1.0.x には Velero 1.7.x が含まれており、OCP 4.11 以降には存在しない API グループ snapshot.storage.k8s.io/v1beta1 が必要です。
S3 ストレージ用の CloudStorage API は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
スナップショットを使用して PV をバックアップするには、ネイティブスナップショット API を備えているか、次のプロバイダーなどの Container Storage Interface (CSI) スナップショットをサポートするクラウドストレージが必要です。
- Amazon Web Services
- Microsoft Azure
- Google Cloud Platform
- Ceph RBD や Ceph FS などの CSI スナップショット対応のクラウドストレージ
スナップショットを使用して PV をバックアップしたくない場合は、デフォルトで OADP Operator によってインストールされる Restic を使用できます。
1.2.2. アプリケーションのバックアップおよび復元
Backup カスタムリソース (CR) を作成して、アプリケーションをバックアップします。バックアップ CR の作成 を参照してください。次のバックアップオプションを設定できます。
- バックアップ操作の前後にコマンドを実行するための バックアップフック
- スケジュールされたバックアップ
- Restic バックアップ
アプリケーションのバックアップを復元するには、Restore (CR) を作成します。復元 CR の作成 を参照してください。復元操作中に init コンテナーまたはアプリケーションコンテナーでコマンドを実行するように 復元フック を設定できます。
第2章 クラスターの正常なシャットダウン
本書では、クラスターを正常にシャットダウンするプロセスについて説明します。メンテナンスの目的で、またはリソースコストの節約のためにクラスターを一時的にシャットダウンする必要がある場合があります。
2.1. 前提条件
- クラスターをシャットダウンする前に etcd バックアップを作成します。
2.2. クラスターのシャットダウン
クラスターを正常な状態でシャットダウンし、後で再起動できるようにします。
インストール日から 1 年までクラスターをシャットダウンして、正常に再起動することを期待できます。インストール日から 1 年後に、クラスター証明書が期限切れになります。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 etcd のバックアップを取得している。
重要クラスターの再起動時に問題が発生した場合にクラスターを復元できるように、この手順を実行する前に etcd バックアップを作成しておくことは重要です。
たとえば、次の条件により、再起動したクラスターが誤動作する可能性があります。
- シャットダウン時の etcd データの破損
- ハードウェアが原因のノード障害
- ネットワーク接続の問題
クラスターが回復しない場合は、クラスターの以前の状態に復元する手順を実行します。
手順
クラスターを長期間シャットダウンする予定がある場合は、クラスター証明書の有効期限が切れる日付を決定します。
証明書の有効期限が切れる前にクラスターを再起動する必要があります。クラスターの再起動時に、kubelet 証明書を回復するために保留中の証明書署名要求 (CSR) を手動で承認する必要がある場合があります。
kube-apiserver-to-kubelet-signerCA 証明書の有効期限を確認します。$ oc -n openshift-kube-apiserver-operator get secret kube-apiserver-to-kubelet-signer -o jsonpath='{.metadata.annotations.auth\.openshift\.io/certificate-not-after}{"\n"}'出力例
2023-08-05T14:37:50Z
kubelet 証明書の有効期限を確認します。
次のコマンドを実行して、コントロールプレーンノードのデバッグセッションを開始します。
$ oc debug node/<node_name>
次のコマンドを実行して、ルートディレクトリーを
/hostに変更します。sh-4.4# chroot /host
次のコマンドを実行して、kubelet クライアント証明書の有効期限を確認します。
sh-5.1# openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -noout -enddate
出力例
notAfter=Jun 6 10:50:07 2023 GMT
次のコマンドを実行して、kubelet サーバー証明書の有効期限を確認します。
sh-5.1# openssl x509 -in /var/lib/kubelet/pki/kubelet-server-current.pem -noout -enddate
出力例
notAfter=Jun 6 10:50:07 2023 GMT
- デバッグセッションを終了します。
- これらの手順を繰り返して、すべてのコントロールプレーンノードの証明書の有効期限を確認します。クラスターを正常に再起動できるようにするには、最も早い証明書の有効期限が切れる前にクラスターを再起動するように計画してください。
クラスターのすべてのノードをシャットダウンします。これは、クラウドプロバイダーの Web コンソールから実行したり、以下のループを実行できます。
$ for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do oc debug node/${node} -- chroot /host shutdown -h 1; done 1- 1
-h 1は、コントロールプレーンノードがシャットダウンされるまで、このプロセスが継続する時間 (分単位) を示します。10 ノード以上の大規模なクラスターでは、まず始めにすべてのコンピュートノードをシャットダウンする時間を確保するために、10 分以上に設定します。
出力例
Starting pod/ip-10-0-130-169us-east-2computeinternal-debug ... To use host binaries, run `chroot /host` Shutdown scheduled for Mon 2021-09-13 09:36:17 UTC, use 'shutdown -c' to cancel. Removing debug pod ... Starting pod/ip-10-0-150-116us-east-2computeinternal-debug ... To use host binaries, run `chroot /host` Shutdown scheduled for Mon 2021-09-13 09:36:29 UTC, use 'shutdown -c' to cancel.
これらの方法のいずれかを使用してノードをシャットダウンすると、Pod は正常に終了するため、データが破損する可能性が低減します。
注記大規模なクラスターでは、シャットダウン時間が長くなるように調整します。
$ for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do oc debug node/${node} -- chroot /host shutdown -h 10; done注記シャットダウン前に OpenShift Container Platform に同梱される標準 Pod のコントロールプレーンノードをドレイン (解放) する必要はありません。
クラスター管理者は、クラスターの再起動後に独自のワークロードのクリーンな再起動を実行する必要があります。カスタムワークロードが原因でシャットダウン前にコントロールプレーンノードをドレイン (解放) した場合は、再起動後にクラスターが再び機能する前にコントロールプレーンノードをスケジュール可能としてマークする必要があります。
外部ストレージや LDAP サーバーなど、不要になったクラスター依存関係をすべて停止します。この作業を行う前に、ベンダーのドキュメントを確認してください。
重要クラスターをクラウドプロバイダープラットフォームにデプロイした場合は、関連するクラウドリソースをシャットダウン、一時停止、または削除しないでください。一時停止された仮想マシンのクラウドリソースを削除すると、OpenShift Container Platform が正常に復元されない場合があります。
2.3. 関連情報
第3章 クラスターの正常な再起動
本書では、正常なシャットダウン後にクラスターを再起動するプロセスについて説明します。
クラスターは再起動後に機能することが予想されますが、クラスターは以下の例を含む予期しない状態によって回復しない可能性があります。
- シャットダウン時の etcd データの破損
- ハードウェアが原因のノード障害
- ネットワーク接続の問題
クラスターが回復しない場合は、クラスターの以前の状態に復元する手順を実行します。
3.1. 前提条件
3.2. クラスターの再起動
クラスターの正常なシャットダウン後にクラスターを再起動できます。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 - この手順では、クラスターを正常にシャットダウンしていることを前提としています。
手順
- 外部ストレージや LDAP サーバーなどのクラスターの依存関係すべてをオンにします。
すべてのクラスターマシンを起動します。
クラウドプロバイダーの Web コンソールなどでマシンを起動するには、ご使用のクラウド環境に適した方法を使用します。
約 10 分程度待機してから、コントロールプレーンノードのステータス確認に進みます。
すべてのコントロールプレーンノードが準備状態にあることを確認します。
$ oc get nodes -l node-role.kubernetes.io/master
以下の出力に示されているように、コントロールプレーンノードはステータスが
Readyの場合、準備状態にあります。NAME STATUS ROLES AGE VERSION ip-10-0-168-251.ec2.internal Ready master 75m v1.25.0 ip-10-0-170-223.ec2.internal Ready master 75m v1.25.0 ip-10-0-211-16.ec2.internal Ready master 75m v1.25.0
コントロールプレーンノードが準備状態に ない 場合、承認する必要がある保留中の証明書署名要求 (CSR) があるかどうかを確認します。
現在の CSR の一覧を取得します。
$ oc get csr
CSR の詳細をレビューし、これが有効であることを確認します。
$ oc describe csr <csr_name> 1- 1
<csr_name>は、現行の CSR の一覧からの CSR の名前です。
それぞれの有効な CSR を承認します。
$ oc adm certificate approve <csr_name>
コントロールプレーンノードが準備状態になった後に、すべてのワーカーノードが準備状態にあることを確認します。
$ oc get nodes -l node-role.kubernetes.io/worker
以下の出力に示されているように、ワーカーノードのステータスが
Readyの場合、ワーカーノードは準備状態にあります。NAME STATUS ROLES AGE VERSION ip-10-0-179-95.ec2.internal Ready worker 64m v1.25.0 ip-10-0-182-134.ec2.internal Ready worker 64m v1.25.0 ip-10-0-250-100.ec2.internal Ready worker 64m v1.25.0
ワーカーノードが準備状態に ない 場合、承認する必要がある保留中の証明書署名要求 (CSR) があるかどうかを確認します。
現在の CSR の一覧を取得します。
$ oc get csr
CSR の詳細をレビューし、これが有効であることを確認します。
$ oc describe csr <csr_name> 1- 1
<csr_name>は、現行の CSR の一覧からの CSR の名前です。
それぞれの有効な CSR を承認します。
$ oc adm certificate approve <csr_name>
クラスターが適切に起動していることを確認します。
パフォーマンスが低下したクラスター Operator がないことを確認します。
$ oc get clusteroperators
DEGRADED条件がTrueに設定されているクラスター Operator がないことを確認します。NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE authentication 4.12.0 True False False 59m cloud-credential 4.12.0 True False False 85m cluster-autoscaler 4.12.0 True False False 73m config-operator 4.12.0 True False False 73m console 4.12.0 True False False 62m csi-snapshot-controller 4.12.0 True False False 66m dns 4.12.0 True False False 76m etcd 4.12.0 True False False 76m ...
すべてのノードが
Ready状態にあることを確認します。$ oc get nodes
すべてのノードのステータスが
Readyであることを確認します。NAME STATUS ROLES AGE VERSION ip-10-0-168-251.ec2.internal Ready master 82m v1.25.0 ip-10-0-170-223.ec2.internal Ready master 82m v1.25.0 ip-10-0-179-95.ec2.internal Ready worker 70m v1.25.0 ip-10-0-182-134.ec2.internal Ready worker 70m v1.25.0 ip-10-0-211-16.ec2.internal Ready master 82m v1.25.0 ip-10-0-250-100.ec2.internal Ready worker 69m v1.25.0
クラスターが適切に起動しなかった場合、etcd バックアップを使用してクラスターを復元する必要がある場合があります。
関連情報
- クラスターが再起動後に回復しない場合に etcd バックアップを使用して復元する方法については、クラスターの直前の状態への復元を参照してください。
第4章 アプリケーションのバックアップおよび復元
4.1. OADP リリースノート
OpenShift API for Data Protection (OADP) のリリースノートでは、新機能と拡張機能、非推奨の機能、製品の推奨事項、既知の問題、および解決された問題について説明します。
4.1.1. OADP 1.2.1 リリースノート
4.1.1.1. 新機能
OpenShift API for Data Protection (OADP) 1.2.1 のリリースには新機能はありません。
4.1.1.2. 解決した問題
OADP 1.2.1 のリリースで解決されたすべての問題の完全なリストについては、Jira の OADP 1.2.1 で解決された問題 のリストを参照してください。
4.1.1.3. 既知の問題
OADP 1.2.1 のリリースでは、次の問題が既知の問題として強調表示されています。
DataMover Restic の保持ポリシーとプルーニングポリシーが期待どおりに機能しない
VolSync と Restic によって提供される保持機能とプルーニング機能が期待どおりに動作しません。VolSync レプリケーションにはプルーニング間隔を設定する有効なオプションがないため、OADP の外部の S3 ストレージにリモートで保存されたバックアップを管理し、プルーニングする必要があります。詳細は、以下を参照してください。
OADP Data Mover はテクノロジープレビューのみの機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
このリリースのすべての既知の問題の完全なリストについては、Jira の OADP 1.2.1 の既知の問題 のリストを参照してください。
4.1.2. OADP 1.2.0 リリースノート
OADP 1.2.0 リリースノートには、新機能、バグ修正、既知の問題に関する情報が含まれています。
4.1.2.1. 新機能
新しい resourceTimeout オプションは、さまざまな Velero リソースを待機するタイムアウト期間を分単位で指定します。このオプションは、Velero CRD の可用性、volumeSnapshot の削除、バックアップリポジトリーの可用性などのリソースに適用されます。デフォルトの継続時間は 10 分です。
AWS S3 互換プロバイダーでオブジェクトとスナップショットをバックアップできます。
4.1.2.1.1. テクニカルプレビュー機能
OADP Data Mover を使用すると、Container Storage Interface (CSI) ボリュームのスナップショットをリモートオブジェクトストアにバックアップできます。Data Mover を有効にすると、クラスターの偶発的な削除、クラスター障害、またはデータ破損が発生した場合に、オブジェクトストアから取得した CSI ボリュームスナップショットを使用してステートフルアプリケーションを復元できます。
OADP Data Mover はテクノロジープレビューのみの機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
4.1.2.2. バグが修正されました。
このリリースでは、次のバグが修正されています。
- OADP-144
- OADP-639
- OADP-1741
- OADP-1152
- OADP-1143
- OADP-1931
- OADP-148
- OADP-1067
- OADP-1332
- OADP-1164
- OADP-1105
- OADP-2009
- OADP-1370
- OADP-969
- OADP-1672
- OADP-1151
- OADP-988
- OADP-1941
- OADP-1830
- OADP-1821
- OADP-1783
- OADP-1719
- OADP-1833
- OADP-1872
- OADP-2047
- OADP-1932
- OADP-1844
- OADP-1182
- OADP-1183
- OADP-1798
- OADP-1726
- OADP-821
- OADP-1781
- OADP-697
- OADP-1281
- OADP-1077
- OADP-1076
- OADP-1670
- OADP-1307
- OADP-1640
- OADP-1987
- OADP-1934
4.1.2.3. 既知の問題
本リリースには既知の問題はありません。
4.1.3. OADP 1.1.4 リリースノート
OADP 1.1.4 リリースノートには、新機能、解決された問題とバグ、既知の問題がリストされています。
4.1.3.1. 新機能
このバージョンの OADP はサービスリリースです。このバージョンには新しい機能は追加されていません。
4.1.3.2. バグが修正されました。
このリリースでは、次のバグが修正されています。
4.1.3.3. 既知の問題
本リリースには、以下の既知の問題があります。
- アプリケーションがリストアされたクラスター上で UID/GID 範囲が変更された可能性があるため、OADP バックアップが失敗する可能性があり、その結果、OADP が OpenShift Container Platform の UID/GID 範囲メタデータをバックアップおよびリストアしません。この問題を回避するには、バックアップされたアプリケーションに特定の UUID が必要な場合、復元時にその範囲が使用可能であることを確認してください。追加の回避策として、OADP が復元操作で namespace を作成できるようにすることが挙げられます。
-
ArgoCD の
app.kubernetes.io/instanceで使用されるラベルが原因で ArgoCD がプロセス中に使用されると、復元が失敗する場合があります。このラベルは、ArgoCD が管理する必要があるリソースを識別します。これにより、復元時にリソースを管理するための OADP の手順と競合が発生する可能性があります。この問題を回避するには、ArgoCD YAML の.spec.resourceTrackingMethodをannotation+labelまたはannotationに設定します。問題が解決しない場合は、復元を開始する前に ArgoCD を無効にし、復元が完了したら再び有効にします。
4.1.4. OADP 1.1.2 リリースノート
OADP 1.1.2 リリースノートには、製品の推奨事項、修正されたバグのリスト、および既知の問題の説明が含まれています。
4.1.4.1. 製品の推奨事項
VolSync
VolSync 0.5.1 から VolSync stable チャネルから入手可能な最新バージョンへのアップグレードを準備するには、次のコマンドを実行して、このアノテーションを openshift-adp namespace に追加する必要があります。
$ oc annotate --overwrite namespace/openshift-adp volsync.backube/privileged-movers='true'
Velero
このリリースでは、Velero がバージョン 1.9.2 からバージョン 1.9.5 にアップグレードされました。
Restic
このリリースでは、Restic がバージョン 0.13.1 からバージョン 0.14.0 にアップグレードされました。
4.1.4.2. バグが修正されました。
このリリースでは、次のバグが修正されています。
4.1.4.3. 既知の問題
本リリースには、以下の既知の問題があります。
- OADP は現在、Velero で restic を使用した AWS EFS ボリュームのバックアップと復元をサポートしていません (OADP-778)。
PVC ごとの
VolumeSnapshotContentスナップショットの Ceph 制限により、CSI バックアップが失敗する場合があります。同じ永続ボリューム要求 (PVC) のスナップショットを複数作成できますが、スナップショットの定期的な作成をスケジュールすることはできません。
詳細は、ボリュームのスナップショット を参照してください。
4.1.5. OADP 1.1.1 リリースノート
OADP 1.1.1 リリースノートには、製品の推奨事項と既知の問題の説明が含まれています。
4.1.5.1. 製品の推奨事項
OADP 1.1.1 をインストールする前に、VolSync 0.5.1 をインストールするか、それにアップグレードすることをお勧めします。
4.1.5.2. 既知の問題
本リリースには、以下の既知の問題があります。
- OADP は現在、Velero で restic を使用した AWS EFS ボリュームのバックアップと復元をサポートしていません (OADP-778)。
PVC ごとの
VolumeSnapshotContentスナップショットの Ceph 制限により、CSI バックアップが失敗する場合があります。同じ永続ボリューム要求 (PVC) のスナップショットを複数作成できますが、スナップショットの定期的な作成をスケジュールすることはできません。
- CephFS の場合、PVC ごとに最大 100 スナップショットを作成できます。
RADOS ブロックデバイス (RBD) の場合は、PVC ごとに最大 512 個のスナップショットを作成できます。(OADP-804) および (OADP-975)
詳細は、ボリュームのスナップショット を参照してください。
4.2. OADP features and plugins
OpenShift API for Data Protection (OADP) 機能は、アプリケーションをバックアップおよび復元するためのオプションを提供します。
デフォルトのプラグインにより、Velero は特定のクラウドプロバイダーと統合し、OpenShift Container Platform リソースをバックアップおよび復元できます。
4.2.1. OADP の機能
OpenShift API for Data Protection (OADP) は、以下の機能をサポートします。
- バックアップ
OADP を使用して OpenShift Platform 上のすべてのアプリケーションをバックアップしたり、タイプ、namespace、またはラベルでリソースをフィルターしたりできます。
OADP は、Kubernetes オブジェクトと内部イメージをアーカイブファイルとしてオブジェクトストレージに保存することにより、それらをバックアップします。OADP は、ネイティブクラウドスナップショット API または Container Storage Interface (CSI) を使用してスナップショットを作成することにより、永続ボリューム (PV) をバックアップします。スナップショットをサポートしないクラウドプロバイダーの場合、OADP は Restic を使用してリソースと PV データをバックアップします。
注記バックアップと復元を成功させるには、アプリケーションのバックアップから Operator を除外する必要があります。
- 復元
バックアップからリソースと PV を復元できます。バックアップ内のすべてのオブジェクトを復元することも、復元されたオブジェクトを namespace、PV、またはラベルでフィルタリングすることもできます。
注記バックアップと復元を成功させるには、アプリケーションのバックアップから Operator を除外する必要があります。
- スケジュール
- 指定した間隔でバックアップをスケジュールできます。
- フック
-
フックを使用して、Pod 上のコンテナーでコマンドを実行できます。たとえば、
fsfreezeを使用してファイルシステムをフリーズできます。バックアップまたは復元の前または後に実行するようにフックを設定できます。復元フックは、init コンテナーまたはアプリケーションコンテナーで実行できます。
4.2.2. OADP プラグイン
OpenShift API for Data Protection (OADP) は、バックアップおよびスナップショット操作をサポートするためにストレージプロバイダーと統合されたデフォルトの Velero プラグインを提供します。Velero プラグインに基づいて カスタムプラグイン を作成できます。
OADP は、OpenShift Container Platform リソースバックアップ、OpenShift Virtualization リソースバックアップ、および Container Storage Interface (CSI) スナップショット用のプラグインも提供します。
表4.1 OADP プラグイン
| OADP プラグイン | 機能 | ストレージの場所 |
|---|---|---|
|
| Kubernetes オブジェクトをバックアップし、復元します。 | AWS S3 |
| スナップショットを使用してボリュームをバックアップおよび復元します。 | AWS EBS | |
|
| Kubernetes オブジェクトをバックアップし、復元します。 | Microsoft Azure Blob ストレージ |
| スナップショットを使用してボリュームをバックアップおよび復元します。 | Microsoft Azure マネージドディスク | |
|
| Kubernetes オブジェクトをバックアップし、復元します。 | Google Cloud Storage |
| スナップショットを使用してボリュームをバックアップおよび復元します。 | Google Compute Engine ディスク | |
|
| OpenShift Container Platform リソースをバックアップおよび復元します。[1] | オブジェクトストア |
|
| OpenShift Virtualization リソースをバックアップおよび復元します。[2] | オブジェクトストア |
|
| CSI スナップショットを使用して、ボリュームをバックアップおよび復元します。[3] | CSI スナップショットをサポートするクラウドストレージ |
|
| VolumeSnapshotMover は、クラスターの削除などの状況で、ステートフルアプリケーションを回復するための復元プロセス中に使用されるスナップショットをクラスターからオブジェクトストアに再配置します。[4] | オブジェクトストア |
- 必須。
- 仮想マシンディスクは CSI スナップショットまたは Restic でバックアップされます。
-
csiプラグインは、Velero CSI ベータスナップショット API を使用します。 - OADP 1.2 のみ。
4.2.3. OADP Velero プラグインについて
Velero のインストール時に、次の 2 種類のプラグインを設定できます。
- デフォルトのクラウドプロバイダープラグイン
- カスタムプラグイン
どちらのタイプのプラグインもオプションですが、ほとんどのユーザーは少なくとも 1 つのクラウドプロバイダープラグインを設定します。
4.2.3.1. デフォルトの Velero クラウドプロバイダープラグイン
デプロイメント中に oadp_v1alpha1_dpa.yaml ファイルを設定するときに、次のデフォルトの Velero クラウドプロバイダープラグインのいずれかをインストールできます。
-
aws(Amazon Web Services) -
gcp(Google Cloud Platform) -
azure(Microsoft Azure) -
openshift(OpenShift Velero プラグイン) -
csi(Container Storage Interface) -
kubevirt(KubeVirt)
デプロイメント中に oadp_v1alpha1_dpa.yaml ファイルで目的のデフォルトプラグインを指定します。
ファイルの例:
次の .yaml ファイルは、openshift、aws、azure、および gcp プラグインをインストールします。
apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
name: dpa-sample
spec:
configuration:
velero:
defaultPlugins:
- openshift
- aws
- azure
- gcp4.2.3.2. カスタム Velero プラグイン
デプロイメント中に oadp_v1alpha1_dpa.yaml ファイルを設定するときに、プラグインの image と name を指定することにより、カスタム Velero プラグインをインストールできます。
デプロイメント中に oadp_v1alpha1_dpa.yaml ファイルで目的のカスタムプラグインを指定します。
ファイルの例:
次の .yaml ファイルは、デフォルトの openshift、azure、および gcp プラグインと、イメージ quay.io/example-repo/custom-velero-plugin を持つ custom-plugin-example という名前のカスタムプラグインをインストールします。
apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
name: dpa-sample
spec:
configuration:
velero:
defaultPlugins:
- openshift
- azure
- gcp
customPlugins:
- name: custom-plugin-example
image: quay.io/example-repo/custom-velero-plugin4.2.4. IBM Power および IBM Z の OADP サポート
OpenShift API for Data Protection (OADP) はプラットフォームに依存しません。以下の情報は、IBM Power および IBM Z のみに関連しています。
OADP 1.1.0 は、IBM Power と IBM Z の両方で、OpenShift Container Platform 4.11 に対して正常にテストされました。以下のセクションでは、これらのシステムのバックアップロケーションに関する OADP 1.1.0 のテストおよびサポート情報を提供します。
4.2.4.1. IBM Power を使用したターゲットバックアップロケーションの OADP サポート
OpenShift Container Platform 4.11 および 4.12、および OpenShift API for Data Protection (OADP) 1.1.2 で実行される IBM Power は、AWS S3 バックアップロケーションターゲットに対して正常にテストされました。テストには AWS S3 ターゲットのみが含まれていましたが、Red Hat は、AWS S3 以外のすべてのバックアップロケーションターゲットに対しても、OpenShift Container Platform 4.11 と 4.12、および OADP 1.1.2 を使用した IBM Power の実行をサポートしています。
4.2.4.2. IBM Z を使用したターゲットバックアップロケーションの OADP テストとサポート
OpenShift Container Platform 4.11 および 4.12、および OpenShift API for Data Protection (OADP) 1.1.2 で実行されている IBM Z は、AWS S3 バックアップロケーションターゲットに対して正常にテストされました。テストには AWS S3 ターゲットのみが含まれていましたが、Red Hat は、AWS S3 以外のすべてのバックアップロケーションターゲットに対しても、OpenShift Container Platform 4.11 と 4.12、および OADP 1.1.2 を使用した IBM Z の実行をサポートしています。
4.3. OADP のインストールおよび設定
4.3.1. OADP のインストールについて
クラスター管理者は、OADP Operator をインストールして、OpenShift API for Data Protection (OADP) をインストールします。OADP オペレーターは Velero 1.9 をインストールします。
OADP 1.0.4 以降、すべて OADP 1.0.z バージョンは、MTC Operator の依存関係としてのみ使用でき、スタンドアロン Operator としては使用できません。
Kubernetes リソースと内部イメージをバックアップするには、次のいずれかのストレージタイプなど、バックアップ場所としてオブジェクトストレージが必要です。
- Amazon Web Services
- Microsoft Azure
- Google Cloud Platform
- Multicloud Object Gateway
- Noobaa や Minio などの AWS S3 互換のオブジェクトストレージ
オブジェクトストレージのバケット作成を自動化する CloudStorage API は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
スナップショットまたは Restic を使用して、永続ボリューム (PV) をバックアップできます。
スナップショットを使用して PV をバックアップするには、ネイティブスナップショット API または Container Storage Interface (CSI) スナップショットのいずれかをサポートするクラウドプロバイダー (次のいずれかのクラウドプロバイダーなど) が必要です。
- Amazon Web Services
- Microsoft Azure
- Google Cloud Platform
- OpenShift Data Foundation などの CSI スナップショット対応クラウドプロバイダー
OCP 4.11 以降で CSI バックアップを使用する場合は、OADP 1.1.x をインストールします。
OADP 1.0.x は、OCP 4.11 以降での CSI バックアップをサポートしていません。OADP 1.0.x には Velero 1.7.x が含まれており、OCP 4.11 以降には存在しない API グループ snapshot.storage.k8s.io/v1beta1 が必要です。
クラウドプロバイダーがスナップショットをサポートしていない場合、またはストレージが NFS の場合は、Restic バックアップ を使用してオブジェクトストレージにアプリケーションをバックアップできます。
デフォルトの Secret を作成し、次に、Data Protection Application をインストールします。
4.3.1.1. AWS S3 互換のバックアップストレージプロバイダー
OADP は、さまざまなバックアップおよびスナップショット操作で使用できる多数のオブジェクトストレージプロバイダーと互換性があります。いくつかのオブジェクトストレージプロバイダーは完全にサポートされていますが、いくつかはサポートされていないものの動作することがわかっており、一部には既知の制限があります。
4.3.1.1.1. サポートされているバックアップストレージプロバイダー
次の AWS S3 互換オブジェクトストレージプロバイダーは、バックアップストレージの場所として使用するために、AWS プラグインを介して OADP によって完全にサポートされています。
- MinIO
- NooBaa を備えた Multicloud Object Gateway (MCG)
- Amazon Web Services (AWS) S3
次の互換オブジェクトストレージプロバイダーはサポートされており、独自の Velero オブジェクトストアプラグインがあります。
- Google Cloud Platform (GCP)
- Microsoft Azure
4.3.1.1.2. サポートされていないバックアップストレージプロバイダー
次の AWS S3 互換オブジェクトストレージプロバイダーは、バックアップストレージの場所として使用するために、AWS プラグインを介して Velero と連携することが知られていますが、サポートされておらず、Red Hat によってテストされていません。
- IBM Cloud
- Oracle Cloud
- DigitalOcean
- NooBaa
- Tencent Cloud
- Ceph RADOS v12.2.7
- Quobyte
- Cloudian HyperStore
4.3.1.1.3. 既知の制限があるバックアップストレージプロバイダー
次の AWS S3 互換オブジェクトストレージプロバイダーは、限定された機能セットを備えた AWS プラグインを介して Velero と連携することが知られています。
- Swift - バックアップストレージのバックアップストレージ場所として使用できますが、ファイルシステムベースのボリュームバックアップおよび復元については Restic と互換性がありません。
4.3.1.2. OpenShift Data Foundation での障害復旧のための NooBaa の設定
OpenShift Data Foundation で NooBaa バケットの backupStorageLocation にクラスターストレージを使用する場合は、NooBaa を外部オブジェクトストアとして設定します。
NooBaa を外部オブジェクトストアとして設定しないと、バックアップが利用できなくなる可能性があります。
手順
- ハイブリッドまたはマルチクラウドのストレージリソースの追加 の説明に従って、NooBaa を外部オブジェクトストアとして設定します。
4.3.1.3. OADP 更新チャネルについて
OADP Operator をインストールするときに、更新チャネル を選択します。このチャネルにより、OADP Operator と Velero のどちらのアップグレードを受け取るかが決まります。いつでもチャンネルを切り替えることができます。
次の更新チャネルを利用できます。
-
stable チャネルは非推奨になりました。stable チャネルには、
oadp.v1.1.zおよびoadp.v1.0.zの古いバージョン用の OADPClusterServiceVersionのパッチ (z-stream 更新) が含まれています。 -
stable-1.0 チャネルには
oadp.v1.0.z、OADP 1.0ClusterServiceVersionが含まれています。 -
stable-1.1 チャネルには
oadp.v1.1.z、最新の OADP 1.1ClusterServiceVersionが含まれています。 -
stable-1.2 チャネルには、最新の OADP 1.2
ClusterServiceVersionのoadp.v1.2.zが含まれています。
適切な更新チャネルはどれですか?
-
stable チャネルは非推奨になりました。すでに安定版チャネルを使用している場合は、引き続き、
oadp.v1.1.zから更新を取得します。 - OADP 1.y をインストールする stable-1.y 更新チャネルを選択し、そのパッチを引き続き受け取ります。このチャネルを選択すると、バージョン 1.y.z のすべての z-stream パッチを受け取ります。
いつ更新チャネルを切り替える必要がありますか?
- OADP 1.y がインストールされていて、その y-stream のパッチのみを受け取りたい場合は、stable 更新チャネルから stable-1.y 更新チャネルに切り替える必要があります。その後、バージョン 1.y.z のすべての z-stream パッチを受け取ります。
- OADP 1.0 がインストールされていて、OADP 1.1 にアップグレードしたい場合、OADP 1.1 のみのパッチを受け取るには、stable-1.0 更新チャネルから stable-1.1 更新チャネルに切り替える必要があります。その後、バージョン 1.1.z のすべての z-stream パッチを受け取ります。
- OADP 1.y がインストールされていて、y が 0 より大きく、OADP 1.0 に切り替える場合は、OADP Operator を アンインストール してから、stable-1.0 更新チャネルを使用して再インストールする必要があります。その後、バージョン 1.0.z のすべての z-stream パッチを受け取ります。
更新チャネルを切り替えて、OADP 1.y から OADP 1.0 に切り替えることはできません。Operator をアンインストールしてから再インストールする必要があります。
4.3.1.4. 複数の namespace への OADP のインストール
OADP を同じクラスター上の複数の namespace にインストールすると、複数のプロジェクト所有者が独自の OADP インスタンスを管理できるようになります。このユースケースは Restic および CSI で検証されています。
本書に含まれるプラットフォームごとの手順で指定されている OADP の各インスタンスを、以下の追加要件とともにインストールします。
- 同じクラスター上のすべての OADP デプロイメントは、同じバージョン (1.1.4 など) である必要があります。同じクラスターに異なるバージョンの OADP をインストールすることはサポートされていません。
-
OADP の個々のデプロイメントには、一意の認証情報のセットと一意の
BackupStorageLocation設定が必要です。 - デフォルトでは、各 OADP デプロイメントには namespace 全体でクラスターレベルのアクセス権があります。OpenShift Container Platform 管理者は、セキュリティーおよび RBAC 設定を注意深く確認し、必要な変更を加えて、各 OADP インスタンスに正しい権限があることを確認する必要があります。
関連情報
4.3.1.5. 収集したデータに基づく Velero CPU およびメモリーの要件
以下の推奨事項は、スケールおよびパフォーマンスのラボで観察したパフォーマンスに基づいています。バックアップおよび復元リソースは、プラグインのタイプ、そのバックアップまたは復元に必要なリソースの量、そのリソースに関連する永続ボリューム (PV) に含まれるデータの影響を受けます。
4.3.1.5.1. 設定に必要な CPU とメモリー
| 設定タイプ | [1] 平均使用量 | [2] 大量使用時 | resourceTimeouts |
|---|---|---|---|
| CSI | Velero: CPU - リクエスト 200m、制限 1000m メモリー - リクエスト 256 Mi、制限 1024 Mi | Velero: CPU - リクエスト 200m、制限 2000m メモリー - リクエスト 256 Mi、制限 2048 Mi | 該当なし |
| Restic | [3] Restic: CPU - リクエスト 1000m、制限 2000m メモリー - リクエスト 16 Gi、制限 32 Gi | [4] Restic: CPU - リクエスト 2000m、制限 8000m メモリー - リクエスト 16 Gi、制限 40 Gi | 900 m |
| [5] DataMover | 該当なし | 該当なし | 10m - 平均使用量 60m - 大量使用時 |
- 平均使用量 - ほとんどの状況下でこの設定を使用します。
- 大量使用時 - 大規模な PV (使用量 500 GB)、複数の namespace (100 以上)、または 1 つの namespace に多数の Pod (2000 Pod 以上) があるなどして使用量が大きくなる状況下では、大規模なデータセットを含む場合のバックアップと復元で最適なパフォーマンスを実現するために、この設定を使用します。
- Restic リソースの使用量は、データの量とデータタイプに対応します。たとえば、多数の小さなファイルがや大量のデータがある場合は、、Restic が大量のリソースを使用する可能性があります。Velero のドキュメントでは、デフォルトとして 500 m を参照していますが、ほとんどのテストではリクエスト 200m、制限 1000m が適切でした。Velero のドキュメントに記載されているとおり、正確な CPU とメモリー使用量は、環境の制限に加えて、ファイルとディレクトリーの規模に依存します。
- CPU を増やすと、バックアップと復元の時間を大幅に短縮できます。
- DataMover - DataMover のデフォルトの resourceTimeout は 10m です。テストでは、大規模な PV (使用量 500 GB) を復元するには、resourceTimeout を 60m に増やす必要があることがわかりました。
このガイド全体に記載されているリソース要件は、平均的な使用量に限定されています。大量に使用する場合は、上の表の説明に従って設定を調整してください。
4.3.2. Amazon Web Services を使用した OpenShift API for Data Protection のインストールおよび設定
OADP Operator をインストールすることで、Amazon Web Services (AWS) を使用して OpenShift API for Data Protection (OADP) をインストールします。Operator は Velero 1.9 をインストールします。
OADP 1.0.4 以降、すべて OADP 1.0.z バージョンは、MTC Operator の依存関係としてのみ使用でき、スタンドアロン Operator としては使用できません。
Velero 向けに AWS を設定し、デフォルトの Secret を作成し、次に、Data Protection Application をインストールします。
制限されたネットワーク環境に OADP Operator をインストールするには、最初にデフォルトの Operator Hub ソースを無効にして、Operator カタログをミラーリングする必要があります。詳細は、ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。
4.3.2.1. OADP Operator のインストール
Operator Lifecycle Manager (OLM) を使用して、OpenShift Container Platform 4.12 に OpenShift API for Data Protection (OADP) オペレーターをインストールします。
OADP オペレーターは Velero 1.9 をインストールします。
前提条件
-
cluster-admin権限を持つユーザーとしてログインしている。
手順
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- Filter by keyword フィールドを使用して、OADP Operator を検索します。
- OADP Operator を選択し、Install をクリックします。
-
Install をクリックして、
openshift-adpプロジェクトに Operator をインストールします。 - Operators → Installed Operators をクリックして、インストールを確認します。
4.3.2.2. Amazon Web Services の設定
OpenShift API for Data Protection (OADP) 用に Amazon Web Services (AWS) を設定します。
前提条件
- AWS CLI がインストールされていること。
手順
BUCKET変数を設定します。$ BUCKET=<your_bucket>
REGION変数を設定します。$ REGION=<your_region>
AWS S3 バケットを作成します。
$ aws s3api create-bucket \ --bucket $BUCKET \ --region $REGION \ --create-bucket-configuration LocationConstraint=$REGION 1- 1
us-east-1はLocationConstraintをサポートしていません。お住まいの地域がus-east-1の場合は、--create-bucket-configuration LocationConstraint=$REGIONを省略してください。
IAM ユーザーを作成します。
$ aws iam create-user --user-name velero 1- 1
- Velero を使用して複数の S3 バケットを持つ複数のクラスターをバックアップする場合は、クラスターごとに一意のユーザー名を作成します。
velero-policy.jsonファイルを作成します。$ cat > velero-policy.json <<EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:DescribeVolumes", "ec2:DescribeSnapshots", "ec2:CreateTags", "ec2:CreateVolume", "ec2:CreateSnapshot", "ec2:DeleteSnapshot" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:DeleteObject", "s3:PutObject", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts" ], "Resource": [ "arn:aws:s3:::${BUCKET}/*" ] }, { "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetBucketLocation", "s3:ListBucketMultipartUploads" ], "Resource": [ "arn:aws:s3:::${BUCKET}" ] } ] } EOFポリシーを添付して、
veleroユーザーに必要最小限の権限を付与します。$ aws iam put-user-policy \ --user-name velero \ --policy-name velero \ --policy-document file://velero-policy.json
veleroユーザーのアクセスキーを作成します。$ aws iam create-access-key --user-name velero
出力例
{ "AccessKey": { "UserName": "velero", "Status": "Active", "CreateDate": "2017-07-31T22:24:41.576Z", "SecretAccessKey": <AWS_SECRET_ACCESS_KEY>, "AccessKeyId": <AWS_ACCESS_KEY_ID> } }credentials-veleroファイルを作成します。$ cat << EOF > ./credentials-velero [default] aws_access_key_id=<AWS_ACCESS_KEY_ID> aws_secret_access_key=<AWS_SECRET_ACCESS_KEY> EOF
Data Protection Application をインストールする前に、
credentials-veleroファイルを使用して AWS のSecretオブジェクトを作成します。
4.3.2.3. バックアップおよびスナップショットの場所、ならびにそのシークレットについて
DataProtectionApplication カスタムリソース (CR) で、バックアップおよびスナップショットの場所、ならびにそのシークレットを指定します。
バックアップの場所
Multicloud Object Gateway、Noobaa、または Minio などの S3 互換オブジェクトストレージを、バックアップの場所として指定します。
Velero は、オブジェクトストレージのアーカイブファイルとして、OpenShift Container Platform リソース、Kubernetes オブジェクト、および内部イメージをバックアップします。
スナップショットの場所
クラウドプロバイダーのネイティブスナップショット API を使用して永続ボリュームをバックアップする場合、クラウドプロバイダーをスナップショットの場所として指定する必要があります。
Container Storage Interface (CSI) スナップショットを使用する場合、CSI ドライバーを登録するために VolumeSnapshotClass CR を作成するため、スナップショットの場所を指定する必要はありません。
Restic を使用する場合は、Restic がオブジェクトストレージにファイルシステムをバックアップするため、スナップショットの場所を指定する必要はありません。
シークレット
バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret を作成します。
バックアップとスナップショットの場所で異なる認証情報を使用する場合は、次の 2 つの secret オブジェクトを作成します。
-
DataProtectionApplicationCR で指定する、バックアップの場所用のカスタムSecret。 -
DataProtectionApplicationCR で参照されない、スナップショットの場所用のデフォルトSecret。
Data Protection Application には、デフォルトの Secret が必要です。作成しないと、インストールは失敗します。
インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の credentials-velero ファイルを使用してデフォルトの Secret を作成できます。
4.3.2.3.1. デフォルト Secret の作成
バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret を作成します。
Secret のデフォルト名は cloud-credentials です。
DataProtectionApplication カスタムリソース (CR) にはデフォルトの Secret が必要です。作成しないと、インストールは失敗します。バックアップの場所の Secret の名前が指定されていない場合は、デフォルトの名前が使用されます。
インストール時にバックアップの場所の認証情報を使用しない場合は、空の credentials-velero ファイルを使用してデフォルト名前で Secret を作成できます。
前提条件
- オブジェクトストレージとクラウドストレージがある場合は、同じ認証情報を使用する必要があります。
- Velero のオブジェクトストレージを設定する必要があります。
-
オブジェクトストレージ用の
credentials-veleroファイルを適切な形式で作成する必要があります。
手順
デフォルト名で
Secretを作成します。$ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
Secret は、Data Protection Application をインストールするときに、DataProtectionApplication CR の spec.backupLocations.credential ブロックで参照されます。
4.3.2.3.2. 異なる認証情報のプロファイルの作成
バックアップとスナップショットの場所で異なる認証情報を使用する場合は、credentials-velero ファイルに個別のプロファイルを作成します。
次に、Secret オブジェクトを作成し、DataProtectionApplication カスタムリソース (CR) でプロファイルを指定します。
手順
次の例のように、バックアップとスナップショットの場所に別々のプロファイルを持つ
credentials-veleroファイルを作成します。[backupStorage] aws_access_key_id=<AWS_ACCESS_KEY_ID> aws_secret_access_key=<AWS_SECRET_ACCESS_KEY> [volumeSnapshot] aws_access_key_id=<AWS_ACCESS_KEY_ID> aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
credentials-veleroファイルを使用してSecretオブジェクトを作成します。$ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero 1次の例のように、プロファイルを
DataProtectionApplicationCR に追加します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> namespace: openshift-adp spec: ... backupLocations: - name: default velero: provider: aws default: true objectStorage: bucket: <bucket_name> prefix: <prefix> config: region: us-east-1 profile: "backupStorage" credential: key: cloud name: cloud-credentials snapshotLocations: - name: default velero: provider: aws config: region: us-west-2 profile: "volumeSnapshot"
4.3.2.4. Data Protection Application の設定
Velero リソースの割り当てを設定するか、自己署名 CA 証明書を有効にして、Data Protection Application を設定できます。
4.3.2.4.1. Velero の CPU とメモリーのリソース割り当てを設定
DataProtectionApplication カスタムリソース (CR) マニフェストを編集して、Velero Pod の CPU およびメモリーリソースの割り当てを設定します。
前提条件
- OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。
手順
次の例のように、
DataProtectionApplicationCR マニフェストのspec.configuration.velero.podConfig.ResourceAllocationsブロックの値を編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> spec: ... configuration: velero: podConfig: nodeSelector: <node selector> 1 resourceAllocations: 2 limits: cpu: "1" memory: 1024Mi requests: cpu: 200m memory: 256Mi
4.3.2.4.2. 自己署名 CA 証明書の有効化
certificate signed by unknown authority エラーを防ぐために、DataProtectionApplication カスタムリソース (CR) マニフェストを編集して、オブジェクトストレージの自己署名 CA 証明書を有効にする必要があります。
前提条件
- OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。
手順
DataProtectionApplicationCR マニフェストのspec.backupLocations.velero.objectStorage.caCertパラメーターとspec.backupLocations.velero.configパラメーターを編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> spec: ... backupLocations: - name: default velero: provider: aws default: true objectStorage: bucket: <bucket> prefix: <prefix> caCert: <base64_encoded_cert_string> 1 config: insecureSkipTLSVerify: "false" 2 ...
4.3.2.5. Data Protection Application のインストール
DataProtectionApplication API のインスタンスを作成して、Data Protection Application (DPA) をインストールします。
前提条件
- OADP Operator をインストールする必要があります。
- オブジェクトストレージをバックアップ場所として設定する必要があります。
- スナップショットを使用して PV をバックアップする場合、クラウドプロバイダーはネイティブスナップショット API または Container Storage Interface (CSI) スナップショットのいずれかをサポートする必要があります。
-
バックアップとスナップショットの場所で同じ認証情報を使用する場合は、デフォルトの名前である
cloud-credentialsを使用してSecretを作成する必要があります。 バックアップとスナップショットの場所で異なる認証情報を使用する場合は、デフォルト名である
cloud-credentialsを使用してSecretを作成する必要があります。これには、バックアップとスナップショットの場所の認証情報用の個別のプロファイルが含まれます。注記インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の
credentials-veleroファイルを使用してデフォルトのSecretを作成できます。デフォルトのSecretがない場合、インストールは失敗します。
手順
- Operators → Installed Operators をクリックして、OADP Operator を選択します。
- Provided APIs で、DataProtectionApplication ボックスの Create instance をクリックします。
YAML View をクリックして、
DataProtectionApplicationマニフェストのパラメーターを更新します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> namespace: openshift-adp spec: configuration: velero: defaultPlugins: - openshift 1 - aws resourceTimeout: 10m 2 restic: enable: true 3 podConfig: nodeSelector: <node_selector> 4 backupLocations: - name: default velero: provider: aws default: true objectStorage: bucket: <bucket_name> 5 prefix: <prefix> 6 config: region: <region> profile: "default" credential: key: cloud name: cloud-credentials 7 snapshotLocations: 8 - name: default velero: provider: aws config: region: <region> 9 profile: "default"- 1
openshiftプラグインは必須です。- 2
- Velero CRD の可用性、volumeSnapshot の削除、バックアップリポジトリーの可用性など、タイムアウトが発生するまでに複数の Velero リソースを待機する時間を分単位で指定します。デフォルトは 10m です。
- 3
- Restic のインストールを無効にする場合は、
falseに設定します。Restic はデーモンセットをデプロイします。これは、各ワーカーノードでResticPod が実行されていることを意味します。spec.defaultVolumesToRestic: trueをBackupCR に追加することで、バックアップ用に Restic を設定できます。 - 4
- Restic を使用できるノードを指定します。デフォルトでは、Restic はすべてのノードで実行されます。
- 5
- バックアップの保存場所としてバケットを指定します。バケットが Velero バックアップ専用のバケットでない場合は、接頭辞を指定する必要があります。
- 6
- バケットが複数の目的で使用される場合は、Velero バックアップの接頭辞を指定します (例:
velero)。 - 7
- 作成した
Secretオブジェクトの名前を指定します。この値を指定しない場合は、デフォルト名のcloud-credentialsが使用されます。カスタム名を指定すると、バックアップの場所にカスタム名が使用されます。 - 8
- CSI スナップショットまたは Restic を使用して PV をバックアップする場合を除き、スナップショットの場所を指定します。
- 9
- スナップショットの場所は、PV と同じリージョンにある必要があります。
- Create をクリックします。
OADP リソースを表示して、インストールを確認します。
$ oc get all -n openshift-adp
出力例
NAME READY STATUS RESTARTS AGE pod/oadp-operator-controller-manager-67d9494d47-6l8z8 2/2 Running 0 2m8s pod/restic-9cq4q 1/1 Running 0 94s pod/restic-m4lts 1/1 Running 0 94s pod/restic-pv4kr 1/1 Running 0 95s pod/velero-588db7f655-n842v 1/1 Running 0 95s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/oadp-operator-controller-manager-metrics-service ClusterIP 172.30.70.140 <none> 8443/TCP 2m8s NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/restic 3 3 3 3 3 <none> 96s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/oadp-operator-controller-manager 1/1 1 1 2m9s deployment.apps/velero 1/1 1 1 96s NAME DESIRED CURRENT READY AGE replicaset.apps/oadp-operator-controller-manager-67d9494d47 1 1 1 2m9s replicaset.apps/velero-588db7f655 1 1 1 96s
4.3.2.5.1. DataProtectionApplication CR で CSI を有効にする
CSI スナップショットを使用して永続ボリュームをバックアップするには、DataProtectionApplication カスタムリソース (CR) で Container Storage Interface (CSI) を有効にします。
前提条件
- クラウドプロバイダーは、CSI スナップショットをサポートする必要があります。
手順
次の例のように、
DataProtectionApplicationCR を編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication ... spec: configuration: velero: defaultPlugins: - openshift - csi 1- 1
csiデフォルトプラグインを追加します。
4.3.3. Microsoft Azure を使用した OpenShift API for Data Protection のインストールおよび設定
OADP Operator をインストールすることで、Microsoft Azure を使用して OpenShift API for Data Protection (OADP) をインストールします。Operator は Velero 1.9 をインストールします。
OADP 1.0.4 以降、すべて OADP 1.0.z バージョンは、MTC Operator の依存関係としてのみ使用でき、スタンドアロン Operator としては使用できません。
Velero 向けに Azure を設定し、デフォルトの Secret を作成し、次に、Data Protection Application をインストールします。
制限されたネットワーク環境に OADP Operator をインストールするには、最初にデフォルトの Operator Hub ソースを無効にして、Operator カタログをミラーリングする必要があります。詳細は、ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。
4.3.3.1. OADP Operator のインストール
Operator Lifecycle Manager (OLM) を使用して、OpenShift Container Platform 4.12 に OpenShift API for Data Protection (OADP) オペレーターをインストールします。
OADP オペレーターは Velero 1.9 をインストールします。
前提条件
-
cluster-admin権限を持つユーザーとしてログインしている。
手順
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- Filter by keyword フィールドを使用して、OADP Operator を検索します。
- OADP Operator を選択し、Install をクリックします。
-
Install をクリックして、
openshift-adpプロジェクトに Operator をインストールします。 - Operators → Installed Operators をクリックして、インストールを確認します。
4.3.3.2. Microsoft Azure の設定
OpenShift API for Data Protection (OADP) 用に Microsoft Azure を設定します。
前提条件
- Azure CLI がインストールされていること。
手順
Azure にログインします。
$ az login
AZURE_RESOURCE_GROUP変数を設定します。$ AZURE_RESOURCE_GROUP=Velero_Backups
Azure リソースグループを作成します。
$ az group create -n $AZURE_RESOURCE_GROUP --location CentralUS 1- 1
- 場所を指定します。
AZURE_STORAGE_ACCOUNT_ID変数を設定します。$ AZURE_STORAGE_ACCOUNT_ID="velero$(uuidgen | cut -d '-' -f5 | tr '[A-Z]' '[a-z]')"
Azure ストレージアカウントを作成します。
$ az storage account create \ --name $AZURE_STORAGE_ACCOUNT_ID \ --resource-group $AZURE_RESOURCE_GROUP \ --sku Standard_GRS \ --encryption-services blob \ --https-only true \ --kind BlobStorage \ --access-tier HotBLOB_CONTAINER変数を設定します。$ BLOB_CONTAINER=velero
Azure Blob ストレージコンテナーを作成します。
$ az storage container create \ -n $BLOB_CONTAINER \ --public-access off \ --account-name $AZURE_STORAGE_ACCOUNT_ID
ストレージアカウントのアクセスキーを取得します。
$ AZURE_STORAGE_ACCOUNT_ACCESS_KEY=`az storage account keys list \ --account-name $AZURE_STORAGE_ACCOUNT_ID \ --query "[?keyName == 'key1'].value" -o tsv`
必要最小限のパーミッションを持つカスタムロールを作成します。
AZURE_ROLE=Velero az role definition create --role-definition '{ "Name": "'$AZURE_ROLE'", "Description": "Velero related permissions to perform backups, restores and deletions", "Actions": [ "Microsoft.Compute/disks/read", "Microsoft.Compute/disks/write", "Microsoft.Compute/disks/endGetAccess/action", "Microsoft.Compute/disks/beginGetAccess/action", "Microsoft.Compute/snapshots/read", "Microsoft.Compute/snapshots/write", "Microsoft.Compute/snapshots/delete", "Microsoft.Storage/storageAccounts/listkeys/action", "Microsoft.Storage/storageAccounts/regeneratekey/action" ], "AssignableScopes": ["/subscriptions/'$AZURE_SUBSCRIPTION_ID'"] }'credentials-veleroファイルを作成します。$ cat << EOF > ./credentials-velero AZURE_SUBSCRIPTION_ID=${AZURE_SUBSCRIPTION_ID} AZURE_TENANT_ID=${AZURE_TENANT_ID} AZURE_CLIENT_ID=${AZURE_CLIENT_ID} AZURE_CLIENT_SECRET=${AZURE_CLIENT_SECRET} AZURE_RESOURCE_GROUP=${AZURE_RESOURCE_GROUP} AZURE_STORAGE_ACCOUNT_ACCESS_KEY=${AZURE_STORAGE_ACCOUNT_ACCESS_KEY} 1 AZURE_CLOUD_NAME=AzurePublicCloud EOF- 1
- 必須。
credentials-veleroファイルにサービスプリンシパル認証情報のみが含まれている場合は、内部イメージをバックアップすることはできません。
Data Protection Application をインストールする前に、
credentials-veleroファイルを使用して Azure のSecretオブジェクトを作成します。
4.3.3.3. バックアップおよびスナップショットの場所、ならびにそのシークレットについて
DataProtectionApplication カスタムリソース (CR) で、バックアップおよびスナップショットの場所、ならびにそのシークレットを指定します。
バックアップの場所
Multicloud Object Gateway、Noobaa、または Minio などの S3 互換オブジェクトストレージを、バックアップの場所として指定します。
Velero は、オブジェクトストレージのアーカイブファイルとして、OpenShift Container Platform リソース、Kubernetes オブジェクト、および内部イメージをバックアップします。
スナップショットの場所
クラウドプロバイダーのネイティブスナップショット API を使用して永続ボリュームをバックアップする場合、クラウドプロバイダーをスナップショットの場所として指定する必要があります。
Container Storage Interface (CSI) スナップショットを使用する場合、CSI ドライバーを登録するために VolumeSnapshotClass CR を作成するため、スナップショットの場所を指定する必要はありません。
Restic を使用する場合は、Restic がオブジェクトストレージにファイルシステムをバックアップするため、スナップショットの場所を指定する必要はありません。
シークレット
バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret を作成します。
バックアップとスナップショットの場所で異なる認証情報を使用する場合は、次の 2 つの secret オブジェクトを作成します。
-
DataProtectionApplicationCR で指定する、バックアップの場所用のカスタムSecret。 -
DataProtectionApplicationCR で参照されない、スナップショットの場所用のデフォルトSecret。
Data Protection Application には、デフォルトの Secret が必要です。作成しないと、インストールは失敗します。
インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の credentials-velero ファイルを使用してデフォルトの Secret を作成できます。
4.3.3.3.1. デフォルト Secret の作成
バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret を作成します。
Secret のデフォルト名は cloud-credentials-azure です。
DataProtectionApplication カスタムリソース (CR) にはデフォルトの Secret が必要です。作成しないと、インストールは失敗します。バックアップの場所の Secret の名前が指定されていない場合は、デフォルトの名前が使用されます。
インストール時にバックアップの場所の認証情報を使用しない場合は、空の credentials-velero ファイルを使用してデフォルト名前で Secret を作成できます。
前提条件
- オブジェクトストレージとクラウドストレージがある場合は、同じ認証情報を使用する必要があります。
- Velero のオブジェクトストレージを設定する必要があります。
-
オブジェクトストレージ用の
credentials-veleroファイルを適切な形式で作成する必要があります。
手順
デフォルト名で
Secretを作成します。$ oc create secret generic cloud-credentials-azure -n openshift-adp --from-file cloud=credentials-velero
Secret は、Data Protection Application をインストールするときに、DataProtectionApplication CR の spec.backupLocations.credential ブロックで参照されます。
4.3.3.3.2. 異なる認証情報のシークレットの作成
バックアップとスナップショットの場所で異なる認証情報を使用する場合は、次の 2 つの Secret オブジェクトを作成する必要があります。
-
カスタム名を持つバックアップ場所の
Secret。カスタム名は、DataProtectionApplicationカスタムリソース (CR) のspec.backupLocationsブロックで指定されます。 -
スナップショットの場所
Secret(デフォルト名はcloud-credentials-azure)。このSecretは、DataProtectionApplicationで指定されていません。
手順
-
スナップショットの場所の
credentials-veleroファイルをクラウドプロバイダーに適した形式で作成します。 デフォルト名でスナップショットの場所の
Secretを作成します。$ oc create secret generic cloud-credentials-azure -n openshift-adp --from-file cloud=credentials-velero
-
オブジェクトストレージに適した形式で、バックアップ場所の
credentials-veleroファイルを作成します。 カスタム名を使用してバックアップ場所の
Secretを作成します。$ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
次の例のように、カスタム名の
SecretをDataProtectionApplicationに追加します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> namespace: openshift-adp spec: ... backupLocations: - velero: config: resourceGroup: <azure_resource_group> storageAccount: <azure_storage_account_id> subscriptionId: <azure_subscription_id> storageAccountKeyEnvVar: AZURE_STORAGE_ACCOUNT_ACCESS_KEY credential: key: cloud name: <custom_secret> 1 provider: azure default: true objectStorage: bucket: <bucket_name> prefix: <prefix> snapshotLocations: - velero: config: resourceGroup: <azure_resource_group> subscriptionId: <azure_subscription_id> incremental: "true" name: default provider: azure- 1
- カスタム名を持つバックアップ場所の
Secret。
4.3.3.4. Data Protection Application の設定
Velero リソースの割り当てを設定するか、自己署名 CA 証明書を有効にして、Data Protection Application を設定できます。
4.3.3.4.1. Velero の CPU とメモリーのリソース割り当てを設定
DataProtectionApplication カスタムリソース (CR) マニフェストを編集して、Velero Pod の CPU およびメモリーリソースの割り当てを設定します。
前提条件
- OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。
手順
次の例のように、
DataProtectionApplicationCR マニフェストのspec.configuration.velero.podConfig.ResourceAllocationsブロックの値を編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> spec: ... configuration: velero: podConfig: nodeSelector: <node selector> 1 resourceAllocations: 2 limits: cpu: "1" memory: 1024Mi requests: cpu: 200m memory: 256Mi
4.3.3.4.2. 自己署名 CA 証明書の有効化
certificate signed by unknown authority エラーを防ぐために、DataProtectionApplication カスタムリソース (CR) マニフェストを編集して、オブジェクトストレージの自己署名 CA 証明書を有効にする必要があります。
前提条件
- OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。
手順
DataProtectionApplicationCR マニフェストのspec.backupLocations.velero.objectStorage.caCertパラメーターとspec.backupLocations.velero.configパラメーターを編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> spec: ... backupLocations: - name: default velero: provider: aws default: true objectStorage: bucket: <bucket> prefix: <prefix> caCert: <base64_encoded_cert_string> 1 config: insecureSkipTLSVerify: "false" 2 ...
4.3.3.5. Data Protection Application のインストール
DataProtectionApplication API のインスタンスを作成して、Data Protection Application (DPA) をインストールします。
前提条件
- OADP Operator をインストールする必要があります。
- オブジェクトストレージをバックアップ場所として設定する必要があります。
- スナップショットを使用して PV をバックアップする場合、クラウドプロバイダーはネイティブスナップショット API または Container Storage Interface (CSI) スナップショットのいずれかをサポートする必要があります。
-
バックアップとスナップショットの場所で同じ認証情報を使用する場合は、デフォルトの名前である
cloud-credentials-azureを使用してSecretを作成する必要があります。 バックアップとスナップショットの場所で異なる認証情報を使用する場合は、2 つの
Secretsを作成する必要があります。-
バックアップ場所のカスタム名を持つ
Secret。このSecretをDataProtectionApplicationCR に追加します。 スナップショットの場所のデフォルト名
cloud-credentials-azureのSecret。このSecretは、DataProtectionApplicationCR では参照されません。注記インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の
credentials-veleroファイルを使用してデフォルトのSecretを作成できます。デフォルトのSecretがない場合、インストールは失敗します。
-
バックアップ場所のカスタム名を持つ
手順
- Operators → Installed Operators をクリックして、OADP Operator を選択します。
- Provided APIs で、DataProtectionApplication ボックスの Create instance をクリックします。
YAML View をクリックして、
DataProtectionApplicationマニフェストのパラメーターを更新します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> namespace: openshift-adp spec: configuration: velero: defaultPlugins: - azure - openshift 1 resourceTimeout: 10m 2 restic: enable: true 3 podConfig: nodeSelector: <node_selector> 4 backupLocations: - velero: config: resourceGroup: <azure_resource_group> 5 storageAccount: <azure_storage_account_id> 6 subscriptionId: <azure_subscription_id> 7 storageAccountKeyEnvVar: AZURE_STORAGE_ACCOUNT_ACCESS_KEY credential: key: cloud name: cloud-credentials-azure 8 provider: azure default: true objectStorage: bucket: <bucket_name> 9 prefix: <prefix> 10 snapshotLocations: 11 - velero: config: resourceGroup: <azure_resource_group> subscriptionId: <azure_subscription_id> incremental: "true" name: default provider: azure- 1
openshiftプラグインは必須です。- 2
- Velero CRD の可用性、volumeSnapshot の削除、バックアップリポジトリーの可用性など、タイムアウトが発生するまでに複数の Velero リソースを待機する時間を分単位で指定します。デフォルトは 10m です。
- 3
- Restic のインストールを無効にする場合は、
falseに設定します。Restic はデーモンセットをデプロイします。これは、各ワーカーノードでResticPod が実行されていることを意味します。spec.defaultVolumesToRestic: trueをBackupCR に追加することで、バックアップ用に Restic を設定できます。 - 4
- Restic を使用できるノードを指定します。デフォルトでは、Restic はすべてのノードで実行されます。
- 5
- Azure リソースグループを指定します。
- 6
- Azure ストレージアカウント ID を指定します。
- 7
- Azure サブスクリプション ID を指定します。
- 8
- この値を指定しない場合は、デフォルト名の
cloud-credentials-azureが使用されます。カスタム名を指定すると、バックアップの場所にカスタム名が使用されます。 - 9
- バックアップの保存場所としてバケットを指定します。バケットが Velero バックアップ専用のバケットでない場合は、接頭辞を指定する必要があります。
- 10
- バケットが複数の目的で使用される場合は、Velero バックアップの接頭辞を指定します (例:
velero)。 - 11
- CSI スナップショットまたは Restic を使用して PV をバックアップする場合は、スナップショットの場所を指定する必要はありません。
- Create をクリックします。
OADP リソースを表示して、インストールを確認します。
$ oc get all -n openshift-adp
出力例
NAME READY STATUS RESTARTS AGE pod/oadp-operator-controller-manager-67d9494d47-6l8z8 2/2 Running 0 2m8s pod/restic-9cq4q 1/1 Running 0 94s pod/restic-m4lts 1/1 Running 0 94s pod/restic-pv4kr 1/1 Running 0 95s pod/velero-588db7f655-n842v 1/1 Running 0 95s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/oadp-operator-controller-manager-metrics-service ClusterIP 172.30.70.140 <none> 8443/TCP 2m8s NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/restic 3 3 3 3 3 <none> 96s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/oadp-operator-controller-manager 1/1 1 1 2m9s deployment.apps/velero 1/1 1 1 96s NAME DESIRED CURRENT READY AGE replicaset.apps/oadp-operator-controller-manager-67d9494d47 1 1 1 2m9s replicaset.apps/velero-588db7f655 1 1 1 96s
4.3.3.5.1. DataProtectionApplication CR で CSI を有効にする
CSI スナップショットを使用して永続ボリュームをバックアップするには、DataProtectionApplication カスタムリソース (CR) で Container Storage Interface (CSI) を有効にします。
前提条件
- クラウドプロバイダーは、CSI スナップショットをサポートする必要があります。
手順
次の例のように、
DataProtectionApplicationCR を編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication ... spec: configuration: velero: defaultPlugins: - openshift - csi 1- 1
csiデフォルトプラグインを追加します。
4.3.4. Google Cloud Platform を使用した OpenShift API for Data Protection のインストールおよび設定
OADP Operator をインストールすることで、Google Cloud Platform (GCP) を使用して OpenShift API for Data Protection (OADP) をインストールします。Operator は Velero 1.9 をインストールします。
OADP 1.0.4 以降、すべて OADP 1.0.z バージョンは、MTC Operator の依存関係としてのみ使用でき、スタンドアロン Operator としては使用できません。
Velero 向けに GCP を設定し、デフォルトの Secret を作成し、次に、Data Protection Application をインストールします。
制限されたネットワーク環境に OADP Operator をインストールするには、最初にデフォルトの Operator Hub ソースを無効にして、Operator カタログをミラーリングする必要があります。詳細は、ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。
4.3.4.1. OADP Operator のインストール
Operator Lifecycle Manager (OLM) を使用して、OpenShift Container Platform 4.12 に OpenShift API for Data Protection (OADP) オペレーターをインストールします。
OADP オペレーターは Velero 1.9 をインストールします。
前提条件
-
cluster-admin権限を持つユーザーとしてログインしている。
手順
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- Filter by keyword フィールドを使用して、OADP Operator を検索します。
- OADP Operator を選択し、Install をクリックします。
-
Install をクリックして、
openshift-adpプロジェクトに Operator をインストールします。 - Operators → Installed Operators をクリックして、インストールを確認します。
4.3.4.2. Google Cloud Provider の設定
OpenShift API for Data Protection (OADP) 用に Google Cloud Platform (GCP) を設定します。
前提条件
-
gcloudおよびgsutilCLI ツールがインストールされている必要があります。詳細は、Google Cloud のドキュメント をご覧ください。
手順
GCP にログインします。
$ gcloud auth login
BUCKET変数を設定します。$ BUCKET=<bucket> 1- 1
- バケット名を指定します。
ストレージバケットを作成します。
$ gsutil mb gs://$BUCKET/
PROJECT_ID変数をアクティブなプロジェクトに設定します。$ PROJECT_ID=$(gcloud config get-value project)
サービスアカウントを作成します。
$ gcloud iam service-accounts create velero \ --display-name "Velero service account"サービスアカウントを一覧表示します。
$ gcloud iam service-accounts list
emailの値と一致するようにSERVICE_ACCOUNT_EMAIL変数を設定します。$ SERVICE_ACCOUNT_EMAIL=$(gcloud iam service-accounts list \ --filter="displayName:Velero service account" \ --format 'value(email)')ポリシーを添付して、
veleroユーザーに必要最小限の権限を付与します。$ ROLE_PERMISSIONS=( compute.disks.get compute.disks.create compute.disks.createSnapshot compute.snapshots.get compute.snapshots.create compute.snapshots.useReadOnly compute.snapshots.delete compute.zones.get storage.objects.create storage.objects.delete storage.objects.get storage.objects.list iam.serviceAccounts.signBlob )velero.serverカスタムロールを作成します。$ gcloud iam roles create velero.server \ --project $PROJECT_ID \ --title "Velero Server" \ --permissions "$(IFS=","; echo "${ROLE_PERMISSIONS[*]}")"IAM ポリシーバインディングをプロジェクトに追加します。
$ gcloud projects add-iam-policy-binding $PROJECT_ID \ --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \ --role projects/$PROJECT_ID/roles/velero.serverIAM サービスアカウントを更新します。
$ gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}IAM サービスアカウントのキーを現在のディレクトリーにある
credentials-veleroファイルに保存します。$ gcloud iam service-accounts keys create credentials-velero \ --iam-account $SERVICE_ACCOUNT_EMAILData Protection Application をインストールする前に、
credentials-veleroファイルを使用して GCP のSecretオブジェクトを作成します。
4.3.4.3. バックアップおよびスナップショットの場所、ならびにそのシークレットについて
DataProtectionApplication カスタムリソース (CR) で、バックアップおよびスナップショットの場所、ならびにそのシークレットを指定します。
バックアップの場所
Multicloud Object Gateway、Noobaa、または Minio などの S3 互換オブジェクトストレージを、バックアップの場所として指定します。
Velero は、オブジェクトストレージのアーカイブファイルとして、OpenShift Container Platform リソース、Kubernetes オブジェクト、および内部イメージをバックアップします。
スナップショットの場所
クラウドプロバイダーのネイティブスナップショット API を使用して永続ボリュームをバックアップする場合、クラウドプロバイダーをスナップショットの場所として指定する必要があります。
Container Storage Interface (CSI) スナップショットを使用する場合、CSI ドライバーを登録するために VolumeSnapshotClass CR を作成するため、スナップショットの場所を指定する必要はありません。
Restic を使用する場合は、Restic がオブジェクトストレージにファイルシステムをバックアップするため、スナップショットの場所を指定する必要はありません。
シークレット
バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret を作成します。
バックアップとスナップショットの場所で異なる認証情報を使用する場合は、次の 2 つの secret オブジェクトを作成します。
-
DataProtectionApplicationCR で指定する、バックアップの場所用のカスタムSecret。 -
DataProtectionApplicationCR で参照されない、スナップショットの場所用のデフォルトSecret。
Data Protection Application には、デフォルトの Secret が必要です。作成しないと、インストールは失敗します。
インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の credentials-velero ファイルを使用してデフォルトの Secret を作成できます。
4.3.4.3.1. デフォルト Secret の作成
バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret を作成します。
Secret のデフォルト名は cloud-credentials-gcp です。
DataProtectionApplication カスタムリソース (CR) にはデフォルトの Secret が必要です。作成しないと、インストールは失敗します。バックアップの場所の Secret の名前が指定されていない場合は、デフォルトの名前が使用されます。
インストール時にバックアップの場所の認証情報を使用しない場合は、空の credentials-velero ファイルを使用してデフォルト名前で Secret を作成できます。
前提条件
- オブジェクトストレージとクラウドストレージがある場合は、同じ認証情報を使用する必要があります。
- Velero のオブジェクトストレージを設定する必要があります。
-
オブジェクトストレージ用の
credentials-veleroファイルを適切な形式で作成する必要があります。
手順
デフォルト名で
Secretを作成します。$ oc create secret generic cloud-credentials-gcp -n openshift-adp --from-file cloud=credentials-velero
Secret は、Data Protection Application をインストールするときに、DataProtectionApplication CR の spec.backupLocations.credential ブロックで参照されます。
4.3.4.3.2. 異なる認証情報のシークレットの作成
バックアップとスナップショットの場所で異なる認証情報を使用する場合は、次の 2 つの Secret オブジェクトを作成する必要があります。
-
カスタム名を持つバックアップ場所の
Secret。カスタム名は、DataProtectionApplicationカスタムリソース (CR) のspec.backupLocationsブロックで指定されます。 -
スナップショットの場所
Secret(デフォルト名はcloud-credentials-gcp)。このSecretは、DataProtectionApplicationで指定されていません。
手順
-
スナップショットの場所の
credentials-veleroファイルをクラウドプロバイダーに適した形式で作成します。 デフォルト名でスナップショットの場所の
Secretを作成します。$ oc create secret generic cloud-credentials-gcp -n openshift-adp --from-file cloud=credentials-velero
-
オブジェクトストレージに適した形式で、バックアップ場所の
credentials-veleroファイルを作成します。 カスタム名を使用してバックアップ場所の
Secretを作成します。$ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
次の例のように、カスタム名の
SecretをDataProtectionApplicationに追加します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> namespace: openshift-adp spec: ... backupLocations: - velero: provider: gcp default: true credential: key: cloud name: <custom_secret> 1 objectStorage: bucket: <bucket_name> prefix: <prefix> snapshotLocations: - velero: provider: gcp default: true config: project: <project> snapshotLocation: us-west1- 1
- カスタム名を持つバックアップ場所の
Secret。
4.3.4.4. Data Protection Application の設定
Velero リソースの割り当てを設定するか、自己署名 CA 証明書を有効にして、Data Protection Application を設定できます。
4.3.4.4.1. Velero の CPU とメモリーのリソース割り当てを設定
DataProtectionApplication カスタムリソース (CR) マニフェストを編集して、Velero Pod の CPU およびメモリーリソースの割り当てを設定します。
前提条件
- OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。
手順
次の例のように、
DataProtectionApplicationCR マニフェストのspec.configuration.velero.podConfig.ResourceAllocationsブロックの値を編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> spec: ... configuration: velero: podConfig: nodeSelector: <node selector> 1 resourceAllocations: 2 limits: cpu: "1" memory: 1024Mi requests: cpu: 200m memory: 256Mi
4.3.4.4.2. 自己署名 CA 証明書の有効化
certificate signed by unknown authority エラーを防ぐために、DataProtectionApplication カスタムリソース (CR) マニフェストを編集して、オブジェクトストレージの自己署名 CA 証明書を有効にする必要があります。
前提条件
- OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。
手順
DataProtectionApplicationCR マニフェストのspec.backupLocations.velero.objectStorage.caCertパラメーターとspec.backupLocations.velero.configパラメーターを編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> spec: ... backupLocations: - name: default velero: provider: aws default: true objectStorage: bucket: <bucket> prefix: <prefix> caCert: <base64_encoded_cert_string> 1 config: insecureSkipTLSVerify: "false" 2 ...
4.3.4.5. Data Protection Application のインストール
DataProtectionApplication API のインスタンスを作成して、Data Protection Application (DPA) をインストールします。
前提条件
- OADP Operator をインストールする必要があります。
- オブジェクトストレージをバックアップ場所として設定する必要があります。
- スナップショットを使用して PV をバックアップする場合、クラウドプロバイダーはネイティブスナップショット API または Container Storage Interface (CSI) スナップショットのいずれかをサポートする必要があります。
-
バックアップとスナップショットの場所で同じ認証情報を使用する場合は、デフォルトの名前である
cloud-credentials-gcpを使用してSecretを作成する必要があります。 バックアップとスナップショットの場所で異なる認証情報を使用する場合は、2 つの
Secretsを作成する必要があります。-
バックアップ場所のカスタム名を持つ
Secret。このSecretをDataProtectionApplicationCR に追加します。 スナップショットの場所として、デフォルト名
cloud-credentials-gcpのSecret。このSecretは、DataProtectionApplicationCR では参照されません。注記インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の
credentials-veleroファイルを使用してデフォルトのSecretを作成できます。デフォルトのSecretがない場合、インストールは失敗します。
-
バックアップ場所のカスタム名を持つ
手順
- Operators → Installed Operators をクリックして、OADP Operator を選択します。
- Provided APIs で、DataProtectionApplication ボックスの Create instance をクリックします。
YAML View をクリックして、
DataProtectionApplicationマニフェストのパラメーターを更新します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> namespace: openshift-adp spec: configuration: velero: defaultPlugins: - gcp - openshift 1 resourceTimeout: 10m 2 restic: enable: true 3 podConfig: nodeSelector: <node_selector> 4 backupLocations: - velero: provider: gcp default: true credential: key: cloud name: cloud-credentials-gcp 5 objectStorage: bucket: <bucket_name> 6 prefix: <prefix> 7 snapshotLocations: 8 - velero: provider: gcp default: true config: project: <project> snapshotLocation: us-west1 9- 1
openshiftプラグインは必須です。- 2
- Velero CRD の可用性、volumeSnapshot の削除、バックアップリポジトリーの可用性など、タイムアウトが発生するまでに複数の Velero リソースを待機する時間を分単位で指定します。デフォルトは 10m です。
- 3
- Restic のインストールを無効にする場合は、
falseに設定します。Restic はデーモンセットをデプロイします。これは、各ワーカーノードでResticPod が実行されていることを意味します。spec.defaultVolumesToRestic: trueをBackupCR に追加することで、バックアップ用に Restic を設定できます。 - 4
- Restic を使用できるノードを指定します。デフォルトでは、Restic はすべてのノードで実行されます。
- 5
- この値を指定しない場合は、デフォルトの名前である
cloud-credentials-gcpが使用されます。カスタム名を指定すると、バックアップの場所にカスタム名が使用されます。 - 6
- バックアップの保存場所としてバケットを指定します。バケットが Velero バックアップ専用のバケットでない場合は、接頭辞を指定する必要があります。
- 7
- バケットが複数の目的で使用される場合は、Velero バックアップの接頭辞を指定します (例:
velero)。 - 8
- CSI スナップショットまたは Restic を使用して PV をバックアップする場合を除き、スナップショットの場所を指定します。
- 9
- スナップショットの場所は、PV と同じリージョンにある必要があります。
- Create をクリックします。
OADP リソースを表示して、インストールを確認します。
$ oc get all -n openshift-adp
出力例
NAME READY STATUS RESTARTS AGE pod/oadp-operator-controller-manager-67d9494d47-6l8z8 2/2 Running 0 2m8s pod/restic-9cq4q 1/1 Running 0 94s pod/restic-m4lts 1/1 Running 0 94s pod/restic-pv4kr 1/1 Running 0 95s pod/velero-588db7f655-n842v 1/1 Running 0 95s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/oadp-operator-controller-manager-metrics-service ClusterIP 172.30.70.140 <none> 8443/TCP 2m8s NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/restic 3 3 3 3 3 <none> 96s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/oadp-operator-controller-manager 1/1 1 1 2m9s deployment.apps/velero 1/1 1 1 96s NAME DESIRED CURRENT READY AGE replicaset.apps/oadp-operator-controller-manager-67d9494d47 1 1 1 2m9s replicaset.apps/velero-588db7f655 1 1 1 96s
4.3.4.5.1. DataProtectionApplication CR で CSI を有効にする
CSI スナップショットを使用して永続ボリュームをバックアップするには、DataProtectionApplication カスタムリソース (CR) で Container Storage Interface (CSI) を有効にします。
前提条件
- クラウドプロバイダーは、CSI スナップショットをサポートする必要があります。
手順
次の例のように、
DataProtectionApplicationCR を編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication ... spec: configuration: velero: defaultPlugins: - openshift - csi 1- 1
csiデフォルトプラグインを追加します。
4.3.5. Multicloud Object Gateway を使用した OpenShift API for Data Protection のインストールおよび設定
OADP Operator をインストールすることで、Multicloud Object Gateway (MCG) を使用して OpenShift API for Data Protection (OADP) をインストールします。Operator は Velero 1.9 をインストールします。
OADP 1.0.4 以降、すべて OADP 1.0.z バージョンは、MTC Operator の依存関係としてのみ使用でき、スタンドアロン Operator としては使用できません。
Multicloud Object Gateway をバックアップの場所として設定します。MCG は、OpenShift Data Foundation のコンポーネントです。MCG は、DataProtectionApplication カスタムリソース (CR) のバックアップ場所として設定します。
オブジェクトストレージのバケット作成を自動化する CloudStorage API は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
バックアップの場所の Secret を作成し、次に、Data Protection Application をインストールします。
制限されたネットワーク環境に OADP Operator をインストールするには、最初にデフォルトの Operator Hub ソースを無効にして、Operator カタログをミラーリングする必要があります。詳細は、ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。
4.3.5.1. OADP Operator のインストール
Operator Lifecycle Manager (OLM) を使用して、OpenShift Container Platform 4.12 に OpenShift API for Data Protection (OADP) オペレーターをインストールします。
OADP オペレーターは Velero 1.9 をインストールします。
前提条件
-
cluster-admin権限を持つユーザーとしてログインしている。
手順
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- Filter by keyword フィールドを使用して、OADP Operator を検索します。
- OADP Operator を選択し、Install をクリックします。
-
Install をクリックして、
openshift-adpプロジェクトに Operator をインストールします。 - Operators → Installed Operators をクリックして、インストールを確認します。
4.3.5.2. Multicloud Object Gateway の認証情報の取得
OpenShift API for Data Protection (OADP) の Secret カスタムリソース (CR) を作成するには、Multicloud Object Gateway (MCG) 認証情報を取得する必要があります。
MCG は、OpenShift Data Foundation のコンポーネントです。
前提条件
- 適切な OpenShift Data Foundation deployment guide を使用して、OpenShift Data Foundation をデプロイする必要があります。
手順
-
NooBaaカスタムリソースでdescribeコマンドを実行して、S3 エンドポイントであるAWS_ACCESS_KEY_IDおよびAWS_SECRET_ACCESS_KEYを取得します。 credentials-veleroファイルを作成します。$ cat << EOF > ./credentials-velero [default] aws_access_key_id=<AWS_ACCESS_KEY_ID> aws_secret_access_key=<AWS_SECRET_ACCESS_KEY> EOF
Data Protection Application をインストールする際に、
credentials-veleroファイルを使用してSecretオブジェクトを作成します。
4.3.5.3. バックアップおよびスナップショットの場所、ならびにそのシークレットについて
DataProtectionApplication カスタムリソース (CR) で、バックアップおよびスナップショットの場所、ならびにそのシークレットを指定します。
バックアップの場所
Multicloud Object Gateway、Noobaa、または Minio などの S3 互換オブジェクトストレージを、バックアップの場所として指定します。
Velero は、オブジェクトストレージのアーカイブファイルとして、OpenShift Container Platform リソース、Kubernetes オブジェクト、および内部イメージをバックアップします。
スナップショットの場所
クラウドプロバイダーのネイティブスナップショット API を使用して永続ボリュームをバックアップする場合、クラウドプロバイダーをスナップショットの場所として指定する必要があります。
Container Storage Interface (CSI) スナップショットを使用する場合、CSI ドライバーを登録するために VolumeSnapshotClass CR を作成するため、スナップショットの場所を指定する必要はありません。
Restic を使用する場合は、Restic がオブジェクトストレージにファイルシステムをバックアップするため、スナップショットの場所を指定する必要はありません。
シークレット
バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret を作成します。
バックアップとスナップショットの場所で異なる認証情報を使用する場合は、次の 2 つの secret オブジェクトを作成します。
-
DataProtectionApplicationCR で指定する、バックアップの場所用のカスタムSecret。 -
DataProtectionApplicationCR で参照されない、スナップショットの場所用のデフォルトSecret。
Data Protection Application には、デフォルトの Secret が必要です。作成しないと、インストールは失敗します。
インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の credentials-velero ファイルを使用してデフォルトの Secret を作成できます。
4.3.5.3.1. デフォルト Secret の作成
バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret を作成します。
Secret のデフォルト名は cloud-credentials です。
DataProtectionApplication カスタムリソース (CR) にはデフォルトの Secret が必要です。作成しないと、インストールは失敗します。バックアップの場所の Secret の名前が指定されていない場合は、デフォルトの名前が使用されます。
インストール時にバックアップの場所の認証情報を使用しない場合は、空の credentials-velero ファイルを使用してデフォルト名前で Secret を作成できます。
前提条件
- オブジェクトストレージとクラウドストレージがある場合は、同じ認証情報を使用する必要があります。
- Velero のオブジェクトストレージを設定する必要があります。
-
オブジェクトストレージ用の
credentials-veleroファイルを適切な形式で作成する必要があります。
手順
デフォルト名で
Secretを作成します。$ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
Secret は、Data Protection Application をインストールするときに、DataProtectionApplication CR の spec.backupLocations.credential ブロックで参照されます。
4.3.5.3.2. 異なる認証情報のシークレットの作成
バックアップとスナップショットの場所で異なる認証情報を使用する場合は、次の 2 つの Secret オブジェクトを作成する必要があります。
-
カスタム名を持つバックアップ場所の
Secret。カスタム名は、DataProtectionApplicationカスタムリソース (CR) のspec.backupLocationsブロックで指定されます。 -
スナップショットの場所
Secret(デフォルト名はcloud-credentials)。このSecretは、DataProtectionApplicationで指定されていません。
手順
-
スナップショットの場所の
credentials-veleroファイルをクラウドプロバイダーに適した形式で作成します。 デフォルト名でスナップショットの場所の
Secretを作成します。$ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
-
オブジェクトストレージに適した形式で、バックアップ場所の
credentials-veleroファイルを作成します。 カスタム名を使用してバックアップ場所の
Secretを作成します。$ oc create secret generic <custom_secret> -n openshift-adp --from-file cloud=credentials-velero
次の例のように、カスタム名の
SecretをDataProtectionApplicationに追加します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> namespace: openshift-adp spec: ... backupLocations: - velero: config: profile: "default" region: minio s3Url: <url> insecureSkipTLSVerify: "true" s3ForcePathStyle: "true" provider: aws default: true credential: key: cloud name: <custom_secret> 1 objectStorage: bucket: <bucket_name> prefix: <prefix>- 1
- カスタム名を持つバックアップ場所の
Secret。
4.3.5.4. Data Protection Application の設定
Velero リソースの割り当てを設定するか、自己署名 CA 証明書を有効にして、Data Protection Application を設定できます。
4.3.5.4.1. Velero の CPU とメモリーのリソース割り当てを設定
DataProtectionApplication カスタムリソース (CR) マニフェストを編集して、Velero Pod の CPU およびメモリーリソースの割り当てを設定します。
前提条件
- OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。
手順
次の例のように、
DataProtectionApplicationCR マニフェストのspec.configuration.velero.podConfig.ResourceAllocationsブロックの値を編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> spec: ... configuration: velero: podConfig: nodeSelector: <node selector> 1 resourceAllocations: 2 limits: cpu: "1" memory: 1024Mi requests: cpu: 200m memory: 256Mi
4.3.5.4.2. 自己署名 CA 証明書の有効化
certificate signed by unknown authority エラーを防ぐために、DataProtectionApplication カスタムリソース (CR) マニフェストを編集して、オブジェクトストレージの自己署名 CA 証明書を有効にする必要があります。
前提条件
- OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。
手順
DataProtectionApplicationCR マニフェストのspec.backupLocations.velero.objectStorage.caCertパラメーターとspec.backupLocations.velero.configパラメーターを編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> spec: ... backupLocations: - name: default velero: provider: aws default: true objectStorage: bucket: <bucket> prefix: <prefix> caCert: <base64_encoded_cert_string> 1 config: insecureSkipTLSVerify: "false" 2 ...
4.3.5.5. Data Protection Application のインストール
DataProtectionApplication API のインスタンスを作成して、Data Protection Application (DPA) をインストールします。
前提条件
- OADP Operator をインストールする必要があります。
- オブジェクトストレージをバックアップ場所として設定する必要があります。
- スナップショットを使用して PV をバックアップする場合、クラウドプロバイダーはネイティブスナップショット API または Container Storage Interface (CSI) スナップショットのいずれかをサポートする必要があります。
-
バックアップとスナップショットの場所で同じ認証情報を使用する場合は、デフォルトの名前である
cloud-credentialsを使用してSecretを作成する必要があります。 バックアップとスナップショットの場所で異なる認証情報を使用する場合は、2 つの
Secretsを作成する必要があります。-
バックアップ場所のカスタム名を持つ
Secret。このSecretをDataProtectionApplicationCR に追加します。 スナップショットの場所のデフォルト名である
cloud-credentialsのSecret。このSecretは、DataProtectionApplicationCR では参照されません。注記インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の
credentials-veleroファイルを使用してデフォルトのSecretを作成できます。デフォルトのSecretがない場合、インストールは失敗します。
-
バックアップ場所のカスタム名を持つ
手順
- Operators → Installed Operators をクリックして、OADP Operator を選択します。
- Provided APIs で、DataProtectionApplication ボックスの Create instance をクリックします。
YAML View をクリックして、
DataProtectionApplicationマニフェストのパラメーターを更新します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> namespace: openshift-adp spec: configuration: velero: defaultPlugins: - aws - openshift 1 resourceTimeout: 10m 2 restic: enable: true 3 podConfig: nodeSelector: <node_selector> 4 backupLocations: - velero: config: profile: "default" region: minio s3Url: <url> 5 insecureSkipTLSVerify: "true" s3ForcePathStyle: "true" provider: aws default: true credential: key: cloud name: cloud-credentials 6 objectStorage: bucket: <bucket_name> 7 prefix: <prefix> 8- 1
openshiftプラグインは必須です。- 2
- Velero CRD の可用性、volumeSnapshot の削除、バックアップリポジトリーの可用性など、タイムアウトが発生するまでに複数の Velero リソースを待機する時間を分単位で指定します。デフォルトは 10m です。
- 3
- Restic のインストールを無効にする場合は、
falseに設定します。Restic はデーモンセットをデプロイします。これは、各ワーカーノードでResticPod が実行されていることを意味します。spec.defaultVolumesToRestic: trueをBackupCR に追加することで、バックアップ用に Restic を設定できます。 - 4
- Restic を使用できるノードを指定します。デフォルトでは、Restic はすべてのノードで実行されます。
- 5
- S3 エンドポイントの URL を指定します。
- 6
- この値を指定しない場合は、デフォルト名の
cloud-credentialsが使用されます。カスタム名を指定すると、バックアップの場所にカスタム名が使用されます。 - 7
- バックアップの保存場所としてバケットを指定します。バケットが Velero バックアップ専用のバケットでない場合は、接頭辞を指定する必要があります。
- 8
- バケットが複数の目的で使用される場合は、Velero バックアップの接頭辞を指定します (例:
velero)。
- Create をクリックします。
OADP リソースを表示して、インストールを確認します。
$ oc get all -n openshift-adp
出力例
NAME READY STATUS RESTARTS AGE pod/oadp-operator-controller-manager-67d9494d47-6l8z8 2/2 Running 0 2m8s pod/restic-9cq4q 1/1 Running 0 94s pod/restic-m4lts 1/1 Running 0 94s pod/restic-pv4kr 1/1 Running 0 95s pod/velero-588db7f655-n842v 1/1 Running 0 95s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/oadp-operator-controller-manager-metrics-service ClusterIP 172.30.70.140 <none> 8443/TCP 2m8s NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/restic 3 3 3 3 3 <none> 96s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/oadp-operator-controller-manager 1/1 1 1 2m9s deployment.apps/velero 1/1 1 1 96s NAME DESIRED CURRENT READY AGE replicaset.apps/oadp-operator-controller-manager-67d9494d47 1 1 1 2m9s replicaset.apps/velero-588db7f655 1 1 1 96s
4.3.5.5.1. DataProtectionApplication CR で CSI を有効にする
CSI スナップショットを使用して永続ボリュームをバックアップするには、DataProtectionApplication カスタムリソース (CR) で Container Storage Interface (CSI) を有効にします。
前提条件
- クラウドプロバイダーは、CSI スナップショットをサポートする必要があります。
手順
次の例のように、
DataProtectionApplicationCR を編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication ... spec: configuration: velero: defaultPlugins: - openshift - csi 1- 1
csiデフォルトプラグインを追加します。
4.3.6. OpenShift Data Foundation を使用した OpenShift API for Data Protection のインストールおよび設定
OpenShift Data Foundation を使用して Openshift API for Data Protection (OADP) をインストールするには、OADP Operator をインストールし、バックアップの場所とスナップショットロケーションを設定します。次に、Data Protection Application をインストールします。
OADP 1.0.4 以降、すべて OADP 1.0.z バージョンは、MTC Operator の依存関係としてのみ使用でき、スタンドアロン Operator としては使用できません。
Multicloud Object Gateway または任意の S3 互換のオブジェクトストレージをバックアップの場所として設定できます。
オブジェクトストレージのバケット作成を自動化する CloudStorage API は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
バックアップの場所の Secret を作成し、次に、Data Protection Application をインストールします。
制限されたネットワーク環境に OADP Operator をインストールするには、最初にデフォルトの Operator Hub ソースを無効にして、Operator カタログをミラーリングする必要があります。詳細は、ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。
4.3.6.1. OADP Operator のインストール
Operator Lifecycle Manager (OLM) を使用して、OpenShift Container Platform 4.12 に OpenShift API for Data Protection (OADP) オペレーターをインストールします。
OADP オペレーターは Velero 1.9 をインストールします。
前提条件
-
cluster-admin権限を持つユーザーとしてログインしている。
手順
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- Filter by keyword フィールドを使用して、OADP Operator を検索します。
- OADP Operator を選択し、Install をクリックします。
-
Install をクリックして、
openshift-adpプロジェクトに Operator をインストールします。 - Operators → Installed Operators をクリックして、インストールを確認します。
4.3.6.2. バックアップおよびスナップショットの場所、ならびにそのシークレットについて
DataProtectionApplication カスタムリソース (CR) で、バックアップおよびスナップショットの場所、ならびにそのシークレットを指定します。
バックアップの場所
Multicloud Object Gateway、Noobaa、または Minio などの S3 互換オブジェクトストレージを、バックアップの場所として指定します。
Velero は、オブジェクトストレージのアーカイブファイルとして、OpenShift Container Platform リソース、Kubernetes オブジェクト、および内部イメージをバックアップします。
スナップショットの場所
クラウドプロバイダーのネイティブスナップショット API を使用して永続ボリュームをバックアップする場合、クラウドプロバイダーをスナップショットの場所として指定する必要があります。
Container Storage Interface (CSI) スナップショットを使用する場合、CSI ドライバーを登録するために VolumeSnapshotClass CR を作成するため、スナップショットの場所を指定する必要はありません。
Restic を使用する場合は、Restic がオブジェクトストレージにファイルシステムをバックアップするため、スナップショットの場所を指定する必要はありません。
シークレット
バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret を作成します。
バックアップとスナップショットの場所で異なる認証情報を使用する場合は、次の 2 つの secret オブジェクトを作成します。
-
DataProtectionApplicationCR で指定する、バックアップの場所用のカスタムSecret。 -
DataProtectionApplicationCR で参照されない、スナップショットの場所用のデフォルトSecret。
Data Protection Application には、デフォルトの Secret が必要です。作成しないと、インストールは失敗します。
インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の credentials-velero ファイルを使用してデフォルトの Secret を作成できます。
4.3.6.2.1. デフォルト Secret の作成
バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret を作成します。
DataProtectionApplication カスタムリソース (CR) にはデフォルトの Secret が必要です。作成しないと、インストールは失敗します。バックアップの場所の Secret の名前が指定されていない場合は、デフォルトの名前が使用されます。
インストール時にバックアップの場所の認証情報を使用しない場合は、空の credentials-velero ファイルを使用してデフォルト名前で Secret を作成できます。
前提条件
- オブジェクトストレージとクラウドストレージがある場合は、同じ認証情報を使用する必要があります。
- Velero のオブジェクトストレージを設定する必要があります。
-
オブジェクトストレージ用の
credentials-veleroファイルを適切な形式で作成する必要があります。
手順
デフォルト名で
Secretを作成します。$ oc create secret generic cloud-credentials -n openshift-adp --from-file cloud=credentials-velero
Secret は、Data Protection Application をインストールするときに、DataProtectionApplication CR の spec.backupLocations.credential ブロックで参照されます。
4.3.6.3. Data Protection Application の設定
Velero リソースの割り当てを設定するか、自己署名 CA 証明書を有効にして、Data Protection Application を設定できます。
4.3.6.3.1. Velero の CPU とメモリーのリソース割り当てを設定
DataProtectionApplication カスタムリソース (CR) マニフェストを編集して、Velero Pod の CPU およびメモリーリソースの割り当てを設定します。
前提条件
- OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。
手順
次の例のように、
DataProtectionApplicationCR マニフェストのspec.configuration.velero.podConfig.ResourceAllocationsブロックの値を編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> spec: ... configuration: velero: podConfig: nodeSelector: <node selector> 1 resourceAllocations: 2 limits: cpu: "1" memory: 1024Mi requests: cpu: 200m memory: 256Mi
4.3.6.3.2. 自己署名 CA 証明書の有効化
certificate signed by unknown authority エラーを防ぐために、DataProtectionApplication カスタムリソース (CR) マニフェストを編集して、オブジェクトストレージの自己署名 CA 証明書を有効にする必要があります。
前提条件
- OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。
手順
DataProtectionApplicationCR マニフェストのspec.backupLocations.velero.objectStorage.caCertパラメーターとspec.backupLocations.velero.configパラメーターを編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_sample> spec: ... backupLocations: - name: default velero: provider: aws default: true objectStorage: bucket: <bucket> prefix: <prefix> caCert: <base64_encoded_cert_string> 1 config: insecureSkipTLSVerify: "false" 2 ...
4.3.6.4. Data Protection Application のインストール
DataProtectionApplication API のインスタンスを作成して、Data Protection Application (DPA) をインストールします。
前提条件
- OADP Operator をインストールする必要があります。
- オブジェクトストレージをバックアップ場所として設定する必要があります。
- スナップショットを使用して PV をバックアップする場合、クラウドプロバイダーはネイティブスナップショット API または Container Storage Interface (CSI) スナップショットのいずれかをサポートする必要があります。
バックアップとスナップショットの場所で同じ認証情報を使用する場合は、デフォルトの名前である
cloud-credentialsを使用してSecretを作成する必要があります。注記インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の
credentials-veleroファイルを使用してデフォルトのSecretを作成できます。デフォルトのSecretがない場合、インストールは失敗します。
手順
- Operators → Installed Operators をクリックして、OADP Operator を選択します。
- Provided APIs で、DataProtectionApplication ボックスの Create instance をクリックします。
-
YAML View をクリックして、
DataProtectionApplicationマニフェストのパラメーターを更新します。 - Create をクリックします。
OADP リソースを表示して、インストールを確認します。
$ oc get all -n openshift-adp
出力例
NAME READY STATUS RESTARTS AGE pod/oadp-operator-controller-manager-67d9494d47-6l8z8 2/2 Running 0 2m8s pod/restic-9cq4q 1/1 Running 0 94s pod/restic-m4lts 1/1 Running 0 94s pod/restic-pv4kr 1/1 Running 0 95s pod/velero-588db7f655-n842v 1/1 Running 0 95s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/oadp-operator-controller-manager-metrics-service ClusterIP 172.30.70.140 <none> 8443/TCP 2m8s NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/restic 3 3 3 3 3 <none> 96s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/oadp-operator-controller-manager 1/1 1 1 2m9s deployment.apps/velero 1/1 1 1 96s NAME DESIRED CURRENT READY AGE replicaset.apps/oadp-operator-controller-manager-67d9494d47 1 1 1 2m9s replicaset.apps/velero-588db7f655 1 1 1 96s
4.3.6.4.1. OpenShift Data Foundation での障害復旧のための NooBaa の設定
OpenShift Data Foundation で NooBaa バケットの backupStorageLocation にクラスターストレージを使用する場合は、NooBaa を外部オブジェクトストアとして設定します。
NooBaa を外部オブジェクトストアとして設定しないと、バックアップが利用できなくなる可能性があります。
手順
- ハイブリッドまたはマルチクラウドのストレージリソースの追加 の説明に従って、NooBaa を外部オブジェクトストアとして設定します。
4.3.6.4.2. DataProtectionApplication CR で CSI を有効にする
CSI スナップショットを使用して永続ボリュームをバックアップするには、DataProtectionApplication カスタムリソース (CR) で Container Storage Interface (CSI) を有効にします。
前提条件
- クラウドプロバイダーは、CSI スナップショットをサポートする必要があります。
手順
次の例のように、
DataProtectionApplicationCR を編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication ... spec: configuration: velero: defaultPlugins: - openshift - csi 1- 1
csiデフォルトプラグインを追加します。
4.3.7. OpenShift API for Data Protection のアンインストール
OpenShift API for Data Protection (OADP) をアンインストールするには、OADP Operator を削除します。詳細は、クラスターからの演算子の削除 を参照してください。
4.4. バックアップおよび復元
4.4.1. アプリケーションのバックアップ
Backup カスタムリソース (CR) を作成して、アプリケーションをバックアップします。バックアップ CR の作成 を参照してください。
Backup CR は、Kubernetes リソースや内部イメージのバックアップファイルを S3 オブジェクトストレージ上に作成し、クラウドプロバイダーが OpenShift Data Foundation 4 のようにスナップショットを作成するためにネイティブスナップショット API や Container Storage Interface (CSI) を使用している場合は、永続ボリューム (PV) のスナップショットを作成します。
CSI ボリュームスナップショットの詳細は、CSI ボリュームスナップショット を参照してください。
S3 ストレージ用の CloudStorage API は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
-
クラウドプロバイダーがネイティブスナップショット API を備えている場合、または CSI スナップショットをサポートしている場合、
BackupCR はスナップショットを作成することによって永続ボリューム (PV) をバックアップします。CSI スナップショットの操作の詳細は、CSI スナップショットを使用した永続ボリュームのバックアップ を参照してください。 - クラウドプロバイダーがスナップショットをサポートしていない場合、またはアプリケーションが NFS データボリューム上にある場合は、Restic を使用してバックアップを作成できます。Restic を使用したアプリケーションのバックアップ を参照してください。
OpenShift API for Data Protection (OADP) は、他のソフトウェアで作成されたボリュームスナップショットのバックアップをサポートしていません。
バックアップ操作の前または後にコマンドを実行するためのバックアップフックを作成できます。バックアップフックの作成 を参照してください。
Backup CR の代わりに Schedule CR を作成することにより、バックアップをスケジュールできます。バックアップのスケジュール設定 を参照してください。
4.4.1.1. バックアップ CR の作成
Backup カスタムリソース (CR) を作成して、Kubernetes イメージ、内部イメージ、および永続ボリューム (PV) をバックアップします。
前提条件
- OpenShift API for Data Protection (OADP) Operator をインストールする必要があります。
-
DataProtectionApplicationCR はReady状態である必要があります。 バックアップ場所の前提条件:
- Velero 用に S3 オブジェクトストレージを設定する必要があります。
-
DataProtectionApplicationCR でバックアップの場所を設定する必要があります。
スナップショットの場所の前提条件:
- クラウドプロバイダーには、ネイティブスナップショット API が必要であるか、Container Storage Interface (CSI) スナップショットをサポートしている必要があります。
-
CSI スナップショットの場合、CSI ドライバーを登録するために
VolumeSnapshotClassCR を作成する必要があります。 -
DataProtectionApplicationCR でボリュームの場所を設定する必要があります。
手順
次のコマンドを入力して、
backupStorageLocationsCR を取得します。$ oc get backupStorageLocations -n openshift-adp
出力例
NAMESPACE NAME PHASE LAST VALIDATED AGE DEFAULT openshift-adp velero-sample-1 Available 11s 31m
次の例のように、
BackupCR を作成します。apiVersion: velero.io/v1 kind: Backup metadata: name: <backup> labels: velero.io/storage-location: default namespace: openshift-adp spec: hooks: {} includedNamespaces: - <namespace> 1 includedResources: [] 2 excludedResources: [] 3 storageLocation: <velero-sample-1> 4 ttl: 720h0m0s labelSelector: 5 matchLabels: app=<label_1> app=<label_2> app=<label_3> orLabelSelectors: 6 - matchLabels: app=<label_1> app=<label_2> app=<label_3>- 1
- バックアップする namespace の配列を指定します。
- 2
- オプション: バックアップに含めるリソースの配列を指定します。リソースは、ショートカット (Pods は po など) または完全修飾の場合があります。指定しない場合、すべてのリソースが含まれます。
- 3
- オプション: バックアップから除外するリソースの配列を指定します。リソースは、ショートカット (Pods は po など) または完全修飾の場合があります。
- 4
backupStorageLocationsCR の名前を指定します。- 5
- 指定したラベルを すべて 持つバックアップリソースの {key,value} ペアのマップ。
- 6
- 指定したラベルを 1 つ以上 持つバックアップリソースの {key,value} ペアのマップ。
BackupCR のステータスがCompletedしたことを確認します。$ oc get backup -n openshift-adp <backup> -o jsonpath='{.status.phase}'
4.4.1.2. CSI スナップショットを使用した永続ボリュームのバックアップ
Backup CR を作成する前に、クラウドストレージの VolumeSnapshotClass カスタムリソース (CR) を編集して、Container Storage Interface (CSI) スナップショットを使用して永続ボリュームをバックアップします。
前提条件
- クラウドプロバイダーは、CSI スナップショットをサポートする必要があります。
-
DataProtectionApplicationCR で CSI を有効にする必要があります。
手順
metadata.labels.velero.io/csi-volumesnapshot-class: "true"のキー: 値ペアをVolumeSnapshotClassCR に追加します。apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshotClass metadata: name: <volume_snapshot_class_name> labels: velero.io/csi-volumesnapshot-class: "true" driver: <csi_driver> deletionPolicy: Retain
これで、Backup CR を作成できます。
4.4.1.3. Restic を使用したアプリケーションのバックアップ
Backup カスタムリソース (CR) を編集して、Restic を使用して Kubernetes リソース、内部イメージ、および永続ボリュームをバックアップします。
DataProtectionApplication CR でスナップショットの場所を指定する必要はありません。
Restic は、hostPath ボリュームのバックアップをサポートしません。詳細は、Restic のその他の制限事項 を参照してください。
前提条件
- OpenShift API for Data Protection (OADP) Operator をインストールする必要があります。
-
DataProtectionApplicationCR でspec.configuration.restic.enableをfalseに設定して、デフォルトの Restic インストールを無効にしないでください。 -
DataProtectionApplicationCR はReady状態である必要があります。
手順
次の例のように、
BackupCR を編集します。apiVersion: velero.io/v1 kind: Backup metadata: name: <backup> labels: velero.io/storage-location: default namespace: openshift-adp spec: defaultVolumesToRestic: true 1 ...- 1
defaultVolumesToRestic: trueをspecブロックに追加します。
4.4.1.4. CSI スナップショットに Data Mover を使用する
OADP Data Mover を使用すると、Container Storage Interface (CSI) ボリュームスナップショットをリモートオブジェクトストアにバックアップできます。
Data Mover が有効になっている場合、クラスターの障害、誤った削除、破損が発生した場合に、オブジェクトストアから取得した CSI ボリュームスナップショットを使用してステートフルアプリケーションを復元できます。
Data Mover ソリューションは、VolSync の Restic オプションを使用します。
Data Mover は、CSI ボリュームスナップショットのバックアップとリストアのみをサポートします。
OADP 1.2 Data Mover では、VolumeSnapshotBackups (VSB) および VolumeSnapshotRestore (VSR) は、VolumeSnapshotMover (VSM) を使用してキューに入れられます。VSM のパフォーマンスは、同時に InProgress で VSB と VSR の同時数を指定することで向上します。すべての非同期プラグイン操作が完了すると、バックアップは完了としてマークされます。
OADP 1.1 Data Mover はテクノロジープレビュー機能です。
OADP 1.2 Data Mover は機能とパフォーマンスが大幅に向上していますが、まだテクノロジープレビュー機能です。
OADP Data Mover はテクノロジープレビューのみの機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
Red Hat では、ODF CephFS ボリュームのバックアップおよびリストアに OADP 1.2 Data Mover を使用しているお客様には、パフォーマンスを向上させるために OpenShift Container Platform バージョン 4.12 以降をアップグレードまたはインストールすることを推奨します。OADP Data Mover は、OpenShift Container Platform バージョン 4.12 以降の CephFS シャローボリュームを利用できます。これは、私たちのテストに基づくと、バックアップ時間のパフォーマンスを向上させることができます。
前提条件
-
StorageClassおよびVolumeSnapshotClassカスタムリソース (CR) が CSI をサポートしていることを確認しました。 注釈
snapshot.storage.kubernetes.io/is-default-class: trueを持つvolumeSnapshotClassCR が 1 つだけであることを確認しました。注記OpenShift Container Platform バージョン 4.12 以降では、これが唯一のデフォルト
volumeSnapshotClassであることを確認します。-
VolumeSnapshotClassCR のdeletionPolicyがRetainに設定されていることを確認しました。 -
注釈
storageclass.kubernetes.io/is-default-class: trueを持つstorageClassCR が 1 つだけであることを確認しました。 -
VolumeSnapshotClassCR にラベルvelero.io/csi-volumesnapshot-class: 'true'を含めました。 OADP namespaceにアノテーションoc annotate --overwrite namespace/openshift-adp volsync.backube/privileged-movers='true'があることを確認しました。注記OADP 1.1 では、上記の設定は必須です。
OADP 1.2 では、ほとんどのシナリオで
privileged-movers設定は必要ありません。復元コンテナーの権限は、Volsync コピーに対して適切である必要があります。一部のユーザーシナリオでは、privileged-mover=true設定で解決する必要がある権限エラーが発生する場合があります。Operator Lifecycle Manager (OLM) を使用して VolSync Operator をインストールしました。
注記OADP Data Mover を使用するには、VolSync Operator が必要です。
- OLM を使用して OADP Operator をインストールしました。
手順
.yamlファイルを作成して Restic シークレットを設定します。apiVersion: v1 kind: Secret metadata: name: <secret_name> type: Opaque stringData: # The repository encryption key RESTIC_PASSWORD: my-secure-restic-password
- 次の例のような DPA CR を作成します。デフォルトのプラグインには CSI が含まれています。
上記の手順で得た Restic シークレット名を DPA CR に
spec.features.dataMover.credentialNameとして追加します。この手順が完了していない場合は、デフォルトのシークレット名dm-credentialが使用されます。注記この DPA には、
CSIとVSMがdefaultPluginsとして含まれています。dataMover.enableフラグも含まれています。データ保護アプリケーション (DPA) CR の例
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: velero-sample namespace: openshift-adp spec: features: dataMover: enable: true credentialName: <secret-name> maxConcurrentBackupVolumes: "3" 1 maxConcurrentRestoreVolumes: "3" 2 pruneInterval: "14" 3 volumeOptionsForStorageClasses: 4 gp2-csi-copy-1: destinationVolumeOptions: storageClassName: csi-copy-2 sourceVolumeOptions: storageClassName: csi-copy-1 backupLocations: - velero: config: profile: default region: us-east-1 credential: key: cloud name: cloud-credentials default: true objectStorage: bucket: <bucket_name> prefix: <bucket-prefix> provider: aws configuration: restic: enable: false velero: defaultPlugins: - openshift - aws - csi - vsm 5- 1
- OADP 1.2 のみ。オプション: バックアップのためにキューに入れることができるスナップショットの数の上限を指定します。デフォルト値は 10 です。
- 2
- OADP 1.2 のみ。オプション: 復元のためにキューに入れることができるスナップショットの数の上限を指定します。デフォルト値は 10 です。
- 3
- OADP 1.2 のみ。オプション: リポジトリーで Restic プルーニングを実行する間隔の日数を指定します。プルーン操作ではデータを再パックして領域を解放しますが、プロセスの一部として大量の I/O トラフィックが生成される可能性もあります。このオプションを設定すると、参照されなくなったデータによるストレージ消費とアクセスコストとの間のトレードオフが可能になります。
- 4
- OADP 1.2 のみ。オプション: バックアップと復元の VolumeSync ボリュームオプションを指定します。
- 5
- OADP 1.2 のみ。
OADP Operator は、2 つのカスタムリソース定義 (CRD)、
VolumeSnapshotBackupおよびVolumeSnapshotRestoreをインストールします。VolumeSnapshotBackupCRD の例apiVersion: datamover.oadp.openshift.io/v1alpha1 kind: VolumeSnapshotBackup metadata: name: <vsb_name> namespace: <namespace_name> 1 spec: volumeSnapshotContent: name: <snapcontent_name> protectedNamespace: <adp_namespace> resticSecretRef: name: <restic_secret_name>- 1
- ボリュームスナップショットが存在する namespace を指定します。
VolumeSnapshotRestoreCRD の例apiVersion: datamover.oadp.openshift.io/v1alpha1 kind: VolumeSnapshotRestore metadata: name: <vsr_name> namespace: <namespace_name> 1 spec: protectedNamespace: <protected_ns> 2 resticSecretRef: name: <restic_secret_name> volumeSnapshotMoverBackupRef: sourcePVCData: name: <source_pvc_name> size: <source_pvc_size> resticrepository: <your_restic_repo> volumeSnapshotClassName: <vsclass_name>
次の手順を実行して、ボリュームスナップショットをバックアップできます。
バックアップ CR を作成します。
apiVersion: velero.io/v1 kind: Backup metadata: name: <backup_name> namespace: <protected_ns> 1 spec: includedNamespaces: - <app_ns> storageLocation: velero-sample-1- 1
- Operator がインストールされている namespace を指定します。デフォルトの namespace は
openshift-adpです。
次のコマンドを入力して、最大 10 分待機し、
VolumeSnapshotBackupCR のステータスがCompletedかどうかを確認します。$ oc get vsb -n <app_ns>
$ oc get vsb <vsb_name> -n <app_ns> -o jsonpath="{.status.phase}"DPA で設定されたオブジェクトストアにスナップショットが作成されます。
注記VolumeSnapshotBackupCR のステータスがFailedになった場合は、トラブルシューティングのために Velero ログを参照してください。
次の手順を実行して、ボリュームスナップショットを復元できます。
-
アプリケーションの namespace と、Velero CSI プラグインによって作成された
volumeSnapshotContentを削除します。 RestoreCR を作成し、restorePVsをtrueに設定します。RestoreCR の例apiVersion: velero.io/v1 kind: Restore metadata: name: <restore_name> namespace: <protected_ns> spec: backupName: <previous_backup_name> restorePVs: true
最大 10 分間待機し、次のコマンドを入力して、
VolumeSnapshotRestoreCR ステータスがCompletedであるかどうかを確認します。$ oc get vsr -n <app_ns>
$ oc get vsr <vsr_name> -n <app_ns> -o jsonpath="{.status.phase}"アプリケーションデータとリソースが復元されたかどうかを確認します。
注記VolumeSnapshotRestoreCR のステータスが失敗になった場合は、トラブルシューティングのために Velero ログを参照してください。
-
アプリケーションの namespace と、Velero CSI プラグインによって作成された
4.4.1.5. Ceph Storage での OADP 1.2 Data Mover の使用
OADP 1.2 Data Mover を使用して、CephFS、CephRBD、またはその両方を使用するクラスターのアプリケーションデータをバックアップおよび復元できます。
OADP 1.2 Data Mover は、大規模環境をサポートする Ceph 機能を活用します。その 1 つはシャローコピー方式で、OpenShift Container Platform 4.12 以降で利用できます。この機能は、ソース Persistent Volume Claim (PVC) にあるもの以外の StorageClass および AccessMode リソースのバックアップと復元をサポートします。
CephFS シャローコピー機能はバックアップ機能です。これは復元操作の一部ではありません。
4.4.1.5.1. Ceph Storage で OADP 1.2 Data Mover を使用するための前提条件
以下の前提条件は、Ceph Storage を使用するクラスター内で OpenShift API for Data Protection (OADP) 1.2 Data Mover を使用するすべてのデータのバックアップおよびリストア操作に適用されます。
- OpenShift Container Platform 4.12 以降がインストールされている。
- OADP Operator がインストールされました。
-
namespace
openshift-adpにシークレットのcloud-credentialsが作成されました。 - Red Hat OpenShift Data Foundation がインストールされています。
- Operator Lifecycle Manager を使用して最新の VolSync Operator をインストールしました。
4.4.1.5.2. OADP 1.2 Data Mover で使用するカスタムリソースの定義
Red Hat OpenShift Data Foundation をインストールすると、デフォルトの CephFS、CephRBD StorageClass および VolumeSnapshotClass カスタムリソース (CR) が自動的に作成されます。これらの CR は、OpenShift API for Data Protection (OADP) 1.2 Data Mover で使用するために定義する必要があります。
CR を定義した後、バックアップおよび復元操作を実行する前に、環境にその他の変更をいくつか加える必要があります。
4.4.1.5.3. OADP 1.2 Data Mover で使用する CephFS カスタムリソースの定義
Red Hat OpenShift Data Foundation をインストールすると、デフォルトの CephFS StorageClass カスタムリソース (CR) とデフォルトの CephFS VolumeSnapshotClass CR が自動的に作成されます。これらの CR は、OpenShift API for Data Protection (OADP) 1.2 Data Mover で使用するために定義できます。
手順
以下の例のように
VolumeSnapshotClassCR を定義します。VolumeSnapshotClassCR の例apiVersion: snapshot.storage.k8s.io/v1 deletionPolicy: Retain 1 driver: openshift-storage.cephfs.csi.ceph.com kind: VolumeSnapshotClass metadata: annotations: snapshot.storage.kubernetes.io/is-default-class: true 2 labels: velero.io/csi-volumesnapshot-class: true 3 name: ocs-storagecluster-cephfsplugin-snapclass parameters: clusterID: openshift-storage csi.storage.k8s.io/snapshotter-secret-name: rook-csi-cephfs-provisioner csi.storage.k8s.io/snapshotter-secret-namespace: openshift-storage
以下の例のように
StorageClassCR を定義します。StorageClassCR の例kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: ocs-storagecluster-cephfs annotations: description: Provides RWO and RWX Filesystem volumes storageclass.kubernetes.io/is-default-class: true 1 provisioner: openshift-storage.cephfs.csi.ceph.com parameters: clusterID: openshift-storage csi.storage.k8s.io/controller-expand-secret-name: rook-csi-cephfs-provisioner csi.storage.k8s.io/controller-expand-secret-namespace: openshift-storage csi.storage.k8s.io/node-stage-secret-name: rook-csi-cephfs-node csi.storage.k8s.io/node-stage-secret-namespace: openshift-storage csi.storage.k8s.io/provisioner-secret-name: rook-csi-cephfs-provisioner csi.storage.k8s.io/provisioner-secret-namespace: openshift-storage fsName: ocs-storagecluster-cephfilesystem reclaimPolicy: Delete allowVolumeExpansion: true volumeBindingMode: Immediate- 1
trueに設定する必要があります。
4.4.1.5.4. OADP 1.2 Data Mover で使用する CephRBD カスタムリソースの定義
Red Hat OpenShift Data Foundation をインストールすると、デフォルトの CephRBD StorageClass カスタムリソース (CR) とデフォルトの CephRBD VolumeSnapshotClass CR が自動的に作成されます。これらの CR は、OpenShift API for Data Protection (OADP) 1.2 Data Mover で使用するために定義できます。
手順
以下の例のように
VolumeSnapshotClassCR を定義します。VolumeSnapshotClassCR の例apiVersion: snapshot.storage.k8s.io/v1 deletionPolicy: Retain 1 driver: openshift-storage.rbd.csi.ceph.com kind: VolumeSnapshotClass metadata: labels: velero.io/csi-volumesnapshot-class: true 2 name: ocs-storagecluster-rbdplugin-snapclass parameters: clusterID: openshift-storage csi.storage.k8s.io/snapshotter-secret-name: rook-csi-rbd-provisioner csi.storage.k8s.io/snapshotter-secret-namespace: openshift-storage
以下の例のように
StorageClassCR を定義します。StorageClassCR の例kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: ocs-storagecluster-ceph-rbd annotations: description: 'Provides RWO Filesystem volumes, and RWO and RWX Block volumes' provisioner: openshift-storage.rbd.csi.ceph.com parameters: csi.storage.k8s.io/fstype: ext4 csi.storage.k8s.io/provisioner-secret-namespace: openshift-storage csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node csi.storage.k8s.io/controller-expand-secret-name: rook-csi-rbd-provisioner imageFormat: '2' clusterID: openshift-storage imageFeatures: layering csi.storage.k8s.io/controller-expand-secret-namespace: openshift-storage pool: ocs-storagecluster-cephblockpool csi.storage.k8s.io/node-stage-secret-namespace: openshift-storage reclaimPolicy: Delete allowVolumeExpansion: true volumeBindingMode: Immediate
4.4.1.5.5. OADP 1.2 Data Mover で使用する追加のカスタムリソースの定義
デフォルトの StorageClass および CephRBD VolumeSnapshotClass カスタムリソース (CR) を再定義した後、次の CR を作成する必要があります。
-
シャローコピー機能を使用するように定義された CephFS
StorageClassCR -
Rustic
SecretCR
手順
次の例のように CephFS
StorageClassCR を作成し、backingSnapshotパラメーターをtrueに設定します。backingSnapshotをtrueに設定した CephFSStorageClassCR の例kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: ocs-storagecluster-cephfs-shallow annotations: description: Provides RWO and RWX Filesystem volumes storageclass.kubernetes.io/is-default-class: false provisioner: openshift-storage.cephfs.csi.ceph.com parameters: csi.storage.k8s.io/provisioner-secret-namespace: openshift-storage csi.storage.k8s.io/provisioner-secret-name: rook-csi-cephfs-provisioner csi.storage.k8s.io/node-stage-secret-name: rook-csi-cephfs-node csi.storage.k8s.io/controller-expand-secret-name: rook-csi-cephfs-provisioner clusterID: openshift-storage fsName: ocs-storagecluster-cephfilesystem csi.storage.k8s.io/controller-expand-secret-namespace: openshift-storage backingSnapshot: true 1 csi.storage.k8s.io/node-stage-secret-namespace: openshift-storage reclaimPolicy: Delete allowVolumeExpansion: true volumeBindingMode: Immediate- 1
trueに設定する必要があります。
重要CephFS
VolumeSnapshotClassおよびStorageClassCR のProvisionerの値が同じであることを確認してください。次の例のように Restic
SecretCR を設定します。Restic
SecretCR の例apiVersion: v1 kind: Secret metadata: name: <secret_name> namespace: <namespace> type: Opaque stringData: RESTIC_PASSWORD: <restic_password>
4.4.1.5.6. OADP 1.2 Data Mover と CephFS ストレージを使用したデータのバックアップと復元
OpenShift API for Data Protection (OADP) 1.2 Data Mover を使用すると、CephFS のシャローコピー機能を有効にすることで、CephFS ストレージを使用してデータをバックアップおよびリストアできます。
前提条件
- ステートフルアプリケーションは、CephFS をプロビジョナーとして使用し、Persistent Volume Claim (PVC) を備えた別の namespace で実行されています。
-
StorageClassおよびVolumeSnapshotClassカスタムリソース (CR) は、CephFS および OADP 1.2 Data Mover 用に定義されています。 -
openshift-adpnamespace には秘密のcloud-credentialsがあります。
4.4.1.5.7. CephFS ストレージで使用する DPA の作成
OpenShift API for Data Protection (OADP) 1.2 Data Mover を使用して、CephFS ストレージでデータをバックアップおよびリストアするには、Data Protection Application (DPA) CR を作成する必要があります。
手順
次のコマンドを実行して、
VolumeSnapshotClassCR のdeletionPolicyフィールドがRetainに設定されていることを確認します。$ oc get volumesnapshotclass -A -o jsonpath='{range .items[*]}{"Name: "}{.metadata.name}{" "}{"Retention Policy: "}{.deletionPolicy}{"\n"}{end}'次のコマンドを実行して、
VolumeSnapshotClassCR のラベルがtrueに設定されていることを確認します。$ oc get volumesnapshotclass -A -o jsonpath='{range .items[*]}{"Name: "}{.metadata.name}{" "}{"labels: "}{.metadata.labels}{"\n"}{end}'次のコマンドを実行して、
StorageClassCR のstorageclass.kubernetes.io/is-default-classアノテーションがtrueに設定されていることを確認します。$ oc get storageClass -A -o jsonpath='{range .items[*]}{"Name: "}{.metadata.name}{" "}{"annotations: "}{.metadata.annotations}{"\n"}{end}'次の例のようなデータ保護アプリケーション (DPA) CR を作成します。
DPA CR の例
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: velero-sample namespace: openshift-adp spec: backupLocations: - velero: config: profile: default region: us-east-1 credential: key: cloud name: cloud-credentials default: true objectStorage: bucket: <my_bucket> prefix: velero provider: aws configuration: restic: enable: false 1 velero: defaultPlugins: - openshift - aws - csi - vsm features: dataMover: credentialName: <restic_secret_name> 2 enable: true 3 volumeOptionsForStorageClasses: ocs-storagecluster-cephfs: sourceVolumeOptions: accessMode: ReadOnlyMany cacheAccessMode: ReadWriteMany cacheStorageClassName: ocs-storagecluster-cephfs storageClassName: ocs-storagecluster-cephfs-shallow
4.4.1.5.8. OADP 1.2 Data Mover と CephFS ストレージを使用したデータのバックアップ
OpenShift API for Data Protection (OADP) 1.2 Data Mover を使用すると、CephFS ストレージのシャローコピー機能を有効にすることで、CephFS ストレージを使用してデータをバックアップできます。
手順
次の例のように、
BackupCR を作成します。BackupCR の例apiVersion: velero.io/v1 kind: Backup metadata: name: <backup_name> namespace: <protected_ns> spec: includedNamespaces: - <app_ns> storageLocation: velero-sample-1
次の手順を実行して、
VolumeSnapshotBackupCR の進行状況を監視します。すべての
VolumeSnapshotBackupCR の進行状況を確認するには、次のコマンドを実行します。$ oc get vsb -n <app_ns>
特定の
VolumeSnapshotBackupCR の進行状況を確認するには、次のコマンドを実行します。$ oc get vsb <vsb_name> -n <app_ns> -ojsonpath="{.status.phase}`
-
VolumeSnapshotBackupCR のステータスがCompletedになるまで、数分間待ちます。 -
Restic
Secretで指定されたスナップショットがオブジェクトストアに少なくとも 1 つあることを確認します。/<OADP-namespace>という接頭辞を持つ、対象のBackupStorageLocationストレージプロバイダーでこのスナップショットを確認できます。
4.4.1.5.9. OADP 1.2 Data Mover と CephFS ストレージを使用したデータのリストア
CephFS ストレージのシャローコピー機能がバックアップ手順で有効になっている場合、OpenShift API for Data Protection (OADP) 1.2 Data Mover を使用して、CephFS ストレージを使用してデータをリストアできます。シャローコピー機能は復元手順では使用されません。
手順
次のコマンドを実行して、アプリケーションの namespace を削除します。
$ oc delete vsb -n <app_namespace> --all
次のコマンドを実行して、バックアップ中に作成された
VolumeSnapshotContentCR を削除します。$ oc delete volumesnapshotcontent --all
次の例のように、
RestoreCR を作成します。RestoreCR の例apiVersion: velero.io/v1 kind: Restore metadata: name: <restore_name> namespace: <protected_ns> spec: backupName: <previous_backup_name>
次の手順を実行して、
VolumeSnapshotRestoreCR の進行状況を監視します。すべての
VolumeSnapshotRestoreCR の進行状況を確認するには、次のコマンドを実行します。$ oc get vsr -n <app_ns>
特定の
VolumeSnapshotRestoreCR の進行状況を確認するには、次のコマンドを実行します。$ oc get vsr <vsr_name> -n <app_ns> -ojsonpath="{.status.phase}
次のコマンドを実行して、アプリケーションデータが復元されたことを確認します。
$ oc get route <route_name> -n <app_ns> -ojsonpath="{.spec.host}"
4.4.1.5.10. OADP 1.2 Data Mover と分割ボリューム (CephFS および Ceph RBD) を使用したデータのバックアップとリストア
OpenShift API for Data Protection (OADP) 1.2 Data Mover を使用すると、ボリュームを分割した 環境、つまり CephFS と CephRBD の両方を使用する環境でデータをバックアップおよびリストアできます。
前提条件
- ステートフルアプリケーションは、CephFS をプロビジョナーとして使用し、Persistent Volume Claim (PVC) を備えた別の namespace で実行されています。
-
StorageClassおよびVolumeSnapshotClassカスタムリソース (CR) は、CephFS および OADP 1.2 Data Mover 用に定義されています。 -
openshift-adpnamespace には秘密のcloud-credentialsがあります。
4.4.1.5.11. 分割ボリュームで使用する DPA の作成
OpenShift API for Data Protection (OADP) 1.2 Data Mover を使用して、分割ボリュームでデータをバックアップおよびリストアするには、Data Protection Application (DPA) CR を作成する必要があります。
手順
次の例のように、Data Protection Application (DPA) CR を作成します。
分割ボリューム環境の DPA CR の例
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: velero-sample namespace: openshift-adp spec: backupLocations: - velero: config: profile: default region: us-east-1 credential: key: cloud name: cloud-credentials default: true objectStorage: bucket: <my-bucket> prefix: velero provider: aws configuration: restic: enable: false velero: defaultPlugins: - openshift - aws - csi - vsm features: dataMover: credentialName: <restic_secret_name> 1 enable: true volumeOptionsForStorageClasses: 2 ocs-storagecluster-cephfs: sourceVolumeOptions: accessMode: ReadOnlyMany cacheAccessMode: ReadWriteMany cacheStorageClassName: ocs-storagecluster-cephfs storageClassName: ocs-storagecluster-cephfs-shallow ocs-storagecluster-ceph-rbd: sourceVolumeOptions: storageClassName: ocs-storagecluster-ceph-rbd cacheStorageClassName: ocs-storagecluster-ceph-rbd destinationVolumeOptions: storageClassName: ocs-storagecluster-ceph-rbd cacheStorageClassName: ocs-storagecluster-ceph-rbd
4.4.1.5.12. OADP 1.2 Data Mover と分割ボリュームを使用したデータのバックアップ
OpenShift API for Data Protection (OADP) 1.2 Data Mover を使用して、分割ボリュームのある環境でデータをバックアップできます。
手順
次の例のように、
BackupCR を作成します。BackupCR の例apiVersion: velero.io/v1 kind: Backup metadata: name: <backup_name> namespace: <protected_ns> spec: includedNamespaces: - <app_ns> storageLocation: velero-sample-1
次の手順を実行して、
VolumeSnapshotBackupCR の進行状況を監視します。すべての
VolumeSnapshotBackupCR の進行状況を確認するには、次のコマンドを実行します。$ oc get vsb -n <app_ns>
特定の
VolumeSnapshotBackupCR の進行状況を確認するには、次のコマンドを実行します。$ oc get vsb <vsb_name> -n <app_ns> -ojsonpath="{.status.phase}`
-
VolumeSnapshotBackupCR のステータスがCompletedになるまで、数分間待ちます。 -
Restic
Secretで指定されたスナップショットがオブジェクトストアに少なくとも 1 つあることを確認します。/<OADP-namespace>という接頭辞を持つ、対象のBackupStorageLocationストレージプロバイダーでこのスナップショットを確認できます。
4.4.1.5.13. OADP 1.2 Data Mover と分割ボリュームを使用したデータのリストア
CephFS ストレージのシャローコピー機能がバックアップ手順で有効になっている場合、OpenShift API for Data Protection (OADP) 1.2 Data Mover を使用して、分割ボリュームのある環境でデータをリストアできます。シャローコピー機能は復元手順では使用されません。
手順
次のコマンドを実行して、アプリケーションの namespace を削除します。
$ oc delete vsb -n <app_namespace> --all
次のコマンドを実行して、バックアップ中に作成された
VolumeSnapshotContentCR を削除します。$ oc delete volumesnapshotcontent --all
次の例のように、
RestoreCR を作成します。RestoreCR の例apiVersion: velero.io/v1 kind: Restore metadata: name: <restore_name> namespace: <protected_ns> spec: backupName: <previous_backup_name>
次の手順を実行して、
VolumeSnapshotRestoreCR の進行状況を監視します。すべての
VolumeSnapshotRestoreCR の進行状況を確認するには、次のコマンドを実行します。$ oc get vsr -n <app_ns>
特定の
VolumeSnapshotRestoreCR の進行状況を確認するには、次のコマンドを実行します。$ oc get vsr <vsr_name> -n <app_ns> -ojsonpath="{.status.phase}
次のコマンドを実行して、アプリケーションデータが復元されたことを確認します。
$ oc get route <route_name> -n <app_ns> -ojsonpath="{.spec.host}"
4.4.1.6. OADP 1.1 Data Mover を使用したバックアップ後のクリーンアップ
OADP 1.1 Data Mover の場合、バックアップを実行した後にデータクリーンアップを実行する必要があります。
クリーンアップには、次のリソースの削除が含まれます。
- バケット内のスナップショット
- クラスターリソース
- スケジュールに従って実行されるか、繰り返し実行されるバックアップ手順の後のボリュームスナップショットバックアップ (VSB)
4.4.1.6.1. バケット内のスナップショットの削除
OADP 1.1 Data Mover は、バックアップ後に 1 つ以上のスナップショットをバケットに残す場合があります。すべてのスナップショットを削除することも、個々のスナップショットを削除することもできます。
手順
-
バケット内のすべてのスナップショットを削除するには、データ保護アプリケーション (DPA) の
.spec.backupLocation.objectStorage.bucketリソースで指定されている/<protected_namespace>フォルダーを削除します。 個々のスナップショットを削除するには、以下のようになりました。
-
DPA
.spec.backupLocation.objectStorage.bucketリソースで指定されている/<protected_namespace>フォルダーを参照します。 -
/<volumeSnapshotContent name>-pvcという接頭辞が付いた適切なフォルダーを削除します。ここで、<VolumeSnapshotContent_name>は、Data Mover によって PVC ごとに作成されたVolumeSnapshotContentです。
-
DPA
4.4.1.6.2. クラスターリソースの削除
OADP 1.1 Data Mover は、コンテナーストレージインターフェイス (CSI) ボリュームのスナップショットをリモートオブジェクトストアに正常にバックアップするかどうかに関係なく、クラスターリソースを残す場合があります。
4.4.1.6.2.1. Data Mover を使用したバックアップとリストアが成功した後のクラスターリソースの削除
Data Mover を使用したバックアップとリストアが成功した後、アプリケーションの namespace に残っている VolumeSnapshotBackup または VolumeSnapshotRestore CR を削除できます。
手順
Data Mover を使用したバックアップ後に、アプリケーションのnamespace (バックアップおよびリストアするアプリケーション PVC を含む namespace) に残っているクラスターリソースを削除します。
$ oc delete vsb -n <app_namespace> --all
Data Mover を使用するリストア後に残るクラスターリソースを削除します。
$ oc delete vsr -n <app_namespace> --all
必要に応じて、Data Mover を使用するバックアップおよびリストア後に残っている
VolumeSnapshotContentリソースを削除します。$ oc delete volumesnapshotcontent --all
4.4.1.6.2.2. Data Mover を使用したバックアップとリストアが部分的に成功または失敗した後のクラスターリソースの削除
Data Mover を使用したバックアップおよびリストア操作が失敗するか、部分的にしか成功しない場合は、アプリケーションの namespace に存在する VolumeSnapshotBackup (VSB) または VolumeSnapshotRestore カスタムリソース定義 (CRD) をクリーンアップし、このコントローラーによって作成された余分なリソースをクリーンアップする必要があります。
手順
次のコマンドを入力して、Data Mover を使用したバックアップ操作後に残ったクラスターリソースをクリーンアップします。
アプリケーション namespace 上の VSB CRD を削除します。この namespace には、バックアップおよび復元するアプリケーション PVC が含まれています。
$ oc delete vsb -n <app_namespace> --all
VolumeSnapshotCR を削除します。$ oc delete volumesnapshot -A --all
VolumeSnapshotContentCR を削除します。$ oc delete volumesnapshotcontent --all
保護された namespace (Operator がインストールされている namespace) 上の PVC をすべて削除します。
$ oc delete pvc -n <protected_namespace> --all
namespace 上の
ReplicationSourceリソースをすべて削除します。$ oc delete replicationsource -n <protected_namespace> --all
次のコマンドを入力して、Data Mover を使用したリストア操作後に残ったクラスターリソースをクリーンアップします。
VSR CRD を削除します。
$ oc delete vsr -n <app-ns> --all
VolumeSnapshotCR を削除します。$ oc delete volumesnapshot -A --all
VolumeSnapshotContentCR を削除します。$ oc delete volumesnapshotcontent --all
namespace 上の
ReplicationDestinationリソースをすべて削除します。$ oc delete replicationdestination -n <protected_namespace> --all
4.4.1.7. バックアップフックの作成
Backup カスタムリソース (CR) を編集して、Pod 内のコンテナーでコマンドを実行するためのバックアップフックを作成します。
プレ フックは、Pod のバックアップが作成される前に実行します。ポスト フックはバックアップ後に実行します。
手順
次の例のように、
BackupCR のspec.hooksブロックにフックを追加します。apiVersion: velero.io/v1 kind: Backup metadata: name: <backup> namespace: openshift-adp spec: hooks: resources: - name: <hook_name> includedNamespaces: - <namespace> 1 excludedNamespaces: 2 - <namespace> includedResources: [] - pods 3 excludedResources: [] 4 labelSelector: 5 matchLabels: app: velero component: server pre: 6 - exec: container: <container> 7 command: - /bin/uname 8 - -a onError: Fail 9 timeout: 30s 10 post: 11 ...- 1
- オプション: フックが適用される namespace を指定できます。この値が指定されていない場合、フックはすべてのネームスペースに適用されます。
- 2
- オプション: フックが適用されない namespace を指定できます。
- 3
- 現在、Pod は、フックを適用できる唯一のサポート対象リソースです。
- 4
- オプション: フックが適用されないリソースを指定できます。
- 5
- オプション: このフックは、ラベルに一致するオブジェクトにのみ適用されます。この値が指定されていない場合、フックはすべてのネームスペースに適用されます。
- 6
- バックアップの前に実行するフックの配列。
- 7
- オプション: コンテナーが指定されていない場合、コマンドは Pod の最初のコンテナーで実行されます。
- 8
- これは、追加される init コンテナーのエントリーポイントです。
- 9
- エラー処理に許可される値は、
FailとContinueです。デフォルトはFailです。 - 10
- オプション: コマンドの実行を待機する時間。デフォルトは
30sです。 - 11
- このブロックでは、バックアップ後に実行するフックの配列を、バックアップ前のフックと同じパラメーターで定義します。
4.4.1.8. バックアップのスケジュール
Backup CR の代わりに Schedule カスタムリソース (CR) を作成して、バックアップをスケジュールします。
バックアップスケジュールでは、別のバックアップが作成される前にバックアップを数量するための時間を十分確保してください。
たとえば、namespace のバックアップに通常 10 分かかる場合は、15 分ごとよりも頻繁にバックアップをスケジュールしないでください。
前提条件
- OpenShift API for Data Protection (OADP) Operator をインストールする必要があります。
-
DataProtectionApplicationCR はReady状態である必要があります。
手順
backupStorageLocationsCR を取得します。$ oc get backupStorageLocations -n openshift-adp
出力例
NAMESPACE NAME PHASE LAST VALIDATED AGE DEFAULT openshift-adp velero-sample-1 Available 11s 31m
次の例のように、
ScheduleCR を作成します。$ cat << EOF | oc apply -f - apiVersion: velero.io/v1 kind: Schedule metadata: name: <schedule> namespace: openshift-adp spec: schedule: 0 7 * * * 1 template: hooks: {} includedNamespaces: - <namespace> 2 storageLocation: <velero-sample-1> 3 defaultVolumesToRestic: true 4 ttl: 720h0m0s EOF
スケジュールされたバックアップの実行後に、
ScheduleCR のステータスがCompletedとなっていることを確認します。$ oc get schedule -n openshift-adp <schedule> -o jsonpath='{.status.phase}'
4.4.1.9. バックアップの削除
Backup カスタムリソース (CR) を削除することで、バックアップファイルを削除できます。
Backup CR および関連するオブジェクトストレージデータを削除した後、削除したデータを復元することはできません。
前提条件
-
BackupCR を作成した。 -
BackupCR の名前とそれを含む namespace がわかっている。 - Velero CLI ツールをダウンロードした。
- クラスター内の Velero バイナリーにアクセスできる。
手順
次のいずれかのアクションを選択して、
BackupCR を削除します。BackupCR を削除し、関連するオブジェクトストレージデータを保持する場合は、次のコマンドを実行します。$ oc delete backup <backup_CR_name> -n <velero_namespace>
BackupCR を削除し、関連するオブジェクトストレージデータを削除する場合は、次のコマンドを実行します。$ velero backup delete <backup_CR_name> -n <velero_namespace>
ここでは、以下のようになります。
- <backup_CR_name>
-
Backupカスタムリソースの名前を指定します。 - <velero_namespace>
-
Backupカスタムリソースを含む namespace を指定します。
4.4.2. アプリケーションの復元
アプリケーションのバックアップを復元するには、Restore カスタムリソース (CR) を作成します。復元 CR の作成 を参照してください。
Restore (CR) を編集することでアプリケーションを復元する際に、Pod 内のコンテナーでコマンドを実行するための復元フックを作成できます。復元フックの作成 を参照してください。
4.4.2.1. 復元 CR の作成
Restore CR を作成して、Backup カスタムリソース (CR) を復元します。
前提条件
- OpenShift API for Data Protection (OADP) Operator をインストールする必要があります。
-
DataProtectionApplicationCR はReady状態である必要があります。 -
Velero
BackupCR が必要です。 - バックアップ時に永続ボリューム (PV) の容量が要求されたサイズと一致するよう、要求されたサイズを調整します。
手順
次の例のように、
RestoreCR を作成します。apiVersion: velero.io/v1 kind: Restore metadata: name: <restore> namespace: openshift-adp spec: backupName: <backup> 1 includedResources: [] 2 excludedResources: - nodes - events - events.events.k8s.io - backups.velero.io - restores.velero.io - resticrepositories.velero.io restorePVs: true 3
- 1
BackupCR の名前- 2
- オプション: 復元プロセスに含めるリソースの配列を指定します。リソースは、ショートカット (
Podsはpoなど) または完全修飾の場合があります。指定しない場合、すべてのリソースが含まれます。 - 3
- オプション:
RestorePVsパラメーターをfalseに設定すると、コンテナーストレージインターフェイス (CSI) スナップショットのVolumeSnapshotから、またはVolumeSnaphshotLocationが設定されている場合はネイティブスナップショットからのPersistentVolumesの復元をオフにすることができます。
次のコマンドを入力して、
RestoreCR のステータスがCompletedであることを確認します。$ oc get restore -n openshift-adp <restore> -o jsonpath='{.status.phase}'次のコマンドを入力して、バックアップリソースが復元されたことを確認します。
$ oc get all -n <namespace> 1- 1
- バックアップした namespace。
Restic を使用して
DeploymentConfigオブジェクトを復元する場合、または復元後のフックを使用する場合は、次のコマンドを入力してdc-restic-post-restore.shクリーンアップスクリプトを実行します。$ bash dc-restic-post-restore.sh <restore-name>
注記復元プロセスの過程で、OADP Velero プラグインは、
DeploymentConfigオブジェクトをスケールダウンし、Pod をスタンドアロン Pod として復元して、クラスターが復元されたDeploymentConfigPod を復元時にすぐに削除しないようにし、Restic および復元後のフックを完了できるようにします。復元された Pod でのアクション。クリーンアップスクリプトは、これらの切断された Pod を削除し、DeploymentConfigオブジェクトを適切な数のレプリカに戻します。例4.1
dc-restic-post-restore.shクリーンアップスクリプト#!/bin/bash set -e # if sha256sum exists, use it to check the integrity of the file if command -v sha256sum >/dev/null 2>&1; then CHECKSUM_CMD="sha256sum" else CHECKSUM_CMD="shasum -a 256" fi label_name () { if [ "${#1}" -le "63" ]; then echo $1 return fi sha=$(echo -n $1|$CHECKSUM_CMD) echo "${1:0:57}${sha:0:6}" } OADP_NAMESPACE=${OADP_NAMESPACE:=openshift-adp} if [[ $# -ne 1 ]]; then echo "usage: ${BASH_SOURCE} restore-name" exit 1 fi echo using OADP Namespace $OADP_NAMESPACE echo restore: $1 label=$(label_name $1) echo label: $label echo Deleting disconnected restore pods oc delete pods -l oadp.openshift.io/disconnected-from-dc=$label for dc in $(oc get dc --all-namespaces -l oadp.openshift.io/replicas-modified=$label -o jsonpath='{range .items[*]}{.metadata.namespace}{","}{.metadata.name}{","}{.metadata.annotations.oadp\.openshift\.io/original-replicas}{","}{.metadata.annotations.oadp\.openshift\.io/original-paused}{"\n"}') do IFS=',' read -ra dc_arr <<< "$dc" if [ ${#dc_arr[0]} -gt 0 ]; then echo Found deployment ${dc_arr[0]}/${dc_arr[1]}, setting replicas: ${dc_arr[2]}, paused: ${dc_arr[3]} cat <<EOF | oc patch dc -n ${dc_arr[0]} ${dc_arr[1]} --patch-file /dev/stdin spec: replicas: ${dc_arr[2]} paused: ${dc_arr[3]} EOF fi done
4.4.2.2. 復元フックの作成
Restore カスタムリソース (CR) を編集して、アプリケーションの復元中に Pod 内のコンテナーでコマンドを実行する復元フックを作成します。
2 種類の復元フックを作成できます。
initフックは、init コンテナーを Pod に追加して、アプリケーションコンテナーが起動する前にセットアップタスクを実行します。Restic バックアップを復元する場合は、復元フック init コンテナーの前に
restic-waitinit コンテナーが追加されます。-
execフックは、復元された Pod のコンテナーでコマンドまたはスクリプトを実行します。
手順
次の例のように、
Restore CRのspec.hooksブロックにフックを追加します。apiVersion: velero.io/v1 kind: Restore metadata: name: <restore> namespace: openshift-adp spec: hooks: resources: - name: <hook_name> includedNamespaces: - <namespace> 1 excludedNamespaces: - <namespace> includedResources: - pods 2 excludedResources: [] labelSelector: 3 matchLabels: app: velero component: server postHooks: - init: initContainers: - name: restore-hook-init image: alpine:latest volumeMounts: - mountPath: /restores/pvc1-vm name: pvc1-vm command: - /bin/ash - -c timeout: 4 - exec: container: <container> 5 command: - /bin/bash 6 - -c - "psql < /backup/backup.sql" waitTimeout: 5m 7 execTimeout: 1m 8 onError: Continue 9- 1
- オプション: フックが適用される namespace の配列。この値が指定されていない場合、フックはすべてのネームスペースに適用されます。
- 2
- 現在、Pod は、フックを適用できる唯一のサポート対象リソースです。
- 3
- オプション: このフックは、ラベルセレクターに一致するオブジェクトにのみ適用されます。
- 4
- オプション: Timeout は、
initContainersが完了するまで Velero が待機する最大時間を指定します。 - 5
- オプション: コンテナーが指定されていない場合、コマンドは Pod の最初のコンテナーで実行されます。
- 6
- これは、追加される init コンテナーのエントリーポイントです。
- 7
- オプション: コンテナーの準備が整うまでの待機時間。これは、コンテナーが起動して同じコンテナー内の先行するフックが完了するのに十分な長さである必要があります。設定されていない場合、復元プロセスの待機時間は無期限になります。
- 8
- オプション: コマンドの実行を待機する時間。デフォルトは
30sです。 - 9
- エラー処理に許可される値は、
FailおよびContinueです。-
Continue: コマンドの失敗のみがログに記録されます。 -
Fail: Pod 内のコンテナーで復元フックが実行されなくなりました。RestoreCR のステータスはPartiallyFailedになります。
-
4.5. トラブルシューティング
OpenShift CLI ツール または Velero CLI ツール を使用して、Velero カスタムリソース (CR) をデバッグできます。Velero CLI ツールは、より詳細なログおよび情報を提供します。
インストールの問題、CR のバックアップと復元の問題、および Restic の問題 を確認できます。
ログと CR 情報は、must-gather ツール を使用して収集できます。
Velero CLI ツールは、次の方法で入手できます。
- Velero CLI ツールをダウンロードする
- クラスター内の Velero デプロイメントで Velero バイナリーにアクセスする
4.5.1. Velero CLI ツールをダウンロードする
Velero documentation page の手順に従って、Velero CLI ツールをダウンロードしてインストールできます。
このページには、以下に関する手順が含まれています。
- Homebrew を使用した macOS
- GitHub
- Chocolatey を使用した Windows
前提条件
- DNS とコンテナーネットワークが有効になっている、v1.16 以降の Kubernetes クラスターにアクセスできる。
-
kubectlをローカルにインストールしている。
手順
- ブラウザーを開き、Velero Web サイトの「CLI のインストール」 に移動します。
- macOS、GitHub、または Windows の適切な手順に従います。
次の表に従って、OADP および OpenShift Container Platform のバージョンに適した Velero バージョンをダウンロードします。
4.5.2. クラスター内の Velero デプロイメントで Velero バイナリーにアクセスする
shell コマンドを使用して、クラスター内の Velero デプロイメントの Velero バイナリーにアクセスできます。
前提条件
-
DataProtectionApplicationカスタムリソースのステータスがReconcile completeである。
手順
次のコマンドを入力して、必要なエイリアスを設定します。
$ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
4.5.3. OpenShift CLI ツールを使用した Velero リソースのデバッグ
OpenShift CLI ツールを使用して Velero カスタムリソース (CR) と Velero Pod ログを確認することで、失敗したバックアップまたは復元をデバッグできます。
Velero CR
oc describe コマンドを使用して、Backup または Restore CR に関連する警告とエラーの要約を取得します。
$ oc describe <velero_cr> <cr_name>
Velero Pod ログ
oc logs コマンドを使用して、Velero Pod ログを取得します。
$ oc logs pod/<velero>
Velero Pod のデバッグログ
次の例に示すとおり、DataProtectionApplication リソースで Velero ログレベルを指定できます。
このオプションは、OADP 1.0.3 以降で使用できます。
apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
name: velero-sample
spec:
configuration:
velero:
logLevel: warning
次の logLevel 値を使用できます。
-
trace -
debug -
info -
warning -
error -
致命的 -
panic
ほとんどのログには debug を使用することをお勧めします。
4.5.4. Velero CLI ツールを使用した Velero リソースのデバッグ
Velero CLI ツールを使用して、Backup および Restore カスタムリソース (CR) をデバッグし、ログを取得できます。
Velero CLI ツールは、OpenShift CLI ツールよりも詳細な情報を提供します。
構文
oc exec コマンドを使用して、Velero CLI コマンドを実行します。
$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \ <backup_restore_cr> <command> <cr_name>
例
$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \ backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql
ヘルプオプション
velero --help オプションを使用して、すべての Velero CLI コマンドを一覧表示します。
$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \ --help
describe コマンド
velero describe コマンドを使用して、Backup または Restore CR に関連する警告とエラーの要約を取得します。
$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \ <backup_restore_cr> describe <cr_name>
例
$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \ backup describe 0e44ae00-5dc3-11eb-9ca8-df7e5254778b-2d8ql
logs コマンド
velero logs コマンドを使用して、Backup または Restore CR のログを取得します。
$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \ <backup_restore_cr> logs <cr_name>
例
$ oc -n openshift-adp exec deployment/velero -c velero -- ./velero \ restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf
4.5.5. メモリーまたは CPU の不足により Pod がクラッシュまたは再起動する
メモリーまたは CPU の不足により Velero または Restic Pod がクラッシュした場合、これらのリソースのいずれかに対して特定のリソースリクエストを設定できます。
関連情報
4.5.5.1. Velero Pod のリソースリクエストの設定
oadp_v1alpha1_dpa.yaml ファイルの configuration.velero.podConfig.resourceAllocations 仕様フィールドを使用して、Velero Pod に対する特定のリソース要求を設定できます。
手順
YAML ファイルで
CPUおよびmemoryリソースのリクエストを設定します。Velero ファイルの例
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication ... configuration: velero: podConfig: resourceAllocations: 1 requests: cpu: 200m memory: 256Mi- 1
- リストされている
resourceAllocationsは、平均使用量です。
4.5.5.2. Restic Pod のリソースリクエストの設定
configuration.restic.podConfig.resourceAllocations 仕様フィールドを使用して、Restic Pod の特定のリソース要求を設定できます。
手順
YAML ファイルで
CPUおよびmemoryリソースのリクエストを設定します。Restic ファイルの例
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication ... configuration: restic: podConfig: resourceAllocations: 1 requests: cpu: 1000m memory: 16Gi- 1
- リストされている
resourceAllocationsは、平均使用量です。
リソース要求フィールドの値は、Kubernetes リソース要件と同じ形式に従う必要があります。また、configuration.velero.podConfig.resourceAllocations または configuration.restic.podConfig.resourceAllocations を指定しない場合、Velero Pod または Restic Pod のデフォルトの resources 仕様は次のようになります。
requests: cpu: 500m memory: 128Mi
4.5.6. Velero と受付 Webhook に関する問題
Velero では、復元中に受付 Webhook の問題を解決する機能が制限されています。受付 Webhook を使用するワークロードがある場合は、追加の Velero プラグインを使用するか、ワークロードの復元方法を変更する必要がある場合があります。
通常、受付 Webhook を使用するワークロードでは、最初に特定の種類のリソースを作成する必要があります。通常、受付 Webhook は子リソースをブロックするため、これは特にワークロードに子リソースがある場合に当てはまります。
たとえば、service.serving.knative.dev などの最上位オブジェクトを作成または復元すると、通常、子リソースが自動的に作成されます。最初にこれを行う場合、Velero を使用してこれらのリソースを作成および復元する必要はありません。これにより、Velero が使用する可能性のある受付 Webhook によって子リソースがブロックされるという問題が回避されます。
4.5.6.1. 受付 Webhook を使用する Velero バックアップの回避策の復元
このセクションでは、受付 Webhook を使用するいくつかのタイプの Velero バックアップのリソースを復元するために必要な追加の手順について説明します。
4.5.6.1.1. Knative リソースの復元
Velero を使用して受付 Webhook を使用する Knative リソースをバックアップする際に問題が発生する場合があります。
受付 Webhook を使用する Knative リソースをバックアップおよび復元する場合は、常に最上位の Service リソースを最初に復元することで、このような問題を回避できます。
手順
最上位の
service.serving.knavtive.dev Serviceリソースを復元します。$ velero restore <restore_name> \ --from-backup=<backup_name> --include-resources \ service.serving.knavtive.dev
4.5.6.1.2. IBM AppConnect リソースの復元
Velero を使用して受付 Webhook を持つ IBM AppConnect リソースを復元するときに問題が発生した場合は、この手順のチェックを実行できます。
手順
クラスター内の
kind: MutatingWebhookConfigurationの受付プラグインの変更があるかチェックします。$ oc get mutatingwebhookconfigurations
-
各
kind: MutatingWebhookConfigurationの YAML ファイルを調べて、問題が発生しているオブジェクトの作成をブロックするルールがないことを確認します。詳細は、Kuberbetes の公式ドキュメント を参照してください。 -
バックアップ時に使用される
type: Configuration.appconnect.ibm.com/v1beta1のspec.versionが、インストールされている Operator のサポート対象であることを確認してください。
4.5.7. インストールの問題
Data Protection Application をインストールするときに、無効なディレクトリーまたは誤った認証情報を使用することによって問題が発生する可能性があります。
4.5.7.1. バックアップストレージに無効なディレクトリーが含まれています
Velero Pod ログにエラーメッセージ Backup storage contains invalid top-level directories が表示されます。
原因
オブジェクトストレージには、Velero ディレクトリーではないトップレベルのディレクトリーが含まれています。
解決方法
オブジェクトストレージが Velero 専用でない場合は、DataProtectionApplication マニフェストで spec.backupLocations.velero.objectStorage.prefix パラメーターを設定して、バケットの接頭辞を指定する必要があります。
4.5.7.2. 不正な AWS 認証情報
oadp-aws-registry Pod ログにエラーメッセージ InvalidAccessKeyId: The AWS Access Key Id you provided does not exist in our records. が表示されます。
Velero Pod ログには、エラーメッセージ NoCredentialProviders: no valid providers in chain が表示されます。
原因
Secret オブジェクトの作成に使用された credentials-velero ファイルの形式が正しくありません。
解決方法
次の例のように、credentials-velero ファイルが正しくフォーマットされていることを確認します。
サンプル credentials-velero ファイル
[default] 1 aws_access_key_id=AKIAIOSFODNN7EXAMPLE 2 aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
4.5.8. OADP タイムアウト
タイムアウトを延長すると、複雑なプロセスやリソースを大量に消費するプロセスが途中で終了することなく正常に完了できます。この設定により、エラー、再試行、または失敗の可能性を減らすことができます。
過度に長いタイムアウトを設定しないように、論理的な方法でタイムアウト延長のバランスをとってください。過度に長いと、プロセス内の根本的な問題が隠れる可能性があります。プロセスのニーズとシステム全体のパフォーマンスを満たす適切なタイムアウト値を慎重に検討して、監視してください。
次に、さまざまな OADP タイムアウトと、これらのパラメーターをいつどのように実装するかの手順を示します。
4.5.8.1. Restic タイムアウト
timeout は Restic タイムアウトを定義します。デフォルト値は 1h です。
以下のシナリオでは Restic timeout を使用します。
- PV データの使用量の合計が 500GB を超える Restic バックアップの場合。
バックアップが次のエラーでタイムアウトになる場合:
level=error msg="Error backing up item" backup=velero/monitoring error="timed out waiting for all PodVolumeBackups to complete"
手順
次の例のように、
DataProtectionApplicationCR マニフェストのspec.configuration.restic.timeoutブロックの値を編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_name> spec: configuration: restic: timeout: 1h # ...
4.5.8.2. Velereo リソースのタイムアウト
resourceTimeout は Velero カスタムリソース定義 (CRD) の可用性、volumeSnapshot の削除、リポジトリーの可用性など、タイムアウトが発生する前に複数の Velero リソースを待機する時間を定義します。デフォルトは 10m です。
次のシナリオでは resourceTimeout を使用します。
合計 PV データ使用量が 1TB を超えるバックアップの場合。このパラメーターは、バックアップを完了としてマークする前に、Velero が Container Storage Interface (CSI) スナップショットをクリーンアップまたは削除しようとするときのタイムアウト値として使用されます。
- このクリーンアップのサブタスクは VSC にパッチを適用しようとします。このタイムアウトはそのタスクに使用できます。
- Restic または Kopia のファイルシステムベースのバックアップのバックアップリポジトリーを作成または準備できるようにするため。
- カスタムリソース (CR) またはバックアップからリソースを復元する前に、クラスター内で Velero CRD が利用可能かどうかを確認します。
手順
次の例のように、
DataProtectionApplicationCR マニフェストのspec.configuration.velero.resourceTimeoutブロックの値を編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_name> spec: configuration: velero: resourceTimeout: 10m # ...
4.5.8.3. Data Mover のタイムアウト
timeout は、VolumeSnapshotBackup および VolumeSnapshotRestore を完了するためにユーザーが指定したタイムアウトです。デフォルト値は 10m です。
次のシナリオでは、Data Mover timeout を使用します。
-
VolumeSnapshotBackups(VSB) およびVolumeSnapshotRestores(VSR) を作成する場合は、10 分後にタイムアウトします。 -
合計 PV データ使用量が 500GB を超える大規模環境向け。
1hのタイムアウトを設定します。 -
VolumeSnapshotMover(VSM) プラグインを使用します。 - OADP 1.1.x のみ。
手順
次の例のように、
DataProtectionApplicationCR マニフェストのspec.features.dataMover.timeoutブロックの値を編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_name> spec: features: dataMover: timeout: 10m # ...
4.5.8.4. CSI スナップショットのタイムアウト
CSISnapshotTimeout は、タイムアウトとしてエラーを返す前に、CSI VolumeSnapshot ステータスが ReadyToUse になるまで待機する作成時の時間を指定します。デフォルト値は 10m です。
以下のシナリオでは、CSISnapshotTimeout を使用します。
- CSI プラグイン。
- スナップショットの作成に 10 分以上かかる可能性がある非常に大規模なストレージボリュームの場合。ログにタイムアウトが見つかった場合は、このタイムアウトを調整します。
通常、CSISnapshotTimeout のデフォルト値は、デフォルト設定で大規模なストレージボリュームに対応できるため、調整する必要はありません。
手順
次の例のように、
BackupCR マニフェストのspec.csiSnapshotTimeoutブロックの値を編集します。apiVersion: velero.io/v1 kind: Backup metadata: name: <backup_name> spec: csiSnapshotTimeout: 10m # ...
4.5.8.5. Velereo のデフォルトのアイテム操作のタイムアウト
defaultItemOperationTimeout では、非同期の BackupItemActions および RestoreItemActions がタイムアウトになる前に完了するのを待機する時間を定義します。デフォルト値は 1h です。
以下のシナリオでは、defaultItemOperationTimeout を使用します。
- Data Mover 1.2.x のみ。
- 特定のバックアップまたは復元が非同期アクションの完了を待機する時間を指定します。OADP 機能のコンテキストでは、この値は、Container Storage Interface (CSI) Data Mover 機能に関連する非同期アクションに使用されます。
-
defaultItemOperationTimeoutが、defaultItemOperationTimeoutを使用して Data Protection Application (DPA) に定義されている場合、バックアップおよび復元操作の両方に適用されます。itemOperationTimeoutでは、以下の Item operation timeout - restore セクションおよび Item operation timeout - backup セクションで説明されているように、バックアップのみを定義するか、これらの CR の復元のみを定義できます。
手順
次の例のように、
DataProtectionApplicationCR マニフェストのspec.configuration.velero.defaultItemOperationTimeoutブロックの値を編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_name> spec: configuration: velero: defaultItemOperationTimeout: 1h # ...
4.5.8.6. アイテム操作のタイムアウト - 復元
ItemOperationTimeout は RestoreItemAction 操作の待機に使用される時間を指定します。デフォルト値は 1h です。
以下のシナリオでは、復元 ItemOperationTimeout を使用します。
- Data Mover 1.2.x のみ。
-
Data Mover の場合は、
BackupStorageLocationにアップロードおよびダウンロードします。タイムアウトに達しても復元アクションが完了しない場合、失敗としてマークされます。ストレージボリュームのサイズが大きいため、タイムアウトの問題が原因で Data Mover の操作が失敗する場合は、このタイムアウト設定を増やす必要がある場合があります。
手順
次の例のように、
RestoreCR マニフェストのRestore.spec.itemOperationTimeoutブロックの値を編集します。apiVersion: velero.io/v1 kind: Restore metadata: name: <restore_name> spec: itemOperationTimeout: 1h # ...
4.5.8.7. アイテム操作のタイムアウト - バックアップ
ItemOperationTimeout は、非同期 BackupItemAction 操作の待機時間を指定します。デフォルト値は 1h です。
次のシナリオでは、バックアップ ItemOperationTimeout を使用します。
- Data Mover 1.2.x のみ。
-
Data Mover の場合は、
BackupStorageLocationにアップロードおよびダウンロードします。タイムアウトに達してもバックアップアクションが完了しない場合は、失敗としてマークされます。ストレージボリュームのサイズが大きいため、タイムアウトの問題が原因で Data Mover の操作が失敗する場合は、このタイムアウト設定を増やす必要がある場合があります。
手順
次の例のように、
BackuoCR マニフェストのBackup.spec.itemOperationTimeoutブロックの値を編集します。apiVersion: velero.io/v1 kind: Backup metadata: name: <backup_name> spec: itemOperationTimeout: 1h # ...
4.5.9. CR の問題のバックアップおよび復元
Backup および Restore カスタムリソース (CR) でこれらの一般的な問題が発生する可能性があります。
4.5.9.1. バックアップ CR はボリュームを取得できません
Backup CR は、エラーメッセージ InvalidVolume.NotFound: The volume ‘vol-xxxx' does not exist を表示します。
原因
永続ボリューム (PV) とスナップショットの場所は異なるリージョンにあります。
解決方法
-
DataProtectionApplicationマニフェストのspec.snapshotLocations.velero.config.regionキーの値を編集して、スナップショットの場所が PV と同じリージョンにあるようにします。 -
新しい
BackupCR を作成します。
4.5.9.2. バックアップ CR ステータスは進行中のままです
Backup CR のステータスは InProgress のフェーズのままであり、完了しません。
原因
バックアップが中断された場合は、再開することができません。
解決方法
BackupCR の詳細を取得します。$ oc -n {namespace} exec deployment/velero -c velero -- ./velero \ backup describe <backup>BackupCR を削除します。$ oc delete backup <backup> -n openshift-adp
進行中の
BackupCR はファイルをオブジェクトストレージにアップロードしていないため、バックアップの場所をクリーンアップする必要はありません。-
新しい
BackupCR を作成します。
4.5.9.3. バックアップ CR ステータスが PartlyFailed のままになる
Restic が使用されていない Backup CR のステータスは、PartiallyFailed フェーズのままで、完了しません。関連する PVC のスナップショットは作成されません。
原因
CSI スナップショットクラスに基づいてバックアップが作成されているが、ラベルがない場合、CSI スナップショットプラグインはスナップショットの作成に失敗します。その結果、Velero Pod は次のようなエラーをログに記録します。
+
time="2023-02-17T16:33:13Z" level=error msg="Error backing up item" backup=openshift-adp/user1-backup-check5 error="error executing custom action (groupResource=persistentvolumeclaims, namespace=busy1, name=pvc1-user1): rpc error: code = Unknown desc = failed to get volumesnapshotclass for storageclass ocs-storagecluster-ceph-rbd: failed to get volumesnapshotclass for provisioner openshift-storage.rbd.csi.ceph.com, ensure that the desired volumesnapshot class has the velero.io/csi-volumesnapshot-class label" logSource="/remote-source/velero/app/pkg/backup/backup.go:417" name=busybox-79799557b5-vprq
解決方法
BackupCR を削除します。$ oc delete backup <backup> -n openshift-adp
-
必要に応じて、
BackupStorageLocationに保存されているデータをクリーンアップして、領域を解放します。 ラベル
velero.io/csi-volumesnapshot-class=trueをVolumeSnapshotClassオブジェクトに適用します。$ oc label volumesnapshotclass/<snapclass_name> velero.io/csi-volumesnapshot-class=true
-
新しい
BackupCR を作成します。
4.5.10. Restic の問題
Restic を使用してアプリケーションのバックアップを作成すると、これらの問題が発生する可能性があります。
4.5.10.1. root_squash が有効になっている NFS データボリュームの Restic パーミッションエラー
Restic Pod ログには、エラーメッセージ controller=pod-volume-backup error="fork/exec/usr/bin/restic: permission denied" が表示されます。
原因
NFS データボリュームで root_squash が有効になっている場合、Restic は nfsnobody にマッピングされ、バックアップを作成する権限がありません。
解決方法
この問題を解決するには、Restic の補足グループを作成し、そのグループ ID を DataProtectionApplication マニフェストに追加します。
-
NFS データボリューム上に
Resticの補足グループを作成します。 -
NFS ディレクトリーに
setgidビットを設定して、グループの所有権が継承されるようにします。 次の例のように、
spec.configuration.restic.supplementalGroupsパラメーターおよびグループ ID をDataProtectionApplicationマニフェストに追加します。spec: configuration: restic: enable: true supplementalGroups: - <group_id> 1- 1
- 補助グループ ID を指定します。
-
ResticPod が再起動し、変更が適用されるまで待機します。
4.5.10.2. バケットが空になった後に、Restic Backup CR を再作成することはできない
namespace の Restic Backup CR を作成し、オブジェクトストレージバケットを空にしてから、同じ namespace の Backup CR を再作成すると、再作成された Backup CR は失敗します。
velero Pod ログにエラーメッセージstderr=Fatal: unable to open config file: Stat: The specified key does not exist.\nIs there a repository at the following location? が表示されます。
原因
オブジェクトストレージから Restic ディレクトリーが削除された場合、Velero は ResticRepository マニフェストから Restic リポジトリーを再作成または更新しません。詳細については、Velero issue 4421 を参照してください。
解決方法
次のコマンドを実行して、関連する Restic リポジトリーを namespace から削除します。
$ oc delete resticrepository openshift-adp <name_of_the_restic_repository>
次のエラーログでは、
mysql-persistentが問題のある Restic リポジトリーです。わかりやすくするために、リポジトリーの名前は斜体で表示されます。time="2021-12-29T18:29:14Z" level=info msg="1 errors encountered backup up item" backup=velero/backup65 logSource="pkg/backup/backup.go:431" name=mysql-7d99fc949-qbkds time="2021-12-29T18:29:14Z" level=error msg="Error backing up item" backup=velero/backup65 error="pod volume backup failed: error running restic backup, stderr=Fatal: unable to open config file: Stat: The specified key does not exist.\nIs there a repository at the following location?\ns3:http://minio-minio.apps.mayap-oadp- veleo-1234.qe.devcluster.openshift.com/mayapvelerooadp2/velero1/ restic/mysql-persistent\n: exit status 1" error.file="/remote-source/ src/github.com/vmware-tanzu/velero/pkg/restic/backupper.go:184" error.function="github.com/vmware-tanzu/velero/ pkg/restic.(*backupper).BackupPodVolumes" logSource="pkg/backup/backup.go:435" name=mysql-7d99fc949-qbkds
4.5.11. must-gather ツールの使用
must-gather ツールを使用して、OADP カスタムリソースのログ、メトリクス、および情報を収集できます。
must-gather データはすべてのカスタマーケースに割り当てられる必要があります。
前提条件
-
cluster-adminロールを持つユーザーとして OpenShift Container Platform クラスターにログインする必要があります。 -
OpenShift CLI (
oc) がインストールされている。
手順
-
must-gatherデータを保存するディレクトリーに移動します。 次のデータ収集オプションのいずれかに対して、
oc adm must-gatherコマンドを実行します。$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel8:v1.1
データは
must-gather/must-gather.tar.gzとして保存されます。このファイルを Red Hat カスタマーポータル で作成したサポートケースにアップロードすることができます。$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel8:v1.1 \ -- /usr/bin/gather_metrics_dump
この操作には長時間かかる場合があります。データは
must-gather/metrics/prom_data.tar.gzとして保存されます。
4.5.12. OADP モニタリング
OpenShift Container Platform は、ユーザーと管理者がクラスターを効果的に監視および管理できるだけでなく、クラスター上で実行されているユーザーアプリケーションやサービスのワークロードパフォーマンスを監視および分析できるようにする監視スタックを提供します (イベント発生時のアラートの受信など)。
関連情報
4.5.12.1. OADP モニタリングの設定
OADP Operator は、OpenShift モニタリングスタックによって提供される OpenShift ユーザーワークロードモニタリングを利用して、Velero サービスエンドポイントからメトリックを取得します。モニタリングスタックを使用すると、ユーザー定義のアラートルールを作成したり、OpenShift メトリッククエリーフロントエンドを使用してメトリックをクエリーしたりできます。
ユーザーワークロードモニタリングを有効にすると、Grafana などの Prometheus 互換のサードパーティー UI を設定して使用し、Velero メトリックを視覚化することができます。
メトリックをモニタリングするには、ユーザー定義プロジェクトのモニタリングを有効にし、openshift-adp namespace に存在するすでに有効にな OADP サービスエンドポイントからそれらのメトリックを取得する ServiceMonitor リソースを作成する必要があります。
前提条件
-
cluster-adminパーミッションを持つアカウントを使用して OpenShift Container Platform クラスターにアクセスできる。 - クラスター監視 config map が作成されました。
手順
openshift-monitoringnamespace でcluster-monitoring-configConfigMapオブジェクトを編集します。$ oc edit configmap cluster-monitoring-config -n openshift-monitoring
dataセクションのconfig.yamlフィールドで、enableUserWorkloadオプションを追加または有効にします。apiVersion: v1 data: config.yaml: | enableUserWorkload: true 1 kind: ConfigMap metadata: # ...- 1
- このオプションを追加するか、
trueに設定します
しばらく待って、
openshift-user-workload-monitoringnamespace で次のコンポーネントが稼働しているかどうかを確認して、ユーザーワークロードモニタリングのセットアップを検証します。$ oc get pods -n openshift-user-workload-monitoring
出力例
NAME READY STATUS RESTARTS AGE prometheus-operator-6844b4b99c-b57j9 2/2 Running 0 43s prometheus-user-workload-0 5/5 Running 0 32s prometheus-user-workload-1 5/5 Running 0 32s thanos-ruler-user-workload-0 3/3 Running 0 32s thanos-ruler-user-workload-1 3/3 Running 0 32s
openshift-user-workload-monitoringにuser-workload-monitoring-configConfigMap が存在することを確認します。存在する場合、この手順の残りの手順はスキップしてください。$ oc get configmap user-workload-monitoring-config -n openshift-user-workload-monitoring
出力例
Error from server (NotFound): configmaps "user-workload-monitoring-config" not found
ユーザーワークロードモニタリングの
user-workload-monitoring-configConfigMapオブジェクトを作成し、2_configure_user_workload_monitoring.yamlファイル名に保存します。出力例
apiVersion: v1 kind: ConfigMap metadata: name: user-workload-monitoring-config namespace: openshift-user-workload-monitoring data: config.yaml: |
2_configure_user_workload_monitoring.yamlファイルを適用します。$ oc apply -f 2_configure_user_workload_monitoring.yaml configmap/user-workload-monitoring-config created
4.5.12.2. OADP サービスモニターの作成
OADP は、DPA の設定時に作成される openshift-adp-velero-metrics-svc サービスを提供します。ユーザーのワークロード監視で使用されるサービスモニターは、定義されたサービスを指す必要があります。
次のコマンドを実行して、サービスの詳細を取得します。
手順
openshift-adp-velero-metrics-svcサービスが存在することを確認します。これには、ServiceMonitorオブジェクトのセレクターとして使用されるapp.kubernetes.io/name=veleroラベルが含まれている必要があります。$ oc get svc -n openshift-adp -l app.kubernetes.io/name=velero
出力例
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE openshift-adp-velero-metrics-svc ClusterIP 172.30.38.244 <none> 8085/TCP 1h
既存のサービスラベルと一致する
ServiceMonitorYAML ファイルを作成し、そのファイルを3_create_oadp_service_monitor.yamlとして保存します。サービスモニターはopenshift-adp-velero-metrics-svcサービスが存在するopenshift-adpnamespace に作成されます。ServiceMonitorオブジェクトの例apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: labels: app: oadp-service-monitor name: oadp-service-monitor namespace: openshift-adp spec: endpoints: - interval: 30s path: /metrics targetPort: 8085 scheme: http selector: matchLabels: app.kubernetes.io/name: "velero"3_create_oadp_service_monitor.yamlファイルを適用します。$ oc apply -f 3_create_oadp_service_monitor.yaml
出力例
servicemonitor.monitoring.coreos.com/oadp-service-monitor created
検証
OpenShift Container Platform Web コンソールの Administrator パースペクティブを使用して、新しいサービスモニターが Up 状態であることを確認します。
- Observe → Targets ページに移動します。
-
Filter が選択されていないこと、または User ソースが選択されていることを確認し、
Text検索フィールドにopenshift-adpと入力します。 サービスモニターの Status のステータスが Up であることを確認します。
図4.1 OADP メトリックのターゲット

4.5.12.3. アラートルールの作成
OpenShift Container Platform モニタリングスタックでは、アラートルールを使用して設定されたアラートを受信できます。OADP プロジェクトのアラートルールを作成するには、ユーザーワークロードの監視で収集されたメトリックの 1 つを使用します。
手順
サンプル
OADPBackupFailingアラートを含むPrometheusRuleYAML ファイルを作成し、4_create_oadp_alert_rule.yamlとして保存します。OADPBackupFailingアラートのサンプルapiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: sample-oadp-alert namespace: openshift-adp spec: groups: - name: sample-oadp-backup-alert rules: - alert: OADPBackupFailing annotations: description: 'OADP had {{$value | humanize}} backup failures over the last 2 hours.' summary: OADP has issues creating backups expr: | increase(velero_backup_failure_total{job="openshift-adp-velero-metrics-svc"}[2h]) > 0 for: 5m labels: severity: warningこのサンプルでは、アラートは次の条件で表示されます。
- 過去 2 時間に失敗した新しいバックアップの数が 0 より大きく増加しており、その状態が少なくとも 5 分間継続します。
-
最初の増加時間が 5 分未満の場合、アラートは
Pending状態になり、その後、Firing状態に変わります。
4_create_oadp_alert_rule.yamlファイルを適用して、openshift-adpnamespace にPrometheusRuleオブジェクトを作成します。$ oc apply -f 4_create_oadp_alert_rule.yaml
出力例
prometheusrule.monitoring.coreos.com/sample-oadp-alert created
検証
アラートがトリガーされた後は、次の方法でアラートを表示できます。
- Developer パースペクティブで、Observe メニューを選択します。
Observe → Alerting メニューの下の Administrator パースペクティブで、Filter ボックスの User を選択します。それ以外の場合、デフォルトでは Platform アラートのみが表示されます。
図4.2 OADP バックアップ失敗アラート

関連情報
4.5.12.4. 利用可能なメトリックのリスト
これらは、OADP によって提供されるメトリックとその Type のリストです。
| メトリック名 | 説明 | タイプ |
|---|---|---|
|
| キャッシュから取得したバイト数 | カウンター |
|
| コンテンツがキャッシュから取得された回数 | カウンター |
|
| 不正なコンテンツがキャッシュから読み取られた回数 | カウンター |
|
| コンテンツがキャッシュ内で見つからずフェッチされた回数 | カウンター |
|
| 基盤となるストレージから取得したバイト数 | カウンター |
|
| 基盤となるストレージでコンテンツが見つからなかった回数 | カウンター |
|
| コンテンツをキャッシュに保存できなかった回数 | カウンター |
|
|
| カウンター |
|
|
| カウンター |
|
|
| カウンター |
|
|
| カウンター |
|
|
| カウンター |
|
|
| カウンター |
|
| 試行されたバックアップの合計数 | カウンター |
|
| 試行されたバックアップ削除の合計数 | カウンター |
|
| 失敗したバックアップ削除の合計数 | カウンター |
|
| 成功したバックアップ削除の合計数 | カウンター |
|
| バックアップの完了にかかる時間 (秒単位) | ヒストグラム |
|
| 失敗したバックアップの合計数 | カウンター |
|
| バックアップ中に発生したエラーの合計数 | ゲージ |
|
| バックアップされたアイテムの総数 | ゲージ |
|
| バックアップの最終ステータス。値 1 は成功、値 0 は成功です。 | ゲージ |
|
| 最後にバックアップが正常に実行された時刻、秒単位の Unix タイムスタンプ | ゲージ |
|
| 部分的に失敗したバックアップの合計数 | カウンター |
|
| 成功したバックアップの合計数 | カウンター |
|
| バックアップのサイズ (バイト単位) | ゲージ |
|
| 既存のバックアップの現在の数 | ゲージ |
|
| 検証に失敗したバックアップの合計数 | カウンター |
|
| 警告されたバックアップの総数 | カウンター |
|
| CSI が試行したボリュームスナップショットの合計数 | カウンター |
|
| CSI で失敗したボリュームスナップショットの総数 | カウンター |
|
| CSI が成功したボリュームスナップショットの総数 | カウンター |
|
| 試行された復元の合計数 | カウンター |
|
| 失敗したリストアの合計数 | カウンター |
|
| 部分的に失敗したリストアの合計数 | カウンター |
|
| 成功した復元の合計数 | カウンター |
|
| 現在の既存のリストアの数 | ゲージ |
|
| 検証に失敗したリストアの失敗の合計数 | カウンター |
|
| 試行されたボリュームスナップショットの総数 | カウンター |
|
| 失敗したボリュームスナップショットの総数 | カウンター |
|
| 成功したボリュームスナップショットの総数 | カウンター |
4.5.12.5. Observe UI を使用したメトリックの表示
OpenShift Container Platform Web コンソールのメトリックは、Administrator または Developer パースペクティブから表示できます。これらのパースペクティブには、openshift-adp プロジェクトへのアクセス権が必要です。
手順
Observe → Metrics ページに移動します。
Developer パースペクティブを使用している場合は、次の手順に従います。
- Custom query を選択するか、Show PromQL リンクをクリックします。
- クエリーを入力し、Enter をクリックします。
Administrator パースペクティブを使用している場合は、テキストフィールドに式を入力し、Run Queries を選択します。
図4.3 OADP メトリッククエリー

4.6. OADP で使用される API
このドキュメントには、OADP で使用できる次の API に関する情報が記載されています。
- Velero API
- OADP API
4.6.1. Velero API
Velero API ドキュメントは、Red Hat ではなく、Velero によって管理されています。これは Velero API types にあります。
4.6.2. OADP API
次の表は、OADP API の構造を示しています。
表4.3 DataProtectionApplicationSpec
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| |
|
|
| |
|
| map [ UnsupportedImageKey ] string |
デプロイされた依存イメージを開発用にオーバーライドするために使用できます。オプションは、 |
|
| Operator によってデプロイされた Pod にアノテーションを追加するために使用されます。 | |
|
| Pod の DNS の設定を定義します。 | |
|
|
| |
|
| *bool | イメージのバックアップと復元を有効にするためにレジストリーを展開するかどうかを指定するために使用されます。 |
|
| データ保護アプリケーションのサーバー設定を定義するために使用されます。 | |
|
| テクノロジープレビュー機能を有効にするための DPA の設定を定義します。 |
表4.4 BackupLocation
| プロパティー | 型 | 説明 |
|---|---|---|
|
| Backup Storage Location で説明されているとおり、ボリュームスナップショットの保存場所。 | |
|
| [テクノロジープレビュー] 一部のクラウドストレージプロバイダーで、バックアップストレージの場所として使用するバケットの作成を自動化します。 |
bucket パラメーターはテクノロジープレビュー機能としてのみ提供されます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
表4.5 SnapshotLocation
| プロパティー | 型 | 説明 |
|---|---|---|
|
| Volume Snapshot Location で説明されているとおり、ボリュームスナップショットの保存場所。 |
SnapshotLocation タプの完全なスキーマ定義。
表4.6 ApplicationConfig
| プロパティー | 型 | 説明 |
|---|---|---|
|
| Velero サーバーの設定を定義します。 | |
|
| Restic サーバーの設定を定義します。 |
ApplicationConfig タイプの完全なスキーマ定義。
表4.7 VeleroConfig
| プロパティー | 型 | 説明 |
|---|---|---|
|
| [] string | Velero インスタンスで有効にする機能のリストを定義します。 |
|
| [] string |
次のタイプのデフォルトの Velero プラグインをインストールできます: |
|
| カスタム Velero プラグインのインストールに使用されます。 デフォルトおよびカスタムのプラグインについては、OADP plug-ins で説明しています。 | |
|
|
| |
|
|
デフォルトのバックアップストレージの場所を設定せずに Velero をインストールするには、インストールを確認するために | |
|
|
| |
|
|
Velero サーバーのログレベル (最も詳細なログを記録するには |
表4.9 ResticConfig
| プロパティー | 型 | 説明 |
|---|---|---|
|
| *bool |
|
|
| []int64 |
|
|
|
Restic タイムアウトを定義するユーザー指定の期間文字列。デフォルト値は | |
|
|
|
表4.10 PodConfig
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| |
|
|
Velero デプロイメントまたは Restic | |
|
|
Setting Velero CPU and memory resource allocations の説明に従って、 | |
|
| Pod に追加するラベル。 |
表4.11 機能
| プロパティー | 型 | 説明 |
|---|---|---|
|
| Data Mover の設定を定義します。 |
表4.12 DataMover
| プロパティー | 型 | 説明 |
|---|---|---|
|
|
| |
|
|
Data Mover のユーザー指定の Restic | |
|
|
|
OADP API の詳細については、OADP Operator を参照してください。
4.7. OADP の高度な特徴と機能
このドキュメントでは、OpenShift API for Data Protection (OADP) の高度な特徴と機能に関する情報を提供します。
4.7.1. 同一クラスター上での異なる Kubernetes API バージョンの操作
4.7.1.1. クラスター上の Kubernetes API グループバージョンの一覧表示
ソースクラスターは複数のバージョンの API を提供する場合があり、これらのバージョンの 1 つが優先 API バージョンになります。たとえば、Example という名前の API を持つソースクラスターは、example.com/v1 および example.com/v1beta2 API グループで使用できる場合があります。
Velero を使用してそのようなソースクラスターをバックアップおよび復元する場合、Velero は、Kubernetes API の優先バージョンを使用するリソースのバージョンのみをバックアップします。
上記の例では、example.com/v1 が優先 API である場合、Velero は example.com/v1 を使用するリソースのバージョンのみをバックアップします。さらに、Velero がターゲットクラスターでリソースを復元するには、ターゲットクラスターで使用可能な API リソースのセットに example.com/v1 が登録されている必要があります。
したがって、ターゲットクラスター上の Kubernetes API グループバージョンのリストを生成して、優先 API バージョンが使用可能な API リソースのセットに登録されていることを確認する必要があります。
手順
- 以下のコマンドを入力します。
$ oc api-resources
4.7.1.2. API グループバージョンの有効化について
デフォルトでは、Velero は Kubernetes API の優先バージョンを使用するリソースのみをバックアップします。ただし、Velero には、この制限を克服する機能 (Enable API Group Versions) も含まれています。ソースクラスターでこの機能を有効にすると、Velero は優先バージョンだけでなく、クラスターでサポートされている すべての Kubernetes API グループバージョンをバックアップします。バージョンがバックアップ .tar ファイルに保存されると、目的のクラスターで復元できるようになります。
たとえば、Example という名前の API を持つソースクラスターが、example.com/v1 および example.com/v1beta2 API グループで使用でき、example.com/v1 が優先 API だとします。
Enable API Group Versions 機能を有効にしないと、Velero は Example の優先 API グループバージョン (example.com/v1) のみをバックアップします。この機能を有効にすると、Velero は example.com/v1beta2 もバックアップします。
宛先クラスターで Enable API Group Versions 機能が有効になっている場合、Velero は、API グループバージョンの優先順位に基づいて、復元するバージョンを選択します。
Enable API Group Versions はまだベータ版です。
Velero は次のアルゴリズムを使用して API バージョンに優先順位を割り当てます。この場合、1 は優先順位が最も高くなります。
- 宛先 クラスターの優先バージョン
- source_ クラスターの優先バージョン
- Kubernetes バージョンの優先順位が最も高い共通の非優先サポート対象バージョン
4.7.1.3. Enable API Group Versions の使用
Velero の Enable API Group Versions 機能を使用して、優先バージョンだけでなく、クラスターでサポートされている すべての Kubernetes API グループバージョンをバックアップできます。
Enable API Group Versions はまだベータ版です。
手順
-
EnableAPIGroupVersions機能フラグを設定します。
apiVersion: oadp.openshift.io/vialpha1
kind: DataProtectionApplication
...
spec:
configuration:
velero:
featureFlags:
- EnableAPIGroupVersions4.7.2. 1 つのクラスターからデータをバックアップし、別のクラスターに復元する
4.7.2.1. あるクラスターからのデータのバックアップと別のクラスターへの復元について
OpenShift API for Data Protection (OADP) は、同じ OpenShift Container Platform クラスター内のアプリケーションデータをバックアップおよび復元するように設計されています。Migration Toolkit for Containers (MTC) は、アプリケーションデータを含むコンテナーを 1 つの OpenShift Container Platform クラスターから別のクラスターに移行するように設計されています。
OADP を使用して、1 つの OpenShift Container Platform クラスターからアプリケーションデータをバックアップし、それを別のクラスターに復元できます。ただし、これを行うことは、MTC または OADP を使用して同じクラスター上でバックアップと復元を行うよりも複雑です。
OADP を使用して 1 つのクラスターからデータをバックアップし、それを別のクラスターに復元するには、OADP を使用して同じクラスター上でデータをバックアップおよび復元する場合に適用される前提条件と手順に加えて、次の要素を考慮する必要があります。
- Operator
- Velero の使用
- UID と GID の範囲
4.7.2.1.1. Operator
バックアップと復元を成功させるには、アプリケーションのバックアップから Operator を除外する必要があります。
4.7.2.1.2. Velero の使用
OADP が構築されている Velero は、クラウドプロバイダー間での永続ボリュームスナップショットの移行をネイティブにサポートしていません。クラウドプラットフォーム間でボリュームスナップショットデータを移行するには、ファイルシステムレベルでボリュームの内容をバックアップする Velero Restic ファイルシステムバックアップオプションを有効にする か、または CSI スナップショットに OADP Data Mover を使用する必要があります。
OADP 1.1 以前では、Velero Restic ファイルシステムのバックアップオプションは restic と呼ばれます。OADP 1.2 以降では、Velero Restic ファイルシステムのバックアップオプションは file-system-backup と呼ばれます。
Velero のファイルシステムバックアップ機能は Kopia と Restic の両方をサポートしていますが、現在 OADP は Restic のみをサポートしています。
- AWS リージョン間または Microsoft Azure リージョン間でデータを移行するには、Velero の File System Backup も使用する必要があります。
- Velero は、ソースクラスターより 前の Kubernetes バージョンを使用したクラスターへのデータの復元をサポートしていません。
- 理論的には、移行元よりも 新しい Kubernetes バージョンを備えた移行先にワークロードを移行することは可能ですが、カスタムリソースごとにクラスター間の API グループの互換性を考慮する必要があります。Kubernetes バージョンのアップグレードによりコアまたはネイティブ API グループの互換性が失われる場合は、まず影響を受けるカスタムリソースを更新する必要があります。
4.7.2.1.3. UID と GID の範囲
あるクラスターからデータをバックアップし、それを別のクラスターに復元する場合、UID (ユーザー ID) および GID (グループ ID) の範囲に関して潜在的な問題が発生する可能性があります。次のセクションでは、これらの潜在的な問題と軽減策について説明します。
- 問題点のまとめ
- namespace の UID 範囲および GID 範囲は、宛先クラスターで変更される可能性があります。OADP は、OpenShift UID 範囲のメタデータをバックアップおよび復元しません。バックアップされたアプリケーションに特定の UID が必要な場合は、復元時にその範囲が使用可能であることを確認してください。OpenShift の UID 範囲および GID 範囲の詳細は、A Guide to OpenShift and UIDs を参照してください。
- 問題の詳細な説明
シェルコマンド
oc create namespaceを使用して OpenShift Container Platform でネームスペースを作成すると、OpenShift Container Platform は、使用可能な UID プールからの一意のユーザー ID (UID) 範囲、補足グループ (GID) 範囲、および一意の SELinux MCS ラベルを namespace に割り当てます。この情報は、クラスターのmetadata.annotationsフィールドに保存されます。この情報はセキュリティーコンテキスト制約 (SCC) アノテーションの一部であり、次のコンポーネントで設定されます。-
openshift.io/sa.scc.mcs -
openshift.io/sa.scc.supplemental-groups -
openshift.io/sa.scc.uid-range
OADP を使用して namespace を復元すると、宛先クラスターの情報をリセットせずに、
metadata.annotations内の情報が自動的に使用されます。その結果、次のいずれかに該当する場合、ワークロードはバックアップデータにアクセスできない可能性があります。- たとえば、別のクラスター上に、異なる SCC アノテーションを持つ既存の namespace があります。この場合、OADP はバックアップ時に、復元しようとしている namespace ではなく、既存の namespace を再利用します。
バックアップではラベルセレクターが使用されましたが、ワークロードが実行される namespace にはラベルがありません。この場合、OADP は namespace をバックアップしませんが、代わりに、バックアップした namespace のアノテーションを含まない新しい namespace を復元中に作成します。これにより、新しい UID 範囲が namespace に割り当てられます。
OpenShift Container Platform が永続ボリュームデータのバックアップ時から変更された namespace アノテーションに基づいて Pod に
securityContextUID を割り当てる場合、これはお客様 のワークロードにとって問題になる可能性があります。- コンテナー UID はファイル所有者の UID と一致しなくなりました。
- OpenShift Container Platform がバックアップクラスターのデータと一致するように宛先クラスターの UID 範囲を変更しなかったため、エラーが発生します。その結果、バックアップクラスターは宛先クラスターとは異なる UID を持つことになり、アプリケーションは宛先クラスターに対してデータの読み取りまたは書き込みを行うことができなくなります。
-
- 軽減策
次の 1 つ以上の緩和策を使用して、UID 範囲および GID 範囲の問題を解決できます。
簡単な緩和策:
-
BackupCR のラベルセレクターを使用して、バックアップに含めるオブジェクトをフィルター処理する場合は、必ずこのラベルセレクターをワークスペースを含む namespace に追加してください。 - 同じ名前の namespace を復元する前に、宛先クラスター上の namespace の既存のバージョンを削除してください。
-
高度な緩和策:
- 移行後の UID 範囲の修正の手順 1 ~ 4 を実行して、移行後に UID 範囲を修正します。ステップ 1 はオプションです。
あるクラスターでのデータのバックアップと別のクラスターでのリストアの問題の解決に重点を置いた、OpenShift Container Platform の UID 範囲および GID 範囲の詳細な説明は、A Guide to OpenShift and UIDs を 参照してください。
4.7.2.2. 1 つのクラスターからデータをバックアップし、別のクラスターに復元する
一般に、同じクラスターにデータをバックアップおよび復元するのと同じ方法で、1 つの OpenShift Container Platform クラスターからデータをバックアップし、別の OpenShift Container Platform クラスターに復元します。ただし、ある OpenShift Container Platform クラスターからデータをバックアップし、それを別のクラスターにリストアする場合は、追加の前提条件と手順の違いがいくつかあります。
前提条件
- プラットフォーム (AWS、Microsoft Azure、GCP など) でのバックアップと復元に関連するすべての前提条件、特にデータ保護アプリケーション (DPA) の前提条件については、このガイドの関連セクションで説明されています。
手順
ご使用のプラットフォームに指定されている手順に次の追加を加えます。
- リソースを別のクラスターに復元するには、バックアップストアの場所 (BSL) とボリュームスナップショットの場所が同じ名前とパスを持つようにしてください。
- 同じオブジェクトストレージの場所の認証情報をクラスター全体で共有します。
- 最良の結果を得るには、OADP を使用して宛先クラスターに namespace を作成します。
Velero
file-system-backupオプションを使用する場合は、次のコマンドを実行して、バックアップ中に使用する--default-volumes-to-fs-backupフラグを有効にします。$ velero backup create <backup_name> --default-volumes-to-fs-backup <any_other_options>
OADP 1.2 以降では、Velero Restic オプションは file-system-backup と呼ばれます。
4.7.3. 関連情報
API グループのバージョンの詳細は、同一クラスター上での異なる Kubernetes API バージョンの操作 を参照してください。
OADP Data Mover の詳細は、CSI スナップショットに Data Mover を使用する を参照してください。
OADP での Restic の使用の詳細は、Restic を使用したアプリケーションのバックアップ を参照してください。
第5章 コントロールプレーンのバックアップおよび復元
5.1. etcd のバックアップ
etcd は OpenShift Container Platform のキーと値のストアであり、すべてのリソースオブジェクトの状態を保存します。
クラスターの etcd データを定期的にバックアップし、OpenShift Container Platform 環境外の安全な場所に保存するのが理想的です。インストールの 24 時間後に行われる最初の証明書のローテーションが完了するまで etcd のバックアップを実行することはできません。ローテーションの完了前に実行すると、バックアップに期限切れの証明書が含まれることになります。etcd スナップショットは I/O コストが高いため、ピーク使用時間以外に etcd バックアップを取得することもお勧めします。
クラスターのアップグレード後に必ず etcd バックアップを作成してください。これは、クラスターを復元する際に、同じ z-stream リリースから取得した etcd バックアップを使用する必要があるために重要になります。たとえば、OpenShift Container Platform 4.y.z クラスターは、4.y.z から取得した etcd バックアップを使用する必要があります。
コントロールプレーンホストでバックアップスクリプトの単一の呼び出しを実行して、クラスターの etcd データをバックアップします。各コントロールプレーンホストのバックアップを取得しないでください。
etcd のバックアップを作成した後に、クラスターの直前の状態への復元を実行できます。
5.1.1. etcd データのバックアップ
以下の手順に従って、etcd スナップショットを作成し、静的 Pod のリソースをバックアップして etcd データをバックアップします。このバックアップは保存でき、etcd を復元する必要がある場合に後で使用することができます。
単一のコントロールプレーンホストからのバックアップのみを保存します。クラスター内の各コントロールプレーンホストからのバックアップは取得しないでください。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 クラスター全体のプロキシーが有効になっているかどうかを確認している。
ヒントoc get proxy cluster -o yamlの出力を確認して、プロキシーが有効にされているかどうかを確認できます。プロキシーは、httpProxy、httpsProxy、およびnoProxyフィールドに値が設定されている場合に有効にされます。
手順
コントロールプレーンノードのデバッグセッションを開始します。
$ oc debug node/<node_name>
ルートディレクトリーを
/hostに変更します。sh-4.2# chroot /host
-
クラスター全体のプロキシーが有効になっている場合は、
NO_PROXY、HTTP_PROXY、およびHTTPS_PROXY環境変数をエクスポートしていることを確認します。 etcd-snapshot-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、およびオブジェクト名は暗号化されません。
-
5.2. 正常でない etcd メンバーの置き換え
本書では、単一の正常でない etcd メンバーを置き換えるプロセスについて説明します。
このプロセスは、マシンが実行されていないか、ノードが準備状態にないことによって etcd メンバーが正常な状態にないか、etcd Pod がクラッシュループしているためにこれが正常な状態にないかによって異なります。
コントロールプレーンホストの大部分を損失した場合は、この手順ではなく、ディザスターリカバリー手順に従って、以前のクラスター状態に復元 してください。
コントロールプレーンの証明書が置き換えているメンバーで有効でない場合は、この手順ではなく、期限切れのコントロールプレーン証明書からの回復手順を実行する必要があります。
コントロールプレーンノードが失われ、新規ノードが作成される場合、etcd クラスター Operator は新規 TLS 証明書の生成と、ノードの etcd メンバーとしての追加を処理します。
5.2.1. 前提条件
- 正常でない etcd メンバーを置き換える前に、etcd バックアップを作成します。
5.2.2. 正常でない etcd メンバーの特定
クラスターに正常でない etcd メンバーがあるかどうかを特定することができます。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
以下のコマンドを使用して
EtcdMembersAvailableステータス条件のステータスを確認します。$ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="EtcdMembersAvailable")]}{.message}{"\n"}'出力を確認します。
2 of 3 members are available, ip-10-0-131-183.ec2.internal is unhealthy
この出力例は、
ip-10-0-131-183.ec2.internaletcd メンバーが正常ではないことを示しています。
5.2.3. 正常でない etcd メンバーの状態の判別
正常でない etcd メンバーを置き換える手順は、etcd メンバーが以下のどの状態にあるかによって異なります。
- マシンが実行されていないか、ノードが準備状態にない
- etcd Pod がクラッシュループしている。
以下の手順では、etcd メンバーがどの状態にあるかを判別します。これにより、正常でない etcd メンバーを置き換えるために実行する必要のある手順を確認できます。
マシンが実行されていないか、ノードが準備状態にないものの、すぐに正常な状態に戻ることが予想される場合は、etcd メンバーを置き換える手順を実行する必要はありません。etcd クラスター Operator はマシンまたはノードが正常な状態に戻ると自動的に同期します。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 - 正常でない etcd メンバーを特定している。
手順
マシンが実行されていないかどうかを判別します。
$ oc get machines -A -ojsonpath='{range .items[*]}{@.status.nodeRef.name}{"\t"}{@.status.providerStatus.instanceState}{"\n"}' | grep -v running出力例
ip-10-0-131-183.ec2.internal stopped 1- 1
- この出力には、ノードおよびノードのマシンのステータスを一覧表示されます。ステータスが
running以外の場合は、マシンは実行されていません。
マシンが実行されていない 場合は、マシンが実行されていないか、ノードが準備状態にない場合の正常でない etcd メンバーの置き換えの手順を実行します。
ノードが準備状態にないかどうかを判別します。
以下のシナリオのいずれかが true の場合、ノードは準備状態にありません。
マシンが実行されている場合は、ノードに到達できないかどうかを確認します。
$ oc get nodes -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{"\t"}{range .spec.taints[*]}{.key}{" "}' | grep unreachable出力例
ip-10-0-131-183.ec2.internal node-role.kubernetes.io/master node.kubernetes.io/unreachable node.kubernetes.io/unreachable 1- 1
- ノードが
unreachableテイントと共に一覧表示される場合、ノードの準備はできていません。
ノードが以前として到達可能である場合は、そのノードが
NotReadyとして一覧表示されているかどうかを確認します。$ oc get nodes -l node-role.kubernetes.io/master | grep "NotReady"
出力例
ip-10-0-131-183.ec2.internal NotReady master 122m v1.25.0 1- 1
- ノードが
NotReadyとして一覧表示されている場合、ノードの準備はできていません。
ノードの準備ができていない 場合は、マシンが実行されていないか、ノードが準備状態にない場合の正常でない etcd メンバーの置き換えの手順を実行します。
etcd Pod がクラッシュループしているかどうかを判別します。
マシンが実行され、ノードが準備できている場合は、etcd Pod がクラッシュループしているかどうかを確認します。
すべてのコントロールプレーンノードが
Readyとして一覧表示されていることを確認します。$ oc get nodes -l node-role.kubernetes.io/master
出力例
NAME STATUS ROLES AGE VERSION ip-10-0-131-183.ec2.internal Ready master 6h13m v1.25.0 ip-10-0-164-97.ec2.internal Ready master 6h13m v1.25.0 ip-10-0-154-204.ec2.internal Ready master 6h13m v1.25.0
etcd Pod のステータスが
ErrorまたはCrashloopBackoffのいずれかであるかどうかを確認します。$ oc -n openshift-etcd get pods -l k8s-app=etcd
出力例
etcd-ip-10-0-131-183.ec2.internal 2/3 Error 7 6h9m 1 etcd-ip-10-0-164-97.ec2.internal 3/3 Running 0 6h6m etcd-ip-10-0-154-204.ec2.internal 3/3 Running 0 6h6m- 1
- この Pod のこのステータスは
Errorであるため、etcd Pod はクラッシュループしています。
etcd Pod がクラッシュループしている場合、etcd Pod がクラッシュループしている場合の正常でない etcd メンバーの置き換えについての手順を実行します。
5.2.4. 正常でない etcd メンバーの置き換え
正常でない etcd メンバーの状態に応じて、以下のいずれかの手順を使用します。
5.2.4.1. マシンが実行されていないか、ノードが準備状態にない場合の正常でない etcd メンバーの置き換え
以下の手順では、マシンが実行されていないか、ノードが準備状態にない場合の正常でない etcd メンバーを置き換える手順を説明します。
クラスターがコントロールプレーンマシンセットを使用している場合、より簡単な etcd リカバリー手順については、コントロールプレーンマシンセットのトラブルシューティングの劣化した etcd Operator のリカバリーを参照してください。
前提条件
- 正常でない etcd メンバーを特定している。
マシンが実行されていないか、ノードが準備状態にないことを確認している。
重要他のコントロールプレーンノードの電源がオフになっている場合は、待機する必要があります。異常な etcd メンバーの交換が完了するまで、コントロールプレーンノードの電源をオフのままにしておく必要があります。
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 etcd のバックアップを取得している。
重要問題が発生した場合にクラスターを復元できるように、この手順を実行する前に etcd バックアップを作成しておくことは重要です。
手順
正常でないメンバーを削除します。
影響を受けるノード上に ない Pod を選択します。
クラスターにアクセスできるターミナルで、
cluster-adminユーザーとして以下のコマンドを実行します。$ oc -n openshift-etcd get pods -l k8s-app=etcd
出力例
etcd-ip-10-0-131-183.ec2.internal 3/3 Running 0 123m etcd-ip-10-0-164-97.ec2.internal 3/3 Running 0 123m etcd-ip-10-0-154-204.ec2.internal 3/3 Running 0 124m
実行中の etcd コンテナーに接続し、影響を受けるノードにない Pod の名前を渡します。
クラスターにアクセスできるターミナルで、
cluster-adminユーザーとして以下のコマンドを実行します。$ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
メンバーの一覧を確認します。
sh-4.2# etcdctl member list -w table
出力例
+------------------+---------+------------------------------+---------------------------+---------------------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | +------------------+---------+------------------------------+---------------------------+---------------------------+ | 6fc1e7c9db35841d | started | ip-10-0-131-183.ec2.internal | https://10.0.131.183:2380 | https://10.0.131.183:2379 | | 757b6793e2408b6c | started | ip-10-0-164-97.ec2.internal | https://10.0.164.97:2380 | https://10.0.164.97:2379 | | ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 | +------------------+---------+------------------------------+---------------------------+---------------------------+
これらの値はこの手順で後ほど必要となるため、ID および正常でない etcd メンバーの名前を書き留めておきます。
$ etcdctl endpoint healthコマンドは、補充手順が完了し、新しいメンバーが追加されるまで、削除されたメンバーを一覧表示します。ID を
etcdctl member removeコマンドに指定して、正常でない etcd メンバーを削除します。sh-4.2# etcdctl member remove 6fc1e7c9db35841d
出力例
Member 6fc1e7c9db35841d removed from cluster ead669ce1fbfb346
メンバーの一覧を再度表示し、メンバーが削除されたことを確認します。
sh-4.2# etcdctl member list -w table
出力例
+------------------+---------+------------------------------+---------------------------+---------------------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | +------------------+---------+------------------------------+---------------------------+---------------------------+ | 757b6793e2408b6c | started | ip-10-0-164-97.ec2.internal | https://10.0.164.97:2380 | https://10.0.164.97:2379 | | ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 | +------------------+---------+------------------------------+---------------------------+---------------------------+
これでノードシェルを終了できます。
重要メンバーを削除した後、残りの etcd インスタンスが再起動している間、クラスターに短時間アクセスできない場合があります。
次のコマンドを入力して、クォーラムガードをオフにします。
$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'このコマンドにより、シークレットを正常に再作成し、静的 Pod をロールアウトできるようになります。
削除された正常でない etcd メンバーの古いシークレットを削除します。
削除された正常でない etcd メンバーのシークレットを一覧表示します。
$ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal 1- 1
- この手順で先ほど書き留めた正常でない etcd メンバーの名前を渡します。
以下の出力に示されるように、ピア、サービング、およびメトリクスシークレットがあります。
出力例
etcd-peer-ip-10-0-131-183.ec2.internal kubernetes.io/tls 2 47m etcd-serving-ip-10-0-131-183.ec2.internal kubernetes.io/tls 2 47m etcd-serving-metrics-ip-10-0-131-183.ec2.internal kubernetes.io/tls 2 47m
削除された正常でない etcd メンバーのシークレットを削除します。
ピアシークレットを削除します。
$ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal
提供シークレットを削除します。
$ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal
メトリクスシークレットを削除します。
$ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal
コントロールプレーンマシンを削除して再度作成します。このマシンが再作成されると、新規リビジョンが強制的に実行され、etcd は自動的にスケールアップします。
インストーラーでプロビジョニングされるインフラストラクチャーを実行している場合、またはマシン API を使用してマシンを作成している場合は、以下の手順を実行します。それ以外の場合は、最初に作成する際に使用した方法と同じ方法を使用して新規マスターを作成する必要があります。
正常でないメンバーのマシンを取得します。
クラスターにアクセスできるターミナルで、
cluster-adminユーザーとして以下のコマンドを実行します。$ oc get machines -n openshift-machine-api -o wide
出力例
NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE clustername-8qw5l-master-0 Running m4.xlarge us-east-1 us-east-1a 3h37m ip-10-0-131-183.ec2.internal aws:///us-east-1a/i-0ec2782f8287dfb7e stopped 1 clustername-8qw5l-master-1 Running m4.xlarge us-east-1 us-east-1b 3h37m ip-10-0-154-204.ec2.internal aws:///us-east-1b/i-096c349b700a19631 running clustername-8qw5l-master-2 Running m4.xlarge us-east-1 us-east-1c 3h37m ip-10-0-164-97.ec2.internal aws:///us-east-1c/i-02626f1dba9ed5bba running clustername-8qw5l-worker-us-east-1a-wbtgd Running m4.large us-east-1 us-east-1a 3h28m ip-10-0-129-226.ec2.internal aws:///us-east-1a/i-010ef6279b4662ced running clustername-8qw5l-worker-us-east-1b-lrdxb Running m4.large us-east-1 us-east-1b 3h28m ip-10-0-144-248.ec2.internal aws:///us-east-1b/i-0cb45ac45a166173b running clustername-8qw5l-worker-us-east-1c-pkg26 Running m4.large us-east-1 us-east-1c 3h28m ip-10-0-170-181.ec2.internal aws:///us-east-1c/i-06861c00007751b0a running- 1
- これは正常でないノードのコントロールプレーンマシンです (
ip-10-0-131-183.ec2.internal)。
マシン設定をファイルシステムのファイルに保存します。
$ oc get machine clustername-8qw5l-master-0 \ 1 -n openshift-machine-api \ -o yaml \ > new-master-machine.yaml- 1
- 正常でないノードのコントロールプレーンマシンの名前を指定します。
直前の手順で作成された
new-master-machine.yamlファイルを編集し、新しい名前を割り当て、不要なフィールドを削除します。statusセクション全体を削除します。status: addresses: - address: 10.0.131.183 type: InternalIP - address: ip-10-0-131-183.ec2.internal type: InternalDNS - address: ip-10-0-131-183.ec2.internal type: Hostname lastUpdated: "2020-04-20T17:44:29Z" nodeRef: kind: Node name: ip-10-0-131-183.ec2.internal uid: acca4411-af0d-4387-b73e-52b2484295ad phase: Running providerStatus: apiVersion: awsproviderconfig.openshift.io/v1beta1 conditions: - lastProbeTime: "2020-04-20T16:53:50Z" lastTransitionTime: "2020-04-20T16:53:50Z" message: machine successfully created reason: MachineCreationSucceeded status: "True" type: MachineCreation instanceId: i-0fdb85790d76d0c3f instanceState: stopped kind: AWSMachineProviderStatusmetadata.nameフィールドを新規の名前に変更します。古いマシンと同じベース名を維持し、最後の番号を次に利用可能な番号に変更することが推奨されます。この例では、
clustername-8qw5l-master-0はclustername-8qw5l-master-3に変更されています。以下に例を示します。
apiVersion: machine.openshift.io/v1beta1 kind: Machine metadata: ... name: clustername-8qw5l-master-3 ...
spec.providerIDフィールドを削除します。providerID: aws:///us-east-1a/i-0fdb85790d76d0c3f
正常でないメンバーのマシンを削除します。
$ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 1- 1
- 正常でないノードのコントロールプレーンマシンの名前を指定します。
マシンが削除されたことを確認します。
$ oc get machines -n openshift-machine-api -o wide
出力例
NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE clustername-8qw5l-master-1 Running m4.xlarge us-east-1 us-east-1b 3h37m ip-10-0-154-204.ec2.internal aws:///us-east-1b/i-096c349b700a19631 running clustername-8qw5l-master-2 Running m4.xlarge us-east-1 us-east-1c 3h37m ip-10-0-164-97.ec2.internal aws:///us-east-1c/i-02626f1dba9ed5bba running clustername-8qw5l-worker-us-east-1a-wbtgd Running m4.large us-east-1 us-east-1a 3h28m ip-10-0-129-226.ec2.internal aws:///us-east-1a/i-010ef6279b4662ced running clustername-8qw5l-worker-us-east-1b-lrdxb Running m4.large us-east-1 us-east-1b 3h28m ip-10-0-144-248.ec2.internal aws:///us-east-1b/i-0cb45ac45a166173b running clustername-8qw5l-worker-us-east-1c-pkg26 Running m4.large us-east-1 us-east-1c 3h28m ip-10-0-170-181.ec2.internal aws:///us-east-1c/i-06861c00007751b0a running
new-master-machine.yamlファイルを使用して新規マシンを作成します。$ oc apply -f new-master-machine.yaml
新規マシンが作成されたことを確認します。
$ oc get machines -n openshift-machine-api -o wide
出力例
NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE clustername-8qw5l-master-1 Running m4.xlarge us-east-1 us-east-1b 3h37m ip-10-0-154-204.ec2.internal aws:///us-east-1b/i-096c349b700a19631 running clustername-8qw5l-master-2 Running m4.xlarge us-east-1 us-east-1c 3h37m ip-10-0-164-97.ec2.internal aws:///us-east-1c/i-02626f1dba9ed5bba running clustername-8qw5l-master-3 Provisioning m4.xlarge us-east-1 us-east-1a 85s ip-10-0-133-53.ec2.internal aws:///us-east-1a/i-015b0888fe17bc2c8 running 1 clustername-8qw5l-worker-us-east-1a-wbtgd Running m4.large us-east-1 us-east-1a 3h28m ip-10-0-129-226.ec2.internal aws:///us-east-1a/i-010ef6279b4662ced running clustername-8qw5l-worker-us-east-1b-lrdxb Running m4.large us-east-1 us-east-1b 3h28m ip-10-0-144-248.ec2.internal aws:///us-east-1b/i-0cb45ac45a166173b running clustername-8qw5l-worker-us-east-1c-pkg26 Running m4.large us-east-1 us-east-1c 3h28m ip-10-0-170-181.ec2.internal aws:///us-east-1c/i-06861c00007751b0a running- 1
- 新規マシン
clustername-8qw5l-master-3が作成され、ProvisioningからRunningにフェーズが変更されると準備状態になります。
新規マシンが作成されるまでに数分の時間がかかる場合があります。etcd クラスター Operator はマシンまたはノードが正常な状態に戻ると自動的に同期します。
次のコマンドを入力して、クォーラムガードをオンに戻します。
$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'次のコマンドを入力して、
unsupportedConfigOverridesセクションがオブジェクトから削除されたことを確認できます。$ oc get etcd/cluster -oyaml
単一ノードの OpenShift を使用している場合は、ノードを再起動します。そうしないと、etcd クラスター Operator で次のエラーが発生する可能性があります。
出力例
EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]
検証
すべての etcd Pod が適切に実行されていることを確認します。
クラスターにアクセスできるターミナルで、
cluster-adminユーザーとして以下のコマンドを実行します。$ oc -n openshift-etcd get pods -l k8s-app=etcd
出力例
etcd-ip-10-0-133-53.ec2.internal 3/3 Running 0 7m49s etcd-ip-10-0-164-97.ec2.internal 3/3 Running 0 123m etcd-ip-10-0-154-204.ec2.internal 3/3 Running 0 124m
直前のコマンドの出力に 2 つの Pod のみが一覧表示される場合、etcd の再デプロイメントを手動で強制できます。クラスターにアクセスできるターミナルで、
cluster-adminユーザーとして以下のコマンドを実行します。$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1- 1
forceRedeploymentReason値は一意である必要があります。そのため、タイムスタンプが付加されます。
3 つの etcd メンバーがあることを確認します。
実行中の etcd コンテナーに接続し、影響を受けるノードになかった Pod の名前を渡します。
クラスターにアクセスできるターミナルで、
cluster-adminユーザーとして以下のコマンドを実行します。$ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
メンバーの一覧を確認します。
sh-4.2# etcdctl member list -w table
出力例
+------------------+---------+------------------------------+---------------------------+---------------------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | +------------------+---------+------------------------------+---------------------------+---------------------------+ | 5eb0d6b8ca24730c | started | ip-10-0-133-53.ec2.internal | https://10.0.133.53:2380 | https://10.0.133.53:2379 | | 757b6793e2408b6c | started | ip-10-0-164-97.ec2.internal | https://10.0.164.97:2380 | https://10.0.164.97:2379 | | ca8c2990a0aa29d1 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 | +------------------+---------+------------------------------+---------------------------+---------------------------+
直前のコマンドの出力に 4 つ以上の etcd メンバーが表示される場合、不要なメンバーを慎重に削除する必要があります。
警告必ず適切な etcd メンバーを削除します。適切な etcd メンバーを削除すると、クォーラム (定足数) が失われる可能性があります。
5.2.4.2. etcd Pod がクラッシュループしている場合の正常でない etcd メンバーの置き換え
この手順では、etcd Pod がクラッシュループしている場合の正常でない etcd メンバーを置き換える手順を説明します。
前提条件
- 正常でない etcd メンバーを特定している。
- etcd Pod がクラッシュループしていることを確認している。
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 etcd のバックアップを取得している。
重要問題が発生した場合にクラスターを復元できるように、この手順を実行する前に etcd バックアップを作成しておくことは重要です。
手順
クラッシュループしている etcd Pod を停止します。
クラッシュループしているノードをデバッグします。
クラスターにアクセスできるターミナルで、
cluster-adminユーザーとして以下のコマンドを実行します。$ oc debug node/ip-10-0-131-183.ec2.internal 1- 1
- これを正常でないノードの名前に置き換えます。
ルートディレクトリーを
/hostに変更します。sh-4.2# chroot /host
既存の etcd Pod ファイルを kubelet マニフェストディレクトリーから移動します。
sh-4.2# mkdir /var/lib/etcd-backup
sh-4.2# mv /etc/kubernetes/manifests/etcd-pod.yaml /var/lib/etcd-backup/
etcd データディレクトリーを別の場所に移動します。
sh-4.2# mv /var/lib/etcd/ /tmp
これでノードシェルを終了できます。
正常でないメンバーを削除します。
影響を受けるノード上に ない Pod を選択します。
クラスターにアクセスできるターミナルで、
cluster-adminユーザーとして以下のコマンドを実行します。$ oc -n openshift-etcd get pods -l k8s-app=etcd
出力例
etcd-ip-10-0-131-183.ec2.internal 2/3 Error 7 6h9m etcd-ip-10-0-164-97.ec2.internal 3/3 Running 0 6h6m etcd-ip-10-0-154-204.ec2.internal 3/3 Running 0 6h6m
実行中の etcd コンテナーに接続し、影響を受けるノードにない Pod の名前を渡します。
クラスターにアクセスできるターミナルで、
cluster-adminユーザーとして以下のコマンドを実行します。$ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
メンバーの一覧を確認します。
sh-4.2# etcdctl member list -w table
出力例
+------------------+---------+------------------------------+---------------------------+---------------------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | +------------------+---------+------------------------------+---------------------------+---------------------------+ | 62bcf33650a7170a | started | ip-10-0-131-183.ec2.internal | https://10.0.131.183:2380 | https://10.0.131.183:2379 | | b78e2856655bc2eb | started | ip-10-0-164-97.ec2.internal | https://10.0.164.97:2380 | https://10.0.164.97:2379 | | d022e10b498760d5 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 | +------------------+---------+------------------------------+---------------------------+---------------------------+
これらの値はこの手順で後ほど必要となるため、ID および正常でない etcd メンバーの名前を書き留めておきます。
ID を
etcdctl member removeコマンドに指定して、正常でない etcd メンバーを削除します。sh-4.2# etcdctl member remove 62bcf33650a7170a
出力例
Member 62bcf33650a7170a removed from cluster ead669ce1fbfb346
メンバーの一覧を再度表示し、メンバーが削除されたことを確認します。
sh-4.2# etcdctl member list -w table
出力例
+------------------+---------+------------------------------+---------------------------+---------------------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | +------------------+---------+------------------------------+---------------------------+---------------------------+ | b78e2856655bc2eb | started | ip-10-0-164-97.ec2.internal | https://10.0.164.97:2380 | https://10.0.164.97:2379 | | d022e10b498760d5 | started | ip-10-0-154-204.ec2.internal | https://10.0.154.204:2380 | https://10.0.154.204:2379 | +------------------+---------+------------------------------+---------------------------+---------------------------+
これでノードシェルを終了できます。
次のコマンドを入力して、クォーラムガードをオフにします。
$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'このコマンドにより、シークレットを正常に再作成し、静的 Pod をロールアウトできるようになります。
削除された正常でない etcd メンバーの古いシークレットを削除します。
削除された正常でない etcd メンバーのシークレットを一覧表示します。
$ oc get secrets -n openshift-etcd | grep ip-10-0-131-183.ec2.internal 1- 1
- この手順で先ほど書き留めた正常でない etcd メンバーの名前を渡します。
以下の出力に示されるように、ピア、サービング、およびメトリクスシークレットがあります。
出力例
etcd-peer-ip-10-0-131-183.ec2.internal kubernetes.io/tls 2 47m etcd-serving-ip-10-0-131-183.ec2.internal kubernetes.io/tls 2 47m etcd-serving-metrics-ip-10-0-131-183.ec2.internal kubernetes.io/tls 2 47m
削除された正常でない etcd メンバーのシークレットを削除します。
ピアシークレットを削除します。
$ oc delete secret -n openshift-etcd etcd-peer-ip-10-0-131-183.ec2.internal
提供シークレットを削除します。
$ oc delete secret -n openshift-etcd etcd-serving-ip-10-0-131-183.ec2.internal
メトリクスシークレットを削除します。
$ oc delete secret -n openshift-etcd etcd-serving-metrics-ip-10-0-131-183.ec2.internal
etcd の再デプロイメントを強制的に実行します。
クラスターにアクセスできるターミナルで、
cluster-adminユーザーとして以下のコマンドを実行します。$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "single-master-recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1- 1
forceRedeploymentReason値は一意である必要があります。そのため、タイムスタンプが付加されます。
etcd クラスター Operator が再デプロイを実行する場合、すべてのコントロールプレーンノードで etcd Pod が機能していることを確認します。
次のコマンドを入力して、クォーラムガードをオンに戻します。
$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'次のコマンドを入力して、
unsupportedConfigOverridesセクションがオブジェクトから削除されたことを確認できます。$ oc get etcd/cluster -oyaml
単一ノードの OpenShift を使用している場合は、ノードを再起動します。そうしないと、etcd クラスター Operator で次のエラーが発生する可能性があります。
出力例
EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]
検証
新しいメンバーが利用可能で、正常な状態にあることを確認します。
再度実行中の etcd コンテナーに接続します。
クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。
$ oc rsh -n openshift-etcd etcd-ip-10-0-154-204.ec2.internal
すべてのメンバーが正常であることを確認します。
sh-4.2# etcdctl endpoint health
出力例
https://10.0.131.183:2379 is healthy: successfully committed proposal: took = 16.671434ms https://10.0.154.204:2379 is healthy: successfully committed proposal: took = 16.698331ms https://10.0.164.97:2379 is healthy: successfully committed proposal: took = 16.621645ms
5.2.4.3. マシンが実行されていないか、ノードが準備状態にない場合の正常でないベアメタル etcd メンバーの置き換え
以下の手順では、マシンが実行されていないか、ノードが準備状態にない場合の正常でない ベアメタル etcd メンバーを置き換える手順を説明します。
インストーラーでプロビジョニングされるインフラストラクチャーを実行している場合、またはマシン API を使用してマシンを作成している場合は、以下の手順を実行します。それ以外の場合は、最初に作成したときと同じ方法で、新しいコントロールプレーンノードを作成する必要があります。
前提条件
- 正常でないベアメタル etcd メンバーを特定している。
- マシンが実行されていないか、ノードが準備状態にないことを確認している。
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。 etcd のバックアップを取得している。
重要問題が発生した場合にクラスターを復元できるように、この手順を実行する前に etcd バックアップを作成しておく。
手順
正常でないメンバーを確認し、削除します。
影響を受けるノード上に ない Pod を選択します。
クラスターにアクセスできるターミナルで、
cluster-adminユーザーとして以下のコマンドを実行します。$ oc -n openshift-etcd get pods -l k8s-app=etcd -o wide
出力例
etcd-openshift-control-plane-0 5/5 Running 11 3h56m 192.168.10.9 openshift-control-plane-0 <none> <none> etcd-openshift-control-plane-1 5/5 Running 0 3h54m 192.168.10.10 openshift-control-plane-1 <none> <none> etcd-openshift-control-plane-2 5/5 Running 0 3h58m 192.168.10.11 openshift-control-plane-2 <none> <none>
実行中の etcd コンテナーに接続し、影響を受けるノードにない Pod の名前を渡します。
クラスターにアクセスできるターミナルで、
cluster-adminユーザーとして以下のコマンドを実行します。$ oc rsh -n openshift-etcd etcd-openshift-control-plane-0
メンバーの一覧を確認します。
sh-4.2# etcdctl member list -w table
出力例
+------------------+---------+--------------------+---------------------------+---------------------------+---------------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | IS LEARNER | +------------------+---------+--------------------+---------------------------+---------------------------+---------------------+ | 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380/ | https://192.168.10.11:2379/ | false | | 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380/ | https://192.168.10.10:2379/ | false | | cc3830a72fc357f9 | started | openshift-control-plane-0 | https://192.168.10.9:2380/ | https://192.168.10.9:2379/ | false | +------------------+---------+--------------------+---------------------------+---------------------------+---------------------+
これらの値はこの手順で後ほど必要となるため、ID および正常でない etcd メンバーの名前を書き留めておきます。
etcdctl endpoint healthコマンドは、置き換えの手順が完了し、新規メンバーが追加されるまで、削除されたメンバーを一覧表示します。ID を
etcdctl member removeコマンドに指定して、正常でない etcd メンバーを削除します。警告必ず適切な etcd メンバーを削除します。適切な etcd メンバーを削除すると、クォーラム (定足数) が失われる可能性があります。
sh-4.2# etcdctl member remove 7a8197040a5126c8
出力例
Member 7a8197040a5126c8 removed from cluster b23536c33f2cdd1b
メンバーの一覧を再度表示し、メンバーが削除されたことを確認します。
sh-4.2# etcdctl member list -w table
出力例
+------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | IS LEARNER | +------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+ | 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380/ | https://192.168.10.11:2379/ | false | | 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380/ | https://192.168.10.10:2379/ | false | +------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+
これでノードシェルを終了できます。
重要メンバーを削除した後、残りの etcd インスタンスが再起動している間、クラスターに短時間アクセスできない場合があります。
次のコマンドを入力して、クォーラムガードをオフにします。
$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'このコマンドにより、シークレットを正常に再作成し、静的 Pod をロールアウトできるようになります。
以下のコマンドを実行して、削除された正常でない etcd メンバーの古いシークレットを削除します。
削除された正常でない etcd メンバーのシークレットを一覧表示します。
$ oc get secrets -n openshift-etcd | grep openshift-control-plane-2
この手順で先ほど書き留めた正常でない etcd メンバーの名前を渡します。
以下の出力に示されるように、ピア、サービング、およびメトリクスシークレットがあります。
etcd-peer-openshift-control-plane-2 kubernetes.io/tls 2 134m etcd-serving-metrics-openshift-control-plane-2 kubernetes.io/tls 2 134m etcd-serving-openshift-control-plane-2 kubernetes.io/tls 2 134m
削除された正常でない etcd メンバーのシークレットを削除します。
ピアシークレットを削除します。
$ oc delete secret etcd-peer-openshift-control-plane-2 -n openshift-etcd secret "etcd-peer-openshift-control-plane-2" deleted
提供シークレットを削除します。
$ oc delete secret etcd-serving-metrics-openshift-control-plane-2 -n openshift-etcd secret "etcd-serving-metrics-openshift-control-plane-2" deleted
メトリクスシークレットを削除します。
$ oc delete secret etcd-serving-openshift-control-plane-2 -n openshift-etcd secret "etcd-serving-openshift-control-plane-2" deleted
コントロールプレーンマシンを削除します。
インストーラーでプロビジョニングされるインフラストラクチャーを実行している場合、またはマシン API を使用してマシンを作成している場合は、以下の手順を実行します。それ以外の場合は、最初に作成したときと同じ方法で、新しいコントロールプレーンノードを作成する必要があります。
正常でないメンバーのマシンを取得します。
クラスターにアクセスできるターミナルで、
cluster-adminユーザーとして以下のコマンドを実行します。$ oc get machines -n openshift-machine-api -o wide
出力例
NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE examplecluster-control-plane-0 Running 3h11m openshift-control-plane-0 baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e externally provisioned 1 examplecluster-control-plane-1 Running 3h11m openshift-control-plane-1 baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1 externally provisioned examplecluster-control-plane-2 Running 3h11m openshift-control-plane-2 baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135 externally provisioned examplecluster-compute-0 Running 165m openshift-compute-0 baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f provisioned examplecluster-compute-1 Running 165m openshift-compute-1 baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9 provisioned- 1
- これは正常でないノードのコントロールプレーンマシンです (
examplecluster-control-plane-2)。
マシン設定をファイルシステムのファイルに保存します。
$ oc get machine examplecluster-control-plane-2 \ 1 -n openshift-machine-api \ -o yaml \ > new-master-machine.yaml- 1
- 正常でないノードのコントロールプレーンマシンの名前を指定します。
直前の手順で作成された
new-master-machine.yamlファイルを編集し、新しい名前を割り当て、不要なフィールドを削除します。statusセクション全体を削除します。status: addresses: - address: "" type: InternalIP - address: fe80::4adf:37ff:feb0:8aa1%ens1f1.373 type: InternalDNS - address: fe80::4adf:37ff:feb0:8aa1%ens1f1.371 type: Hostname lastUpdated: "2020-04-20T17:44:29Z" nodeRef: kind: Machine name: fe80::4adf:37ff:feb0:8aa1%ens1f1.372 uid: acca4411-af0d-4387-b73e-52b2484295ad phase: Running providerStatus: apiVersion: machine.openshift.io/v1beta1 conditions: - lastProbeTime: "2020-04-20T16:53:50Z" lastTransitionTime: "2020-04-20T16:53:50Z" message: machine successfully created reason: MachineCreationSucceeded status: "True" type: MachineCreation instanceId: i-0fdb85790d76d0c3f instanceState: stopped kind: Machine
metadata.nameフィールドを新規の名前に変更します。古いマシンと同じベース名を維持し、最後の番号を次に利用可能な番号に変更することが推奨されます。この例では、
examplecluster-control-plane-2がexamplecluster-control-plane-3に変更されています。以下に例を示します。
apiVersion: machine.openshift.io/v1beta1 kind: Machine metadata: ... name: examplecluster-control-plane-3 ...
spec.providerIDフィールドを削除します。providerID: baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135
metadata.annotationsおよびmetadata.generationフィールドを削除します。annotations: machine.openshift.io/instance-state: externally provisioned ... generation: 2spec.conditions、spec.lastUpdated、spec.nodeRef、およびspec.phaseフィールドを削除します。lastTransitionTime: "2022-08-03T08:40:36Z" message: 'Drain operation currently blocked by: [{Name:EtcdQuorumOperator Owner:clusteroperator/etcd}]' reason: HookPresent severity: Warning status: "False" type: Drainable lastTransitionTime: "2022-08-03T08:39:55Z" status: "True" type: InstanceExists lastTransitionTime: "2022-08-03T08:36:37Z" status: "True" type: Terminable lastUpdated: "2022-08-03T08:40:36Z" nodeRef: kind: Node name: openshift-control-plane-2 uid: 788df282-6507-4ea2-9a43-24f237ccbc3c phase: Running
以下のコマンドを実行して、Bare Metal Operator が利用可能であることを確認します。
$ oc get clusteroperator baremetal
出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE baremetal 4.12.0 True False False 3d15h
次のコマンドを実行して、古い
BareMetalHostオブジェクトを削除します。$ oc delete bmh openshift-control-plane-2 -n openshift-machine-api
出力例
baremetalhost.metal3.io "openshift-control-plane-2" deleted
次のコマンドを実行して、異常なメンバーのマシンを削除します。
$ oc delete machine -n openshift-machine-api examplecluster-control-plane-2
BareMetalHostおよびMachineオブジェクトを削除すると、MachineコントローラーによりNodeオブジェクトが自動的に削除されます。何らかの理由でマシンの削除が遅れたり、コマンドが妨げられて遅れたりする場合は、マシンオブジェクトのファイナライザーフィールドを削除することで強制的に削除できます。
重要Ctrl+cを押してマシンの削除を中断しないでください。コマンドが完了するまで続行できるようにする必要があります。新しいターミナルウィンドウを開き、ファイナライザーフィールドを編集して削除します。次のコマンドを実行して、マシン設定を編集します。
$ oc edit machine -n openshift-machine-api examplecluster-control-plane-2
Machineカスタムリソースの次のフィールドを削除し、更新されたファイルを保存します。finalizers: - machine.machine.openshift.io
出力例
machine.machine.openshift.io/examplecluster-control-plane-2 edited
以下のコマンドを実行して、マシンが削除されていることを確認します。
$ oc get machines -n openshift-machine-api -o wide
出力例
NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE examplecluster-control-plane-0 Running 3h11m openshift-control-plane-0 baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e externally provisioned examplecluster-control-plane-1 Running 3h11m openshift-control-plane-1 baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1 externally provisioned examplecluster-compute-0 Running 165m openshift-compute-0 baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f provisioned examplecluster-compute-1 Running 165m openshift-compute-1 baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9 provisioned
次のコマンドを実行して、ノードが削除されたことを確認します。
$ oc get nodes NAME STATUS ROLES AGE VERSION openshift-control-plane-0 Ready master 3h24m v1.25.0 openshift-control-plane-1 Ready master 3h24m v1.25.0 openshift-compute-0 Ready worker 176m v1.25.0 openshift-compute-1 Ready worker 176m v1.25.0
新しい
BareMetalHostオブジェクトとシークレットを作成して BMC 認証情報を保存します。$ cat <<EOF | oc apply -f - apiVersion: v1 kind: Secret metadata: name: openshift-control-plane-2-bmc-secret namespace: openshift-machine-api data: password: <password> username: <username> type: Opaque --- apiVersion: metal3.io/v1alpha1 kind: BareMetalHost metadata: name: openshift-control-plane-2 namespace: openshift-machine-api spec: automatedCleaningMode: disabled bmc: address: redfish://10.46.61.18:443/redfish/v1/Systems/1 credentialsName: openshift-control-plane-2-bmc-secret disableCertificateVerification: true bootMACAddress: 48:df:37:b0:8a:a0 bootMode: UEFI externallyProvisioned: false online: true rootDeviceHints: deviceName: /dev/sda userData: name: master-user-data-managed namespace: openshift-machine-api EOF注記ユーザー名とパスワードは、他のベアメタルホストのシークレットで確認できます。
bmc:addressで使用するプロトコルは、他の bmh オブジェクトから取得できます。重要既存のコントロールプレーンホストから
BareMetalHostオブジェクト定義を再利用する場合は、externallyProvisionedフィールドをtrueに設定したままにしないでください。既存のコントロールプレーン
BareMetalHostオブジェクトが、OpenShift Container Platform インストールプログラムによってプロビジョニングされた場合には、externallyProvisionedフラグがtrueに設定されている可能性があります。検査が完了すると、
BareMetalHostオブジェクトが作成され、プロビジョニングできるようになります。利用可能な
BareMetalHostオブジェクトを使用して作成プロセスを確認します。$ oc get bmh -n openshift-machine-api NAME STATE CONSUMER ONLINE ERROR AGE openshift-control-plane-0 externally provisioned examplecluster-control-plane-0 true 4h48m openshift-control-plane-1 externally provisioned examplecluster-control-plane-1 true 4h48m openshift-control-plane-2 available examplecluster-control-plane-3 true 47m openshift-compute-0 provisioned examplecluster-compute-0 true 4h48m openshift-compute-1 provisioned examplecluster-compute-1 true 4h48m
new-master-machine.yamlファイルを使用して新規コントロールプレーンマシンを作成します。$ oc apply -f new-master-machine.yaml
新規マシンが作成されたことを確認します。
$ oc get machines -n openshift-machine-api -o wide
出力例
NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE examplecluster-control-plane-0 Running 3h11m openshift-control-plane-0 baremetalhost:///openshift-machine-api/openshift-control-plane-0/da1ebe11-3ff2-41c5-b099-0aa41222964e externally provisioned 1 examplecluster-control-plane-1 Running 3h11m openshift-control-plane-1 baremetalhost:///openshift-machine-api/openshift-control-plane-1/d9f9acbc-329c-475e-8d81-03b20280a3e1 externally provisioned examplecluster-control-plane-2 Running 3h11m openshift-control-plane-2 baremetalhost:///openshift-machine-api/openshift-control-plane-2/3354bdac-61d8-410f-be5b-6a395b056135 externally provisioned examplecluster-compute-0 Running 165m openshift-compute-0 baremetalhost:///openshift-machine-api/openshift-compute-0/3d685b81-7410-4bb3-80ec-13a31858241f provisioned examplecluster-compute-1 Running 165m openshift-compute-1 baremetalhost:///openshift-machine-api/openshift-compute-1/0fdae6eb-2066-4241-91dc-e7ea72ab13b9 provisioned- 1
- 新規マシン
clustername-8qw5l-master-3が作成され、ProvisioningからRunningにフェーズが変更されると準備状態になります。
新規マシンが作成されるまでに数分の時間がかかる場合があります。etcd クラスター Operator はマシンまたはノードが正常な状態に戻ると自動的に同期します。
以下のコマンドを実行して、ベアメタルホストがプロビジョニングされ、エラーが報告されていないことを確認します。
$ oc get bmh -n openshift-machine-api
出力例
$ oc get bmh -n openshift-machine-api NAME STATE CONSUMER ONLINE ERROR AGE openshift-control-plane-0 externally provisioned examplecluster-control-plane-0 true 4h48m openshift-control-plane-1 externally provisioned examplecluster-control-plane-1 true 4h48m openshift-control-plane-2 provisioned examplecluster-control-plane-3 true 47m openshift-compute-0 provisioned examplecluster-compute-0 true 4h48m openshift-compute-1 provisioned examplecluster-compute-1 true 4h48m
以下のコマンドを実行して、新規ノードが追加され、Ready の状態であることを確認します。
$ oc get nodes
出力例
$ oc get nodes NAME STATUS ROLES AGE VERSION openshift-control-plane-0 Ready master 4h26m v1.25.0 openshift-control-plane-1 Ready master 4h26m v1.25.0 openshift-control-plane-2 Ready master 12m v1.25.0 openshift-compute-0 Ready worker 3h58m v1.25.0 openshift-compute-1 Ready worker 3h58m v1.25.0
次のコマンドを入力して、クォーラムガードをオンに戻します。
$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'次のコマンドを入力して、
unsupportedConfigOverridesセクションがオブジェクトから削除されたことを確認できます。$ oc get etcd/cluster -oyaml
単一ノードの OpenShift を使用している場合は、ノードを再起動します。そうしないと、etcd クラスター Operator で次のエラーが発生する可能性があります。
出力例
EtcdCertSignerControllerDegraded: [Operation cannot be fulfilled on secrets "etcd-peer-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-sno-0": the object has been modified; please apply your changes to the latest version and try again, Operation cannot be fulfilled on secrets "etcd-serving-metrics-sno-0": the object has been modified; please apply your changes to the latest version and try again]
検証
すべての etcd Pod が適切に実行されていることを確認します。
クラスターにアクセスできるターミナルで、
cluster-adminユーザーとして以下のコマンドを実行します。$ oc -n openshift-etcd get pods -l k8s-app=etcd
出力例
etcd-openshift-control-plane-0 5/5 Running 0 105m etcd-openshift-control-plane-1 5/5 Running 0 107m etcd-openshift-control-plane-2 5/5 Running 0 103m
直前のコマンドの出力に 2 つの Pod のみが一覧表示される場合、etcd の再デプロイメントを手動で強制できます。クラスターにアクセスできるターミナルで、
cluster-adminユーザーとして以下のコマンドを実行します。$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1- 1
forceRedeploymentReason値は一意である必要があります。そのため、タイムスタンプが付加されます。
etcd メンバーがちょうど 3 つあることを確認するには、実行中の etcd コンテナーに接続し、影響を受けたノード上になかった Pod の名前を渡します。クラスターにアクセスできるターミナルで、
cluster-adminユーザーとして以下のコマンドを実行します。$ oc rsh -n openshift-etcd etcd-openshift-control-plane-0
メンバーの一覧を確認します。
sh-4.2# etcdctl member list -w table
出力例
+------------------+---------+--------------------+---------------------------+---------------------------+-----------------+ | ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | IS LEARNER | +------------------+---------+--------------------+---------------------------+---------------------------+-----------------+ | 7a8197040a5126c8 | started | openshift-control-plane-2 | https://192.168.10.11:2380 | https://192.168.10.11:2379 | false | | 8d5abe9669a39192 | started | openshift-control-plane-1 | https://192.168.10.10:2380 | https://192.168.10.10:2379 | false | | cc3830a72fc357f9 | started | openshift-control-plane-0 | https://192.168.10.9:2380 | https://192.168.10.9:2379 | false | +------------------+---------+--------------------+---------------------------+---------------------------+-----------------+
注記直前のコマンドの出力に 4 つ以上の etcd メンバーが表示される場合、不要なメンバーを慎重に削除する必要があります。
以下のコマンドを実行して、すべての etcd メンバーが正常であることを確認します。
# etcdctl endpoint health --cluster
出力例
https://192.168.10.10:2379 is healthy: successfully committed proposal: took = 8.973065ms https://192.168.10.9:2379 is healthy: successfully committed proposal: took = 11.559829ms https://192.168.10.11:2379 is healthy: successfully committed proposal: took = 11.665203ms
以下のコマンドを実行して、すべてのノードが最新のリビジョンであることを確認します。
$ oc get etcd -o=jsonpath='{range.items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'AllNodesAtLatestRevision
5.2.5. 関連情報
5.3. ホストされたクラスターでの etcd のバックアップと復元
OpenShift Container Platform でホストされたコントロールプレーンを使用する場合、etcd をバックアップおよび復元するプロセスは、通常の etcd バックアッププロセス とは異なります。
ホストされたコントロールプレーンは、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
5.3.1. ホストされたクラスターでの etcd のスナップショットの作成
ホストされたクラスターの etcd をバックアップするプロセスの一環として、etcd のスナップショットを作成します。スナップショットを作成した後、たとえば障害復旧操作の一部として復元できます。
この手順には、API のダウンタイムが必要です。
手順
このコマンドを入力して、ホストされたクラスターの調整を一時停止します。
$ oc patch -n clusters hostedclusters/${CLUSTER_NAME} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=mergeこのコマンドを入力して、すべての etcd-writer デプロイメントを停止します。
$ oc scale deployment -n ${HOSTED_CLUSTER_NAMESPACE} --replicas=0 kube-apiserver openshift-apiserver openshift-oauth-apiserver各 etcd コンテナーで
execコマンドを使用して、etcd スナップショットを作成します。$ oc exec -it etcd-0 -n ${HOSTED_CLUSTER_NAMESPACE} -- env ETCDCTL_API=3 /usr/bin/etcdctl --cacert /etc/etcd/tls/client/etcd-client-ca.crt --cert /etc/etcd/tls/client/etcd-client.crt --key /etc/etcd/tls/client/etcd-client.key --endpoints=localhost:2379 snapshot save /var/lib/data/snapshot.db $ oc exec -it etcd-0 -n ${HOSTED_CLUSTER_NAMESPACE} -- env ETCDCTL_API=3 /usr/bin/etcdctl -w table snapshot status /var/lib/data/snapshot.db次の例に示すように、S3 バケットなど、後で取得できる場所にスナップショットデータをコピーします。
注記次の例では、署名バージョン 2 を使用しています。署名バージョン 4 をサポートするリージョン (例: us-east-2 リージョン) にいる場合は、署名バージョン 4 を使用してください。それ以外の場合は、署名バージョン 2 を使用してスナップショットを S3 バケットにコピーすると、アップロードは失敗し、署名バージョン 2 は非推奨になります。
例
BUCKET_NAME=somebucket FILEPATH="/${BUCKET_NAME}/${CLUSTER_NAME}-snapshot.db" CONTENT_TYPE="application/x-compressed-tar" DATE_VALUE=`date -R` SIGNATURE_STRING="PUT\n\n${CONTENT_TYPE}\n${DATE_VALUE}\n${FILEPATH}" ACCESS_KEY=accesskey SECRET_KEY=secret SIGNATURE_HASH=`echo -en ${SIGNATURE_STRING} | openssl sha1 -hmac ${SECRET_KEY} -binary | base64` oc exec -it etcd-0 -n ${HOSTED_CLUSTER_NAMESPACE} -- curl -X PUT -T "/var/lib/data/snapshot.db" \ -H "Host: ${BUCKET_NAME}.s3.amazonaws.com" \ -H "Date: ${DATE_VALUE}" \ -H "Content-Type: ${CONTENT_TYPE}" \ -H "Authorization: AWS ${ACCESS_KEY}:${SIGNATURE_HASH}" \ https://${BUCKET_NAME}.s3.amazonaws.com/${CLUSTER_NAME}-snapshot.db後で新しいクラスターでスナップショットを復元できるようにする場合は、この例に示すように、ホストされたクラスターが参照する暗号化シークレットを保存します。
例
oc get hostedcluster $CLUSTER_NAME -o=jsonpath='{.spec.secretEncryption.aescbc}' {"activeKey":{"name":"CLUSTER_NAME-etcd-encryption-key"}} # Save this secret, or the key it contains so the etcd data can later be decrypted oc get secret ${CLUSTER_NAME}-etcd-encryption-key -o=jsonpath='{.data.key}'
次のステップ
etcd スナップショットを復元します。
5.3.2. ホストされたクラスターでの etcd スナップショットの復元
ホストされたクラスターからの etcd のスナップショットがある場合は、それを復元できます。現在、クラスターの作成中にのみ etcd スナップショットを復元できます。
etcd スナップショットを復元するには、create cluster --render コマンドからの出力を変更し、HostedCluster 仕様の etcd セクションで restoreSnapshotURL 値を定義します。
前提条件
ホストされたクラスターで etcd スナップショットを作成している。
手順
awsコマンドラインインターフェイス (CLI) で事前に署名された URL を作成し、認証情報を etcd デプロイメントに渡さずに S3 から etcd スナップショットをダウンロードできるようにします。ETCD_SNAPSHOT=${ETCD_SNAPSHOT:-"s3://${BUCKET_NAME}/${CLUSTER_NAME}-snapshot.db"} ETCD_SNAPSHOT_URL=$(aws s3 presign ${ETCD_SNAPSHOT})次の URL を参照するように
HostedCluster仕様を変更します。spec: etcd: managed: storage: persistentVolume: size: 4Gi type: PersistentVolume restoreSnapshotURL: - "${ETCD_SNAPSHOT_URL}" managementType: Managed-
spec.secretEncryption.aescbc値から参照したシークレットに、前の手順で保存したものと同じ AES キーが含まれていることを確認します。
5.3.3. 関連情報
5.4. 障害復旧
5.4.1. 障害復旧について
この障害復旧ドキュメントでは、OpenShift Container Platform クラスターで発生する可能性のある複数の障害のある状態からの復旧方法についての管理者向けの情報を提供しています。管理者は、クラスターの状態を機能する状態に戻すために、以下の 1 つまたは複数の手順を実行する必要がある場合があります。
障害復旧には、少なくとも 1 つの正常なコントロールプレーンホストが必要です。
- クラスターの直前の状態への復元
このソリューションは、管理者が重要なものを削除した場合など、クラスターを直前の状態に復元する必要がある状態に対応します。これには、大多数のコントロールプレーンホストが失われたために etcd クォーラム (定足数) が失われ、クラスターがオフラインになる状態も含まれます。etcd バックアップを取得している限り、以下の手順に従ってクラスターを直前の状態に復元できます。
該当する場合は、コントロールプレーン証明書の期限切れの状態からのリカバリーが必要になる場合もあります。
警告クラスターの直前の状態への復元は、実行中のクラスターで行う破壊的で、不安定なアクションです。この手順は、最後の手段としてのみ使用してください。
復元の実行前に、クラスターへの影響の詳細についてクラスターの復元を参照してください。
注記大多数のマスターが依然として利用可能であり、etcd のクォーラムがある場合は、手順に従って単一の正常でない etcd メンバーの置き換えを実行します。
- コントロールプレーン証明書の期限切れの状態からのリカバリー
- このソリューションは、コントロールプレーン証明書の期限が切れた状態に対応します。たとえば、インストールの 24 時間後に行われる最初の証明書のローテーション前にクラスターをシャットダウンする場合、証明書はローテーションされず、期限切れになります。以下の手順に従って、コントロールプレーン証明書の期限切れの状態からのリカバリーを実行できます。
5.4.2. クラスターの直前の状態への復元
クラスターを直前の状態に復元するには、スナップショットを作成して、事前に etcd データのバックアップを行っている必要があります。このスナップショットを使用して、クラスターの状態を復元します。
5.4.2.1. クラスターの状態の復元について
etcd バックアップを使用して、クラスターを直前の状態に復元できます。これは、以下の状況から回復するために使用できます。
- クラスターは、大多数のコントロールプレーンホストを失いました (クォーラムの喪失)。
- 管理者が重要なものを削除し、クラスターを復旧するために復元する必要があります。
クラスターの直前の状態への復元は、実行中のクラスターで行う破壊的で、不安定なアクションです。これは、最後の手段としてのみ使用してください。
Kubernetes API サーバーを使用してデータを取得できる場合は、etcd が利用できるため、etcd バックアップを使用して復元することはできません。
etcd を効果的に復元すると、クラスターが時間内に元に戻され、すべてのクライアントは競合する並列履歴が発生します。これは、kubelet、Kubernetes コントローラーマネージャー、SDN コントローラー、永続ボリュームコントローラーなどのコンポーネントを監視する動作に影響を与える可能性があります。
etcd のコンテンツがディスク上の実際のコンテンツと一致しないと、Operator チャーンが発生し、ディスク上のファイルが etcd のコンテンツと競合すると、Kubernetes API サーバー、Kubernetes コントローラーマネージャー、Kubernetes スケジューラーなどの Operator が停止する場合があります。この場合は、問題の解決に手動のアクションが必要になる場合があります。
極端な場合、クラスターは永続ボリュームを追跡できなくなり、存在しなくなった重要なワークロードを削除し、マシンのイメージを再作成し、期限切れの証明書を使用して CA バンドルを書き換えることができます。
5.4.2.2. クラスターの直前の状態への復元
保存された etcd のバックアップを使用して、クラスターの以前の状態を復元したり、大多数のコントロールプレーンホストが失われたクラスターを復元したりできます。
クラスターがコントロールプレーンマシンセットを使用している場合、より簡単な etcd リカバリー手順については、コントロールプレーンマシンセットのトラブルシューティングを参照してください。
クラスターを復元する際に、同じ z-stream リリースから取得した etcd バックアップを使用する必要があります。たとえば、OpenShift Container Platform 4.7.2 クラスターは、4.7.2 から取得した etcd バックアップを使用する必要があります。
前提条件
-
インストール時に使用したものと同様、証明書ベースの
kubeconfigファイルを介して、cluster-adminロールを持つユーザーとしてクラスターにアクセスします。 - リカバリーホストとして使用する正常なコントロールプレーンホストがあること。
- コントロールプレーンホストへの SSH アクセス。
-
etcd スナップショットと静的 Pod のリソースの両方を含むバックアップディレクトリー (同じバックアップから取られるもの)。ディレクトリー内のファイル名は、
snapshot_<datetimestamp>.dbおよびstatic_kuberesources_<datetimestamp>.tar.gzの形式にする必要があります。
非復元コントロールプレーンノードの場合は、SSH 接続を確立したり、静的 Pod を停止したりする必要はありません。他のリカバリー以外のコントロールプレーンマシンを 1 つずつ削除し、再作成します。
手順
- リカバリーホストとして使用するコントロールプレーンホストを選択します。これは、復元操作を実行するホストです。
リカバリーホストを含む、各コントロールプレーンノードへの SSH 接続を確立します。
Kubernetes API サーバーは復元プロセスの開始後にアクセスできなくなるため、コントロールプレーンノードにはアクセスできません。このため、別のターミナルで各コントロールプレーンホストに SSH 接続を確立することが推奨されます。
重要この手順を完了しないと、復元手順を完了するためにコントロールプレーンホストにアクセスすることができなくなり、この状態からクラスターを回復できなくなります。
etcd バックアップディレクトリーをリカバリーコントロールプレーンホストにコピーします。
この手順では、etcd スナップショットおよび静的 Pod のリソースを含む
backupディレクトリーを、リカバリーコントロールプレーンホストの/home/core/ディレクトリーにコピーしていることを前提としています。他のすべてのコントロールプレーンノードで静的 Pod を停止します。
注記リカバリーホストで静的 Pod を停止する必要はありません。
- リカバリーホストではないコントロールプレーンホストにアクセスします。
既存の etcd Pod ファイルを kubelet マニフェストディレクトリーから移動します。
$ sudo mv /etc/kubernetes/manifests/etcd-pod.yaml /tmp
etcd Pod が停止していることを確認します。
$ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"
コマンドの出力は空であるはずです。空でない場合は、数分待機してから再度確認します。
既存の Kubernetes API サーバー Pod ファイルを kubelet マニフェストディレクトリーから移動します。
$ sudo mv /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp
Kubernetes API サーバー Pod が停止していることを確認します。
$ sudo crictl ps | grep kube-apiserver | egrep -v "operator|guard"
コマンドの出力は空であるはずです。空でない場合は、数分待機してから再度確認します。
etcd データディレクトリーを別の場所に移動します。
$ sudo mv /var/lib/etcd/ /tmp
- リカバリーホストではない他のコントロールプレーンホストでこの手順を繰り返します。
- リカバリーコントロールプレーンホストにアクセスします。
クラスター全体のプロキシーが有効になっている場合は、
NO_PROXY、HTTP_PROXY、およびHTTPS_PROXY環境変数をエクスポートしていることを確認します。ヒントoc get proxy cluster -o yamlの出力を確認して、プロキシーが有効にされているかどうかを確認できます。プロキシーは、httpProxy、httpsProxy、およびnoProxyフィールドに値が設定されている場合に有効にされます。リカバリーコントロールプレーンホストで復元スクリプトを実行し、パスを etcd バックアップディレクトリーに渡します。
$ sudo -E /usr/local/bin/cluster-restore.sh /home/core/backup
スクリプトの出力例
...stopping kube-scheduler-pod.yaml ...stopping kube-controller-manager-pod.yaml ...stopping etcd-pod.yaml ...stopping kube-apiserver-pod.yaml Waiting for container etcd to stop .complete Waiting for container etcdctl to stop .............................complete Waiting for container etcd-metrics to stop complete Waiting for container kube-controller-manager to stop complete Waiting for container kube-apiserver to stop ..........................................................................................complete Waiting for container kube-scheduler to stop complete Moving etcd data-dir /var/lib/etcd/member to /var/lib/etcd-backup starting restore-etcd static pod starting kube-apiserver-pod.yaml static-pod-resources/kube-apiserver-pod-7/kube-apiserver-pod.yaml starting kube-controller-manager-pod.yaml static-pod-resources/kube-controller-manager-pod-7/kube-controller-manager-pod.yaml starting kube-scheduler-pod.yaml static-pod-resources/kube-scheduler-pod-8/kube-scheduler-pod.yaml
注記最後の etcd バックアップの後にノード証明書が更新された場合、復元プロセスによってノードが
NotReady状態になる可能性があります。ノードをチェックして、
Ready状態であることを確認します。以下のコマンドを実行します。
$ oc get nodes -w
出力例
NAME STATUS ROLES AGE VERSION host-172-25-75-28 Ready master 3d20h v1.25.0 host-172-25-75-38 Ready infra,worker 3d20h v1.25.0 host-172-25-75-40 Ready master 3d20h v1.25.0 host-172-25-75-65 Ready master 3d20h v1.25.0 host-172-25-75-74 Ready infra,worker 3d20h v1.25.0 host-172-25-75-79 Ready worker 3d20h v1.25.0 host-172-25-75-86 Ready worker 3d20h v1.25.0 host-172-25-75-98 Ready infra,worker 3d20h v1.25.0
すべてのノードが状態を報告するのに数分かかる場合があります。
NotReady状態のノードがある場合は、ノードにログインし、各ノードの/var/lib/kubelet/pkiディレクトリーからすべての PEM ファイルを削除します。ノードに SSH 接続するか、Web コンソールのターミナルウィンドウを使用できます。$ ssh -i <ssh-key-path> core@<master-hostname>
サンプル
pkiディレクトリーsh-4.4# pwd /var/lib/kubelet/pki sh-4.4# ls kubelet-client-2022-04-28-11-24-09.pem kubelet-server-2022-04-28-11-24-15.pem kubelet-client-current.pem kubelet-server-current.pem
すべてのコントロールプレーンホストで kubelet サービスを再起動します。
リカバリーホストから以下のコマンドを実行します。
$ sudo systemctl restart kubelet.service
- 他のすべてのコントロールプレーンホストでこの手順を繰り返します。
保留中の CSR を承認します。
注記単一ノードクラスターや 3 つのスケジュール可能なコントロールプレーンノードで設定されるクラスターなど、ワーカーノードを持たないクラスターには、承認する保留中の CSR はありません。この手順にリストされているすべてのコマンドをスキップできます。
現在の CSR の一覧を取得します。
$ oc get csr
出力例
NAME AGE SIGNERNAME REQUESTOR CONDITION csr-2s94x 8m3s kubernetes.io/kubelet-serving system:node:<node_name> Pending 1 csr-4bd6t 8m3s kubernetes.io/kubelet-serving system:node:<node_name> Pending 2 csr-4hl85 13m kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending 3 csr-zhhhp 3m8s kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending 4 ...
CSR の詳細をレビューし、これが有効であることを確認します。
$ oc describe csr <csr_name> 1- 1
<csr_name>は、現行の CSR の一覧からの CSR の名前です。
それぞれの有効な
node-bootstrapperCSR を承認します。$ oc adm certificate approve <csr_name>
ユーザーによってプロビジョニングされるインストールの場合は、それぞれの有効な kubelet 提供の CSR を承認します。
$ oc adm certificate approve <csr_name>
単一メンバーのコントロールプレーンが正常に起動していることを確認します。
リカバリーホストから etcd コンテナーが実行中であることを確認します。
$ sudo crictl ps | grep etcd | egrep -v "operator|etcd-guard"
出力例
3ad41b7908e32 36f86e2eeaaffe662df0d21041eb22b8198e0e58abeeae8c743c3e6e977e8009 About a minute ago Running etcd 0 7c05f8af362f0
リカバリーホストから、etcd Pod が実行されていることを確認します。
$ oc -n openshift-etcd get pods -l k8s-app=etcd
出力例
NAME READY STATUS RESTARTS AGE etcd-ip-10-0-143-125.ec2.internal 1/1 Running 1 2m47s
ステータスが
Pendingの場合や出力に複数の実行中の etcd Pod が一覧表示される場合、数分待機してから再度チェックを行います。
OVNKubernetesネットワークプラグインを使用している場合は、リカバリーコントロールプレーンホストではないコントロールプレーンホストに関連付けられているノードオブジェクトを削除します。$ oc delete node <non-recovery-controlplane-host-1> <non-recovery-controlplane-host-2>
Cluster Network Operator (CNO) が OVN-Kubernetes コントロールプレーンを再デプロイし、回復していないコントローラー IP アドレスを参照していないことを確認します。この結果を確認するには、以下のコマンドの出力を定期的に確認します。空の結果が返されるまで待ってから、次の手順ですべてのホスト上の Open Virtual Network (OVN) Kubernetes Pod の再起動に進みます。
$ oc -n openshift-ovn-kubernetes get ds/ovnkube-master -o yaml | grep -E '<non-recovery_controller_ip_1>|<non-recovery_controller_ip_2>'
注記OVN-Kubernetes コントロールプレーンが再デプロイされ、直前のコマンドが空の出力を返すまでに 5-10 分以上かかる場合があります。
すべてのホストで Open Virtual Network (OVN) Kubernetes Pod を再起動します。
注記検証および変更用の受付 Webhook は Pod を拒否することができます。
failurePolicyをFailに設定して追加の Webhook を追加すると、Pod が拒否され、復元プロセスが失敗する可能性があります。これは、クラスターの状態の復元中に Webhook を保存および削除することで回避できます。クラスターの状態が正常に復元された後に、Webhook を再度有効にできます。または、クラスターの状態の復元中に
failurePolicyを一時的にIgnoreに設定できます。クラスターの状態が正常に復元された後に、failurePolicyをFailにすることができます。ノースバウンドデータベース (nbdb) とサウスバウンドデータベース (sbdb) を削除します。Secure Shell (SSH) を使用してリカバリーホストと残りのコントロールプレーンノードにアクセスし、次のコマンドを実行します。
$ sudo rm -f /var/lib/ovn/etc/*.db
次のコマンドを実行して、すべての OVN-Kubernetes コントロールプレーン Pod を削除します。
$ oc delete pods -l app=ovnkube-master -n openshift-ovn-kubernetes
次のコマンドを実行して、OVN-Kubernetes コントロールプレーン Pod が再度デプロイされ、
Running状態になっていることを確認します。$ oc get pods -l app=ovnkube-master -n openshift-ovn-kubernetes
出力例
NAME READY STATUS RESTARTS AGE ovnkube-master-nb24h 4/4 Running 0 48s
次のコマンドを実行して、すべての
ovnkube-nodePod を削除します。$ oc get pods -n openshift-ovn-kubernetes -o name | grep ovnkube-node | while read p ; do oc delete $p -n openshift-ovn-kubernetes ; done
次のコマンドを実行して、すべての
ovnkube-nodePod が再度デプロイされ、Running状態になっていることを確認します。$ oc get pods -n openshift-ovn-kubernetes | grep ovnkube-node
他の非復旧のコントロールプレーンマシンを 1 つずつ削除して再作成します。マシンが再作成された後、新しいリビジョンが強制され、etcd が自動的にスケールアップします。
ユーザーがプロビジョニングしたベアメタルインストールを使用する場合は、最初に作成したときと同じ方法を使用して、コントロールプレーンマシンを再作成できます。詳細については、ユーザーがプロビジョニングしたクラスターをベアメタルにインストールするを参照してください。
警告リカバリーホストのマシンを削除し、再作成しないでください。
インストーラーでプロビジョニングされるインフラストラクチャーを実行している場合、またはマシン API を使用してマシンを作成している場合は、以下の手順を実行します。
警告リカバリーホストのマシンを削除し、再作成しないでください。
インストーラーによってプロビジョニングされたインフラストラクチャーでのベアメタルインストールの場合、コントロールプレーンマシンは再作成されません。詳細については、ベアメタルコントロールプレーンノードの交換を参照してください。
失われたコントロールプレーンホストのいずれかのマシンを取得します。
クラスターにアクセスできるターミナルで、cluster-admin ユーザーとして以下のコマンドを実行します。
$ oc get machines -n openshift-machine-api -o wide
出力例:
NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE clustername-8qw5l-master-0 Running m4.xlarge us-east-1 us-east-1a 3h37m ip-10-0-131-183.ec2.internal aws:///us-east-1a/i-0ec2782f8287dfb7e stopped 1 clustername-8qw5l-master-1 Running m4.xlarge us-east-1 us-east-1b 3h37m ip-10-0-143-125.ec2.internal aws:///us-east-1b/i-096c349b700a19631 running clustername-8qw5l-master-2 Running m4.xlarge us-east-1 us-east-1c 3h37m ip-10-0-154-194.ec2.internal aws:///us-east-1c/i-02626f1dba9ed5bba running clustername-8qw5l-worker-us-east-1a-wbtgd Running m4.large us-east-1 us-east-1a 3h28m ip-10-0-129-226.ec2.internal aws:///us-east-1a/i-010ef6279b4662ced running clustername-8qw5l-worker-us-east-1b-lrdxb Running m4.large us-east-1 us-east-1b 3h28m ip-10-0-144-248.ec2.internal aws:///us-east-1b/i-0cb45ac45a166173b running clustername-8qw5l-worker-us-east-1c-pkg26 Running m4.large us-east-1 us-east-1c 3h28m ip-10-0-170-181.ec2.internal aws:///us-east-1c/i-06861c00007751b0a running- 1
- これは、失われたコントロールプレーンホストのコントロールプレーンマシンです (
ip-10-0-131-183.ec2.internal)。
マシン設定をファイルシステムのファイルに保存します。
$ oc get machine clustername-8qw5l-master-0 \ 1 -n openshift-machine-api \ -o yaml \ > new-master-machine.yaml- 1
- 失われたコントロールプレーンホストのコントロールプレーンマシンの名前を指定します。
直前の手順で作成された
new-master-machine.yamlファイルを編集し、新しい名前を割り当て、不要なフィールドを削除します。statusセクション全体を削除します。status: addresses: - address: 10.0.131.183 type: InternalIP - address: ip-10-0-131-183.ec2.internal type: InternalDNS - address: ip-10-0-131-183.ec2.internal type: Hostname lastUpdated: "2020-04-20T17:44:29Z" nodeRef: kind: Node name: ip-10-0-131-183.ec2.internal uid: acca4411-af0d-4387-b73e-52b2484295ad phase: Running providerStatus: apiVersion: awsproviderconfig.openshift.io/v1beta1 conditions: - lastProbeTime: "2020-04-20T16:53:50Z" lastTransitionTime: "2020-04-20T16:53:50Z" message: machine successfully created reason: MachineCreationSucceeded status: "True" type: MachineCreation instanceId: i-0fdb85790d76d0c3f instanceState: stopped kind: AWSMachineProviderStatusmetadata.nameフィールドを新規の名前に変更します。古いマシンと同じベース名を維持し、最後の番号を次に利用可能な番号に変更することが推奨されます。この例では、
clustername-8qw5l-master-0はclustername-8qw5l-master-3に変更されています。apiVersion: machine.openshift.io/v1beta1 kind: Machine metadata: ... name: clustername-8qw5l-master-3 ...
spec.providerIDフィールドを削除します。providerID: aws:///us-east-1a/i-0fdb85790d76d0c3f
metadata.annotationsおよびmetadata.generationフィールドを削除します。annotations: machine.openshift.io/instance-state: running ... generation: 2
metadata.resourceVersionおよびmetadata.uidフィールドを削除します。resourceVersion: "13291" uid: a282eb70-40a2-4e89-8009-d05dd420d31a
失われたコントロールプレーンホストのマシンを削除します。
$ oc delete machine -n openshift-machine-api clustername-8qw5l-master-0 1- 1
- 失われたコントロールプレーンホストのコントロールプレーンマシンの名前を指定します。
マシンが削除されたことを確認します。
$ oc get machines -n openshift-machine-api -o wide
出力例:
NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE clustername-8qw5l-master-1 Running m4.xlarge us-east-1 us-east-1b 3h37m ip-10-0-143-125.ec2.internal aws:///us-east-1b/i-096c349b700a19631 running clustername-8qw5l-master-2 Running m4.xlarge us-east-1 us-east-1c 3h37m ip-10-0-154-194.ec2.internal aws:///us-east-1c/i-02626f1dba9ed5bba running clustername-8qw5l-worker-us-east-1a-wbtgd Running m4.large us-east-1 us-east-1a 3h28m ip-10-0-129-226.ec2.internal aws:///us-east-1a/i-010ef6279b4662ced running clustername-8qw5l-worker-us-east-1b-lrdxb Running m4.large us-east-1 us-east-1b 3h28m ip-10-0-144-248.ec2.internal aws:///us-east-1b/i-0cb45ac45a166173b running clustername-8qw5l-worker-us-east-1c-pkg26 Running m4.large us-east-1 us-east-1c 3h28m ip-10-0-170-181.ec2.internal aws:///us-east-1c/i-06861c00007751b0a running
new-master-machine.yamlファイルを使用してマシンを作成します。$ oc apply -f new-master-machine.yaml
新規マシンが作成されたことを確認します。
$ oc get machines -n openshift-machine-api -o wide
出力例:
NAME PHASE TYPE REGION ZONE AGE NODE PROVIDERID STATE clustername-8qw5l-master-1 Running m4.xlarge us-east-1 us-east-1b 3h37m ip-10-0-143-125.ec2.internal aws:///us-east-1b/i-096c349b700a19631 running clustername-8qw5l-master-2 Running m4.xlarge us-east-1 us-east-1c 3h37m ip-10-0-154-194.ec2.internal aws:///us-east-1c/i-02626f1dba9ed5bba running clustername-8qw5l-master-3 Provisioning m4.xlarge us-east-1 us-east-1a 85s ip-10-0-173-171.ec2.internal aws:///us-east-1a/i-015b0888fe17bc2c8 running 1 clustername-8qw5l-worker-us-east-1a-wbtgd Running m4.large us-east-1 us-east-1a 3h28m ip-10-0-129-226.ec2.internal aws:///us-east-1a/i-010ef6279b4662ced running clustername-8qw5l-worker-us-east-1b-lrdxb Running m4.large us-east-1 us-east-1b 3h28m ip-10-0-144-248.ec2.internal aws:///us-east-1b/i-0cb45ac45a166173b running clustername-8qw5l-worker-us-east-1c-pkg26 Running m4.large us-east-1 us-east-1c 3h28m ip-10-0-170-181.ec2.internal aws:///us-east-1c/i-06861c00007751b0a running- 1
- 新規マシン
clustername-8qw5l-master-3が作成され、ProvisioningからRunningにフェーズが変更されると準備状態になります。
新規マシンが作成されるまでに数分の時間がかかる場合があります。etcd クラスター Operator はマシンまたはノードが正常な状態に戻ると自動的に同期します。
- リカバリーホストではない喪失したコントロールプレーンホストで、これらのステップを繰り返します。
次のコマンドを入力して、クォーラムガードをオフにします。
$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'このコマンドにより、シークレットを正常に再作成し、静的 Pod をロールアウトできるようになります。
リカバリーホスト内の別のターミナルウィンドウで、次のコマンドを実行してリカバリー
kubeconfigファイルをエクスポートします。$ export KUBECONFIG=/etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs/localhost-recovery.kubeconfig
etcd の再デプロイメントを強制的に実行します。
リカバリー
kubeconfigファイルをエクスポートしたのと同じターミナルウィンドウで、次のコマンドを実行します。$ oc patch etcd cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=merge 1- 1
forceRedeploymentReason値は一意である必要があります。そのため、タイムスタンプが付加されます。
etcd クラスター Operator が再デプロイメントを実行すると、初期ブートストラップのスケールアップと同様に、既存のノードが新規 Pod と共に起動します。
次のコマンドを入力して、クォーラムガードをオンに戻します。
$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": null}}'次のコマンドを入力して、
unsupportedConfigOverridesセクションがオブジェクトから削除されたことを確認できます。$ oc get etcd/cluster -oyaml
すべてのノードが最新のリビジョンに更新されていることを確認します。
クラスターにアクセスできるターミナルで、
cluster-adminユーザーとして以下のコマンドを実行します。$ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'etcd の
NodeInstallerProgressing状況条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力にはAllNodesAtLatestRevisionが表示されます。AllNodesAtLatestRevision 3 nodes are at revision 7 1- 1
- この例では、最新のリビジョン番号は
7です。
出力に
2 nodes are at revision 6; 1 nodes are at revision 7などの複数のリビジョン番号が含まれる場合、これは更新が依然として進行中であることを意味します。数分待機した後に再試行します。etcd の再デプロイ後に、コントロールプレーンの新規ロールアウトを強制的に実行します。kubelet が内部ロードバランサーを使用して API サーバーに接続されているため、Kubernetes API サーバーは他のノードに再インストールされます。
クラスターにアクセスできるターミナルで、
cluster-adminユーザーとして以下のコマンドを実行します。Kubernetes API サーバーの新規ロールアウトを強制的に実行します。
$ oc patch kubeapiserver cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=mergeすべてのノードが最新のリビジョンに更新されていることを確認します。
$ oc get kubeapiserver -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'NodeInstallerProgressing状況条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力にはAllNodesAtLatestRevisionが表示されます。AllNodesAtLatestRevision 3 nodes are at revision 7 1- 1
- この例では、最新のリビジョン番号は
7です。
出力に
2 nodes are at revision 6; 1 nodes are at revision 7などの複数のリビジョン番号が含まれる場合、これは更新が依然として進行中であることを意味します。数分待機した後に再試行します。Kubernetes コントローラーマネージャーの新規ロールアウトを強制的に実行します。
$ oc patch kubecontrollermanager cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=mergeすべてのノードが最新のリビジョンに更新されていることを確認します。
$ oc get kubecontrollermanager -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'NodeInstallerProgressing状況条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力にはAllNodesAtLatestRevisionが表示されます。AllNodesAtLatestRevision 3 nodes are at revision 7 1- 1
- この例では、最新のリビジョン番号は
7です。
出力に
2 nodes are at revision 6; 1 nodes are at revision 7などの複数のリビジョン番号が含まれる場合、これは更新が依然として進行中であることを意味します。数分待機した後に再試行します。Kubernetes スケジューラーの新規ロールアウトを強制的に実行します。
$ oc patch kubescheduler cluster -p='{"spec": {"forceRedeploymentReason": "recovery-'"$( date --rfc-3339=ns )"'"}}' --type=mergeすべてのノードが最新のリビジョンに更新されていることを確認します。
$ oc get kubescheduler -o=jsonpath='{range .items[0].status.conditions[?(@.type=="NodeInstallerProgressing")]}{.reason}{"\n"}{.message}{"\n"}'NodeInstallerProgressing状況条件を確認し、すべてのノードが最新のリビジョンであることを確認します。更新が正常に実行されると、この出力にはAllNodesAtLatestRevisionが表示されます。AllNodesAtLatestRevision 3 nodes are at revision 7 1- 1
- この例では、最新のリビジョン番号は
7です。
出力に
2 nodes are at revision 6; 1 nodes are at revision 7などの複数のリビジョン番号が含まれる場合、これは更新が依然として進行中であることを意味します。数分待機した後に再試行します。
すべてのコントロールプレーンホストが起動しており、クラスターに参加していることを確認します。
クラスターにアクセスできるターミナルで、
cluster-adminユーザーとして以下のコマンドを実行します。$ oc -n openshift-etcd get pods -l k8s-app=etcd
出力例
etcd-ip-10-0-143-125.ec2.internal 2/2 Running 0 9h etcd-ip-10-0-154-194.ec2.internal 2/2 Running 0 9h etcd-ip-10-0-173-171.ec2.internal 2/2 Running 0 9h
復元手順の後にすべてのワークロードが通常の動作に戻るようにするには、Kubernetes API 情報を保存している各 Pod を再起動します。これには、ルーター、Operator、サードパーティーコンポーネントなどの OpenShift Container Platform コンポーネントが含まれます。
前の手順が完了したら、すべてのサービスが復元された状態に戻るまで数分間待つ必要がある場合があります。たとえば、oc login を使用した認証は、OAuth サーバー Pod が再起動するまですぐに機能しない可能性があります。
即時認証に system:admin kubeconfig ファイルを使用することを検討してください。この方法は、OAuth トークンではなく SSL/TLS クライアント証明書に基づいて認証を行います。以下のコマンドを実行し、このファイルを使用して認証できます。
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig
以下のコマンドを実行て、認証済みユーザー名を表示します。
$ oc whoami
5.4.2.3. 関連情報
5.4.2.4. 永続ストレージの状態復元に関する問題および回避策
OpenShift Container Platform クラスターがいずれかの形式の永続ストレージを使用する場合に、クラスターの状態は通常 etcd 外に保存されます。たとえば、Pod で実行されている Elasticsearch クラスター、または StatefulSet オブジェクトで実行されているデータベースなどである可能性があります。etcd バックアップから復元する場合には、OpenShift Container Platform のワークロードのステータスも復元されます。ただし、etcd スナップショットが古い場合には、ステータスは無効または期限切れの可能性があります。
永続ボリューム (PV) の内容は etcd スナップショットには含まれません。etcd スナップショットから OpenShift Container Platform クラスターを復元する時に、重要ではないワークロードから重要なデータにアクセスしたり、その逆ができたりする場合があります。
以下は、古いステータスを生成するシナリオ例です。
- MySQL データベースが PV オブジェクトでバックアップされる Pod で実行されている。etcd スナップショットから OpenShift Container Platform を復元すると、Pod の起動を繰り返し試行しても、ボリュームをストレージプロバイダーに戻したり、実行中の MySQL Pod が生成したりされるわけではありません。この Pod は、ストレージプロバイダーでボリュームを復元し、次に PV を編集して新規ボリュームを参照するように手動で復元する必要があります。
- Pod P1 は、ノード X に割り当てられているボリューム A を使用している。別の Pod がノード Y にある同じボリュームを使用している場合に etcd スナップショットが作成された場合に、etcd の復元が実行されると、ボリュームがノード Y に割り当てられていることが原因で Pod P1 が正常に起動できなくなる可能性があります。OpenShift Container Platform はこの割り当てを認識せず、ボリュームが自動的に切り離されるわけではありません。これが生じる場合には、ボリュームをノード Y から手動で切り離し、ノード X に割り当ててることで Pod P1 を起動できるようにします。
- クラウドプロバイダーまたはストレージプロバイダーの認証情報が etcd スナップショットの作成後に更新された。これが原因で、プロバイダーの認証情報に依存する CSI ドライバーまたは Operator が機能しなくなります。これらのドライバーまたは Operator で必要な認証情報を手動で更新する必要がある場合があります。
デバイスが etcd スナップショットの作成後に OpenShift Container Platform ノードから削除されたか、名前が変更された。ローカルストレージ Operator で、
/dev/disk/by-idまたは/devディレクトリーから管理する各 PV のシンボリックリンクが作成されます。この状況では、ローカル PV が存在しないデバイスを参照してしまう可能性があります。この問題を修正するには、管理者は以下を行う必要があります。
- デバイスが無効な PV を手動で削除します。
- 各ノードからシンボリックリンクを削除します。
-
LocalVolumeまたはLocalVolumeSetオブジェクトを削除します (ストレージ → 永続ストレージの設定 → ローカルボリュームを使用した永続ストレージ → ローカルストレージ Operator のリソースの削除 を参照)。
5.4.3. コントロールプレーン証明書の期限切れの状態からのリカバリー
5.4.3.1. コントロールプレーン証明書の期限切れの状態からのリカバリー
クラスターはコントロールプレーン証明書の期限切れの状態から自動的に回復できます。
ただし、kubelet 証明書を回復するために保留状態の node-bootstrapper 証明書署名要求 (CSR) を手動で承認する必要があります。ユーザーによってプロビジョニングされるインストールの場合は、保留中の kubelet 提供の CSR を承認しないといけない場合があります。
保留中の CSR を承認するには、以下の手順に従います。
手順
現在の CSR の一覧を取得します。
$ oc get csr
出力例
NAME AGE SIGNERNAME REQUESTOR CONDITION csr-2s94x 8m3s kubernetes.io/kubelet-serving system:node:<node_name> Pending 1 csr-4bd6t 8m3s kubernetes.io/kubelet-serving system:node:<node_name> Pending csr-4hl85 13m kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending 2 csr-zhhhp 3m8s kubernetes.io/kube-apiserver-client-kubelet system:serviceaccount:openshift-machine-config-operator:node-bootstrapper Pending ...
CSR の詳細をレビューし、これが有効であることを確認します。
$ oc describe csr <csr_name> 1- 1
<csr_name>は、現行の CSR の一覧からの CSR の名前です。
それぞれの有効な
node-bootstrapperCSR を承認します。$ oc adm certificate approve <csr_name>
ユーザーによってプロビジョニングされるインストールの場合は、それぞれの有効な kubelet 提供の CSR を承認します。
$ oc adm certificate approve <csr_name>
5.4.4. AWS リージョン内のホストされたクラスターの障害復旧
ホストされたクラスターの障害復旧 (DR) が必要な状況では、ホストされたクラスターを AWS 内の同じリージョンに回復できます。たとえば、管理クラスターのアップグレードが失敗し、ホストされているクラスターが読み取り専用状態になっている場合、DR が必要です。
ホストされたコントロールプレーンは、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
DR プロセスには、次の 3 つの主要な手順が含まれます。
- ソース管理クラスターでのホストされたクラスターのバックアップ
- 宛先管理クラスターでのホストされたクラスターの復元
- ホストされたクラスターのソース管理クラスターからの削除
プロセス中、ワークロードは引き続き実行されます。クラスター API は一定期間使用できない場合がありますが、ワーカーノードで実行されているサービスには影響しません。
次の例に示すように、ソース管理クラスターと宛先管理クラスターの両方に --external-dns フラグを設定して、API サーバー URL を維持する必要があります。
例: 外部 DNS フラグ
--external-dns-provider=aws \ --external-dns-credentials=<AWS Credentials location> \ --external-dns-domain-filter=<DNS Base Domain>
これにより、サーバー URL は https://api-sample-hosted.sample-hosted.aws.openshift.com で終わります。
API サーバー URL を維持するために --external-dns フラグを含めない場合、ホストされたクラスターを移行することはできません。
5.4.4.1. 環境とコンテキストの例
復元するクラスターが 3 つあるシナリオを考えてみます。2 つは管理クラスターで、1 つはホストされたクラスターです。コントロールプレーンのみ、またはコントロールプレーンとノードのいずれかを復元できます。開始する前に、以下の情報が必要です。
- ソース MGMT namespace: ソース管理 namespace
- ソース MGMT ClusterName: ソース管理クラスター名
-
ソース MGMT Kubeconfig: ソース管理
kubeconfigファイル -
宛先 MGMT Kubeconfig: 宛先管理
kubeconfigファイル -
HC Kubeconfig: ホストされたクラスターの
kubeconfigファイル - SSH 鍵ファイル: SSH 公開鍵
- プルシークレット: リリースイメージにアクセスするためのプルシークレットファイル
- AWS 認証情報
- AWS region
- ベースドメイン: 外部 DNS として使用する DNS ベースドメイン
- S3 バケット名: etcd バックアップをアップロードする予定の AWS リージョンのバケット
この情報は、次の環境変数の例に示されています。
環境変数の例
SSH_KEY_FILE=${HOME}/.ssh/id_rsa.pub
BASE_PATH=${HOME}/hypershift
BASE_DOMAIN="aws.sample.com"
PULL_SECRET_FILE="${HOME}/pull_secret.json"
AWS_CREDS="${HOME}/.aws/credentials"
AWS_ZONE_ID="Z02718293M33QHDEQBROL"
CONTROL_PLANE_AVAILABILITY_POLICY=SingleReplica
HYPERSHIFT_PATH=${BASE_PATH}/src/hypershift
HYPERSHIFT_CLI=${HYPERSHIFT_PATH}/bin/hypershift
HYPERSHIFT_IMAGE=${HYPERSHIFT_IMAGE:-"quay.io/${USER}/hypershift:latest"}
NODE_POOL_REPLICAS=${NODE_POOL_REPLICAS:-2}
# MGMT Context
MGMT_REGION=us-west-1
MGMT_CLUSTER_NAME="${USER}-dev"
MGMT_CLUSTER_NS=${USER}
MGMT_CLUSTER_DIR="${BASE_PATH}/hosted_clusters/${MGMT_CLUSTER_NS}-${MGMT_CLUSTER_NAME}"
MGMT_KUBECONFIG="${MGMT_CLUSTER_DIR}/kubeconfig"
# MGMT2 Context
MGMT2_CLUSTER_NAME="${USER}-dest"
MGMT2_CLUSTER_NS=${USER}
MGMT2_CLUSTER_DIR="${BASE_PATH}/hosted_clusters/${MGMT2_CLUSTER_NS}-${MGMT2_CLUSTER_NAME}"
MGMT2_KUBECONFIG="${MGMT2_CLUSTER_DIR}/kubeconfig"
# Hosted Cluster Context
HC_CLUSTER_NS=clusters
HC_REGION=us-west-1
HC_CLUSTER_NAME="${USER}-hosted"
HC_CLUSTER_DIR="${BASE_PATH}/hosted_clusters/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}"
HC_KUBECONFIG="${HC_CLUSTER_DIR}/kubeconfig"
BACKUP_DIR=${HC_CLUSTER_DIR}/backup
BUCKET_NAME="${USER}-hosted-${MGMT_REGION}"
# DNS
AWS_ZONE_ID="Z07342811SH9AA102K1AC"
EXTERNAL_DNS_DOMAIN="hc.jpdv.aws.kerbeross.com"
5.4.4.2. バックアップおよび復元プロセスの概要
バックアップと復元のプロセスは、以下のような仕組みとなっています。
管理クラスター 1 (ソース管理クラスターと見なすことができます) では、コントロールプレーンとワーカーが 外部 DNS API を使用して対話します。外部 DNS API はアクセス可能で、管理クラスター間にロードバランサーが配置されています。

ホストされたクラスターのスナップショットを作成します。これには、etcd、コントロールプレーン、およびワーカーノードが含まれます。このプロセスの間、ワーカーノードは外部 DNS API にアクセスできなくても引き続きアクセスを試みます。また、ワークロードが実行され、コントロールプレーンがローカルマニフェストファイルに保存され、etcd が S3 バケットにバックアップされます。データプレーンはアクティブで、コントロールプレーンは一時停止しています。

管理クラスター 2 (宛先管理クラスターと見なすことができます) では、S3 バケットから etcd を復元し、ローカルマニフェストファイルからコントロールプレーンを復元します。このプロセスの間、外部 DNS API は停止し、ホストされたクラスター API にアクセスできなくなり、API を使用するワーカーはマニフェストファイルを更新できなくなりますが、ワークロードは引き続き実行されます。

外部 DNS API に再びアクセスできるようになり、ワーカーノードはそれを使用して管理クラスター 2 に移動します。外部 DNS API は、コントロールプレーンを参照するロードバランサーにアクセスできます。

管理クラスター 2 では、コントロールプレーンとワーカーノードが外部 DNS API を使用して対話します。リソースは、etcd の S3 バックアップを除いて、管理クラスター 1 から削除されます。ホストされたクラスターを管理クラスター 1 で再度設定しようとしても、機能しません。

ホストされたクラスターを手動でバックアップおよび復元するか、スクリプトを実行してプロセスを完了することができます。スクリプトの詳細については、「ホストされたクラスターをバックアップおよび復元するためのスクリプトの実行」を参照してください。
5.4.4.3. ホストされたクラスターのバックアップ
ターゲット管理クラスターでホストされたクラスターを復元するには、最初にすべての関連データをバックアップする必要があります。
手順
以下のコマンドを入力して、configmap ファイルを作成し、ソース管理クラスターを宣言します。
$ oc create configmap mgmt-parent-cluster -n default --from-literal=from=${MGMT_CLUSTER_NAME}以下のコマンドを入力して、ホストされたクラスターとノードプールの調整をシャットダウンします。
PAUSED_UNTIL="true" oc patch -n ${HC_CLUSTER_NS} hostedclusters/${HC_CLUSTER_NAME} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 kube-apiserver openshift-apiserver openshift-oauth-apiserver control-plane-operatorPAUSED_UNTIL="true" oc patch -n ${HC_CLUSTER_NS} hostedclusters/${HC_CLUSTER_NAME} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge oc patch -n ${HC_CLUSTER_NS} nodepools/${NODEPOOLS} -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 kube-apiserver openshift-apiserver openshift-oauth-apiserver control-plane-operator以下の bash スクリプトを実行して、etcd をバックアップし、データを S3 バケットにアップロードします。
ヒントこのスクリプトを関数でラップし、メイン関数から呼び出します。
# ETCD Backup ETCD_PODS="etcd-0" if [ "${CONTROL_PLANE_AVAILABILITY_POLICY}" = "HighlyAvailable" ]; then ETCD_PODS="etcd-0 etcd-1 etcd-2" fi for POD in ${ETCD_PODS}; do # Create an etcd snapshot oc exec -it ${POD} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -- env ETCDCTL_API=3 /usr/bin/etcdctl --cacert /etc/etcd/tls/client/etcd-client-ca.crt --cert /etc/etcd/tls/client/etcd-client.crt --key /etc/etcd/tls/client/etcd-client.key --endpoints=localhost:2379 snapshot save /var/lib/data/snapshot.db oc exec -it ${POD} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -- env ETCDCTL_API=3 /usr/bin/etcdctl -w table snapshot status /var/lib/data/snapshot.db FILEPATH="/${BUCKET_NAME}/${HC_CLUSTER_NAME}-${POD}-snapshot.db" CONTENT_TYPE="application/x-compressed-tar" DATE_VALUE=`date -R` SIGNATURE_STRING="PUT\n\n${CONTENT_TYPE}\n${DATE_VALUE}\n${FILEPATH}" set +x ACCESS_KEY=$(grep aws_access_key_id ${AWS_CREDS} | head -n1 | cut -d= -f2 | sed "s/ //g") SECRET_KEY=$(grep aws_secret_access_key ${AWS_CREDS} | head -n1 | cut -d= -f2 | sed "s/ //g") SIGNATURE_HASH=$(echo -en ${SIGNATURE_STRING} | openssl sha1 -hmac "${SECRET_KEY}" -binary | base64) set -x # FIXME: this is pushing to the OIDC bucket oc exec -it etcd-0 -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -- curl -X PUT -T "/var/lib/data/snapshot.db" \ -H "Host: ${BUCKET_NAME}.s3.amazonaws.com" \ -H "Date: ${DATE_VALUE}" \ -H "Content-Type: ${CONTENT_TYPE}" \ -H "Authorization: AWS ${ACCESS_KEY}:${SIGNATURE_HASH}" \ https://${BUCKET_NAME}.s3.amazonaws.com/${HC_CLUSTER_NAME}-${POD}-snapshot.db doneetcd のバックアップの詳細については、「ホストされたクラスターでの etcd のバックアップと復元」を参照してください。
以下のコマンドを入力して、Kubernetes および OpenShift Container Platform オブジェクトをバックアップします。次のオブジェクトをバックアップする必要があります。
-
HostedCluster namespace の
HostedClusterおよびNodePoolオブジェクト -
HostedCluster namespace の
HostedClusterシークレット -
Hosted Control Plane namespace の
HostedControlPlane -
Hosted Control Plane namespace の
Cluster -
Hosted Control Plane namespace の
AWSCluster、AWSMachineTemplate、およびAWSMachine -
Hosted Control Plane namespace の
MachineDeployments、MachineSets、およびMachines Hosted Control Plane namespace の
ControlPlaneシークレットmkdir -p ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS} ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} chmod 700 ${BACKUP_DIR}/namespaces/ # HostedCluster echo "Backing Up HostedCluster Objects:" oc get hc ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}.yaml echo "--> HostedCluster" sed -i '' -e '/^status:$/,$d' ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}.yaml # NodePool oc get np ${NODEPOOLS} -n ${HC_CLUSTER_NS} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-${NODEPOOLS}.yaml echo "--> NodePool" sed -i '' -e '/^status:$/,$ d' ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-${NODEPOOLS}.yaml # Secrets in the HC Namespace echo "--> HostedCluster Secrets:" for s in $(oc get secret -n ${HC_CLUSTER_NS} | grep "^${HC_CLUSTER_NAME}" | awk '{print $1}'); do oc get secret -n ${HC_CLUSTER_NS} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/secret-${s}.yaml done # Secrets in the HC Control Plane Namespace echo "--> HostedCluster ControlPlane Secrets:" for s in $(oc get secret -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} | egrep -v "docker|service-account-token|oauth-openshift|NAME|token-${HC_CLUSTER_NAME}" | awk '{print $1}'); do oc get secret -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/secret-${s}.yaml done # Hosted Control Plane echo "--> HostedControlPlane:" oc get hcp ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/hcp-${HC_CLUSTER_NAME}.yaml # Cluster echo "--> Cluster:" CL_NAME=$(oc get hcp ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o jsonpath={.metadata.labels.\*} | grep ${HC_CLUSTER_NAME}) oc get cluster ${CL_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/cl-${HC_CLUSTER_NAME}.yaml # AWS Cluster echo "--> AWS Cluster:" oc get awscluster ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awscl-${HC_CLUSTER_NAME}.yaml # AWS MachineTemplate echo "--> AWS Machine Template:" oc get awsmachinetemplate ${NODEPOOLS} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsmt-${HC_CLUSTER_NAME}.yaml # AWS Machines echo "--> AWS Machine:" CL_NAME=$(oc get hcp ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o jsonpath={.metadata.labels.\*} | grep ${HC_CLUSTER_NAME}) for s in $(oc get awsmachines -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --no-headers | grep ${CL_NAME} | cut -f1 -d\ ); do oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} awsmachines $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsm-${s}.yaml done # MachineDeployments echo "--> HostedCluster MachineDeployments:" for s in $(oc get machinedeployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do mdp_name=$(echo ${s} | cut -f 2 -d /) oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machinedeployment-${mdp_name}.yaml done # MachineSets echo "--> HostedCluster MachineSets:" for s in $(oc get machineset -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do ms_name=$(echo ${s} | cut -f 2 -d /) oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machineset-${ms_name}.yaml done # Machines echo "--> HostedCluster Machine:" for s in $(oc get machine -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do m_name=$(echo ${s} | cut -f 2 -d /) oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machine-${m_name}.yaml done
-
HostedCluster namespace の
次のコマンドを入力して、
ControlPlaneルートをクリーンアップします。$ oc delete routes -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --allこのコマンドを入力すると、ExternalDNS Operator が Route53 エントリーを削除できるようになります。
次のスクリプトを実行して、Route53 エントリーがクリーンであることを確認します。
function clean_routes() { if [[ -z "${1}" ]];then echo "Give me the NS where to clean the routes" exit 1 fi # Constants if [[ -z "${2}" ]];then echo "Give me the Route53 zone ID" exit 1 fi ZONE_ID=${2} ROUTES=10 timeout=40 count=0 # This allows us to remove the ownership in the AWS for the API route oc delete route -n ${1} --all while [ ${ROUTES} -gt 2 ] do echo "Waiting for ExternalDNS Operator to clean the DNS Records in AWS Route53 where the zone id is: ${ZONE_ID}..." echo "Try: (${count}/${timeout})" sleep 10 if [[ $count -eq timeout ]];then echo "Timeout waiting for cleaning the Route53 DNS records" exit 1 fi count=$((count+1)) ROUTES=$(aws route53 list-resource-record-sets --hosted-zone-id ${ZONE_ID} --max-items 10000 --output json | grep -c ${EXTERNAL_DNS_DOMAIN}) done } # SAMPLE: clean_routes "<HC ControlPlane Namespace>" "<AWS_ZONE_ID>" clean_routes "${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}" "${AWS_ZONE_ID}"
検証
すべての OpenShift Container Platform オブジェクトと S3 バケットをチェックし、すべてが想定どおりであることを確認します。
次のステップ
ホストされたクラスターを復元します。
5.4.4.4. ホストされたクラスターの復元
バックアップしたすべてのオブジェクトを収集し、宛先管理クラスターに復元します。
前提条件
ソース管理クラスターからデータをバックアップしている。
宛先管理クラスターの kubeconfig ファイルが、KUBECONFIG 変数に設定されているとおりに、あるいは、スクリプトを使用する場合は MGMT2_KUBECONFIG 変数に設定されているとおりに配置されていることを確認します。export KUBECONFIG=<Kubeconfig FilePath> を使用するか、スクリプトを使用する場合は export KUBECONFIG=${MGMT2_KUBECONFIG} を使用します。
手順
以下のコマンドを入力して、新しい管理クラスターに、復元するクラスターの namespace が含まれていないことを確認します。
# Just in case export KUBECONFIG=${MGMT2_KUBECONFIG} BACKUP_DIR=${HC_CLUSTER_DIR}/backup # Namespace deletion in the destination Management cluster $ oc delete ns ${HC_CLUSTER_NS} || true $ oc delete ns ${HC_CLUSTER_NS}-{HC_CLUSTER_NAME} || true以下のコマンドを入力して、削除された namespace を再作成します。
# Namespace creation $ oc new-project ${HC_CLUSTER_NS} $ oc new-project ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}次のコマンドを入力して、HC namespace のシークレットを復元します。
$ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/secret-*以下のコマンドを入力して、
HostedClusterコントロールプレーン namespace のオブジェクトを復元します。# Secrets $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/secret-* # Cluster $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/hcp-* $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/cl-*ノードとノードプールを復元して AWS インスタンスを再利用する場合は、次のコマンドを入力して、HC コントロールプレーン namespace のオブジェクトを復元します。
# AWS $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awscl-* $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsmt-* $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsm-* # Machines $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machinedeployment-* $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machineset-* $ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machine-*次の bash スクリプトを実行して、etcd データとホストされたクラスターを復元します。
ETCD_PODS="etcd-0" if [ "${CONTROL_PLANE_AVAILABILITY_POLICY}" = "HighlyAvailable" ]; then ETCD_PODS="etcd-0 etcd-1 etcd-2" fi HC_RESTORE_FILE=${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}-restore.yaml HC_BACKUP_FILE=${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}.yaml HC_NEW_FILE=${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}-new.yaml cat ${HC_BACKUP_FILE} > ${HC_NEW_FILE} cat > ${HC_RESTORE_FILE} <<EOF restoreSnapshotURL: EOF for POD in ${ETCD_PODS}; do # Create a pre-signed URL for the etcd snapshot ETCD_SNAPSHOT="s3://${BUCKET_NAME}/${HC_CLUSTER_NAME}-${POD}-snapshot.db" ETCD_SNAPSHOT_URL=$(AWS_DEFAULT_REGION=${MGMT2_REGION} aws s3 presign ${ETCD_SNAPSHOT}) # FIXME no CLI support for restoreSnapshotURL yet cat >> ${HC_RESTORE_FILE} <<EOF - "${ETCD_SNAPSHOT_URL}" EOF done cat ${HC_RESTORE_FILE} if ! grep ${HC_CLUSTER_NAME}-snapshot.db ${HC_NEW_FILE}; then sed -i '' -e "/type: PersistentVolume/r ${HC_RESTORE_FILE}" ${HC_NEW_FILE} sed -i '' -e '/pausedUntil:/d' ${HC_NEW_FILE} fi HC=$(oc get hc -n ${HC_CLUSTER_NS} ${HC_CLUSTER_NAME} -o name || true) if [[ ${HC} == "" ]];then echo "Deploying HC Cluster: ${HC_CLUSTER_NAME} in ${HC_CLUSTER_NS} namespace" oc apply -f ${HC_NEW_FILE} else echo "HC Cluster ${HC_CLUSTER_NAME} already exists, avoiding step" fiノードとノードプールを復元して AWS インスタンスを再利用する場合は、次のコマンドを入力してノードプールを復元します。
oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-*
検証
ノードが完全に復元されたことを確認するには、次の関数を使用します。
timeout=40 count=0 NODE_STATUS=$(oc get nodes --kubeconfig=${HC_KUBECONFIG} | grep -v NotReady | grep -c "worker") || NODE_STATUS=0 while [ ${NODE_POOL_REPLICAS} != ${NODE_STATUS} ] do echo "Waiting for Nodes to be Ready in the destination MGMT Cluster: ${MGMT2_CLUSTER_NAME}" echo "Try: (${count}/${timeout})" sleep 30 if [[ $count -eq timeout ]];then echo "Timeout waiting for Nodes in the destination MGMT Cluster" exit 1 fi count=$((count+1)) NODE_STATUS=$(oc get nodes --kubeconfig=${HC_KUBECONFIG} | grep -v NotReady | grep -c "worker") || NODE_STATUS=0 done
次のステップ
クラスターをシャットダウンして削除します。
5.4.4.5. ホストされたクラスターのソース管理クラスターからの削除
ホストされたクラスターをバックアップして宛先管理クラスターに復元した後、ソース管理クラスターのホストされたクラスターをシャットダウンして削除します。
前提条件
データをバックアップし、ソース管理クラスターに復元している。
宛先管理クラスターの kubeconfig ファイルが、KUBECONFIG 変数に設定されているとおりに、あるいは、スクリプトを使用する場合は MGMT_KUBECONFIG 変数に設定されているとおりに配置されていることを確認します。export KUBECONFIG=<Kubeconfig FilePath> を使用するか、スクリプトを使用する場合は export KUBECONFIG=${MGMT_KUBECONFIG} を使用します。
手順
以下のコマンドを入力して、
deploymentおよびstatefulsetオブジェクトをスケーリングします。# Just in case export KUBECONFIG=${MGMT_KUBECONFIG} # Scale down deployments oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 --all oc scale statefulset.apps -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 --all sleep 15次のコマンドを入力して、
NodePoolオブジェクトを削除します。NODEPOOLS=$(oc get nodepools -n ${HC_CLUSTER_NS} -o=jsonpath='{.items[?(@.spec.clusterName=="'${HC_CLUSTER_NAME}'")].metadata.name}') if [[ ! -z "${NODEPOOLS}" ]];then oc patch -n "${HC_CLUSTER_NS}" nodepool ${NODEPOOLS} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' oc delete np -n ${HC_CLUSTER_NS} ${NODEPOOLS} fi次のコマンドを入力して、
machineおよびmachinesetオブジェクトを削除します。# Machines for m in $(oc get machines -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' || true oc delete -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} || true done oc delete machineset -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all || true次のコマンドを入力して、クラスターオブジェクトを削除します。
# Cluster C_NAME=$(oc get cluster -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name) oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${C_NAME} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' oc delete cluster.cluster.x-k8s.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all次のコマンドを入力して、AWS マシン (Kubernetes オブジェクト) を削除します。実際の AWS マシンの削除について心配する必要はありません。クラウドインスタンスへの影響はありません。
# AWS Machines for m in $(oc get awsmachine.infrastructure.cluster.x-k8s.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name) do oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' || true oc delete -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} || true done次のコマンドを入力して、
HostedControlPlaneおよびControlPlaneHC namespace オブジェクトを削除します。# Delete HCP and ControlPlane HC NS oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} hostedcontrolplane.hypershift.openshift.io ${HC_CLUSTER_NAME} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' oc delete hostedcontrolplane.hypershift.openshift.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all oc delete ns ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} || true次のコマンドを入力して、
HostedClusterおよび HC namespace オブジェクトを削除します。# Delete HC and HC Namespace oc -n ${HC_CLUSTER_NS} patch hostedclusters ${HC_CLUSTER_NAME} -p '{"metadata":{"finalizers":null}}' --type merge || true oc delete hc -n ${HC_CLUSTER_NS} ${HC_CLUSTER_NAME} || true oc delete ns ${HC_CLUSTER_NS} || true
検証
すべてが機能することを確認するには、次のコマンドを入力します。
# Validations export KUBECONFIG=${MGMT2_KUBECONFIG} oc get hc -n ${HC_CLUSTER_NS} oc get np -n ${HC_CLUSTER_NS} oc get pod -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} oc get machines -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} # Inside the HostedCluster export KUBECONFIG=${HC_KUBECONFIG} oc get clusterversion oc get nodes
次のステップ
ホストされたクラスター内の OVN Pod を削除して、新しい管理クラスターで実行される新しい OVN コントロールプレーンに接続できるようにします。
-
ホストされたクラスターの kubeconfig パスを使用して
KUBECONFIG環境変数を読み込みます。 以下のコマンドを入力します。
$ oc delete pod -n openshift-ovn-kubernetes --all
5.4.4.6. ホストされたクラスターをバックアップおよび復元するためのスクリプトの実行
ホストされたクラスターをバックアップし、AWS の同じリージョン内で復元するプロセスを迅速化するために、スクリプトを修正して実行できます。
手順
次のスクリプトの変数を独自の情報に置き換えます。
# Fill the Common variables to fit your environment, this is just a sample SSH_KEY_FILE=${HOME}/.ssh/id_rsa.pub BASE_PATH=${HOME}/hypershift BASE_DOMAIN="aws.sample.com" PULL_SECRET_FILE="${HOME}/pull_secret.json" AWS_CREDS="${HOME}/.aws/credentials" CONTROL_PLANE_AVAILABILITY_POLICY=SingleReplica HYPERSHIFT_PATH=${BASE_PATH}/src/hypershift HYPERSHIFT_CLI=${HYPERSHIFT_PATH}/bin/hypershift HYPERSHIFT_IMAGE=${HYPERSHIFT_IMAGE:-"quay.io/${USER}/hypershift:latest"} NODE_POOL_REPLICAS=${NODE_POOL_REPLICAS:-2} # MGMT Context MGMT_REGION=us-west-1 MGMT_CLUSTER_NAME="${USER}-dev" MGMT_CLUSTER_NS=${USER} MGMT_CLUSTER_DIR="${BASE_PATH}/hosted_clusters/${MGMT_CLUSTER_NS}-${MGMT_CLUSTER_NAME}" MGMT_KUBECONFIG="${MGMT_CLUSTER_DIR}/kubeconfig" # MGMT2 Context MGMT2_CLUSTER_NAME="${USER}-dest" MGMT2_CLUSTER_NS=${USER} MGMT2_CLUSTER_DIR="${BASE_PATH}/hosted_clusters/${MGMT2_CLUSTER_NS}-${MGMT2_CLUSTER_NAME}" MGMT2_KUBECONFIG="${MGMT2_CLUSTER_DIR}/kubeconfig" # Hosted Cluster Context HC_CLUSTER_NS=clusters HC_REGION=us-west-1 HC_CLUSTER_NAME="${USER}-hosted" HC_CLUSTER_DIR="${BASE_PATH}/hosted_clusters/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}" HC_KUBECONFIG="${HC_CLUSTER_DIR}/kubeconfig" BACKUP_DIR=${HC_CLUSTER_DIR}/backup BUCKET_NAME="${USER}-hosted-${MGMT_REGION}" # DNS AWS_ZONE_ID="Z026552815SS3YPH9H6MG" EXTERNAL_DNS_DOMAIN="guest.jpdv.aws.kerbeross.com"- スクリプトをローカルファイルシステムに保存します。
次のコマンドを入力して、スクリプトを実行します。
source <env_file>
ここの
env_fileは、スクリプトを保存したファイルの名前になります。移行スクリプトは、https://github.com/openshift/hypershift/blob/main/contrib/migration/migrate-hcp.sh のリポジトリーで管理されています。