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

2.7. SiteConfig の高度なトピック

SiteConfig Operator は、カスタうテンプレートの作成、ワークノードのスケーリング、大半のユースケースに適用する標準操作の拡張など、追加の機能を提供します。SiteConfig Operator の高度なトピックは、以下のドキュメントを参照してください。

2.7.1. SiteConfig Operator を使用してカスタムテンプレートを作成する
リンクのコピー

デフォルトのテンプレートセットに用意されていないユーザー定義テンプレートを作成します。

必要なアクセス権: クラスター管理者

カスタムテンプレートを作成するには、次の手順を実行します。

  1. ConfigMap オブジェクトにクラスターレベルのテンプレートが含まれる YAML ファイルを、my-custom-secret.yaml という名前で作成します。 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: my-custom-secret
  namespace: rhacm
data:
  MySecret: |-
    apiVersion: v1
    kind: Secret
    metadata:
      name: "{{ .Spec.ClusterName }}-my-custom-secret-key"
      namespace: "clusters"
      annotations:
        siteconfig.open-cluster-management.io/sync-wave: "1"
    1 
    
    type: Opaque
    data:
      key: <key>
    Copy to Clipboard Toggle word wrap
    1
    siteconfig.open-cluster-management.io/sync-wave アノテーションは、マニフェストが作成、更新、または削除される順序を制御します。

  2. 次のコマンドを実行して、ハブクラスターにカスタムテンプレートを適用します。 

    oc apply -f my-custom-secret.yaml
    Copy to Clipboard Toggle word wrap

  3. clusterinstance-my-custom-secret.yaml という名前の ClusterInstance カスタムリソースでテンプレートを参照します。 

    spec:
    ...
  templateRefs:
    - name: ai-cluster-templates-v1.yaml
      namespace: rhacm
    - name: my-custom-secret.yaml
      namespace: rhacm
    ...
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して、ClusterInstance カスタムリソースを適用します。 

    oc apply -f clusterinstance-my-custom-secret.yaml
    Copy to Clipboard Toggle word wrap

2.7.2. SiteConfig Operator を使用してシングルノード OpenShift クラスターをスケーリングする
リンクのコピー

SiteConfig Operator によってインストールされたマネージドクラスターをスケールインします。ワーカーノードを削除することでクラスターをスケールインできます。

必要なアクセス権: クラスター管理者

2.7.2.1. 前提条件
リンクのコピー

2.7.2.2. ワーカーノードにアノテーションを追加する
リンクのコピー

削除するワーカーノードにアノテーションを追加します。

マネージドクラスターからワーカーノードにアノテーションを付けるには、次の手順を実行します。

  1. クラスターのプロビジョニングに使用される ClusterInstance カスタムリソースのワーカーノードエントリーの extraAnnotations フィールドに、アノテーションを追加します。 

    spec:
   ...
   nodes:
   - hostName: "worker-node2.example.com"
      role: "worker"
      ironicInspect: ""
      extraAnnotations:
        BareMetalHost:
          bmac.agent-install.openshift.io/remove-agent-and-node-on-delete: "true"
...
    Copy to Clipboard Toggle word wrap

  2. 変更を適用します。以下のオプションを参照してください。

    1. Red Hat OpenShift GitOps を使用せずに Red Hat Advanced Cluster Management を使用している場合は、ハブクラスターで次のコマンドを実行します。 
    oc apply -f <clusterinstance>.yaml
    Copy to Clipboard Toggle word wrap
    1. GitOps ZTP を使用している場合は、Git リポジトリーにプッシュし、Argo CD が変更を同期するのを待ちます。

  3. ハブクラスターで次のコマンドを実行して、アノテーションが BaremetalHost ワーカーリソースに適用されていることを確認します。 

    oc get bmh -n <clusterinstance_namespace> worker-node2.example.com -ojsonpath='{.metadata.annotations}' | jq
    Copy to Clipboard Toggle word wrap

    アノテーションが正常に適用された場合の出力例を次に示します。 

{
  "baremetalhost.metal3.io/detached": "assisted-service-controller",
  "bmac.agent-install.openshift.io/hostname": "worker-node2.example.com",
  "bmac.agent-install.openshift.io/remove-agent-and-node-on-delete": "true"
  "bmac.agent-install.openshift.io/role": "master",
  "inspect.metal3.io": "disabled",
  "siteconfig.open-cluster-management.io/sync-wave": "1",
}
Copy to Clipboard Toggle word wrap

