19.10. Topology Aware Lifecycle Manager を使用したマネージドクラスターの更新


Topology Aware Lifecycle Manager (TALM) を使用して、OpenShift Container Platform マネージドクラスターのソフトウェアライフサイクルを管理できます。TALM は Red Hat Advanced Cluster Management (RHACM) ポリシーを使用して、ターゲットクラスター上で変更を実行します。

重要

Topology Aware Lifecycle Manager は、テクノロジープレビュー機能のみとなります。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

関連情報

19.10.1. 切断された環境でのクラスターの更新

GitOps ZTP および Topology Aware Lifecycle Manager (TALM) を使用してデプロイした管理対象クラスターおよびマネージドクラスターの Operator をアップグレードできます。

19.10.1.1. 環境の設定

TALM は、プラットフォームと Operator の更新の両方を実行できます。

TALM を使用して非接続クラスターを更新する前に、ミラーレジストリーで更新するプラットフォームイメージおよび Operator イメージの両方をミラーリングする必要があります。イメージをミラーリングするには以下の手順を実行します。

  • プラットフォームの更新では、以下の手順を実行する必要があります。

    1. 必要な OpenShift Container Platform イメージリポジトリーをミラーリングします。追加リソースにリンクされている OpenShift Container Platform イメージリポジトリーのミラーリング手順に従って、目的のプラットフォームイメージがミラーリングされていることを確認してください。imageContentSources.yaml ファイルの imageContentSources セクションの内容を保存します。

      出力例

      imageContentSources:
       - mirrors:
         - mirror-ocp-registry.ibmcloud.io.cpak:5000/openshift-release-dev/openshift4
         source: quay.io/openshift-release-dev/ocp-release
       - mirrors:
         - mirror-ocp-registry.ibmcloud.io.cpak:5000/openshift-release-dev/openshift4
         source: quay.io/openshift-release-dev/ocp-v4.0-art-dev

    2. ミラーリングされた目的のプラットフォーム イメージのイメージ シグネチャーを保存します。プラットフォームの更新のために、イメージ署名を PolicyGenTemplate CR に追加する必要があります。イメージ署名を取得するには、次の手順を実行します。

      1. 以下のコマンドを実行して、目的の OpenShift Container Platform タグを指定します。

        $ OCP_RELEASE_NUMBER=<release_version>
      2. 次のコマンドを実行して、サーバーのアーキテクチャーを指定します。

        $ ARCHITECTURE=<server_architecture>
      3. 次のコマンドを実行して、Quay からリリースイメージダイジェストを取得します。

        $ DIGEST="$(oc adm release info quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_NUMBER}-${ARCHITECTURE} | sed -n 's/Pull From: .*@//p')"
      4. 次のコマンドを実行して、ダイジェストアルゴリズムを設定します。

        $ DIGEST_ALGO="${DIGEST%%:*}"
      5. 次のコマンドを実行して、ダイジェスト署名を設定します。

        $ DIGEST_ENCODED="${DIGEST#*:}"
      6. 次のコマンドを実行して、mirror.openshift.com Web サイトからイメージ署名を取得します。

        $ SIGNATURE_BASE64=$(curl -s "https://mirror.openshift.com/pub/openshift-v4/signatures/openshift/release/${DIGEST_ALGO}=${DIGEST_ENCODED}/signature-1" | base64 -w0 && echo)
      7. 以下のコマンドを実行して、イメージ署名を checksum-<OCP_RELEASE_NUMBER>.yaml ファイルに保存します。

        $ cat >checksum-${OCP_RELEASE_NUMBER}.yaml <<EOF
        ${DIGEST_ALGO}-${DIGEST_ENCODED}: ${SIGNATURE_BASE64}
        EOF
    3. 更新グラフを準備します。更新グラフを準備するオプションは 2 つあります。

      1. OpenShift Update Service を使用します。

        ハブクラスターでグラフを設定する方法の詳細については、 OpenShift Update Service の Operator のデプロイ および グラフデータ init コンテナーのビルド を参照してください。

      2. アップストリームグラフのローカルコピーを作成します。マネージドクラスターにアクセスできる非接続環境の http または https サーバーで更新グラフをホストします。更新グラフをダウンロードするには、以下のコマンドを使用します。

        $ curl -s https://api.openshift.com/api/upgrades_info/v1/graph?channel=stable-4.10 -o ~/upgrade-graph_stable-4.10
  • Operator の更新については、以下のタスクを実行する必要があります。

    • Operator カタログをミラーリングします。切断されたクラスターで使用する Operator カタログのミラーリングセクションの手順に従って、目的の Operator イメージがミラーリングされていることを確認します。

