ビジネス継続性

クラスターのバックアップと復元 Operator のソリューションは、マネージドクラスター、アプリケーション、ポリシーなど、すべてのハブクラスターリソースのバックアップと復元のサポートを提供します。このソリューションを使用して、基本的なハブクラスターのインストールを拡張するサードパーティーリソースをバックアップします。このバックアップソリューションを使用すると、cron ベースのバックアップスケジュールを定義します。これは、指定された時間間隔で実行し、ハブクラスターのコンテンツの最新バージョンを継続的にバックアップします。

ハブクラスターを交換する必要がある場合、またはハブクラスターに障害が発生したときに障害シナリオにある場合は、新しいハブクラスターをデプロイし、バックアップデータを新しいハブクラスターに移動できます。

次のクラスターのバックアップおよび復元プロセスのリストと、バックアップデータを識別するためにリソースとグループをバックアップまたは除外する方法を確認します。

Red Hat Advanced Cluster Management スケジュールを使用して、リソースタイプまたはラベルアノテーションに基づいて個別のバックアップファイルにグループ化されたハブクラスターリソースをバックアップできます。

BackupSchedule.cluster.open-cluster-management.io リソースは、4 つの schedule.velero.io リソースのセットを作成します。これらの schedule.velero.io リソースは、リソースとも呼ばれるバックアップファイルを生成します。

スケジュールされたバックアップファイルの一覧を表示するには、oc get schedules -A | grep acm のコマンドを実行します。

スケジュールされたバックアップファイルは backup.velero.io です。これらのスケジュールされたバックアップファイルの説明を表示するには、次の表を参照してください。

リソースに cluster.open-cluster-management.io/backup ラベルを追加すると、そのリソースは自動的に acm-resources-generic-schedule バックアップに追加されます。ただし、Secrets および ConfigMap リソースは、backup acm-credentials-schedule- にバックアップされます。マネージドクラスターを新しいハブクラスターに移動した後、および復元されたリソースで veleroManagedClustersBackupName:latest を使用する場合は、ラベル値を cluster-activation に設定します。

cluster.open-cluster-management.io/backup ラベルを cluster-activation に設定すると、マネージドクラスターをアクティブ化しない限り、リソースが復元されないようになります。以下の例を参照してください。

apiVersion: my.group/v1alpha1
kind: MyResource
 metadata:
  labels:
    cluster.open-cluster-management.io/backup: cluster-activation

apiVersion: my.group/v1alpha1
kind: MyResource
 metadata:
  labels:
    cluster.open-cluster-management.io/backup: cluster-activation

注記: マネージドクラスターの namespace またはその namespace 内のリソースは、クラスターのアクティブ化ステップで、どちらかを復元する必要があります。したがって、マネージドクラスターの namespace に作成されたバックアップリソースに追加する必要がある場合は、cluster.open-cluster-management.io/backup ラベルの cluster-activation 値を使用してください。復元プロセスを理解するには、次の情報を参照してください。

cluster.open-cluster-management.io/backup: cluster-activation ラベルを使用して識別され、acm-resources-generic-schedule バックアップによって保存されるアクティベーションデータリソースとは別に、クラスターのバックアップおよび復元 Operator には、デフォルトでは、アクティベーションセット内のいくつかのリソースが含まれます。次のリソースは、acm-managed-clusters-schedule バックアップによってバックアップされます。

cluster.open-cluster-management.io/backup ラベルをリソースに追加することで、クラスターのバックアップおよび復元を使用してサードパーティーのリソースをバックアップできます。ラベルの値は、空の文字列を含む任意の文字列にすることができます。バックアップするコンポーネントを識別するのに役立つ値を使用してください。たとえば、コンポーネントが IDP ソリューションによって提供される場合は、cluster.open-cluster-management.io/backup: idp ラベルを使用します。

注意: マネージドクラスターのアクティブ化リソースが復元されたときにリソースを復元する場合は、cluster.open-cluster-management.io/backup ラベルに cluster-activation 値を使用します。マネージドクラスターのアクティベーションリソースを復元すると、ハブクラスターによってアクティブに管理されているマネージドクラスターの復元が開始されます。

active-passive 設定では、アクティブなハブクラスターが 1 つと、パッシブなクラスターが複数あります。アクティブハブクラスターは、primary ハブクラスターとも見なされます。これは、BackupSchedule.cluster.open-cluster-management.io リソースを使用してクラスターを管理し、定義された時間間隔でリソースをバックアップします。

