検索

10.3. PolicyGenTemplate リソースと TALM を使用して、非接続環境で管理対象クラスターを更新する

download PDF

Topology Aware Lifecycle Manager (TALM) を使用すると、GitOps Zero Touch Provisioning (ZTP) と Topology Aware Lifecycle Manager (TALM) を使用してデプロイした管理対象クラスターのソフトウェアライフサイクルを管理できます。TALM は、Red Hat Advanced Cluster Management (RHACM) PolicyGenTemplate ポリシーを使用して、ターゲットクラスターに適用される変更を管理および制御します。

重要

PolicyGenTemplate CR を使用してポリシーを管理および管理対象クラスターにデプロイすることは、今後の OpenShift Container Platform リリースでは非推奨になります。同等の機能および改善された機能は、Red Hat Advanced Cluster Management (RHACM) および PolicyGenerator CR を使用することで利用できます。

PolicyGenerator リソースの詳細は、RHACM Policy Generator の ドキュメントを参照してください。

10.3.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=<cluster_architecture> 1
        1
        x86_64aarch64s390x、または ppc64le など、クラスターのアーキテクチャーを指定します。
      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.16 -o ~/upgrade-graph_stable-4.16
  • Operator の更新については、以下のタスクを実行する必要があります。

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

10.3.2. PolicyGenTemplate CR を使用したプラットフォーム更新の実行

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

前提条件

  • Topology Aware Lifecycle Manager (TALM) をインストールします。
  • GitOps Zero Touch Provisioning (ZTP) を最新バージョンに更新します。
  • GitOps 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"
            metadata:
              name: version
            spec:
              channel: "stable-4.16"
              upstream: http://upgrade.example.com/images/upgrade-graph_stable-4.16
              desiredUpdate:
                version: 4.16.4
            status:
              history:
                - version: 4.16.4
                  state: "Completed"

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

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

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

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

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

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

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

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

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

    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}'
  4. プラットフォームの更新を開始します。

    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

10.3.3. PolicyGenTemplate CR を使用した Operator 更新の実行

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

前提条件

  • Topology Aware Lifecycle Manager (TALM) をインストールします。
  • GitOps Zero Touch Provisioning (ZTP) を最新バージョンに更新します。
  • GitOps 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.16 1
              updateStrategy: 2
                registryPoll:
                  interval: 1h
            status:
              connectionState:
                  lastObservedState: READY 3
      1
      インデックスイメージ URL には、必要な Operator イメージが含まれます。インデックスイメージが常に同じイメージ名とタグにプッシュされている場合、この変更は必要ありません。
      2
      Operator Lifecycle Manager (OLM) が新しい Operator バージョンのインデックスイメージをポーリングする頻度を registryPoll.interval フィールドで設定します。y-stream および z-stream Operator の更新のために新しいインデックスイメージタグが常にプッシュされる場合、この変更は必要ありません。registryPoll.interval フィールドを短い間隔に設定して更新を促進できますが、間隔を短くすると計算負荷が増加します。これに対処するために、更新が完了したら、registryPoll.interval をデフォルト値に戻すことができます。
      3
      カタログ接続が最後に監視された状態。READY 値は、CatalogSource ポリシーの準備が整っていることを保証し、インデックス Pod がプルされ、実行中であることを示します。このように、TALM は最新のポリシー準拠状態に基づいて Operator をアップグレードします。
    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 に指定されたサブスクリプションチャネルが存在する場合は、それらを削除します。GItOps ZTP イメージのデフォルトサブスクリプションチャネルが更新に使用されます。

      注記

      GItOps ZTP 4.15 で適用される Operator のデフォルトチャネルは、performance-addon-operator を除きすべて stable です。OpenShift Container Platform 4.11 以降、performance-addon-operator 機能は node-tuning-operator に移動されました。4.10 リリースの場合、PAO のデフォルトチャネルは v4.10 です。共通の PolicyGenTemplate CR でデフォルトのチャネルを指定することもできます。

    4. PolicyGenTemplate CR の更新を GitOps 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 サブスクリプションが含まれます。参照 PolicyGenTemplates の構造と内容に従っている場合、すべての 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