2.7.2.3. ワーカーノードの BareMetalHost リソースを削除する
リンクのコピー

削除するワーカーノードの BareMetalHost リソースを削除します。

マネージドクラスターからワーカーノードを削除するには、次の手順を実行します。

  1. 既存の ClusterInstance カスタムリソースで削除するノードオブジェクトを、次の設定で更新します。 

    ...
spec:
   ...
   nodes:
     - hostName: "worker-node2.example.com"
       ...
       pruneManifests:
         - apiVersion: metal3.io/v1alpha1
           kind: BareMetalHost
...
    Copy to Clipboard Toggle word wrap

  2. 変更を適用します。以下のオプションを参照してください。

    1. Red Hat OpenShift GitOps を使用せずに Red Hat Advanced Cluster Management を使用している場合は、ハブクラスターで次のコマンドを実行します。 
    oc apply -f <clusterinstance>.yaml
    Copy to Clipboard Toggle word wrap
    1. GitOps ZTP を使用している場合は、Git リポジトリーにプッシュし、Argo CD が変更を同期するのを待ちます。

  3. ハブクラスターで次のコマンドを実行して、BareMetalHost リソースが削除されていることを確認します。 

    oc get bmh -n <clusterinstance_namespace> --watch --kubeconfig <hub_cluster_kubeconfig_filename>
    Copy to Clipboard Toggle word wrap

    以下の出力例を参照してください。 

    NAME                        STATE                        CONSUMER         ONLINE   ERROR   AGE
master-node1.example.com    provisioned                  true             81m
worker-node2.example.com    deprovisioning               true             44m
worker-node2.example.com    powering off before delete   true             20h
worker-node2.example.com    deleting                     true             50m
    Copy to Clipboard Toggle word wrap

  4. ハブクラスターで次のコマンドを実行して、Agent リソースが削除されていることを確認します。 

    oc get agents -n <clusterinstance_namespace> --kubeconfig <hub_cluster_kubeconfig_filename>
    Copy to Clipboard Toggle word wrap

    以下の出力例を参照してください。 

    NAME                       CLUSTER                  APPROVED   ROLE     STAGE
master-node1.example.com   <managed_cluster_name>   true       master   Done
master-node2.example.com   <managed_cluster_name>   true       master   Done
master-node3.example.com   <managed_cluster_name>   true       master   Done
worker-node1.example.com   <managed_cluster_name>   true       worker   Done
    Copy to Clipboard Toggle word wrap

  5. マネージドクラスターで次のコマンドを実行して、Node リソースが削除されていることを確認します。 

    oc get nodes --kubeconfig <managed_cluster_kubeconfig_filename>
    Copy to Clipboard Toggle word wrap

    以下の出力例を参照してください。 

    NAME                       STATUS                        ROLES                  AGE   VERSION
worker-node2.example.com   NotReady,SchedulingDisabled   worker                 19h   v1.30.5
worker-node1.example.com   Ready                         worker                 19h   v1.30.5
master-node1.example.com   Ready                         control-plane,master   19h   v1.30.5
master-node2.example.com   Ready                         control-plane,master   19h   v1.30.5
master-node3.example.com   Ready                         control-plane,master   19h   v1.30.5
    Copy to Clipboard Toggle word wrap
  6. ワーカーノードの BareMetalHost オブジェクトが正常に削除されたら、ClusterInstance リソースの spec.nodes セクションから、関連付けられたワーカーノード定義を削除します。

2.7.3. SiteConfig Operator を使用してシングルノードの OpenShift クラスターをスケールアウトする
リンクのコピー

SiteConfig Operator でインストールされたマネージドクラスターをスケールアウトします。ワーカーノードを追加することでクラスターをスケールアウトできます。

必要なアクセス権: クラスター管理者

2.7.3.1. 前提条件
リンクのコピー

2.7.3.2. ワーカーノードを追加する
リンクのコピー

クラスターのプロビジョニングに使用される ClusterInstance カスタムリソースを更新して、ワーカーノードを追加します。

マネージドクラスターにワーカーノードを追加するには、次の手順を実行します。

  1. 既存の ClusterInstance カスタムリソースに新しいノードオブジェクトを定義します。 

    spec:
  ...
  nodes:
    - hostName: "<host_name>"
      role: "worker"
      templateRefs:
        - name: ai-node-templates-v1
          namespace: rhacm
      bmcAddress: "<bmc_address>"
      bmcCredentialsName:
        name: "<bmc_credentials_name>"
      bootMACAddress: "<boot_mac_address>"