関連情報

19.10.1.2. プラットフォームの更新の実行

TALM を使用してプラットフォームの更新を実行できます。

前提条件

  • Topology Aware Lifecycle Manager (TALM) をインストールします。
  • ZTP を最新バージョンに更新します。
  • ZTP を使用して 1 つ以上のマネージドクラスターをプロビジョニングします。
  • 目的のイメージ リポジトリーをミラーリングします。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • ハブクラスターで RHACM ポリシーを作成します。

手順

  1. プラットフォーム更新用の PolicyGenTemplate CR を作成します。

    1. 次の PolicyGenTemplate CR の内容を du-upgrade.yaml ファイルに保存します。

      プラットフォーム更新の PolicyGenTemplate の例

      apiVersion: ran.openshift.io/v1
      kind: PolicyGenTemplate
      metadata:
        name: "du-upgrade"
        namespace: "ztp-group-du-sno"
      spec:
        bindingRules:
          group-du-sno: ""
        mcp: "master"
        remediationAction: inform
        sourceFiles:
          - fileName: ImageSignature.yaml 1
            policyName: "platform-upgrade-prep"
            binaryData:
              ${DIGEST_ALGO}-${DIGEST_ENCODED}: ${SIGNATURE_BASE64} 2
          - fileName: DisconnectedICSP.yaml
            policyName: "platform-upgrade-prep"
            metadata:
              name: disconnected-internal-icsp-for-ocp
            spec:
              repositoryDigestMirrors: 3
                - mirrors:
                  - quay-intern.example.com/ocp4/openshift-release-dev
                  source: quay.io/openshift-release-dev/ocp-release
                - mirrors:
                  - quay-intern.example.com/ocp4/openshift-release-dev
                  source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
          - fileName: ClusterVersion.yaml 4
            policyName: "platform-upgrade-prep"
            metadata:
              name: version
              annotations:
                ran.openshift.io/ztp-deploy-wave: "1"
            spec:
              channel: "stable-4.10"
              upstream: http://upgrade.example.com/images/upgrade-graph_stable-4.10
          - fileName: ClusterVersion.yaml 5
            policyName: "platform-upgrade"
            metadata:
              name: version
            spec:
              channel: "stable-4.10"
              upstream: http://upgrade.example.com/images/upgrade-graph_stable-4.10
              desiredUpdate:
                version: 4.10.4
            status:
              history:
                - version: 4.10.4
                  state: "Completed"

      1
      ConfigMap CR には、更新先の目的のリリースイメージの署名が含まれています。
      2
      目的の OpenShift Container Platform リリースのイメージ署名を表示します。環境のセットアップセクションの手順に従って保存した checksum-${OCP_RELASE_NUMBER}.yaml ファイルから署名を取得します。
      3
      目的の OpenShift Container Platform イメージを含むミラーリポジトリーを表示します。環境のセットアップセクションの手順に従って保存した imageContentSources.yaml ファイルからミラーを取得します。
      4
      アップストリームを更新する ClusterVersion CR を表示します。
      5
      更新をトリガーする ClusterVersion CR を示します。イメージの事前キャッシュには、channelupstream、および desiredVersion フィールドがすべて必要です。

      PolicyGenTemplate CR は 2 つのポリシーを生成します。

      • du-upgrade-platform-upgrade-prep ポリシーは、プラットフォームの更新の準備作業を行います。目的のリリースイメージシグネチャーの ConfigMap CR を作成し、ミラー化されたリリースイメージリポジトリーのイメージ コンテンツソースを作成し、目的の更新チャネルと切断された環境でマネージドクラスターが到達可能な更新グラフを使用してクラスターバージョンを更新します。
      • du-upgrade-platform-upgrade ポリシーは、プラットフォームのアップグレードを実行するために使用されます。
    2. PolicyGenTemplate CR の ZTP Git リポジトリーにある kustomization.yaml ファイルに du-upgrade.yaml ファイルの内容を追加し、変更を Git リポジトリーにプッシュします。

      ArgoCD は Git リポジトリーから変更を取得し、ハブクラスターでポリシーを生成します。

    3. 以下のコマンドを実行して、作成したポリシーを確認します。

      $ oc get policies -A | grep platform-upgrade
  2. TALM でプラットフォームの更新を開始する前に、必要な更新リソースを適用します。

    1. 次の例に示すように、du-upgrade-platform-upgrade-prep ポリシーとターゲットマネージドクラスターを使用して platform-upgrade-prep ClusterUpgradeGroup CR の内容を cgu-platform-upgrade-prep.yml ファイルに保存します。

      apiVersion: ran.openshift.io/v1alpha1
      kind: ClusterGroupUpgrade
      metadata:
        name: cgu-platform-upgrade-prep
        namespace: default
      spec:
        managedPolicies:
        - du-upgrade-platform-upgrade-prep
        clusters:
        - spoke1
        remediationStrategy:
          maxConcurrency: 1
        enable: true
    2. 次のコマンドを実行して、ポリシーをハブ クラスターに適用します。

      $ oc apply -f cgu-platform-upgrade-prep.yml
    3. 更新プロセスを監視します。完了したら、次のコマンドを実行して、ポリシーが準拠していることを確認します。

      $ oc get policies --all-namespaces
  3. spec.enable フィールドを false に設定して、プラットフォーム更新用の ClusterGroupUpdate CR を作成します。

    1. 次の例に示すように、du-upgrade-platform-upgrade ポリシーとターゲットクラスターを含むプラットフォーム更新 ClusterGroupUpdate CR の内容を cgu-platform-upgrade.yml ファイルに保存します。

      apiVersion: ran.openshift.io/v1alpha1
      kind: ClusterGroupUpgrade
      metadata:
        name: cgu-platform-upgrade
        namespace: default
      spec:
        managedPolicies:
        - du-upgrade-platform-upgrade
        preCaching: false
        clusters:
        - spoke1
        remediationStrategy:
          maxConcurrency: 1
        enable: false
    2. 次のコマンドを実行して、ClusterGroupUpdate CR をハブクラスターに適用します。

      $ oc apply -f cgu-platform-upgrade.yml
  4. オプション: プラットフォームの更新用にイメージを事前キャッシュします。

    1. 次のコマンドを実行して、ClusterGroupUpdate CR で事前キャッシュを有効にします。

      $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \
      --patch '{"spec":{"preCaching": true}}' --type=merge
    2. 更新プロセスを監視し、事前キャッシュが完了するまで待ちます。ハブクラスターで次のコマンドを実行して、事前キャッシュの状態を確認します。

      $ oc get cgu cgu-platform-upgrade -o jsonpath='{.status.precaching.status}'
  5. プラットフォームの更新を開始します。

    1. 次のコマンドを実行して、cgu-platform-upgrade ポリシーを有効にし、事前キャッシュを無効にします。

      $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \
      --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
    2. プロセスを監視します。完了したら、次のコマンドを実行して、ポリシーが準拠していることを確認します。

      $ oc get policies --all-namespaces