10.3.4. PolicyGenTemplate CR による Operator 更新の失敗のトラブルシューティング

一部のシナリオでは、ポリシーのコンプライアンス状態が古いため、Topology Aware Lifecycle Manager (TALM) が Operator の更新を見逃す可能性があります。

カタログソースの更新後に Operator Lifecycle Manager (OLM) がサブスクリプションステータスを更新すると、時間がかかります。TALM が修復が必要かどうかを判断する間、サブスクリプションポリシーのステータスは準拠していると表示される場合があります。その結果、サブスクリプションポリシーで指定された Operator はアップグレードされません。

このシナリオを回避するには、別のカタログソース設定を PolicyGenTemplate に追加し、更新が必要な Operator のサブスクリプションでこの設定を指定します。

手順

  1. PolicyGenTemplate リソースにカタログソース設定を追加します。

    - 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:v{product-version}
            updateStrategy:
              registryPoll:
                interval: 1h
          status:
            connectionState:
                lastObservedState: READY
    - fileName: DefaultCatsrc.yaml
          remediationAction: inform
          policyName: "operator-catsrc-policy"
          metadata:
            name: redhat-operators-v2 1
          spec:
            displayName: Red Hat Operators Catalog v2 2
            image: registry.example.com:5000/olredhat-operators:<version> 3
            updateStrategy:
              registryPoll:
                interval: 1h
          status:
            connectionState:
                lastObservedState: READY
    1
    新しい設定の名前を更新します。
    2
    新しい設定の表示名を更新します。
    3
    インデックスイメージの URL を更新します。この fileName.spec.image フィールドは、DefaultCatsrc.yaml ファイル内の設定をオーバーライドします。
  2. 更新が必要な Operator の新しい設定を指すように Subscription リソースを更新します。

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: operator-subscription
      namespace: operator-namspace
    # ...
    spec:
      source: redhat-operators-v2 1
    # ...
    1
    PolicyGenTemplate リソースで定義した追加のカタログソース設定の名前を入力します。

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

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

前提条件

  • Topology Aware Lifecycle Manager (TALM) をインストールします。
  • GitOps Zero Touch Provisioning (ZTP) を最新バージョンに更新します。
  • GitOps 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 に設定すると、更新の完了後にこれらのリソースがすべて削除されます。

10.3.6. PolicyGenTemplate CR を使用してデプロイされたクラスターからパフォーマンスアドオン 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 アプリケーションが変更をハブクラスターに同期するのを待ちます。ポリシーは準拠したままです。

10.3.7. シングルノード OpenShift クラスター上の TALM を使用したユーザー指定のイメージの事前キャッシュ

アプリケーションをアップグレードする前に、アプリケーション固有のワークロードイメージを単一ノード OpenShift クラスターに事前キャッシュできます。

次のカスタムリソース (CR) を使用して、事前キャッシュジョブの設定オプションを指定できます。

  • PreCachingConfig CR
  • ClusterGroupUpgrade CR
注記

PreCachingConfig CR のフィールドはすべてオプションです。

PreCachingConfig CR の例

apiVersion: ran.openshift.io/v1alpha1
kind: PreCachingConfig
metadata:
  name: exampleconfig
  namespace: exampleconfig-ns
spec:
  overrides: 1
    platformImage: quay.io/openshift-release-dev/ocp-release@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e1ef
    operatorsIndexes:
      - registry.example.com:5000/custom-redhat-operators:1.0.0
    operatorsPackagesAndChannels:
      - local-storage-operator: stable
      - ptp-operator: stable
      - sriov-network-operator: stable
  spaceRequired: 30 Gi 2
  excludePrecachePatterns: 3
    - aws
    - vsphere
  additionalImages: 4
    - quay.io/exampleconfig/application1@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e1ef
    - quay.io/exampleconfig/application2@sha256:3d5800123dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47adfaef
    - quay.io/exampleconfig/applicationN@sha256:4fe1334adfafadsf987123adfffdaf1243340adfafdedga0991234afdadfsa09

