17.10. Topology Aware Lifecycle Manager を使用したマネージドクラスターの更新
Topology Aware Lifecycle Manager (TALM) を使用して、OpenShift Container Platform マネージドクラスターのソフトウェアライフサイクルを管理できます。TALM は Red Hat Advanced Cluster Management (RHACM) ポリシーを使用して、ターゲットクラスター上で変更を実行します。
関連情報
- Topology Aware Lifecycle Manager の詳細は、About the Topology Aware Lifecycle Manager を参照してください。
17.10.1. 切断された環境でのクラスターの更新
GitOps Zero Touch Provisioning (ZTP) および Topology Aware Lifecycle Manager (TALM) を使用してデプロイしたマネージドクラスターとそのマネージドクラスターの Operator をアップグレードできます。
17.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
ミラーリングされた目的のプラットフォーム イメージのイメージ シグネチャーを保存します。プラットフォームの更新のために、イメージ署名を
PolicyGenTemplateCR に追加する必要があります。イメージ署名を取得するには、次の手順を実行します。以下のコマンドを実行して、目的の OpenShift Container Platform タグを指定します。
$ OCP_RELEASE_NUMBER=<release_version>
次のコマンドを実行して、クラスターのアーキテクチャーを指定します。
$ ARCHITECTURE=<cluster_architecture> 1- 1
x86_64、aarch64、s390x、またはppc64leなど、クラスターのアーキテクチャーを指定します。
次のコマンドを実行して、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.13 -o ~/upgrade-graph_stable-4.13
Operator の更新については、以下のタスクを実行する必要があります。
- Operator カタログをミラーリングします。切断されたクラスターで使用する Operator カタログのミラーリングセクションの手順に従って、目的の Operator イメージがミラーリングされていることを確認します。
関連情報
- GitOps Zero Touch Provisioning (ZTP) の更新方法について、詳しくは GitOps ZTP のアップグレード を参照してください。
- OpenShift Container Platform イメージリポジトリーをミラーリングする方法の詳細は、OpenShift Container Platform イメージリポジトリーのミラーリング を参照してください。
- 切断されたクラスターの Operator カタログをミラーリングする方法の詳細は、非接続クラスターで使用する Operator カタログのミラーリング を参照してください。
- 非接続環境を準備して目的のイメージリポジトリーをミラーリングする方法の詳細は、非接続環境の準備 を参照してください。
- 更新チャネルとリリースの詳細は、更新チャネルとリリースについて を参照してください。
17.10.1.2. プラットフォームの更新の実行
TALM を使用してプラットフォームの更新を実行できます。
前提条件
- Topology Aware Lifecycle Manager (TALM) をインストールします。
- GitOps Zero Touch Provisioning (ZTP) を最新バージョンに更新します。
- GitOps ZTP を使用して 1 つ以上のマネージドクラスターをプロビジョニングします。
- 目的のイメージ リポジトリーをミラーリングします。
-
cluster-admin権限を持つユーザーとしてログインしている。 - ハブクラスターで RHACM ポリシーを作成します。
手順
プラットフォーム更新用の
PolicyGenTemplateCR を作成します。次の
PolicyGenTemplateCR の内容を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.13" upstream: http://upgrade.example.com/images/upgrade-graph_stable-4.13 - fileName: ClusterVersion.yaml 5 policyName: "platform-upgrade" metadata: name: version spec: channel: "stable-4.13" upstream: http://upgrade.example.com/images/upgrade-graph_stable-4.13 desiredUpdate: version: 4.13.4 status: history: - version: 4.13.4 state: "Completed"- 1
ConfigMapCR には、更新先の目的のリリースイメージの署名が含まれています。- 2
- 目的の OpenShift Container Platform リリースのイメージ署名を表示します。環境のセットアップセクションの手順に従って保存した
checksum-${OCP_RELASE_NUMBER}.yamlファイルから署名を取得します。 - 3
- 目的の OpenShift Container Platform イメージを含むミラーリポジトリーを表示します。環境のセットアップセクションの手順に従って保存した
imageContentSources.yamlファイルからミラーを取得します。 - 4
- アップストリームを更新する
ClusterVersionCR を表示します。 - 5
- 更新をトリガーする
ClusterVersionCR を示します。イメージの事前キャッシュには、channel、upstream、およびdesiredVersionフィールドがすべて必要です。
PolicyGenTemplateCR は 2 つのポリシーを生成します。-
du-upgrade-platform-upgrade-prepポリシーは、プラットフォームの更新の準備作業を行います。目的のリリースイメージシグネチャーのConfigMapCR を作成し、ミラー化されたリリースイメージリポジトリーのイメージ コンテンツソースを作成し、目的の更新チャネルと切断された環境でマネージドクラスターが到達可能な更新グラフを使用してクラスターバージョンを更新します。 -
du-upgrade-platform-upgradeポリシーは、プラットフォームのアップグレードを実行するために使用されます。
PolicyGenTemplateCR の GitOps 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-prepClusterUpgradeGroupCR の内容を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に設定して、プラットフォーム更新用のClusterGroupUpdateCR を作成します。次の例に示すように、
du-upgrade-platform-upgradeポリシーとターゲットクラスターを含むプラットフォーム更新ClusterGroupUpdateCR の内容を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次のコマンドを実行して、
ClusterGroupUpdateCR をハブクラスターに適用します。$ oc apply -f cgu-platform-upgrade.yml
オプション: プラットフォームの更新用にイメージを事前キャッシュします。
次のコマンドを実行して、
ClusterGroupUpdateCR で事前キャッシュを有効にします。$ 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
関連情報
- 非接続環境でのイメージのミラーリングに関する詳細は、非接続環境の準備 を参照してください。
17.10.1.3. Operator 更新の実行
TALM で Operator の更新を実行できます。
前提条件
- Topology Aware Lifecycle Manager (TALM) をインストールします。
- GitOps Zero Touch Provisioning (ZTP) を最新バージョンに更新します。
- GitOps ZTP を使用して 1 つ以上のマネージドクラスターをプロビジョニングします。
- 目的のインデックスイメージ、バンドルイメージ、およびバンドルイメージで参照されるすべての Operator イメージをミラーリングします。
-
cluster-admin権限を持つユーザーとしてログインしている。 - ハブクラスターで RHACM ポリシーを作成します。
手順
Operator の更新用に
PolicyGenTemplateCR を更新します。du-upgrade.yamlファイルの次の追加コンテンツでdu-upgradePolicyGenTemplateCR を更新します。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.13 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共通の
PolicyGenTemplateCR に指定されたサブスクリプションチャネルが存在する場合は、それらを削除します。GItOps ZTP イメージのデフォルトサブスクリプションチャネルが更新に使用されます。注記GItOps ZTP 4.13 で適用される Operator のデフォルトチャネルは、
performance-addon-operatorを除きすべてstableです。OpenShift Container Platform 4.11 以降、performance-addon-operator機能はnode-tuning-operatorに移動されました。4.10 リリースの場合、PAO のデフォルトチャネルはv4.10です。共通のPolicyGenTemplateCR でデフォルトのチャネルを指定することもできます。PolicyGenTemplateCR の更新を GitOps ZTP Git リポジトリーにプッシュします。ArgoCD は Git リポジトリーから変更を取得し、ハブクラスターでポリシーを生成します。
以下のコマンドを実行して、作成したポリシーを確認します。
$ oc get policies -A | grep -E "catsrc-policy|subscription"
Operator の更新を開始する前に、必要なカタログソースの更新を適用します。
operator-upgrade-prepという名前のClusterGroupUpgradeCR の内容をカタログソースポリシーと共に、ターゲットマネージドクラスターの内容を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 更新のClusterGroupUpgradeCR を作成します。以下の例のように、Operator 更新
ClusterGroupUpgradeCR の内容を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 つの
ClusterGroupUpgradeCR は、ClusterGroupUpgradeCR に含まれる 1 つのカタログソースからサブスクリプションポリシーで定義される必要な Operator のイメージのみを事前キャッシュできます。SRIOV-FEC Operator の例のように、目的の Operator が異なるカタログソースからのものである場合、別のClusterGroupUpgradeCR をdu-upgrade-fec-catsrc-policyおよびdu-upgrade-subscriptions-fec-policyポリシーで作成する必要があります。SRIOV-FEC Operator イメージの事前キャッシュと更新。次のコマンドを実行して、
ClusterGroupUpgradeCR をハブクラスターに適用します。$ 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
以下のコマンドを実行して、
ClusterGroupUpgradeCR で事前キャッシュを有効にします。$ 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-upgradeClusterGroupUpgradeCR を有効にし、事前キャッシュを無効にして 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 のアップグレード を参照してください。
17.10.1.4. プラットフォームと Operator の更新を一緒に実行する
プラットフォームと Operator の更新を同時に実行できます。
前提条件
- Topology Aware Lifecycle Manager (TALM) をインストールします。
- GitOps Zero Touch Provisioning (ZTP) を最新バージョンに更新します。
- GitOps ZTP を使用して 1 つ以上のマネージドクラスターをプロビジョニングします。
-
cluster-admin権限を持つユーザーとしてログインしている。 - ハブクラスターで RHACM ポリシーを作成します。
手順
-
プラットフォーム更新の実行および Operator 更新の実行セクションで説明されている手順に従って、更新用の
PolicyGenTemplateCR を作成します。 プラットフォームの準備作業と Operator の更新を適用します。
プラットフォームの更新の準備作業、カタログ ソースの更新、およびターゲット クラスターのポリシーを
含む ClusterGroupUpgradeCR の内容を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
プラットフォーム用の
ClusterGroupUpdateCR と、spec.enableフィールドをfalseに設定した Operator 更新を作成します。次の例に示すように、ポリシーとターゲットクラスターを含むプラットフォームと Operator の更新
ClusterGroupUpdateCR の内容を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 の更新用にイメージを事前キャッシュします。
以下のコマンドを実行して、
ClusterGroupUpgradeCR で事前キャッシュを有効にします。$ 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-upgradeClusterGroupUpgradeCR がプラットフォームと 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に設定すると、更新の完了後にこれらのリソースがすべて削除されます。
17.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 アプリケーションが変更をハブクラスターに同期するのを待ちます。ポリシーは準拠したままです。
17.10.2. 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