...
    Copy to Clipboard Toggle word wrap

  2. 変更を適用します。以下のオプションを参照してください。

    1. Red Hat OpenShift GitOps を使用せずに Red Hat Advanced Cluster Management を使用している場合は、ハブクラスターで次のコマンドを実行します。 
    oc apply -f <clusterinstance>.yaml
    Copy to Clipboard Toggle word wrap
    1. GitOps ZTP を使用している場合は、Git リポジトリーにプッシュし、Argo CD が変更を同期するのを待ちます。

  3. ハブクラスターで次のコマンドを実行して、新しい BareMetalHost リソースが追加されたことを確認します。 

    oc get bmh -n <clusterinstance_namespace> --watch --kubeconfig <hub_cluster_kubeconfig_filename>
    Copy to Clipboard Toggle word wrap

    以下の出力例を参照してください。 

    NAME                        STATE          CONSUMER   ONLINE   ERROR   AGE
master-node1.example.com    provisioned               true             81m
worker-node2.example.com    provisioning              true             44m
    Copy to Clipboard Toggle word wrap

  4. ハブクラスターで次のコマンドを実行して、新しい Agent リソースが追加されたことを確認します。 

    oc get agents -n <clusterinstance_namespace> --kubeconfig <hub_cluster_kubeconfig_filename>
    Copy to Clipboard Toggle word wrap

    以下の出力例を参照してください。 

    NAME                       CLUSTER                   APPROVED    ROLE     STAGE
master-node1.example.com   <managed_cluster_name>    true        master   Done
master-node2.example.com   <managed_cluster_name>    true        master   Done
master-node3.example.com   <managed_cluster_name>    true        master   Done
worker-node1.example.com   <managed_cluster_name>    false       worker
worker-node2.example.com   <managed_cluster_name>    true        worker   Starting installation
worker-node2.example.com   <managed_cluster_name>    true        worker   Installing
worker-node2.example.com   <managed_cluster_name>    true        worker   Writing image to disk
worker-node2.example.com   <managed_cluster_name>    true        worker   Waiting for control plane
worker-node2.example.com   <managed_cluster_name>    true        worker   Rebooting
worker-node2.example.com   <managed_cluster_name>    true        worker   Joined
worker-node2.example.com   <managed_cluster_name>    true        worker   Done
    Copy to Clipboard Toggle word wrap

  5. マネージドクラスターで次のコマンドを実行して、新しい Node リソースが追加されたことを確認します。 

    oc get nodes --kubeconfig <managed_cluster_kubeconfig_filename>
    Copy to Clipboard Toggle word wrap

    以下の出力例を参照してください。 

    NAME                       STATUS    ROLES                  AGE   VERSION
worker-node2.example.com   Ready     worker                 1h    v1.30.5
worker-node1.example.com   Ready     worker                 19h   v1.30.5
master-node1.example.com   Ready     control-plane,master   19h   v1.30.5
master-node2.example.com   Ready     control-plane,master   19h   v1.30.5
master-node3.example.com   Ready     control-plane,master   19h   v1.30.5
    Copy to Clipboard Toggle word wrap

2.7.4. 非接続環境向けのミラーリングイメージ
リンクのコピー

基盤となる Operator として Image Based Install Operator を使用すると、SiteConfig Operator を使用してクラスターをデプロイできます。非接続環境で Image Based Install Operator を使用してクラスターをデプロイする場合は、ミラーイメージを ClusterInstance カスタムリソースの追加マニフェストとして提供する必要があります。

必要なアクセス権: クラスター管理者

非接続環境のイメージをミラーリングするには、次の手順を実行します。

  1. ミラーレジストリーの場所を含む ImageDigestMirrorSet オブジェクト用に、idms-configmap.yaml という名前の YAML ファイルを作成します。 

    kind: ConfigMap
apiVersion: v1
metadata:
  name: "idms-configmap"
  namespace: "example-sno"
data:
  99-example-idms.yaml: |
    apiVersion: config.openshift.io/v1
    kind: ImageDigestMirrorSet
    metadata:
      name: example-idms
    spec:
      imageDigestMirrors:
      - mirrors:
        - mirror.registry.example.com/image-repo/image
        source: registry.example.com/image-repo/image
    Copy to Clipboard Toggle word wrap

重要: ClusterInstance リソースと同じ namespace に追加のマニフェストを含む ConfigMap リソースを定義します。

  1. ハブクラスターで次のコマンドを実行してリソースを作成します。 

    oc apply -f idms-configmap.yaml
    Copy to Clipboard Toggle word wrap

  2. ClusterInstance カスタムリソース内の ImageDigestMirrorSet オブジェクトを参照します。 

    apiVersion: siteconfig.open-cluster-management.io/v1alpha1