1
デフォルトでは、TALM は、マネージドクラスターのポリシーから platformImageoperatorsIndexes、および operatorsPackagesAndChannels フィールドに自動的に値を設定します。これらのフィールドのデフォルトの TALM 派生値をオーバーライドする値を指定できます。
2
クラスター上で最低限必要なディスク容量を指定します。指定しない場合、TALM は OpenShift Container Platform イメージのデフォルト値を定義します。ディスク容量フィールドには、整数値とストレージユニットを含める必要があります。たとえば、40 GiB200 MB1 TiB です。
3
イメージ名の一致に基づいて事前キャッシュから除外するイメージを指定します。
4
事前キャッシュする追加イメージのリストを指定します。

PreCachingConfig CR 参照を使用した ClusterGroupUpgrade CR の例

apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu
spec:
  preCaching: true 1
  preCachingConfigRef:
    name: exampleconfig 2
    namespace: exampleconfig-ns 3

1
preCaching フィールドを true に設定すると、事前キャッシュジョブが有効になります。
2
preCachingConfigRef.name フィールドは、使用する PreCachingConfig CR を指定します。
3
preCachingConfigRef.namespace は、使用する PreCachingConfig CR の namespace を指定します。

10.3.7.1. 事前キャッシュ用のカスタムリソースの作成

PreCachingConfig CR は、ClusterGroupUpgrade CR の前または同時に作成する必要があります。

  1. 事前キャッシュする追加イメージのリストを使用して PreCachingConfig CR を作成します。

    apiVersion: ran.openshift.io/v1alpha1
    kind: PreCachingConfig
    metadata:
      name: exampleconfig
      namespace: default 1
    spec:
    [...]
      spaceRequired: 30Gi 2
      additionalImages:
        - quay.io/exampleconfig/application1@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e1ef
        - quay.io/exampleconfig/application2@sha256:3d5800123dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47adfaef
        - quay.io/exampleconfig/applicationN@sha256:4fe1334adfafadsf987123adfffdaf1243340adfafdedga0991234afdadfsa09
    1
    namespace は、ハブクラスターにアクセスできる必要があります。
    2
    事前にキャッシュされたイメージ用に十分なストレージ領域を確保するために、必要な最小ディスク領域フィールドを設定することを推奨します。
  2. preCaching フィールドを true に設定して ClusterGroupUpgrade CR を作成し、前の手順で作成した PreCachingConfig CR を指定します。

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu
      namespace: default
    spec:
      clusters:
      - sno1
      - sno2
      preCaching: true
      preCachingConfigRef:
      - name: exampleconfig
        namespace: default
      managedPolicies:
        - du-upgrade-platform-upgrade
        - du-upgrade-operator-catsrc-policy
        - common-subscriptions-policy
      remediationStrategy:
        timeout: 240
    警告

    クラスターにイメージをインストールすると、それらを変更したり削除したりすることはできません。

  3. イメージを事前キャッシュを開始する場合は、次のコマンドを実行して ClusterGroupUpgrade CR CR を適用します。

    $ oc apply -f cgu.yaml

TALM は ClusterGroupUpgrade CR を検証します。

この時点から、TALM 事前キャッシュワークフローを続行できます。

注記

すべてのサイトが同時に事前キャッシュされます。