関連情報

  • 切断された環境でのイメージのミラーリングに関する詳細は、非接続環境の準備 を参照してください。

19.10.1.3. Operator 更新の実行

TALM で Operator の更新を実行できます。

前提条件

  • Topology Aware Lifecycle Manager (TALM) をインストールします。
  • ZTP を最新バージョンに更新します。
  • ZTP を使用して 1 つ以上のマネージドクラスターをプロビジョニングします。
  • 目的のインデックスイメージ、バンドルイメージ、およびバンドルイメージで参照されるすべての Operator イメージをミラーリングします。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • ハブクラスターで RHACM ポリシーを作成します。

手順

  1. Operator の更新用に PolicyGenTemplate CR を更新します。

    1. du-upgrade.yaml ファイルの次の追加コンテンツで du-upgradePolicyGenTemplate CR を更新します。

      apiVersion: ran.openshift.io/v1
      kind: PolicyGenTemplate
      metadata:
        name: "du-upgrade"
        namespace: "ztp-group-du-sno"
      spec:
        bindingRules:
          group-du-sno: ""
        mcp: "master"
        remediationAction: inform
        sourceFiles:
          - fileName: DefaultCatsrc.yaml
            remediationAction: inform
            policyName: "operator-catsrc-policy"
            metadata:
              name: redhat-operators
            spec:
              displayName: Red Hat Operators Catalog
              image: registry.example.com:5000/olm/redhat-operators:v4.10 1
              updateStrategy: 2
                registryPoll:
                  interval: 1h
      1
      インデックスイメージ URL には、必要な Operator イメージが含まれます。インデックスイメージが常に同じイメージ名とタグにプッシュされている場合、この変更は必要ありません。
      2
      Operator Lifecycle Manager (OLM) が新しい Operator バージョンのインデックスイメージをポーリングする頻度を registryPoll.interval フィールドで設定します。y-stream および z-stream Operator の更新のために新しいインデックスイメージタグが常にプッシュされる場合、この変更は必要ありません。registryPoll.interval フィールドを短い間隔に設定して更新を促進できますが、間隔を短くすると計算負荷が増加します。これに対処するために、更新が完了したら、registryPoll.interval をデフォルト値に戻すことができます。
    2. この更新により、1 つのポリシー du-upgrade-operator-catsrc-policy が生成され、必要な Operator イメージを含む新しいインデックスイメージで redhat-operators カタログソースが更新されます。

      注記

      Operator にイメージの事前キャッシュを使用する必要があり、redhat-operators 以外の別のカタログソースからの Operator がある場合は、次のタスクを実行する必要があります。

      • 別のカタログソースの新しいインデックスイメージまたはレジストリーポーリング間隔の更新を使用して、別のカタログソースポリシーを準備します。
      • 異なるカタログソースからの目的の Operator に対して個別のサブスクリプションポリシーを準備します。

      たとえば、目的の SRIOV-FEC Operator は、certified-operators カタログソースで入手できます。カタログソースと Operator サブスクリプションを更新するには、次の内容を追加して、2 つのポリシー du-upgrade-fec-catsrc-policydu-upgrade-subscriptions-fec-policy を生成します。

      apiVersion: ran.openshift.io/v1
      kind: PolicyGenTemplate
      metadata:
        name: "du-upgrade"
        namespace: "ztp-group-du-sno"
      spec:
        bindingRules:
          group-du-sno: ""
        mcp: "master"
        remediationAction: inform
        sourceFiles:
             …
          - fileName: DefaultCatsrc.yaml
            remediationAction: inform
            policyName: "fec-catsrc-policy"
            metadata:
              name: certified-operators
            spec:
              displayName: Intel SRIOV-FEC Operator
              image: registry.example.com:5000/olm/far-edge-sriov-fec:v4.10
              updateStrategy:
                registryPoll:
                  interval: 10m
          - fileName: AcceleratorsSubscription.yaml
            policyName: "subscriptions-fec-policy"
            spec:
              channel: "stable"
              source: certified-operators
    3. 共通の PolicyGenTemplate CR に指定されたサブスクリプションチャネルが存在する場合は、それらを削除します。ZTP イメージのデフォルトのサブスクリプションチャネルが更新に使用されます。

      注記

      ZTP 4.10 で適用される Operator のデフォルトチャネルは stable ですが、performance-addon-operator を除きます。PAO のデフォルトのチャネルは 4.10 です。共通の PolicyGenTemplate CR でデフォルトのチャネルを指定することもできます。

    4. PolicyGenTemplate CR 更新を ZTP Git リポジトリーにプッシュします。

      ArgoCD は Git リポジトリーから変更を取得し、ハブクラスターでポリシーを生成します。

    5. 以下のコマンドを実行して、作成したポリシーを確認します。

      $ oc get policies -A | grep -E "catsrc-policy|subscription"
  2. Operator の更新を開始する前に、必要なカタログソースの更新を適用します。

    1. operator-upgrade-prep という名前の ClusterGroupUpgrade CR の内容をカタログソースポリシーと共に、ターゲットマネージドクラスターの内容を cgu-operator-upgrade-prep.yml ファイルに保存します。

      apiVersion: ran.openshift.io/v1alpha1
      kind: ClusterGroupUpgrade
      metadata:
        name: cgu-operator-upgrade-prep
        namespace: default
      spec:
        clusters:
        - spoke1
        enable: true
        managedPolicies:
        - du-upgrade-operator-catsrc-policy
        remediationStrategy:
          maxConcurrency: 1
    2. 次のコマンドを実行して、ポリシーをハブ クラスターに適用します。

      $ oc apply -f cgu-operator-upgrade-prep.yml
    3. 更新プロセスを監視します。完了したら、次のコマンドを実行して、ポリシーが準拠していることを確認します。

      $ oc get policies -A | grep -E "catsrc-policy"
  3. spec.enable フィールドを false に設定して、Operator 更新の ClusterGroupUpgrade CR を作成します。

    1. 以下の例のように、Operator 更新 ClusterGroupUpgrade CR の内容を du-upgrade-operator-catsrc-policy ポリシーで保存して、共通の PolicyGenTemplate およびターゲットクラスターで作成されたサブスクリプションポリシーを cgu-operator-upgrade.yml ファイルに保存します。

      apiVersion: ran.openshift.io/v1alpha1
      kind: ClusterGroupUpgrade
      metadata:
        name: cgu-operator-upgrade
        namespace: default
      spec:
        managedPolicies:
        - du-upgrade-operator-catsrc-policy 1
        - common-subscriptions-policy 2
        preCaching: false
        clusters:
        - spoke1
        remediationStrategy:
          maxConcurrency: 1
        enable: false
      1
      このポリシーは、カタログソースから Operator イメージを取得するために、イメージの事前キャッシュ機能で必要になります。
      2
      ポリシーには Operator サブスクリプションが含まれます。ZTP を 4.9 から 4.10 にアップグレードするに従って ZTP を 4.9 から 4.10 にアップグレードした場合、すべての Operator サブスクリプションは common-subscriptions-policy ポリシーにグループ化されます。
      注記

      1 つの ClusterGroupUpgrade CR は、ClusterGroupUpgrade CR に含まれる 1 つのカタログソースからサブスクリプションポリシーで定義される必要な Operator のイメージのみを事前キャッシュできます。SRIOV-FEC Operator の例のように、目的の Operator が異なるカタログソースからのものである場合、別の ClusterGroupUpgrade CR を du-upgrade-fec-catsrc-policy および du-upgrade-subscriptions-fec-policy ポリシーで作成する必要があります。SRIOV-FEC Operator イメージの事前キャッシュと更新。

    2. 次のコマンドを実行して、ClusterGroupUpgrade CR をハブクラスターに適用します。

      $ oc apply -f cgu-operator-upgrade.yml
  4. オプション: Operator の更新用にイメージを事前キャッシュします。

    1. イメージの事前キャッシュを開始する前に、以下のコマンドを実行して、サブスクリプションポリシーがこの時点で NonCompliant であることを確認します。

      $ oc get policy common-subscriptions-policy -n <policy_namespace>

      出力例

      NAME                          REMEDIATION ACTION   COMPLIANCE STATE     AGE
      common-subscriptions-policy   inform               NonCompliant         27d

    2. 以下のコマンドを実行して、ClusterGroupUpgrade CR で事前キャッシュを有効にします。

      $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \
      --patch '{"spec":{"preCaching": true}}' --type=merge
    3. プロセスを監視し、事前キャッシュが完了するまで待ちます。マネージドクラスターで次のコマンドを実行して、事前キャッシュの状態を確認します。

      $ oc get cgu cgu-operator-upgrade -o jsonpath='{.status.precaching.status}'
    4. 以下のコマンドを実行して、更新を開始する前に事前キャッシュが完了したかどうかを確認します。

      $ oc get cgu -n default cgu-operator-upgrade -ojsonpath='{.status.conditions}' | jq

      出力例

      [
          {
            "lastTransitionTime": "2022-03-08T20:49:08.000Z",
            "message": "The ClusterGroupUpgrade CR is not enabled",
            "reason": "UpgradeNotStarted",
            "status": "False",
            "type": "Ready"
          },
          {
            "lastTransitionTime": "2022-03-08T20:55:30.000Z",
            "message": "Precaching is completed",
            "reason": "PrecachingCompleted",
            "status": "True",
            "type": "PrecachingDone"
          }
      ]

  5. Operator の更新を開始します。

    1. 以下のコマンドを実行して cgu-operator-upgrade ClusterGroupUpgrade CR を有効にし、事前キャッシュを無効にして Operator の更新を開始します。

      $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \
      --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
    2. プロセスを監視します。完了したら、次のコマンドを実行して、ポリシーが準拠していることを確認します。

      $ oc get policies --all-namespaces