kind: ClusterInstance
metadata:
  name: "example-sno"
  namespace: "example-sno"
spec:
  ...
  extraManifestsRefs:
    - name: idms-configmap
...
    Copy to Clipboard Toggle word wrap

2.7.5. SiteConfig Operator によるクラスターの再インストール (テクノロジープレビュー)
リンクのコピー

SiteConfig Operator は、重要な設定データを保持しながら、ClusterInstance API を介して OpenShift クラスターの再インストールを簡素化します。

GitOps と互換性のある宣言型のアプローチを使用すると、ユーザーは ClusterInstance リソースを更新することで再インストールをトリガーできます。Operator にはハブ側の Secret および ConfigMap リソースのバックアップおよび復元メカニズムも含まれており、認証情報や設定リソースなどの重要なクラスターデータがそのまま残ります。

2.7.5.1. クラスターアイデンティティーの保持
リンクのコピー

クラスターの再インストールでは、シングルノード OpenShift クラスターとマルチノード OpenShift クラスターの両方がサポートされます。ただし、クラスターアイデンティティーの保存は、イメージベースのインストールプロビジョニング方法を使用してインストールしたシングルノード OpenShift クラスターでのみサポートされます。

イメージベースのインストールの詳細は、シングルノード OpenShift のイメージベースのインストール を参照してください。

2.7.5.2. クラスターの再インストールワークフロー
リンクのコピー

クラスターの再インストールワークフローの次の手順を参照してください。

  • 保存用にリソースにラベルを付けます。リソースを保存しない場合、これはオプションです。クラスターの再インストールを開始する前に、リソースに適切なラベルを付けることができます。
  • クラスターの再インストールを開始します。
  • 再インストールの進捗を監視し、再インストールしたクラスターが利用可能であることを確認します。これは任意です。

2.7.5.3. 保存のためのリソースラベル付け
リンクのコピー

再インストール後に重要なクラスター設定データを保持する場合、SiteConfig Operator は ClusterInstance namespace 内のハブ側の Secret および ConfigMap リソースのバックアップおよび復元メカニズムを提供します。

ClusterInstance リソースで preservationMode を設定し、適切な予約ラベルをリソースに追加し、データの保存を制御できます。使用できる保存モードは次のとおりです。

Expand
表2.1 保持モード
保持モード動作使用方法ラベル要件

None

ConfigMap または Secret リソースは保持されません。

再インストール中にクラスターのデータを保持する必要がない場合は、None モードを選択します。

None

All

ClusterInstance リソースと同じ namespace にあり、ラベルが付いた ConfigMap および Secret リソースがすべてバックアップされます。SiteConfig Operator がラベル付けされたリソースを見つけられない場合、Operator はデータを保存せずに再インストールを続行します。元のリソースはイミュータブルな Kubernetes Secret として保存されます。

ラベル付けされたリソース (存在する場合) を保持する場合は、All モードを選択します。

任意の値を指定して siteconfig.open-cluster-management.io/preserve: "<arbitrary-value>" ラベルを追加します (例: siteconfig.open-cluster-management.io/preserve: "")。ラベルは、保存モードが All に設定されている場合にのみ、指定のラベルを持つリソースをバックアップするように Operator に指示します。

ClusterIdentity

ClusterInstance CR と同じ namespace の siteconfig.open-cluster-management.io/preserve: "cluster-identity" ラベルの付いた ConfigMap および Secret リソースのみがバックアップされます。SiteConfig Operator がラベルの付いたリソースを見つけられない場合、Operator は再インストールプロセスを停止し、エラーメッセージを表示します。これらのリソースの元の CR は、イミュータブルな Kubernetes シークレットとして保存されます。

少なくとも 1 つのリソースにラベルが付けられていることを Operator が確認できるようにするには、ClusterIdentity モードを選択します。

保存モードが All または ClusterIdentity に設定されている場合に、ラベルを使用してリソースをバックアップするように Operator に指示するために siteconfig.open-cluster-management.io/preserve: "cluster-identity" ラベルを追加します。保存モードが ClusterIdentity に設定されていて、Operator が siteconfig.open-cluster-management.io/preserve: "cluster-identity" ラベルを持つリソースを少なくとも 1 つ見つけられない場合に、再インストールは停止します。

