1.6. バックアップおよびリストア Operator の管理
クラスターのバックアップおよび復元 Operator は自動的にインストールされません。MultiClusterHub リソースで cluster-backup パラメーターを true に設定して、バックアップコンポーネントを有効にします。有効にすると、クラスターのバックアップと復元のオペレーターが open-cluster-management-backup namespace にインストールされます。クラスターバックアップオペレーターをインストールすると、クラスターバックアップおよび復元オペレーターと同じ namespace に OADP Operator も自動的にインストールされます。
注記:
-
OADP Operator 1.0 はマルチアーキテクチャービルドをサポートしなくなり、公式リリース用に x86_64 ビルドのみを生成します。その結果、
x86_64以外のアーキテクチャーを使用している場合は、バックアップコンポーネントでインストールされた OADP Operator を正しいバージョンに置き換える必要があります。バージョンを置き換えるには、OADP Operator をアンインストールし、アーキテクチャーに一致するオペレーターを見つけてからインストールします。 -
以前に OADP Operator をハブクラスターにインストールして使用していた場合は、バックアップコンポーネントの namespace とは異なる namespace で、このバージョンをアンインストールしてください。これは、バックアップコンポーネントが、コンポーネントの namespace にインストールされた OADP で動作するようになったためです。バックアップコンポーネントでインストールされた OADP Operator が所有する
DataProtectionApplicationリソースと同じストレージの場所を使用します。これは、前回の Operator と同じバックアップデータにアクセスします。Velero バックアップリソースが、このハブクラスターの新しい OADP Operator namespace 内に読み込まれるようになりました。
Velero は、Red Hat Advanced Cluster Management ハブクラスターの OADP Operator と共にインストールされます。Velero は、Red Hat Advanced Cluster Management ハブクラスターリソースのバックアップおよび復元に使用されます。
Velero のサポートされるストレージプロバイダーの一覧は、S3-Compatible オブジェクトストアプロバイダー を参照してください。
1.6.1. 前提条件 リンクのコピーリンクがクリップボードにコピーされました!
バックアップおよび復元 operator を有効にして使用するには、次の前提条件を満たしている必要があります。
- バックアップの保存先となるクラウドストレージの 認証情報シークレットの作成 手順を必ず実行します。シークレットリソースは、バックアップコンポーネントの namespace にある OADP Operator の namespace に作成する必要があります。
アクティブ/パッシブハブクラスターの両方の場合:
-
Red Hat OpenShift Container Platform クラスターから、Red Hat Advanced Cluster Management for Kubernetes Operator バージョン 2.6.x をインストールします。
MultiClusterHubリソースは、Red Hat Advanced Cluster Management のインストール時に自動的に作成され、Runningのステータスを表示します。 -
クラスターのバックアップおよび復元 Operator は手動でインストールする必要があります。クラスターのバックアップおよび復元 Operator (
cluster-backup) を有効にします。cluster-backupパラメーターをtrueに設定してMultiClusterHubリソースを編集します。これにより、バックアップコンポーネントと同じネームスペースに OADP オペレータがインストールされます。
-
Red Hat OpenShift Container Platform クラスターから、Red Hat Advanced Cluster Management for Kubernetes Operator バージョン 2.6.x をインストールします。
パッシブハブクラスターの場合:
- パッシブハブクラスターで復元操作を実行する前に、ハブクラスターを手動で設定し、すべての Operator をアクティブなハブクラスターと同じ namespace にインストールする必要があります。
-
Red Hat Advanced Cluster Management Operator が、初期ハブクラスターと同じ namespace にインストールされていることを確認します。次に
DataProtectionApplicationリソースを作成し、初期ハブクラスターがデータをバックアップしたのと同じストレージの場所に接続します。
DataProtectionAppliationリソースの作成時に作成したシークレットを使用します。以下の手順を実行して、
DataProtectionApplicationリソースのインスタンスを作成します。- Red Hat OpenShift Container Platform コンソールから、Operators > Installed Operators を選択します。
-
DataProtectionApplication の下の
Create instanceをクリックします。 -
{ocp-short) コンソールを使用して設定を選択するか、
DataProtectionApplicationの例で説明されているように YAML ファイルを使用して、Velero インスタンスを作成します。 -
DataProtectionApplicationnamespaceをopen-cluster-management-backupに設定します。 DataProtectionApplicationリソースの仕様 (spec:) 値を適切に設定します。次に、Create をクリックします。デフォルトのバックアップストレージの場所を使用する場合は、
backupStorageLocationsセクションで値default: trueを設定します。以下のDataProtectionApplicationリソースの例を確認します。apiVersion: oadp.openshift.io/v1alpha1 kind: DataProtectionApplication metadata: name: dpa-sample spec: configuration: velero: defaultPlugins: - openshift - aws restic: enable: true backupLocations: - name: default velero: provider: aws default: true objectStorage: bucket: my-bucket prefix: my-prefix config: region: us-east-1 profile: "default" credential: name: cloud-credentials key: cloud snapshotLocations: - name: default velero: provider: aws config: region: us-west-2 profile: "default"DataProtectionApplicationリソース を作成する例を参照してください。
- 復元操作を実行する前に、Ansible Automation Platform、Red Hat OpenShift Container Platform GitOps、または証明書マネージャーなどの他の Operator がインストールされていることを確認します。これにより、新しいハブクラスターが初期のハブクラスターと同じように設定されます。
- パッシブハブクラスターは、バックアップと復元 Operator、および前のハブクラスターで設定された他の Operator をインストールするときに、最初のハブクラスターと同じ namespace 名を使用する必要があります。
1.6.2. バックアップおよびリストア Operator の有効化 リンクのコピーリンクがクリップボードにコピーされました!
クラスターのバックアップおよび復元 Operator は、MultiClusterHub リソースの初回作成時に有効にできます。cluster-backup パラメーターは true に設定します。Operator を有効にすると、Operator リソースがインストールされます。
MultiClusterHub リソースがすでに作成されている場合には、MultiClusterHub リソースを編集して、クラスターバックアップ Operator をインストールまたはアンインストールできます。クラスターバックアップ Operator をアンインストールする場合は、cluster-backup を false に設定します。
バックアップおよび復元 Operator が有効にされている場合には、MultiClusterHub リソースは以下の YAML ファイルのようになります。
apiVersion: operator.open-cluster-management.io/v1
kind: MultiClusterHub
metadata:
name: multiclusterhub
namespace: open-cluster-management
spec:
availabilityConfig: High
enableClusterBackup: false
imagePullSecret: multiclusterhub-operator-pull-secret
ingress:
sslCiphers:
- ECDHE-ECDSA-AES256-GCM-SHA384
- ECDHE-RSA-AES256-GCM-SHA384
- ECDHE-ECDSA-AES128-GCM-SHA256
- ECDHE-RSA-AES128-GCM-SHA256
overrides:
components:
- enabled: true
name: multiclusterhub-repo
- enabled: true
name: search
- enabled: true
name: management-ingress
- enabled: true
name: console
- enabled: true
name: insights
- enabled: true
name: grc
- enabled: true
name: cluster-lifecycle
- enabled: true
name: volsync
- enabled: true
name: multicluster-engine
- enabled: true <<<<<<<<
name: cluster-backup
separateCertificateManagement: false
1.6.3. バックアップおよびリストア Operator の使用 リンクのコピーリンクがクリップボードにコピーされました!
バックアップをスケジュールおよび復元するには、以下の手順を実行します。
-
バックアップおよび復元 Operator
backupschedule.cluster.open-cluster-management.ioを使用してバックアップスケジュールを作成し、restore.cluster.open-cluster-management.ioリソースを使用してバックアップを復元します。 次のコマンドを実行して、
backupschedule.cluster.open-cluster-management.ioリソースを作成します。kubectl create -f cluster_v1beta1_backupschedule.yamlcluster_v1beta1_backupschedule.yamlリソースは、次のファイルのようになる場合があります。apiVersion: cluster.open-cluster-management.io/v1beta1 kind: BackupSchedule metadata: name: schedule-acm namespace: open-cluster-management-backup spec: veleroSchedule: 0 */2 * * * # Create a backup every 2 hours veleroTtl: 120h # deletes scheduled backups after 120h; optional, if not specified, the maximum default value set by velero is used - 720hbackupschedule.cluster.open-cluster-management.iospecプロパティーに関する以下の説明を確認してください。-
veleroScheduleは必須のプロパティーで、バックアップをスケジュールする cron ジョブを定義します。 -
veleroTtlは任意のプロパティーで、スケジュールされているバックアップリソースの有効期限を定義します。指定されていない場合には、Velero で設定された最大デフォルト値 (720h) が使用されます。
-
backupschedule.cluster.open-cluster-management.ioリソースの状態をチェックします。3 つのschedule.velero.ioリソースの定義が表示されます。以下のコマンドを実行します。oc get BackupSchedule -n open-cluster-management-backup注意: 復元操作は、復元シナリオ向けに別のハブクラスターで実行します。復元操作を開始するには、バックアップを復元するハブクラスターに
restore.cluster.open-cluster-management.ioリソースを作成します。注意: 新しいハブクラスターにバックアップを復元する場合には、バックアップを作成した、前のバブクラスターがシャットダウンされていることを確認します。実行中の場合には、前のハブクラスターは、マネージドクラスターの調整機能により、マネージドクラスターが使用できなくなったことが検出されるとすぐに、マネージドクラスターの再インポートが試行されます。
クラスターのバックアップおよび復元 Operator、backup
schedule.cluster.open-cluster-management.ioおよびrestore.cluster.open-cluster-management.ioリソースを使用して、バックアップまたは復元リソースを作成できます。cluster-backup-operatorサンプル を参照してください。次のコマンドを実行して、
restore.cluster.open-cluster-management.ioリソースを作成します。kubectl create -f cluster_v1beta1_backupschedule.yamlリソースは以下のファイルのようになります。
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Restore metadata: name: restore-acm namespace: open-cluster-management-backup spec: veleroManagedClustersBackupName: latest veleroCredentialsBackupName: latest veleroResourcesBackupName: latest以下のコマンドを実行して Velero
Restoreリソースを表示します。oc get restore.velero.io -n open-cluster-management-backup次のコマンドを実行して、Red Hat Advanced Cluster Management
Restoreイベントを表示します。oc describe restore.cluster.open-cluster-management.io -n open-cluster-management-backup
Restore YAML リソースのパラメーターとサンプルの説明については、Restoring a backup セクションを参照してください。
1.6.4. Extending backup data リンクのコピーリンクがクリップボードにコピーされました!
cluster.open-cluster-management.io/backup ラベルをリソースに追加することで、クラスターのバックアップおよび復元を使用してサードパーティーのリソースをバックアップできます。ラベルの値は、空の文字列を含む任意の文字列にすることができます。バックアップするコンポーネントを識別するのに役立つ値を使用してください。たとえば、コンポーネントが IDP ソリューションによって提供される場合は、cluster.open-cluster-management.io/backup: idp ラベルを使用します。
注意: マネージドクラスターのアクティブ化リソースが復元されたときにリソースを復元する場合は、cluster.open-cluster-management.io/backup ラベルに cluster-activation 値を使用します。マネージドクラスターのアクティブ化リソースを復元すると、マネージドクラスターは、復元が開始されたハブクラスターによってアクティブに管理されます。
1.6.5. Scheduling a cluster backup リンクのコピーリンクがクリップボードにコピーされました!
backupschedule.cluster.open-cluster-management.io リソースを作成すると、バックアップスケジュールが有効になります。以下の backupschedule.cluster.open-cluster-management.io サンプルを表示します。
apiVersion: cluster.open-cluster-management.io/v1beta1
kind: BackupSchedule
metadata:
name: schedule-acm
namespace: open-cluster-management-backup
spec:
veleroSchedule: 0 */2 * * *
veleroTtl: 120h
backupschedule.cluster.open-cluster-management.io リソースを作成したら、以下のコマンドを実行してスケジュールされたクラスターバックアップのステータスを取得します。
oc get BackupSchedule -n open-cluster-management-backup
1 つ前のコマンドの <oadp-operator-ns> パラメーターは、BackupSchedule が作成される namespace で、OADP Operator がインストールされている namespace と同じです。backupschedule.cluster.open-cluster-management.io リソースは、バックアップの生成に使用される schedule.velero.io リソースを 6 つ作成します。以下のコマンドを実行して、スケジュールされるバックアップの一覧を表示します。
os get schedules -A | grep acm
リソースは、以下のグループで個別にバックアップされます。
- Credentials backup は、Hive 認証情報、Red Hat Advanced Cluster Management、およびユーザー作成の認証情報と ConfigMap を保存するバックアップファイルです。
-
リソースバックアップ: Red Hat Advanced Cluster Management リソースのバックアップと汎用リソース用のバックアップが含まれています。これらのリソースは、
cluster.open-cluster-management.io/backupというラベルを使用します。 - マネージドクラスターのバックアップ。これには、バックアップが復元されるハブクラスターへのマネージドクラスター接続をアクティブにするリソースのみが含まれます。
注記: リソースバックアップ ファイルには、マネージドクラスター固有のリソースが含まれますが、マネージドクラスターをハブクラスターに接続するリソースのサブセットは含まれません。マネージドクラスターを接続するリソースは、アクティベーションリソースと呼ばれ、マネージドクラスターのバックアップに含まれます。新しいハブクラスターで 認証情報 および リソース のバックアップのみのバックアップを復元すると、新しいハブクラスターには、Hive API で作成されたすべてのマネージドクラスターが切り離された状態で表示されます。ただし、インポート操作を使用してプライマリーハブクラスターにインポートされたマネージドクラスターは、アクティベーションデータがパッシブハブクラスターに復元された場合にのみ表示されます。この時点で、マネージドクラスターは、バックアップファイルを作成した元のハブクラスターに引き続き接続されます。
アクティベーションデータが復元されると、Hive API を使用して作成されたマネージドクラスターのみが新しいハブクラスターに自動的に接続されます。他のすべてのマネージドクラスターは 保留 状態で表示されるため、新しいクラスターに手動で再接続する必要があります。
1.6.6. バックアップの復元 リンクのコピーリンクがクリップボードにコピーされました!
一般的な復元のシナリオでは、バックアップが実行されるハブクラスターが利用できなくなり、バックアップデータを新しいハブクラスターに移動する必要があります。これには、新しいハブクラスターでクラスター復元操作を実行します。この場合、復元操作はバックアップが作成される場所とは異なるハブクラスターで実行します。
また、以前のスナップショットからのデータを復元できるように、バックアップデータを取得したハブクラスターでデータを復元するケースもあります。この場合、復元とバックアップ操作の両方が同じハブクラスターで実行されます。
ハブクラスターで restore.cluster.open-cluster-management.io リソースを作成した後に、oc get restore -n open-cluster-management-backup のコマンドを実行して復元操作のステータスを取得できます。また、バックアップファイルに含まれるバックアップのリソースが作成されていることを確認できる必要があります。
注記: Restore passive resources セクションで説明されているように、syncRestoreWithNewBackups オプションを使用して true に設定しない限り、restore.cluster.open-cluster-management.io リソースは 1 回実行されます。復元操作の完了後に同じ復元操作を再度実行する場合は、同じ spec オプションで新しい restore.cluster.open-cluster-management.io リソースを作成する必要があります。
復元操作を使用して、バックアップ操作で作成される全バックアップタイプ 3 つを復元します。ただし、特定の種類のバックアップ (マネージドクラスターのみ、ユーザー資格情報のみ、またはハブクラスターリソースのみ) のみをインストールするように選択できます。
復元では、以下の 3 つの必要な spec プロパティーを定義します。ここでは、バックアップしたファイルのタイプに対して復元ロジックが定義されます。
-
veleroManagedClustersBackupNameは、マネージドクラスターのアクティベーションリソースの復元オプションを定義するのに使用されます。 -
veleroCredentialsBackupNameは、ユーザーの認証情報の復元オプションを定義するために使用されます。 veleroResourcesBackupNameは、ハブクラスターリソース (Applications、Policy、その他のハブクラスターリソース (マネージドクラスターパッシブデータなど)) の復元オプションを定義するのに使用されます。前述のプロパティーの有効な値は次のとおりです。
-
latest: このプロパティーは、このタイプのバックアップで使用可能な、最後のバックアップファイルを復元します。 -
skip:このプロパティーは、現在の復元操作でこのタイプのバックアップの復元は試行ません。 -
<backup_name>: このプロパティーは、名前で参照する指定のバックアップを復元します。
-
restore.cluster.open-cluster-management.io で作成された restore.velero.io リソースの名前は、<restore.cluster.open-cluster-management.io name>-<velero-backup-resource-name> のテンプレートルールを使用して生成されます。以下の説明を参照してください。
-
restore.cluster.open-cluster-management.ioは、復元を開始する現在のrestore.cluster.open-cluster-management.ioリソースの名前です。 Velero-backup-resource-nameは、データの復元に使用される Velero バックアップファイルの名前です。たとえば、restore.cluster.open-cluster-management.ioリソースrestore-acmはrestore.velero.io復元リソースを作成します。フォーマットについては、以下の例を参照してください。-
restore-acm-acm-managed-clusters-schedule-20210902205438は、マネージドクラスターのアクティベーションデータのバックアップを復元するのに使用されます。このサンプルでは、リソースの復元に使用されるbackup.velero.ioバックアップ名はacm-managed-clusters-schedule-20210902205438です。 -
restore-acm-acm-credentials-schedule-20210902206789は、認証情報バックアップの復元に使用されます。このサンプルでは、リソースの復元に使用されるbackup.velero.ioバックアップ名はacm-managed-clusters-schedule-20210902206789です。 -
restore-acm-acm-resources-schedule-20210902201234は、アプリケーション、ポリシー、およびマネージドクラスターパッシブデータバックアップなどの他のハブクラスターリソースを復元するのに使用されます。このサンプルでは、リソースの復元に使用されるbackup.velero.ioバックアップ名はacm-managed-clusters-schedule-20210902201234です。
-
注記: skip がバックアップタイプに使用されている場合は、restore.velero.io は作成されません。
以下の YAML サンプルで、クラスターの リストア リソースを参照してください。この例では、利用可能な最新のバックアップファイルを使用して、3 つのタイプのバックアップファイルがすべて復元されています。
apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
name: restore-acm
namespace: open-cluster-management-backup
spec:
veleroManagedClustersBackupName: latest
veleroCredentialsBackupName: latest
veleroResourcesBackupName: latest
注記 Hive API によって作成されたマネージドクラスターのみが、マネージドクラスターのバックアップからの acm-managed-clusters バックアップが別のハブクラスターに復元されるときに、新しいハブクラスターに自動的に接続されます。他のすべてのマネージドクラスターは Pending Import 状態のままであり、新しいハブクラスターにインポートし直す必要があります。詳細は、Restoring imported managed clusters (Technology Preview) を参照してください。
1.6.6.1. Preparing the new hub cluster リンクのコピーリンクがクリップボードにコピーされました!
新しいハブクラスターで復元操作を実行する前に、ハブクラスターを手動で設定し、初期ハブクラスターと同じ Operator をインストールする必要があります。Red Hat Advanced Cluster Management Operator は、初期ハブクラスターと同じ namespace にインストールし、DataProtectionApplication リソースを作成してから、初期ハブクラスターがデータをバックアップしたのと同じストレージの場所に接続する必要があります。
MultiClusterEngine リソースへの変更を含め、Red Hat Advanced Cluster Management オペレーターによって作成された MultiClusterHub リソースの最初のハブクラスターと同じ設定を使用します。
たとえば、初期ハブクラスターに Ansible Automation Platform、Red Hat OpenShift GitOps、cert-manager などの他の Operator がインストールされている場合は、復元操作を実行する前にそれらをインストールする必要があります。これにより、新しいハブクラスターが初期のハブクラスターと同じ方法で設定されます。
1.6.6.2. 復元前のハブクラスターのクリーニング リンクのコピーリンクがクリップボードにコピーされました!
Velero は現在、ハブクラスターの既存のバックアップリソースを省略します。これにより、新しいハブクラスターでハブクラスターデータを復元する時に使用可能なシナリオが制限されます。新しいハブクラスターが使用され、復元が複数回適用される場合は、復元が実行する前にデータがクリーンアップされない限り、ハブクラスターをパッシブ設定として使用することは推奨されません。新しいハブクラスターのデータは、復元されたリソースで利用可能なデータを反映していません。
restore.cluster.open-cluster-management.io リソースが作成されると、クラスターのバックアップおよび復元 Operator は一連の手順を実行し、Velero 復元を開始する前にハブクラスターを消去して復元の準備を行います。
cleanup オプションは cleanupBeforeRestore プロパティーを使用して、クリーンアップするオブジェクトのサブセットを特定します。このクリーンアップには、以下の 3 つのオプションを設定できます。
-
None: クリーンアップは必要なく、Velero の復元を開始するだけです。これは、新しいハブクラスターで使用されます。 -
CleanupRestored: 以前の Red Hat Advanced Cluster Management の復元で作成されたすべてのリソースを消去します。このプロパティーは、CleanupAllプロパティーよりも影響範囲が少ないので、こちらを使用することが推奨されます。 -
CleanupAll: 復元操作を実行してからリソースが作成されていなくても、Red Hat Advanced Cluster Management バックアップとして含まれている可能性のある、ハブクラスター上の全リソースを消去します。これは、ハブクラスターに追加のコンテンツが作成された場合にクリーンアップが必要となるため、使用されます。このオプションは、以前のバックアップではなく、ユーザーによって作成されたハブクラスター上のリソースを消去するため、このオプションは注意して使用してください。CleanupRestoredオプションを使用し、ハブクラスターが災害シナリオのパッシブクラスターとして指定されている場合は、ハブクラスターのコンテンツを手動で更新しないことを強くお勧めします。最終的な選択肢として、CleanupAllオプションを使用するようにしてください。
注記:
-
Velero は、復元されたバックアップにリソースがない場合に、velero 復元リソースのステータス
PartiallyFailedを設定します。これは、対応するバックアップが空であるために作成されたrestore.velero.ioリソースのいずれかによりリソースが復元されない場合には、restore.cluster.open-cluster-management.ioリソースがPartiallyFailedステータスになる可能性があることを意味します。 -
syncRestoreWithNewBackups:trueを使用して新規バックアップが利用可能な場合にパッシブデータの復元を継続しない限り、restore.cluster.open-cluster-management.ioリソースは 1 回実行されます。この場合、同期サンプルで復元パッシブに従います。Restoring passive resources while checking for backups を参照してください。復元操作が完了し、同じハブクラスターで別の復元操作を実行する場合は、新しいrestore.cluster.open-cluster-management.ioリソースを作成する必要があります。 -
複数の
restore.cluster.open-cluster-management.ioリソースを作成できますが、いつでもアクティブにできるのは 1 つだけです。
1.6.6.3. Restoring passive resources while checking for backups リンクのコピーリンクがクリップボードにコピーされました!
新しいバックアップが利用可能かどうかを引き続き確認し、それらを自動的に復元しながら、restore-passive-sync サンプルを使用してパッシブデータを復元します。新しいバックアップを自動的に復元するには、syncRestoreWithNewBackups パラメーターを true に設定する必要があります。また、最新のパッシブデータだけを復元する必要もあります。サンプルの例は、このセクションの最後にあります。
VeleroResourcesBackupName および VeleroCredentialsBackupName パラメーターを latest に設定し、VeleroManagedClustersBackupName パラメーターを省略して スキップ します。VeleroManagedClustersBackupName が latest に設定された直後に、マネージドクラスターは新しいハブクラスターでアクティベートされ、プライマリーハブクラスターになります。
アクティベートされたマネージドクラスターがプライマリーハブクラスターになると、復元リソースが Finished に設定され、true に設定されていても syncRestoreWithNewBackups は無視されます。
デフォルトでは、コントローラーは syncRestoreWithNewBackups が true に設定されると、30 分ごとに新規バックアップをチェックします。新しいバックアップが見つかった場合は、バックアップされたリソースを復元します。restoreSyncInterval パラメーターを更新してチェックの期間を変更できます。
たとえば、10 分ごとにバックアップをチェックする次のリソースを参照してください。
apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
name: restore-acm-passive-sync
namespace: open-cluster-management-backup
spec:
syncRestoreWithNewBackups: true # restore again when new backups are available
restoreSyncInterval: 10m # check for new backups every 10 minutes
cleanupBeforeRestore: CleanupRestored
veleroManagedClustersBackupName: skip
veleroCredentialsBackupName: latest
veleroResourcesBackupName: latest
1.6.6.4. Restoring passive resources リンクのコピーリンクがクリップボードにコピーされました!
パッシブ設定でハブクラスターリソースを復元するには、restore-acm-passive サンプルを使用します。パッシブデータは、シークレット、ConfigMap、アプリケーション、ポリシー、およびすべてのマネージドクラスターカスタムリソースなどのバックアップデータで、マネージドクラスターとハブクラスター間の接続をアクティブ化しません。バックアップリソースは、認証情報のバックアップおよび復元リソースによりハブクラスターで復元されます。
以下のサンプルを参照してください。
apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
name: restore-acm-passive
namespace: open-cluster-management-backup
spec:
cleanupBeforeRestore: CleanupRestored
veleroManagedClustersBackupName: skip
veleroCredentialsBackupName: latest
veleroResourcesBackupName: latest
1.6.6.5. アクティベーションリソースの復元 リンクのコピーリンクがクリップボードにコピーされました!
ハブクラスターでクラスターを管理する場合は、restore-acm-passive-activate サンプルを使用します。この場合、パッシブリソースを使用するハブクラスターで他のデータがすでに復元されていることを前提とします。
apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
name: restore-acm-passive-activate
namespace: open-cluster-management-backup
spec:
cleanupBeforeRestore: CleanupRestored
veleroManagedClustersBackupName: latest
veleroCredentialsBackupName: skip
veleroResourcesBackupName: skip
パッシブリソースを復元した方法に応じて、アクティベーションリソースを復元するいくつかのオプションがあります。
-
Restore passive resources while checking for backups to restore passive data セクションに記載されているように、
restore-acm-passive-sync cluster.open-cluster-management.ioリソースを使用した場合は、このリソースでveleroManagedClustersBackupNameの値をlatestの値に更新します。その結果、マネージドクラスターリソースとrestore-acm-passive-syncリソースが復元されます。 - パッシブリソースを 1 回限りの操作で復元した場合、またはリソースをまだ復元していない場合は、Restoring all resources セクションで指定されているように、すべてのリソースを復元することを選択します。
1.6.6.6. Restoring all resources リンクのコピーリンクがクリップボードにコピーされました!
一度にすべてのデータを復元し、ハブクラスターがマネージドクラスターを 1 つのステップで管理するようにする場合は、restore-acm サンプルを使用します。ハブクラスターに restore.cluster.open-cluster-management.io リソースを作成したら、次のコマンドを実行して復元操作のステータスを取得します。
oc get restore -n open-cluster-management-backup
サンプルは、次のリソースに酷似している可能性があります。
apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
name: restore-acm
namespace: open-cluster-management-backup
spec:
cleanupBeforeRestore: CleanupRestored
veleroManagedClustersBackupName: latest
veleroCredentialsBackupName: latest
veleroResourcesBackupName: latest
ハブクラスターから、バックアップファイルに含まれるバックアップされたリソースが作成されていることを確認します。
1.6.6.7. Restoring imported managed clusters リンクのコピーリンクがクリップボードにコピーされました!
Hive API を使用してプライマリーハブクラスターに接続されたマネージドクラスターのみが、アクティベーションデータが復元される新しいハブクラスターに自動的に接続されます。これらのクラスターは、Clusters タブの Create cluster ボタンを使用して、プライマリーハブクラスター上に作成されています。Import cluster ボタンを使用して最初のハブクラスターに接続されたマネージドクラスターは、アクティベーションデータが復元されると Pending Import として表示され、新しいハブクラスターにインポートし直す必要があります。
Hive がマネージドクラスター kubeconfig をハブクラスターのマネージドクラスター namespace に格納するため、Hive マネージドクラスターを新しいハブクラスターに接続できます。これは、新しいハブクラスターでバックアップおよび復元されます。次に、インポートコントローラーは、復元された設定を使用してマネージドクラスターのブートストラップ kubeconfig を更新します。これは、Hive API を使用して作成されたマネージドクラスターでのみ使用できます。インポートされたクラスターでは使用できません。
インポートされたクラスターを新しいハブクラスターに再接続するには、復元操作の開始後に auto-import-secret リソースを手動で作成します。詳細は、Importing the cluster with the auto import secret を参照してください。
Pending Import 状態のクラスターごとに、マネージドクラスターの namespace に auto-import-secret リソースを作成します。インポートコンポーネントが新しいハブクラスターで自動インポートを開始するのに十分な権限を持つ kubeconfig またはトークンを使用します。マネージドクラスターに接続するには、トークンを使用して各マネージドクラスターにアクセスできる必要があります。トークンには、klusterlet ロールバインディングまたは同じアクセス権限を持つロールが必要です。
1.6.6.8. 他の復元サンプルの使用 リンクのコピーリンクがクリップボードにコピーされました!
次の復元セクションを参照して、さまざまな種類のバックアップファイルを復元するための YAML の例を確認してください。
3 種類のバックアップリソースをすべて復元します。
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Restore metadata: name: restore-acm namespace: open-cluster-management-backup spec: veleroManagedClustersBackupSchedule: latest veleroCredentialsBackupSchedule: latest veleroResourcesBackupSchedule: latestマネージドクラスターリソースのみを復元します。
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Restore metadata: name: restore-acm namespace: open-cluster-management-backup spec: veleroManagedClustersBackupName: latest veleroCredentialsBackupName: skip veleroResourcesBackupName: skipacm-managed-clusters-schedule-20210902205438バックアップを使用して、マネージドクラスターのリソースのみを復元します。apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Restore metadata: name: restore-acm namespace: open-cluster-management-backup spec: veleroManagedClustersBackupName: acm-managed-clusters-schedule-20210902205438 veleroCredentialsBackupName: skip veleroResourcesBackupName: skip注記:
-
restore.cluster.open-cluster-management.ioリソースは 1 回実行されます。復元操作が完了したら、オプションで同じハブクラスターで別の復元操作を実行できます。新しい復元操作を実行するには、restore.cluster.open-cluster-management.ioリソースを新規作成する必要があります。 -
複数の
restore.cluster.open-cluster-management.ioを作成できますが、同時に実行できるのは 1 つのみです。
-
1.6.6.9. 復元イベントの表示 リンクのコピーリンクがクリップボードにコピーされました!
以下のコマンドを使用して、復元イベントに関する情報を取得します。
oc describe -n <oadp-n> <restore-name>
イベント一覧は以下の例のようになります。
Spec:
Cleanup Before Restore: CleanupRestored
Restore Sync Interval: 4m
Sync Restore With New Backups: true
Velero Credentials Backup Name: latest
Velero Managed Clusters Backup Name: skip
Velero Resources Backup Name: latest
Status:
Last Message: Velero restores have run to completion, restore will continue to sync with new backups
Phase: Enabled
Velero Credentials Restore Name: example-acm-credentials-schedule-20220406171919
Velero Resources Restore Name: example-acm-resources-schedule-20220406171920
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Prepare to restore: 76m Restore controller Cleaning up resources for backup acm-credentials-hive-schedule-20220406155817
Normal Prepare to restore: 76m Restore controller Cleaning up resources for backup acm-credentials-cluster-schedule-20220406155817
Normal Prepare to restore: 76m Restore controller Cleaning up resources for backup acm-credentials-schedule-20220406155817
Normal Prepare to restore: 76m Restore controller Cleaning up resources for backup acm-resources-generic-schedule-20220406155817
Normal Prepare to restore: 76m Restore controller Cleaning up resources for backup acm-resources-schedule-20220406155817
Normal Velero restore created: 74m Restore controller example-acm-credentials-schedule-20220406155817
Normal Velero restore created: 74m Restore controller example-acm-resources-generic-schedule-20220406155817
Normal Velero restore created: 74m Restore controller example-acm-resources-schedule-20220406155817
Normal Velero restore created: 74m Restore controller example-acm-credentials-cluster-schedule-20220406155817
Normal Velero restore created: 74m Restore controller example-acm-credentials-hive-schedule-20220406155817
Normal Prepare to restore: 64m Restore controller Cleaning up resources for backup acm-resources-schedule-20220406165328
Normal Prepare to restore: 62m Restore controller Cleaning up resources for backup acm-credentials-hive-schedule-20220406165328
Normal Prepare to restore: 62m Restore controller Cleaning up resources for backup acm-credentials-cluster-schedule-20220406165328
Normal Prepare to restore: 62m Restore controller Cleaning up resources for backup acm-credentials-schedule-20220406165328
Normal Prepare to restore: 62m Restore controller Cleaning up resources for backup acm-resources-generic-schedule-20220406165328
Normal Velero restore created: 61m Restore controller example-acm-credentials-cluster-schedule-20220406165328
Normal Velero restore created: 61m Restore controller example-acm-credentials-schedule-20220406165328
Normal Velero restore created: 61m Restore controller example-acm-resources-generic-schedule-20220406165328
Normal Velero restore created: 61m Restore controller example-acm-resources-schedule-20220406165328
Normal Velero restore created: 61m Restore controller example-acm-credentials-hive-schedule-20220406165328
Normal Prepare to restore: 38m Restore controller Cleaning up resources for backup acm-resources-generic-schedule-20220406171920
Normal Prepare to restore: 38m Restore controller Cleaning up resources for backup acm-resources-schedule-20220406171920
Normal Prepare to restore: 36m Restore controller Cleaning up resources for backup acm-credentials-hive-schedule-20220406171919
Normal Prepare to restore: 36m Restore controller Cleaning up resources for backup acm-credentials-cluster-schedule-20220406171919
Normal Prepare to restore: 36m Restore controller Cleaning up resources for backup acm-credentials-schedule-20220406171919
Normal Velero restore created: 36m Restore controller example-acm-credentials-cluster-schedule-20220406171919
Normal Velero restore created: 36m Restore controller example-acm-credentials-schedule-20220406171919
Normal Velero restore created: 36m Restore controller example-acm-resources-generic-schedule-20220406171920
Normal Velero restore created: 36m Restore controller example-acm-resources-schedule-20220406171920
Normal Velero restore created: 36m Restore controller example-acm-credentials-hive-schedule-20220406171919
1.6.6.10. プライマリークラスターのシャットダウン リンクのコピーリンクがクリップボードにコピーされました!
新しいハブクラスターにバックアップを復元する場合には、バックアップを作成した、前のバブクラスターがシャットダウンされていることを確認します。そのクラスターが実行中の場合には、前のハブクラスターは、マネージドクラスターの調整機能により、マネージドクラスターが使用できなくなったことが検出されると、マネージドクラスターの再インポートが試行されます。
1.6.7. バックアップまたは復元設定の検証 リンクのコピーリンクがクリップボードにコピーされました!
クラスターのバックアップおよび復元 Operator の Helm チャート (cluster-backup-chart) は、ハブクラスターに backup-restore-enabled ポリシーをインストールし m バックアップと復元のコンポーネントに関する問題について通知するために使用されます。backup-restore-enabled ポリシーには、以下の制約を確認するテンプレートセットが含まれます。
Pod の検証
以下のテンプレートは、Pod のステータスでバックアップコンポーネントおよび依存関係の有無を確認します。
-
acm-backup-pod-runningテンプレートは、バックアップおよび復元 Operator Pod が実行されているかどうかを確認します。 -
OADP-pod-runningテンプレートは、OADP Operator Pod が実行されているかどうかを確認します。 -
velero-pod-runningテンプレートは Velero Pod が実行されているかどうかを確認します。
-
Data Protection Application の検証
-
data-protection-application-availableテンプレートは、DataProtectioApplicatio.oadp.openshift.ioリソースが作成されるかどうかを確認します。この OADP リソースは Velero 設定をセットアップします。
-
バックアップストレージの検証
-
backup-storage-location-availableテンプレートは、BackupStorageLocation.velero.ioリソースが作成され、ステータス値がAvailableかどうかを確認します。これは、バックアップストレージへの接続が有効であることを意味します。
-
BackupSchedule 競合検証
acm-backup-clusters-collision-reportテンプレートは、BackupSchedule.cluster.open-cluster-management.ioが現在のハブクラスターに存在する場合に、ステータスがBackupCollisionではないことを検証します。これにより、バックアップデータをストレージの場所に書き込むときに、現在のハブクラスターが他のハブクラスターと競合していないことを確認できます。BackupCollision状態の定義については、Backup Collisions セクションを参照してください。
BackupSchedule および復元ステータスの検証
-
acm-backup-phase-validationテンプレートは、BackupSchedule.cluster.open-cluster-management.ioが現在のクラスターに存在する場合に、ステータスがFailedでないこと、または空の状態であることを確認します。これにより、このクラスターがプライマリーハブクラスターであり、バックアップを生成している場合にBackupSchedule.cluster.open-cluster-management.ioステータスが正常であることが保証されます。 -
同じテンプレートは、
Restore.cluster.open-cluster-management.ioが現在のクラスターに存在する場合に、ステータスが失敗でないこと、または空の状態にないことを確認します。これにより、このクラスターがセカンダリーハブクラスターであり、バックアップを復元する場合に、Restore.cluster.open-cluster-management.ioのステータスが正常であることが保証されます。
-
バックアップの存在検証
-
acm-managed-clusters-schedule-backups-availableテンプレートは、BackupStorageLocation.velero.ioで指定された場所でBackup.velero.ioリソースが利用可能かどうかを確認し、バックアップがBackupSchedule.cluster.open-cluster-management.ioリソースによって作成されるかどうかを確認します。これにより、バックアップが少なくとも 1 回実行され、バックアップと復元 Operator が検証されます。
-
完了するためのバックアップ
-
acm-backup-in-progress-reportテンプレートは、Backup.velero.ioリソースがInProgress状態で停止していないか確認します。この検証が追加されるのは、多数のリソースがある場合、バックアップの実行中に velero Pod が再起動し、バックアップが完了せずに進行中のままになるためです。通常のバックアップ中、バックアップリソースは、実行中のどこかの時点で進行中になりますが、停止しているわけではなく、完了まで実行されます。スケジュールの実行中およびバックアップの進行中にacm-backup-in-progress-reportテンプレートが警告を報告するのは正常です。
-
cron ジョブとしてアクティブに実行されるバックアップ
BackupSchedule.cluster.open-cluster-management.ioはアクティブに実行され、ストレージの場所に新しいバックアップを保存します。この検証は、backup-schedule-cron-enabledポリシーテンプレートにより行われます。テンプレートは、ストレージの場所にvelero.io/schedule-name: acm-validation-policy-scheduleラベルの付いたBackup.velero.ioがあることを確認します。acm-validation-policy-scheduleバックアップは、バックアップ cron スケジュールの時刻が設定された後に期限切れになるように設定されています。バックアップを作成するために実行されている cron ジョブがない場合には、古いacm-validation-policy-scheduleバックアップは期限切れになり、新しいバックアップが作成されないので削除されます。したがって、現在acm-validation-policy-schedule backupsが存在しない場合には、アクティブな cron ジョブがバックアップを生成することはありません。このポリシーは、ハブクラスターがアクティブで、バックアップを作成または復元するときに、バックアップの問題をハブクラスター管理者に通知することを目的としています。
1.6.8. サーバー側の暗号化を使用したデータの保護 リンクのコピーリンクがクリップボードにコピーされました!
サーバー側の暗号化は、保存場所でデータを受信するアプリケーションまたはサービスのデータ暗号化です。バックアップメカニズム自体は、転送中 (バックアップストレージの場所との間を移動するとき) または保存中 (バックアップストレージの場所のディスクに保存されている間) にデータを暗号化しません。代わりに、オブジェクトおよびスナップショットシステムのネイティブメカニズムに依存しています。
ベストプラクティス: 使用可能なバックアップストレージのサーバー側の暗号化を使用して、宛先でデータを暗号化します。バックアップには、認証情報や設定ファイルなど、ハブクラスターの外部に保存するときに暗号化する必要があるリソースが含まれています。
serverSideEncryption パラメーターおよび kmsKeyId パラメーターを使用して、Amazon S3 に保存されているバックアップの暗号化を有効にすることができます。詳細は、バックアップストレージの場所 YAML を参照してください。次のサンプルは、DataProtectionApplication リソースを設定するときに AWS KMS キー ID を指定します。
spec:
backupLocations:
- velero:
config:
kmsKeyId: 502b409c-4da1-419f-a16e-eif453b3i49f
profile: default
region: us-east-1
他のストレージプロバイダーの設定可能なすべてのパラメーターについては、Velero がサポートするストレージプロバイダー を参照してください。