関連情報

19.10.1.4. プラットフォームと Operator の更新を一緒に実行する

プラットフォームと Operator の更新を同時に実行できます。

前提条件

  • Topology Aware Lifecycle Manager (TALM) をインストールします。
  • ZTP を最新バージョンに更新します。
  • ZTP を使用して 1 つ以上のマネージドクラスターをプロビジョニングします。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • ハブクラスターで RHACM ポリシーを作成します。

手順

  1. プラットフォーム更新の実行および Operator 更新の実行セクションで説明されている手順に従って、更新用の PolicyGenTemplate CR を作成します。
  2. プラットフォームの準備作業と Operator の更新を適用します。

    1. プラットフォームの更新の準備作業、カタログ ソースの更新、およびターゲット クラスターのポリシーを 含む ClusterGroupUpgrade CR の内容を cgu-platform-operator-upgrade-prep.yml ファイルに保存します。次に例を示します。

      apiVersion: ran.openshift.io/v1alpha1
      kind: ClusterGroupUpgrade
      metadata:
        name: cgu-platform-operator-upgrade-prep
        namespace: default
      spec:
        managedPolicies:
        - du-upgrade-platform-upgrade-prep
        - du-upgrade-operator-catsrc-policy
        clusterSelector:
        - group-du-sno
        remediationStrategy:
          maxConcurrency: 10
        enable: true
    2. 次のコマンドを実行して、cgu-platform-operator-upgrade-prep.yml ファイルをハブクラスターに適用します。

      $ oc apply -f cgu-platform-operator-upgrade-prep.yml
    3. プロセスを監視します。完了したら、次のコマンドを実行して、ポリシーが準拠していることを確認します。

      $ oc get policies --all-namespaces
  3. プラットフォーム用の ClusterGroupUpdate CR と、spec.enable フィールドを false に設定した Operator 更新を作成します。

    1. 次の例に示すように、ポリシーとターゲットクラスターを含むプラットフォームと Operator の更新 ClusterGroupUpdate CR の内容を cgu-platform-operator-upgrade.yml ファイルに保存します。

      apiVersion: ran.openshift.io/v1alpha1
      kind: ClusterGroupUpgrade
      metadata:
        name: cgu-du-upgrade
        namespace: default
      spec:
        managedPolicies:
        - du-upgrade-platform-upgrade 1
        - du-upgrade-operator-catsrc-policy 2
        - common-subscriptions-policy 3
        preCaching: true
        clusterSelector:
        - group-du-sno
        remediationStrategy:
          maxConcurrency: 1
        enable: false
      1
      これはプラットフォーム更新ポリシーです。
      2
      これは、更新される Operator のカタログソース情報が含まれるポリシーです。事前キャッシュ機能がマネージドクラスターにダウンロードする Operator イメージを決定するために必要です。
      3
      これは、Operator を更新するためのポリシーです。
    2. 次のコマンドを実行して、cgu-platform-operator-upgrade.yml ファイルをハブクラスターに適用します。

      $ oc apply -f cgu-platform-operator-upgrade.yml
  4. オプション: プラットフォームおよび Operator の更新用にイメージを事前キャッシュします。

    1. 以下のコマンドを実行して、ClusterGroupUpgrade CR で事前キャッシュを有効にします。

      $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \
      --patch '{"spec":{"preCaching": true}}' --type=merge
    2. 更新プロセスを監視し、事前キャッシュが完了するまで待ちます。マネージドクラスターで次のコマンドを実行して、事前キャッシュの状態を確認します。

      $ oc get jobs,pods -n openshift-talm-pre-cache
    3. 以下のコマンドを実行して、更新を開始する前に事前キャッシュが完了したかどうかを確認します。

      $ oc get cgu cgu-du-upgrade -ojsonpath='{.status.conditions}'
  5. プラットフォームおよび Operator の更新を開始します。

    1. 以下のコマンドを実行して、cgu-du-upgrade ClusterGroupUpgrade CR がプラットフォームと Operator の更新を開始します。

      $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \
      --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
    2. プロセスを監視します。完了したら、次のコマンドを実行して、ポリシーが準拠していることを確認します。

      $ oc get policies --all-namespaces
      注記

      プラットフォームおよび Operator 更新の CR は、設定を spec.enable: true に設定して最初から作成できます。この場合、更新は事前キャッシュが完了した直後に開始し、CR を手動で有効にする必要はありません。

      事前キャッシュと更新の両方で、ポリシー、配置バインディング、配置ルール、マネージドクラスターアクション、マネージドクラスタービューなどの追加リソースが作成され、手順を完了することができます。afterCompletion.deleteObjects フィールドを true に設定すると、更新の完了後にこれらのリソースがすべて削除されます。