アクティブハブクラスターとパッシブハブクラスターは、同じ Red Hat Advanced Cluster Management for Kubernetes バージョンを使用する必要があります。active-passive 設定が使用するハブクラスターをアップグレードする場合は、最初に復元ハブを最新バージョンにアップグレードしてから、プライマリーハブクラスターをアップグレードします。

注: プライマリーハブクラスターのデータをバックアップするには、active-passive 設定は必要ありません。ハブクラスターデータのバックアップと保存のみが可能です。これにより、問題や障害が発生した場合に、新しいハブクラスターをデプロイし、この新しいハブクラスター上にプライマリーハブクラスターデータを復元できます。プライマリーハブクラスターのデータを回復する時間を短縮するには、active-passive 設定を使用します。ただし、これは必須ではありません。

パッシブハブクラスターは、最新のバックアップを継続的に取得し、パッシブデータを復元します。パッシブハブは、Restore.cluster.open-cluster-management.io リソースを使用して、新規バックアップデータが利用可能な場合に、プライマリーハブクラスターからパッシブデータを復元します。これらのハブクラスターは、プライマリーハブクラスターで障害が発生した場合にプライマリーハブに切り替えられるように、スタンバイ状態にあります。

アクティブ/パッシブハブクラスターは同じストレージの場所に接続され、プライマリーハブクラスターはパッシブハブクラスターのデータをバックアップし、パッシブハブクラスターはプライマリーハブクラスターのバックアップにアクセスします。この自動復元を設定する方法の詳細は、バックアップの確認中にパッシブリソースを復元する を参照してください。

以下の図は、アクティブなハブクラスターがローカルクラスターを管理し、ハブクラスターデータを一定間隔でバックアップします。

パッシブハブクラスターは、マネージドクラスターをパッシブハブクラスターに移動するマネージドクラスターアクティベーションデータを除いて、このデータを復元します。パッシブハブクラスターは、パッシブデータを継続的に復元できます。パッシブハブクラスターは、パッシブデータを 1 回限りの操作として復元できます。詳細は、パッシブリソースの復元 を参照してください。

プライマリーハブクラスターに障害が発生した場合、ハブ管理者は、マネージドクラスターを引き継ぐパッシブハブクラスターを選択できます。次の 障害復旧図 では、ハブクラスター N を新しいプライマリーハブクラスターとして使用する方法を示しています。

ハブクラスター N は、マネージドクラスターのアクティブ化データを復元します。マネージドクラスターは ハブクラスター N に接続します。BackupSchedule.cluster.open-cluster-management.io リソースを作成し、最初のプライマリーハブクラスターと同じストレージの場所にバックアップを保存することにより、新しいプライマリーハブクラスターである ハブクラスター N のバックアップをアクティブ化します。

その他のパッシブハブクラスターはすべて、新しいプライマリーハブクラスターが作成したバックアップデータを使用してパッシブデータを復元するようになりました。ハブクラスター N がプライマリーハブクラスターとなり、クラスターの管理とデータのバックアップを行います。

重要:

パッシブリソースの詳細は、次の復元オプションを参照してください。

バックアップおよび復元 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

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

ハブクラスターのステータスがパッシブハブクラスターからプライマリーハブクラスターに、またはプライマリーハブクラスターからパッシブに変更され、異なるハブクラスターが同じストレージの場所にデータをバックアップすると、バックアップの競合が発生する可能性があります。

その結果、最新のバックアップは、プライマリーハブクラスターではなくなったハブクラスターによって生成されます。BackupSchedule.cluster.open-cluster-management.io リソースがまだ有効であるため、このハブクラスターは引き続きバックアップを生成します。

障害復旧テスト操作などの制御された環境で復元操作を実行する場合は、バックアップハブクラスターで BackupSchedule paused プロパティーを使用すると、バックアップの競合を防ぐことができます。新しいハブクラスターにリソースを復元する前に、BackupSchedule リソースで paused=true プロパティーを設定して、バックアップハブの BackupSchedule リソースを一時停止します。

バックアップの競合を引き起こす可能性のある 2 つのシナリオは、次のリストを参照してください。