再インストールを開始する前に、リソースに適切なラベルを付けることができます。

2.7.5.4. クラスター再インストールの監視
リンクのコピー

再インストールには 2 つのフェーズがあります。

フェーズ 1 - 再インストール要求の処理
  • リクエストの検証: SiteConfig Operator がリクエストを検証します。
  • データの保存: SiteConfig Operator はラベル付けされたリソースをバックアップします。
  • クリーンアップ: SiteConfig Operator は既存のインストールマニフェストを削除します。この手順がタイムアウトすると、再インストールが停止し、ClusterInstance リソースが一時停止されます。
  • データの復元: SiteConfig Operator は保存されたデータを復元します。
フェーズ 2 - クラスターのプロビジョニング
  • マニフェストの再生成: SiteConfig Operator はテンプレートから新しいマニフェストを生成します。
  • クラスターのインストール: クラスターは新しいマニフェストを使用してプロビジョニングされます。

フェーズ 1 と 2 の進行状況は、それぞれ status.reinstall.conditions フィールドと status.conditions フィールドで追跡できます。クラスターの再インストールの進行状況を追跡するために、SiteConfig Operator は次のステータス条件を提供します。

Expand
表2.2 再インストールのステータス (状態)

状態

説明

理由

ReinstallRequestProcessed

再インストール要求の全体的なステータスを示します。

InProgress: 再インストールプロセスが進行中です。
Completed: 再インストールプロセスが正常に完了し、クラスターの再プロビジョニングの準備が整いました。
Failed: 再インストールプロセスでエラーが発生し、失敗しました。
TimedOut: 再インストールプロセスが予想された時間制限を超えたため、正常に完了しませんでした。

ReinstallRequestValidated

再インストール要求の有効性を確認します。

Completed: 再インストール要求は有効です。
Failed: 再インストール要求が無効です。

ReinstallPreservationDataBackedUp

保存済みデータのバックアップステータスを追跡します。

PreservationNotRequired: spec.reinstall.preservationMode: None が設定されているため、バックアップは必要ありません。
DataUnavailable: ClusterInstance namespace に保存ラベルを持つ Secret または ConfigMap オブジェクトが見つかりません。
Completed: Secret および ConfigMap オブジェクトが正常にバックアップされました。
Failed: 1 つ以上の Secret および ConfigMap オブジェクトがバックアップされていません。

ReinstallClusterIdentityDataDetected

クラスターアイデンティティーデータを保存できるかどうかを決定します。

PreservationNotRequired: データの保存は必要ありません。preservationMode フィールドが None に設定されています。
DataAvailable: クラスターアイデンティティー Secret および ConfigMap オブジェクトが正常に見つかりました。
DataUnavailable: クラスターアイデンティティー Secret または ConfigMap オブジェクトが検出されません。
Failed: 保存モードが ClusterIdentity に設定されていますが、クラスターアイデンティティーデータが見つかりません。

ReinstallRenderedManifestsDeleted

レンダリングされたマニフェストで、ClusterInstance リソースに関連付けられたものの削除を監視します。

InProgress: レンダリングされたマニフェストの削除が進行中です。
Completed: レンダリングされたマニフェストをすべて正常に削除しました。
Failed: レンダリングされたマニフェストを 1 つ以上削除できませんでした。
TimedOut: レンダリングされたマニフェストが削除されるのを待機中にタイムアウトしました。

ReinstallPreservationDataRestored

保存済みデータの復元ステータスを追跡します。

PreservationNotRequired: preservationMode フィールドが None に設定されているため、保存は不要です。
DataUnavailable: 復元用に保存された Secret または ConfigMap オブジェクトが検出されませんでした。
Completed: Secret および ConfigMap オブジェクトが正常に復元されました。
Failed: 1 つ以上の Secret および ConfigMap オブジェクトの復元に失敗しました。

status.reinstall フィールドには、次のフィールドで再インストールプロセスに関する詳細情報が提供されます。

  • InProgressGeneration: 再インストールで処理されるアクティブな世代を表します。
  • ObservedGeneration: 最後に正常に処理された再インストール要求を表します。
  • RequestStartTime: 再インストール要求の開始時刻を表します。
  • RequestEndTime: 再インストールプロセスが完了した時間を表します。
  • History: 生成の詳細、タイムスタンプ、ClusterInstance リソースの仕様変更など、過去の再インストールの試行を表示します。

2.7.6. SiteConfig Operator を使用したクラスターの再インストール (テクノロジープレビュー)
リンクのコピー