19.10.1.5. デプロイされたクラスターから Performance Addon Operator サブスクリプションを削除する

以前のバージョンの OpenShift Container Platform では、Performance Addon Operator はアプリケーションの自動低レイテンシーパフォーマンスチューニングを提供していました。OpenShift Container Platform 4.11 以降では、これらの機能は Node Tuning Operator の一部です。

OpenShift Container Platform 4.11 以降を実行しているクラスターに Performance Addon Operator をインストールしないでください。OpenShift Container Platform 4.11 以降にアップグレードすると、Node Tuning Operator は Performance Addon Operator を自動的に削除します。

注記

Operator の再インストールを防ぐために、Performance Addon Operator サブスクリプションを作成するポリシーを削除する必要があります。

参照 DU プロファイルには、PolicyGenTemplate CR common-ranGen.yaml に Performance Addon Operator が含まれています。デプロイされたマネージドクラスターからサブスクリプションを削除するには、common-ranGen.yaml を更新する必要があります。

注記

Performance Addon Operator 4.10.3-5 以降を OpenShift Container Platform 4.11 以降にインストールする場合、Performance Addon Operator はクラスターのバージョンを検出し、Node Tuning Operator 機能との干渉を避けるために自動的に休止状態になります。ただし、最高のパフォーマンスを確保するには、OpenShift Container Platform 4.11 クラスターから Performance Addon Operator を削除してください。