バックアップの競合を防止および報告するには、BackupSchedule.cluster.open-cluster-management.io リソースの BackupCollision 状態を使用します。コントローラーは、保管場所の最新のバックアップが現在のハブクラスターから生成されたかどうかを定期的に確認します。そうでない場合は、別のハブクラスターが最近バックアップデータを保存場所に書き込んだことになり、ハブクラスターが別のハブクラスターと競合していることを示します。

バックアップ競合シナリオでは、現在のハブクラスターの BackupSchedule.cluster.open-cluster-management.io リソースのステータスが BackupCollision に設定されます。データの破損を防ぐために、このリソースは Schedule.velero.io リソースを削除します。バックアップポリシーは BackupCollision を報告します。

同じシナリオで、管理者はどのハブクラスターがストレージの場所に書き込むかを確認します。管理者は、無効なハブクラスターから BackupSchedule.cluster.open-cluster-management.io リソースを削除する前にこの検証を実行します。その後、管理者は有効なプライマリーハブクラスターに新しい BackupSchedule.cluster.open-cluster-management.io リソースを作成し、バックアップを再開できます。

バックアップの競合があるかどうかを確認するには、次のコマンドを実行します。

oc get backupschedule -A

oc get backupschedule -A

バックアップの競合がある場合は、出力は次の例のようになります。

NAMESPACE       NAME               PHASE             MESSAGE
openshift-adp   schedule-hub-1   BackupCollision   Backup acm-resources-schedule-20220301234625, from cluster with id [be97a9eb-60b8-4511-805c-298e7c0898b3] is using the same storage location. This is a backup collision with current cluster [1f30bfe5-0588-441c-889e-eaf0ae55f941] backup. Review and resolve the collision then create a new BackupSchedule resource to  resume backups from this cluster.

NAMESPACE       NAME               PHASE             MESSAGE
openshift-adp   schedule-hub-1   BackupCollision   Backup acm-resources-schedule-20220301234625, from cluster with id [be97a9eb-60b8-4511-805c-298e7c0898b3] is using the same storage location. This is a backup collision with current cluster [1f30bfe5-0588-441c-889e-eaf0ae55f941] backup. Review and resolve the collision then create a new BackupSchedule resource to  resume backups from this cluster.

復元操作を使用して、バックアップ操作によって作成された 3 つのバックアップタイプすべてを復元します。特定の種類のバックアップ (マネージドクラスターのみ、ユーザー認証情報のみ、またはハブクラスターリソースのみ) のみをインストールするように選択します。

復元では、以下の 3 つの必要な spec プロパティーを定義します。ここでは、バックアップしたファイルのタイプに対して復元ロジックが定義されます。

restore.cluster.open-cluster-management.io で作成された restore.velero.io リソースの名前は、<restore.cluster.open-cluster-management.io name>-<velero-backup-resource-name> のテンプレートルールを使用して生成されます。以下の説明を参照してください。

注記: skip がバックアップタイプに使用されている場合は、restore.velero.io は作成されません。

以下の YAML サンプルで、クラスターの Restore リソースを参照してください。この例では、利用可能な最新のバックアップファイルを使用して、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

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 状態のままであり、新しいハブクラスターにインポートし直す必要があります。詳細は、インポートしたマネージドクラスターの復元 を参照してください。

クラスターでバックアップデータを復元する必要がある場合は、ユーザーが作成したリソースを使用して、プライマリーハブクラスターまたはハブクラスターでデータを復元する代わりに、新しいクラスターを作成します。

データを初期のプライマリーハブクラスターに復元すると、現在のハブクラスターとプライマリーハブクラスターの両方がマネージドクラスターにアクセスできるようになります。両方のハブクラスターが制御を取得しようとするため、マネージドクラスターはハブクラスター間を頻繁に行き来することになります。

復元操作前にユーザーが作成したリソースを含むハブクラスターでデータを復元する場合、その操作にリソースを含めることはできません。ハブクラスター上のデータには、利用可能なデータがすべて含まれているわけではありません。

障害復旧テストシナリオでは、プライマリーハブクラスターをパッシブクラスターとして使用します。障害復旧テストでは、パッシブハブでの復元操作のみを検証し、その後プライマリーハブクラスターを使用します。

ハブバックアップクラスターのみをテストし、プライマリーハブクラスターを使用して新しいリソースを作成しません。代わりに、バックアップデータはプライマリーハブクラスターからパッシブハブクラスターに一時的に移動されます。すべてのリソースを復元すると、最初のプライマリーハブクラスターを再びプライマリーハブクラスターにすることができます。この操作では、復元後の操作が実行され、マネージドクラスターがこのハブクラスターに戻されます。