SiteConfig Operator を使用してクラスターを再インストールします。再インストールを有効にした後、任意の保存モードを定義し、該当する場合はリソースにラベルを付けることができます。

必要なアクセス権: クラスター管理者

クラスターを再インストールするには、次の手順を実行します。

  1. クラスターの再インストールを有効にする
  2. 保持用のリソースにラベルを付ける
  3. クラスターの再インストールを開始する
  4. クラスターの再インストールを監視する

2.7.6.1. クラスターの再インストールを有効にする
リンクのコピー

siteconfig-Operator-configuration ConfigMap リソースでクラスターの再インストールを明示的に有効にする必要があります。これは、プロセスを開始するよりもはるか前に完了させておくことができます。デフォルトでは、再インストールは無効になっています。

以下の手順を実行します。

  1. SiteConfig Operator がインストールされている namespace と一致するように NAMESPACE 環境変数を設定します。以下のコマンドを実行します。 

    NAMESPACE=<namespace>
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、現在の設定を確認します。 

    oc get configmap siteconfig-operator-configuration -n $NAMESPACE -o yaml
    Copy to Clipboard Toggle word wrap

    出力例: 

    apiVersion: v1
kind: ConfigMap
metadata:
    name: siteconfig-operator-configuration
    namespace: <namespace>
    1 
    
data:
    allowReinstalls: false
    2 
    
    ...
    Copy to Clipboard Toggle word wrap
    1
    SiteConfig Operator がインストールされている namespace。
    2
    再インストールを有効にするには true に設定します。

    注記: Operator は、siteconfig- operator -configuration ConfigMap リソースの変更を継続的に監視します。

  3. クラスターの再インストールを有効にするには、data.allowReinstalls フィールドを true に設定して ConfigMap リソースを更新します。以下のコマンドを実行します。 

    oc patch configmap siteconfig-operator-configuration \
    -n $NAMESPACE \
    --type=json \
    -p '[{"op": "replace", "path": "/data/allowReinstalls", "value": "true"}]'
    Copy to Clipboard Toggle word wrap

  4. 次のコマンドを実行して更新を確認します。 

    oc get configmap siteconfig-operator-configuration -n $NAMESPACE -o yaml
    Copy to Clipboard Toggle word wrap

2.7.6.2. 保持用のリソースにラベルを付ける
リンクのコピー

ClusterInstance カスタムリソースで、任意の保存モードを設定し、該当する場合はそれに応じてリソースにラベルを付けることができます。デフォルトでは、preservationMode フィールドは None に設定されています。詳細は、保存用のリソースのラベル付け を参照してください。

次の手順例を完了します。

  • 次のコマンドを実行して、リソースに保存モード All のラベルを付けます。 

    oc label configmap <your_configmap> "siteconfig.open-cluster-management.io/preserve=all"
    Copy to Clipboard Toggle word wrap

ClusterInstance カスタムリソースは、適用されたラベルに対応する適切な preservationMode で更新されます。

2.7.6.3. クラスターの再インストールを開始する
リンクのコピー

再インストールを開始するには、ClusterInstance リソースを新しい spec.reinstall.generation 値で更新します。

  1. ClusterInstance リソースの spec.reinstall.generation 値を変更します。 

    apiVersion: siteconfig.open-cluster-management.io/v1alpha1
kind: `ClusterInstance`
metadata:
  name: clusterinstance-example
  namespace: some-namespace
spec:
  reinstall:
    generation: "unique-generation-string"
    preservationMode: "<your-preservation-mode>"
    Copy to Clipboard Toggle word wrap

注記: ClusterInstance リソースを変更するときは、適切な保存モードを設定してください。有効な値は、"none"、"All"、または "ClusterIdentity" です。

  1. オプション: spec.reinstall オブジェクトを定義するときに、ClusterInstance リソース内の次の追加フィールドを変更できます。

    • spec.extraAnnotations
    • spec.extraLabels
    • spec.suppressedManifests
    • spec.pruneManifests
    • spec.nodes.<node-id>.extraAnnotations
    • spec.nodes.<node-id>.extraLabels
    • spec.nodes.<node-id>.suppressedManifests
    • spec.nodes.<node-id>.pruneManifests
    • spec.nodes.<node-id>.bmcAddress
    • spec.nodes.<node-id>.bootMACAddress
    • spec.nodes.<node-id>.nodeNetwork.interfaces.macAddress
    • spec.nodes.<node-id>.rootDeviceHints

    注記: <node-id> は、更新された NodeSpec オブジェクトを表します。

  2. 変更を適用します。以下のオプションを参照してください。

    1. OpenShift GitOps ZTP を使用している場合は、Git リポジトリーにプッシュし、Argo CD が変更を同期するまで待ちます。
    2. 変更を手動で適用するには、ハブクラスターで次のコマンドを実行します。 
    oc apply -f clusterinstance-example.yaml
    Copy to Clipboard Toggle word wrap