検証

  1. 次のコマンドを実行して、ClusterUpgradeGroup CR が適用されているハブクラスターの事前キャッシュステータスを確認します。

    $ oc get cgu <cgu_name> -n <cgu_namespace> -oyaml

    出力例

      precaching:
        spec:
          platformImage: quay.io/openshift-release-dev/ocp-release@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e1ef
          operatorsIndexes:
            - registry.example.com:5000/custom-redhat-operators:1.0.0
          operatorsPackagesAndChannels:
            - local-storage-operator: stable
            - ptp-operator: stable
            - sriov-network-operator: stable
          excludePrecachePatterns:
            - aws
            - vsphere
          additionalImages:
            - quay.io/exampleconfig/application1@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e1ef
            - quay.io/exampleconfig/application2@sha256:3d5800123dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47adfaef
            - quay.io/exampleconfig/applicationN@sha256:4fe1334adfafadsf987123adfffdaf1243340adfafdedga0991234afdadfsa09
          spaceRequired: "30"
        status:
          sno1: Starting
          sno2: Starting

    事前キャッシュ設定は、管理ポリシーが存在するかどうかをチェックすることによって検証されます。ClusterGroupUpgrade および PreCachingConfig CR の設定が有効であると、次のステータスになります。

    有効な CR の出力例

    - lastTransitionTime: "2023-01-01T00:00:01Z"
      message: All selected clusters are valid
      reason: ClusterSelectionCompleted
      status: "True"
      type: ClusterSelected
    - lastTransitionTime: "2023-01-01T00:00:02Z"
      message: Completed validation
      reason: ValidationCompleted
      status: "True"
      type: Validated
    - lastTransitionTime: "2023-01-01T00:00:03Z"
      message: Precaching spec is valid and consistent
      reason: PrecacheSpecIsWellFormed
      status: "True"
      type: PrecacheSpecValid
    - lastTransitionTime: "2023-01-01T00:00:04Z"
      message: Precaching in progress for 1 clusters
      reason: InProgress
      status: "False"
      type: PrecachingSucceeded

    無効な PreCachingConfig CR の例

    Type:    "PrecacheSpecValid"
    Status:  False,
    Reason:  "PrecacheSpecIncomplete"
    Message: "Precaching spec is incomplete: failed to get PreCachingConfig resource due to PreCachingConfig.ran.openshift.io "<pre-caching_cr_name>" not found"

  2. マネージドクラスターで次のコマンドを実行すると、事前キャッシュジョブを見つけることができます。

    $ oc get jobs -n openshift-talo-pre-cache

    進行中の事前キャッシュジョブの例

    NAME        COMPLETIONS       DURATION      AGE
    pre-cache   0/1               1s            1s

  3. 次のコマンドを実行して、事前キャッシュジョブ用に作成された Pod のステータスを確認できます。

    $ oc describe pod pre-cache -n openshift-talo-pre-cache

    進行中の事前キャッシュジョブの例

    Type        Reason              Age    From              Message
    Normal      SuccesfulCreate     19s    job-controller    Created pod: pre-cache-abcd1

  4. 次のコマンドを実行すると、ジョブのステータスに関するライブ更新を取得できます。

    $ oc logs -f pre-cache-abcd1 -n openshift-talo-pre-cache
  5. 事前キャッシュジョブが正常に完了したことを確認するには、次のコマンドを実行します。

    $ oc describe pod pre-cache -n openshift-talo-pre-cache

    完了した事前キャッシュジョブの例

    Type        Reason              Age    From              Message
    Normal      SuccesfulCreate     5m19s  job-controller    Created pod: pre-cache-abcd1
    Normal      Completed           19s    job-controller    Job completed

  6. イメージが単一ノード OpenShift で正常に事前キャッシュされていることを確認するには、次の手順を実行します。

    1. デバッグモードでノードに入ります。

      $ oc debug node/cnfdf00.example.lab
    2. root を host に変更します。

      $ chroot /host/
    3. 目的のイメージを検索します。

      $ sudo podman images | grep <operator_name>

10.3.8. GitOps ZTP 用に自動作成された ClusterGroupUpgrade CR について

TALM には、ManagedClusterForCGU と呼ばれるコントローラーがあります。このコントローラーは、ハブクラスター上で ManagedCluster CR の Ready 状態を監視し、GitOps Zero Touch Provisioning (ZTP) の ClusterGroupUpgrade CR を作成します。

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

クラスターが Ready になった時点でマネージドクラスターのポリシーがない場合、ポリシーのない ClusterGroupUpgrade CR が作成されます。ClusterGroupUpgrade が完了すると、マネージドクラスターには ztp-done というラベルが付けられます。そのマネージドクラスターに適用するポリシーがある場合は、2 日目の操作として ClusterGroupUpgrade を 手動で作成します。

GitOps 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.