Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

9.7.6.2. OADP を使用したホステッドクラスターの新しい管理クラスターへの復元

Restore カスタムリソース (CR) を作成することにより、ホステッドクラスターを新しい管理クラスターに復元できます。

  • インプレース更新を使用している場合、InfraEnv リソースには予備のノードは必要ありません。代わりに、新しい管理クラスターからワーカーノードを再プロビジョニングする必要があります。
  • replace 更新を使用している場合は、ワーカーノードをデプロイするために InfraEnv リソース用の予備ノードがいくつか必要です。

前提条件

  • OpenShift API for Data Protection (OADP) を使用するように新しい管理クラスターを設定している。Restore CR がバックアップストレージにアクセスできるように、新しい管理クラスターには、バックアップ元の管理クラスターと同じ Data Protection Application (DPA) が必要です。

  • ホステッドクラスターの DNS を解決するために、新しい管理クラスターのネットワーク設定を設定している。

    • ホストの DNS は、新しい管理クラスターとホステッドクラスターの両方の IP に解決される必要があります。
    • ホステッドクラスターは、新しい管理クラスターの IP に解決する必要があります。

バックアッププロセスを監視および観察するには、「バックアップおよび復元プロセスの観察」を参照してください。

重要

バックアップを作成した管理クラスターではなく、ホステッドクラスターを復元する新しい管理クラスターで次の手順を実行します。

手順

  1. Restore CR を定義する YAML ファイルを作成します。

    restore-hosted-cluster.yaml ファイルの例

    apiVersion: velero.io/v1
kind: Restore
metadata:
  name: <restore_resource_name>
    1 
    
  namespace: openshift-adp
spec:
  includedNamespaces:
    2 
    
  - <hosted_cluster_namespace>
    3 
    
  - <hosted_control_plane_namespace>
    4 
    
  - <agent_namespace>
    5 
    
  backupName: <backup_resource_name>
    6 
    
  cleanupBeforeRestore: CleanupRestored
  veleroManagedClustersBackupName: <managed_cluster_name>
    7 
    
  veleroCredentialsBackupName: <credentials_backup_name>
  veleroResourcesBackupName: <resources_backup_name>
  restorePVs: true
    8 
    
  preserveNodePorts: true
  existingResourcePolicy: update
    9 
    
  excludedResources:
  - pod
  - nodes
  - events
  - events.events.k8s.io
  - backups.velero.io
  - restores.velero.io
  - resticrepositories.velero.io
  - pv
  - pvc

    1
    <restore_resource_name> を Restore リソースの名前に置き換えます。
    2
    特定の namespace を選択して、そこからオブジェクトをバックアップします。ホステッドクラスターの namespace と Hosted Control Plane の namespace を含める必要があります。
    3
    <hosted_cluster_namespace> を、ホステッドクラスター namespace の名前 (例: clusters) に置き換えます。
    4
    <hosted_control_plane_namespace> は、Hosted Control Plane の namespace の名前 (例: clusters-hosted) に置き換えます。
    5
    <agent_namespace> は、Agent、BMH、および InfraEnv CR が配置されている namespace (例: agents) に置き換えます。
    6
    <backup_resource_name> を Backup リソースの名前に置き換えます。
    7
    Red Hat Advanced Cluster Management を使用していない場合は、このフィールドを省略できます。
    8
    永続ボリューム (PV) とその Pod のリカバリーを開始します。
    9
    既存のオブジェクトがバックアップされたコンテンツで上書きされるようにします。

  2. 次のコマンドを実行して、Restore CR を適用します。 

    $ oc --kubeconfig <restore_management_kubeconfig> apply -f restore-hosted-cluster.yaml

  3. 次のコマンドを実行して、status.phase の値が Completed であることを確認します。 

    $ oc --kubeconfig <restore_management_kubeconfig> \
  get restore.velero.io <restore_resource_name> \
  -n openshift-adp -o jsonpath='{.status.phase}'

  4. 次のコマンドを実行して、すべての CR が復元されていることを確認します。 

    $ oc --kubeconfig <restore_management_kubeconfig> get infraenv -n <agent_namespace>
     
    $ oc --kubeconfig <restore_management_kubeconfig> get agent -n <agent_namespace>
     
    $  oc --kubeconfig <restore_management_kubeconfig> get bmh -n <agent_namespace>
     
    $ oc --kubeconfig <restore_management_kubeconfig> get hostedcluster -n <hosted_cluster_namespace>
     
    $ oc --kubeconfig <restore_management_kubeconfig> get nodepool -n <hosted_cluster_namespace>
     
    $ oc --kubeconfig <restore_management_kubeconfig> get agentmachine -n <hosted_controlplane_namespace>
     
    $ oc --kubeconfig <restore_management_kubeconfig> get agentcluster -n <hosted_controlplane_namespace>

  5. 今後、新しい管理クラスターをメインの管理クラスターとして使用する予定の場合は、以下の手順を実行します。バックアップ元の管理クラスターをメインの管理クラスターとして使用する予定の場合は、「OADP を使用してホステッドクラスターを同じ管理クラスターに復元する」の手順 5 - 8 を完了します。

    1. 次のコマンドを実行して、バックアップした管理クラスターから Cluster API デプロイメントを削除します。 

      $ oc --kubeconfig <backup_management_kubeconfig> delete deploy cluster-api \
  -n <hosted_control_plane_namespace>

      一度に 1 つの Cluster API のみがクラスターにアクセスできるため、この手順により、新しい管理クラスターの Cluster API が正常に機能します。

    2. 復元プロセスが完了したら、コントロールプレーンワークロードのバックアップ中に一時停止した HostedCluster リソースおよび NodePool リソースのリコンシリエーションを開始します。

      1. 次のコマンドを実行して、HostedCluster リソースのリコンシリエーションを開始します。 

        $ oc --kubeconfig <restore_management_kubeconfig> \
  patch hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> \
  --type json \
  -p '[{"op": "replace", "path": "/spec/pausedUntil", "value": "false"}]'

      2. 次のコマンドを実行して、NodePool リソースのリコンシリエーションを開始します。 

        $ oc --kubeconfig <restore_management_kubeconfig> \
  patch nodepool -n <hosted_cluster_namespace> <node_pool_name> \
  --type json \
  -p '[{"op": "replace", "path": "/spec/pausedUntil", "value": "false"}]'

      3. 次のコマンドを実行して、Hosted Control Plane が使用可能であるとホステッドクラスターが報告していることを確認します。 

        $ oc --kubeconfig <restore_management_kubeconfig> get hostedcluster

      4. 次のコマンドを実行して、クラスター Operator が利用可能であるとホステッドクラスターが報告していることを確認します。 

        $ oc get co --kubeconfig <hosted_cluster_kubeconfig>

    3. コントロールプレーンワークロードのバックアップ中に一時停止したエージェントプロバイダーリソースのリコンシリエーションを開始します。

      1. 次のコマンドを実行して、AgentCluster リソースのリコンシリエーションを開始します。 

        $ oc --kubeconfig <restore_management_kubeconfig> \
  annotate agentcluster -n <hosted_control_plane_namespace>  \
  cluster.x-k8s.io/paused- --overwrite=true --all

      2. 次のコマンドを実行して、AgentMachine リソースのリコンシリエーションを開始します。 

        $ oc --kubeconfig <restore_management_kubeconfig> \
  annotate agentmachine -n <hosted_control_plane_namespace>  \
  cluster.x-k8s.io/paused- --overwrite=true --all

      3. 次のコマンドを実行して、Cluster リソースのリコンシリエーションを開始します。 

        $ oc --kubeconfig <restore_management_kubeconfig> \
  annotate cluster -n <hosted_control_plane_namespace> \
  cluster.x-k8s.io/paused- --overwrite=true --all

    4. 次のコマンドを実行して、ノードプールが予想通りに機能していることを確認します。 

      $ oc --kubeconfig <restore_management_kubeconfig> \
  get nodepool -n <hosted_cluster_namespace>

      出力例

      NAME       CLUSTER    DESIRED NODES   CURRENT NODES   AUTOSCALING   AUTOREPAIR   VERSION   UPDATINGVERSION   UPDATINGCONFIG   MESSAGE