2.7.6.4. クラスターの再インストールを監視する
リンクのコピー

クラスターの再インストールの進行状況を監視できます。以下の手順を実行します。

  1. 再インストール要求が処理されていることを確認します。 

    oc get clusterinstance clusterinstance-example -n some-namespace -o json | jq -r '.status.reinstall.conditions[] | select(.type=="ReinstallRequestProcessed")'
    Copy to Clipboard Toggle word wrap

    以下の出力例を参照してください。 

    {
"type": "ReinstallRequestProcessed"
"reason": "InProgress",
"status": "False",
...
}
    Copy to Clipboard Toggle word wrap

  2. クラスターの再インストール要求が正常に検証されていることを確認します。 

    oc get clusterinstance clusterinstance-example -n some-namespace -o json | jq -r '.status.reinstall.conditions[] | select(.type=="ReinstallRequestValidated")'
    Copy to Clipboard Toggle word wrap

    以下の出力例を参照してください。 

    {
"type": "ReinstallRequestValidated"
"reason": "Completed",
"status": "True",
...
}
    Copy to Clipboard Toggle word wrap

  3. オプション: spec.reinstall.preservationMode フィールドを All または ClusterIdentity に設定した場合は、クラスター ID データが保持されていることを確認します。 

    oc get clusterinstance clusterinstance-example -n some-namespace -o json | jq -r '.status.reinstall.conditions[] | select(.type=="ReinstallPreservationDataBackedup")'
    Copy to Clipboard Toggle word wrap

    以下の出力例を参照してください。 

    {
"type": "ReinstallPreservationDataBackedup"
"reason": "Completed",
"status": "True",
...
}
    Copy to Clipboard Toggle word wrap

  4. オプション: spec.reinstall.preservationMode フィールドを All または ClusterIdentity に設定した場合は、クラスター ID データが検出されていることを確認します。 

    oc get clusterinstance clusterinstance-example -n some-namespace -o json | jq -r '.status.reinstall.conditions[] | select(.type=="ReinstallClusterIdentityDataDetected")'
    Copy to Clipboard Toggle word wrap

    以下の出力例を参照してください。 

    {
"type": "ReinstallClusterIdentityDataDetected"
"reason": "DataAvailable",
"status": "True",
...
}
    Copy to Clipboard Toggle word wrap

  5. インストールマニフェストが削除されていることを確認します。削除が完了するまで数分かかる場合があります。 

    oc get clusterinstance clusterinstance-example -n some-namespace -o json | jq -r '.status.reinstall.conditions[] | select(.type=="ReinstallRenderedManifestsDeleted")'
    Copy to Clipboard Toggle word wrap

    以下の出力例を参照してください。 

    {
"type": "ReinstallRenderedManifestsDeleted"
"reason": "Completed",
"status": "True",
...
}
    Copy to Clipboard Toggle word wrap

  6. オプション: preseservationMode フィールドを All または ClusterIdentity に設定した場合、以前に保持されたデータが復元されていることを確認します。 

    oc get clusterinstance clusterinstance-example -n some-namespace -o json | jq -r '.status.reinstall.conditions[] | select(.type=="ReinstallPreservationDataRestored")'
    Copy to Clipboard Toggle word wrap

    以下の出力例を参照してください。 

    {
"type": "ReinstallPreservationDataRestored"
"reason": "Completed",
"status": "True",
...
}
    Copy to Clipboard Toggle word wrap

  7. 前の手順を確認した後、再インストール要求が正常に完了したことを確認します。 

    oc get clusterinstance clusterinstance-example -n some-namespace -o json | jq -r '.status.reinstall.conditions[] | select(.type=="ReinstallRequestProcessed")'
    Copy to Clipboard Toggle word wrap

    以下の出力例を参照してください。 

    {
"type": "ReinstallRequestProcessed"
"reason": "Completed",
"status": "True",
...
}
    Copy to Clipboard Toggle word wrap
  8. 再インストールされたクラスターに関連付けられている kubeconfig ファイルを使用して oc コマンドを実行し、クラスターが正常に再インストールされ、動作していることを確認します。