重要: 障害復旧テストでは、初期のプライマリーハブクラスターに戻る前に、復元クラスターを停止します。復元クラスターを停止すると、データが復元されて元のプライマリーハブクラスターへ移動した後も、マネージドクラスターは元の状態に復帰しなくなります。

ハブクラスターでバックアップデータを復元する必要がある場合は、プライマリーハブクラスターまたは復元操作の前に以前のユーザーがリソースを作成したハブクラスターを使用する代わりに、新しいハブクラスターを作成します。

障害復旧シナリオでは、バックアップをパッシブハブクラスターに復元するときに、障害発生中に失敗したハブクラスターと同じハブクラスターが必要になります。アプリケーション、ポリシー、追加のマネージドクラスターなど、その他のユーザーリソースは必要ありません。

このハブクラスターでバックアップを復元する場合、このハブクラスターによって管理されるマネージドクラスターがあると、復元操作によってそれらのクラスターがデタッチされ、クラスターリソースが削除される可能性があります。復元操作では、復元されたバックアップに含まれないリソースをクリーンアップするためにこれを行います。その結果、このハブクラスターのコンテンツは最初のハブクラスターと同じになります。この場合、マネージドクラスターのワークロードがデタッチアクションによってデタッチされるため、ユーザーデータが失われる可能性があります。

新しいハブクラスターで復元操作を実行する前に、ハブクラスターを手動で設定し、初期ハブクラスターと同じ Operator をインストールする必要があります。Red Hat Advanced Cluster Management Operator は、最初のハブクラスターと同じ namespace にインストールし、DataProtectionApplication リソースを作成してから、最初のハブクラスターがデータをバックアップしたのと同じストレージの場所に接続する必要があります。

MultiClusterEngine リソースへの変更を含め、Red Hat Advanced Cluster Management Operator によって作成された MultiClusterHub リソースの最初のハブクラスターと同じ設定を使用します。

たとえば、最初のハブクラスターに Ansible Automation Platform、Red Hat OpenShift GitOps、cert-manager などの他の Operator がインストールされている場合は、復元操作を実行する前にそれらをインストールする必要があります。これにより、新しいハブクラスターが初期のハブクラスターと同じ方法で設定されます。

データをバックアップしたハブクラスターと同じ Red Hat Advanced Cluster Management Operator バージョンを使用するハブクラスターで復元操作を実行します。新しい Red Hat Advanced Cluster Management Operator バージョンを使用するハブクラスターで復元操作を実行する場合は、次の手順を実行します。

現在復元されているバックアップで既存のリソースが変更されている場合、Velero は既存のリソースを更新します。Velero はデルタリソースをクリーンアップしません。これは、以前の復元によって作成されたリソースであり、現在復元されているバックアップの一部ではありません。これにより、新しいハブクラスターでハブクラスターデータを復元するときに使用できるシナリオが制限されます。復元が 1 回だけ適用されない限り、新しいハブクラスターをパッシブ設定として確実に使用することはできません。ハブクラスターのデータは、復元されたリソースで利用できるデータを反映していません。

この制限に対処するために、Restore.cluster.open-cluster-management.io リソースが作成されると、バックアップ Operator は、ハブクラスターをクリーンアップする復元後の操作を実行します。この操作は、現在復元されているバックアップの一部ではない、以前の Red Hat Advanced Cluster Management 復元によって作成されたすべてのリソースを削除します。

復元後のクリーンアップでは、cleanupBeforeRestore プロパティーを使用して、クリーンアップするオブジェクトのサブセットを識別します。復元後のクリーンアップには、次のオプションを使用できます。

注記:

新しいバックアップが利用可能かどうかを引き続き確認し、それらを自動的に復元しながら、restore-passive-sync サンプルを使用してパッシブデータを復元します。新しいバックアップを自動的に復元するには、syncRestoreWithNewBackups パラメーターを true に設定する必要があります。また、最新のパッシブデータだけを復元する必要もあります。サンプルの例は、このセクションの最後にあります。

VeleroResourcesBackupName および VeleroCredentialsBackupName パラメーターを latest に設定し、VeleroManagedClustersBackupName パラメーターを skip に設定します。VeleroManagedClustersBackupName が latest に設定された直後に、マネージドクラスターは新しいハブクラスターでアクティベートされ、プライマリーハブクラスターになります。