前提条件

  • カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、Argo CD のソースリポジトリーとして定義されている必要があります。
  • OpenShift Container Platform 4.11 以降に更新します。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. common-ranGen.yaml ファイル の Performance Addon Operator namespace、Operator グループ、およびサブスクリプションの ComplianceTypemustnothave に変更します。

     -  fileName: PaoSubscriptionNS.yaml
        policyName: "subscriptions-policy"
        complianceType: mustnothave
     -  fileName: PaoSubscriptionOperGroup.yaml
        policyName: "subscriptions-policy"
        complianceType: mustnothave
     -  fileName: PaoSubscription.yaml
        policyName: "subscriptions-policy"
        complianceType: mustnothave
  2. 変更をカスタムサイトリポジトリーにマージし、ArgoCD アプリケーションが変更をハブクラスターに同期するのを待ちます。common-subscriptions-policy ポリシーのステータスが Non-Compliant に変わります。
  3. Topology Aware Lifecycle Manager を使用して、ターゲットクラスターに変更を適用します。設定変更のロールアウトの詳細については、「関連情報」セクションを参照してください。
  4. プロセスを監視します。ターゲットクラスターの common-subscriptions-policy ポリシーのステータスが Compliant の場合、Performance Addon Operator はクラスターから削除されています。次のコマンドを実行して、common-subscriptions-policy のステータスを取得します。

    $ oc get policy -n ztp-common common-subscriptions-policy
  5. common-ranGen.yaml ファイルの .spec.sourceFiles から Performance Addon Operator namespace、Operator グループ、およびサブスクリプション CR を削除します。
  6. 変更をカスタムサイトリポジトリーにマージし、ArgoCD アプリケーションが変更をハブクラスターに同期するのを待ちます。ポリシーは準拠したままです。