hosted-0   hosted-0   3               3               False         False        4.17.11   False             False

    5. オプション: 競合が存在せず、新しい管理クラスターが引き続き機能していることを確認するには、次の手順を実行して、バックアップ管理クラスターから HostedCluster リソースを削除します。

      1. バックアップ元の管理クラスターの ClusterDeployment リソースで、次のコマンドを実行して spec.preserveOnDelete パラメーターを true に設定します。 

        $ oc --kubeconfig <backup_management_kubeconfig> patch \
  -n <hosted_control_plane_namespace> \
  ClusterDeployment/<hosted_cluster_name> -p \
  '{"spec":{"preserveOnDelete":'true'}}' \
  --type=merge

        この手順は、ホストのプロビジョニングが解除されないようにします。

      2. 以下のコマンドを実行してマシンを削除します。 

        $ oc --kubeconfig <backup_management_kubeconfig> patch \
  <machine_name> -n <hosted_control_plane_namespace> -p \
  '[{"op":"remove","path":"/metadata/finalizers"}]' \
  --type=merge
         
        $ oc --kubeconfig <backup_management_kubeconfig> \
  delete machine <machine_name> \
  -n <hosted_control_plane_namespace>

      3. 次のコマンドを実行して、AgentCluster および Cluster リソースを削除します。 

        $ oc --kubeconfig <backup_management_kubeconfig> \
  delete agentcluster <hosted_cluster_name> \
  -n <hosted_control_plane_namespace>
         
        $ oc --kubeconfig <backup_management_kubeconfig> \
  patch cluster <cluster_name> \
  -n <hosted_control_plane_namespace> \
  -p '[{"op":"remove","path":"/metadata/finalizers"}]' \
  --type=json
         
        $ oc --kubeconfig <backup_management_kubeconfig> \
  delete cluster <cluster_name> \
  -n <hosted_control_plane_namespace>

      4. Red Hat Advanced Cluster Management を使用する場合は、次のコマンドを実行してマネージドクラスターを削除します。 

        $ oc --kubeconfig <backup_management_kubeconfig> \
  patch managedcluster <hosted_cluster_name> \
  -n <hosted_cluster_namespace> \
  -p '[{"op":"remove","path":"/metadata/finalizers"}]' \
  --type=json
         
        $ oc --kubeconfig <backup_management_kubeconfig> \
  delete managedcluster <hosted_cluster_name> \
  -n <hosted_cluster_namespace>

      5. 次のコマンドを実行して、HostedCluster リソースを削除します。 

        $ oc --kubeconfig <backup_management_kubeconfig> \
  delete hostedcluster \
  -n <hosted_cluster_namespace> <hosted_cluster_name>
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

Legal Notice

Theme

© 2026 Red Hatトップに戻る