アクティベートされたマネージドクラスターがプライマリーハブクラスターになると、復元リソースが Finished に設定され、true に設定されていても syncRestoreWithNewBackups は無視されます。

デフォルトでは、コントローラーは syncRestoreWithNewBackups が true に設定されると、30 分ごとに新規バックアップをチェックします。新しいバックアップが見つかった場合は、バックアップされたリソースを復元します。restoreSyncInterval パラメーターを更新してチェックの期間を変更できます。

復元操作の完了後に同じ復元操作を再度実行する場合は、同じ spec オプションで新しい restore.cluster.open-cluster-management.io リソースを作成する必要があります。

たとえば、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

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

パッシブ設定でハブクラスターリソースを復元するには、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

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

パッシブハブクラスターにアクティベーションデータを復元する前に、バックアップが作成された以前のハブクラスターをシャットダウンします。プライマリーハブクラスターがまだ実行中の場合は、このハブクラスターで実行されている調整手順に基づいて、使用できなくなったマネージドクラスターへの再接続を試行します。

ハブクラスターでクラスターを管理する場合は、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

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

パッシブリソースを復元した方法に応じて、アクティベーションリソースを復元するいくつかのオプションがあります。

cluster.open-cluster-management.io/backup: cluster-activation ラベルを使用すると、マネージドクラスターのアクティベーションデータまたはその他のアクティベーションデータリソースは、マネージドクラスターのバックアップおよび resource-generic バックアップにより保存されます。アクティベーションデータが新しいハブクラスターに復元すると、マネージドクラスターは、復元が実行するハブクラスターによりアクティブに管理されます。Operator の使用方法は、バックアップのスケジュールと復元 を参照してください。

すべてのデータを復元するには、次の restore-acm サンプルを使用します。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm
  namespace: open-cluster-management-backup
spec:
  cleanupBeforeRestore: None
  veleroManagedClustersBackupName: latest
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-acm
  namespace: open-cluster-management-backup
spec:
  cleanupBeforeRestore: None
  veleroManagedClustersBackupName: latest
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest

ハブクラスターに restore.cluster.open-cluster-management.io リソースを作成した後、次のコマンドを実行して復元操作のステータスを取得します。

oc describe -n open-cluster-management-backup restore-acm

oc describe -n open-cluster-management-backup restore-acm

Hive API を使用してプライマリーハブクラスターに接続されたマネージドクラスターのみが、アクティベーションデータが復元される新しいハブクラスターに自動的に接続されます。これらのクラスターは、Clusters タブの Create cluster ボタンを使用するか、CLI を通じて、Hive API によってプライマリーハブクラスター上に作成されています。Import cluster ボタンを使用して最初のハブクラスターに接続されたマネージドクラスターは、アクティベーションデータが復元されると Pending Import として表示され、新しいハブクラスターにインポートし直す必要があります。

Hive がマネージドクラスター kubeconfig をハブクラスターのマネージドクラスター namespace に格納するため、Hive マネージドクラスターを新しいハブクラスターに接続できます。これは、新しいハブクラスターでバックアップおよび復元されます。次に、インポートコントローラーは、復元された設定を使用してマネージドクラスターのブートストラップ kubeconfig を更新します。これは、Hive API を使用して作成されたマネージドクラスターでのみ使用できます。インポートされたクラスターでは使用できません。

復元操作中に新しいハブクラスターにインポートされたクラスターを再接続するには、BackupSchedule で自動インポート機能を有効にします。詳細は、自動インポートの有効化 を参照してください。

以下の YAML の例を参照して、さまざまなタイプのバックアップファイルを復元します。

velero.io.restore 仕様では、高度な復元オプションが定義されています。これらの高度な復元オプションを使用すると、復元するリソースを除外できます。

たとえば、次の YAML サンプルを使用して、マネージドクラスターの namespace vb-managed-cls-2 からのみリソースを復元し、グローバルの Managedluster リソースを除外することができます。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-filter-sample
  namespace: open-cluster-management-backup
spec:
  cleanupBeforeRestore: None
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest
  veleroManagedClustersBackupName: latest
  excludedResources:
    - ManagedCluster
  includedNamespaces:
    - vb-managed-cls-2

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
  name: restore-filter-sample
  namespace: open-cluster-management-backup
spec:
  cleanupBeforeRestore: None
  veleroCredentialsBackupName: latest
  veleroResourcesBackupName: latest
  veleroManagedClustersBackupName: latest
  excludedResources:
    - ManagedCluster
  includedNamespaces:
    - vb-managed-cls-2

Red Hat Advanced Cluster Management for Kubernetes の復元リソースを作成するときに、velero.io.restore 仕様のオプションがさらに必要な場合は、次の復元フィルターを参照してください。

spec:
  includedResources
  includedNamespaces
  excludedResources
  excludedNamespaces
  LabelSelector
  OrLabelSelector

spec:
  includedResources
  includedNamespaces
  excludedResources
  excludedNamespaces
  LabelSelector
  OrLabelSelector

注記: どの Velero 復元フィルターでも、cleanupBeforeRestore フィールドを None に設定してください。これは、復元されるバックアップの一部であるが、適用されるフィルターによって復元対象外となるハブクラスターリソースをクリーンアップする必要性を回避するためです。

以下のコマンドを使用して、復元イベントに関する情報を取得します。

oc describe -n open-cluster-management-backup <restore-name>

oc describe -n open-cluster-management-backup <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

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

マネージドサービスアカウントコンポーネントを使用した自動インポート機能は、デフォルトでは無効になっています。自動インポート機能を有効にするには、次の手順を実行します。

自動インポート機能を有効にすると、バックアップコンポーネントは以下を作成して、インポートされたマネージドクラスターの処理を開始します。

トークンは、マネージドサービスアカウントの作成時にマネージドクラスターにアクセスできる場合にのみ作成されます。それ以外の場合は、後でマネージドクラスターが利用可能になったときに作成されます。

次のシナリオでは、新しいハブクラスターに移動するときに、マネージドクラスターが自動的にインポートされなくなる可能性があります。

BackupSchedule リソースで useManagedServiceAccount パラメーターを false に設定することで、クラスターの自動インポート機能を無効にすることができます。以下の例を参照してください。

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: BackupSchedule
metadata:
  name: schedule-acm-msa
  namespace: open-cluster-management-backup
spec:
  veleroSchedule:
  veleroTtl: 120h
  useManagedServiceAccount: false

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: BackupSchedule
metadata:
  name: schedule-acm-msa
  namespace: open-cluster-management-backup
spec:
  veleroSchedule:
  veleroTtl: 120h
  useManagedServiceAccount: false

デフォルト値は false です。値を false に設定した後、バックアップ Operator は、ManagedServiceAddon、ManagedServiceAccount、および ManifestWork を含む、作成されたすべてのリソースを削除します。リソースを削除すると、ハブクラスターとマネージドクラスターの自動インポートトークンが削除されます。

サーバー側の暗号化は、保存場所でデータを受信するアプリケーションまたはサービスのデータ暗号化です。バックアップメカニズム自体は、転送中 (バックアップストレージの場所との間を移動するとき) または保存中 (バックアップストレージの場所のディスクに保存されている間) にデータを暗号化しません。代わりに、オブジェクトおよびスナップショットシステムのネイティブメカニズムに依存しています。

ベストプラクティス: 使用可能なバックアップストレージのサーバー側の暗号化を使用して、宛先でデータを暗号化します。バックアップには、認証情報や設定ファイルなど、ハブクラスターの外部に保存するときに暗号化する必要があるリソースが含まれています。

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

spec:
  backupLocations:
    - velero:
        config:
          kmsKeyId: 502b409c-4da1-419f-a16e-eif453b3i49f
          profile: default
          region: us-east-1

他のストレージプロバイダーの設定可能なすべてのパラメーターは、Velero がサポートするストレージプロバイダー を参照してください。

復元操作を実行してハブクラスターをアクティブにする前に、プライマリーハブクラスターを準備する必要があります。

プライマリーハブクラスターを準備するには、次の手順を実行します。

プライマリーハブクラスターを準備したら、新しいハブクラスターで復元操作を実行し、マネージドクラスターを移動します。バックアップハブクラスターで自動インポート機能が無効になっているため、マネージドクラスターは新しいハブクラスターに接続され、最初のハブクラスターに戻りません。

次の手順を実行して、新しいハブクラスターで復元操作を実行します。