19.10.2. ZTP の自動作成された ClusterGroupUpgrade CR について

TALM には、ハブ クラスター上の ManagedCluster CR の Ready 状態を監視し、ZTP (ゼロ タッチ プロビジョニング) 用の ClusterGroupUpgrade CR を作成する ManagedClusterForCGU と呼ばれるコントローラーがあります。

ztp-done ラベルが適用されていない Ready 状態の管理対象クラスターの場合、ManagedClusterForCGU コントローラーは、ZTP プロセス中に作成された関連する RHACM ポリシーを使用して、ztp-install namespace に ClusterGroupUpgrade CR を自動的に作成します。次に TALM は自動作成された ClusterGroupUpgrade CR にリスト表示されている設定ポリシーのセットを修正し、設定 CR をマネージドクラスターにプッシュします。

注記

クラスターが Ready になったときにマネージドクラスターにバインドされたポリシーがない場合、ClusterGroupUpgrade CR は作成されません。

ZTP の自動作成された ClusterGroupUpgrade CR の例

apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  generation: 1
  name: spoke1
  namespace: ztp-install
  ownerReferences:
  - apiVersion: cluster.open-cluster-management.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: ManagedCluster
    name: spoke1
    uid: 98fdb9b2-51ee-4ee7-8f57-a84f7f35b9d5
  resourceVersion: "46666836"
  uid: b8be9cd2-764f-4a62-87d6-6b767852c7da
spec:
  actions:
    afterCompletion:
      addClusterLabels:
        ztp-done: "" 1
      deleteClusterLabels:
        ztp-running: ""
      deleteObjects: true
    beforeEnable:
      addClusterLabels:
        ztp-running: "" 2
  clusters:
  - spoke1
  enable: true
  managedPolicies:
  - common-spoke1-config-policy
  - common-spoke1-subscriptions-policy
  - group-spoke1-config-policy
  - spoke1-config-policy
  - group-spoke1-validator-du-policy
  preCaching: false
  remediationStrategy:
    maxConcurrency: 1
    timeout: 240

1
TALM がクラスター設定を完了する際にマネージドクラスターに適用されます。
2
TALM が設定ポリシーのデプロイを開始するときにマネージドクラスターに適用されます。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.