バックアップおよび復元
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 バックアップを作成します。
重要クラスターの再起動時に問題が発生した場合にクラスターを復元できるように、この手順を実行する前に etcd バックアップを作成しておくことは重要です。
たとえば、次の条件により、再起動したクラスターが誤動作する可能性があります。
- シャットダウン時の etcd データの破損
- ハードウェアが原因のノード障害
- ネットワーク接続の問題
クラスターが回復しない場合は、クラスターの以前の状態に復元する手順を実行します。
2.2. クラスターのシャットダウン
クラスターを正常な状態でシャットダウンし、後で再起動できるようにします。
インストール日から 1 年までクラスターをシャットダウンして、正常に再起動することを期待できます。インストール日から 1 年後に、クラスター証明書が期限切れになります。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - etcd のバックアップを取得している。
手順
クラスターを長期間シャットダウンする場合は、証明書の有効期限が切れる日付を確認し、次のコマンドを実行します。
$ oc -n openshift-kube-apiserver-operator get secret kube-apiserver-to-kubelet-signer -o jsonpath='{.metadata.annotations.auth\.openshift\.io/certificate-not-after}'
出力例
2022-08-05T14:37:50Zuser@user:~ $ 1
- 1
- クラスターが正常に再起動できるようにするために、指定の日付または指定の日付の前に再起動するように計画します。クラスターの再起動時に、kubelet 証明書を回復するために保留中の証明書署名要求 (CSR) を手動で承認する必要がある場合があります。
クラスター内のすべてのノードをスケジュール不可としてマークします。クラウドプロバイダーの Web コンソールから、または次のループを実行することでマークできます。
$ for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do echo ${node} ; oc adm cordon ${node} ; done
出力例
ci-ln-mgdnf4b-72292-n547t-master-0 node/ci-ln-mgdnf4b-72292-n547t-master-0 cordoned ci-ln-mgdnf4b-72292-n547t-master-1 node/ci-ln-mgdnf4b-72292-n547t-master-1 cordoned ci-ln-mgdnf4b-72292-n547t-master-2 node/ci-ln-mgdnf4b-72292-n547t-master-2 cordoned ci-ln-mgdnf4b-72292-n547t-worker-a-s7ntl node/ci-ln-mgdnf4b-72292-n547t-worker-a-s7ntl cordoned ci-ln-mgdnf4b-72292-n547t-worker-b-cmc9k node/ci-ln-mgdnf4b-72292-n547t-worker-b-cmc9k cordoned ci-ln-mgdnf4b-72292-n547t-worker-c-vcmtn node/ci-ln-mgdnf4b-72292-n547t-worker-c-vcmtn cordoned
次の方法を使用して Pod を退避させます。
$ for node in $(oc get nodes -l node-role.kubernetes.io/worker -o jsonpath='{.items[*].metadata.name}'); do echo ${node} ; oc adm drain ${node} --delete-emptydir-data --ignore-daemonsets=true --timeout=15s ; done
クラスターのすべてのノードをシャットダウンします。クラウドプロバイダーの Web コンソールから、または次のループを実行することでマークできます。
$ for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do oc debug node/${node} -- chroot /host shutdown -h 1; done
出力例
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 バックアップを使用してクラスターを復元する必要がある場合があります。
コントロールプレーンとワーカーノードの準備ができたら、クラスター内のすべてのノードをスケジュール可能としてマークします。以下のコマンドを実行します。
for node in $(oc get nodes -o jsonpath='{.items[*].metadata.name}'); do echo ${node} ; oc adm uncordon ${node} ; done
関連情報
- クラスターが再起動後に回復しない場合に etcd バックアップを使用して復元する方法は、クラスターの直前の状態への復元を参照してください。
第4章 OADP アプリケーションのバックアップと復元
4.1. OpenShift API for Data Protection の概要
OpenShift API for Data Protection (OADP) 製品は、OpenShift Container Platform 上のお客様のアプリケーションを保護します。この製品は、OpenShift Container Platform のアプリケーション、アプリケーション関連のクラスターリソース、永続ボリューム、内部イメージをカバーする包括的な障害復旧保護を提供します。OADP は、コンテナー化されたアプリケーションと仮想マシン (VM) の両方をバックアップすることもできます。
ただし、OADP は etcd または OpenShift Operator の障害復旧ソリューションとしては機能しません。
OADP サポートは、お客様のワークロードの namespace とクラスタースコープのリソースに提供されます。
完全なクラスターの バックアップ と 復元 はサポートされていません。
4.1.1. OpenShift API for Data Protection API
OpenShift API for Data Protection (OADP) は、バックアップをカスタマイズし、不要または不適切なリソースの組み込みを防止するための複数のアプローチを可能にする API を提供します。
OADP は次の API を提供します。
関連情報
4.2. OADP リリースノート
4.2.1. OADP 1.3 リリースノート
OpenShift API for Data Protection (OADP) のリリースノートでは、新機能と拡張機能、非推奨の機能、製品の推奨事項、既知の問題、および解決された問題を説明します。
4.2.1.1. OADP 1.4.0 リリースノート
OpenShift API for Data Protection (OADP) 1.3.3 リリースノートには、解決された問題と既知の問題が記載されています。
4.2.1.1.1. 解決した問題
バックアップの spec.resourcepolicy.kind パラメーターは、大文字と小文字が区別されなくなりました。
以前は、バックアップの spec.resourcepolicy.kind
パラメーターは、下位レベルの文字列でのみサポートされていました。今回の修正により、大文字と小文字が区別されなくなりました。OADP-3922
olm.maxOpenShiftVersion を使用して OCP 4.16 バージョンにアップグレードされないようにする
クラスターの operator-lifecycle-manager
Operator は、OpenShift Container Platform のマイナーバージョン間でアップグレードすることはできません。olm.maxOpenShiftVersion
パラメーターを使用すると、OADP 1.3 がインストールされている場合に OpenShift Container Platform 4.16 バージョンにアップグレードできなくなります。OpenShift Container Platform 4.16 バージョンにアップグレードするには、OCP 4.15 バージョンで OADP 1.3 を OADP 1.4 にアップグレードします。OADP-4803
BSL および VSL がクラスターから削除される
以前は、backupLocations
または snapshotLocations セクションから Backup Storage Locations (BSL)またはボリューム スナップショット
の場所(VSL)を削除するようにデータ保護アプリケーション(DPA)を変更すると、DPA が削除されるまでクラスターから BSL または VSL が削除されませんでした。今回の更新により、BSL/VSL がクラスターから削除されるようになりました。OADP-3050
DPA は秘密鍵を調整し、検証します。
以前は、データ保護アプリケーション(DPA)が間違ったボリュームスナップショットの場所(VSL)の秘密鍵名で正常に調整されていました。今回の更新により、DPA は、VSL を調整する前に秘密鍵名を検証します。OADP-3922
Velero のクラウド認証情報のパーミッションが制限されるようになりました
以前は、Velero のクラウド認証情報権限が 0644 権限でマウントされていました。その結果、所有者やグループとは別に /credentials/cloud
ファイルを読み取ることができ、ストレージアクセスキーなどの機密情報へのアクセスが容易になります。今回の更新では、このファイルの権限が 0640 に更新され、owner と group 以外の他のユーザーがこのファイルにアクセスできなくなりました。
ArgoCD 管理 namespace がバックアップに含まれると警告が表示される
ArgoCD と Velero が同じ namespace を管理する場合、バックアップ操作中に警告が表示されます。OADP-3922
このリリースに含まれるセキュリティー修正のリストは RHSA-2024:4982 アドバイザリーに記載されています。
このリリースで解決されたすべての問題のリストは、Jira の OADP 1.4.1 の解決済みの問題 を参照してください。
4.2.1.1.2. 既知の問題
OADP を復元した後に Cassandra アプリケーション Pod が CrashLoopBackoff
ステータスになる
OADP が復元されると、Cassandra アプリケーション Pod が CrashLoopBackoff
ステータスになる可能性があります。この問題を回避するには、OADP を復元した後、エラーまたは CrashLoopBackOff
状態を返す StatefulSet
Pod を削除します。StatefulSet
コントローラーがこれらの Pod を再作成し、正常に動作するようになります。OADP-3767
defaultVolumesToFSBackup フラグと defaultVolumesToFsBackup フラグが同じではない
dpa.spec.configuration.velero.defaultVolumesToFSBackup
フラグは backup.spec.defaultVolumesToFsBackup
フラグと同じではないため、混乱を招く可能性があります。OADP-3692
PodVolumeRestore は、復元が失敗としてマークされている場合でも機能します
podvolumerestore
は、復元が失敗としてマークされている場合でもデータ転送を続行します。OADP-3922
Velero は initContainer 仕様の復元をスキップできない
Velero は、restore-wait の init コンテナーが必要ないにもかかわらず、復元待ちの init
コンテナーを復元する場合があります。OADP-3759
4.2.1.2. OADP 1.3.3 リリースノート
OpenShift API for Data Protection (OADP) 1.3.3 リリースノートには、解決された問題と既知の問題が記載されています。
4.2.1.2.1. 解決した問題
namespace 名が 37 文字を超えると OADP が失敗する
37 文字を超える文字を含む namespace に OADP Operator をインストールし、新しい DPA を作成すると、cloud-credentials
シークレットのラベル付けに失敗します。このリリースでは、この問題が修正されています。OADP-4211
OADP image PullPolicy を Always
に設定
OADP の以前のバージョンでは、adp-controller-manager および Velero Pod の image PullPolicy が Always
に設定されていました。これは、レジストリーにネットワーク帯域幅が制限されている可能性があるエッジシナリオで問題があり、Pod の再起動後にリカバリー時間が遅くなることがありました。OADP 1.3.3 では、openshift-adp-controller-manager
および Velero Pod の image PullPolicy は IfNotPresent
に設定されます。
このリリースに含まれるセキュリティー修正のリストは RHSA-2024:4982 アドバイザリーに記載されています。
このリリースで解決されたすべての問題のリストは、Jira の OADP 1.3.3 の解決済みの問題 のリストを参照してください。
4.2.1.2.2. 既知の問題
OADP を復元した後に Cassandra アプリケーション Pod が CrashLoopBackoff
ステータスになる
OADP が復元されると、Cassandra アプリケーション Pod が CrashLoopBackoff
ステータスになる可能性があります。この問題を回避するには、OADP を復元した後、エラーまたは CrashLoopBackOff
状態を返す StatefulSet
Pod を削除します。StatefulSet
コントローラーがこれらの Pod を再作成し、正常に動作するようになります。
4.2.1.3. OADP 1.3.2 リリースノート
OpenShift API for Data Protection (OADP) 1.3.2 リリースノートには、解決された問題と既知の問題が記載されています。
4.2.1.3.1. 解決した問題
BSL に有効なカスタムシークレットが使用されている場合、DPA は調整に失敗します。
Backup Storage Location (BSL) に有効なカスタムシークレットが使用されているが、デフォルトのシークレットが見つからない場合、DPA は調整に失敗します。回避策は、最初に必要なデフォルトの cloud-credentials
を作成することです。カスタムシークレットが再作成されると、それを使用してその存在を確認できます。
CVE-2023-45290: oadp-velero-container
: Golang net/http
: Request.ParseMultipartForm
でのメモリー不足
net/http
Golang 標準ライブラリーパッケージに不具合が見つかり、OADP の以前のバージョンに影響します。multipart
フォームを解析する場合、明示的に Request.ParseMultipartForm
を使用するか、または暗黙的に Request.FormValue
、Request.PostFormValue
、または Request.FormFile
を使用するかにかかわらず、解析されたフォームの合計サイズの制限は、単一のフォーム行の読み取り中に消費されるメモリーには適用されません。これにより、長い行を含む悪意のある入力により、任意の大量のメモリーが割り当てられ、メモリー不足につながる可能性があります。この不具合は OADP 1.3.2 で解決されました。
詳細は、CVE-2023-45290 を参照してください。
CVE-2023-45289: oadp-velero-container
: Golang net/http/cookiejar
: HTTP リダイレクト時の機密ヘッダーと Cookie の不適切な転送
net/http/cookiejar
Golang 標準ライブラリーパッケージに不具合が見つかり、OADP の以前のバージョンに影響します。 サブドメインが一致しない、または初期ドメインと完全に一致しないドメインへの HTTP リダイレクトに従う場合、http.Client
は Authorization
や Cookie
などの機密ヘッダーを転送しません。悪意を持って作成された HTTP リダイレクトにより、機密ヘッダーが予期せず転送される可能性があります。この不具合は OADP 1.3.2 で解決されました。
詳細は、CVE-2023-45289 を参照してください。
CVE-2024-24783: oadp-velero-container
: Golang crypto/x509
: 不明な公開鍵アルゴリズムを持つ証明書の検証パニック
crypto/x509
Golang 標準ライブラリーパッケージに不具合が見つかり、OADP の以前のバージョンに影響します。不明な公開鍵アルゴリズムを持つ証明書を含む証明書チェーンを検証すると、Certificate.Verify
がパニックになります。これは、Config.ClientAuth
を VerifyClientCertIfGiven
または RequireAndVerifyClientCert
に設定するすべての crypto/tls
クライアントおよびサーバーに影響します。デフォルトの動作では、TLS サーバーはクライアント証明書を検証しません。この不具合は OADP 1.3.2 で解決されました。
詳細は、CVE-2024-24783 を参照してください。
CVE-2024-24784: oadp-velero-plugin-container
: Golang net/mail
: 表示名内のコメントが正しく処理されない
net/mail
Golang 標準ライブラリーパッケージに不具合が見つかり、OADP の以前のバージョンに影響します。ParseAddressList
関数は、コメント、括弧内のテキスト、および表示名を正しく処理しません。これは準拠するアドレスパーサーとの不整合であるため、異なるパーサーを使用するプログラムによって異なる信頼の決定が行われる可能性があります。この不具合は OADP 1.3.2 で解決されました。
詳細は、CVE-2024-24784 を参照してください。
CVE-2024-24785: oadp-velero-container
: Golang: html/template: MarshalJSON
メソッドから返されるエラーにより、テンプレートのエスケープが壊れる可能性がある
html/template
Golang 標準ライブラリーパッケージに不具合が見つかり、OADP の以前のバージョンに影響します。 MarshalJSON
メソッドから返されるエラーにユーザーが制御するデータが含まれている場合、そのエラーは HTML/テンプレートパッケージのコンテキスト自動エスケープ動作の中断に使用される可能性があり、後続のアクションにより、予期しないコンテンツがテンプレートに挿入される可能性があります。 この不具合は OADP 1.3.2 で解決されました。
詳細は、CVE-2024-24785 を参照してください。
このリリースで解決されたすべての問題のリストは、Jira の OADP 1.3.2 の解決済みの問題 のリストを参照してください。
4.2.1.3.2. 既知の問題
OADP を復元した後に Cassandra アプリケーション Pod が CrashLoopBackoff
ステータスになる
OADP が復元されると、Cassandra アプリケーション Pod が CrashLoopBackoff
ステータスになる可能性があります。この問題を回避するには、OADP を復元した後、エラーまたは CrashLoopBackOff
状態を返す StatefulSet
Pod を削除します。StatefulSet
コントローラーがこれらの Pod を再作成し、正常に動作するようになります。
4.2.1.4. OADP 1.3.1 リリースノート
OpenShift API for Data Protection (OADP) 1.3.1 リリースノートには、新機能と解決された問題が記載されています。
4.2.1.4.1. 新機能
OADP 1.3.0 Data Mover が完全にサポートされるようになりました
OADP 1.3.0 でテクノロジープレビューとして導入された OADP 組み込みの Data Mover が、コンテナー化されたワークロードと仮想マシンのワークロードの両方で完全にサポートされるようになりました。
4.2.1.4.2. 解決した問題
IBM Cloud (R) Object Storage がバックアップストレージプロバイダーとしてサポートされるようになりました
IBM Cloud® Object Storage は、これまでサポートされていなかった AWS S3 互換のバックアップストレージプロバイダーの 1 つです。この更新により、IBM Cloud® Object Storage が AWS S3 互換のバックアップストレージプロバイダーとしてサポートされるようになりました。
OADP Operator が missing region エラーを正しく報告するようになりました
以前は、AWS Backup Storage Location (BSL) 設定で region
を指定せずに profile:default
を指定すると、OADP Operator が Data Protection Application (DPA) カスタムリソース (CR) での missing region
エラーを報告できませんでした。この更新により、AWS の DPA BSL 仕様の検証が修正されました。その結果、OADP Operator が missing region
エラーを報告するようになりました。
カスタムラベルが openshift-adp namespace から削除されなくなりました
以前は、openshift-adp-controller-manager
Pod が openshift-adp
namespace に割り当てられたラベルをリセットしていました。これにより、Argo CD などのカスタムラベルを必要とするアプリケーションで同期の問題が発生し、機能が適切に動作しませんでした。この更新により、この問題が修正され、カスタムラベルが openshift-adp
namespace から削除されなくなりました。
OADP must-gather イメージが CRD を収集するようになりました
以前は、OADP must-gather
イメージが、OADP によって提供されるカスタムリソース定義 (CRD) を収集しませんでした。その結果、omg
ツールを使用してサポートシェルでデータを抽出することができませんでした。この修正により、must-gather
イメージが OADP によって提供される CRD を収集し、omg
ツールを使用してデータを抽出できるようになりました。
ガベージコレクションのデフォルト頻度値の記述が修正されました
以前は、garbage-collection-frequency
フィールドのデフォルト頻度値の記述が間違っていました。この更新により、garbage-collection-frequency
の gc-controller
調整のデフォルト頻度値が 1 時間という正しい値になりました。
FIPS モードフラグが OperatorHub で利用可能になりました
fips-compatible
フラグを true
に設定すると、OperatorHub の OADP Operator リストに FIPS モードフラグが追加されます。この機能は OADP 1.3.0 で有効になりましたが、Red Hat Container Catalog には FIPS 対応と表示されていませんでした。
csiSnapshotTimeout を短い期間に設定した場合に nil ポインターによる CSI プラグインのパニックが発生しなくなりました
以前は、csiSnapshotTimeout
パラメーターを短い期間に設定すると、CSI プラグインで plugin panicked: runtime error: invalid memory address or nil pointer dereference
というエラーが発生していました。
この修正により、バックアップが Timed out awaiting reconciliation of volumesnapshot
エラーで失敗するようになりました。
このリリースで解決されたすべての問題のリストは、Jira の OADP 1.3.1 の解決済みの問題 のリストを参照してください。
4.2.1.4.3. 既知の問題
IBM Power (R) および IBM Z(R) プラットフォームにデプロイされたシングルノード OpenShift クラスターのバックアップおよびストレージの制限
IBM Power® および IBM Z® プラットフォームにデプロイされたシングルノード OpenShift クラスターのバックアップおよびストレージ関連の次の制限を確認してください。
- Storage
- 現在、IBM Power® および IBM Z® プラットフォームにデプロイされたシングルノードの OpenShift クラスターと互換性があるのは、NFS ストレージのみです。
- バックアップ
-
バックアップおよび復元操作では、
kopia
やrestic
などのファイルシステムバックアップを使用したアプリケーションのバックアップのみがサポートされます。
OADP を復元した後に Cassandra アプリケーション Pod が CrashLoopBackoff ステータスになる
OADP が復元されると、Cassandra アプリケーション Pod が CrashLoopBackoff
ステータスになる可能性があります。この問題を回避するには、OADP を復元した後、エラーまたは CrashLoopBackoff
状態の StatefulSet
Pod を削除します。StatefulSet
コントローラーがこれらの Pod を再作成し、正常に動作するようになります。
4.2.1.5. OADP 1.3.0 リリースノート
OpenShift API for Data Protection (OADP) 1.3.0 のリリースノートには、新機能、解決された問題とバグ、既知の問題がリストされています。
4.2.1.5.1. 新機能
Velero ビルトイン DataMover は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
OADP 1.3 には、Container Storage Interface (CSI) ボリュームのスナップショットをリモートオブジェクトストアに移動するために使用できる、ビルトイン Data Mover が含まれています。ビルトイン Data Mover を使用すると、クラスターの障害、誤削除、または破損が発生した場合に、リモートオブジェクトストアからステートフルアプリケーションを復元できます。スナップショットデータを読み取り、統合リポジトリーに書き込むためのアップローダーメカニズムとして Kopia を使用します。
ファイルシステムバックアップを使用してアプリケーションをバックアップする: Kopia または Restic
Velero のファイルシステムバックアップ (FSB) は、Restic パスと Kopia パスという 2 つのバックアップライブラリーをサポートしています。
Velero を使用すると、ユーザーは 2 つのパスから選択できます。
バックアップの場合は、インストール中に uploader-type
フラグを使用してパスを指定します。有効な値は、restic
または kopia
です。値が指定されていない場合、このフィールドのデフォルトは kopia
です。インストール後に選択を変更することはできません。
GCP クラウド認証
Google Cloud Platform (GCP) 認証を使用すると、有効期間の短い Google 認証情報を使用できます。
GCP と Workload Identity Federation を使用すると、Identity and Access Management (IAM) を使用して、サービスアカウントに成り代わる機能などの IAM ロールを外部アイデンティティーに付与できます。これにより、サービスアカウントキーに関連するメンテナンスとセキュリティーのリスクが排除されます。
AWS ROSA STS 認証
Red Hat OpenShift Service on AWS (ROSA) クラスターで OpenShift API for Data Protection (OADP) を使用して、アプリケーションデータをバックアップおよび復元できます。
ROSA は、幅広い AWS コンピュート、データベース、分析、機械学習、ネットワーク、モバイル、およびその他のサービスとのシームレスな統合を提供し、差別化されたエクスペリエンスの構築とお客様への提供をさらに高速化します。
AWS アカウントから直接サービスをサブスクライブできます。
クラスターの作成後、OpenShift Web コンソールを使用してクラスターを操作できます。ROSA サービスは、OpenShift API およびコマンドラインインターフェイス (CLI) ツールも使用します。
4.2.1.5.2. 解決した問題
ACM アプリケーションが削減され、復元後にマネージドクラスター上で再作成される
マネージドクラスター上のアプリケーションは削除され、復元をアクティブ化すると再作成されていました。OpenShift API for Data Protection (OADP 1.2) のバックアップおよび復元のプロセスは、古いバージョンよりも高速です。OADP のパフォーマンスが変わったことで、ACM リソースの復元時にこのような動作が発生するようになりました。一部のリソースは他のリソースより前に復元され、その結果、マネージドクラスターからアプリケーションが削除されていました。OADP-2686
Pod セキュリティー標準が原因で Restic の復元が部分的に失敗する
相互運用性のテスト中に、OpenShift Container Platform 4.14 の Pod セキュリティーモードが enforce
に設定されていたため、Pod が拒否されました。これは、復元順序が原因で発生します。Pod が security context constraints (SCC) リソースの前に作成されることで podSecurity
標準に違反していたため、Pod が拒否されました。Velero サーバーで復元優先度フィールドを設定すると、復元は成功します。OADP-2688
Velero が複数の namespace にインストールされている場合、Pod ボリュームのバックアップが失敗する可能性がある
Velero が複数の namespace にインストールされている場合、Pod Volume Backup (PVB) 機能でリグレッションが発生していました。PVB コントローラーは、その namespace 内の PVB に適切に制限されませんでした。OADP-2308
OADP Velero プラグインが "received EOF, stopping recv loop" のメッセージを返す
OADP では、Velero プラグインは別のプロセスとして開始されました。Velero 操作が完了すると、成功しても失敗しても終了します。そのため、デバッグログに received EOF, stopping recv loop
メッセージが表示された場合、それはエラーの発生ではなく、プラグイン操作の完了を意味しました。OADP-2176
CVE-2023-39325 複数の HTTP/2 対応 Web サーバーが DDoS 攻撃 (Rapid Reset Attack) に対して脆弱である
OADP の以前のリリースでは、リクエストのキャンセルにより複数のストリームがすぐにリセットされる可能性があるため、HTTP/2 プロトコルはサービス拒否攻撃の影響を受けやすかった。サーバーは、接続ごとのアクティブなストリームの最大数に関するサーバー側の制限に達しないようにしながら、ストリームをセットアップおよび破棄する必要がありました。これにより、サーバーリソースの消費によりサービス拒否が発生しました。
詳細は、CVE-2023-39325 (Rapid Reset Attack) を参照してください。
このリリースで解決された問題の一覧は、Jira の OADP 1.3.0 解決済みの問題 に記載されているリストを参照してください。
4.2.1.5.3. 既知の問題
csiSnapshotTimeout が短く設定されている場合、nil ポインターで CSI プラグインエラーが発生する
csiSnapshotTimeout
の期間が短く設定されている場合、CSI プラグインが nil ポインターでエラーを引き起こします。短時間でスナップショットを完了できることもありますが、多くの場合、バックアップ PartiallyFailed
でパニックが発生し、エラー plugin panicked: runtime error: invalid memory address or nil pointer dereference
が表示されます。
volumeSnapshotContent CR にエラーがある場合、バックアップは PartiallyFailed としてマークされる
いずれかの VolumeSnapshotContent
CR に VolumeSnapshotBeingCreated
アノテーションの削除に関連するエラーがある場合、バックアップは WaitingForPluginOperationsPartiallyFailed
フェーズに遷移します。OADP-2871
初めて 30,000 個のリソースの復元する際に、パフォーマンスの問題が発生する
既存のリソースポリシーを使用せずに 30,000 個のリソースを初めて復元する際に、既存のリソースポリシーを update
に設定して 2 回目と 3 回目の復元を実行する場合と比べて、2 倍の時間がかかります。OADP-3071
Datadownload 操作が関連する PV を解放する前に、復元後のフックが実行を開始する可能性がある
Data Mover 操作は非同期のため、関連する Pod の永続ボリューム (PV) が Data Mover の永続ボリューム要求 (PVC) によって解放される前に、ポストフックが試行される可能性があります。
GCP-Workload Identity Federation VSL バックアップで PartiallyFailed が発生する
GCP Workload Identity が GCP 上で設定されている場合、VSL バックアップで PartiallyFailed
が発生します。
このリリースにおける既知の問題の完全なリストは、Jira の OADP 1.3.0 の既知の問題 のリストを参照してください。
4.2.1.5.4. アップグレードの注意事項
必ず次のマイナーバージョンにアップグレードしてください。バージョンは絶対に スキップしないでください。新しいバージョンに更新するには、一度に 1 つのチャネルのみアップグレードします。たとえば、OpenShift API for Data Protection (OADP) 1.1 から 1.3 にアップグレードする場合、まず 1.2 にアップグレードし、次に 1.3 にアップグレードします。
4.2.1.5.4.1. OADP 1.2 から 1.3 への変更点
Velero サーバーが、バージョン 1.11 から 1.12 に更新されました。
OpenShift API for Data Protection (OADP) 1.3 は、VolumeSnapshotMover (VSM) や Volsync Data Mover の代わりに Velero のビルトイン Data Mover を使用します。
これにより、以下の変更が発生します。
-
spec.features.dataMover
フィールドと VSM プラグインは OADP 1.3 と互換性がないため、それらの設定をDataProtectionApplication
(DPA) 設定から削除する必要があります。 - Volsync Operator は Data Mover の機能には不要になったため、削除できます。
-
カスタムリソース定義の
volumesnapshotbackups.datamover.oadp.openshift.io
およびvolumesnapshotrestores.datamover.oadp.openshift.io
は不要になったため、削除できます。 - OADP-1.2 Data Mover に使用されるシークレットは不要になったため、削除できます。
OADP 1.3 は、Restic の代替ファイルシステムバックアップツールである Kopia をサポートしています。
Kopia を使用するには、次の例に示すように、新しい
spec.configuration.nodeAgent
フィールドを使用します。例
spec: configuration: nodeAgent: enable: true uploaderType: kopia # ...
spec.configuration.restic
フィールドは OADP 1.3 で非推奨となり、今後の OADP バージョンで削除される予定です。非推奨の警告が表示されないようにするには、restic
キーとその値を削除し、次の新しい構文を使用します。例
spec: configuration: nodeAgent: enable: true uploaderType: restic # ...
今後の OADP リリースでは、kopia
ツールが uploaderType
のデフォルト値になる予定です。
4.2.1.5.4.2. OADP 1.2 の Data Mover (テクノロジープレビュー) からアップグレードする
OpenShift API for Data Protection (OADP) 1.2 Data Mover のバックアップは、OADP 1.3 では 復元できません。アプリケーションのデータ保護にギャップが生じることを防ぐには、OADP 1.3 にアップグレードする前に次の手順を実行します。
手順
- クラスターのバックアップが十分で、Container Storage Interface (CSI) ストレージが利用可能な場合は、CSI バックアップを使用してアプリケーションをバックアップします。
クラスター外のバックアップが必要な場合:
-
--default-volumes-to-fs-backup=true or backup.spec.defaultVolumesToFsBackup
オプションを使用するファイルシステムバックアップで、アプリケーションをバックアップします。 -
オブジェクトストレージプラグイン (
velero-plugin-for-aws
など) を使用してアプリケーションをバックアップします。
-
OADP 1.2 Data Mover バックアップを復元するには、OADP をアンインストールし、OADP 1.2 をインストールして設定する必要があります。
4.2.1.5.4.3. DPA 設定をバックアップする
現在の DataProtectionApplication
(DPA) 設定をバックアップする必要があります。
手順
次のコマンドを実行して、現在の DPA 設定を保存します。
例
$ oc get dpa -n openshift-adp -o yaml > dpa.orig.backup
4.2.1.5.4.4. OADP Operator をアップグレードする
OpenShift API for Data Protection (OADP) Operator をアップグレードする場合は、次の手順を使用します。
手順
-
OADP Operator のサブスクリプションチャネルを、
steady-1.2
からstable-1.3
に変更します。 - Operator とコンテナーが更新され、再起動されるまで待機します。
4.2.1.5.4.5. DPA を新しいバージョンに変換する
Data Mover を使用してバックアップをクラスター外に移動する必要がある場合は、次のように DataProtectionApplication
(DPA) マニフェストを再設定します。
手順
- Operators → Installed Operators をクリックして、OADP Operator を選択します。
- Provided APIs セクションで、View more をクリックします。
- DataProtectionApplication ボックスの Create instance をクリックします。
YAML View をクリックして、現在の DPA パラメーターを表示します。
現在の DPA の例
spec: configuration: features: dataMover: enable: true credentialName: dm-credentials velero: defaultPlugins: - vsm - csi - openshift # ...
DPA パラメーターを更新します。
-
DPA から、
features.dataMover
キーと値を削除します。 - VolumeSnapshotMover (VSM) プラグインを削除します。
nodeAgent
キーと値を追加します。更新された DPA の例
spec: configuration: nodeAgent: enable: true uploaderType: kopia velero: defaultPlugins: - csi - openshift # ...
-
DPA から、
- DPA が正常に調整するまで待機します。
4.2.1.5.4.6. アップグレードの検証
アップグレードを検証するには、次の手順を使用します。
手順
次のコマンドを実行して OpenShift API for Data Protection (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/node-agent-9cq4q 1/1 Running 0 94s pod/node-agent-m4lts 1/1 Running 0 94s pod/node-agent-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 service/openshift-adp-velero-metrics-svc ClusterIP 172.30.10.0 <none> 8085/TCP 8h NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/node-agent 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
次のコマンドを実行して、
DataProtectionApplication
(DPA) が調整されていることを確認します。$ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'
出力例
{"conditions":[{"lastTransitionTime":"2023-10-27T01:23:57Z","message":"Reconcile complete","reason":"Complete","status":"True","type":"Reconciled"}]}
-
type
がReconciled
に設定されていることを確認します。 次のコマンドを実行して、バックアップ保存場所を確認し、
PHASE
がAvailable
であることを確認します。$ oc get backupStorageLocation -n openshift-adp
出力例
NAME PHASE LAST VALIDATED AGE DEFAULT dpa-sample-1 Available 1s 3d16h true
OADP 1.3 では、DataProtectionApplication
(DPA) 設定を作成するのではなく、バックアップごとにクラスター外へのデータ移動を開始できます。
例
$ velero backup create example-backup --include-namespaces mysql-persistent --snapshot-move-data=true
例
apiVersion: velero.io/v1 kind: Backup metadata: name: example-backup namespace: openshift-adp spec: snapshotMoveData: true includedNamespaces: - mysql-persistent storageLocation: dpa-sample-1 ttl: 720h0m0s # ...
4.2.2. OADP 1.2 リリースノート
OpenShift API for Data Protection (OADP) 1.2 のリリースノートでは、新機能と拡張機能、非推奨の機能、製品の推奨事項、既知の問題、および解決された問題を説明します。
4.2.2.1. OADP 1.2.5 リリースノート
OpenShift API for Data Protection (OADP) 1.2.5 は、Container Grade Only (CGO) のリリースであり、コンテナーのヘルスグレードを更新するためにリリースされました。OADP 1.2.4 と比較して、製品自体のコードに変更はありません。
4.2.2.1.1. 解決した問題
CVE-2023-2431: oadp-velero-plugin-for-microsoft-azure-container
: seccomp プロファイル適用のバイパス
Kubernetes に不具合が見つかり、OADP の以前のバージョンに影響します。この不具合は、seccomp
プロファイルに localhost タイプを使用し、空のプロファイルフィールドを指定する場合の不具合によって、Kubernetes がローカル認証された攻撃者にセキュリティー制限の回避を許可した場合に発生します。攻撃者は、悪用目的で作成されたリクエストを送信することで、seccomp
プロファイルの適用を回避できます。 この不具合は OADP 1.2.5 で解決されました。
詳細は、(CVE-2023-2431) を参照してください。
CSI 復元が 'PartiallyFailed' ステータスで終了し、PVC が作成されない
CSI 復元が PartiallyFailed
ステータスで終了しました。PVC は作成されず、Pod のステータスは Pending
です。この問題は OADP 1.2.5 で解決されました。
完了した Pod ボリュームで PodVolumeBackup が失敗する
OADP 1.2 の以前のバージョンでは、Restic podvolumebackup
または Velero バックアップで使用される namespace にボリュームをマウントした完了した Pod がある場合、バックアップは正常に完了しません。これは、defaultVolumesToFsBackup
が true
に設定されている場合に発生します。この問題は OADP 1.2.5 で解決されました。
4.2.2.1.2. 既知の問題
データ保護アプリケーション (DPA) は、認証情報のシークレットが更新されても調整を行いません。
現在、OADP Operator は cloud-credentials
シークレットを更新しても調整を行いません。これは、cloud-credentials
シークレットに OADP 固有のラベルまたは所有者参照がないことが原因です。 空のデータなどの誤った認証情報を使用して cloud-credentials
シークレットを作成すると、Operator はその空のデータを使用して調整し、Backup Storage Location (BSL) とレジストリーデプロイメントを作成します。その結果、正しい認証情報で cloud-credentials
シークレットを更新しても、OADP Operator はすぐに調整して新しい認証情報を取得することはしません。
回避策: OADP 1.3 に更新します。
4.2.2.2. OADP 1.2.4 リリースノート
OpenShift API for Data Protection (OADP) 1.2.4 は、コンテナーグレードのみ (CGO) のリリースであり、コンテナーのヘルスグレードを更新するためにリリースされました。OADP 1.2.3 と比較して、製品自体のコードに変更はありません。
4.2.2.2.1. 解決した問題
OADP 1.2.4 には解決された問題はありません。
4.2.2.2.2. 既知の問題
OADP 1.2.4 には次の既知の問題があります。
データ保護アプリケーション (DPA) は、認証情報のシークレットが更新されても調整を行いません。
現在、OADP Operator は cloud-credentials
シークレットを更新しても調整を行いません。これは、cloud-credentials
シークレットに OADP 固有のラベルまたは所有者参照がないことが原因です。 空のデータなどの誤った認証情報を使用して cloud-credentials
シークレットを作成すると、Operator はその空のデータを使用して調整し、Backup Storage Location (BSL) とレジストリーデプロイメントを作成します。その結果、正しい認証情報で cloud-credentials
シークレットを更新しても、Operator はすぐに調整して新しい認証情報を取得することはしません。
回避策: OADP 1.3 に更新します。
4.2.2.3. OADP 1.2.3 リリースノート
4.2.2.3.1. 新機能
OpenShift API for Data Protection (OADP) 1.2.3 のリリースに新機能はありません。
4.2.2.3.2. 解決した問題
以下で強調表示された問題は、OADP 1.2.3 で解決されています。
複数の HTTP/2 対応 Web サーバーが DDoS 攻撃 (Rapid Reset Attack) に対して脆弱です
OADP 1.2 の以前のリリースでは、リクエストのキャンセルにより複数のストリームがすぐにリセットされる可能性があるため、HTTP/2 プロトコルはサービス拒否攻撃の影響を受けやすかった。サーバーは、接続ごとのアクティブなストリームの最大数に関するサーバー側の制限に達しないようにしながら、ストリームをセットアップおよび破棄する必要がありました。これにより、サーバーリソースの消費によりサービス拒否が発生しました。この CVE に関連するすべての OADP 問題のリストは、次の Jira リスト を参照してください。
詳細は、CVE-2023-39325 (Rapid Reset Attack) を参照してください。
OADP 1.2.3 のリリースで解決されたすべての問題の完全なリストは、Jira の OADP 1.2.3 で解決された問題 のリストを参照してください。
4.2.2.3.3. 既知の問題
OADP 1.2.3 には次の既知の問題があります。
データ保護アプリケーション (DPA) は、認証情報のシークレットが更新されても調整を行いません。
現在、OADP Operator は cloud-credentials
シークレットを更新しても調整を行いません。これは、cloud-credentials
シークレットに OADP 固有のラベルまたは所有者参照がないことが原因です。 空のデータなどの誤った認証情報を使用して cloud-credentials
シークレットを作成すると、Operator はその空のデータを使用して調整し、Backup Storage Location (BSL) とレジストリーデプロイメントを作成します。その結果、正しい認証情報で cloud-credentials
シークレットを更新しても、Operator はすぐに調整して新しい認証情報を取得することはしません。
回避策: OADP 1.3 に更新します。
4.2.2.4. OADP 1.2.2 リリースノート
4.2.2.4.1. 新機能
OpenShift API for Data Protection (OADP) 1.2.2 のリリースに新機能はありません。
4.2.2.4.2. 解決した問題
以下で強調表示された問題は、OADP 1.2.2 で解決されています。
Pod セキュリティー標準が原因で Restic の復元が部分的に失敗します
OADP 1.2 の以前のリリースでは、OpenShift Container Platform 4.14 は、Restic 復元プロセス中に Pod の readiness を妨げる可能性がある Pod Security Admission (PSA) ポリシーを強制していました。
この問題は、OADP 1.2.2 と OADP 1.1.6 のリリースで解決されました。ユーザーは、これらのリリースにアップグレードすることが推奨されます。
詳細は、PSA ポリシーの変更により、OCP 4.14 で部分的に Restic 復元が失敗する を参照してください。(OADP-2094)
内部イメージを使用したアプリケーションのバックアップが、プラグインパニックエラーにより部分的に失敗します
OADP 1.2 の以前のリリースでは、内部イメージを使用したアプリケーションのバックアップが部分的に失敗し、プラグインパニックエラーが返されました。バックアップが部分的に失敗し、Velero ログに次のエラーが記録されます。
time="2022-11-23T15:40:46Z" level=info msg="1 errors encountered backup up item" backup=openshift-adp/django-persistent-67a5b83d-6b44-11ed-9cba-902e163f806c logSource="/remote-source/velero/app/pkg/backup/backup.go:413" name=django-psql-persistent time="2022-11-23T15:40:46Z" level=error msg="Error backing up item" backup=openshift-adp/django-persistent-67a5b83d-6b44-11ed-9cba-902e163f8
この問題は、OADP 1.2.2 で解決されました。(OADP-1057)
復元順序が原因で、ACM クラスターの復元が期待どおりに機能しません
OADP 1.2 の以前のリリースでは、復元順序が原因で、ACM クラスターの復元が期待どおりに機能しませんでした。ACM アプリケーションは、復元を有効にした後に削除され、マネージドクラスター上で再作成されました。(OADP-2505)
ボリュームサイズの不一致により、filesystemOverhead を使用している仮想マシンが、バックアップおよび復元時に失敗します
OADP 1.2 の以前のリリースでは、選択したストレージプロバイダー実装が原因で、アプリケーションの永続ボリューム要求 (PVC) のストレージ要求と同じ PVC のスナップショットサイズが異なると、バックアップおよび復元時に filesystemOverhead を使用する仮想マシンが失敗していました。 この問題は、OADP 1.2.2 の Data Mover で解決されました。(OADP-2144)
OADP には、VolSync レプリケーションソースのプルーニング間隔を設定するオプションが含まれていませんでした
OADP 1.2 の以前のリリースでは、VolSync レプリケーションソースの pruneInterval
を設定するオプションがありませんでした。(OADP-2052)
Velero が複数の namespace にインストールされている場合、Pod ボリュームのバックアップが失敗する可能性がありました
OADP 1.2 の以前のリリースでは、Velero が複数の namespace にインストールされている場合、Pod ボリュームのバックアップが失敗する可能性がありました。(OADP-2409)
VSL がカスタムシークレットを使用する場合、Backup Storage Locations が使用不可フェーズに遷移しました
OADP 1.2 の以前のリリースでは、Volume Snapshot Location がカスタムシークレットを使用した場合、Backup Storage Locations が使用不可フェーズに遷移しました。(OADP-1737)
OADP 1.2.2 のリリースで解決されたすべての問題の完全なリストは、Jira の OADP 1.2.2 で解決された問題 のリストを参照してください。
4.2.2.4.3. 既知の問題
以下で強調表示されている問題は、OADP 1.2.2 のリリースにおける既知の問題です。
Must-gather コマンドが ClusterRoleBinding リソースの削除に失敗します
oc adm must-gather
コマンドは、アドミッション Webhook が原因で、クラスター上に残っている ClusterRoleBinding
リソースの削除に失敗します。したがって、ClusterRoleBinding
リソースの削除要求は拒否されます。(OADP-27730)
admission webhook "clusterrolebindings-validation.managed.openshift.io" denied the request: Deleting ClusterRoleBinding must-gather-p7vwj is not allowed
このリリースにおける既知の問題の完全なリストは、Jira の OADP 1.2.2 の既知の問題 のリストを参照してください。
4.2.2.5. OADP 1.2.1 リリースノート
4.2.2.5.1. 新機能
OpenShift API for Data Protection (OADP) 1.2.1 のリリースには新機能はありません。
4.2.2.5.2. 解決した問題
OADP 1.2.1 のリリースで解決されたすべての問題の完全なリストは、Jira の OADP 1.2.1 で解決された問題 のリストを参照してください。
4.2.2.5.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.2.2.6. OADP 1.2.0 リリースノート
OADP 1.2.0 リリースノートには、新機能、バグ修正、既知の問題に関する情報が含まれています。
4.2.2.6.1. 新機能
リソースタイムアウト
新しい resourceTimeout
オプションは、さまざまな Velero リソースを待機するタイムアウト期間を分単位で指定します。このオプションは、Velero CRD の可用性、volumeSnapshot
の削除、バックアップリポジトリーの可用性などのリソースに適用されます。デフォルトの期間は 10 分です。
AWS S3 互換のバックアップストレージプロバイダー
AWS S3 互換プロバイダーでオブジェクトとスナップショットをバックアップできます。
4.2.2.6.1.1. テクニカルプレビュー機能
Data Mover
OADP Data Mover を使用すると、Container Storage Interface (CSI) ボリュームのスナップショットをリモートオブジェクトストアにバックアップできます。Data Mover を有効にすると、クラスターの偶発的な削除、クラスター障害、またはデータ破損が発生した場合に、オブジェクトストアから取得した CSI ボリュームスナップショットを使用してステートフルアプリケーションを復元できます。
OADP Data Mover はテクノロジープレビューのみの機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
4.2.2.6.2. 解決した問題
このリリースで解決された問題の一覧は、Jira の OADP 1.2.0 解決済みの問題 に記載されているリストを参照してください。
4.2.2.6.3. 既知の問題
以下で強調表示されている問題は、OADP 1.2.0 のリリースにおける既知の問題です。
複数の HTTP/2 対応 Web サーバーが DDoS 攻撃 (Rapid Reset Attack) に対して脆弱です
HTTP/2 プロトコルは、リクエストのキャンセルによって複数のストリームがすぐにリセットされる可能性があるため、サービス拒否攻撃の影響を受けやすくなっています。サーバーは、接続ごとのアクティブなストリームの最大数に関するサーバー側の制限に達しないようにしながら、ストリームをセットアップおよび破棄する必要があります。これにより、サーバーのリソースが消費され、サービス拒否が発生します。
この問題を解決する OADP 1.2.3 にアップグレードすることを推奨します。
詳細は、CVE-2023-39325 (Rapid Reset Attack) を参照してください。
生成されたルートのホスト名を変更すると、不正なホスト名が作成される場合があります。
デフォルトでは、OpenShift Container Platform クラスターは、openshift.io/host.generated: true
アノテーションがオンになっていることを確認し、生成されたルートと生成されていないルートの両方のフィールドに値を入力します。
.spec.host
フィールドの値を、生成されたルートと生成されていないルートのクラスターのベースドメイン名に基づいて変更することはできません。
.spec.host
フィールドの値を変更する場合、OpenShift Container Platform クラスターによって生成されたデフォルト値を復元することはできません。OpenShift Container Platform クラスターを復元した後、Operator がそのフィールドの値をリセットします。
4.2.2.6.4. アップグレードの注意事項
必ず次のマイナーバージョンにアップグレードしてください。バージョンは絶対に スキップしないでください。新しいバージョンに更新するには、一度に 1 つのチャネルのみアップグレードします。たとえば、OpenShift API for Data Protection (OADP) 1.1 から 1.3 にアップグレードする場合、まず 1.2 にアップグレードし、次に 1.3 にアップグレードします。
4.2.2.6.4.1. OADP 1.1 から 1.2 への変更点
Velero サーバーが、バージョン 1.9 から 1.11 に更新されました。
OADP 1.2 では、DataProtectionApplication
(DPA) 設定の dpa.spec.configuration.velero.args
に、次の変更が加えられました。
-
default-volumes-to-restic
フィールドの名前がdefault-volumes-to-fs-backup
に変更されました。dpa.spec.configuration.velero.args
を使用する場合は、OADP のアップグレード後に、新しい名前で DPA に再度追加する必要があります。 -
restic-timeout
フィールドの名前がfs-backup-timeout
に変更されました。dpa.spec.configuration.velero.args
を使用する場合は、OADP のアップグレード後に、新しい名前で DPA に再度追加する必要があります。 -
restic
デーモンセットの名前がnode-agent
に変更されました。OADP は、デーモンセットの名前を自動的に更新します。 -
カスタムリソース定義
resticrepositories.velero.io
の名前がbackuprepositories.velero.io
に変更されました。 -
カスタムリソース定義
resticrepositories.velero.io
は、クラスターから削除できます。
4.2.2.6.5. アップグレード手順
4.2.2.6.5.1. DPA 設定をバックアップする
現在の DataProtectionApplication
(DPA) 設定をバックアップする必要があります。
手順
次のコマンドを実行して、現在の DPA 設定を保存します。
例
$ oc get dpa -n openshift-adp -o yaml > dpa.orig.backup
4.2.2.6.5.2. OADP Operator をアップグレードする
OpenShift API for Data Protection (OADP) Operator をアップグレードする場合は、次の手順を使用します。
手順
-
OADP Operator のサブスクリプションチャネルを、
stable-1.1
からstable-1.2
に変更します。 - Operator とコンテナーが更新され、再起動されるまで待機します。
4.2.2.6.5.3. DPA を新しいバージョンに変換する
spec.configuration.velero.args
スタンザで更新されたフィールドを使用する場合は、新しいパラメーター名を使用するように DataProtectionApplication
(DPA) マニフェストを設定する必要があります。
手順
- Operators → Installed Operators をクリックして、OADP Operator を選択します。
- Provided APIs を選択し、DataProtectionApplication ボックスの Create instance をクリックします。
YAML View をクリックして、現在の DPA パラメーターを表示します。
現在の DPA の例
spec: configuration: velero: args: default-volumes-to-fs-backup: true default-restic-prune-frequency: 6000 fs-backup-timeout: 600 # ...
- DPA パラメーターを更新します。
DPA パラメーターの値は変更せずに、名前を更新します。
-
default-volumes-to-restic
キーを、default-volumes-to-fs-backup
に変更します。 -
default-restic-prune-frequency
キーを、default-repo-maintain-frequency
に変更します。 -
restic-timeout
キーを、fs-backup-timeout
に変更します。
更新された DPA の例
spec: configuration: velero: args: default-volumes-to-fs-backup: true default-repo-maintain-frequency: 6000 fs-backup-timeout: 600 # ...
-
- DPA が正常に調整するまで待機します。
4.2.2.6.5.4. アップグレードの検証
アップグレードを検証するには、次の手順を使用します。
手順
次のコマンドを実行して OpenShift API for Data Protection (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
次のコマンドを実行して、
DataProtectionApplication
(DPA) が調整されていることを確認します。$ oc get dpa dpa-sample -n openshift-adp -o jsonpath='{.status}'
出力例
{"conditions":[{"lastTransitionTime":"2023-10-27T01:23:57Z","message":"Reconcile complete","reason":"Complete","status":"True","type":"Reconciled"}]}
-
type
がReconciled
に設定されていることを確認します。 次のコマンドを実行して、バックアップ保存場所を確認し、
PHASE
がAvailable
であることを確認します。$ oc get backupStorageLocation -n openshift-adp
出力例
NAME PHASE LAST VALIDATED AGE DEFAULT dpa-sample-1 Available 1s 3d16h true
4.2.3. OADP 1.1 リリースノート
OpenShift API for Data Protection (OADP) 1.1 のリリースノートでは、新機能と拡張機能、非推奨の機能、製品の推奨事項、既知の問題、および解決された問題を説明します。
4.2.3.1. OADP 1.1.8 リリースノート
OpenShift API for Data Protection (OADP) 1.1.8 リリースノートには、既知の問題がすべて記載されています。本リリースで解決された問題はありません。
4.2.3.1.1. 既知の問題
OADP 1.1.8 における既知の問題の完全なリストは、Jira の OADP 1.1.8 の既知の問題 のリストを参照してください。
4.2.3.2. OADP 1.1.7 リリースノート
OADP 1.1.7 リリースノートには、解決された問題と既知の問題がリストされています。
4.2.3.2.1. 解決した問題
以下で強調表示された問題は、OADP 1.1.7 で解決されています。
複数の HTTP/2 対応 Web サーバーが DDoS 攻撃 (Rapid Reset Attack) に対して脆弱です
OADP 1.1 の以前のリリースでは、リクエストのキャンセルにより複数のストリームがすぐにリセットされる可能性があるため、HTTP/2 プロトコルはサービス拒否攻撃の影響を受けやすかった。サーバーは、接続ごとのアクティブなストリームの最大数に関するサーバー側の制限に達しないようにしながら、ストリームをセットアップおよび破棄する必要がありました。これにより、サーバーリソースの消費によりサービス拒否が発生しました。この CVE に関連するすべての OADP 問題のリストは、次の Jira リスト を参照してください。
詳細は、CVE-2023-39325 (Rapid Reset Attack) を参照してください。
OADP 1.1.7 のリリースで解決されたすべての問題の完全なリストは、Jira の OADP 1.1.7 で解決された問題 のリストを参照してください。
4.2.3.2.2. 既知の問題
OADP 1.1.7 のリリースには既知の問題はありません。
4.2.3.3. OADP 1.1.6 リリースノート
OADP 1.1.6 リリースノートには、新機能、解決された問題とバグ、既知の問題がリストされています。
4.2.3.3.1. 解決した問題
Pod セキュリティー標準が原因で Restic の復元が部分的に失敗します
OCP 4.14 では、privileged
プロファイルが enforced
になる Pod セキュリティー標準が導入されました。以前の OADP リリースでは、このプロファイルが原因で Pod が permission denied
エラーを受信していました。この問題は、復元順序が原因で発生していました。Pod は security context constraints (SCC) リソースの前に作成されました。この Pod が Pod のセキュリティー標準に違反するため、Pod は拒否され、その後失敗しました。OADP-2420
ジョブリソースの復元が部分的に失敗します
以前の OADP リリースでは、OCP 4.14 でジョブリソースの復元が部分的に失敗していました。この問題は古い OCP バージョンでは確認されませんでした。この問題は、ジョブリソースに追加のラベルが存在するために発生しましたが、これは古い OCP バージョンには存在していませんでした。OADP-2530
このリリースで解決された問題の一覧は、Jira の OADP 1.1.6 解決済みの問題 に記載されているリストを参照してください。
4.2.3.3.2. 既知の問題
このリリースにおける既知の問題の完全なリストは、Jira の OADP 1.1.6 の既知の問題 のリストを参照してください。
4.2.3.4. OADP 1.1.5 リリースノート
OADP 1.1.5 リリースノートには、新機能、解決された問題とバグ、既知の問題がリストされています。
4.2.3.4.1. 新機能
このバージョンの OADP はサービスリリースです。このバージョンには新しい機能は追加されていません。
4.2.3.4.2. 解決した問題
このリリースで解決された問題の一覧は、Jira の OADP 1.1.5 解決済みの問題 に記載されているリストを参照してください。
4.2.3.4.3. 既知の問題
このリリースにおける既知の問題の完全なリストは、Jira の OADP 1.1.5 の既知の問題 のリストを参照してください。
4.2.3.5. OADP 1.1.4 リリースノート
OADP 1.1.4 リリースノートには、新機能、解決された問題とバグ、既知の問題がリストされています。
4.2.3.5.1. 新機能
このバージョンの OADP はサービスリリースです。このバージョンには新しい機能は追加されていません。
4.2.3.5.2. 解決した問題
すべての velero デプロイメントサーバー引数のサポートを追加しました
以前の OADP リリースでは、OADP はアップストリームのすべての Velero サーバー引数のサポートを促進しませんでした。この問題は OADP 1.1.4 で解決され、アップストリームのすべての Velero サーバー引数がサポートされるようになりました。OADP-1557
復元名と PVC 名に複数の VSR がある場合、Data Mover は誤ったスナップショットから復元できます
以前のリリースの OADP では、クラスター内に同じ Velero restore
名と PersistentVolumeClaim (pvc) 名の Volume Snapshot Restore (VSR) リソースが複数ある場合、OADP Data Mover が間違ったスナップショットから復元できる可能性がありました。OADP-1822
Cloud Storage API BSL には OwnerReference が必要です
OADP の以前のリリースでは、dpa.spec.backupLocations.bucket
で作成された Backup Storage Location (BSL) で OwnerReference
が欠落しているため、ACM BackupSchedules が検証に失敗しました。OADP-1511
このリリースで解決された問題の一覧は、Jira の OADP 1.1.4 解決済みの問題 に記載されているリストを参照してください。
4.2.3.5.3. 既知の問題
本リリースには、以下の既知の問題があります。
UID/GID 範囲がクラスター上で変更された可能性があるため、OADP バックアップが失敗する可能性があります
アプリケーションがリストアされたクラスター上で UID/GID 範囲が変更された可能性があるため、OADP バックアップが失敗する可能性があり、その結果、OADP が OpenShift Container Platform の UID/GID 範囲メタデータをバックアップおよびリストアしません。この問題を回避するには、バックアップされたアプリケーションに特定の UUID が必要な場合、復元時にその範囲が使用可能であることを確認してください。追加の回避策として、OADP が復元操作で namespace を作成できるようにすることが挙げられます。
ArgoCD で使用されるラベルが原因で ArgoCD がプロセス中に使用されると、復元が失敗する場合があります。
ArgoCD の app.kubernetes.io/instance
で使用されるラベルが原因で ArgoCD がプロセス中に使用されると、復元が失敗する場合があります。このラベルは、ArgoCD が管理する必要があるリソースを識別します。これにより、復元時にリソースを管理するための OADP の手順と競合が発生する可能性があります。この問題を回避するには、ArgoCD YAML の .spec.resourceTrackingMethod
を annotation+label
または annotation
に設定します。問題が解決しない場合は、復元を開始する前に ArgoCD を無効にし、復元が完了したら再び有効にします。
OADP Velero プラグインが "received EOF, stopping recv loop" のメッセージを返す
Velero プラグインは、別のプロセスとして開始されます。Velero 操作が完了すると、成功したかどうかにかかわらず終了します。つまり、デバッグログに received EOF, stopping recv loop
メッセージが表示されても、エラーが発生したことを意味するものではありません。このメッセージは、プラグイン操作が完了したことを示します。OADP-2176
このリリースにおける既知の問題の完全なリストは、Jira の OADP 1.1.4 の既知の問題 のリストを参照してください。
4.2.3.6. OADP 1.1.3 リリースノート
OADP 1.1.3 リリースノートには、新機能、解決された問題とバグ、既知の問題がリストされています。
4.2.3.6.1. 新機能
このバージョンの OADP はサービスリリースです。このバージョンには新しい機能は追加されていません。
4.2.3.6.2. 解決した問題
このリリースで解決された問題の一覧は、Jira の OADP 1.1.3 解決済みの問題 に記載されているリストを参照してください。
4.2.3.6.3. 既知の問題
このリリースにおける既知の問題の完全なリストは、Jira の OADP 1.1.3 の既知の問題 のリストを参照してください。
4.2.3.7. OADP 1.1.2 リリースノート
OADP 1.1.2 リリースノートには、製品の推奨事項、修正されたバグのリスト、および既知の問題の説明が含まれています。
4.2.3.7.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.2.3.7.2. 解決した問題
このリリースでは、次の問題が解決されました。
4.2.3.7.3. 既知の問題
本リリースには、以下の既知の問題があります。
- OADP は現在、Velero で restic を使用した AWS EFS ボリュームのバックアップと復元をサポートしていません (OADP-778)。
PVC ごとの
VolumeSnapshotContent
スナップショットの Ceph 制限により、CSI バックアップが失敗する場合があります。同じ永続ボリューム要求 (PVC) のスナップショットを複数作成できますが、スナップショットの定期的な作成をスケジュールすることはできません。
詳細は、ボリュームのスナップショット を参照してください。
4.2.3.8. OADP 1.1.1 リリースノート
OADP 1.1.1 リリースノートには、製品の推奨事項と既知の問題の説明が含まれています。
4.2.3.8.1. 製品の推奨事項
OADP 1.1.1 をインストールする前に、VolSync 0.5.1 をインストールするか、それにアップグレードすることを推奨します。
4.2.3.8.2. 既知の問題
本リリースには、以下の既知の問題があります。
複数の HTTP/2 対応 Web サーバーが DDoS 攻撃 (Rapid Reset Attack) に対して脆弱です
HTTP/2 プロトコルは、リクエストのキャンセルによって複数のストリームがすぐにリセットされる可能性があるため、サービス拒否攻撃の影響を受けやすくなっています。サーバーは、接続ごとのアクティブなストリームの最大数に関するサーバー側の制限に達しないようにしながら、ストリームをセットアップおよび破棄する必要があります。これにより、サーバーのリソースが消費され、サービス拒否が発生します。この CVE に関連するすべての OADP 問題のリストは、次の Jira リスト を参照してください。
この問題を解決するには、OADP 1.1.7 または 1.2.3 にアップグレードすることを推奨します。
詳細は、CVE-2023-39325 (Rapid Reset Attack) を参照してください。
- OADP は現在、Velero で restic を使用した AWS EFS ボリュームのバックアップと復元をサポートしていません (OADP-778)。
PVC ごとの
VolumeSnapshotContent
スナップショットの Ceph 制限により、CSI バックアップが失敗する場合があります。同じ永続ボリューム要求 (PVC) のスナップショットを複数作成できますが、スナップショットの定期的な作成をスケジュールすることはできません。
- CephFS の場合、PVC ごとに最大 100 スナップショットを作成できます。
RADOS ブロックデバイス (RBD) の場合は、PVC ごとに最大 512 個のスナップショットを作成できます。(OADP-804) および (OADP-975)
詳細は、ボリュームのスナップショット を参照してください。
4.3. OADP features and plugins
OpenShift API for Data Protection (OADP) 機能は、アプリケーションをバックアップおよび復元するためのオプションを提供します。
デフォルトのプラグインにより、Velero は特定のクラウドプロバイダーと統合し、OpenShift Container Platform リソースをバックアップおよび復元できます。
4.3.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.3.2. OADP プラグイン
OpenShift API for Data Protection (OADP) は、バックアップおよびスナップショット操作をサポートするためにストレージプロバイダーと統合されたデフォルトの Velero プラグインを提供します。Velero プラグインに基づき、カスタムプラグイン を作成できます。
OADP は、OpenShift Container Platform リソースバックアップ、OpenShift Virtualization リソースバックアップ、および Container Storage Interface (CSI) スナップショット用のプラグインも提供します。
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
プラグインは、Kubernetes CSI スナップショット API を使用します。-
OADP 1.1 以降は
snapshot.storage.k8s.io/v1
を使用します。 -
OADP 1.0 は
snapshot.storage.k8s.io/v1beta1
を使用します。
-
OADP 1.1 以降は
- OADP 1.2 のみ。
4.3.3. OADP Velero プラグインについて
Velero のインストール時に、次の 2 種類のプラグインを設定できます。
- デフォルトのクラウドプロバイダープラグイン
- カスタムプラグイン
どちらのタイプのプラグインもオプションですが、ほとんどのユーザーは少なくとも 1 つのクラウドプロバイダープラグインを設定します。
4.3.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 - gcp
4.3.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-plugin
4.3.3.3. Velero プラグインがメッセージ "received EOF, stopping recv loop" を返す
Velero プラグインは、別のプロセスとして開始されます。Velero 操作が完了すると、成功したかどうかにかかわらず終了します。デバッグログの received EOF, stopping recv loop
メッセージは、プラグイン操作が完了したことを示します。エラーが発生したわけではありません。
4.3.4. OADP でサポートされるアーキテクチャー
OpenShift API for Data Protection (OADP) は、次のアーキテクチャーをサポートします。
- AMD64
- ARM64
- PPC64le
- s390x
OADP 1.2.0 以降のバージョンは、ARM64 アーキテクチャーをサポートします。
4.3.5. IBM Power および IBM Z の OADP サポート
OpenShift API for Data Protection (OADP) はプラットフォームに依存しません。以下の情報は、IBM Power および IBM Z のみに関連しています。
- OADP 1.1.7 は、IBM Power® および IBM Z® 上の OpenShift Container Platform 4.11 に対して正常にテストされました。以下のセクションでは、これらのシステムのバックアップ場所に関する OADP 1.1.7 のテストおよびサポート情報を提供します。
- OADP 1.2.3 は、IBM Power® および IBM Z® 上の OpenShift Container Platform 4.12、4.13、4.14、4.15 に対して正常にテストされました。以下のセクションでは、これらのシステムのバックアップロケーションに関する OADP 1.2.3 のテストおよびサポート情報を提供します。
- OADP 1.3.3 は、IBM Power® および IBM Z® 上の OpenShift Container Platform 4.12、4.13、4.14、4.15 に対して正常にテストされました。以下のセクションでは、これらのシステムのバックアップロケーションに関する OADP 1.3.3 のテストおよびサポート情報を提供します。
4.3.5.1. IBM Power を使用したターゲットバックアップロケーションの OADP サポート
- OpenShift Container Platform 4.11、4.12、および OpenShift API for Data Protection (OADP) 1.1.7 で実行される IBM Power® は、AWS S3 バックアップロケーションターゲットに対して正常にテストされました。テストには AWS S3 ターゲットのみが含まれていましたが、Red Hat は、AWS ではないすべての S3 バックアップロケーションターゲットに対しても、OpenShift Container Platform 4.11 と 4.12、および OADP 1.1.7 に対応する IBM Power の実行をサポートしています。
- OpenShift Container Platform 4.12、4.13、4.14、4.15、および OADP 1.2.3 で実行される IBM Power® は、AWS S3 バックアップロケーションターゲットに対して正常にテストされました。テストには AWS S3 ターゲットのみが含まれていましたが、Red Hat は、AWS ではないすべての S3 バックアップロケーションターゲットに対しても、OpenShift Container Platform 4.12、4.13、4.14、4.15、および OADP 1.2.3 に対応する IBM Power の実行をサポートしています。
- OpenShift Container Platform 4.12、4.13、4.14、4.15、および OADP 1.3.3 で実行される IBM Power® は、AWS S3 バックアップロケーションターゲットに対して正常にテストされました。テストには AWS S3 ターゲットのみが含まれていましたが、Red Hat は、AWS ではないすべての S3 バックアップロケーションターゲットに対しても、OpenShift Container Platform 4.12、4.13、4.14、4.15、および OADP 1.2.3 に対応する IBM Power の実行をサポートしています。
4.3.5.2. IBM Z を使用したターゲットバックアップロケーションの OADP テストとサポート
- OpenShift Container Platform 4.11、4.12、および OpenShift API for Data Protection (OADP) 1.1.7 で実行される IBM Z® は、AWS S3 バックアップロケーションターゲットに対して正常にテストされました。テストには AWS S3 ターゲットのみが含まれていましたが、Red Hat は、AWS ではないすべての S3 バックアップロケーションターゲットに対しても、OpenShift Container Platform 4.11 と 4.12、および OADP 1.1.7 に対応する IBM Z® の実行をサポートしています。
- OpenShift Container Platform 4.12、4.13、4.14、4.15、および OADP 1.2.3 で実行されている IBM Z® は、AWS S3 バックアップロケーションターゲットに対して正常にテストされました。テストには AWS S3 ターゲットのみが含まれていましたが、Red Hat は、AWS ではないすべての S3 バックアップロケーションターゲットに対しても、OpenShift Container Platform 4.11、4.12、4.13、4.14、4.15、および OADP 1.2.3 に対応する IBM Z® の実行をサポートしています。
- OpenShift Container Platform 4.12、4.13、4.14、4.15、および 1.3.3 で実行される IBM Z® は、AWS S3 バックアップロケーションターゲットに対して正常にテストされました。テストには AWS S3 ターゲットのみが含まれていましたが、Red Hat は、AWS ではないすべての S3 バックアップロケーションターゲットに対しても、OpenShift Container Platform 4.14、4.15、4.16、および OADP 1.4.1 に対応する IBM Z® の実行をサポートしています。
4.3.6. OADP プラグインの既知の問題
次のセクションでは、OpenShift API for Data Protection (OADP) プラグインの既知の問題を説明します。
4.3.6.1. シークレットがないことで、イメージストリームのバックアップ中に Velero プラグインでパニックが発生する
バックアップとバックアップ保存場所 (BSL) が Data Protection Application (DPA) の範囲外で管理されている場合、OADP コントローラー (つまり DPA の調整) によって関連する oadp-<bsl_name>-<bsl_provider>-registry-secret
が作成されません。
バックアップを実行すると、OpenShift Velero プラグインがイメージストリームバックアップでパニックになり、次のパニックエラーが表示されます。
024-02-27T10:46:50.028951744Z time="2024-02-27T10:46:50Z" level=error msg="Error backing up item" backup=openshift-adp/<backup name> error="error executing custom action (groupResource=imagestreams.image.openshift.io, namespace=<BSL Name>, name=postgres): rpc error: code = Aborted desc = plugin panicked: runtime error: index out of range with length 1, stack trace: goroutine 94…
4.3.6.1.1. パニックエラーを回避するための回避策
Velero プラグインのパニックエラーを回避するには、次の手順を実行します。
カスタム BSL に適切なラベルを付けます。
$ oc label BackupStorageLocation <bsl_name> app.kubernetes.io/component=bsl
BSL にラベルを付けた後、DPA の調整を待ちます。
注記DPA 自体に軽微な変更を加えることで、強制的に調整を行うことができます。
DPA の調整では、適切な
oadp-<bsl_name>-<bsl_provider>-registry-secret
が作成されていること、正しいレジストリーデータがそこに設定されていることを確認します。$ oc -n openshift-adp get secret/oadp-<bsl_name>-<bsl_provider>-registry-secret -o json | jq -r '.data'
4.3.6.2. OpenShift ADP Controller のセグメンテーション違反
cloudstorage
と restic
の両方を有効にして DPA を設定すると、openshift-adp-controller-manager
Pod がクラッシュし、Pod がクラッシュループのセグメンテーション違反で失敗するまで無期限に再起動します。
velero
または cloudstorage
は相互に排他的なフィールドであるため、どちらか一方だけ定義できます。
-
velero
とcloudstorage
の両方が定義されている場合、openshift-adp-controller-manager
は失敗します。 -
velero
とcloudstorage
のいずれも定義されていない場合、openshift-adp-controller-manager
は失敗します。
この問題の詳細は、OADP-1054 を参照してください。
4.3.6.2.1. OpenShift ADP Controller のセグメンテーション違反の回避策
DPA の設定時に、velero
または cloudstorage
のいずれかを定義する必要があります。DPA で両方の API を定義すると、openshift-adp-controller-manager
Pod がクラッシュループのセグメンテーション違反で失敗します。
4.4. OADP のインストールおよび設定
4.4.1. OADP のインストールについて
クラスター管理者は、OADP Operator をインストールして、OpenShift API for Data Protection (OADP) をインストールします。OADP Operator は Velero 1.12 をインストールします。
OADP 1.0.4 以降、すべて OADP 1.0.z バージョンは、MTC Operator の依存関係としてのみ使用でき、スタンドアロン Operator としては使用できません。
Kubernetes リソースと内部イメージをバックアップするには、次のいずれかのストレージタイプなど、バックアップロケーションとしてオブジェクトストレージが必要です。
- Amazon Web Services
- Microsoft Azure
- Google Cloud Platform
- Multicloud Object Gateway
- AWS S3 互換オブジェクトストレージ (Multicloud Object Gateway、MinIO など)
個々の OADP デプロイメントごとに、同じ namespace 内に複数のバックアップ保存場所を設定できます。
特に指定のない限り、"NooBaa" は軽量オブジェクトストレージを提供するオープンソースプロジェクトを指し、"Multicloud Object Gateway (MCG)" は NooBaa の Red Hat ディストリビューションを指します。
MCG の詳細は、アプリケーションを使用して Multicloud Object Gateway にアクセスする を参照してください。
オブジェクトストレージのバケット作成を自動化する 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.4.1.1. AWS S3 互換のバックアップストレージプロバイダー
OADP は、さまざまなバックアップおよびスナップショット操作で使用できる多数のオブジェクトストレージプロバイダーと互換性があります。いくつかのオブジェクトストレージプロバイダーは完全にサポートされていますが、いくつかはサポートされていないものの動作することがわかっており、一部には既知の制限があります。
4.4.1.1.1. サポートされているバックアップストレージプロバイダー
次の AWS S3 互換オブジェクトストレージプロバイダーは、AWS プラグインを介して OADP によって完全にサポートされており、バックアップ保存場所として使用できます。
- MinIO
- Multicloud Object Gateway (MCG)
- Amazon Web Services (AWS) S3
- IBM Cloud® Object Storage S3
- Ceph RADOS ゲートウェイ (Ceph オブジェクトゲートウェイ)
次の互換オブジェクトストレージプロバイダーはサポートされており、独自の Velero オブジェクトストアプラグインがあります。
- Google Cloud Platform (GCP)
- Microsoft Azure
4.4.1.1.2. サポートされていないバックアップストレージプロバイダー
次の AWS S3 互換オブジェクトストレージプロバイダーは、バックアップストレージの場所として使用するために、AWS プラグインを介して Velero と連携することが知られていますが、サポートされておらず、Red Hat によってテストされていません。
- IBM Cloud
- Oracle Cloud
- DigitalOcean
- NooBaa (Multicloud Object Gateway (MCG) を使用してインストールされていない場合)
- Tencent Cloud
- Ceph RADOS v12.2.7
- Quobyte
- Cloudian HyperStore
特に指定のない限り、"NooBaa" は軽量オブジェクトストレージを提供するオープンソースプロジェクトを指し、"Multicloud Object Gateway (MCG)" は NooBaa の Red Hat ディストリビューションを指します。
MCG の詳細は、アプリケーションを使用して Multicloud Object Gateway にアクセスする を参照してください。
4.4.1.1.3. 既知の制限があるバックアップストレージプロバイダー
次の AWS S3 互換オブジェクトストレージプロバイダーは、AWS プラグインを介して Velero と連携することがわかっていますが、機能セットが制限されています。
- Swift - バックアップストレージのバックアップ保存場所として使用できますが、ファイルシステムベースのボリュームバックアップおよび復元については Restic と互換性がありません。
4.4.1.2. OpenShift Data Foundation で障害復旧を行うための Multicloud Object Gateway (MCG) 設定
OpenShift Data Foundation 上の MCG バケット backupStorageLocation
にクラスターストレージを使用する場合は、MCG を外部オブジェクトストアとして設定します。
MCG を外部オブジェクトストアとして設定しない場合、バックアップが利用できなくなる可能性があります。
特に指定のない限り、"NooBaa" は軽量オブジェクトストレージを提供するオープンソースプロジェクトを指し、"Multicloud Object Gateway (MCG)" は NooBaa の Red Hat ディストリビューションを指します。
MCG の詳細は、アプリケーションを使用して Multicloud Object Gateway にアクセスする を参照してください。
手順
- ハイブリッドまたはマルチクラウドのストレージリソースの追加 の説明に従って、MCG を外部オブジェクトストアとして設定します。
4.4.1.3. OADP 更新チャネルについて
OADP Operator をインストールするときに、更新チャネル を選択します。このチャネルにより、OADP Operator と Velero のどちらのアップグレードを受け取るかが決まります。いつでもチャンネルを切り替えることができます。
次の更新チャネルを利用できます。
-
stable チャネルは非推奨になりました。stable チャネルには、
OADP.v1.1.z
およびOADP.v1.0.z
の古いバージョン用の OADPClusterServiceVersion
のパッチ (z-stream 更新) が含まれています。 - stable-1.0 チャネルは非推奨であり、サポートされていません。
- stable-1.1 チャネルは非推奨であり、サポートされていません。
- stable-1.2 チャネルは非推奨であり、サポートされていません。
-
stable-1.3 チャネルには、最新の OADP 1.3
ClusterServiceVersion
のOADP.v1.3.z
が含まれています。 -
stable-1.4 チャネルには、最新の OADP 1.4
ClusterServiceVersion
のOADP.v1.4.z
が含まれています。
詳細は、OpenShift Operator のライフサイクル を参照してください。
適切な更新チャネルはどれですか?
-
stable チャネルは非推奨になりました。すでに安定版チャネルを使用している場合は、引き続き、
OADP.v1.1.z
から更新を取得します。 - stable-1.y をインストールする OADP 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.4.1.4. 複数の namespace への OADP のインストール
OADP を同じクラスター上の複数の namespace にインストールすると、複数のプロジェクト所有者が独自の OADP インスタンスを管理できるようになります。このユースケースは Restic および CSI で検証されています。
本書に含まれるプラットフォームごとの手順で指定されている OADP の各インスタンスを、以下の追加要件とともにインストールします。
- 同じクラスター上のすべての OADP デプロイメントは、同じバージョン (1.1.4 など) である必要があります。同じクラスターに異なるバージョンの OADP をインストールすることはサポートされていません。
-
OADP の個々のデプロイメントには、一意の認証情報セットと一意の
BackupStorageLocation
設定が必要です。同じ namespace 内で、複数のBackupStorageLocation
設定を使用することもできます。 - デフォルトでは、各 OADP デプロイメントには namespace 全体でクラスターレベルのアクセス権があります。OpenShift Container Platform 管理者は、セキュリティーおよび RBAC 設定を注意深く確認し、必要な変更を加えて、各 OADP インスタンスに正しい権限があることを確認する必要があります。
関連情報
4.4.1.5. 収集したデータに基づく Velero CPU およびメモリーの要件
以下の推奨事項は、スケールおよびパフォーマンスのラボで観察したパフォーマンスに基づいています。バックアップおよび復元リソースは、プラグインのタイプ、そのバックアップまたは復元に必要なリソースの量、そのリソースに関連する永続ボリューム (PV) に含まれるデータの影響を受けます。
4.4.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.4.1.5.2. 大量使用のための NodeAgent CPU
テストの結果、NodeAgent
CPU を増やすと、OpenShift API for Data Protection (OADP) を使用する際のバックアップと復元の時間が大幅に短縮されることがわかりました。
Kopia はリソースを積極的に消費するため、実稼働環境で実稼働ワークロードを実行しているノードで Kopia を制限なく使用することは推奨されません。ただし、Kopia を実行する際の制限が低すぎると、CPU が制限され、バックアップと復元が遅くなります。テストの結果、20 コアと 32 Gi メモリーで Kopia を実行した場合、100 GB 超のデータ、複数の namespace、または単一 namespace 内の 2000 超の Pod のバックアップと復元操作がサポートされることが判明しました。
テストでは、これらのリソース仕様では CPU の制限やメモリーの飽和は検出されませんでした。
これらの制限を Ceph MDS Pod に設定するには、rook-ceph Pod の CPU およびメモリーリソースの変更 に記載された手順に従ってください。
制限を設定するには、ストレージクラスターのカスタムリソース (CR) に次の行を追加する必要があります。
resources: mds: limits: cpu: "3" memory: 128Gi requests: cpu: "3" memory: 8Gi
4.4.2. OADP Operator のインストール
Operator Lifecycle Manager (OLM) を使用して、OpenShift Container Platform 4.12 に OpenShift API for Data Protection (OADP) Operator をインストールできます。
OADP Operator は Velero 1.12 をインストールします。
前提条件
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- Filter by keyword フィールドを使用して、OADP Operator を検索します。
- OADP Operator を選択し、Install をクリックします。
-
Install をクリックして、
openshift-adp
プロジェクトに Operator をインストールします。 - Operators → Installed Operators をクリックして、インストールを確認します。
4.4.2.1. OADP-Velero-OpenShift Container Platform バージョンの関係
OADP のバージョン | Velero のバージョン | OpenShift Container Platform バージョン |
---|---|---|
1.1.0 | 4.9 以降 | |
1.1.1 | 4.9 以降 | |
1.1.2 | 4.9 以降 | |
1.1.3 | 4.9 以降 | |
1.1.4 | 4.9 以降 | |
1.1.5 | 4.9 以降 | |
1.1.6 | 4.11 以降 | |
1.1.7 | 4.11 以降 | |
1.2.0 | 4.11 以降 | |
1.2.1 | 4.11 以降 | |
1.2.2 | 4.11 以降 | |
1.2.3 | 4.11 以降 | |
1.3.0 | 4.10 - 4.15 | |
1.3.1 | 4.10 - 4.15 | |
1.3.2 | 4.10 - 4.15 | |
1.3.3 | 4.10 - 4.15 |
4.4.3. Amazon Web Services を使用した OpenShift API for Data Protection の設定
OADP Operator をインストールすることで、Amazon Web Services (AWS) を使用して OpenShift API for Data Protection (OADP) をインストールします。Operator は Velero 1.12 をインストールします。
OADP 1.0.4 以降、すべて OADP 1.0.z バージョンは、MTC Operator の依存関係としてのみ使用でき、スタンドアロン Operator としては使用できません。
Velero 向けに AWS を設定し、デフォルトの Secret
を作成し、次に、Data Protection Application をインストールします。詳細は、OADP Operator のインストール を参照してください。
制限されたネットワーク環境に OADP Operator をインストールするには、最初にデフォルトの OperatorHub ソースを無効にして、Operator カタログをミラーリングする必要があります。詳細は、ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。
4.4.3.1. 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.4.3.2. バックアップおよびスナップショットの場所、ならびにそのシークレットについて
DataProtectionApplication
カスタムリソース (CR) で、バックアップおよびスナップショットの場所、ならびにそのシークレットを指定します。
バックアップの場所
バックアップの場所として、Multicloud Object Gateway、Ceph RADOS Gateway (Ceph Object Gateway とも呼ばれます)、MinIO などの AWS S3 互換オブジェクトストレージを指定します。
Velero は、オブジェクトストレージのアーカイブファイルとして、OpenShift Container Platform リソース、Kubernetes オブジェクト、および内部イメージをバックアップします。
スナップショットの場所
クラウドプロバイダーのネイティブスナップショット API を使用して永続ボリュームをバックアップする場合、クラウドプロバイダーをスナップショットの場所として指定する必要があります。
Container Storage Interface (CSI) スナップショットを使用する場合、CSI ドライバーを登録するために VolumeSnapshotClass
CR を作成するため、スナップショットの場所を指定する必要はありません。
Restic を使用する場合は、Restic がオブジェクトストレージにファイルシステムをバックアップするため、スナップショットの場所を指定する必要はありません。
シークレット
バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret
を作成します。
バックアップとスナップショットの場所で異なる認証情報を使用する場合は、次の 2 つの secret オブジェクトを作成します。
-
DataProtectionApplication
CR で指定する、バックアップの場所用のカスタムSecret
。 -
DataProtectionApplication
CR で参照されない、スナップショットの場所用のデフォルトSecret
。
Data Protection Application には、デフォルトの Secret
が必要です。作成しないと、インストールは失敗します。
インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の credentials-velero
ファイルを使用してデフォルトの Secret
を作成できます。
4.4.3.2.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.4.3.2.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
次の例のように、プロファイルを
DataProtectionApplication
CR に追加します。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: - velero: provider: aws config: region: us-west-2 profile: "volumeSnapshot"
4.4.3.3. Data Protection Application の設定
Velero リソースの割り当てを設定するか、自己署名 CA 証明書を有効にして、Data Protection Application を設定できます。
4.4.3.3.1. Velero の CPU とメモリーのリソース割り当てを設定
DataProtectionApplication
カスタムリソース (CR) マニフェストを編集して、Velero
Pod の CPU およびメモリーリソースの割り当てを設定します。
前提条件
- OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。
手順
次の例のように、
DataProtectionApplication
CR マニフェストの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
nodeSelector
フィールドを使用して、ノードエージェントを実行できるノードを選択します。nodeSelector
フィールドは、推奨される最も単純な形式のノード選択制約です。指定したラベルが、各ノードのラベルと一致する必要があります。
詳細は、ノードエージェントとノードラベルの設定 を参照してください。
4.4.3.3.2. 自己署名 CA 証明書の有効化
certificate signed by unknown authority
エラーを防ぐために、DataProtectionApplication
カスタムリソース (CR) マニフェストを編集して、オブジェクトストレージの自己署名 CA 証明書を有効にする必要があります。
前提条件
- OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。
手順
DataProtectionApplication
CR マニフェストの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.4.3.4. 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
がない場合、インストールは失敗します。注記Velero は、OADP namespace に
velero-repo-credentials
という名前のシークレットを作成します。これには、デフォルトのバックアップリポジトリーパスワードが含まれます。バックアップリポジトリーを対象とした最初のバックアップを実行する 前 に、base64 としてエンコードされた独自のパスワードを使用してシークレットを更新できます。更新するキーの値はData[repository-password]
です。DPA を作成した後、バックアップリポジトリーを対象としたバックアップを初めて実行するときに、Velero はシークレットが
velero-repo-credentials
のバックアップリポジトリーを作成します。これには、デフォルトのパスワードまたは置き換えたパスワードが含まれます。最初のバックアップの 後 にシークレットパスワードを更新すると、新しいパスワードがvelero-repo-credentials
のパスワードと一致しなくなり、Velero は古いバックアップに接続できなくなります。
手順
- 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 - velero: provider: aws config: region: <region> 9 profile: "default"
- 1
openshift
プラグインは必須です。- 2
- Velero CRD の可用性、volumeSnapshot の削除、バックアップリポジトリーの可用性など、タイムアウトが発生するまでに複数の Velero リソースを待機する時間を分単位で指定します。デフォルトは 10m です。
- 3
- Restic インストールを無効にする場合は、この値を
false
に設定します。Restic はデーモンセットをデプロイします。これは、Restic Pod が各動作ノードで実行していることを意味します。OADP バージョン 1.2 以降では、spec.defaultVolumesToFsBackup: true
をBackup
CR に追加することで、バックアップ用に Restic を設定できます。OADP バージョン 1.1 では、spec.defaultVolumesToRestic: true
をBackup
CR に追加します。 - 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.4.3.4.1. ノードエージェントとノードラベルの設定
OADP の DPA は、nodeSelector
フィールドを使用して、ノードエージェントを実行できるノードを選択します。nodeSelector
フィールドは、推奨される最も単純な形式のノード選択制約です。
指定したラベルが、各ノードのラベルと一致する必要があります。
選択した任意のノードでノードエージェントを実行する正しい方法は、ノードにカスタムラベルを付けることです。
$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
ノードのラベル付けに使用したのと同じカスタムラベルを DPA.spec.configuration.nodeAgent.podConfig.nodeSelector
で使用します。以下に例を示します。
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/nodeAgent: ""
次の例は nodeSelector
のアンチパターンです。この例は、ノードに 'node-role.kubernetes.io/infra: ""'
と 'node-role.kubernetes.io/worker: ""'
の両方のラベルがないと機能しません。
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/infra: "" node-role.kubernetes.io/worker: ""
4.4.3.4.2. DataProtectionApplication CR で CSI を有効にする
CSI スナップショットを使用して永続ボリュームをバックアップするには、DataProtectionApplication
カスタムリソース (CR) で Container Storage Interface (CSI) を有効にします。
前提条件
- クラウドプロバイダーは、CSI スナップショットをサポートする必要があります。
手順
次の例のように、
DataProtectionApplication
CR を編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication ... spec: configuration: velero: defaultPlugins: - openshift - csi 1
- 1
csi
デフォルトプラグインを追加します。
4.4.4. Microsoft Azure を使用した OpenShift API for Data Protection の設定
OADP Operator をインストールすることで、Microsoft Azure を使用して OpenShift API for Data Protection (OADP) をインストールします。Operator は Velero 1.12 をインストールします。
OADP 1.0.4 以降、すべて OADP 1.0.z バージョンは、MTC Operator の依存関係としてのみ使用でき、スタンドアロン Operator としては使用できません。
Velero 向けに Azure を設定し、デフォルトの Secret
を作成し、次に、Data Protection Application をインストールします。詳細は、OADP Operator のインストール を参照してください。
制限されたネットワーク環境に OADP Operator をインストールするには、最初にデフォルトの OperatorHub ソースを無効にして、Operator カタログをミラーリングする必要があります。詳細は、ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。
4.4.4.1. Microsoft Azure の設定
OpenShift API for Data Protection (OADP) 用に Microsoft Azure を設定します。
前提条件
- Azure CLI がインストールされていること。
Azure サービスを使用するツールには、Azure リソースの安全を確保するために、必ず制限された権限を付与する必要があります。そのため、Azure では、アプリケーションを完全な権限を持つユーザーとしてサインインさせる代わりに、サービスプリンシパルを提供しています。Azure サービスプリンシパルは、アプリケーション、ホストされたサービス、または自動化ツールで使用できる名前です。
このアイデンティティーはリソースへのアクセスに使用されます。
- サービスプリンシパルを作成する
- サービスプリンシパルとパスワードを使用してサインインする
- サービスプリンシパルと証明書を使用してサインインする
- サービスプリンシパルのロールを管理する
- サービスプリンシパルを使用して Azure リソースを作成する
- サービスプリンシパルの認証情報をリセットする
詳細は、Create an Azure service principal with Azure CLI を参照してください。
4.4.4.2. バックアップおよびスナップショットの場所、ならびにそのシークレットについて
DataProtectionApplication
カスタムリソース (CR) で、バックアップおよびスナップショットの場所、ならびにそのシークレットを指定します。
バックアップの場所
バックアップの場所として、Multicloud Object Gateway、Ceph RADOS Gateway (Ceph Object Gateway とも呼ばれます)、MinIO などの AWS S3 互換オブジェクトストレージを指定します。
Velero は、オブジェクトストレージのアーカイブファイルとして、OpenShift Container Platform リソース、Kubernetes オブジェクト、および内部イメージをバックアップします。
スナップショットの場所
クラウドプロバイダーのネイティブスナップショット API を使用して永続ボリュームをバックアップする場合、クラウドプロバイダーをスナップショットの場所として指定する必要があります。
Container Storage Interface (CSI) スナップショットを使用する場合、CSI ドライバーを登録するために VolumeSnapshotClass
CR を作成するため、スナップショットの場所を指定する必要はありません。
Restic を使用する場合は、Restic がオブジェクトストレージにファイルシステムをバックアップするため、スナップショットの場所を指定する必要はありません。
シークレット
バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret
を作成します。
バックアップとスナップショットの場所で異なる認証情報を使用する場合は、次の 2 つの secret オブジェクトを作成します。
-
DataProtectionApplication
CR で指定する、バックアップの場所用のカスタムSecret
。 -
DataProtectionApplication
CR で参照されない、スナップショットの場所用のデフォルトSecret
。
Data Protection Application には、デフォルトの Secret
が必要です。作成しないと、インストールは失敗します。
インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の credentials-velero
ファイルを使用してデフォルトの Secret
を作成できます。
4.4.4.2.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.4.4.2.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" provider: azure
- 1
- カスタム名を持つバックアップロケーションの
Secret
。
4.4.4.3. Data Protection Application の設定
Velero リソースの割り当てを設定するか、自己署名 CA 証明書を有効にして、Data Protection Application を設定できます。
4.4.4.3.1. Velero の CPU とメモリーのリソース割り当てを設定
DataProtectionApplication
カスタムリソース (CR) マニフェストを編集して、Velero
Pod の CPU およびメモリーリソースの割り当てを設定します。
前提条件
- OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。
手順
次の例のように、
DataProtectionApplication
CR マニフェストの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
nodeSelector
フィールドを使用して、ノードエージェントを実行できるノードを選択します。nodeSelector
フィールドは、推奨される最も単純な形式のノード選択制約です。指定したラベルが、各ノードのラベルと一致する必要があります。
詳細は、ノードエージェントとノードラベルの設定 を参照してください。
4.4.4.3.2. 自己署名 CA 証明書の有効化
certificate signed by unknown authority
エラーを防ぐために、DataProtectionApplication
カスタムリソース (CR) マニフェストを編集して、オブジェクトストレージの自己署名 CA 証明書を有効にする必要があります。
前提条件
- OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。
手順
DataProtectionApplication
CR マニフェストの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.4.4.4. 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
をDataProtectionApplication
CR に追加します。 スナップショットの場所のデフォルト名
cloud-credentials-azure
のSecret
。このSecret
は、DataProtectionApplication
CR では参照されません。注記インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の
credentials-velero
ファイルを使用してデフォルトのSecret
を作成できます。デフォルトのSecret
がない場合、インストールは失敗します。注記Velero は、OADP namespace に
velero-repo-credentials
という名前のシークレットを作成します。これには、デフォルトのバックアップリポジトリーパスワードが含まれます。バックアップリポジトリーを対象とした最初のバックアップを実行する 前 に、base64 としてエンコードされた独自のパスワードを使用してシークレットを更新できます。更新するキーの値はData[repository-password]
です。DPA を作成した後、バックアップリポジトリーを対象としたバックアップを初めて実行するときに、Velero はシークレットが
velero-repo-credentials
のバックアップリポジトリーを作成します。これには、デフォルトのパスワードまたは置き換えたパスワードが含まれます。最初のバックアップの 後 にシークレットパスワードを更新すると、新しいパスワードがvelero-repo-credentials
のパスワードと一致しなくなり、Velero は古いバックアップに接続できなくなります。
-
バックアップの場所用のカスタム名を持つ
手順
- 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 はデーモンセットをデプロイします。これは、Restic Pod が各動作ノードで実行していることを意味します。OADP バージョン 1.2 以降では、spec.defaultVolumesToFsBackup: true
をBackup
CR に追加することで、バックアップ用に Restic を設定できます。OADP バージョン 1.1 では、spec.defaultVolumesToRestic: true
をBackup
CR に追加します。 - 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.4.4.4.1. ノードエージェントとノードラベルの設定
OADP の DPA は、nodeSelector
フィールドを使用して、ノードエージェントを実行できるノードを選択します。nodeSelector
フィールドは、推奨される最も単純な形式のノード選択制約です。
指定したラベルが、各ノードのラベルと一致する必要があります。
選択した任意のノードでノードエージェントを実行する正しい方法は、ノードにカスタムラベルを付けることです。
$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
ノードのラベル付けに使用したのと同じカスタムラベルを DPA.spec.configuration.nodeAgent.podConfig.nodeSelector
で使用します。以下に例を示します。
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/nodeAgent: ""
次の例は nodeSelector
のアンチパターンです。この例は、ノードに 'node-role.kubernetes.io/infra: ""'
と 'node-role.kubernetes.io/worker: ""'
の両方のラベルがないと機能しません。
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/infra: "" node-role.kubernetes.io/worker: ""
4.4.4.4.2. DataProtectionApplication CR で CSI を有効にする
CSI スナップショットを使用して永続ボリュームをバックアップするには、DataProtectionApplication
カスタムリソース (CR) で Container Storage Interface (CSI) を有効にします。
前提条件
- クラウドプロバイダーは、CSI スナップショットをサポートする必要があります。
手順
次の例のように、
DataProtectionApplication
CR を編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication ... spec: configuration: velero: defaultPlugins: - openshift - csi 1
- 1
csi
デフォルトプラグインを追加します。
4.4.5. Google Cloud Platform を使用した OpenShift API for Data Protection の設定
OADP Operator をインストールすることで、Google Cloud Platform (GCP) を使用して OpenShift API for Data Protection (OADP) をインストールします。Operator は Velero 1.12 をインストールします。
OADP 1.0.4 以降、すべて OADP 1.0.z バージョンは、MTC Operator の依存関係としてのみ使用でき、スタンドアロン Operator としては使用できません。
Velero 向けに GCP を設定し、デフォルトの Secret
を作成し、次に、Data Protection Application をインストールします。詳細は、OADP Operator のインストール を参照してください。
制限されたネットワーク環境に OADP Operator をインストールするには、最初にデフォルトの OperatorHub ソースを無効にして、Operator カタログをミラーリングする必要があります。詳細は、ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。
4.4.5.1. Google Cloud Platform の設定
OpenShift API for Data Protection (OADP) 用に Google Cloud Platform (GCP) を設定します。
前提条件
-
gcloud
およびgsutil
CLI ツールがインストールされている必要があります。詳細は、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.server
IAM サービスアカウントを更新します。
$ 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_EMAIL
Data Protection Application をインストールする前に、
credentials-velero
ファイルを使用して GCP のSecret
オブジェクトを作成します。
4.4.5.2. バックアップおよびスナップショットの場所、ならびにそのシークレットについて
DataProtectionApplication
カスタムリソース (CR) で、バックアップおよびスナップショットの場所、ならびにそのシークレットを指定します。
バックアップの場所
バックアップの場所として、Multicloud Object Gateway、Ceph RADOS Gateway (Ceph Object Gateway とも呼ばれます)、MinIO などの AWS S3 互換オブジェクトストレージを指定します。
Velero は、オブジェクトストレージのアーカイブファイルとして、OpenShift Container Platform リソース、Kubernetes オブジェクト、および内部イメージをバックアップします。
スナップショットの場所
クラウドプロバイダーのネイティブスナップショット API を使用して永続ボリュームをバックアップする場合、クラウドプロバイダーをスナップショットの場所として指定する必要があります。
Container Storage Interface (CSI) スナップショットを使用する場合、CSI ドライバーを登録するために VolumeSnapshotClass
CR を作成するため、スナップショットの場所を指定する必要はありません。
Restic を使用する場合は、Restic がオブジェクトストレージにファイルシステムをバックアップするため、スナップショットの場所を指定する必要はありません。
シークレット
バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret
を作成します。
バックアップとスナップショットの場所で異なる認証情報を使用する場合は、次の 2 つの secret オブジェクトを作成します。
-
DataProtectionApplication
CR で指定する、バックアップの場所用のカスタムSecret
。 -
DataProtectionApplication
CR で参照されない、スナップショットの場所用のデフォルトSecret
。
Data Protection Application には、デフォルトの Secret
が必要です。作成しないと、インストールは失敗します。
インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の credentials-velero
ファイルを使用してデフォルトの Secret
を作成できます。
4.4.5.2.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.4.5.2.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.4.5.3. Data Protection Application の設定
Velero リソースの割り当てを設定するか、自己署名 CA 証明書を有効にして、Data Protection Application を設定できます。
4.4.5.3.1. Velero の CPU とメモリーのリソース割り当てを設定
DataProtectionApplication
カスタムリソース (CR) マニフェストを編集して、Velero
Pod の CPU およびメモリーリソースの割り当てを設定します。
前提条件
- OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。
手順
次の例のように、
DataProtectionApplication
CR マニフェストの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
nodeSelector
フィールドを使用して、ノードエージェントを実行できるノードを選択します。nodeSelector
フィールドは、推奨される最も単純な形式のノード選択制約です。指定したラベルが、各ノードのラベルと一致する必要があります。
詳細は、ノードエージェントとノードラベルの設定 を参照してください。
4.4.5.3.2. 自己署名 CA 証明書の有効化
certificate signed by unknown authority
エラーを防ぐために、DataProtectionApplication
カスタムリソース (CR) マニフェストを編集して、オブジェクトストレージの自己署名 CA 証明書を有効にする必要があります。
前提条件
- OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。
手順
DataProtectionApplication
CR マニフェストの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.4.5.4. 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
をDataProtectionApplication
CR に追加します。 スナップショットの場所として、デフォルト名
cloud-credentials-gcp
のSecret
。このSecret
は、DataProtectionApplication
CR では参照されません。注記インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の
credentials-velero
ファイルを使用してデフォルトのSecret
を作成できます。デフォルトのSecret
がない場合、インストールは失敗します。注記Velero は、OADP namespace に
velero-repo-credentials
という名前のシークレットを作成します。これには、デフォルトのバックアップリポジトリーパスワードが含まれます。バックアップリポジトリーを対象とした最初のバックアップを実行する 前 に、base64 としてエンコードされた独自のパスワードを使用してシークレットを更新できます。更新するキーの値はData[repository-password]
です。DPA を作成した後、バックアップリポジトリーを対象としたバックアップを初めて実行するときに、Velero はシークレットが
velero-repo-credentials
のバックアップリポジトリーを作成します。これには、デフォルトのパスワードまたは置き換えたパスワードが含まれます。最初のバックアップの 後 にシークレットパスワードを更新すると、新しいパスワードがvelero-repo-credentials
のパスワードと一致しなくなり、Velero は古いバックアップに接続できなくなります。
-
バックアップの場所用のカスタム名を持つ
手順
- 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 はデーモンセットをデプロイします。これは、Restic Pod が各動作ノードで実行していることを意味します。OADP バージョン 1.2 以降では、spec.defaultVolumesToFsBackup: true
をBackup
CR に追加することで、バックアップ用に Restic を設定できます。OADP バージョン 1.1 では、spec.defaultVolumesToRestic: true
をBackup
CR に追加します。 - 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.4.5.4.1. ノードエージェントとノードラベルの設定
OADP の DPA は、nodeSelector
フィールドを使用して、ノードエージェントを実行できるノードを選択します。nodeSelector
フィールドは、推奨される最も単純な形式のノード選択制約です。
指定したラベルが、各ノードのラベルと一致する必要があります。
選択した任意のノードでノードエージェントを実行する正しい方法は、ノードにカスタムラベルを付けることです。
$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
ノードのラベル付けに使用したのと同じカスタムラベルを DPA.spec.configuration.nodeAgent.podConfig.nodeSelector
で使用します。以下に例を示します。
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/nodeAgent: ""
次の例は nodeSelector
のアンチパターンです。この例は、ノードに 'node-role.kubernetes.io/infra: ""'
と 'node-role.kubernetes.io/worker: ""'
の両方のラベルがないと機能しません。
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/infra: "" node-role.kubernetes.io/worker: ""
4.4.5.4.2. DataProtectionApplication CR で CSI を有効にする
CSI スナップショットを使用して永続ボリュームをバックアップするには、DataProtectionApplication
カスタムリソース (CR) で Container Storage Interface (CSI) を有効にします。
前提条件
- クラウドプロバイダーは、CSI スナップショットをサポートする必要があります。
手順
次の例のように、
DataProtectionApplication
CR を編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication ... spec: configuration: velero: defaultPlugins: - openshift - csi 1
- 1
csi
デフォルトプラグインを追加します。
4.4.6. Multicloud Object Gateway を使用した OpenShift API for Data Protection の設定
OADP Operator をインストールすることで、Multicloud Object Gateway (MCG) を使用して OpenShift API for Data Protection (OADP) をインストールします。Operator は Velero 1.12 をインストールします。
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 のインストール を参照してください。
制限されたネットワーク環境に OADP Operator をインストールするには、最初にデフォルトの OperatorHub ソースを無効にして、Operator カタログをミラーリングする必要があります。詳細は、ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。
4.4.6.1. 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.4.6.2. バックアップおよびスナップショットの場所、ならびにそのシークレットについて
DataProtectionApplication
カスタムリソース (CR) で、バックアップおよびスナップショットの場所、ならびにそのシークレットを指定します。
バックアップの場所
バックアップの場所として、Multicloud Object Gateway、Ceph RADOS Gateway (Ceph Object Gateway とも呼ばれます)、MinIO などの AWS S3 互換オブジェクトストレージを指定します。
Velero は、オブジェクトストレージのアーカイブファイルとして、OpenShift Container Platform リソース、Kubernetes オブジェクト、および内部イメージをバックアップします。
スナップショットの場所
クラウドプロバイダーのネイティブスナップショット API を使用して永続ボリュームをバックアップする場合、クラウドプロバイダーをスナップショットの場所として指定する必要があります。
Container Storage Interface (CSI) スナップショットを使用する場合、CSI ドライバーを登録するために VolumeSnapshotClass
CR を作成するため、スナップショットの場所を指定する必要はありません。
Restic を使用する場合は、Restic がオブジェクトストレージにファイルシステムをバックアップするため、スナップショットの場所を指定する必要はありません。
シークレット
バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret
を作成します。
バックアップとスナップショットの場所で異なる認証情報を使用する場合は、次の 2 つの secret オブジェクトを作成します。
-
DataProtectionApplication
CR で指定する、バックアップの場所用のカスタムSecret
。 -
DataProtectionApplication
CR で参照されない、スナップショットの場所用のデフォルトSecret
。
Data Protection Application には、デフォルトの Secret
が必要です。作成しないと、インストールは失敗します。
インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の credentials-velero
ファイルを使用してデフォルトの Secret
を作成できます。
4.4.6.2.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.4.6.2.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.4.6.3. Data Protection Application の設定
Velero リソースの割り当てを設定するか、自己署名 CA 証明書を有効にして、Data Protection Application を設定できます。
4.4.6.3.1. Velero の CPU とメモリーのリソース割り当てを設定
DataProtectionApplication
カスタムリソース (CR) マニフェストを編集して、Velero
Pod の CPU およびメモリーリソースの割り当てを設定します。
前提条件
- OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。
手順
次の例のように、
DataProtectionApplication
CR マニフェストの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
nodeSelector
フィールドを使用して、ノードエージェントを実行できるノードを選択します。nodeSelector
フィールドは、推奨される最も単純な形式のノード選択制約です。指定したラベルが、各ノードのラベルと一致する必要があります。
詳細は、ノードエージェントとノードラベルの設定 を参照してください。
4.4.6.3.2. 自己署名 CA 証明書の有効化
certificate signed by unknown authority
エラーを防ぐために、DataProtectionApplication
カスタムリソース (CR) マニフェストを編集して、オブジェクトストレージの自己署名 CA 証明書を有効にする必要があります。
前提条件
- OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。
手順
DataProtectionApplication
CR マニフェストの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.4.6.4. Data Protection Application のインストール
DataProtectionApplication
API のインスタンスを作成して、Data Protection Application (DPA) をインストールします。
前提条件
- OADP Operator をインストールする。
- オブジェクトストレージをバックアップロケーションとして設定する必要がある。
- スナップショットを使用して PV をバックアップする場合、クラウドプロバイダーはネイティブスナップショット API または Container Storage Interface (CSI) スナップショットのいずれかをサポートする必要がある。
-
バックアップとスナップショットの場所で同じ認証情報を使用する場合は、デフォルトの名前である
cloud-credentials
を使用してSecret
を作成する必要がある。 バックアップとスナップショットの場所で異なる認証情報を使用する場合は、以下のように 2 つの
Secrets
を作成する必要がある。-
バックアップの場所用のカスタム名を持つ
Secret
。このSecret
をDataProtectionApplication
CR に追加します。 スナップショットの場所のデフォルト名である
cloud-credentials
のSecret
。このSecret
は、DataProtectionApplication
CR では参照されません。注記インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の
credentials-velero
ファイルを使用してデフォルトのSecret
を作成できます。デフォルトのSecret
がない場合、インストールは失敗します。注記Velero は、OADP namespace に
velero-repo-credentials
という名前のシークレットを作成します。これには、デフォルトのバックアップリポジトリーパスワードが含まれます。バックアップリポジトリーを対象とした最初のバックアップを実行する 前 に、base64 としてエンコードされた独自のパスワードを使用してシークレットを更新できます。更新するキーの値はData[repository-password]
です。DPA を作成した後、バックアップリポジトリーを対象としたバックアップを初めて実行するときに、Velero はシークレットが
velero-repo-credentials
のバックアップリポジトリーを作成します。これには、デフォルトのパスワードまたは置き換えたパスワードが含まれます。最初のバックアップの 後 にシークレットパスワードを更新すると、新しいパスワードがvelero-repo-credentials
のパスワードと一致しなくなり、Velero は古いバックアップに接続できなくなります。
-
バックアップの場所用のカスタム名を持つ
手順
- 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 はデーモンセットをデプロイします。これは、Restic Pod が各動作ノードで実行していることを意味します。OADP バージョン 1.2 以降では、spec.defaultVolumesToFsBackup: true
をBackup
CR に追加することで、バックアップ用に Restic を設定できます。OADP バージョン 1.1 では、spec.defaultVolumesToRestic: true
をBackup
CR に追加します。 - 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.4.6.4.1. ノードエージェントとノードラベルの設定
OADP の DPA は、nodeSelector
フィールドを使用して、ノードエージェントを実行できるノードを選択します。nodeSelector
フィールドは、推奨される最も単純な形式のノード選択制約です。
指定したラベルが、各ノードのラベルと一致する必要があります。
選択した任意のノードでノードエージェントを実行する正しい方法は、ノードにカスタムラベルを付けることです。
$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
ノードのラベル付けに使用したのと同じカスタムラベルを DPA.spec.configuration.nodeAgent.podConfig.nodeSelector
で使用します。以下に例を示します。
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/nodeAgent: ""
次の例は nodeSelector
のアンチパターンです。この例は、ノードに 'node-role.kubernetes.io/infra: ""'
と 'node-role.kubernetes.io/worker: ""'
の両方のラベルがないと機能しません。
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/infra: "" node-role.kubernetes.io/worker: ""
4.4.6.4.2. DataProtectionApplication CR で CSI を有効にする
CSI スナップショットを使用して永続ボリュームをバックアップするには、DataProtectionApplication
カスタムリソース (CR) で Container Storage Interface (CSI) を有効にします。
前提条件
- クラウドプロバイダーは、CSI スナップショットをサポートする必要があります。
手順
次の例のように、
DataProtectionApplication
CR を編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication ... spec: configuration: velero: defaultPlugins: - openshift - csi 1
- 1
csi
デフォルトプラグインを追加します。
4.4.7. 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 のインストール を参照してください。
制限されたネットワーク環境に OADP Operator をインストールするには、最初にデフォルトの OperatorHub ソースを無効にして、Operator カタログをミラーリングする必要があります。詳細は、ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。
4.4.7.1. バックアップおよびスナップショットの場所、ならびにそのシークレットについて
DataProtectionApplication
カスタムリソース (CR) で、バックアップおよびスナップショットの場所、ならびにそのシークレットを指定します。
バックアップの場所
バックアップの場所として、Multicloud Object Gateway、Ceph RADOS Gateway (Ceph Object Gateway とも呼ばれます)、MinIO などの AWS S3 互換オブジェクトストレージを指定します。
Velero は、オブジェクトストレージのアーカイブファイルとして、OpenShift Container Platform リソース、Kubernetes オブジェクト、および内部イメージをバックアップします。
スナップショットの場所
クラウドプロバイダーのネイティブスナップショット API を使用して永続ボリュームをバックアップする場合、クラウドプロバイダーをスナップショットの場所として指定する必要があります。
Container Storage Interface (CSI) スナップショットを使用する場合、CSI ドライバーを登録するために VolumeSnapshotClass
CR を作成するため、スナップショットの場所を指定する必要はありません。
Restic を使用する場合は、Restic がオブジェクトストレージにファイルシステムをバックアップするため、スナップショットの場所を指定する必要はありません。
シークレット
バックアップとスナップショットの場所が同じ認証情報を使用する場合、またはスナップショットの場所が必要ない場合は、デフォルトの Secret
を作成します。
バックアップとスナップショットの場所で異なる認証情報を使用する場合は、次の 2 つの secret オブジェクトを作成します。
-
DataProtectionApplication
CR で指定する、バックアップの場所用のカスタムSecret
。 -
DataProtectionApplication
CR で参照されない、スナップショットの場所用のデフォルトSecret
。
Data Protection Application には、デフォルトの Secret
が必要です。作成しないと、インストールは失敗します。
インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の credentials-velero
ファイルを使用してデフォルトの Secret
を作成できます。
4.4.7.1.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.4.7.1.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: gcp default: true credential: key: cloud name: <custom_secret> 1 objectStorage: bucket: <bucket_name> prefix: <prefix>
- 1
- カスタム名を持つバックアップロケーションの
Secret
。
4.4.7.2. Data Protection Application の設定
Velero リソースの割り当てを設定するか、自己署名 CA 証明書を有効にして、Data Protection Application を設定できます。
4.4.7.2.1. Velero の CPU とメモリーのリソース割り当てを設定
DataProtectionApplication
カスタムリソース (CR) マニフェストを編集して、Velero
Pod の CPU およびメモリーリソースの割り当てを設定します。
前提条件
- OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。
手順
次の例のように、
DataProtectionApplication
CR マニフェストの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
nodeSelector
フィールドを使用して、ノードエージェントを実行できるノードを選択します。nodeSelector
フィールドは、推奨される最も単純な形式のノード選択制約です。指定したラベルが、各ノードのラベルと一致する必要があります。
詳細は、ノードエージェントとノードラベルの設定 を参照してください。
4.4.7.2.1.1. 収集したデータに基づき Ceph の CPU およびメモリー要件を調整する
以下の推奨事項は、スケールおよびパフォーマンスのラボで観察したパフォーマンスに基づいています。この変更は、特に {odf-first} に関連します。ODF を使用する場合は、適切なチューニングガイドで公式の推奨事項を確認してください。
4.4.7.2.1.1.1. 設定に必要な CPU とメモリー
バックアップおよび復元操作には、大量の CephFS PersistentVolumes
(PV) が必要です。out-of-memory
(OOM) エラーによる Ceph MDS Pod の再起動を回避するためには、次の設定が推奨されます。
設定タイプ | 要求 | 上限 |
---|---|---|
CPU | 要求が 3 に変更されました | 上限は 3 |
メモリー | 要求が 8 Gi に変更されました | 上限は 128 Gi |
4.4.7.2.2. 自己署名 CA 証明書の有効化
certificate signed by unknown authority
エラーを防ぐために、DataProtectionApplication
カスタムリソース (CR) マニフェストを編集して、オブジェクトストレージの自己署名 CA 証明書を有効にする必要があります。
前提条件
- OpenShift API for Data Protection (OADP) Operator がインストールされている必要があります。
手順
DataProtectionApplication
CR マニフェストの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.4.7.3. Data Protection Application のインストール
DataProtectionApplication
API のインスタンスを作成して、Data Protection Application (DPA) をインストールします。
前提条件
- OADP Operator をインストールする。
- オブジェクトストレージをバックアップロケーションとして設定する必要がある。
- スナップショットを使用して PV をバックアップする場合、クラウドプロバイダーはネイティブスナップショット API または Container Storage Interface (CSI) スナップショットのいずれかをサポートする必要がある。
-
バックアップとスナップショットの場所で同じ認証情報を使用する場合は、デフォルトの名前である
cloud-credentials
を使用してSecret
を作成する必要がある。 バックアップとスナップショットの場所で異なる認証情報を使用する場合は、以下のように 2 つの
Secrets
を作成する必要がある。-
バックアップの場所用のカスタム名を持つ
Secret
。このSecret
をDataProtectionApplication
CR に追加します。 スナップショットの場所のデフォルト名である
cloud-credentials
のSecret
。このSecret
は、DataProtectionApplication
CR では参照されません。注記インストール中にバックアップまたはスナップショットの場所を指定したくない場合は、空の
credentials-velero
ファイルを使用してデフォルトのSecret
を作成できます。デフォルトのSecret
がない場合、インストールは失敗します。注記Velero は、OADP namespace に
velero-repo-credentials
という名前のシークレットを作成します。これには、デフォルトのバックアップリポジトリーパスワードが含まれます。バックアップリポジトリーを対象とした最初のバックアップを実行する 前 に、base64 としてエンコードされた独自のパスワードを使用してシークレットを更新できます。更新するキーの値はData[repository-password]
です。DPA を作成した後、バックアップリポジトリーを対象としたバックアップを初めて実行するときに、Velero はシークレットが
velero-repo-credentials
のバックアップリポジトリーを作成します。これには、デフォルトのパスワードまたは置き換えたパスワードが含まれます。最初のバックアップの 後 にシークレットパスワードを更新すると、新しいパスワードがvelero-repo-credentials
のパスワードと一致しなくなり、Velero は古いバックアップに接続できなくなります。
-
バックアップの場所用のカスタム名を持つ
手順
- 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: gcp 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 はデーモンセットをデプロイします。これは、Restic Pod が各動作ノードで実行していることを意味します。OADP バージョン 1.2 以降では、spec.defaultVolumesToFsBackup: true
をBackup
CR に追加することで、バックアップ用に Restic を設定できます。OADP バージョン 1.1 では、spec.defaultVolumesToRestic: true
をBackup
CR に追加します。 - 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.4.7.3.1. ノードエージェントとノードラベルの設定
OADP の DPA は、nodeSelector
フィールドを使用して、ノードエージェントを実行できるノードを選択します。nodeSelector
フィールドは、推奨される最も単純な形式のノード選択制約です。
指定したラベルが、各ノードのラベルと一致する必要があります。
選択した任意のノードでノードエージェントを実行する正しい方法は、ノードにカスタムラベルを付けることです。
$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
ノードのラベル付けに使用したのと同じカスタムラベルを DPA.spec.configuration.nodeAgent.podConfig.nodeSelector
で使用します。以下に例を示します。
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/nodeAgent: ""
次の例は nodeSelector
のアンチパターンです。この例は、ノードに 'node-role.kubernetes.io/infra: ""'
と 'node-role.kubernetes.io/worker: ""'
の両方のラベルがないと機能しません。
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/infra: "" node-role.kubernetes.io/worker: ""
4.4.7.3.2. OpenShift Data Foundation での障害不復旧用のオブジェクトバケット要求の作成
OpenShift Data Foundation の Multicloud Object Gateway (MCG) バケット backupStorageLocation
にクラスターストレージを使用する場合は、OpenShift Web コンソールを使用して Object Bucket Claim (OBC) を作成します。
Object Bucket Claim (OBC) の設定に失敗すると、バックアップが利用できなくなる可能性があります。
特に指定のない限り、"NooBaa" は軽量オブジェクトストレージを提供するオープンソースプロジェクトを指し、"Multicloud Object Gateway (MCG)" は NooBaa の Red Hat ディストリビューションを指します。
MCG の詳細は、アプリケーションを使用して Multicloud Object Gateway にアクセスする を参照してください。
手順
- OpenShift Web コンソールを使用した Object Bucket Claim の作成 に記載されているとおり、OpenShift Web コンソールを使用して Object Bucket Claim (OBC) を作成します。
4.4.7.3.3. DataProtectionApplication CR で CSI を有効にする
CSI スナップショットを使用して永続ボリュームをバックアップするには、DataProtectionApplication
カスタムリソース (CR) で Container Storage Interface (CSI) を有効にします。
前提条件
- クラウドプロバイダーは、CSI スナップショットをサポートする必要があります。
手順
次の例のように、
DataProtectionApplication
CR を編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication ... spec: configuration: velero: defaultPlugins: - openshift - csi 1
- 1
csi
デフォルトプラグインを追加します。
4.5. OADP のアンインストール
4.5.1. OpenShift API for Data Protection のアンインストール
OpenShift API for Data Protection (OADP) をアンインストールするには、OADP Operator を削除します。詳細は、クラスターからの Operators の削除 を参照してください。
4.6. OADP のバックアップ
4.6.1. アプリケーションのバックアップ
Backup
カスタムリソース (CR) を作成して、アプリケーションをバックアップします。バックアップ CR の作成 を参照してください。
-
Backup
CR は、Kubernetes リソースと内部イメージのバックアップファイルを S3 オブジェクトストレージに作成します。 -
クラウドプロバイダーがネイティブスナップショット API を備えている場合、または CSI スナップショットをサポートしている場合、
Backup
CR はスナップショットを作成することによって永続ボリューム (PV) をバックアップします。CSI スナップショットの操作の詳細は、CSI スナップショットを使用した永続ボリュームのバックアップ を参照してください。
CSI ボリュームスナップショットの詳細は、CSI ボリュームスナップショット を参照してください。
S3 ストレージ用の CloudStorage
API は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
- クラウドプロバイダーがスナップショットをサポートしていない場合、またはアプリケーションが NFS データボリューム上にある場合は、Kopia または Restic を使用してバックアップを作成できます。ファイルシステムバックアップを使用してアプリケーションをバックアップする: Kopia または Restic を参照してください。
…/.snapshot: read-only file system
エラーで失敗する
…/.snapshot
ディレクトリーは、複数の NFS サーバーによって使用されるスナップショットコピーディレクトリーです。このディレクトリーにはデフォルトで読み取り専用アクセスが設定されているため、Velero はこのディレクトリーに復元できません。
Velero に .snapshot
ディレクトリーへの書き込みアクセス権を付与しないでください。また、このディレクトリーへのクライアントアクセスを無効にしてください。
OpenShift API for Data Protection (OADP) は、他のソフトウェアで作成されたボリュームスナップショットのバックアップをサポートしていません。
バックアップ操作の前または後にコマンドを実行するためのバックアップフックを作成できます。バックアップフックの作成 を参照してください。
Backup
CR の代わりに Schedule
CR を作成することにより、バックアップをスケジュールできます。スケジュール CR を使用したバックアップのスケジュール設定 を参照してください。
4.6.1.1. 既知の問題
OpenShift Container Platform 4.14 は、Restic 復元プロセス中に Pod の readiness を妨げる可能性がある Pod セキュリティーアドミッション (PSA) ポリシーを強制します。
この問題は OADP 1.1.6 および OADP 1.2.2 リリースで解決されており、これらのリリースにアップグレードすることが推奨されます。
詳細は、PSA ポリシーの変更により、OCP 4.14 で部分的に Restic 復元が失敗する を参照してください。
4.6.2. Backup CR の作成
Backup
カスタムリソース (CR) を作成して、Kubernetes リソース、内部イメージ、永続ボリューム (PV) をバックアップします。
前提条件
- OpenShift API for Data Protection (OADP) Operator をインストールしている。
-
DataProtectionApplication
CR がReady
状態である。 バックアップロケーションの前提条件:
- Velero 用に S3 オブジェクトストレージを設定する必要があります。
-
DataProtectionApplication
CR でバックアップの場所を設定する必要があります。
スナップショットの場所の前提条件:
- クラウドプロバイダーには、ネイティブスナップショット API が必要であるか、Container Storage Interface (CSI) スナップショットをサポートしている必要があります。
-
CSI スナップショットの場合、CSI ドライバーを登録するために
VolumeSnapshotClass
CR を作成する必要があります。 -
DataProtectionApplication
CR でボリュームの場所を設定する必要があります。
手順
次のコマンドを入力して、
backupStorageLocations
CR を取得します。$ oc get backupStorageLocations -n openshift-adp
出力例
NAMESPACE NAME PHASE LAST VALIDATED AGE DEFAULT openshift-adp velero-sample-1 Available 11s 31m
次の例のように、
Backup
CR を作成します。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
backupStorageLocations
CR の名前を指定します。- 5
- 指定したラベルを すべて 持つバックアップリソースの {key,value} ペアのマップ。
- 6
- 指定したラベルを 1 つ以上 持つバックアップリソースの {key,value} ペアのマップ。
Backup
CR のステータスがCompleted
したことを確認します。$ oc get backup -n openshift-adp <backup> -o jsonpath='{.status.phase}'
4.6.3. CSI スナップショットを使用した永続ボリュームのバックアップ
Backup
CR を作成する前に、クラウドストレージの VolumeSnapshotClass
カスタムリソース (CR) を編集して、Container Storage Interface (CSI) スナップショットを使用して永続ボリュームをバックアップします。CSI ボリュームスナップショット を参照してください。
詳細は、バックアップ CR の作成 を参照してください。
前提条件
- クラウドプロバイダーは、CSI スナップショットをサポートする必要があります。
-
DataProtectionApplication
CR で CSI を有効にする必要があります。
手順
metadata.labels.velero.io/csi-volumesnapshot-class: "true"
のキー: 値ペアをVolumeSnapshotClass
CR に追加します。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.6.4. ファイルシステムバックアップを使用してアプリケーションをバックアップする: Kopia または Restic
OADP を使用して、Pod にアタッチされている Kubernetes ボリュームを、そのボリュームのファイルシステムからバックアップおよび復元できます。このプロセスは、File System Backup (FSB) または Pod Volume Backup (PVB) と呼ばれます。これは、オープンソースのバックアップツール Restic または Kopia のモジュールを使用して実行できます。
クラウドプロバイダーがスナップショットをサポートしていない場合、またはアプリケーションが NFS データボリューム上にある場合は、FSB を使用してバックアップを作成できます。
FSB と OADP の統合により、ほぼすべてのタイプの Kubernetes ボリュームをバックアップおよび復元するためのソリューションが提供されます。この統合は OADP の追加機能であり、既存の機能を置き換えるものではありません。
Backup
カスタムリソース (CR) を編集して、Kopia または Restic で Kubernetes リソース、内部イメージ、および永続ボリュームをバックアップします。
DataProtectionApplication
CR でスナップショットの場所を指定する必要はありません。
OADP バージョン 1.3 以降では、アプリケーションのバックアップに Kopia または Restic を使用できます。
ビルトイン DataMover の場合は、Kopia を使用する必要があります。
OADP バージョン 1.2 以前の場合、アプリケーションのバックアップには Restic のみ使用できます。
FSB は、hostPath
ボリュームのバックアップをサポートしません。詳細は、FSB の制限事項 を参照してください。
…/.snapshot: read-only file system
エラーで失敗する
…/.snapshot
ディレクトリーは、複数の NFS サーバーによって使用されるスナップショットコピーディレクトリーです。このディレクトリーにはデフォルトで読み取り専用アクセスが設定されているため、Velero はこのディレクトリーに復元できません。
Velero に .snapshot
ディレクトリーへの書き込みアクセス権を付与しないでください。また、このディレクトリーへのクライアントアクセスを無効にしてください。
前提条件
- OpenShift API for Data Protection (OADP) Operator をインストールしている。
-
DataProtectionApplication
CR でspec.configuration.nodeAgent.enable
をfalse
に設定して、デフォルトのnodeAgent
インストールを無効にしていない。 -
DataProtectionApplication
CR でspec.configuration.nodeAgent.uploaderType
をkopia
またはrestic
に設定して、Kopia または Restic をアップローダーとして選択している。 -
DataProtectionApplication
CR がReady
状態である。
手順
次の例のように、
Backup
CR を作成します。apiVersion: velero.io/v1 kind: Backup metadata: name: <backup> labels: velero.io/storage-location: default namespace: openshift-adp spec: defaultVolumesToFsBackup: true 1 ...
- 1
- OADP バージョン 1.2 以降では、
defaultVolumesToFsBackup: true
設定をspec
ブロック内に追加します。OADP バージョン 1.1 では、defaultVolumesToRestic: true
を追加します。
4.6.5. バックアップフックの作成
バックアップを実行する際に、バックアップされる Pod に基づいて、Pod 内のコンテナーで実行するコマンドを 1 つ以上指定できます。
コマンドは、カスタムアクション処理の前 (プリ フック)、またはすべてのカスタムアクションが完了し、カスタムアクションで指定された追加アイテムがバックアップされた後 (ポスト フック) に実行するように設定できます。
Backup
カスタムリソース (CR) を編集して、Pod 内のコンテナーでコマンドを実行するためのバックアップフックを作成します。
手順
次の例のように、
Backup
CR の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.6.6. Schedule CR を使用したバックアップのスケジュール設定
スケジュール操作を使用すると、Cron 式で指定された特定の時間にデータのバックアップを作成できます。
Backup
CR の代わりに Schedule
カスタムリソース (CR) を作成して、バックアップをスケジュールします。
バックアップスケジュールでは、別のバックアップが作成される前にバックアップを数量するための時間を十分確保してください。
たとえば、namespace のバックアップに通常 10 分かかる場合は、15 分ごとよりも頻繁にバックアップをスケジュールしないでください。
前提条件
- OpenShift API for Data Protection (OADP) Operator をインストールしている。
-
DataProtectionApplication
CR がReady
状態である。
手順
backupStorageLocations
CR を取得します。$ oc get backupStorageLocations -n openshift-adp
出力例
NAMESPACE NAME PHASE LAST VALIDATED AGE DEFAULT openshift-adp velero-sample-1 Available 11s 31m
次の例のように、
Schedule
CR を作成します。$ 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 defaultVolumesToFsBackup: true 4 ttl: 720h0m0s EOF
- 1
- バックアップをスケジュールするための
cron
式。たとえば、毎日 7:00 にバックアップを実行する場合は0 7 * * *
です。注記特定の間隔でバックアップをスケジュールするには、次の形式で
<duration_in_minutes>
を入力します。schedule: "*/10 * * * *"
引用符 (
" "
) の間に分の値を入力します。 - 2
- バックアップを作成する namespace の配列。
- 3
backupStorageLocations
CR の名前。- 4
- オプション: OADP バージョン 1.2 以降では、Restic を使用してボリュームのバックアップを実行するときに、
defaultVolumesToFsBackup: true
キーと値のペアを設定に追加します。OADP バージョン 1.1 では、Restic でボリュームをバックアップするときに、defaultVolumesToRestic: true
のキーと値のペアを追加します。スケジュールされたバックアップの実行後に、
Schedule
CR のステータスがCompleted
となっていることを確認します。$ oc get schedule -n openshift-adp <schedule> -o jsonpath='{.status.phase}'
4.6.7. バックアップの削除
Backup
カスタムリソース (CR) を削除することで、バックアップファイルを削除できます。
Backup
CR および関連するオブジェクトストレージデータを削除した後、削除したデータを復元することはできません。
前提条件
-
Backup
CR を作成した。 -
Backup
CR の名前とそれを含む namespace がわかっている。 - Velero CLI ツールをダウンロードした。
- クラスター内の Velero バイナリーにアクセスできる。
手順
次のいずれかのアクションを選択して、
Backup
CR を削除します。Backup
CR を削除し、関連するオブジェクトストレージデータを保持する場合は、次のコマンドを実行します。$ oc delete backup <backup_CR_name> -n <velero_namespace>
Backup
CR を削除し、関連するオブジェクトストレージデータを削除する場合は、次のコマンドを実行します。$ velero backup delete <backup_CR_name> -n <velero_namespace>
ここでは、以下のようになります。
- <backup_CR_name>
-
Backup
カスタムリソースの名前。 - <velero_namespace>
-
Backup
カスタムリソースを含む namespace。
4.6.8. Kopia について
Kopia は、高速かつセキュアなオープンソースのバックアップおよび復元ツールです。これを使用して、データの暗号化されたスナップショットを作成し、そのスナップショットを選択したリモートストレージまたはクラウドストレージに保存できます。
Kopia は、ネットワークおよびローカルストレージの場所、および多くのクラウドまたはリモートストレージの場所をサポートしています。以下はその一部です。
- Amazon S3 および S3 と互換性のあるクラウドストレージ
- Azure Blob Storage
- Google Cloud Storage プラットフォーム
Kopia は、スナップショットにコンテンツアドレスを指定できるストレージを使用します。
- スナップショットは常に増分されます。すでに以前のスナップショットに含まれているデータは、リポジトリーに再アップロードされません。リポジトリーに再度アップロードされるのは、ファイルが変更されたときだけです。
- 保存されたデータは重複排除されます。同じファイルのコピーが複数存在する場合、そのうちの 1 つだけが保存されます。
- ファイルが移動された場合、またはファイルの名前が変更された場合、Kopia はそれらが同じコンテンツであることを認識し、それらを再度アップロードしません。
4.6.8.1. OADP と Kopia の統合
OADP 1.3 は、Pod ボリュームバックアップのバックアップメカニズムとして、Restic に加えて Kopia をサポートします。インストール時に、DataProtectionApplication
カスタムリソース (CR) の uploaderType
フィールドを設定して、どちらかを選択する必要があります。使用できる値は、restic
または kopia
です。uploaderType
を指定しない場合、OADP 1.3 はデフォルトで Kopia をバックアップメカニズムとして使用します。データは統合リポジトリーに書き込まれ、統合リポジトリーから読み取られます。
次の例は、Kopia を使用するように設定された DataProtectionApplication
CR を示しています。
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: dpa-sample spec: configuration: nodeAgent: enable: true uploaderType: kopia # ...
4.7. OADP の復元
4.7.1. アプリケーションの復元
アプリケーションのバックアップを復元するには、Restore
カスタムリソース (CR) を作成します。復元 CR の作成 を参照してください。
Restore
CR を編集することで、Pod 内のコンテナーでコマンドを実行するための復元フックを作成できます。復元フックの作成 を参照してください。
4.7.1.1. 復元 CR の作成
Restore
CR を作成して、Backup
カスタムリソース (CR) を復元します。
前提条件
- OpenShift API for Data Protection (OADP) Operator をインストールしている。
-
DataProtectionApplication
CR がReady
状態である。 -
Velero
Backup
CR がある。 - 永続ボリューム (PV) の容量は、バックアップ時に要求されたサイズと一致する必要があります。必要に応じて、要求されたサイズを調整します。
手順
次の例のように、
Restore
CR を作成します。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
Backup
CR の名前- 2
- オプション: 復元プロセスに含めるリソースの配列を指定します。リソースは、ショートカット (
Pods
はpo
など) または完全修飾の場合があります。指定しない場合、すべてのリソースが含まれます。 - 3
- オプション:
restorePVs
パラメーターをfalse
に設定すると、コンテナーストレージインターフェイス (CSI) スナップショットのVolumeSnapshot
から、またはVolumeSnapshotLocation
が設定されている場合はネイティブスナップショットからのPersistentVolumes
の復元をオフにすることができます。
次のコマンドを入力して、
Restore
CR のステータスが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 として復元します。これは、クラスターが復元されたDeploymentConfig
Pod を復元時にすぐに削除することを防ぎ、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.7.1.2. 復元フックの作成
Restore
カスタムリソース (CR) を編集して、Pod 内のコンテナーでコマンドを実行する復元フックを作成します。
2 種類の復元フックを作成できます。
init
フックは、init コンテナーを Pod に追加して、アプリケーションコンテナーが起動する前にセットアップタスクを実行します。Restic バックアップを復元する場合は、復元フック init コンテナーの前に
restic-wait
init コンテナーが追加されます。-
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 内のコンテナーで復元フックが実行されなくなりました。Restore
CR のステータスはPartiallyFailed
になります。
-
4.8. OADP と ROSA
4.8.1. OADP を使用して ROSA クラスター上のアプリケーションをバックアップする
Red Hat OpenShift Service on AWS (ROSA) クラスターで OpenShift API for Data Protection (OADP) を使用して、アプリケーションデータをバックアップおよび復元できます。
ROSA は、フルマネージドのターンキーアプリケーションプラットフォームであり、アプリケーションを構築してデプロイすることにより、お客様に価値を提供することに集中できます。
ROSA は、幅広い Amazon Web Services (AWS) コンピュート、データベース、分析、機械学習、ネットワーク、モバイル、およびその他のサービスとのシームレスな統合を提供し、差別化されたエクスペリエンスの構築とお客様への提供をさらに高速化します。
AWS アカウントから直接サービスをサブスクライブできます。
クラスターを作成した後、OpenShift Container Platform Web コンソールを使用して、または Red Hat OpenShift Cluster Manager を介してクラスターを操作できます。ROSA では、OpenShift API やコマンドラインインターフェイス (CLI) ツールも使用できます。
ROSA のインストールの詳細は、Red Hat OpenShift Service on AWS (ROSA) のインストールのインタラクティブな説明 を参照してください。
OpenShift API for Data Protection (OADP) をインストールする前に、OADP が Amazon Web Services API を使用できるように、OADP のロールとポリシーの認証情報を設定する必要があります。
このプロセスは次の 2 段階で実行されます。
- AWS 認証情報を準備します。
- OADP Operator をインストールし、IAM ロールを付与します。
4.8.1.1. OADP 用の AWS 認証情報を準備する
Amazon Web Services アカウントは、OpenShift API for Data Protection (OADP) インストールを受け入れるように準備および設定する必要があります。
手順
次のコマンドを実行して、以下の環境変数を作成します。
重要ROSA クラスターに一致するようにクラスター名を変更し、管理者としてクラスターにログインしていることを確認します。続行する前に、すべてのフィールドが正しく出力されていることを確認します。
$ export CLUSTER_NAME=my-cluster 1 export ROSA_CLUSTER_ID=$(rosa describe cluster -c ${CLUSTER_NAME} --output json | jq -r .id) export REGION=$(rosa describe cluster -c ${CLUSTER_NAME} --output json | jq -r .region.id) export OIDC_ENDPOINT=$(oc get authentication.config.openshift.io cluster -o jsonpath='{.spec.serviceAccountIssuer}' | sed 's|^https://||') export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) export CLUSTER_VERSION=$(rosa describe cluster -c ${CLUSTER_NAME} -o json | jq -r .version.raw_id | cut -f -2 -d '.') export ROLE_NAME="${CLUSTER_NAME}-openshift-oadp-aws-cloud-credentials" export SCRATCH="/tmp/${CLUSTER_NAME}/oadp" mkdir -p ${SCRATCH} echo "Cluster ID: ${ROSA_CLUSTER_ID}, Region: ${REGION}, OIDC Endpoint: ${OIDC_ENDPOINT}, AWS Account ID: ${AWS_ACCOUNT_ID}"
- 1
my-cluster
は、ROSA クラスター名に置き換えます。
AWS アカウントで、AWS S3 へのアクセスを許可する IAM ポリシーを作成します。
以下のコマンドを実行して、ポリシーが存在するかどうかを確認します。
$ POLICY_ARN=$(aws iam list-policies --query "Policies[?PolicyName=='RosaOadpVer1'].{ARN:Arn}" --output text) 1
- 1
RosaOadp
は、実際のポリシー名に置き換えます。
以下のコマンドを入力してポリシー JSON ファイルを作成し、ROSA でポリシーを作成します。
注記ポリシー ARN が見つからない場合、コマンドはポリシーを作成します。ポリシー ARN がすでに存在する場合、
if
ステートメントはポリシーの作成を意図的にスキップします。$ if [[ -z "${POLICY_ARN}" ]]; then cat << EOF > ${SCRATCH}/policy.json 1 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:CreateBucket", "s3:DeleteBucket", "s3:PutBucketTagging", "s3:GetBucketTagging", "s3:PutEncryptionConfiguration", "s3:GetEncryptionConfiguration", "s3:PutLifecycleConfiguration", "s3:GetLifecycleConfiguration", "s3:GetBucketLocation", "s3:ListBucket", "s3:GetObject", "s3:PutObject", "s3:DeleteObject", "s3:ListBucketMultipartUploads", "s3:AbortMultipartUploads", "s3:ListMultipartUploadParts", "s3:DescribeSnapshots", "ec2:DescribeVolumes", "ec2:DescribeVolumeAttribute", "ec2:DescribeVolumesModifications", "ec2:DescribeVolumeStatus", "ec2:CreateTags", "ec2:CreateVolume", "ec2:CreateSnapshot", "ec2:DeleteSnapshot" ], "Resource": "*" } ]} EOF POLICY_ARN=$(aws iam create-policy --policy-name "RosaOadpVer1" \ --policy-document file:///${SCRATCH}/policy.json --query Policy.Arn \ --tags Key=rosa_openshift_version,Value=${CLUSTER_VERSION} Key=rosa_role_prefix,Value=ManagedOpenShift Key=operator_namespace,Value=openshift-oadp Key=operator_name,Value=openshift-oadp \ --output text) fi
- 1
SCRATCH
は、環境変数用に作成された一時ディレクトリーの名前です。
以下のコマンドを実行してポリシー ARN を表示します。
$ echo ${POLICY_ARN}
クラスターの IAM ロール信頼ポリシーを作成します。
次のコマンドを実行して、信頼ポリシーファイルを作成します。
$ cat <<EOF > ${SCRATCH}/trust-policy.json { "Version":2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/${OIDC_ENDPOINT}" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "${OIDC_ENDPOINT}:sub": [ "system:serviceaccount:openshift-adp:openshift-adp-controller-manager", "system:serviceaccount:openshift-adp:velero"] } } }] } EOF
以下のコマンドを実行してロールを作成します。
$ ROLE_ARN=$(aws iam create-role --role-name \ "${ROLE_NAME}" \ --assume-role-policy-document file://${SCRATCH}/trust-policy.json \ --tags Key=rosa_cluster_id,Value=${ROSA_CLUSTER_ID} Key=rosa_openshift_version,Value=${CLUSTER_VERSION} Key=rosa_role_prefix,Value=ManagedOpenShift Key=operator_namespace,Value=openshift-adp Key=operator_name,Value=openshift-oadp \ --query Role.Arn --output text)
次のコマンドを実行して、ロール ARN を表示します。
$ echo ${ROLE_ARN}
次のコマンドを実行して、IAM ポリシーを IAM ロールにアタッチします。
$ aws iam attach-role-policy --role-name "${ROLE_NAME}" \ --policy-arn ${POLICY_ARN}
4.8.1.2. OADP Operator のインストールおよび IAM ロールの指定
AWS Security Token Service (AWS STS) は、IAM またはフェデレーションされたユーザーの短期認証情報を提供するグローバル Web サービスです。STS を使用した OpenShift Container Platform (ROSA) は、ROSA クラスターに推奨される認証情報モードです。このドキュメントでは、AWS STS を使用する ROSA に OpenShift API for Data Protection (OADP) をインストールする方法を説明します。
Restic はサポートされていません。
Container Storage Interface (CSI) スナップショットをサポートしていないファイルシステムをバックアップする場合は、Kopia ファイルシステムバックアップ (FSB) がサポートされています。
ファイルシステムの例には次のものがあります。
- Amazon Elastic File System (EFS)
- Network File System (NFS)
-
emptyDir
ボリューム - ローカルボリューム
ボリュームをバックアップする場合、AWS STS を使用する ROSA の OADP は、ネイティブスナップショットと Container Storage Interface (CSI) スナップショットのみをサポートします。
STS 認証を使用する Amazon ROSA クラスターでは、別の AWS リージョンでのバックアップデータの復元はサポートされていません。
Data Mover 機能は現在、ROSA クラスターではサポートされていません。データの移動にはネイティブ AWS S3 ツールを使用できます。
前提条件
-
必要なアクセス権とトークンを備えた OpenShift Container Platform ROSA クラスター。詳細は、前の手順である OADP 用の AWS 認証情報の準備 を参照してください。バックアップと復元に 2 つの異なるクラスターを使用する予定の場合は、
ROLE_ARN
を含む AWS 認証情報をクラスターごとに準備する必要があります。
手順
次のコマンドを入力して、AWS トークンファイルから OpenShift Container Platform シークレットを作成します。
認証情報ファイルを作成します。
$ cat <<EOF > ${SCRATCH}/credentials [default] role_arn = ${ROLE_ARN} web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token EOF
OADP の namespace を作成します。
$ oc create namespace openshift-adp
OpenShift Container Platform シークレットを作成します。
$ oc -n openshift-adp create secret generic cloud-credentials \ --from-file=${SCRATCH}/credentials
注記OpenShift Container Platform バージョン 4.14 以降では、OADP Operator は Operator Lifecycle Manager (OLM) および Cloud Credentials Operator (CCO) を通じて、標準化された新しい STS ワークフローをサポートします。このワークフローでは、上記シークレットの作成は必要ありません。OpenShift Container Platform Web コンソールを使用して、OLM で管理される Operator のインストール中にロール ARN のみ指定する必要があります。詳細は、Web コンソールを使用して OperatorHub からインストールする を参照してください。
前述のシークレットは CCO によって自動的に作成されます。
OADP Operator をインストールします。
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub ページを表示します。
- OADP Operator を検索します。
- role_ARN フィールドに、前に作成した role_arn を貼り付け、Install をクリックします。
次のコマンドを入力し、AWS 認証情報を使用して AWS クラウドストレージを作成します。
$ cat << EOF | oc create -f - apiVersion: oadp.openshift.io/v1alpha1 kind: CloudStorage metadata: name: ${CLUSTER_NAME}-oadp namespace: openshift-adp spec: creationSecret: key: credentials name: cloud-credentials enableSharedConfig: true name: ${CLUSTER_NAME}-oadp provider: aws region: $REGION EOF
次のコマンドを入力して、アプリケーションのストレージのデフォルトストレージクラスを確認します。
$ oc get pvc -n <namespace>
出力例
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE applog Bound pvc-351791ae-b6ab-4e8b-88a4-30f73caf5ef8 1Gi RWO gp3-csi 4d19h mysql Bound pvc-16b8e009-a20a-4379-accc-bc81fedd0621 1Gi RWO gp3-csi 4d19h
次のコマンドを実行してストレージクラスを取得します。
$ oc get storageclass
出力例
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE gp2 kubernetes.io/aws-ebs Delete WaitForFirstConsumer true 4d21h gp2-csi ebs.csi.aws.com Delete WaitForFirstConsumer true 4d21h gp3 ebs.csi.aws.com Delete WaitForFirstConsumer true 4d21h gp3-csi (default) ebs.csi.aws.com Delete WaitForFirstConsumer true 4d21h
注記次のストレージクラスが機能します。
- gp3-csi
- gp2-csi
- gp3
- gp2
すべてのアプリケーション、またはバックアップされるアプリケーションが Container Storage Interface (CSI) で永続ボリューム (PV) を使用している場合は、OADP DPA 設定に CSI プラグインを含めることをお勧めします。
バックアップとボリュームスナップショットが保存されるストレージへの接続を設定するために、
DataProtectionApplication
リソースを作成します。CSI ボリュームのみを使用している場合は、次のコマンドを入力して Data Protection Application をデプロイします。
$ cat << EOF | oc create -f - apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: ${CLUSTER_NAME}-dpa namespace: openshift-adp spec: backupImages: true 1 features: dataMover: enable: false backupLocations: - bucket: cloudStorageRef: name: ${CLUSTER_NAME}-oadp credential: key: credentials name: cloud-credentials prefix: velero default: true config: region: ${REGION} configuration: velero: defaultPlugins: - openshift - aws - csi restic: enable: false EOF
- 1
- ROSA は内部イメージバックアップをサポートします。イメージのバックアップを使用しない場合は、このフィールドを
false
に設定します。
CSI ボリュームまたは非 CSI ボリュームを使用している場合は、次のコマンドを入力して Data Protection Application をデプロイします。
$ cat << EOF | oc create -f - apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: ${CLUSTER_NAME}-dpa namespace: openshift-adp spec: backupImages: true 1 features: dataMover: enable: false backupLocations: - bucket: cloudStorageRef: name: ${CLUSTER_NAME}-oadp credential: key: credentials name: cloud-credentials prefix: velero default: true config: region: ${REGION} configuration: velero: defaultPlugins: - openshift - aws nodeAgent: 2 enable: false uploaderType: restic snapshotLocations: - velero: config: credentialsFile: /tmp/credentials/openshift-adp/cloud-credentials-credentials 3 enableSharedConfig: "true" 4 profile: default 5 region: ${REGION} 6 provider: aws EOF
- 1
- ROSA は内部イメージバックアップをサポートします。イメージのバックアップを使用しない場合は、このフィールドを false に設定します。
- 2
- 以下の注意点を参照してください。
- 3
credentialsFile
フィールドは、Pod のバケット認証情報のマウント先です。- 4
enableSharedConfig
フィールドを使用すると、snapshotLocations
がバケットに定義された認証情報を共有または再利用できます。- 5
- AWS 認証情報ファイルに設定されているプロファイル名を使用します。
- 6
region
は、お使いの AWS リージョンに指定します。これはクラスターリージョンと同じである必要があります。
これで、アプリケーションのバックアップ で説明されているとおり、OpenShift Container Platform アプリケーションをバックアップおよび復元する準備が整いました。
OADP は ROSA 環境で Restic をサポートしていないため、restic
の enable
パラメーターは false
に設定されています。
OADP 1.2 を使用する場合は、次の設定を置き換えます。
nodeAgent: enable: false uploaderType: restic
次の設定に置き換えます。
restic: enable: false
バックアップと復元に 2 つの異なるクラスターを使用する場合、クラウドストレージ CR と OADP DataProtectionApplication
設定の両方で、2 つのクラスターの AWS S3 ストレージ名が同じである必要があります。
4.8.1.3. 例: オプションのクリーンアップを使用して OADP ROSA STS 上のワークロードをバックアップする
4.8.1.3.1. OADP と ROSA STS を使用したバックアップの実行
次の hello-world
アプリケーションの例では、永続ボリューム (PV) が接続されていません。Red Hat OpenShift Service on AWS (ROSA) STS を使用して、OpenShift API for Data Protection (OADP) でバックアップを実行します。
どちらの Data Protection Application (DPA) 設定も機能します。
次のコマンドを実行して、バックアップするワークロードを作成します。
$ oc create namespace hello-world
$ oc new-app -n hello-world --image=docker.io/openshift/hello-openshift
次のコマンドを実行してルートを公開します。
$ oc expose service/hello-openshift -n hello-world
次のコマンドを実行して、アプリケーションが動作していることを確認します。
$ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`
出力例
Hello OpenShift!
次のコマンドを実行して、ワークロードをバックアップします。
$ cat << EOF | oc create -f - apiVersion: velero.io/v1 kind: Backup metadata: name: hello-world namespace: openshift-adp spec: includedNamespaces: - hello-world storageLocation: ${CLUSTER_NAME}-dpa-1 ttl: 720h0m0s EOF
バックアップが完了するまで待ってから、次のコマンドを実行します。
$ watch "oc -n openshift-adp get backup hello-world -o json | jq .status"
出力例
{ "completionTimestamp": "2022-09-07T22:20:44Z", "expiration": "2022-10-07T22:20:22Z", "formatVersion": "1.1.0", "phase": "Completed", "progress": { "itemsBackedUp": 58, "totalItems": 58 }, "startTimestamp": "2022-09-07T22:20:22Z", "version": 1 }
次のコマンドを実行して、デモワークロードを削除します。
$ oc delete ns hello-world
次のコマンドを実行して、バックアップからワークロードを復元します。
$ cat << EOF | oc create -f - apiVersion: velero.io/v1 kind: Restore metadata: name: hello-world namespace: openshift-adp spec: backupName: hello-world EOF
次のコマンドを実行して、復元が完了するまで待ちます。
$ watch "oc -n openshift-adp get restore hello-world -o json | jq .status"
出力例
{ "completionTimestamp": "2022-09-07T22:25:47Z", "phase": "Completed", "progress": { "itemsRestored": 38, "totalItems": 38 }, "startTimestamp": "2022-09-07T22:25:28Z", "warnings": 9 }
次のコマンドを実行して、ワークロードが復元されていることを確認します。
$ oc -n hello-world get pods
出力例
NAME READY STATUS RESTARTS AGE hello-openshift-9f885f7c6-kdjpj 1/1 Running 0 90s
次のコマンドを実行して JSONPath を確認します。
$ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`
出力例
Hello OpenShift!
トラブルシューティングのヒントについては、OADP チームの トラブルシューティングドキュメント を参照してください。
4.8.1.3.2. OADP と ROSA STS を使用してバックアップ後のクラスターをクリーンアップする
この例のバックアップおよび S3 バケットと OpenShift API for Data Protection (OADP) Operator をアンインストールする必要がある場合は、次の手順を実行します。
手順
次のコマンドを実行して、ワークロードを削除します。
$ oc delete ns hello-world
次のコマンドを実行して、Data Protection Application (DPA) を削除します。
$ oc -n openshift-adp delete dpa ${CLUSTER_NAME}-dpa
次のコマンドを実行して、クラウドストレージを削除します。
$ oc -n openshift-adp delete cloudstorage ${CLUSTER_NAME}-oadp
警告このコマンドがハングした場合は、次のコマンドを実行してファイナライザーを削除する必要がある場合があります。
$ oc -n openshift-adp patch cloudstorage ${CLUSTER_NAME}-oadp -p '{"metadata":{"finalizers":null}}' --type=merge
Operator が不要になった場合は、次のコマンドを実行して削除します。
$ oc -n openshift-adp delete subscription oadp-operator
Operator から namespace を削除します。
$ oc delete ns openshift-adp
バックアップおよび復元リソースが不要になった場合は、次のコマンドを実行してクラスターからリソースを削除します。
$ oc delete backup hello-world
AWS S3 のバックアップ、復元、およびリモートオブジェクトを削除するには、次のコマンドを実行します。
$ velero backup delete hello-world
カスタムリソース定義 (CRD) が不要になった場合は、次のコマンドを実行してクラスターから削除します。
$ for CRD in `oc get crds | grep velero | awk '{print $1}'`; do oc delete crd $CRD; done
次のコマンドを実行して、AWS S3 バケットを削除します。
$ aws s3 rm s3://${CLUSTER_NAME}-oadp --recursive
$ aws s3api delete-bucket --bucket ${CLUSTER_NAME}-oadp
次のコマンドを実行して、ロールからポリシーを切り離します。
$ aws iam detach-role-policy --role-name "${ROLE_NAME}" --policy-arn "${POLICY_ARN}"
以下のコマンドを実行してロールを削除します。
$ aws iam delete-role --role-name "${ROLE_NAME}"
4.9. OADP Data Mover
4.9.1. OADP Data Mover の概要
OADP Data Mover を使用すると、クラスターの障害が発生した場合、誤って削除した場合、または破損した場合に、ストアからステートフルアプリケーションを復元できます。
OADP 1.1 Data Mover はテクノロジープレビュー機能です。
OADP 1.2 Data Mover は機能とパフォーマンスが大幅に向上していますが、まだテクノロジープレビュー機能です。
OADP Data Mover はテクノロジープレビューのみの機能です。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
- OADP Data Mover を使用して、Container Storage Interface (CSI) ボリュームのスナップショットをリモートオブジェクトストアにバックアップできます。CSI スナップショットに Data Mover を使用する を参照してください。
- OADP 1.2 Data Mover を使用して、CephFS、CephRBD、またはその両方を使用するクラスターのアプリケーションデータをバックアップおよび復元できます。Ceph Storage での OADP 1.2 Data Mover の使用 を参照してください。
- OADP 1.1 Data Mover を使用している場合は、バックアップを実行した後にデータのクリーンアップを実行する必要があります。OADP 1.1 Data Mover を使用したバックアップ後のクリーンアップ を参照してください。
OADP 1.3 Data Mover では、移行後のフックがうまく機能しない可能性があります。
OADP 1.1 および OADP 1.2 Data Mover は、同期プロセスを使用してアプリケーションデータのバックアップと復元を行います。プロセスは同期しているため、復元後のフックが開始されるのは、必ず関連する Pod の永続ボリューム (PV) が Data Mover の永続ボリューム要求 (PVC) により解放された後になります。
しかし、OADP 1.3 Data Mover は非同期プロセスを使用します。このような順序の違いにより、Data Mover の PVC によって関連する PV が解放される前に、復元後のフックが呼び出される可能性があります。これが発生した場合、Pod は Pending
ステータスのままになり、フックを実行できません。Pod が解放される前にフックの試行がタイムアウトになり、復元操作で PartiallyFailed
が発生する可能性があります。
4.9.1.1. OADP Data Mover の前提条件
- 別の namespace で実行されているステートフルアプリケーションがある。
- Operator Lifecycle Manager (OLM) を使用して OADP Operator をインストールしている。
-
適切な
VolumeSnapshotClass
とStorageClass
を作成している。 - OLM を使用して VolSync オペレーターをインストールしている。
4.9.2. 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"
のアノテーションを持つVolumeSnapshotClass
CR が 1 つだけであることを確認している。注記OpenShift Container Platform バージョン 4.12 以降では、これが唯一のデフォルト
VolumeSnapshotClass
であることを確認してください。-
VolumeSnapshotClass
CR のdeletionPolicy
がRetain
に設定されていることを確認している。 -
注釈
storageclass.kubernetes.io/is-default-class: "true"
を持つStorageClass
CR が 1 つだけであることを確認している。 -
VolumeSnapshotClass
CR にラベル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 をインストールしました。
注記XFS ファイルシステムを使用してボリュームをフォーマットし、ボリュームの容量が 100% になっている場合は、
no space left on device
エラーが発生してバックアップが失敗します。以下に例を示します。Error: relabel failed /var/lib/kubelet/pods/3ac..34/volumes/ \ kubernetes.io~csi/pvc-684..12c/mount: lsetxattr /var/lib/kubelet/ \ pods/3ac..34/volumes/kubernetes.io~csi/pvc-68..2c/mount/data-xfs-103: \ no space left on device
このシナリオでは、バックアップが正常に完了するように、ボリュームのサイズを変更するか、
ext4
などの別のファイルシステムタイプを使用することを検討してください。
手順
次のように
.yaml
ファイルを作成して、Restic シークレットを設定します。apiVersion: v1 kind: Secret metadata: name: <secret_name> namespace: openshift-adp type: Opaque stringData: RESTIC_PASSWORD: <secure_restic_password>
注記デフォルトでは、Operator は
dm-credential
という名前のシークレットを探します。別の名前を使用している場合は、dpa.spec.features.dataMover.credentialName
を使用して、Data Protection Application (DPA) CR で名前を指定する必要があります。次の例のような DPA CR を作成します。デフォルトのプラグインには CSI が含まれています。
データ保護アプリケーション (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: <bucket_name> prefix: <bucket-prefix> provider: aws configuration: restic: enable: <true_or_false> velero: itemOperationSyncFrequency: "10s" defaultPlugins: - openshift - aws - csi - vsm 1 features: dataMover: credentialName: restic-secret enable: true maxConcurrentBackupVolumes: "3" 2 maxConcurrentRestoreVolumes: "3" 3 pruneInterval: "14" 4 volumeOptions: 5 sourceVolumeOptions: accessMode: ReadOnlyMany cacheAccessMode: ReadWriteOnce cacheCapacity: 2Gi destinationVolumeOptions: storageClass: other-storageclass-name cacheAccessMode: ReadWriteMany snapshotLocations: - velero: config: profile: default region: us-west-2 provider: aws
- 1
- OADP 1.2 のみ。
- 2
- OADP 1.2 のみ。オプション: バックアップのためにキューに入れることができるスナップショットの数の上限を指定します。デフォルト値は 10 です。
- 3
- OADP 1.2 のみ。オプション: 復元のためにキューに入れることができるスナップショットの数の上限を指定します。デフォルト値は 10 です。
- 4
- OADP 1.2 のみ。オプション: リポジトリーで Restic プルーニングを実行する間隔の日数を指定します。プルーン操作ではデータを再パックして領域を解放しますが、プロセスの一部として大量の I/O トラフィックが生成される可能性もあります。このオプションを設定すると、参照されなくなったデータによるストレージ消費とアクセスコストとの間のトレードオフが可能になります。
- 5
- OADP 1.2 のみ。オプション: バックアップと復元の VolumeSync ボリュームオプションを指定します。
OADP Operator は、2 つのカスタムリソース定義 (CRD)、
VolumeSnapshotBackup
およびVolumeSnapshotRestore
をインストールします。VolumeSnapshotBackup
CRD の例apiVersion: datamover.oadp.openshift.io/v1alpha1 kind: VolumeSnapshotBackup metadata: name: <vsb_name> namespace: <namespace_name> 1 spec: volumeSnapshotContent: name: <snapcontent_name> protectedNamespace: <adp_namespace> 2 resticSecretRef: name: <restic_secret_name>
VolumeSnapshotRestore
CRD の例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> 2 storageLocation: velero-sample-1
次のコマンドを入力して、最大 10 分待機し、
VolumeSnapshotBackup
CR のステータスがCompleted
かどうかを確認します。$ oc get vsb -n <app_ns>
$ oc get vsb <vsb_name> -n <app_ns> -o jsonpath="{.status.phase}"
DPA で設定されたオブジェクトストアにスナップショットが作成されます。
注記VolumeSnapshotBackup
CR のステータスがFailed
になった場合は、トラブルシューティングのために Velero ログを参照してください。
次の手順を実行して、ボリュームスナップショットを復元できます。
-
アプリケーションの namespace と、Velero CSI プラグインによって作成された
VolumeSnapshotContent
を削除します。 Restore
CR を作成し、restorePVs
をtrue
に設定します。Restore
CR の例apiVersion: velero.io/v1 kind: Restore metadata: name: <restore_name> namespace: <protected_ns> spec: backupName: <previous_backup_name> restorePVs: true
最大 10 分間待機し、次のコマンドを入力して、
VolumeSnapshotRestore
CR ステータスがCompleted
であるかどうかを確認します。$ oc get vsr -n <app_ns>
$ oc get vsr <vsr_name> -n <app_ns> -o jsonpath="{.status.phase}"
アプリケーションデータとリソースが復元されたかどうかを確認します。
注記VolumeSnapshotRestore
CR のステータスが 'Failed' になった場合は、トラブルシューティングのために Velero ログを参照してください。
-
アプリケーションの namespace と、Velero CSI プラグインによって作成された
4.9.3. 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.9.3.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.9.3.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.9.3.2.1. 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 で使用するために定義できます。
手順
以下の例のように
VolumeSnapshotClass
CR を定義します。VolumeSnapshotClass
CR の例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
以下の例のように
StorageClass
CR を定義します。StorageClass
CR の例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.9.3.2.2. 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 で使用するために定義できます。
手順
以下の例のように
VolumeSnapshotClass
CR を定義します。VolumeSnapshotClass
CR の例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
以下の例のように
StorageClass
CR を定義します。StorageClass
CR の例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.9.3.2.3. OADP 1.2 Data Mover で使用する追加のカスタムリソースの定義
デフォルトの StorageClass
および CephRBD VolumeSnapshotClass
カスタムリソース (CR) を再定義した後、次の CR を作成する必要があります。
-
シャローコピー機能を使用するように定義された CephFS
StorageClass
CR -
Restic
Secret
CR
手順
次の例のように CephFS
StorageClass
CR を作成し、backingSnapshot
パラメーターをtrue
に設定します。backingSnapshot
をtrue
に設定した CephFSStorageClass
CR の例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
およびStorageClass
CR のProvisioner
の値が同じであることを確認してください。次の例のように Restic
Secret
CR を設定します。Restic
Secret
CR の例apiVersion: v1 kind: Secret metadata: name: <secret_name> namespace: <namespace> type: Opaque stringData: RESTIC_PASSWORD: <restic_password>
4.9.3.3. OADP 1.2 Data Mover と CephFS ストレージを使用したデータのバックアップと復元
OpenShift API for Data Protection (OADP) 1.2 Data Mover を使用すると、CephFS のシャローコピー機能を有効にすることで、CephFS ストレージを使用してデータをバックアップおよびリストアできます。
前提条件
- ステートフルアプリケーションが、CephFS をプロビジョナーとして使用し、永続ボリューム要求 (PVC) を持つ別の namespace で実行されている。
-
StorageClass
およびVolumeSnapshotClass
カスタムリソース (CR) が、CephFS および OADP 1.2 Data Mover 用に定義されています。 -
openshift-adp
namespace にシークレットのcloud-credentials
がある。
4.9.3.3.1. CephFS ストレージで使用する DPA の作成
OpenShift API for Data Protection (OADP) 1.2 Data Mover を使用して、CephFS ストレージでデータをバックアップおよびリストアするには、Data Protection Application (DPA) CR を作成する必要があります。
手順
次のコマンドを実行して、
VolumeSnapshotClass
CR のdeletionPolicy
フィールドがRetain
に設定されていることを確認します。$ oc get volumesnapshotclass -A -o jsonpath='{range .items[*]}{"Name: "}{.metadata.name}{" "}{"Retention Policy: "}{.deletionPolicy}{"\n"}{end}'
次のコマンドを実行して、
VolumeSnapshotClass
CR のラベルがtrue
に設定されていることを確認します。$ oc get volumesnapshotclass -A -o jsonpath='{range .items[*]}{"Name: "}{.metadata.name}{" "}{"labels: "}{.metadata.labels}{"\n"}{end}'
次のコマンドを実行して、
StorageClass
CR のstorageclass.kubernetes.io/is-default-class
アノテーションがtrue
に設定されていることを確認します。$ oc get storageClass -A -o jsonpath='{range .items[*]}{"Name: "}{.metadata.name}{" "}{"annotations: "}{.metadata.annotations}{"\n"}{end}'
次の例のような 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 1 velero: defaultPlugins: - openshift - aws - csi - vsm features: dataMover: credentialName: <restic_secret_name> 2 enable: true 3 volumeOptionsForStorageClasses: 4 ocs-storagecluster-cephfs: sourceVolumeOptions: accessMode: ReadOnlyMany cacheAccessMode: ReadWriteMany cacheStorageClassName: ocs-storagecluster-cephfs storageClassName: ocs-storagecluster-cephfs-shallow
- 1
enable
フィールドにはデフォルト値はありません。有効な値はtrue
またはfalse
です。- 2
- OADP 1.2 Data Mover および Ceph を操作するための環境を準備したときに作成した Restic
Secret
を使用します。ResticSecret
を使用しない場合、CR はこのパラメーターのデフォルト値dm-credential
を使用します。 - 3
enable
フィールドにはデフォルト値はありません。有効な値はtrue
またはfalse
です。- 4
- オプションのパラメーター。各
storageClass
ボリュームに対して、異なるVolumeOptionsForStorageClass
ラベルのセットを定義できます。この設定では、異なるプロバイダーのボリュームのバックアップが提供されます。オプションのVolumeOptionsForStorageClass
パラメーターは通常 CephFS で使用されますが、どのストレージタイプでも使用できます。
4.9.3.3.2. OADP 1.2 Data Mover と CephFS ストレージを使用したデータのバックアップ
OpenShift API for Data Protection (OADP) 1.2 Data Mover を使用すると、CephFS ストレージのシャローコピー機能を有効にすることで、CephFS ストレージを使用してデータをバックアップできます。
手順
次の例のように、
Backup
CR を作成します。Backup
CR の例apiVersion: velero.io/v1 kind: Backup metadata: name: <backup_name> namespace: <protected_ns> spec: includedNamespaces: - <app_ns> storageLocation: velero-sample-1
次の手順を実行して、
VolumeSnapshotBackup
CR の進行状況を監視します。すべての
VolumeSnapshotBackup
CR の進行状況を確認するには、次のコマンドを実行します。$ oc get vsb -n <app_ns>
特定の
VolumeSnapshotBackup
CR の進行状況を確認するには、次のコマンドを実行します。$ oc get vsb <vsb_name> -n <app_ns> -ojsonpath="{.status.phase}`
-
VolumeSnapshotBackup
CR のステータスがCompleted
になるまで、数分間待ちます。 -
Restic
Secret
で指定されたスナップショットがオブジェクトストアに少なくとも 1 つあることを確認します。/<OADP-namespace>
という接頭辞を持つ、対象のBackupStorageLocation
ストレージプロバイダーでこのスナップショットを確認できます。
4.9.3.3.3. 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
次のコマンドを実行して、バックアップ中に作成された
VolumeSnapshotContent
CR を削除します。$ oc delete volumesnapshotcontent --all
次の例のように、
Restore
CR を作成します。Restore
CR の例apiVersion: velero.io/v1 kind: Restore metadata: name: <restore_name> namespace: <protected_ns> spec: backupName: <previous_backup_name>
次の手順を実行して、
VolumeSnapshotRestore
CR の進行状況を監視します。すべての
VolumeSnapshotRestore
CR の進行状況を確認するには、次のコマンドを実行します。$ oc get vsr -n <app_ns>
特定の
VolumeSnapshotRestore
CR の進行状況を確認するには、次のコマンドを実行します。$ oc get vsr <vsr_name> -n <app_ns> -ojsonpath="{.status.phase}
次のコマンドを実行して、アプリケーションデータが復元されたことを確認します。
$ oc get route <route_name> -n <app_ns> -ojsonpath="{.spec.host}"
4.9.3.4. OADP 1.2 Data Mover と分割ボリューム (CephFS および Ceph RBD) を使用したデータのバックアップとリストア
OpenShift API for Data Protection (OADP) 1.2 Data Mover を使用すると、ボリュームを分割した 環境、つまり CephFS と CephRBD の両方を使用する環境でデータをバックアップおよびリストアできます。
前提条件
- ステートフルアプリケーションが、CephFS をプロビジョナーとして使用し、永続ボリューム要求 (PVC) を持つ別の namespace で実行されている。
-
StorageClass
およびVolumeSnapshotClass
カスタムリソース (CR) が、CephFS および OADP 1.2 Data Mover 用に定義されています。 -
openshift-adp
namespace にシークレットのcloud-credentials
がある。
4.9.3.4.1. 分割ボリュームで使用する 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
- 1
- OADP 1.2 Data Mover および Ceph を操作するための環境を準備したときに作成した Restic
Secret
を使用します。そうしない場合、CR はこのパラメーターのデフォルト値dm-credential
を使用します。 - 2
storageClass
ボリュームごとに異なるVolumeOptionsForStorageClass
ラベルのセットを定義できるため、異なるプロバイダーのボリュームへのバックアップが可能になります。VolumeOptionsForStorageClass
パラメーターは、CephFS で使用するためのものです。ただし、オプションのVolumeOptionsForStorageClass
パラメーターは、どのストレージタイプでも使用できます。
4.9.3.4.2. OADP 1.2 Data Mover と分割ボリュームを使用したデータのバックアップ
OpenShift API for Data Protection (OADP) 1.2 Data Mover を使用して、分割ボリュームのある環境でデータをバックアップできます。
手順
次の例のように、
Backup
CR を作成します。Backup
CR の例apiVersion: velero.io/v1 kind: Backup metadata: name: <backup_name> namespace: <protected_ns> spec: includedNamespaces: - <app_ns> storageLocation: velero-sample-1
次の手順を実行して、
VolumeSnapshotBackup
CR の進行状況を監視します。すべての
VolumeSnapshotBackup
CR の進行状況を確認するには、次のコマンドを実行します。$ oc get vsb -n <app_ns>
特定の
VolumeSnapshotBackup
CR の進行状況を確認するには、次のコマンドを実行します。$ oc get vsb <vsb_name> -n <app_ns> -ojsonpath="{.status.phase}`
-
VolumeSnapshotBackup
CR のステータスがCompleted
になるまで、数分間待ちます。 -
Restic
Secret
で指定されたスナップショットがオブジェクトストアに少なくとも 1 つあることを確認します。/<OADP-namespace>
という接頭辞を持つ、対象のBackupStorageLocation
ストレージプロバイダーでこのスナップショットを確認できます。
4.9.3.4.3. OADP 1.2 Data Mover と分割ボリュームを使用したデータのリストア
CephFS ストレージのシャローコピー機能がバックアップ手順で有効になっている場合、OpenShift API for Data Protection (OADP) 1.2 Data Mover を使用して、分割ボリュームのある環境でデータをリストアできます。シャローコピー機能は復元手順では使用されません。
手順
次のコマンドを実行して、アプリケーションの namespace を削除します。
$ oc delete vsb -n <app_namespace> --all
次のコマンドを実行して、バックアップ中に作成された
VolumeSnapshotContent
CR を削除します。$ oc delete volumesnapshotcontent --all
次の例のように、
Restore
CR を作成します。Restore
CR の例apiVersion: velero.io/v1 kind: Restore metadata: name: <restore_name> namespace: <protected_ns> spec: backupName: <previous_backup_name>
次の手順を実行して、
VolumeSnapshotRestore
CR の進行状況を監視します。すべての
VolumeSnapshotRestore
CR の進行状況を確認するには、次のコマンドを実行します。$ oc get vsr -n <app_ns>
特定の
VolumeSnapshotRestore
CR の進行状況を確認するには、次のコマンドを実行します。$ oc get vsr <vsr_name> -n <app_ns> -ojsonpath="{.status.phase}
次のコマンドを実行して、アプリケーションデータが復元されたことを確認します。
$ oc get route <route_name> -n <app_ns> -ojsonpath="{.spec.host}"
4.9.4. OADP 1.1 Data Mover を使用したバックアップ後のクリーンアップ
OADP 1.1 Data Mover の場合、バックアップを実行した後にデータクリーンアップを実行する必要があります。
クリーンアップには、次のリソースの削除が含まれます。
- バケット内のスナップショット
- クラスターリソース
- スケジュールに従って実行されるか、繰り返し実行されるバックアップ手順の後のボリュームスナップショットバックアップ (VSB)
4.9.4.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.9.4.2. クラスターリソースの削除
OADP 1.1 Data Mover は、コンテナーストレージインターフェイス (CSI) ボリュームのスナップショットをリモートオブジェクトストアに正常にバックアップするかどうかに関係なく、クラスターリソースを残す場合があります。
4.9.4.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.9.4.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
VolumeSnapshot
CR を削除します。$ oc delete volumesnapshot -A --all
VolumeSnapshotContent
CR を削除します。$ 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
VolumeSnapshot
CR を削除します。$ oc delete volumesnapshot -A --all
VolumeSnapshotContent
CR を削除します。$ oc delete volumesnapshotcontent --all
namespace 上の
ReplicationDestination
リソースをすべて削除します。$ oc delete replicationdestination -n <protected_namespace> --all
4.10. OADP 1.3 Data Mover
4.10.1. OADP 1.3 Data Mover について
OADP 1.3 には、Container Storage Interface (CSI) ボリュームのスナップショットをリモートオブジェクトストアに移動するために使用できる、ビルトイン Data Mover が含まれています。ビルトイン Data Mover を使用すると、クラスターの障害、誤削除、または破損が発生した場合に、リモートオブジェクトストアからステートフルアプリケーションを復元できます。スナップショットデータを読み取り、統合リポジトリーに書き込むためのアップローダーメカニズムとして Kopia を使用します。
OADP は、以下で CSI スナップショットをサポートします。
- Red Hat OpenShift Data Foundation
- Kubernetes Volume Snapshot API をサポートする Container Storage Interface (CSI) ドライバーを使用するその他のクラウドストレージプロバイダー
OADP のビルトイン Data Mover は、テクノロジープレビューのみの機能です。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
4.10.1.1. ビルトイン Data Mover の有効化
ビルトイン Data Mover を有効にするには、CSI プラグインを組み込み、DataProtectionApplication
カスタムリソース (CR) でノードエージェントを有効にする必要があります。ノードエージェントは、データ移動モジュールをホストする Kubernetes デーモンセットです。これには、Data Mover のコントローラー、アップローダー、リポジトリーが含まれます。
DataProtectionApplication
マニフェストの例
apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: dpa-sample spec: configuration: nodeAgent: enable: true 1 uploaderType: kopia 2 velero: defaultPlugins: - openshift - aws - csi 3 # ...
4.10.1.2. ビルトイン Data Mover のコントローラーとカスタムリソース定義 (CRD)
ビルトイン Data Mover 機能には、バックアップと復元を管理するための CRD として定義された 3 つの新しい API オブジェクトが導入されています。
-
DataDownload
: ボリュームスナップショットのデータダウンロードを表します。CSI プラグインは、復元するボリュームごとに 1 つのDataDownload
オブジェクトを作成します。DataDownload
CR には、ターゲットボリューム、指定された Data Mover、現在のデータダウンロードの進行状況、指定されたバックアップリポジトリー、プロセス完了後の現在のデータダウンロードの結果に関する情報が含まれます。 -
DataUpload
: ボリュームスナップショットのデータアップロードを表します。CSI プラグインは、CSI スナップショットごとに 1 つのDataUpload
オブジェクトを作成します。DataUpload
CR には、指定されたスナップショット、指定された Data Mover、指定されたバックアップリポジトリー、現在のデータアップロードの進行状況、およびプロセス完了後の現在のデータアップロードの結果に関する情報が含まれます。 -
BackupRepository
: バックアップリポジトリーのライフサイクルを表し、管理します。OADP は、namespace の最初の CSI スナップショットバックアップまたは復元が要求されると、namespace ごとにバックアップリポジトリーを作成します。
4.10.2. CSI スナップショットのバックアップと復元
OADP 1.3 Data Mover を使用して、永続ボリュームのバックアップと復元を実行できます。
4.10.2.1. CSI スナップショットを使用した永続ボリュームのバックアップ
OADP Data Mover を使用して、Container Storage Interface (CSI) ボリュームのスナップショットをリモートオブジェクトストアにバックアップできます。
前提条件
-
cluster-admin
ロールでクラスターにアクセスできる。 - OADP Operator がインストールされている。
-
CSI プラグインを組み込み、
DataProtectionApplication
カスタムリソース (CR) でノードエージェントを有効にしている。 - 別の namespace で実行されている永続ボリュームを持つアプリケーションがある。
-
metadata.labels.velero.io/csi-volumesnapshot-class: "true"
のキー/値ペアをVolumeSnapshotClass
CR に追加している。
手順
次の例のように、
Backup
オブジェクトの YAML ファイルを作成します。Backup
CR の例kind: Backup apiVersion: velero.io/v1 metadata: name: backup namespace: openshift-adp spec: csiSnapshotTimeout: 10m0s defaultVolumesToFsBackup: false includedNamespaces: - mysql-persistent itemOperationTimeout: 4h0m0s snapshotMoveData: true 1 storageLocation: default ttl: 720h0m0s volumeSnapshotLocations: - dpa-sample-1 # ...
- 1
- CSI スナップショットのリモートオブジェクトストレージへの移動を有効にするには、
true
に設定します。
注記XFS ファイルシステムを使用してボリュームをフォーマットし、ボリュームの容量が 100% になっている場合は、
no space left on device
エラーが発生してバックアップが失敗します。以下に例を示します。Error: relabel failed /var/lib/kubelet/pods/3ac..34/volumes/ \ kubernetes.io~csi/pvc-684..12c/mount: lsetxattr /var/lib/kubelet/ \ pods/3ac..34/volumes/kubernetes.io~csi/pvc-68..2c/mount/data-xfs-103: \ no space left on device
このシナリオでは、バックアップが正常に完了するように、ボリュームのサイズを変更するか、
ext4
などの別のファイルシステムタイプを使用することを検討してください。マニフェストを適用します。
$ oc create -f backup.yaml
スナップショットの作成が完了すると、
DataUpload
CR が作成されます。
検証
DataUpload
CR のstatus.phase
フィールドを監視して、スナップショットデータがリモートオブジェクトストアに正常に転送されたことを確認します。使用される値は、In Progress
、Completed
、Failed
、またはCanceled
です。オブジェクトストアは、DataProtectionApplication
CR のbackupLocations
スタンザで設定されます。次のコマンドを実行して、すべての
DataUpload
オブジェクトのリストを取得します。$ oc get datauploads -A
出力例
NAMESPACE NAME STATUS STARTED BYTES DONE TOTAL BYTES STORAGE LOCATION AGE NODE openshift-adp backup-test-1-sw76b Completed 9m47s 108104082 108104082 dpa-sample-1 9m47s ip-10-0-150-57.us-west-2.compute.internal openshift-adp mongo-block-7dtpf Completed 14m 1073741824 1073741824 dpa-sample-1 14m ip-10-0-150-57.us-west-2.compute.internal
次のコマンドを実行して、
DataUpload
オブジェクトのstatus.phase
フィールドの値を確認します。$ oc get datauploads <dataupload_name> -o yaml
出力例
apiVersion: velero.io/v2alpha1 kind: DataUpload metadata: name: backup-test-1-sw76b namespace: openshift-adp spec: backupStorageLocation: dpa-sample-1 csiSnapshot: snapshotClass: "" storageClass: gp3-csi volumeSnapshot: velero-mysql-fq8sl operationTimeout: 10m0s snapshotType: CSI sourceNamespace: mysql-persistent sourcePVC: mysql status: completionTimestamp: "2023-11-02T16:57:02Z" node: ip-10-0-150-57.us-west-2.compute.internal path: /host_pods/15116bac-cc01-4d9b-8ee7-609c3bef6bde/volumes/kubernetes.io~csi/pvc-eead8167-556b-461a-b3ec-441749e291c4/mount phase: Completed 1 progress: bytesDone: 108104082 totalBytes: 108104082 snapshotID: 8da1c5febf25225f4577ada2aeb9f899 startTimestamp: "2023-11-02T16:56:22Z"
- 1
- これは、スナップショットデータがリモートオブジェクトストアに正常に転送されたことを示しています。
4.10.2.2. CSI ボリュームスナップショットの復元
Restore
CR を作成することで、ボリュームスナップショットを復元できます。
OAPD 1.3 のビルトイン Data Mover を使用して、OADP 1.2 から Volsync バックアップを復元することはできません。OADP 1.3 にアップグレードする前に、Restic を使用してすべてのワークロードのファイルシステムバックアップを実行することが推奨されます。
前提条件
-
cluster-admin
ロールでクラスターにアクセスできる。 -
データの復元元となる OADP
Backup
CR がある。
手順
次の例のように、
Restore
CR の YAML ファイルを作成します。Restore
CR の例apiVersion: velero.io/v1 kind: Restore metadata: name: restore namespace: openshift-adp spec: backupName: <backup> # ...
マニフェストを適用します。
$ oc create -f restore.yaml
復元が開始されると、
DataDownload
が作成されます。
検証
DataDownload
CR のstatus.phase
フィールドをチェックすることで、復元プロセスのステータスを監視できます。使用される値は、In Progress
、Completed
、Failed
、またはCanceled
です。すべての
DataDownload
オブジェクトのリストを取得するには、次のコマンドを実行します。$ oc get datadownloads -A
出力例
NAMESPACE NAME STATUS STARTED BYTES DONE TOTAL BYTES STORAGE LOCATION AGE NODE openshift-adp restore-test-1-sk7lg Completed 7m11s 108104082 108104082 dpa-sample-1 7m11s ip-10-0-150-57.us-west-2.compute.internal
次のコマンドを入力して、特定の
DataDownload
オブジェクトのstatus.phase
フィールドの値を確認します。$ oc get datadownloads <datadownload_name> -o yaml
出力例
apiVersion: velero.io/v2alpha1 kind: DataDownload metadata: name: restore-test-1-sk7lg namespace: openshift-adp spec: backupStorageLocation: dpa-sample-1 operationTimeout: 10m0s snapshotID: 8da1c5febf25225f4577ada2aeb9f899 sourceNamespace: mysql-persistent targetVolume: namespace: mysql-persistent pv: "" pvc: mysql status: completionTimestamp: "2023-11-02T17:01:24Z" node: ip-10-0-150-57.us-west-2.compute.internal phase: Completed 1 progress: bytesDone: 108104082 totalBytes: 108104082 startTimestamp: "2023-11-02T17:00:52Z"
- 1
- CSI スナップショットデータが正常に復元されたことを示します。
4.11. トラブルシューティング
OpenShift CLI ツール または Velero CLI ツール を使用して、Velero カスタムリソース (CR) をデバッグできます。Velero CLI ツールは、より詳細なログおよび情報を提供します。
インストールの問題、CR のバックアップと復元の問題、および Restic の問題 を確認できます。
ログと CR 情報は、must-gather
ツール を使用して収集できます。
Velero CLI ツールは、次の方法で入手できます。
- Velero CLI ツールをダウンロードする
- クラスター内の Velero デプロイメントで Velero バイナリーにアクセスする
4.11.1. Velero CLI ツールをダウンロードする
Velero のドキュメントページ の手順に従って、Velero CLI ツールをダウンロードしてインストールできます。
このページには、以下に関する手順が含まれています。
- Homebrew を使用した macOS
- GitHub
- Chocolatey を使用した Windows
前提条件
- DNS とコンテナーネットワークが有効になっている、v1.16 以降の Kubernetes クラスターにアクセスできる。
-
kubectl
をローカルにインストールしている。
手順
- ブラウザーを開き、Velero Web サイト上の "Install the CLI" に移動します。
- macOS、GitHub、または Windows の適切な手順に従います。
- 使用している OADP および OpenShift Container Platform のバージョンに適切な Velero バージョンをダウンロードします。
4.11.1.1. OADP-Velero-OpenShift Container Platform バージョンの関係
OADP のバージョン | Velero のバージョン | OpenShift Container Platform バージョン |
---|---|---|
1.1.0 | 4.9 以降 | |
1.1.1 | 4.9 以降 | |
1.1.2 | 4.9 以降 | |
1.1.3 | 4.9 以降 | |
1.1.4 | 4.9 以降 | |
1.1.5 | 4.9 以降 | |
1.1.6 | 4.11 以降 | |
1.1.7 | 4.11 以降 | |
1.2.0 | 4.11 以降 | |
1.2.1 | 4.11 以降 | |
1.2.2 | 4.11 以降 | |
1.2.3 | 4.11 以降 | |
1.3.0 | 4.10 - 4.15 | |
1.3.1 | 4.10 - 4.15 | |
1.3.2 | 4.10 - 4.15 | |
1.3.3 | 4.10 - 4.15 |
4.11.2. クラスター内の Velero デプロイメントで Velero バイナリーにアクセスする
shell コマンドを使用して、クラスター内の Velero デプロイメントの Velero バイナリーにアクセスできます。
前提条件
-
DataProtectionApplication
カスタムリソースのステータスがReconcile complete
である。
手順
次のコマンドを入力して、必要なエイリアスを設定します。
$ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
4.11.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.11.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
次の種類の復元エラーと警告が、velero describe
リクエストの出力に表示されます。
-
Velero
: Velero 自体の操作に関連するメッセージのリスト (クラウドへの接続、バックアップファイルの読み取りなどに関連するメッセージなど) -
Cluster
: クラスタースコープのリソースのバックアップまたは復元に関連するメッセージのリスト -
Namespaces
: namespace に保存されているリソースのバックアップまたは復元に関連するメッセージのリスト
これらのカテゴリーのいずれかで 1 つ以上のエラーが発生すると、Restore
操作のステータスが PartiallyFailed
になり、Completed
ではなくなります。警告によって完了ステータスが変化することはありません。
-
リソース固有のエラー、つまり
Cluster
およびNamespaces
エラーの場合、restore describe --details
出力に、Velero が復元に成功したすべてのリソースのリストが含まれています。このようなエラーが発生したリソースは、そのリソースが実際にクラスター内に存在するかどうかを確認してください。 describe
コマンドの出力にVelero
エラーがあっても、リソース固有のエラーがない場合は、ワークロードの復元で実際の問題が発生することなく復元が完了した可能性があります。ただし、復元後のアプリケーションを十分に検証してください。たとえば、出力に
PodVolumeRestore
またはノードエージェント関連のエラーが含まれている場合は、PodVolumeRestores
とDataDownloads
のステータスを確認します。これらのいずれも失敗していないか、まだ実行中である場合は、ボリュームデータが完全に復元されている可能性があります。
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.11.5. メモリーまたは CPU の不足により Pod がクラッシュまたは再起動する
メモリーまたは CPU の不足により Velero または Restic Pod がクラッシュした場合、これらのリソースのいずれかに対して特定のリソースリクエストを設定できます。
関連情報
4.11.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.11.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.11.6. StorageClass が NFS の場合、PodVolumeRestore は完了しない
Restic
または Kopia
を使用して NFS を復元するときにボリュームが複数あると、復元操作は失敗します。PodVolumeRestore
は、次のエラーで失敗するか、復元を試行し続けた後に最終的に失敗します。
エラーメッセージ
Velero: pod volume restore failed: data path restore failed: \ Failed to run kopia restore: Failed to copy snapshot data to the target: \ restore error: copy file: error creating file: \ open /host_pods/b4d...6/volumes/kubernetes.io~nfs/pvc-53...4e5/userdata/base/13493/2681: \ no such file or directory
原因
復元する 2 つのボリュームの NFS マウントパスは一意ではありません。その結果、velero
ロックファイルは復元中に NFS サーバー上の同じファイルを使用するため、PodVolumeRestore
が失敗します。
解決方法
この問題は、deploy/class.yaml
ファイルで nfs-subdir-external-provisioner
の StorageClass
を定義しながら、ボリュームごとに一意の pathPattern
を設定することで解決できます。次の nfs-subdir-external-provisioner
StorageClass
の例を使用します。
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: nfs-client
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner
parameters:
pathPattern: "${.PVC.namespace}/${.PVC.annotations.nfs.io/storage-path}" 1
onDelete: delete
- 1
- ラベル、アノテーション、名前、namespace などの
PVC
メタデータを使用してディレクトリーパスを作成するためのテンプレートを指定します。メタデータを指定するには、${.PVC.<metadata>}
を使用します。たとえば、フォルダーに<pvc-namespace>-<pvc-name>
という名前を付けるには、pathPattern
として${.PVC.namespace}-${.PVC.name}
使用します。
4.11.7. Velero と受付 Webhook に関する問題
Velero では、復元中に受付 Webhook の問題を解決する機能が制限されています。受付 Webhook を使用するワークロードがある場合は、追加の Velero プラグインを使用するか、ワークロードの復元方法を変更する必要がある場合があります。
通常、受付 Webhook を使用するワークロードでは、最初に特定の種類のリソースを作成する必要があります。通常、受付 Webhook は子リソースをブロックするため、これは特にワークロードに子リソースがある場合に当てはまります。
たとえば、service.serving.knative.dev
などの最上位オブジェクトを作成または復元すると、通常、子リソースが自動的に作成されます。最初にこれを行う場合、Velero を使用してこれらのリソースを作成および復元する必要はありません。これにより、Velero が使用する可能性のある受付 Webhook によって子リソースがブロックされるという問題が回避されます。
4.11.7.1. 受付 Webhook を使用する Velero バックアップの回避策の復元
このセクションでは、受付 Webhook を使用するいくつかのタイプの Velero バックアップのリソースを復元するために必要な追加の手順を説明します。
4.11.7.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.11.7.1.2. IBM AppConnect リソースの復元
Velero を使用して受付 Webhook を持つ IBM AppConnect リソースを復元するときに問題が発生した場合は、この手順のチェックを実行できます。
手順
クラスター内の
kind: MutatingWebhookConfiguration
の受付プラグインの変更があるかチェックします。$ oc get mutatingwebhookconfigurations
-
各
kind: MutatingWebhookConfiguration
の YAML ファイルを調べて、問題が発生しているオブジェクトの作成をブロックするルールがないことを確認します。詳細は、Kubernetes の公式ドキュメント を参照してください。 -
バックアップ時に使用される
type: Configuration.appconnect.ibm.com/v1beta1
のspec.version
が、インストールされている Operator のサポート対象であることを確認してください。
4.11.7.2. OADP プラグインの既知の問題
次のセクションでは、OpenShift API for Data Protection (OADP) プラグインの既知の問題を説明します。
4.11.7.2.1. シークレットがないことで、イメージストリームのバックアップ中に Velero プラグインでパニックが発生する
バックアップとバックアップ保存場所 (BSL) が Data Protection Application (DPA) の範囲外で管理されている場合、OADP コントローラー (つまり DPA の調整) によって関連する oadp-<bsl_name>-<bsl_provider>-registry-secret
が作成されません。
バックアップを実行すると、OpenShift Velero プラグインがイメージストリームバックアップでパニックになり、次のパニックエラーが表示されます。
024-02-27T10:46:50.028951744Z time="2024-02-27T10:46:50Z" level=error msg="Error backing up item" backup=openshift-adp/<backup name> error="error executing custom action (groupResource=imagestreams.image.openshift.io, namespace=<BSL Name>, name=postgres): rpc error: code = Aborted desc = plugin panicked: runtime error: index out of range with length 1, stack trace: goroutine 94…
4.11.7.2.1.1. パニックエラーを回避するための回避策
Velero プラグインのパニックエラーを回避するには、次の手順を実行します。
カスタム BSL に適切なラベルを付けます。
$ oc label BackupStorageLocation <bsl_name> app.kubernetes.io/component=bsl
BSL にラベルを付けた後、DPA の調整を待ちます。
注記DPA 自体に軽微な変更を加えることで、強制的に調整を行うことができます。
DPA の調整では、適切な
oadp-<bsl_name>-<bsl_provider>-registry-secret
が作成されていること、正しいレジストリーデータがそこに設定されていることを確認します。$ oc -n openshift-adp get secret/oadp-<bsl_name>-<bsl_provider>-registry-secret -o json | jq -r '.data'
4.11.7.2.2. OpenShift ADP Controller のセグメンテーション違反
cloudstorage
と restic
の両方を有効にして DPA を設定すると、openshift-adp-controller-manager
Pod がクラッシュし、Pod がクラッシュループのセグメンテーション違反で失敗するまで無期限に再起動します。
velero
または cloudstorage
は相互に排他的なフィールドであるため、どちらか一方だけ定義できます。
-
velero
とcloudstorage
の両方が定義されている場合、openshift-adp-controller-manager
は失敗します。 -
velero
とcloudstorage
のいずれも定義されていない場合、openshift-adp-controller-manager
は失敗します。
この問題の詳細は、OADP-1054 を参照してください。
4.11.7.2.2.1. OpenShift ADP Controller のセグメンテーション違反の回避策
DPA の設定時に、velero
または cloudstorage
のいずれかを定義する必要があります。DPA で両方の API を定義すると、openshift-adp-controller-manager
Pod がクラッシュループのセグメンテーション違反で失敗します。
4.11.7.3. Velero プラグインがメッセージ "received EOF, stopping recv loop" を返す
Velero プラグインは、別のプロセスとして開始されます。Velero 操作が完了すると、成功したかどうかにかかわらず終了します。デバッグログの received EOF, stopping recv loop
メッセージは、プラグイン操作が完了したことを示します。エラーが発生したわけではありません。
4.11.8. インストールの問題
Data Protection Application をインストールするときに、無効なディレクトリーまたは誤った認証情報を使用することによって問題が発生する可能性があります。
4.11.8.1. バックアップストレージに無効なディレクトリーが含まれています
Velero
Pod ログにエラーメッセージ Backup storage contains invalid top-level directories
が表示されます。
原因
オブジェクトストレージには、Velero ディレクトリーではないトップレベルのディレクトリーが含まれています。
解決方法
オブジェクトストレージが Velero 専用でない場合は、DataProtectionApplication
マニフェストで spec.backupLocations.velero.objectStorage.prefix
パラメーターを設定して、バケットの接頭辞を指定する必要があります。
4.11.8.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.11.9. OADP Operator の問題
OpenShift API for Data Protection (OADP) Operator では、解決できない問題が原因で問題が発生する可能性があります。
4.11.9.1. OADP Operator がサイレントに失敗する
OADP Operator の S3 バケットは空である可能性がありますが、oc get po -n <OADP_Operator_namespace>
コマンドを実行すると、Operator のステータスが Running
であることがわかります。この場合、Operator は実行中であると誤報告するため、サイレントに失敗した と言われます。
原因
この問題は、クラウド認証情報で提供される権限が不十分な場合に発生します。
解決方法
Backup Storage Location (BSL) のリストを取得し、各 BSL のマニフェストで認証情報の問題を確認します。
手順
次のコマンドのいずれかを実行して、BSL のリストを取得します。
OpenShift CLI を使用する場合:
$ oc get backupstoragelocation -A
Velero CLI を使用する場合:
$ velero backup-location get -n <OADP_Operator_namespace>
BSL のリストを使用し、次のコマンドを実行して各 BSL のマニフェストを表示し、各マニフェストにエラーがないか調べます。
$ oc get backupstoragelocation -n <namespace> -o yaml
結果の例:
apiVersion: v1 items: - apiVersion: velero.io/v1 kind: BackupStorageLocation metadata: creationTimestamp: "2023-11-03T19:49:04Z" generation: 9703 name: example-dpa-1 namespace: openshift-adp-operator ownerReferences: - apiVersion: oadp.openshift.io/v1alpha1 blockOwnerDeletion: true controller: true kind: DataProtectionApplication name: example-dpa uid: 0beeeaff-0287-4f32-bcb1-2e3c921b6e82 resourceVersion: "24273698" uid: ba37cd15-cf17-4f7d-bf03-8af8655cea83 spec: config: enableSharedConfig: "true" region: us-west-2 credential: key: credentials name: cloud-credentials default: true objectStorage: bucket: example-oadp-operator prefix: example provider: aws status: lastValidationTime: "2023-11-10T22:06:46Z" message: "BackupStorageLocation \"example-dpa-1\" is unavailable: rpc error: code = Unknown desc = WebIdentityErr: failed to retrieve credentials\ncaused by: AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity\n\tstatus code: 403, request id: d3f2e099-70a0-467b-997e-ff62345e3b54" phase: Unavailable kind: List metadata: resourceVersion: ""
4.11.10. OADP タイムアウト
タイムアウトを延長すると、複雑なプロセスやリソースを大量に消費するプロセスが途中で終了することなく正常に完了できます。この設定により、エラー、再試行、または失敗の可能性を減らすことができます。
過度に長いタイムアウトを設定しないように、論理的な方法でタイムアウト延長のバランスをとってください。過度に長いと、プロセス内の根本的な問題が隠れる可能性があります。プロセスのニーズとシステム全体のパフォーマンスを満たす適切なタイムアウト値を慎重に検討して、監視してください。
次に、さまざまな OADP タイムアウトと、これらのパラメーターをいつどのように実装するかの手順を示します。
4.11.10.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"
手順
次の例のように、
DataProtectionApplication
CR マニフェストのspec.configuration.restic.timeout
ブロックの値を編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_name> spec: configuration: restic: timeout: 1h # ...
4.11.10.2. Velero リソースのタイムアウト
resourceTimeout
は Velero カスタムリソース定義 (CRD) の可用性、volumeSnapshot
の削除、リポジトリーの可用性など、タイムアウトが発生する前に複数の Velero リソースを待機する時間を定義します。デフォルトは 10m
です。
次のシナリオでは resourceTimeout
を使用します。
合計 PV データ使用量が 1TB を超えるバックアップの場合。このパラメーターは、バックアップを完了としてマークする前に、Velero が Container Storage Interface (CSI) スナップショットをクリーンアップまたは削除しようとするときのタイムアウト値として使用されます。
- このクリーンアップのサブタスクは VSC にパッチを適用しようとします。このタイムアウトはそのタスクに使用できます。
- Restic または Kopia のファイルシステムベースのバックアップのバックアップリポジトリーを作成または準備できるようにするため。
- カスタムリソース (CR) またはバックアップからリソースを復元する前に、クラスター内で Velero CRD が利用可能かどうかを確認します。
手順
次の例のように、
DataProtectionApplication
CR マニフェストのspec.configuration.velero.resourceTimeout
ブロックの値を編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_name> spec: configuration: velero: resourceTimeout: 10m # ...
4.11.10.3. Data Mover のタイムアウト
timeout
は、VolumeSnapshotBackup
および VolumeSnapshotRestore
を完了するためにユーザーが指定したタイムアウトです。デフォルト値は 10m
です。
次のシナリオでは、Data Mover timeout
を使用します。
-
VolumeSnapshotBackups
(VSB) およびVolumeSnapshotRestores
(VSR) を作成する場合は、10 分後にタイムアウトします。 -
合計 PV データ使用量が 500GB を超える大規模環境向け。
1h
のタイムアウトを設定します。 -
VolumeSnapshotMover
(VSM) プラグインを使用します。 - OADP 1.1.x のみ。
手順
次の例のように、
DataProtectionApplication
CR マニフェストのspec.features.dataMover.timeout
ブロックの値を編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_name> spec: features: dataMover: timeout: 10m # ...
4.11.10.4. CSI スナップショットのタイムアウト
CSISnapshotTimeout
は、タイムアウトとしてエラーを返す前に、CSI VolumeSnapshot
ステータスが ReadyToUse
になるまで待機する作成時の時間を指定します。デフォルト値は 10m
です。
以下のシナリオでは、CSISnapshotTimeout
を使用します。
- CSI プラグイン。
- スナップショットの作成に 10 分以上かかる可能性がある非常に大規模なストレージボリュームの場合。ログにタイムアウトが見つかった場合は、このタイムアウトを調整します。
通常、CSISnapshotTimeout
のデフォルト値は、デフォルト設定で大規模なストレージボリュームに対応できるため、調整する必要はありません。
手順
次の例のように、
Backup
CR マニフェストのspec.csiSnapshotTimeout
ブロックの値を編集します。apiVersion: velero.io/v1 kind: Backup metadata: name: <backup_name> spec: csiSnapshotTimeout: 10m # ...
4.11.10.5. Velero におけるアイテム操作のデフォルトタイムアウト
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 の復元のみを定義できます。
手順
次の例のように、
DataProtectionApplication
CR マニフェストのspec.configuration.velero.defaultItemOperationTimeout
ブロックの値を編集します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: <dpa_name> spec: configuration: velero: defaultItemOperationTimeout: 1h # ...
4.11.10.6. アイテム操作のタイムアウト - 復元
ItemOperationTimeout
は RestoreItemAction
操作の待機に使用される時間を指定します。デフォルト値は 1h
です。
以下のシナリオでは、復元 ItemOperationTimeout
を使用します。
- Data Mover 1.2.x のみ。
-
Data Mover の場合は、
BackupStorageLocation
にアップロードおよびダウンロードします。タイムアウトに達しても復元アクションが完了しない場合、失敗としてマークされます。ストレージボリュームのサイズが大きいため、タイムアウトの問題が原因で Data Mover の操作が失敗する場合は、このタイムアウト設定を増やす必要がある場合があります。
手順
次の例のように、
Restore
CR マニフェストのRestore.spec.itemOperationTimeout
ブロックの値を編集します。apiVersion: velero.io/v1 kind: Restore metadata: name: <restore_name> spec: itemOperationTimeout: 1h # ...
4.11.10.7. アイテム操作のタイムアウト - バックアップ
ItemOperationTimeout
は、非同期 BackupItemAction
操作の待機時間を指定します。デフォルト値は 1h
です。
次のシナリオでは、バックアップ ItemOperationTimeout
を使用します。
- Data Mover 1.2.x のみ。
-
Data Mover の場合は、
BackupStorageLocation
にアップロードおよびダウンロードします。タイムアウトに達してもバックアップアクションが完了しない場合は、失敗としてマークされます。ストレージボリュームのサイズが大きいため、タイムアウトの問題が原因で Data Mover の操作が失敗する場合は、このタイムアウト設定を増やす必要がある場合があります。
手順
次の例のように、
Backup
CR マニフェストのBackup.spec.itemOperationTimeout
ブロックの値を編集します。apiVersion: velero.io/v1 kind: Backup metadata: name: <backup_name> spec: itemOperationTimeout: 1h # ...
4.11.11. CR の問題のバックアップおよび復元
Backup
および Restore
カスタムリソース (CR) でこれらの一般的な問題が発生する可能性があります。
4.11.11.1. バックアップ CR はボリュームを取得できません
Backup
CR は、エラーメッセージ InvalidVolume.NotFound: The volume ‘vol-xxxx’ does not exist
を表示します。
原因
永続ボリューム (PV) とスナップショットの場所は異なるリージョンにあります。
解決方法
-
DataProtectionApplication
マニフェストのspec.snapshotLocations.velero.config.region
キーの値を編集して、スナップショットの場所が PV と同じリージョンにあるようにします。 -
新しい
Backup
CR を作成します。
4.11.11.2. バックアップ CR ステータスは進行中のままです
Backup
CR のステータスは InProgress
のフェーズのままであり、完了しません。
原因
バックアップが中断された場合は、再開することができません。
解決方法
Backup
CR の詳細を取得します。$ oc -n {namespace} exec deployment/velero -c velero -- ./velero \ backup describe <backup>
Backup
CR を削除します。$ oc delete backup <backup> -n openshift-adp
進行中の
Backup
CR はファイルをオブジェクトストレージにアップロードしていないため、バックアップの場所をクリーンアップする必要はありません。-
新しい
Backup
CR を作成します。 Velero バックアップの詳細を表示します。
$ velero backup describe <backup-name> --details
4.11.11.3. バックアップ CR ステータスが PartiallyFailed のままになる
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
解決方法
Backup
CR を削除します。$ 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
-
新しい
Backup
CR を作成します。
4.11.12. Restic の問題
Restic を使用してアプリケーションのバックアップを作成すると、これらの問題が発生する可能性があります。
4.11.12.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 を指定します。
-
Restic
Pod が再起動し、変更が適用されるまで待機します。
4.11.12.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.11.13. must-gather ツールの使用
must-gather
ツールを使用して、OADP カスタムリソースのログ、メトリック、および情報を収集できます。
must-gather
データはすべてのカスタマーケースに割り当てられる必要があります。
前提条件
-
cluster-admin
ロールを持つユーザーとして OpenShift Container Platform クラスターにログインしている。 -
OpenShift CLI (
oc
) がインストールされている。
手順
-
must-gather
データを保存するディレクトリーに移動します。 -
次のデータ収集オプションのいずれかに対して、
oc adm must-gather
コマンドを実行します。
関連情報
4.11.13.1. 安全でない TLS 接続で must-gather を使用する
カスタム CA 証明書が使用されている場合、must-gather
Pod は velero logs/describe
の出力を取得できません。安全でない TLS 接続で must-gather
ツールを使用するには、gather_without_tls
フラグを must-gather
コマンドに渡します。
手順
-
次のコマンドを使用して、値を
true
に設定したgather_without_tls
フラグをmust-gather
ツールに渡します。
$ oc adm must-gather --image=registry.redhat.io/oadp/oadp-mustgather-rhel9:v1.3 -- /usr/bin/gather_without_tls <true/false>
デフォルトでは、フラグの値は false
に設定されています。安全でない TLS 接続を許可するには、値を true
に設定します。
4.11.13.2. must-gather ツールを使用する場合のオプションの組み合わせ
現時点では、たとえば安全でない TLS 接続を許可しながらタイムアウトしきい値を指定するなど、must-gather スクリプトを組み合わせることはできません。状況によっては、次の例のように must-gather コマンドラインで内部変数を設定することで、この制限を回避できます。
$ oc adm must-gather --image=brew.registry.redhat.io/rh-osbs/oadp-oadp-mustgather-rhel8:1.1.1-8 -- skip_tls=true /usr/bin/gather_with_timeout <timeout_value_in_seconds>
この例では、gather_with_timeout
スクリプトを実行する前に、skip_tls
変数を設定します。その結果、Gather_with_timeout
と Gather_without_tls
が組み合わされます。
この方法で指定できる他の変数は次のとおりです。
-
logs_since
、デフォルト値は72h
-
request_timeout
、デフォルト値は0s
4.11.14. OADP モニタリング
OpenShift Container Platform は、ユーザーと管理者がクラスターを効果的に監視および管理できるだけでなく、クラスター上で実行されているユーザーアプリケーションやサービスのワークロードパフォーマンスを監視および分析できるようにする監視スタックを提供します (イベント発生時のアラートの受信など)。
関連情報
4.11.14.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-monitoring
namespace でcluster-monitoring-config
ConfigMap
オブジェクトを編集します。$ 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-monitoring
namespace で次のコンポーネントが稼働しているかどうかを確認して、ユーザーワークロードモニタリングのセットアップを検証します。$ 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-config
ConfigMap が存在することを確認します。存在する場合、この手順の残りの手順はスキップしてください。$ 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-config
ConfigMap
オブジェクトを作成し、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.11.14.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
既存のサービスラベルと一致する
ServiceMonitor
YAML ファイルを作成し、そのファイルを3_create_oadp_service_monitor.yaml
として保存します。サービスモニターはopenshift-adp-velero-metrics-svc
サービスが存在するopenshift-adp
namespace に作成されます。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.11.14.3. アラートルールの作成
OpenShift Container Platform モニタリングスタックでは、アラートルールを使用して設定されたアラートを受信できます。OADP プロジェクトのアラートルールを作成するには、ユーザーワークロードの監視で収集されたメトリックの 1 つを使用します。
手順
サンプル
OADPBackupFailing
アラートを含むPrometheusRule
YAML ファイルを作成し、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-adp
namespace に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.11.14.4. 利用可能なメトリックのリスト
これらは、OADP によって提供されるメトリックとその Type のリストです。
メトリクス名 | 説明 | タイプ |
---|---|---|
| キャッシュから取得したバイト数 | カウンター |
| コンテンツがキャッシュから取得された回数 | カウンター |
| 不正なコンテンツがキャッシュから読み取られた回数 | カウンター |
| コンテンツがキャッシュ内で見つからずフェッチされた回数 | カウンター |
| 基盤となるストレージから取得したバイト数 | カウンター |
| 基盤となるストレージでコンテンツが見つからなかった回数 | カウンター |
| コンテンツをキャッシュに保存できなかった回数 | カウンター |
|
| カウンター |
|
| カウンター |
|
| カウンター |
|
| カウンター |
|
| カウンター |
|
| カウンター |
| 試行されたバックアップの合計数 | カウンター |
| 試行されたバックアップ削除の合計数 | カウンター |
| 失敗したバックアップ削除の合計数 | カウンター |
| 成功したバックアップ削除の合計数 | カウンター |
| バックアップの完了にかかる時間 (秒単位) | ヒストグラム |
| 失敗したバックアップの合計数 | カウンター |
| バックアップ中に発生したエラーの合計数 | ゲージ |
| バックアップされたアイテムの総数 | ゲージ |
| バックアップの最終ステータス。値 1 は成功、値 0 は成功です。 | ゲージ |
| 最後にバックアップが正常に実行された時刻、秒単位の Unix タイムスタンプ | ゲージ |
| 部分的に失敗したバックアップの合計数 | カウンター |
| 成功したバックアップの合計数 | カウンター |
| バックアップのサイズ (バイト単位) | ゲージ |
| 既存のバックアップの現在の数 | ゲージ |
| 検証に失敗したバックアップの合計数 | カウンター |
| 警告されたバックアップの総数 | カウンター |
| CSI が試行したボリュームスナップショットの合計数 | カウンター |
| CSI で失敗したボリュームスナップショットの総数 | カウンター |
| CSI が成功したボリュームスナップショットの総数 | カウンター |
| 試行された復元の合計数 | カウンター |
| 失敗したリストアの合計数 | カウンター |
| 部分的に失敗したリストアの合計数 | カウンター |
| 成功した復元の合計数 | カウンター |
| 現在の既存のリストアの数 | ゲージ |
| 検証に失敗したリストアの失敗の合計数 | カウンター |
| 試行されたボリュームスナップショットの総数 | カウンター |
| 失敗したボリュームスナップショットの総数 | カウンター |
| 成功したボリュームスナップショットの総数 | カウンター |
4.11.14.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.12. OADP で使用される API
このドキュメントには、OADP で使用できる次の API に関する情報が記載されています。
- Velero API
- OADP API
4.12.1. Velero API
Velero API ドキュメントは、Red Hat ではなく、Velero によって管理されています。これは Velero API types にあります。
4.12.2. OADP API
次の表は、OADP API の構造を示しています。
プロパティー | 型 | 説明 |
---|---|---|
|
| |
|
| |
| map [ UnsupportedImageKey ] string |
デプロイされた依存イメージを開発用にオーバーライドするために使用できます。オプションは、 |
| Operator によってデプロイされた Pod にアノテーションを追加するために使用されます。 | |
| Pod の DNS の設定を定義します。 | |
|
| |
| *bool | イメージのバックアップと復元を有効にするためにレジストリーをデプロイメントするかどうかを指定するために使用されます。 |
| Data Protection Application のサーバー設定を定義するために使用されます。 | |
| テクノロジープレビュー機能を有効にするための DPA の設定を定義します。 |
プロパティー | 型 | 説明 |
---|---|---|
| Backup Storage Location で説明されているとおり、ボリュームスナップショットの保存場所。 | |
| [テクノロジープレビュー] 一部のクラウドストレージプロバイダーで、Backup Storage Location として使用するバケットの作成を自動化します。 |
bucket
パラメーターはテクノロジープレビュー機能としてのみ提供されます。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
プロパティー | 型 | 説明 |
---|---|---|
| Volume Snapshot Location で説明されているとおり、ボリュームスナップショットの保存場所。 |
SnapshotLocation
タプの完全なスキーマ定義。
プロパティー | 型 | 説明 |
---|---|---|
| Velero サーバーの設定を定義します。 | |
| Restic サーバーの設定を定義します。 |
ApplicationConfig
タイプの完全なスキーマ定義。
プロパティー | 型 | 説明 |
---|---|---|
| [] string | Velero インスタンスで有効にする機能のリストを定義します。 |
| [] string |
次のタイプのデフォルトの Velero プラグインをインストールできます: |
| カスタム Velero プラグインのインストールに使用されます。 デフォルトおよびカスタムのプラグインについては、OADP plug-ins で説明しています。 | |
|
| |
|
デフォルトの Backup Storage Location を設定せずに Velero をインストールするには、インストールを確認するために | |
|
| |
|
Velero サーバーのログレベル (最も詳細なログを記録するには |
プロパティー | 型 | 説明 |
---|---|---|
| カスタムプラグインの名前。 | |
| カスタムプラグインのイメージ。 |
プロパティー | 型 | 説明 |
---|---|---|
| *bool |
|
| []int64 |
|
|
Restic タイムアウトを定義するユーザー指定の期間文字列。デフォルト値は | |
|
|
プロパティー | 型 | 説明 |
---|---|---|
|
| |
|
Velero デプロイメントまたは Restic | |
|
Setting Velero CPU and memory resource allocations の説明に従って、 | |
| Pod に追加するラベル。 |
4.12.2.1. ノードエージェントとノードラベルの設定
OADP の DPA は、nodeSelector
フィールドを使用して、ノードエージェントを実行できるノードを選択します。nodeSelector
フィールドは、推奨される最も単純な形式のノード選択制約です。
指定したラベルが、各ノードのラベルと一致する必要があります。
選択した任意のノードでノードエージェントを実行する正しい方法は、ノードにカスタムラベルを付けることです。
$ oc label node/<node_name> node-role.kubernetes.io/nodeAgent=""
ノードのラベル付けに使用したのと同じカスタムラベルを DPA.spec.configuration.nodeAgent.podConfig.nodeSelector
で使用します。以下に例を示します。
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/nodeAgent: ""
次の例は nodeSelector
のアンチパターンです。この例は、ノードに 'node-role.kubernetes.io/infra: ""'
と 'node-role.kubernetes.io/worker: ""'
の両方のラベルがないと機能しません。
configuration: nodeAgent: enable: true podConfig: nodeSelector: node-role.kubernetes.io/infra: "" node-role.kubernetes.io/worker: ""
プロパティー | 型 | 説明 |
---|---|---|
| Data Mover の設定を定義します。 |
プロパティー | 型 | 説明 |
---|---|---|
|
| |
|
Data Mover のユーザー指定の Restic | |
|
|
OADP API の詳細は、OADP Operator を参照してください。
4.13. OADP の高度な特徴と機能
このドキュメントでは、OpenShift API for Data Protection (OADP) の高度な特徴と機能に関する情報を提供します。
4.13.1. 同一クラスター上での異なる Kubernetes API バージョンの操作
4.13.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.13.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.13.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: - EnableAPIGroupVersions
4.13.2. 1 つのクラスターからデータをバックアップし、別のクラスターに復元する
4.13.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.13.2.1.1. Operator
バックアップと復元を成功させるには、アプリケーションのバックアップから Operator を除外する必要があります。
4.13.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
と呼ばれます。
- AWS リージョン間または Microsoft Azure リージョン間でデータを移行するには、Velero の File System Backup も使用する必要があります。
- Velero は、ソースクラスターより 前 の Kubernetes バージョンを使用したクラスターへのデータの復元をサポートしていません。
- 理論的には、移行元よりも 新しい Kubernetes バージョンを備えた移行先にワークロードを移行することは可能ですが、カスタムリソースごとにクラスター間の API グループの互換性を考慮する必要があります。Kubernetes バージョンのアップグレードによりコアまたはネイティブ API グループの互換性が失われる場合は、まず影響を受けるカスタムリソースを更新する必要があります。
4.13.2.2. バックアップする Pod ボリュームの判断方法
ファイルシステムバックアップ (FSB) を使用してバックアップ操作を開始する前に、バックアップするボリュームが含まれる Pod を指定する必要があります。Velero では、このプロセスを適切な Pod ボリュームの "検出" と呼んでいます。
Velero は、Pod ボリュームを決定する方法として 2 つの方式をサポートしています。オプトイン方式かオプトアウト方式を使用して、Velero が FSB、ボリュームスナップショット、または Data Mover バックアップを決定できるようにします。
- オプトイン方式: オプトイン方式では、ボリュームがデフォルトでスナップショットまたは Data Mover を使用してバックアップされます。FSB は、アノテーションによってオプトインされた特定のボリュームで使用されます。
- オプトアウト方式: オプトアウト方式では、ボリュームがデフォルトで FSB を使用してバックアップされます。スナップショットまたは Data Mover は、アノテーションによってオプトアウトされた特定のボリュームで使用されます。
4.13.2.2.1. 制限
-
FSB は、
hostpath
ボリュームのバックアップと復元をサポートしていません。ただし、FSB はローカルボリュームのバックアップと復元をサポートします。 - Velero は、作成するすべてのバックアップリポジトリーに静的な共通暗号化キーを使用します。この静的キーは、バックアップストレージにアクセスできれば、誰でもバックアップデータを復号化できることを意味します。バックアップストレージへのアクセスを制限することが重要です。
PVC の場合、すべての増分バックアップチェーンは Pod が再スケジュールされても維持されます。
emptyDir
ボリュームなどの PVC ではない Pod ボリュームの場合、たとえばReplicaSet
やデプロイメントなどによって Pod が削除または再作成されると、そのボリュームの次回のバックアップは増分バックアップではなく完全バックアップになります。Pod ボリュームのライフサイクルは、その Pod によって定義されると想定されます。- バックアップデータは増分的に保存できますが、データベースなどの大きなファイルのバックアップには時間がかかることがあります。これは、FSB が重複排除を使用して、バックアップが必要な差分を見つけるためです。
- FSB は、Pod が実行されているノードのファイルシステムにアクセスすることで、ボリュームからデータを読み書きします。そのため、FSB は Pod からマウントされたボリュームのみバックアップでき、PVC から直接バックアップすることはできません。一部の Velero ユーザーは、Velero バックアップを実行する前に、無限スリープがある BusyBox や Alpine コンテナーなどのステージング Pod を実行して PVC と PV のペアをマウントすることで、この制限を克服しています。
-
FSB では、ボリュームは
<hostPath>/<pod UID>
の下にマウントされ、<hostPath>
が設定可能であると想定します。vCluster などの一部の Kubernetes システムでは、ボリュームを<pod UID>
サブディレクトリーにマウントしないため、そのようなシステムでは VFSB は期待どおり機能しません。
4.13.2.2.2. オプトインメソッドを使用して Pod ボリュームをバックアップする
オプトインメソッドを使用して、ファイルシステムバックアップ (FSB) でバックアップする必要のあるボリュームを指定できます。これを行うには、backup.velero.io/backup-volumes
コマンドを使用します。
手順
バックアップするボリュームを 1 つ以上含む各 Pod で、次のコマンドを入力します。
$ oc -n <your_pod_namespace> annotate pod/<your_pod_name> \ backup.velero.io/backup-volumes=<your_volume_name_1>, \ <your_volume_name_2>>,...,<your_volume_name_n>
ここでは、以下のようになります。
<your_volume_name_x>
- Pod 仕様の x 番目のボリュームの名前を指定します。
4.13.2.2.3. オプトアウトメソッドを使用して Pod ボリュームをバックアップする
オプトアウトアプローチを使用する場合、いくつかの例外を除き、すべての Pod ボリュームがファイルシステムバックアップ (FSB) を使用してバックアップされます。
- デフォルトのサービスアカウントトークン、シークレット、設定マップをマウントするボリューム。
-
hostPath
volumes
オプトアウトメソッドを使用して、バックアップしない ボリュームを指定できます。これを行うには、backup.velero.io/backup-volumes-excludes
コマンドを使用します。
手順
バックアップしないボリュームを 1 つ以上含む各 Pod で、次のコマンドを実行します。
$ oc -n <your_pod_namespace> annotate pod/<your_pod_name> \ backup.velero.io/backup-volumes-excludes=<your_volume_name_1>, \ <your_volume_name_2>>,...,<your_volume_name_n>
ここでは、以下のようになります。
<your_volume_name_x>
- Pod 仕様の x 番目のボリュームの名前を指定します。
--default-volumes-to-fs-backup
フラグを指定して velero install
コマンドを実行することで、すべての Velero バックアップに対してこの動作を有効にできます。
4.13.2.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 に
securityContext
UID を割り当てる場合、これはお客様のワークロードにとって問題になる可能性があります。- コンテナーの UID がファイル所有者の UID と一致しなくなった。
OpenShift Container Platform がバックアップクラスターデータと一致するように宛先クラスターの UID 範囲を変更していないため、エラーが発生する。その結果、バックアップクラスターは宛先クラスターとは異なる UID を持つことになり、アプリケーションは宛先クラスターに対してデータの読み取りまたは書き込みを行うことができなくなります。
- 軽減策
- 次の 1 つ以上の緩和策を使用して、UID 範囲および GID 範囲の問題を解決できます。
簡単な緩和策:
-
Backup
CR のラベルセレクターを使用して、バックアップに含めるオブジェクトをフィルター処理する場合は、必ずこのラベルセレクターをワークスペースを含む namespace に追加してください。 - 同じ名前の namespace を復元する前に、宛先クラスター上の namespace の既存のバージョンを削除してください。
-
高度な緩和策:
- 移行後に OpenShift namespace 内の重複する UID 範囲を解決する ことで、移行後の UID 範囲を修正します。ステップ 1 はオプションです。
あるクラスターでのデータのバックアップと別のクラスターでのリストアの問題の解決に重点を置いた、OpenShift Container Platform の UID 範囲および GID 範囲の詳細は、A Guide to OpenShift and UIDs を参照してください。
4.13.2.4. 1 つのクラスターからデータをバックアップし、別のクラスターに復元する
一般に、同じクラスターにデータをバックアップおよび復元するのと同じ方法で、1 つの OpenShift Container Platform クラスターからデータをバックアップし、別の OpenShift Container Platform クラスターに復元します。ただし、ある OpenShift Container Platform クラスターからデータをバックアップし、それを別のクラスターにリストアする場合は、追加の前提条件と手順の違いがいくつかあります。
前提条件
- お使いのプラットフォーム (AWS、Microsoft Azure、GCP など) でのバックアップと復元に関連するすべての前提条件、特に Data Protection Application (DPA) の前提条件については、このガイドの関連セクションで説明されています。
手順
お使いのプラットフォーム別の手順に加えて、次のステップを実行します。
- リソースを別のクラスターに復元するには、Backup Store Location (BSL) と Volume Snapshot Location の名前とパスが同じであることを確認します。
- 同じオブジェクトストレージの場所の認証情報をクラスター全体で共有します。
- 最良の結果を得るには、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.13.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
フィールドに値が設定されている場合に有効にされます。
手順
コントロールプレーンノードの root としてデバッグセッションを開始します。
$ oc debug --as-root node/<node_name>
デバッグシェルで root ディレクトリーを
/host
に変更します。sh-4.4# chroot /host
クラスター全体のプロキシーが有効になっている場合は、次のコマンドを実行して、
NO_PROXY
、HTTP_PROXY
、およびHTTPS_PROXY
環境変数をエクスポートします。$ export HTTP_PROXY=http://<your_proxy.example.com>:8080
$ export HTTPS_PROXY=https://<your_proxy.example.com>:8080
$ export NO_PROXY=<example.com>
デバッグシェルで
cluster-backup.sh
スクリプトを実行し、バックアップの保存先となる場所を渡します。ヒントcluster-backup.sh
スクリプトは etcd Cluster Operator のコンポーネントとして維持され、etcdctl snapshot save
コマンドに関連するラッパーです。sh-4.4# /usr/local/bin/cluster-backup.sh /home/core/assets/backup
スクリプトの出力例
found latest kube-apiserver: /etc/kubernetes/static-pod-resources/kube-apiserver-pod-6 found latest kube-controller-manager: /etc/kubernetes/static-pod-resources/kube-controller-manager-pod-7 found latest kube-scheduler: /etc/kubernetes/static-pod-resources/kube-scheduler-pod-6 found latest etcd: /etc/kubernetes/static-pod-resources/etcd-pod-3 ede95fe6b88b87ba86a03c15e669fb4aa5bf0991c180d3c6895ce72eaade54a1 etcdctl version: 3.4.14 API version: 3.4 {"level":"info","ts":1624647639.0188997,"caller":"snapshot/v3_snapshot.go:119","msg":"created temporary db file","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db.part"} {"level":"info","ts":"2021-06-25T19:00:39.030Z","caller":"clientv3/maintenance.go:200","msg":"opened snapshot stream; downloading"} {"level":"info","ts":1624647639.0301006,"caller":"snapshot/v3_snapshot.go:127","msg":"fetching snapshot","endpoint":"https://10.0.0.5:2379"} {"level":"info","ts":"2021-06-25T19:00:40.215Z","caller":"clientv3/maintenance.go:208","msg":"completed snapshot read; closing"} {"level":"info","ts":1624647640.6032252,"caller":"snapshot/v3_snapshot.go:142","msg":"fetched snapshot","endpoint":"https://10.0.0.5:2379","size":"114 MB","took":1.584090459} {"level":"info","ts":1624647640.6047094,"caller":"snapshot/v3_snapshot.go:152","msg":"saved","path":"/home/core/assets/backup/snapshot_2021-06-25_190035.db"} Snapshot saved at /home/core/assets/backup/snapshot_2021-06-25_190035.db {"hash":3866667823,"revision":31407,"totalKey":12828,"totalSize":114446336} snapshot db and kube resources are successfully saved to /home/core/assets/backup
この例では、コントロールプレーンホストの
/home/core/assets/backup/
ディレクトリーにファイルが 2 つ作成されます。-
snapshot_<datetimestamp>.db
: このファイルは etcd スナップショットです。cluster-backup.sh
スクリプトで、その有効性を確認します。 static_kuberesources_<datetimestamp>.tar.gz
: このファイルには、静的 Pod のリソースが含まれます。etcd 暗号化が有効にされている場合、etcd スナップショットの暗号化キーも含まれます。注記etcd 暗号化が有効にされている場合、セキュリティー上の理由から、この 2 つ目のファイルを etcd スナップショットとは別に保存することが推奨されます。ただし、このファイルは etcd スナップショットから復元するために必要になります。
etcd 暗号化はキーではなく値のみを暗号化することに注意してください。つまり、リソースタイプ、namespace、およびオブジェクト名は暗号化されません。
-
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.internal
etcd メンバーが正常ではないことを示しています。
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 | +------------------+---------+------------------------------+---------------------------+---------------------------+
これでノードシェルを終了できます。
次のコマンドを入力して、クォーラムガードをオフにします。
$ oc patch etcd/cluster --type=merge -p '{"spec": {"unsupportedConfigOverrides": {"useUnsupportedUnsafeNonHANonProductionUnstableEtcd": true}}}'
このコマンドにより、シークレットを正常に再作成し、静的 Pod をロールアウトできるようになります。
重要クォーラムガードをオフにすると、設定の変更を反映するために残りの etcd インスタンスが再起動するまで、短時間クラスターにアクセスできなくなる可能性があります。
注記etcd は、2 つのメンバーで実行されている場合、新たなメンバー障害を許容できません。残りのメンバーのいずれかを再起動すると、クォーラムが破棄され、クラスターでダウンタイムが発生します。クォーラムガードによって、ダウンタイムを引き起こす可能性のある設定変更による再起動から etcd が保護されるため、この手順を完了するには、クォーラムガードを無効にする必要があります。
次のコマンドを実行して、影響を受けるノードを削除します。
$ oc delete node <node_name>
コマンドの例
$ oc delete node ip-10-0-131-183.ec2.internal
削除された正常でない 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 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-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 | +------------------+---------+--------------------+---------------------------+---------------------------+-------------------------+ | cc3830a72fc357f9 | 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
正常でないメンバーのマシンを取得します。
クラスターにアクセスできるターミナルで、
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
)。
以下のコマンドを実行して、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
新しいマシンが作成されたことを確認します。
$ 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 バックアッププロセス とは異なります。
Hosted Control Plane は、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、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 -v /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 -v /etc/kubernetes/manifests/kube-apiserver-pod.yaml /tmp
Kubernetes API サーバー Pod が停止していることを確認します。
$ sudo crictl ps | grep kube-apiserver | egrep -v "operator|guard"
コマンドの出力は空であるはずです。空でない場合は、数分待機してから再度確認します。
etcd データディレクトリーを別の場所に移動します。
$ sudo mv -v /var/lib/etcd/ /tmp
/etc/kubernetes/manifests/keepalived.yaml
ファイルが存在し、ノードが削除された場合は、次の手順に従います。/etc/kubernetes/manifests/keepalived.yaml
ファイルを kubelet マニフェストディレクトリーから移動します。$ sudo mv -v /etc/kubernetes/manifests/keepalived.yaml /tmp
keepalived
デーモンによって管理されているコンテナーが停止していることを確認します。$ sudo crictl ps --name keepalived
コマンドの出力は空であるはずです。空でない場合は、数分待機してから再度確認します。
コントロールプレーンに仮想 IP (VIP) が割り当てられているかどうかを確認します。
$ ip -o address | egrep '<api_vip>|<ingress_vip>'
報告された仮想 IP ごとに、次のコマンドを実行して仮想 IP を削除します。
$ sudo ip address del <reported_vip> dev <reported_vip_device>
- リカバリーホストではない他のコントロールプレーンホストでこの手順を繰り返します。
- リカバリーコントロールプレーンホストにアクセスします。
keepalived
デーモンが使用されている場合は、リカバリーコントロールプレーンノードが仮想 IP を所有していることを確認します。$ ip -o address | grep <api_vip>
仮想 IP のアドレスが存在する場合、出力内で強調表示されます。仮想 IP が設定されていないか、正しく設定されていない場合、このコマンドは空の文字列を返します。
クラスター全体のプロキシーが有効になっている場合は、
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/assets/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-bootstrapper
CSR を承認します。$ 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 分以上かかる場合があります。
OVN-Kubernetes ネットワークプラグインを使用している場合は、すべてのホストで 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-node
Pod を削除します。$ 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-node
Pod が再度デプロイされ、Running
状態になっていることを確認します。$ oc get pods -n openshift-ovn-kubernetes | grep ovnkube-node
他の非復旧のコントロールプレーンマシンを 1 つずつ削除して再作成します。マシンが再作成された後、新しいリビジョンが強制され、etcd が自動的にスケールアップします。
ユーザーがプロビジョニングしたベアメタルインストールを使用する場合は、最初に作成したときと同じ方法を使用して、コントロールプレーンマシンを再作成できます。詳細は、「ユーザーによってプロビジョニングされるクラスターのベアメタルへのインストール」を参照してください。
警告リカバリーホストのマシンを削除し、再作成しないでください。
installer-provisioned infrastructure を実行している場合、またはマシン API を使用してマシンを作成している場合は、以下の手順を実行します。
警告リカバリーホストのマシンを削除し、再作成しないでください。
installer-provisioned infrastructure でのベアメタルインストールの場合、コントロールプレーンマシンは再作成されません。詳細は、「ベアメタルコントロールプレーンノードの交換」を参照してください。
失われたコントロールプレーンホストのいずれかのマシンを取得します。
クラスターにアクセスできるターミナルで、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 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-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-bootstrapper
CSR を承認します。$ oc adm certificate approve <csr_name>
ユーザーによってプロビジョニングされるインストールの場合は、それぞれの有効な kubelet 提供の CSR を承認します。
$ oc adm certificate approve <csr_name>
5.4.4. AWS リージョン内のホストされたクラスターの障害復旧
ホストされたクラスターの障害復旧 (DR) が必要な状況では、ホストされたクラスターを AWS 内の同じリージョンに回復できます。たとえば、管理クラスターのアップグレードが失敗し、ホストされているクラスターが読み取り専用状態になっている場合、DR が必要です。
Hosted Control Plane は、テクノロジープレビュー機能としてのみ利用できます。テクノロジープレビュー機能は、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 リージョン
- ベースドメイン: 外部 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-operator
$ PAUSED_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 done
etcd のバックアップの詳細は、「ホストされたクラスターでの 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
およびControlPlane
HC 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 のリポジトリーで管理されています。
Legal Notice
Copyright © 2024 Red Hat, Inc.
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.