復元後、マネージドクラスターが新しいハブクラスターに正常に接続したら、初期バックアップハブクラスターからマネージドクラスターリソースを消去します。リカバリーテストが完了した後にそのデータをバックアップに復元する場合は、リソースのクリーンアップをスキップしてください。

バックアップハブクラスターからマネージドクラスターをクリーンアップするには、次の手順を実行します。

重要:

Velero の初回インストール時に、Velero Pod は以下のサンプルで定義されるデフォルトの CPU およびメモリー制限に設定されます。

resources:
 limits:
   cpu: "1"
   memory: 256Mi
 requests:
   cpu: 500m
   memory: 128Mi

resources:
 limits:
   cpu: "1"
   memory: 256Mi
 requests:
   cpu: 500m
   memory: 128Mi

前のサンプルの制限は一部のシナリオでうまく機能しますが、クラスターが多数のリソースをバックアップする場合には更新する必要がある場合があります。たとえば、2000 個のクラスターを管理するハブクラスターでバックアップを実行すると、メモリー不足 (OOM) エラーが原因で、Velero Pod が失敗します。以下の設定では、このシナリオでバックアップを完了できます。

  limits:
    cpu: "2"
    memory: 1Gi
  requests:
    cpu: 500m
    memory: 256Mi

  limits:
    cpu: "2"
    memory: 1Gi
  requests:
    cpu: 500m
    memory: 256Mi

Velero Pod リソースの制限および要求を更新するには、DataProtectionApplication リソースを更新し、Velero Pod の resourceAllocation テンプレートを挿入する必要があります。以下のサンプルを参照してください。

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: velero
  namespace: open-cluster-management-backup
spec:
...
  configuration:
...
    velero:
      podConfig:
        resourceAllocations:
          limits:
            cpu: "2"
            memory: 1Gi
          requests:
            cpu: 500m
            memory: 256Mi

apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: velero
  namespace: open-cluster-management-backup
spec:
...
  configuration:
...
    velero:
      podConfig:
        resourceAllocations:
          limits:
            cpu: "2"
            memory: 1Gi
          requests:
            cpu: 500m
            memory: 256Mi

復元操作に使用する予定のハブクラスターがすでにクラスターを管理しており、cleanupBeforeRestore オプションを CleanupRestored に設定して復元操作を実行すると、次の結果になることが予想されます。

ユーザーが作成したデータを含むハブクラスターでデータを復元する場合に、復元操作の cleanupBeforeRestore オプションが CleanupRestored に設定されていれば、そのデータはクリーンアップされません。これは、データが以前の復元ではなくユーザーによって作成されたためです。

ユーザーが作成したリソースがクリーンアップされない場合でも、既存のハブクラスターを、復元ハブクラスター設定用として引き続き使用できます。バックアップと復元のハブクラスター内のコンテンツを相互に一致させることができます。リソースに cluster.open-cluster-management.io/backup ラベルのタグを付けると、ユーザーが作成したすべてのリソースが、以前の復元操作によって生成されたかのように同じように表示されます。

リソースにタグを付ける方法については、ユーザーリソースにバックアップラベルをタグ付けする を完了して詳細を確認してください。

復元ハブクラスター上のユーザーが作成したリソースに velero.io/backup-name: backupName ラベルのタグを付けるには、復元ハブクラスターで次の手順を実行します。

Operator は、ハブクラスターバックアップに含まれる各リソースを調べ、velero.io/backup-name: backupName のタグを付けます。ここで、backupName は最新のバックアップの名前です。

リソースにタグを付けた後、ハブクラスターを復元クラスターとして使用できます。DataProtectionApplication の保存場所を更新してバックアップハブクラスターの保存場所を参照するようにすることで、プライマリーハブクラスターからデータを復元できるようになり、ハブクラスターのバックアップリソースを使用する復元操作を実行できるようになりました。

すべての復元ハブクラスターリソースには velero.io/backup-name label のタグが付いているため、ハブクラスターは以前の復元によって生成されたものとして表示されます。したがって、cleanupBeforeRestore オプションを CleanupRestored に設定して既存のハブクラスターで実行する復元操作では、復元されたバックアップに含まれないデータが消去されます。

重要:

復元プロセス中にプライマリーハブクラスターがアクティブな状態を維持するように準備するには、プライマリーハブクラスターがアクティブな状態での復元操作の実行 というタスクを完了します。

復元操作のためにバックアップハブクラスターを準備して復元を実行するには、復元プロセス中にプライマリーハブクラスターをアクティブに保つ ドキュメントの内容を完了します。

シミュレーションを開始するには、次の手順を実行して、新しいハブクラスターをアクティブハブクラスターにする必要があります。

障害復旧テストが終了したら、次の手順を実行してプライマリーハブクラスターに戻り、クラスターフリートを管理するアクティブハブクラスターにします。

これで最初のハブクラスターが再びプライマリーハブクラスターになりました。次に以下の手順を実行して、プライマリーハブクラスターでバックアップスケジュールを有効にします。

クラスターに VolSync をインストールする前に、以下の要件が必要です。

VolSync が 1 つのクラスターの永続ボリューム要求を別のクラスターの永続ボリューム要求に複製できるようにするには、ソースとターゲットの両方のマネージドクラスターに VolSync をインストールする必要があります。

VolSync は独自の namespace を作成しないため、他の OpenShift Container Platform のすべての namespace Operator と同じ namespace にあります。VolSync の Operator 設定に加えた変更は、チャネル更新の手動承認に変更した場合など、同じ namespace 内の他の Operator にも影響します。

2 つの方法のいずれかを使用して、環境内の 2 つのクラスターに VolSync をインストールできます。次のセクションで説明するように、ハブクラスター内の各マネージドクラスターにラベルを追加するか、ManagedClusterAddOn を手動で作成して適用することができます。

Rsync-TLS レプリケーションを使用して、永続ボリュームの 1:1 非同期レプリケーションを作成できます。Rsync-TLS ベースのレプリケーションを災害復旧やリモートサイトへのデータ送信に使用できます。Rsync-TLS を使用する場合、VolSync は、stunnel によって提供される TLS で保護されたトンネル全体で Rsync を使用してデータを同期します。詳細は stunnel のドキュメント を参照してください。

次の例は、Rsync-TLS メソッドを使用して設定する方法を示しています。Rsync-TLS の追加情報は、VolSync ドキュメントの Usage を参照してください。

重要: セキュリティーを強化するには、Rsync の代わりに Rsync-TLS を使用してください。Rsync-TLS を使用すると、永続ボリュームのレプリケーションに必要のない昇格されたユーザー権限の使用を回避できます。

Rsync レプリケーションを使用して、永続ボリュームの 1:1 非同期レプリケーションを作成できます。Rsync ベースのレプリケーションを災害復旧やリモートサイトへのデータ送信に使用できます。

次の例は、Rsync メソッドを使用して設定する方法を示しています。

restic ベースのバックアップは、永続ボリュームの restic ベースのバックアップコピーを、restic-config.yaml シークレットファイルで指定された場所にコピーします。restic バックアップは、クラスター間でデータを同期しませんが、データをバックアップします。

次の手順を実行して、restic ベースのバックアップを設定します。

注記: デフォルトでは、restic ムーバーは root 権限なしで実行されます。restic ムーバーを root として実行する場合は、次のコマンドを実行して、昇格された権限のアノテーションを namespace に追加します。

oc annotate namespace <namespace> volsync.backube/privileged-movers=true

oc annotate namespace <namespace> volsync.backube/privileged-movers=true

<namespace> を namespace の名前に置き換えます。

Rclone バックアップは、Rclone を使用して AWS S3 などの中間オブジェクトストレージの場所を介して単一の永続ボリュームを複数の場所にコピーします。複数の場所にデータを配布する場合に役立ちます。

次の手順を実行して、Rclone レプリケーションを設定します。

注記: デフォルトでは、rclone ムーバーは root 権限なしで実行されます。rclone ムーバーを root として実行する場合は、次のコマンドを実行して、昇格された権限のアノテーションを namespace に追加します。

oc annotate namespace <namespace> volsync.backube/privileged-movers=true

oc annotate namespace <namespace> volsync.backube/privileged-movers=true

<namespace> を namespace の名前に置き換えます。

詳細は、以下のトピックを参照してください。

送信元と宛先は、TLS 接続の共有キーにアクセスできる必要があります。キーの場所は keySecret フィールドで確認できます。.spec.rsyncTLS.keySecret にシークレット名を指定しない場合、シークレット名は自動的に生成され、.status.rsyncTLS.keySecret に追加されます。

独自のシークレットを作成するには、次の手順を実行します。