Image-Based Break/Fix 機能は、SiteConfig Operator のクラスター再インストールメカニズムを利用して、シングルノード OpenShift ハードウェアの交換を簡素化します。この機能は、クラスターの元のアイデンティティーを保持することでダウンタイムを最小限に抑えます。Image-Based Break/Fix 機能は、識別子、kubeconfig などの暗号鍵、認証情報を含む、重要なクラスターの詳細を保持し、これにより、交換ノードで障害が発生したハードウェアのアイデンティティーをシームレスに引き継ぐことができます。

Image-Based Intall 方式を使用してインストールされたシングルノード OpenShift クラスターでの同一のハードウェア交換用に設計された Image-Based Break/Fix では、GitOps と互換性のある宣言型 API が導入されています。ユーザーは、1 回の Git コミットでハードウェアの交換を開始できます。SiteConfig Operator と Image-Based Install Operator を活用した Image-Based Break/Fix では、既存の ClusterInstance カスタムリソースを使用してクラスターの再デプロイメントが可能になります。

Image-Based Break/Fix により、OpenShift Container Platform ユーザーは、ハードウェア障害発生後にシングルノードの OpenShift クラスターを迅速に復元するための、回復力のある自動化された GitOps ネイティブソリューションを入手できます。

2.7.7.1. Image-Based Break/Fix クラスターの再インストールワークフロー
リンクのコピー

Image-Based Break/Fix のワークフローは、クラスターの再インストールワークフローに似ていますが、いくつかの違いがあります。ワークフローの違いを理解するには、Image-Based Break/Fix クラスターの再インストールワークフローの概要を参照してください。

  • SiteConfig Operator の再インストールサービスを有効にします。

  • クラスターの再インストールを開始します。

    • spec.reinstall.preservationMode: "ClusterIdentity" を設定します。
    • 変更されたハードウェア情報で spec.nodes オブジェクトを更新します。
    • 注記: Image Based Install Operator は、クラスターアイデンティティーリソースに自動的にラベルを付けます。

  • 再インストールの進捗を監視します。

    • クラスターのプロビジョニング中に、インストールマニフェストを使用する Operator は、新しく生成されたマニフェストを使用してクラスターをプロビジョニングします。
    • 注記: Image Based Install Operator は、保存されたクラスターアイデンティティーデータを検出し、設定 ISO イメージに組み込みます。

  • クラスターがプロビジョニングされており、利用可能であることを確認します。

    • 障害が発生したハードウェアに関連付けられている kubeconfig を使用して、再インストールされたスポーククラスターにアクセスします。

詳細は、SiteConfig Operator を使用したクラスターの再インストール (テクノロジープレビュー) を参照してください。

2.7.7.2. 前提条件
リンクのコピー

  • クラスターは、イメージベースのインストールプロビジョニング方法を使用してインストールされたシングルノードの OpenShift クラスターである。
  • 障害のあるハードウェアを、同じ仕様を持つ新しいノードに置き換える。

2.7.7.3. Image-Based Break/Fix クラスターの再インストールの開始
リンクのコピー

Image-Based Break/Fix クラスター再インストールを開始するには、spec.reinstall.generation フィールドを設定し、変更されたハードウェア情報を使用して spec.nodes オブジェクトを更新して、ClusterInstance リソースを更新します。

  1. spec.reinstall.generation フィールドを変更し、ClusterInstance リソース内の spec.nodes オブジェクトを新しいノードの詳細で更新します。 

    apiVersion: siteconfig.open-cluster-management.io/v1alpha1
kind: `ClusterInstance`
metadata:
  name: clusterinstance-example
  namespace: some-namespace
spec:
  ...
  reinstall:
    generation: "unique-generation-string"
    preservationMode: "ClusterIdentity"
  nodes:
    - bmcAddress: <new-node-bmcAddress>
      bootMACAddress: <new-node-bootMACAddress>
      rootDeviceHints: <new-node-rootDeviceHints>
      nodeNetwork:
        interfaces:
          macAddress: <new-node-macAddress>
          ...
      ...
    Copy to Clipboard Toggle word wrap

  2. 変更を適用します。以下のオプションを参照してください。

    1. OpenShift GitOps ZTP を使用している場合は、Git リポジトリーにプッシュし、Argo CD が変更を同期するまで待ちます。
    2. 変更を手動で適用するには、ハブクラスターで次のコマンドを実行します。 
    oc apply -f clusterinstance-example.yaml
    Copy to Clipboard Toggle word wrap
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat