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 のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
関連情報
- Topology Aware Lifecycle Manager の詳細は、Topology Aware Lifecycle Manager の概要 を参照してください。
19.10.1. 切断された環境でのクラスターの更新
GitOps ZTP および Topology Aware Lifecycle Manager (TALM) を使用してデプロイした管理対象クラスターおよびマネージドクラスターの Operator をアップグレードできます。
19.10.1.1. 環境の設定
TALM は、プラットフォームと Operator の更新の両方を実行できます。
TALM を使用して非接続クラスターを更新する前に、ミラーレジストリーで更新するプラットフォームイメージおよび Operator イメージの両方をミラーリングする必要があります。イメージをミラーリングするには以下の手順を実行します。
プラットフォームの更新では、以下の手順を実行する必要があります。
必要な 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
ミラーリングされた目的のプラットフォーム イメージのイメージ シグネチャーを保存します。プラットフォームの更新のために、イメージ署名を
PolicyGenTemplate
CR に追加する必要があります。イメージ署名を取得するには、次の手順を実行します。以下のコマンドを実行して、目的の OpenShift Container Platform タグを指定します。
$ OCP_RELEASE_NUMBER=<release_version>
次のコマンドを実行して、サーバーのアーキテクチャーを指定します。
$ ARCHITECTURE=<server_architecture>
次のコマンドを実行して、Quay からリリースイメージダイジェストを取得します。
$ DIGEST="$(oc adm release info quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_NUMBER}-${ARCHITECTURE} | sed -n 's/Pull From: .*@//p')"
次のコマンドを実行して、ダイジェストアルゴリズムを設定します。
$ DIGEST_ALGO="${DIGEST%%:*}"
次のコマンドを実行して、ダイジェスト署名を設定します。
$ DIGEST_ENCODED="${DIGEST#*:}"
次のコマンドを実行して、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)
以下のコマンドを実行して、イメージ署名を
checksum-<OCP_RELEASE_NUMBER>.yaml
ファイルに保存します。$ cat >checksum-${OCP_RELEASE_NUMBER}.yaml <<EOF ${DIGEST_ALGO}-${DIGEST_ENCODED}: ${SIGNATURE_BASE64} EOF
更新グラフを準備します。更新グラフを準備するオプションは 2 つあります。
OpenShift Update Service を使用します。
ハブクラスターでグラフを設定する方法の詳細については、 OpenShift Update Service の Operator のデプロイ および グラフデータ init コンテナーのビルド を参照してください。
アップストリームグラフのローカルコピーを作成します。マネージドクラスターにアクセスできる非接続環境の
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 イメージがミラーリングされていることを確認します。
関連情報
- ZTP の更新方法の詳細は、GitOps ZTP のアップグレード を参照してください。
- OpenShift Container Platform イメージリポジトリーをミラーリングする方法の詳細は、OpenShift Container Platform イメージリポジトリーのミラーリング を参照してください。
- 切断されたクラスターの Operator カタログをミラーリングする方法の詳細は、非接続クラスターで使用する Operator カタログのミラーリング を参照してください。
- 切断された環境を準備し、目的のイメージリポジトリーをミラーリングする方法に関する詳細は、非接続環境の準備 を参照してください。
- 更新チャネルとリリースの詳細は、更新チャネルとリリースについて を参照してください。
19.10.1.2. プラットフォームの更新の実行
TALM を使用してプラットフォームの更新を実行できます。
前提条件
- Topology Aware Lifecycle Manager (TALM) をインストールします。
- ZTP を最新バージョンに更新します。
- ZTP を使用して 1 つ以上のマネージドクラスターをプロビジョニングします。
- 目的のイメージ リポジトリーをミラーリングします。
-
cluster-admin
権限を持つユーザーとしてログインしている。 - ハブクラスターで RHACM ポリシーを作成します。
手順
プラットフォーム更新用の
PolicyGenTemplate
CR を作成します。次の
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 を示します。イメージの事前キャッシュには、channel
、upstream
、およびdesiredVersion
フィールドがすべて必要です。
PolicyGenTemplate
CR は 2 つのポリシーを生成します。-
du-upgrade-platform-upgrade-prep
ポリシーは、プラットフォームの更新の準備作業を行います。目的のリリースイメージシグネチャーのConfigMap
CR を作成し、ミラー化されたリリースイメージリポジトリーのイメージ コンテンツソースを作成し、目的の更新チャネルと切断された環境でマネージドクラスターが到達可能な更新グラフを使用してクラスターバージョンを更新します。 -
du-upgrade-platform-upgrade
ポリシーは、プラットフォームのアップグレードを実行するために使用されます。
PolicyGenTemplate
CR の ZTP Git リポジトリーにあるkustomization.yaml
ファイルにdu-upgrade.yaml
ファイルの内容を追加し、変更を Git リポジトリーにプッシュします。ArgoCD は Git リポジトリーから変更を取得し、ハブクラスターでポリシーを生成します。
以下のコマンドを実行して、作成したポリシーを確認します。
$ oc get policies -A | grep platform-upgrade
TALM でプラットフォームの更新を開始する前に、必要な更新リソースを適用します。
次の例に示すように、
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
次のコマンドを実行して、ポリシーをハブ クラスターに適用します。
$ oc apply -f cgu-platform-upgrade-prep.yml
更新プロセスを監視します。完了したら、次のコマンドを実行して、ポリシーが準拠していることを確認します。
$ oc get policies --all-namespaces
spec.enable
フィールドをfalse
に設定して、プラットフォーム更新用のClusterGroupUpdate
CR を作成します。次の例に示すように、
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
次のコマンドを実行して、
ClusterGroupUpdate
CR をハブクラスターに適用します。$ oc apply -f cgu-platform-upgrade.yml
オプション: プラットフォームの更新用にイメージを事前キャッシュします。
次のコマンドを実行して、
ClusterGroupUpdate
CR で事前キャッシュを有効にします。$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge
更新プロセスを監視し、事前キャッシュが完了するまで待ちます。ハブクラスターで次のコマンドを実行して、事前キャッシュの状態を確認します。
$ oc get cgu cgu-platform-upgrade -o jsonpath='{.status.precaching.status}'
プラットフォームの更新を開始します。
次のコマンドを実行して、
cgu-platform-upgrade
ポリシーを有効にし、事前キャッシュを無効にします。$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
プロセスを監視します。完了したら、次のコマンドを実行して、ポリシーが準拠していることを確認します。
$ oc get policies --all-namespaces
関連情報
- 切断された環境でのイメージのミラーリングに関する詳細は、非接続環境の準備 を参照してください。
19.10.1.3. Operator 更新の実行
TALM で Operator の更新を実行できます。
前提条件
- Topology Aware Lifecycle Manager (TALM) をインストールします。
- ZTP を最新バージョンに更新します。
- ZTP を使用して 1 つ以上のマネージドクラスターをプロビジョニングします。
- 目的のインデックスイメージ、バンドルイメージ、およびバンドルイメージで参照されるすべての Operator イメージをミラーリングします。
-
cluster-admin
権限を持つユーザーとしてログインしている。 - ハブクラスターで RHACM ポリシーを作成します。
手順
Operator の更新用に
PolicyGenTemplate
CR を更新します。du-upgrade.yaml
ファイルの次の追加コンテンツでdu-upgrade
PolicyGenTemplate
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
をデフォルト値に戻すことができます。
この更新により、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-policy
とdu-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
共通の
PolicyGenTemplate
CR に指定されたサブスクリプションチャネルが存在する場合は、それらを削除します。ZTP イメージのデフォルトのサブスクリプションチャネルが更新に使用されます。注記ZTP 4.10 で適用される Operator のデフォルトチャネルは
stable
ですが、performance-addon-operator
を除きます。PAO のデフォルトのチャネルは4.10
です。共通のPolicyGenTemplate
CR でデフォルトのチャネルを指定することもできます。PolicyGenTemplate
CR 更新を ZTP Git リポジトリーにプッシュします。ArgoCD は Git リポジトリーから変更を取得し、ハブクラスターでポリシーを生成します。
以下のコマンドを実行して、作成したポリシーを確認します。
$ oc get policies -A | grep -E "catsrc-policy|subscription"
Operator の更新を開始する前に、必要なカタログソースの更新を適用します。
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
次のコマンドを実行して、ポリシーをハブ クラスターに適用します。
$ oc apply -f cgu-operator-upgrade-prep.yml
更新プロセスを監視します。完了したら、次のコマンドを実行して、ポリシーが準拠していることを確認します。
$ oc get policies -A | grep -E "catsrc-policy"
spec.enable
フィールドをfalse
に設定して、Operator 更新のClusterGroupUpgrade
CR を作成します。以下の例のように、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 つの
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 イメージの事前キャッシュと更新。次のコマンドを実行して、
ClusterGroupUpgrade
CR をハブクラスターに適用します。$ oc apply -f cgu-operator-upgrade.yml
オプション: Operator の更新用にイメージを事前キャッシュします。
イメージの事前キャッシュを開始する前に、以下のコマンドを実行して、サブスクリプションポリシーがこの時点で
NonCompliant
であることを確認します。$ oc get policy common-subscriptions-policy -n <policy_namespace>
出力例
NAME REMEDIATION ACTION COMPLIANCE STATE AGE common-subscriptions-policy inform NonCompliant 27d
以下のコマンドを実行して、
ClusterGroupUpgrade
CR で事前キャッシュを有効にします。$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge
プロセスを監視し、事前キャッシュが完了するまで待ちます。マネージドクラスターで次のコマンドを実行して、事前キャッシュの状態を確認します。
$ oc get cgu cgu-operator-upgrade -o jsonpath='{.status.precaching.status}'
以下のコマンドを実行して、更新を開始する前に事前キャッシュが完了したかどうかを確認します。
$ 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" } ]
Operator の更新を開始します。
以下のコマンドを実行して
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
プロセスを監視します。完了したら、次のコマンドを実行して、ポリシーが準拠していることを確認します。
$ oc get policies --all-namespaces
関連情報
- GitOps ZTP の更新に関する詳細は、GitOps ZTP のアップグレード を参照してください。
19.10.1.4. プラットフォームと Operator の更新を一緒に実行する
プラットフォームと Operator の更新を同時に実行できます。
前提条件
- Topology Aware Lifecycle Manager (TALM) をインストールします。
- ZTP を最新バージョンに更新します。
- ZTP を使用して 1 つ以上のマネージドクラスターをプロビジョニングします。
-
cluster-admin
権限を持つユーザーとしてログインしている。 - ハブクラスターで RHACM ポリシーを作成します。
手順
-
プラットフォーム更新の実行および Operator 更新の実行セクションで説明されている手順に従って、更新用の
PolicyGenTemplate
CR を作成します。 プラットフォームの準備作業と Operator の更新を適用します。
プラットフォームの更新の準備作業、カタログ ソースの更新、およびターゲット クラスターのポリシーを
含む 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
次のコマンドを実行して、
cgu-platform-operator-upgrade-prep.yml
ファイルをハブクラスターに適用します。$ oc apply -f cgu-platform-operator-upgrade-prep.yml
プロセスを監視します。完了したら、次のコマンドを実行して、ポリシーが準拠していることを確認します。
$ oc get policies --all-namespaces
プラットフォーム用の
ClusterGroupUpdate
CR と、spec.enable
フィールドをfalse
に設定した Operator 更新を作成します。次の例に示すように、ポリシーとターゲットクラスターを含むプラットフォームと 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
次のコマンドを実行して、
cgu-platform-operator-upgrade.yml
ファイルをハブクラスターに適用します。$ oc apply -f cgu-platform-operator-upgrade.yml
オプション: プラットフォームおよび Operator の更新用にイメージを事前キャッシュします。
以下のコマンドを実行して、
ClusterGroupUpgrade
CR で事前キャッシュを有効にします。$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge
更新プロセスを監視し、事前キャッシュが完了するまで待ちます。マネージドクラスターで次のコマンドを実行して、事前キャッシュの状態を確認します。
$ oc get jobs,pods -n openshift-talm-pre-cache
以下のコマンドを実行して、更新を開始する前に事前キャッシュが完了したかどうかを確認します。
$ oc get cgu cgu-du-upgrade -ojsonpath='{.status.conditions}'
プラットフォームおよび Operator の更新を開始します。
以下のコマンドを実行して、
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
プロセスを監視します。完了したら、次のコマンドを実行して、ポリシーが準拠していることを確認します。
$ 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
権限を持つユーザーとしてログインしている。
手順
common-ranGen.yaml
ファイル の Performance Addon Operator namespace、Operator グループ、およびサブスクリプションのComplianceType
をmustnothave
に変更します。- fileName: PaoSubscriptionNS.yaml policyName: "subscriptions-policy" complianceType: mustnothave - fileName: PaoSubscriptionOperGroup.yaml policyName: "subscriptions-policy" complianceType: mustnothave - fileName: PaoSubscription.yaml policyName: "subscriptions-policy" complianceType: mustnothave
-
変更をカスタムサイトリポジトリーにマージし、ArgoCD アプリケーションが変更をハブクラスターに同期するのを待ちます。
common-subscriptions-policy
ポリシーのステータスがNon-Compliant
に変わります。 - Topology Aware Lifecycle Manager を使用して、ターゲットクラスターに変更を適用します。設定変更のロールアウトの詳細については、「関連情報」セクションを参照してください。
プロセスを監視します。ターゲットクラスターの
common-subscriptions-policy
ポリシーのステータスがCompliant
の場合、Performance Addon Operator はクラスターから削除されています。次のコマンドを実行して、common-subscriptions-policy
のステータスを取得します。$ oc get policy -n ztp-common common-subscriptions-policy
-
common-ranGen.yaml
ファイルの.spec.sourceFiles
から Performance Addon Operator namespace、Operator グループ、およびサブスクリプション CR を削除します。 - 変更をカスタムサイトリポジトリーにマージし、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