18.11. Topology Aware Lifecycle Manager を使用したマネージドクラスターの更新
Topology Aware Lifecycle Manager (TALM) を使用して、複数のクラスターのソフトウェアライフサイクルを管理できます。TALM は Red Hat Advanced Cluster Management (RHACM) ポリシーを使用して、ターゲットクラスター上で変更を実行します。
18.11.1. Topology Aware Lifecycle Manager の設定について
Topology Aware Lifecycle Manager (TALM) は、1 つまたは複数の OpenShift Container Platform クラスターに対する Red Hat Advanced Cluster Management (RHACM) ポリシーのデプロイメントを管理します。TALM を大規模なクラスターのネットワークで使用することにより、限られたバッチで段階的にポリシーをクラスターにデプロイメントすることができます。これにより、更新時のサービス中断の可能性を最小限に抑えることができます。TALM では、以下の動作を制御することができます。
- 更新のタイミング
- RHACM マネージドクラスター数
- ポリシーを適用するマネージドクラスターのサブセット
- クラスターの更新順序
- クラスターに修復されたポリシーのセット
- クラスターに修復されたポリシーの順序
- カナリアクラスターの割り当て
シングルノード OpenShift の場合、Topology Aware Lifecycle Manager (TALM) は次の機能を提供します。
- アップグレード前に、デプロイメントのバックアップを作成する
- 帯域幅が制限されたクラスターのイメージの事前キャッシュ
TALM は、OpenShift Container Platform y-stream および z-stream 更新のオーケストレーションをサポートし、y-streams および z-streams での day-two 操作をサポートします。
18.11.2. Topology Aware Lifecycle Manager で使用される管理ポリシー
Topology Aware Lifecycle Manager (TALM) は、クラスターの更新に RHACM ポリシーを使用します。
TALM は、remediationAction
フィールドが inform
に設定されているポリシー CR のロールアウトを管理するために使用できます。サポートされるユースケースには、以下が含まれます。
- ポリシー CR の手動ユーザー作成
-
PolicyGenTemplate
カスタムリソース定義 (CRD) から自動生成されたポリシー
手動承認で Operator 契約を更新するポリシーのために、TALM は、更新された Operator のインストールを承認する追加機能を提供します。
管理されたポリシーの詳細については、RHACM のドキュメントの ポリシーの概要 を参照してください。
PolicyGenTemplate
CRD の詳細は、「ポリシーと PolicyGenTemplate リソースを使用したマネージドクラスターの設定」の「PolicyGenTemplate CRD について」のセクションを参照してください。
18.11.3. Web コンソールを使用した Topology Aware Lifecycle Manager のインストール
OpenShift Container Platform Web コンソールを使用して Topology Aware Lifecycle Manager をインストールできます。
前提条件
- 最新バージョンの RHACM Operator をインストールします。
- 非接続の regitry でハブクラスターを設定します。
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
-
OpenShift Container Platform Web コンソールで、Operators
OperatorHub ページに移動します。 - 利用可能な Operator のリストから Topology Aware Lifecycle Manager を検索し、Install をクリックします。
- Installation mode ["All namespaces on the cluster (default)"] および Installed Namespace ("openshift-operators") のデフォルトの選択を維持し、Operator が適切にインストールされていることを確認します。
- Install をクリックします。
検証
インストールが正常に行われたことを確認するには、以下を実行します。
-
Operators
Installed Operators ページに移動します。 -
Operator が
All Namespaces
ネームスペースにインストールされ、そのステータスがSucceeded
であることを確認します。
Operator が正常にインストールされていない場合、以下を実行します。
-
Operators
Installed Operators ページに移動し、 Status
列でエラーまたは失敗の有無を確認します。 -
Workloads
Pods ページに移動し、問題を報告している cluster-group-upgrades-controller-manager
Pod のコンテナーのログを確認します。
18.11.4. CLI を使用した Topology Aware Lifecycle Manager のインストール
OpenShift CLI (oc
) を使用して Topology Aware Lifecycle Manager (TALM) をインストールできます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - 最新バージョンの RHACM Operator をインストールします。
- 非接続の regitry でハブクラスターを設定します。
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
Subscription
CR を作成します。Subscription
CR を定義し、YAML ファイルを保存します (例:talm-subscription.yaml
)。apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-topology-aware-lifecycle-manager-subscription namespace: openshift-operators spec: channel: "stable" name: topology-aware-lifecycle-manager source: redhat-operators sourceNamespace: openshift-marketplace
以下のコマンドを実行して
Subscription
CR を作成します。$ oc create -f talm-subscription.yaml
検証
CSV リソースを調べて、インストールが成功したことを確認します。
$ oc get csv -n openshift-operators
出力例
NAME DISPLAY VERSION REPLACES PHASE topology-aware-lifecycle-manager.4.14.x Topology Aware Lifecycle Manager 4.14.x Succeeded
TALM が稼働していることを確認します。
$ oc get deploy -n openshift-operators
出力例
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE openshift-operators cluster-group-upgrades-controller-manager 1/1 1 1 14s
18.11.5. ClusterGroupUpgrade CR
Topology Aware Lifecycle Manager (TALM) は、クラスターグループの ClusterGroupUpgrade
CR から修復計画を作成します。ClusterGroupUpgrade
CR で次の仕様を定義できます。
- グループのクラスター
-
ClusterGroupUpgrade
CR のブロック - 管理ポリシーの適用リスト
- 同時更新の数
- 適用可能なカナリア更新
- 更新前後に実行するアクション
- 更新タイミング
ClusterGroupUpgrade
CR の enable
フィールドを使用して、更新の開始時刻を制御できます。たとえば、メンテナンスウィンドウが 4 時間にスケジュールされている場合、enable
フィールドを false
に設定して ClusterGroupUpgrade
CR を準備できます。
次のように spec.remediationStrategy.timeout
設定を設定することで、タイムアウトを設定できます。
spec remediationStrategy: maxConcurrency: 1 timeout: 240
batchTimeoutAction
を使用して、クラスターの更新が失敗した場合にどうなるかを判断できます。continue
を指定して失敗したクラスターをスキップし、他のクラスターのアップグレードを続行するか、abort
を指定してすべてのクラスターのポリシー修復を停止することができます。タイムアウトが経過すると、TALM はすべての enforce
ポリシーを削除して、クラスターがそれ以上更新されないようにします。
変更を適用するには、enabled
フィールドを true
に設定します。
詳細は、「マネージドクラスターへの更新ポリシーの適用」セクションを参照してください。
TALM は指定されたクラスターへのポリシーの修復を通じて機能するため、ClusterGroupUpgrade
CR は多くの条件について true または false のステータスを報告できます。
TALM がクラスターの更新を完了した後、同じ ClusterGroupUpgrade
CR の制御下でクラスターが再度更新されることはありません。次の場合は、新しい ClusterGroupUpgrade
CR を作成する必要があります。
- クラスターを再度更新する必要がある場合
-
クラスターが更新後に
inform
ポリシーで非準拠に変更された場合
18.11.5.1. クラスターの選択
TALM は修復計画を作成し、次のフィールドに基づいてクラスターを選択します。
-
clusterLabelSelector
フィールドは、更新するクラスターのラベルを指定します。これは、k8s.io/apimachinery/pkg/apis/meta/v1
からの標準ラベルセレクターのリストで構成されます。リスト内の各セレクターは、ラベル値ペアまたはラベル式のいずれかを使用します。各セレクターからの一致は、clusterSelector
フィールドおよびcluster
フィールドからの一致と共に、クラスターの最終リストに追加されます。 -
clusters
フィールドは、更新するクラスターのリストを指定します。 -
canaries
フィールドは、カナリア更新のクラスターを指定します。 -
maxConcurrency
フィールドは、バッチで更新するクラスターの数を指定します。 -
actions
フィールドは、更新プロセスを開始するときに TALM が実行するbeforeEnable
アクションと、各クラスターのポリシー修復を完了するときに TALM が実行するafterCompletion
アクションを指定します。
clusters
、clusterLabelSelector
、および clusterSelector
フィールドを一緒に使用して、クラスターの結合リストを作成できます。
修復計画は、canaries
フィールドにリストされているクラスターから開始されます。各カナリアクラスターは、単一クラスターバッチを形成します。
有効な field
が false
に設定されたサンプル ClusterGroupUpgrade
CR
apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: creationTimestamp: '2022-11-18T16:27:15Z' finalizers: - ran.openshift.io/cleanup-finalizer generation: 1 name: talm-cgu namespace: talm-namespace resourceVersion: '40451823' uid: cca245a5-4bca-45fa-89c0-aa6af81a596c Spec: actions: afterCompletion: 1 addClusterLabels: upgrade-done: "" deleteClusterLabels: upgrade-running: "" deleteObjects: true beforeEnable: 2 addClusterLabels: upgrade-running: "" backup: false clusters: 3 - spoke1 enable: false 4 managedPolicies: 5 - talm-policy preCaching: false remediationStrategy: 6 canaries: 7 - spoke1 maxConcurrency: 2 8 timeout: 240 clusterLabelSelectors: 9 - matchExpressions: - key: label1 operator: In values: - value1a - value1b batchTimeoutAction: 10 status: 11 computedMaxConcurrency: 2 conditions: - lastTransitionTime: '2022-11-18T16:27:15Z' message: All selected clusters are valid reason: ClusterSelectionCompleted status: 'True' type: ClustersSelected 12 - lastTransitionTime: '2022-11-18T16:27:15Z' message: Completed validation reason: ValidationCompleted status: 'True' type: Validated 13 - lastTransitionTime: '2022-11-18T16:37:16Z' message: Not enabled reason: NotEnabled status: 'False' type: Progressing managedPoliciesForUpgrade: - name: talm-policy namespace: talm-namespace managedPoliciesNs: talm-policy: talm-namespace remediationPlan: - - spoke1 - - spoke2 - spoke3 status:
- 1
- 各クラスターのポリシー修復が完了したときに TALM が実行するアクションを指定します。
- 2
- 更新プロセスを開始するときに TALM が実行するアクションを指定します。
- 3
- 更新するクラスターの一覧を定義します。
- 4
enable
フィールドはfalse
に設定されています。- 5
- 修復するユーザー定義のポリシーセットを一覧表示します。
- 6
- クラスター更新の詳細を定義します。
- 7
- カナリア更新のクラスターを定義します。
- 8
- バッチの同時更新の最大数を定義します。修復バッチの数は、カナリアクラスターの数に加えて、カナリアクラスターを除くクラスターの数を
maxConcurrency
値で除算します。すべての管理ポリシーに準拠しているクラスターは、修復計画から除外されます。 - 9
- クラスターを選択するためのパラメーターを表示します。
- 10
- バッチがタイムアウトした場合の動作を制御します。可能な値は
abort
またはcontinue
です。指定しない場合、デフォルトはcontinue
です。 - 11
- 更新のステータスに関する情報を表示します。
- 12
ClustersSelected
条件は、選択されたすべてのクラスターが有効であることを示します。- 13
Validated
条件は、選択したすべてのクラスターが検証済みであることを示します。
カナリアクラスターの更新中に障害が発生すると、更新プロセスが停止します。
修復計画が正常に作成されたら、enable
フィールドを true
に設定できます。TALM は、指定された管理ポリシーを使用して、準拠していないクラスターの更新を開始します。
ClusterGroupUpgrade
CR の enable
フィールドが false
に設定されている場合にのみ、spec
フィールドを変更できます。
18.11.5.2. Validating
TALM は、指定されたすべての管理ポリシーが使用可能で正しいことを確認し、Validated
条件を使用して、ステータスと理由を次のようにレポートします。
true
検証が完了しました。
false
ポリシーが見つからないか無効であるか、無効なプラットフォームイメージが指定されています。
18.11.5.3. 事前キャッシュ
クラスターにはコンテナーイメージレジストリーにアクセスするための帯域幅が制限されるため、更新が完了する前にタイムアウトが発生する可能性があります。シングルノード OpenShift クラスターでは、事前キャッシュを使用して、これを回避できます。preCaching
フィールドを true
に設定して ClusterGroupUpgrade
CR を作成すると、コンテナーイメージの事前キャッシュが開始されます。TALM は、使用可能なディスク容量を OpenShift Container Platform イメージの推定サイズと比較して、十分な容量があることを確認します。クラスターに十分なスペースがない場合、TALM はそのクラスターの事前キャッシュをキャンセルし、そのクラスターのポリシーを修復しません。
TALM は PrecacheSpecValid
条件を使用して、次のようにステータス情報を報告します。
true
事前キャッシュの仕様は有効で一貫性があります。
false
事前キャッシュの仕様は不完全です。
TALM は PrecachingSucceeded
条件を使用して、次のようにステータス情報を報告します。
true
TALM は事前キャッシュプロセスを完了しました。いずれかのクラスターで事前キャッシュが失敗した場合、そのクラスターの更新は失敗しますが、他のすべてのクラスターの更新は続行されます。クラスターの事前キャッシュが失敗した場合は、メッセージで通知されます。
false
1 つ以上のクラスターで事前キャッシュがまだ進行中か、すべてのクラスターで失敗しました。
詳細は、「コンテナーイメージの事前キャッシュ機能の使用」セクションを参照してください。
18.11.5.4. バックアップの作成
シングルノード OpenShift の場合、TALM は更新前にデプロイメントのバックアップを作成できます。アップデートが失敗した場合は、以前のバージョンを回復し、アプリケーションの再プロビジョニングを必要とせずにクラスターを動作状態に復元できます。バックアップ機能を使用するには、最初に backup
フィールドを true
に設定して ClusterGroupUpgrade
CR を作成します。バックアップの内容が最新であることを確認するために、ClusterGroupUpgrade
CR の enable
フィールドを true
に設定するまで、バックアップは取得されません。
TALM は BackupSucceeded
条件を使用して、ステータスと理由を次のように報告します。
true
すべてのクラスターのバックアップが完了したか、バックアップの実行が完了したが、1 つ以上のクラスターで失敗しました。いずれかのクラスターのバックアップが失敗した場合、そのクラスターの更新は失敗しますが、他のすべてのクラスターの更新は続行されます。
false
1 つ以上のクラスターのバックアップがまだ進行中か、すべてのクラスターのバックアップが失敗しました。
詳細は、「アップグレード前のクラスターリソースのバックアップの作成」セクションを参照してください。
18.11.5.5. クラスターの更新
TALM は、修復計画に従ってポリシーを適用します。以降のバッチに対するポリシーの適用は、現在のバッチのすべてのクラスターがすべての管理ポリシーに準拠した直後に開始されます。バッチがタイムアウトすると、TALM は次のバッチに移動します。バッチのタイムアウト値は、spec.timeout
フィールドは修復計画のバッチ数で除算されます。
TALM は Progressing
条件を使用して、ステータスと理由を次のように報告します。
true
TALM は準拠していないポリシーを修復しています。
false
更新は進行中ではありません。これには次の理由が考えられます。
- すべてのクラスターは、すべての管理ポリシーに準拠しています。
- ポリシーの修復に時間がかかりすぎたため、更新がタイムアウトしました。
- ブロッキング CR がシステムにないか、まだ完了していません。
-
ClusterGroupUpgrade
CR が有効になっていません。 - バックアップはまだ進行中です。
管理されたポリシーは、ClusterGroupUpgrade
CR の managedPolicies
フィールドに一覧表示される順序で適用されます。1 つの管理ポリシーが一度に指定されたクラスターに適用されます。クラスターが現在のポリシーに準拠している場合、次の管理ポリシーがクラスターに適用されます。
Progressing
状態の ClusterGroupUpgrade
CR の例
apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
creationTimestamp: '2022-11-18T16:27:15Z'
finalizers:
- ran.openshift.io/cleanup-finalizer
generation: 1
name: talm-cgu
namespace: talm-namespace
resourceVersion: '40451823'
uid: cca245a5-4bca-45fa-89c0-aa6af81a596c
Spec:
actions:
afterCompletion:
deleteObjects: true
beforeEnable: {}
backup: false
clusters:
- spoke1
enable: true
managedPolicies:
- talm-policy
preCaching: true
remediationStrategy:
canaries:
- spoke1
maxConcurrency: 2
timeout: 240
clusterLabelSelectors:
- matchExpressions:
- key: label1
operator: In
values:
- value1a
- value1b
batchTimeoutAction:
status:
clusters:
- name: spoke1
state: complete
computedMaxConcurrency: 2
conditions:
- lastTransitionTime: '2022-11-18T16:27:15Z'
message: All selected clusters are valid
reason: ClusterSelectionCompleted
status: 'True'
type: ClustersSelected
- lastTransitionTime: '2022-11-18T16:27:15Z'
message: Completed validation
reason: ValidationCompleted
status: 'True'
type: Validated
- lastTransitionTime: '2022-11-18T16:37:16Z'
message: Remediating non-compliant policies
reason: InProgress
status: 'True'
type: Progressing 1
managedPoliciesForUpgrade:
- name: talm-policy
namespace: talm-namespace
managedPoliciesNs:
talm-policy: talm-namespace
remediationPlan:
- - spoke1
- - spoke2
- spoke3
status:
currentBatch: 2
currentBatchRemediationProgress:
spoke2:
state: Completed
spoke3:
policyIndex: 0
state: InProgress
currentBatchStartedAt: '2022-11-18T16:27:16Z'
startedAt: '2022-11-18T16:27:15Z'
- 1
Progressing
フィールドは、TALM がポリシーの修復中であることを示しています。
18.11.5.6. 更新ステータス
TALM は Succeeded
条件を使用して、ステータスと理由を次のようにレポートします。
true
すべてのクラスターは、指定された管理ポリシーに準拠しています。
false
修復に使用できるクラスターがないか、次のいずれかの理由でポリシーの修復に時間がかかりすぎたため、ポリシーの修復に失敗しました。
- 現在のバッチにカナリア更新が含まれており、バッチ内のクラスターがバッチタイムアウト内のすべての管理ポリシーに準拠していません。
-
クラスターは、
remediationStrategy
フィールドに指定されたtimeout
値内で管理ポリシーに準拠していませんでした。
Succeeded
状態の ClusterGroupUpgrade
CR の例
apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: name: cgu-upgrade-complete namespace: default spec: clusters: - spoke1 - spoke4 enable: true managedPolicies: - policy1-common-cluster-version-policy - policy2-common-pao-sub-policy remediationStrategy: maxConcurrency: 1 timeout: 240 status: 1 clusters: - name: spoke1 state: complete - name: spoke4 state: complete conditions: - message: All selected clusters are valid reason: ClusterSelectionCompleted status: "True" type: ClustersSelected - message: Completed validation reason: ValidationCompleted status: "True" type: Validated - message: All clusters are compliant with all the managed policies reason: Completed status: "False" type: Progressing 2 - message: All clusters are compliant with all the managed policies reason: Completed status: "True" type: Succeeded 3 managedPoliciesForUpgrade: - name: policy1-common-cluster-version-policy namespace: default - name: policy2-common-pao-sub-policy namespace: default remediationPlan: - - spoke1 - - spoke4 status: completedAt: '2022-11-18T16:27:16Z' startedAt: '2022-11-18T16:27:15Z'
タイムアウト
状態の ClusterGroupUpgrade
CR の例
apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: creationTimestamp: '2022-11-18T16:27:15Z' finalizers: - ran.openshift.io/cleanup-finalizer generation: 1 name: talm-cgu namespace: talm-namespace resourceVersion: '40451823' uid: cca245a5-4bca-45fa-89c0-aa6af81a596c spec: actions: afterCompletion: deleteObjects: true beforeEnable: {} backup: false clusters: - spoke1 - spoke2 enable: true managedPolicies: - talm-policy preCaching: false remediationStrategy: maxConcurrency: 2 timeout: 240 status: clusters: - name: spoke1 state: complete - currentPolicy: 1 name: talm-policy status: NonCompliant name: spoke2 state: timedout computedMaxConcurrency: 2 conditions: - lastTransitionTime: '2022-11-18T16:27:15Z' message: All selected clusters are valid reason: ClusterSelectionCompleted status: 'True' type: ClustersSelected - lastTransitionTime: '2022-11-18T16:27:15Z' message: Completed validation reason: ValidationCompleted status: 'True' type: Validated - lastTransitionTime: '2022-11-18T16:37:16Z' message: Policy remediation took too long reason: TimedOut status: 'False' type: Progressing - lastTransitionTime: '2022-11-18T16:37:16Z' message: Policy remediation took too long reason: TimedOut status: 'False' type: Succeeded 2 managedPoliciesForUpgrade: - name: talm-policy namespace: talm-namespace managedPoliciesNs: talm-policy: talm-namespace remediationPlan: - - spoke1 - spoke2 status: startedAt: '2022-11-18T16:27:15Z' completedAt: '2022-11-18T20:27:15Z'
18.11.5.7. ClusterGroupUpgrade CR のブロック
複数の ClusterGroupUpgrade
CR を作成して、それらの適用順序を制御できます。
たとえば、ClusterGroupUpgrade
CR A の開始をブロックする ClusterGroupUpgrade
CR C を作成する場合、ClusterGroupUpgrade
CR A は ClusterGroupUpgrade
CR C のステータスが UpgradeComplete
になるまで起動できません。
1 つの ClusterGroupUpgrade
CR には複数のブロッキング CR を含めることができます。この場合、現在の CR のアップグレードを開始する前に、すべてのブロッキング CR を完了する必要があります。
前提条件
- Topology Aware Lifecycle Manager (TALM) をインストールしている。
- 1 つ以上のマネージドクラスターをプロビジョニングします。
-
cluster-admin
権限を持つユーザーとしてログインしている。 - ハブクラスターで RHACM ポリシーを作成している。
手順
ClusterGroupUpgrade
CR の内容をcgu-a.yaml
、cgu-b.yaml
、およびcgu-c.yaml
ファイルに保存します。apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: name: cgu-a namespace: default spec: blockingCRs: 1 - name: cgu-c namespace: default clusters: - spoke1 - spoke2 - spoke3 enable: false managedPolicies: - policy1-common-cluster-version-policy - policy2-common-pao-sub-policy - policy3-common-ptp-sub-policy remediationStrategy: canaries: - spoke1 maxConcurrency: 2 timeout: 240 status: conditions: - message: The ClusterGroupUpgrade CR is not enabled reason: UpgradeNotStarted status: "False" type: Ready copiedPolicies: - cgu-a-policy1-common-cluster-version-policy - cgu-a-policy2-common-pao-sub-policy - cgu-a-policy3-common-ptp-sub-policy managedPoliciesForUpgrade: - name: policy1-common-cluster-version-policy namespace: default - name: policy2-common-pao-sub-policy namespace: default - name: policy3-common-ptp-sub-policy namespace: default placementBindings: - cgu-a-policy1-common-cluster-version-policy - cgu-a-policy2-common-pao-sub-policy - cgu-a-policy3-common-ptp-sub-policy placementRules: - cgu-a-policy1-common-cluster-version-policy - cgu-a-policy2-common-pao-sub-policy - cgu-a-policy3-common-ptp-sub-policy remediationPlan: - - spoke1 - - spoke2
- 1
- ブロッキング CR を定義します。
cgu-c
が完了するまでcgu-a
の更新を開始できません。
apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: name: cgu-b namespace: default spec: blockingCRs: 1 - name: cgu-a namespace: default clusters: - spoke4 - spoke5 enable: false managedPolicies: - policy1-common-cluster-version-policy - policy2-common-pao-sub-policy - policy3-common-ptp-sub-policy - policy4-common-sriov-sub-policy remediationStrategy: maxConcurrency: 1 timeout: 240 status: conditions: - message: The ClusterGroupUpgrade CR is not enabled reason: UpgradeNotStarted status: "False" type: Ready copiedPolicies: - cgu-b-policy1-common-cluster-version-policy - cgu-b-policy2-common-pao-sub-policy - cgu-b-policy3-common-ptp-sub-policy - cgu-b-policy4-common-sriov-sub-policy managedPoliciesForUpgrade: - name: policy1-common-cluster-version-policy namespace: default - name: policy2-common-pao-sub-policy namespace: default - name: policy3-common-ptp-sub-policy namespace: default - name: policy4-common-sriov-sub-policy namespace: default placementBindings: - cgu-b-policy1-common-cluster-version-policy - cgu-b-policy2-common-pao-sub-policy - cgu-b-policy3-common-ptp-sub-policy - cgu-b-policy4-common-sriov-sub-policy placementRules: - cgu-b-policy1-common-cluster-version-policy - cgu-b-policy2-common-pao-sub-policy - cgu-b-policy3-common-ptp-sub-policy - cgu-b-policy4-common-sriov-sub-policy remediationPlan: - - spoke4 - - spoke5 status: {}
- 1
cgu-a
が完了するまでcgu-b
の更新を開始できません。
apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: name: cgu-c namespace: default spec: 1 clusters: - spoke6 enable: false managedPolicies: - policy1-common-cluster-version-policy - policy2-common-pao-sub-policy - policy3-common-ptp-sub-policy - policy4-common-sriov-sub-policy remediationStrategy: maxConcurrency: 1 timeout: 240 status: conditions: - message: The ClusterGroupUpgrade CR is not enabled reason: UpgradeNotStarted status: "False" type: Ready copiedPolicies: - cgu-c-policy1-common-cluster-version-policy - cgu-c-policy4-common-sriov-sub-policy managedPoliciesCompliantBeforeUpgrade: - policy2-common-pao-sub-policy - policy3-common-ptp-sub-policy managedPoliciesForUpgrade: - name: policy1-common-cluster-version-policy namespace: default - name: policy4-common-sriov-sub-policy namespace: default placementBindings: - cgu-c-policy1-common-cluster-version-policy - cgu-c-policy4-common-sriov-sub-policy placementRules: - cgu-c-policy1-common-cluster-version-policy - cgu-c-policy4-common-sriov-sub-policy remediationPlan: - - spoke6 status: {}
- 1
cgu-c
の更新にはブロック CR がありません。TALM は、enable
フィールドがtrue
に設定されている場合にcgu-c
の更新を開始します。
関連する CR ごとに以下のコマンドを実行して
ClusterGroupUpgrade
CR を作成します。$ oc apply -f <name>.yaml
関連する各 CR について以下のコマンドを実行して、更新プロセスを開始します。
$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/<name> \ --type merge -p '{"spec":{"enable":true}}'
以下の例は、
enable
フィールドがtrue
に設定されているClusterGroupUpgrade
CR を示しています。ブロッキング CR のある
cgu-a
の例apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: name: cgu-a namespace: default spec: blockingCRs: - name: cgu-c namespace: default clusters: - spoke1 - spoke2 - spoke3 enable: true managedPolicies: - policy1-common-cluster-version-policy - policy2-common-pao-sub-policy - policy3-common-ptp-sub-policy remediationStrategy: canaries: - spoke1 maxConcurrency: 2 timeout: 240 status: conditions: - message: 'The ClusterGroupUpgrade CR is blocked by other CRs that have not yet completed: [cgu-c]' 1 reason: UpgradeCannotStart status: "False" type: Ready copiedPolicies: - cgu-a-policy1-common-cluster-version-policy - cgu-a-policy2-common-pao-sub-policy - cgu-a-policy3-common-ptp-sub-policy managedPoliciesForUpgrade: - name: policy1-common-cluster-version-policy namespace: default - name: policy2-common-pao-sub-policy namespace: default - name: policy3-common-ptp-sub-policy namespace: default placementBindings: - cgu-a-policy1-common-cluster-version-policy - cgu-a-policy2-common-pao-sub-policy - cgu-a-policy3-common-ptp-sub-policy placementRules: - cgu-a-policy1-common-cluster-version-policy - cgu-a-policy2-common-pao-sub-policy - cgu-a-policy3-common-ptp-sub-policy remediationPlan: - - spoke1 - - spoke2 status: {}
- 1
- ブロッキング CR のリストを表示します。
ブロッキング CR のある
cgu-b
の例apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: name: cgu-b namespace: default spec: blockingCRs: - name: cgu-a namespace: default clusters: - spoke4 - spoke5 enable: true managedPolicies: - policy1-common-cluster-version-policy - policy2-common-pao-sub-policy - policy3-common-ptp-sub-policy - policy4-common-sriov-sub-policy remediationStrategy: maxConcurrency: 1 timeout: 240 status: conditions: - message: 'The ClusterGroupUpgrade CR is blocked by other CRs that have not yet completed: [cgu-a]' 1 reason: UpgradeCannotStart status: "False" type: Ready copiedPolicies: - cgu-b-policy1-common-cluster-version-policy - cgu-b-policy2-common-pao-sub-policy - cgu-b-policy3-common-ptp-sub-policy - cgu-b-policy4-common-sriov-sub-policy managedPoliciesForUpgrade: - name: policy1-common-cluster-version-policy namespace: default - name: policy2-common-pao-sub-policy namespace: default - name: policy3-common-ptp-sub-policy namespace: default - name: policy4-common-sriov-sub-policy namespace: default placementBindings: - cgu-b-policy1-common-cluster-version-policy - cgu-b-policy2-common-pao-sub-policy - cgu-b-policy3-common-ptp-sub-policy - cgu-b-policy4-common-sriov-sub-policy placementRules: - cgu-b-policy1-common-cluster-version-policy - cgu-b-policy2-common-pao-sub-policy - cgu-b-policy3-common-ptp-sub-policy - cgu-b-policy4-common-sriov-sub-policy remediationPlan: - - spoke4 - - spoke5 status: {}
- 1
- ブロッキング CR のリストを表示します。
CR をブロックする
cgu-c
の例apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: name: cgu-c namespace: default spec: clusters: - spoke6 enable: true managedPolicies: - policy1-common-cluster-version-policy - policy2-common-pao-sub-policy - policy3-common-ptp-sub-policy - policy4-common-sriov-sub-policy remediationStrategy: maxConcurrency: 1 timeout: 240 status: conditions: - message: The ClusterGroupUpgrade CR has upgrade policies that are still non compliant 1 reason: UpgradeNotCompleted status: "False" type: Ready copiedPolicies: - cgu-c-policy1-common-cluster-version-policy - cgu-c-policy4-common-sriov-sub-policy managedPoliciesCompliantBeforeUpgrade: - policy2-common-pao-sub-policy - policy3-common-ptp-sub-policy managedPoliciesForUpgrade: - name: policy1-common-cluster-version-policy namespace: default - name: policy4-common-sriov-sub-policy namespace: default placementBindings: - cgu-c-policy1-common-cluster-version-policy - cgu-c-policy4-common-sriov-sub-policy placementRules: - cgu-c-policy1-common-cluster-version-policy - cgu-c-policy4-common-sriov-sub-policy remediationPlan: - - spoke6 status: currentBatch: 1 remediationPlanForBatch: spoke6: 0
- 1
cgu-c
の更新にはブロック CR がありません。
18.11.6. マネージドクラスターでのポリシーの更新
Topology Aware Lifecycle Manager (TALM) は、ClusterGroupUpgrade
CR で指定されたクラスターの inform
ポリシーのセットを修正します。TALM は、マネージドの RHACM ポリシーの enforce
コピーを作成することにより、inform
ポリシーを修正します。コピーされた各ポリシーには、それぞれの対応する RHACM 配置ルールと RHACM 配置バインディングがあります。
1 つずつ、TALM は、現在のバッチから、適用可能な管理ポリシーに対応する配置ルールに各クラスターを追加します。クラスターがポリシーにすでに準拠している場合は、TALM は準拠するクラスターへのポリシーの適用を省略します。次に TALM は次のポリシーを非準拠クラスターに適用します。TALM がバッチの更新を完了すると、コピーしたポリシーに関連付けられた配置ルールからすべてのクラスターが削除されます。次に、次のバッチの更新が開始されます。
スポーククラスターの状態が RHACM に準拠している状態を報告しない場合、ハブクラスターの管理ポリシーには TALM が必要とするステータス情報がありません。TALM は、以下の方法でこれらのケースを処理します。
-
ポリシーの
status.compliant
フィールドがない場合、TALM はポリシーを無視してログエントリーを追加します。次に、TALM はポリシーのstatus.status
フィールドを確認し続けます。 -
ポリシーの
status.status
がない場合、TALM はエラーを生成します。 -
クラスターのコンプライアンスステータスがポリシーの
status.status
フィールドにない場合、TALM はそのクラスターをそのポリシーに準拠していないと見なします。
ClusterGroupUpgrade
CR の batchTimeoutAction
は、クラスターのアップグレードが失敗した場合にどうなるかを決定します。continue
を指定して失敗したクラスターをスキップし、他のクラスターのアップグレードを続行するか、abort
を指定してすべてのクラスターのポリシー修正を停止することができます。タイムアウトが経過すると、TALM はすべての強制ポリシーを削除して、クラスターがそれ以上更新されないようにします。
アップグレードポリシーの例
apiVersion: policy.open-cluster-management.io/v1 kind: Policy metadata: name: ocp-4.4.14.4 namespace: platform-upgrade spec: disabled: false policy-templates: - objectDefinition: apiVersion: policy.open-cluster-management.io/v1 kind: ConfigurationPolicy metadata: name: upgrade spec: namespaceselector: exclude: - kube-* include: - '*' object-templates: - complianceType: musthave objectDefinition: apiVersion: config.openshift.io/v1 kind: ClusterVersion metadata: name: version spec: channel: stable-4.14 desiredUpdate: version: 4.4.14.4 upstream: https://api.openshift.com/api/upgrades_info/v1/graph status: history: - state: Completed version: 4.4.14.4 remediationAction: inform severity: low remediationAction: inform
RHACM ポリシーの詳細は、ポリシーの概要 を参照してください。
関連情報
PolicyGenTemplate
CRD の詳細は、About the PolicyGenTemplate CRD を参照してください。
18.11.6.1. TALM を使用してインストールするマネージドクラスターの Operator サブスクリプションの設定
Topology Aware Lifecycle Manager (TALM) は、Operator の Subscription
カスタムリソース (CR) に status.state.AtlatestKnown
フィールドが含まれている場合に限り、Operator のインストールプランを承認できます。
手順
Operator の
Subscription
CR に、status.state.AtlatestKnown
フィールドを追加します。Subscription CR の例
apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: cluster-logging namespace: openshift-logging annotations: ran.openshift.io/ztp-deploy-wave: "2" spec: channel: "stable" name: cluster-logging source: redhat-operators sourceNamespace: openshift-marketplace installPlanApproval: Manual status: state: AtLatestKnown 1
- 1
status.state: AtlatestKnown
フィールドは、Operator カタログから入手可能な Operator の最新バージョンに使用されます。
注記新しいバージョンの Operator がレジストリーで利用可能になると、関連するポリシーが非準拠になります。
-
ClusterGroupUpgrade
CR を使用して、変更したSubscription
ポリシーをマネージドクラスターに適用します。
18.11.6.2. マネージドクラスターへの更新ポリシーの適用
ポリシーを適用してマネージドクラスターを更新できます。
前提条件
- Topology Aware Lifecycle Manager (TALM) をインストールしている。
- 1 つ以上のマネージドクラスターをプロビジョニングします。
-
cluster-admin
権限を持つユーザーとしてログインしている。 - ハブクラスターで RHACM ポリシーを作成している。
手順
ClusterGroupUpgrade
CR の内容をcgu-1.yaml
ファイルに保存します。apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: name: cgu-1 namespace: default spec: managedPolicies: 1 - policy1-common-cluster-version-policy - policy2-common-nto-sub-policy - policy3-common-ptp-sub-policy - policy4-common-sriov-sub-policy enable: false clusters: 2 - spoke1 - spoke2 - spoke5 - spoke6 remediationStrategy: maxConcurrency: 2 3 timeout: 240 4 batchTimeoutAction: 5
以下のコマンドを実行して
ClusterGroupUpgrade
CR を作成します。$ oc create -f cgu-1.yaml
以下のコマンドを実行して、
ClusterGroupUpgrade
CR がハブクラスターに作成されていることを確認します。$ oc get cgu --all-namespaces
出力例
NAMESPACE NAME AGE STATE DETAILS default cgu-1 8m55 NotEnabled Not Enabled
以下のコマンドを実行して更新のステータスを確認します。
$ oc get cgu -n default cgu-1 -ojsonpath='{.status}' | jq
出力例
{ "computedMaxConcurrency": 2, "conditions": [ { "lastTransitionTime": "2022-02-25T15:34:07Z", "message": "Not enabled", 1 "reason": "NotEnabled", "status": "False", "type": "Progressing" } ], "copiedPolicies": [ "cgu-policy1-common-cluster-version-policy", "cgu-policy2-common-nto-sub-policy", "cgu-policy3-common-ptp-sub-policy", "cgu-policy4-common-sriov-sub-policy" ], "managedPoliciesContent": { "policy1-common-cluster-version-policy": "null", "policy2-common-nto-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"node-tuning-operator\",\"namespace\":\"openshift-cluster-node-tuning-operator\"}]", "policy3-common-ptp-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"ptp-operator-subscription\",\"namespace\":\"openshift-ptp\"}]", "policy4-common-sriov-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"sriov-network-operator-subscription\",\"namespace\":\"openshift-sriov-network-operator\"}]" }, "managedPoliciesForUpgrade": [ { "name": "policy1-common-cluster-version-policy", "namespace": "default" }, { "name": "policy2-common-nto-sub-policy", "namespace": "default" }, { "name": "policy3-common-ptp-sub-policy", "namespace": "default" }, { "name": "policy4-common-sriov-sub-policy", "namespace": "default" } ], "managedPoliciesNs": { "policy1-common-cluster-version-policy": "default", "policy2-common-nto-sub-policy": "default", "policy3-common-ptp-sub-policy": "default", "policy4-common-sriov-sub-policy": "default" }, "placementBindings": [ "cgu-policy1-common-cluster-version-policy", "cgu-policy2-common-nto-sub-policy", "cgu-policy3-common-ptp-sub-policy", "cgu-policy4-common-sriov-sub-policy" ], "placementRules": [ "cgu-policy1-common-cluster-version-policy", "cgu-policy2-common-nto-sub-policy", "cgu-policy3-common-ptp-sub-policy", "cgu-policy4-common-sriov-sub-policy" ], "precaching": { "spec": {} }, "remediationPlan": [ [ "spoke1", "spoke2" ], [ "spoke5", "spoke6" ] ], "status": {} }
- 1
ClusterGroupUpgrade
CR のspec.enable
フィールドはfalse
に設定されます。
以下のコマンドを実行してポリシーのステータスを確認します。
$ oc get policies -A
出力例
NAMESPACE NAME REMEDIATION ACTION COMPLIANCE STATE AGE default cgu-policy1-common-cluster-version-policy enforce 17m 1 default cgu-policy2-common-nto-sub-policy enforce 17m default cgu-policy3-common-ptp-sub-policy enforce 17m default cgu-policy4-common-sriov-sub-policy enforce 17m default policy1-common-cluster-version-policy inform NonCompliant 15h default policy2-common-nto-sub-policy inform NonCompliant 15h default policy3-common-ptp-sub-policy inform NonCompliant 18m default policy4-common-sriov-sub-policy inform NonCompliant 18m
- 1
- 現在クラスターに適用されるポリシーの
spec.remediationAction
フィールドは、enforce
に設定されます。ClusterGroupUpgrade
CR からのinform
モードのマネージドポリシーは、更新中もinform
モードで残ります。
以下のコマンドを実行して、
spec.enable
フィールドの値をtrue
に変更します。$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-1 \ --patch '{"spec":{"enable":true}}' --type=merge
検証
以下のコマンドを実行して更新のステータスを再度確認します。
$ oc get cgu -n default cgu-1 -ojsonpath='{.status}' | jq
出力例
{ "computedMaxConcurrency": 2, "conditions": [ 1 { "lastTransitionTime": "2022-02-25T15:33:07Z", "message": "All selected clusters are valid", "reason": "ClusterSelectionCompleted", "status": "True", "type": "ClustersSelected", "lastTransitionTime": "2022-02-25T15:33:07Z", "message": "Completed validation", "reason": "ValidationCompleted", "status": "True", "type": "Validated", "lastTransitionTime": "2022-02-25T15:34:07Z", "message": "Remediating non-compliant policies", "reason": "InProgress", "status": "True", "type": "Progressing" } ], "copiedPolicies": [ "cgu-policy1-common-cluster-version-policy", "cgu-policy2-common-nto-sub-policy", "cgu-policy3-common-ptp-sub-policy", "cgu-policy4-common-sriov-sub-policy" ], "managedPoliciesContent": { "policy1-common-cluster-version-policy": "null", "policy2-common-nto-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"node-tuning-operator\",\"namespace\":\"openshift-cluster-node-tuning-operator\"}]", "policy3-common-ptp-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"ptp-operator-subscription\",\"namespace\":\"openshift-ptp\"}]", "policy4-common-sriov-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"sriov-network-operator-subscription\",\"namespace\":\"openshift-sriov-network-operator\"}]" }, "managedPoliciesForUpgrade": [ { "name": "policy1-common-cluster-version-policy", "namespace": "default" }, { "name": "policy2-common-nto-sub-policy", "namespace": "default" }, { "name": "policy3-common-ptp-sub-policy", "namespace": "default" }, { "name": "policy4-common-sriov-sub-policy", "namespace": "default" } ], "managedPoliciesNs": { "policy1-common-cluster-version-policy": "default", "policy2-common-nto-sub-policy": "default", "policy3-common-ptp-sub-policy": "default", "policy4-common-sriov-sub-policy": "default" }, "placementBindings": [ "cgu-policy1-common-cluster-version-policy", "cgu-policy2-common-nto-sub-policy", "cgu-policy3-common-ptp-sub-policy", "cgu-policy4-common-sriov-sub-policy" ], "placementRules": [ "cgu-policy1-common-cluster-version-policy", "cgu-policy2-common-nto-sub-policy", "cgu-policy3-common-ptp-sub-policy", "cgu-policy4-common-sriov-sub-policy" ], "precaching": { "spec": {} }, "remediationPlan": [ [ "spoke1", "spoke2" ], [ "spoke5", "spoke6" ] ], "status": { "currentBatch": 1, "currentBatchStartedAt": "2022-02-25T15:54:16Z", "remediationPlanForBatch": { "spoke1": 0, "spoke2": 1 }, "startedAt": "2022-02-25T15:54:16Z" } }
- 1
- 現在のバッチの更新の進捗を反映します。このコマンドを再度実行して、進捗に関する更新情報を取得します。
ポリシーに Operator サブスクリプションが含まれる場合、インストールの進捗を単一ノードクラスターで直接確認できます。
以下のコマンドを実行して、インストールの進捗を確認するシングルノードクラスターの
KUBECONFIG
ファイルをエクスポートします。$ export KUBECONFIG=<cluster_kubeconfig_absolute_path>
シングルノードクラスターに存在するすべてのサブスクリプションを確認し、以下のコマンドを実行し、
ClusterGroupUpgrade
CR でインストールしようとしているポリシーを探します。$ oc get subs -A | grep -i <subscription_name>
cluster-logging
ポリシーの出力例NAMESPACE NAME PACKAGE SOURCE CHANNEL openshift-logging cluster-logging cluster-logging redhat-operators stable
管理ポリシーの 1 つに
ClusterVersion
CR が含まれる場合は、スポーククラスターに対して以下のコマンドを実行して、現在のバッチでプラットフォーム更新のステータスを確認します。$ oc get clusterversion
出力例
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.4.14.5 True True 43s Working towards 4.4.14.7: 71 of 735 done (9% complete)
以下のコマンドを実行して Operator サブスクリプションを確認します。
$ oc get subs -n <operator-namespace> <operator-subscription> -ojsonpath="{.status}"
以下のコマンドを実行して、必要なサブスクリプションに関連付けられているシングルノードのクラスターに存在するインストール計画を確認します。
$ oc get installplan -n <subscription_namespace>
cluster-logging
Operator の出力例NAMESPACE NAME CSV APPROVAL APPROVED openshift-logging install-6khtw cluster-logging.5.3.3-4 Manual true 1
- 1
- インストール計画の
Approval
フィールドはManual
に設定されており、TALM がインストール計画を承認すると、Approved
フィールドはfalse
からtrue
に変わります。
注記TALM がサブスクリプションを含むポリシーを修復している場合、そのサブスクリプションに関連付けられているすべてのインストールプランが自動的に承認されます。オペレーターが最新の既知のバージョンに到達するために複数のインストールプランが必要な場合、TALM は複数のインストールプランを承認し、最終バージョンに到達するために 1 つ以上の中間バージョンをアップグレードします。
以下のコマンドを実行して、
ClusterGroupUpgrade
がインストールしているポリシーの Operator のクラスターサービスバージョンがSucceeded
フェーズに到達したかどうかを確認します。$ oc get csv -n <operator_namespace>
OpenShift Logging Operator の出力例
NAME DISPLAY VERSION REPLACES PHASE cluster-logging.5.4.2 Red Hat OpenShift Logging 5.4.2 Succeeded
18.11.7. アップグレード前のクラスターリソースのバックアップの作成
シングルノード OpenShift の場合、Topology Aware Lifecycle Manager (TALM) は、アップグレード前にデプロイメントのバックアップを作成できます。アップグレードが失敗した場合は、以前のバージョンを回復し、アプリケーションの再プロビジョニングを必要とせずにクラスターを動作状態に復元できます。
バックアップ機能を使用するには、最初に backup
フィールドを true
に設定して ClusterGroupUpgrade
CR を作成します。バックアップの内容が最新であることを確認するために、ClusterGroupUpgrade
CR の enable
フィールドを true
に設定するまで、バックアップは取得されません。
TALM は BackupSucceeded
条件を使用して、ステータスと理由を次のように報告します。
true
すべてのクラスターのバックアップが完了したか、バックアップの実行が完了したが、1 つ以上のクラスターで失敗しました。いずれかのクラスターでバックアップが失敗した場合、そのクラスターの更新は続行されません。
false
1 つ以上のクラスターのバックアップがまだ進行中か、すべてのクラスターのバックアップが失敗しました。スポーククラスターで実行されているバックアッププロセスには、次のステータスがあります。
PreparingToStart
最初の調整パスが進行中です。TALM は、失敗したアップグレード試行で作成されたスポークバックアップネームスペースとハブビューリソースをすべて削除します。
Starting
バックアップの前提条件とバックアップジョブを作成しています。
Active
バックアップが進行中です。
Succeeded
バックアップは成功しました。
BackupTimeout
アーティファクトのバックアップは部分的に行われます。
UnrecoverableError
バックアップはゼロ以外の終了コードで終了しました。
クラスターのバックアップが失敗し、BackupTimeout
または UnrecoverableError
状態になると、そのクラスターのクラスター更新は続行されません。他のクラスターへの更新は影響を受けず、続行されます。
18.11.7.1. バックアップを含む ClusterGroupUpgrade CR の作成
シングルノード OpenShift クラスターでアップグレードする前に、デプロイメントのバックアップを作成できます。アップグレードが失敗した場合は、Topology Aware Lifecycle Manager (TALM) によって生成された upgrade-recovery.sh
スクリプトを使用して、システムをアップグレード前の状態に戻すことができます。バックアップは次の項目で構成されています。
- クラスターのバックアップ
-
etcd
と静的 Pod マニフェストのスナップショット。 - コンテンツのバックアップ
-
/etc
、/usr/local
、/var/lib/kubelet
などのフォルダーのバックアップ。 - 変更されたファイルのバックアップ
-
変更された
machine-config
によって管理されるすべてのファイル。 - Deployment
-
固定された
ostree
デプロイメント。 - イメージ (オプション)
- 使用中のコンテナーイメージ。
前提条件
- Topology Aware Lifecycle Manager (TALM) をインストールしている。
- 1 つ以上のマネージドクラスターをプロビジョニングします。
-
cluster-admin
権限を持つユーザーとしてログインしている。 - Red Hat Advanced Cluster Management 2.2.4 をインストールします。
リカバリーパーティションを作成することを強く推奨します。以下は、50 GB のリカバリーパーティションの SiteConfig
カスタムリソース (CR) の例です。
nodes: - hostName: "node-1.example.com" role: "master" rootDeviceHints: hctl: "0:2:0:0" deviceName: /dev/disk/by-id/scsi-3600508b400105e210000900000490000 ... #Disk /dev/disk/by-id/scsi-3600508b400105e210000900000490000: #893.3 GiB, 959119884288 bytes, 1873281024 sectors diskPartition: - device: /dev/disk/by-id/scsi-3600508b400105e210000900000490000 partitions: - mount_point: /var/recovery size: 51200 start: 800000
手順
clustergroupupgrades-group-du.yaml
ファイルで、backup
フィールドとenable
フィールドをtrue
に設定して、ClusterGroupUpgrade
CR の内容を保存します。apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: name: du-upgrade-4918 namespace: ztp-group-du-sno spec: preCaching: true backup: true clusters: - cnfdb1 - cnfdb2 enable: true managedPolicies: - du-upgrade-platform-upgrade remediationStrategy: maxConcurrency: 2 timeout: 240
更新を開始するには、次のコマンドを実行して
ClusterGroupUpgrade
CR を適用します。$ oc apply -f clustergroupupgrades-group-du.yaml
検証
以下のコマンドを実行して、ハブクラスターのアップグレードのステータスを確認します。
$ oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'
出力例
{ "backup": { "clusters": [ "cnfdb2", "cnfdb1" ], "status": { "cnfdb1": "Succeeded", "cnfdb2": "Failed" 1 } }, "computedMaxConcurrency": 1, "conditions": [ { "lastTransitionTime": "2022-04-05T10:37:19Z", "message": "Backup failed for 1 cluster", 2 "reason": "PartiallyDone", 3 "status": "True", 4 "type": "Succeeded" } ], "precaching": { "spec": {} }, "status": {}
18.11.7.2. アップグレードが失敗した後のクラスターのリカバリー
クラスターのアップグレードが失敗した場合は、手動でクラスターにログインし、バックアップを使用してクラスターをアップグレード前の状態に戻すことができます。次の 2 つの段階があります。
- ロールバック
- 試行されたアップグレードにプラットフォーム OS 展開への変更が含まれていた場合は、回復スクリプトを実行する前に、以前のバージョンにロールバックする必要があります。
ロールバックは、TALM およびシングルノード OpenShift からのアップグレードにのみ適用されます。このプロセスは、他のアップグレードタイプからのロールバックには適用されません。
- 復元
- リカバリーはコンテナーをシャットダウンし、バックアップパーティションのファイルを使用してコンテナーを再起動し、クラスターを復元します。
前提条件
- Topology Aware Lifecycle Manager (TALM) をインストールしている。
- 1 つ以上のマネージドクラスターをプロビジョニングします。
- Red Hat Advanced Cluster Management 2.2.4 をインストールします。
-
cluster-admin
権限を持つユーザーとしてログインしている。 - バックアップ用に設定されたアップグレードを実行します。
手順
次のコマンドを実行して、以前に作成した
ClusterGroupUpgrade
カスタムリソース (CR) を削除します。$ oc delete cgu/du-upgrade-4918 -n ztp-group-du-sno
- リカバリーするクラスターにログインします。
次のコマンドを実行して、プラットフォーム OS の展開のステータスを確認します。
$ ostree admin status
出力例
[root@lab-test-spoke2-node-0 core]# ostree admin status * rhcos c038a8f08458bbed83a77ece033ad3c55597e3f64edad66ea12fda18cbdceaf9.0 Version: 49.84.202202230006-0 Pinned: yes 1 origin refspec: c038a8f08458bbed83a77ece033ad3c55597e3f64edad66ea12fda18cbdceaf9
- 1
- 現在の展開は固定されています。プラットフォーム OS 展開のロールバックは必要ありません。
[root@lab-test-spoke2-node-0 core]# ostree admin status * rhcos f750ff26f2d5550930ccbe17af61af47daafc8018cd9944f2a3a6269af26b0fa.0 Version: 410.84.202204050541-0 origin refspec: f750ff26f2d5550930ccbe17af61af47daafc8018cd9944f2a3a6269af26b0fa rhcos ad8f159f9dc4ea7e773fd9604c9a16be0fe9b266ae800ac8470f63abc39b52ca.0 (rollback) 1 Version: 410.84.202203290245-0 Pinned: yes 2 origin refspec: ad8f159f9dc4ea7e773fd9604c9a16be0fe9b266ae800ac8470f63abc39b52ca
プラットフォーム OS 展開のロールバックをトリガーするには、次のコマンドを実行します。
$ rpm-ostree rollback -r
復元の最初のフェーズでは、コンテナーをシャットダウンし、ファイルをバックアップパーティションから対象のディレクトリーに復元します。リカバリーを開始するには、次のコマンドを実行します。
$ /var/recovery/upgrade-recovery.sh
プロンプトが表示されたら、次のコマンドを実行してクラスターを再起動します。
$ systemctl reboot
再起動後、次のコマンドを実行してリカバリーを再開します。
$ /var/recovery/upgrade-recovery.sh --resume
リカバリーユーティリティーが失敗した場合は、--restart
オプションを使用して再試行できます。
$ /var/recovery/upgrade-recovery.sh --restart
検証
リカバリーのステータスを確認するには、次のコマンドを実行します。
$ oc get clusterversion,nodes,clusteroperator
出力例
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS clusterversion.config.openshift.io/version 4.4.14.23 True False 86d Cluster version is 4.4.14.23 1 NAME STATUS ROLES AGE VERSION node/lab-test-spoke1-node-0 Ready master,worker 86d v1.22.3+b93fd35 2 NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE clusteroperator.config.openshift.io/authentication 4.4.14.23 True False False 2d7h 3 clusteroperator.config.openshift.io/baremetal 4.4.14.23 True False False 86d ..............
18.11.8. コンテナーイメージ事前キャッシュ機能の使用
シングルノード OpenShift クラスターでは、コンテナーイメージレジストリーにアクセスするための帯域幅が制限されている可能性があり、更新が完了する前に、タイムアウトが発生する可能性があります。
更新の時間は TALM によって設定されていません。手動アプリケーションまたは外部自動化により、更新の開始時に ClusterGroupUpgrade
CR を適用できます。
コンテナーイメージの事前キャッシュは、ClusterGroupUpgrade
CR で preCaching
フィールドが true
に設定されている場合に起動します。
TALM は PrecacheSpecValid
条件を使用して、次のようにステータス情報を報告します。
true
事前キャッシュの仕様は有効で一貫性があります。
false
事前キャッシュの仕様は不完全です。
TALM は PrecachingSucceeded
条件を使用して、次のようにステータス情報を報告します。
true
TALM は事前キャッシュプロセスを完了しました。いずれかのクラスターで事前キャッシュが失敗した場合、そのクラスターの更新は失敗しますが、他のすべてのクラスターの更新は続行されます。クラスターの事前キャッシュが失敗した場合は、メッセージで通知されます。
false
1 つ以上のクラスターで事前キャッシュがまだ進行中か、すべてのクラスターで失敗しました。
事前キャッシュプロセスに成功すると、ポリシーの修復を開始できます。修復アクションは、enable
フィールドが true
に設定されている場合に開始されます。クラスターで事前キャッシュエラーが発生した場合、そのクラスターのアップグレードは失敗します。アップグレードプロセスは、事前キャッシュが成功した他のすべてのクラスターに対して続行されます。
事前キャッシュプロセスは、以下のステータスにあります。
NotStarted
これは、すべてのクラスターが
ClusterGroupUpgrade
CR の最初の調整パスで自動的に割り当てられる初期状態です。この状態では、TALM は、以前の不完全な更新から残ったスポーククラスターの事前キャッシュの namespace およびハブビューリソースを削除します。次に TALM は、スポーク前の namespace の新規のManagedClusterView
リソースを作成し、PrecachePreparing
状態の削除を確認します。PreparingToStart
以前の不完全な更新からの残りのリソースを消去すると進行中です。
Starting
キャッシュ前のジョブの前提条件およびジョブが作成されます。
Active
ジョブは "Active" の状態です。
Succeeded
事前キャッシュジョブが成功しました。
PrecacheTimeout
アーティファクトの事前キャッシュは部分的に行われます。
UnrecoverableError
ジョブはゼロ以外の終了コードで終了します。
18.11.8.1. コンテナーイメージの事前キャッシュフィルターの使用
通常、事前キャッシュ機能は、クラスターが更新に必要とするよりも多くのイメージをダウンロードします。どの事前キャッシュイメージをクラスターにダウンロードするかを制御できます。これにより、ダウンロード時間が短縮され、帯域幅とストレージが節約されます。
次のコマンドを使用して、ダウンロードするすべてのイメージのリストを表示できます。
$ oc adm release info <ocp-version>
次の ConfigMap
の例は、excludePrecachePatterns
フィールドを使用してイメージを除外する方法を示しています。
apiVersion: v1
kind: ConfigMap
metadata:
name: cluster-group-upgrade-overrides
data:
excludePrecachePatterns: |
azure 1
aws
vsphere
alibaba
- 1
- TALM は、ここにリストされているパターンのいずれかを含む名前を持つすべてのイメージを除外します。
18.11.8.2. 事前キャッシュでの ClusterGroupUpgrade CR の作成
シングルノード OpenShift の場合は、事前キャッシュ機能により、更新が開始する前に、必要なコンテナーイメージをスポーククラスターに配置できます。
事前キャッシュの場合、TALM は ClusterGroupUpgrade
CR の spec.remediationStrategy.timeout
値を使用します。事前キャッシュジョブが完了するのに十分な時間を与える timeout
値を設定する必要があります。事前キャッシュの完了後に ClusterGroupUpgrade
CR を有効にすると、timeout
値を更新に適した期間に変更できます。
前提条件
- Topology Aware Lifecycle Manager (TALM) をインストールしている。
- 1 つ以上のマネージドクラスターをプロビジョニングします。
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
clustergroupupgrades-group-du.yaml
ファイルでpreCaching
フィールドをtrue
に設定してClusterGroupUpgrade
CR の内容を保存します。apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: name: du-upgrade-4918 namespace: ztp-group-du-sno spec: preCaching: true 1 clusters: - cnfdb1 - cnfdb2 enable: false managedPolicies: - du-upgrade-platform-upgrade remediationStrategy: maxConcurrency: 2 timeout: 240
- 1
preCaching
フィールドはtrue
に設定されています。これにより、更新を開始する前に TALM がコンテナーイメージをプルできます。
事前キャッシュを開始する場合は、次のコマンドを実行して
ClusterGroupUpgrade
CR を適用します。$ oc apply -f clustergroupupgrades-group-du.yaml
検証
以下のコマンドを実行して、
ClusterGroupUpgrade
CR がハブクラスターに存在するかどうかを確認します。$ oc get cgu -A
出力例
NAMESPACE NAME AGE STATE DETAILS ztp-group-du-sno du-upgrade-4918 10s InProgress Precaching is required and not done 1
- 1
- CR が作成されます。
以下のコマンドを実行して、事前キャッシュタスクのステータスを確認します。
$ oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'
出力例
{ "conditions": [ { "lastTransitionTime": "2022-01-27T19:07:24Z", "message": "Precaching is required and not done", "reason": "InProgress", "status": "False", "type": "PrecachingSucceeded" }, { "lastTransitionTime": "2022-01-27T19:07:34Z", "message": "Pre-caching spec is valid and consistent", "reason": "PrecacheSpecIsWellFormed", "status": "True", "type": "PrecacheSpecValid" } ], "precaching": { "clusters": [ "cnfdb1" 1 "cnfdb2" ], "spec": { "platformImage": "image.example.io"}, "status": { "cnfdb1": "Active" "cnfdb2": "Succeeded"} } }
- 1
- 特定されたクラスターの一覧を表示します。
スポーククラスターで以下のコマンドを実行して、事前キャッシュジョブのステータスを確認します。
$ oc get jobs,pods -n openshift-talo-pre-cache
出力例
NAME COMPLETIONS DURATION AGE job.batch/pre-cache 0/1 3m10s 3m10s NAME READY STATUS RESTARTS AGE pod/pre-cache--1-9bmlr 1/1 Running 0 3m10s
以下のコマンドを実行して
ClusterGroupUpgrade
CR のステータスを確認します。$ oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'
出力例
"conditions": [ { "lastTransitionTime": "2022-01-27T19:30:41Z", "message": "The ClusterGroupUpgrade CR has all clusters compliant with all the managed policies", "reason": "UpgradeCompleted", "status": "True", "type": "Ready" }, { "lastTransitionTime": "2022-01-27T19:28:57Z", "message": "Precaching is completed", "reason": "PrecachingCompleted", "status": "True", "type": "PrecachingSucceeded" 1 }
- 1
- キャッシュ前のタスクが実行されます。
18.11.9. Topology Aware Lifecycle Manager のトラブルシューティング
Topology Aware Lifecycle Manager (TALM) は、RHACM ポリシーを修復する OpenShift Container Platform Operator です。問題が発生した場合には、oc adm must-gather
コマンドを使用して詳細およびログを収集し、問題のデバッグ手順を行います。
関連トピックの詳細は、以下のドキュメントを参照してください。
- Red Hat Advanced Cluster Management for Kubernetes 2.4 Support Matrix
- Red Hat Advanced Cluster Management Troubleshooting
- 「Operator の問題のトラブルシューティング」セクション
18.11.9.1. 一般的なトラブルシューティング
以下の質問を確認して、問題の原因を特定できます。
適用する設定がサポートされているか ?
- RHACM と OpenShift Container Platform のバージョンと互換性があるか ?
- TALM および RHACM のバージョンと互換性があるか ?
問題の原因となる以下のコンポーネントはどれですか ?
ClusterGroupUpgrade
設定が機能するようにするには、以下を実行できます。
-
spec.enable
フィールドをfalse
に設定してClusterGroupUpgrade
CR を作成します。 - ステータスが更新され、トラブルシューティングの質問を確認するのを待ちます。
-
すべてが予想通りに機能する場合は、
ClusterGroupUpgrade
CR でspec.enable
フィールドをtrue
に設定します。
ClusterUpgradeGroup
CR で spec.enable
フィールドを true
に設定すると、更新手順が起動し、CR の spec
フィールドを編集することができなくなります。
18.11.9.2. ClusterUpgradeGroup CR を変更できません。
- 問題
-
更新を有効にした後に、
ClusterUpgradeGroup
CR を編集することはできません。 - 解決方法
以下の手順を実行して手順を再起動します。
以下のコマンドを実行して古い
ClusterGroupUpgrade
CR を削除します。$ oc delete cgu -n <ClusterGroupUpgradeCR_namespace> <ClusterGroupUpgradeCR_name>
マネージドクラスターおよびポリシーに関する既存の問題を確認し、修正します。
- すべてのクラスターがマネージドクラスターで、利用可能であることを確認します。
-
すべてのポリシーが存在し、
spec.remediationAction
フィールドがinform
に設定されていることを確認します。
正しい設定で新規の
ClusterGroupUpgrade
CR を作成します。$ oc apply -f <ClusterGroupUpgradeCR_YAML>
18.11.9.3. 管理ポリシー
システムでの管理ポリシーの確認
- 問題
- システムで正しい管理ポリシーがあるかどうかをチェックする。
- 解決方法
以下のコマンドを実行します。
$ oc get cgu lab-upgrade -ojsonpath='{.spec.managedPolicies}'
出力例
["group-du-sno-validator-du-validator-policy", "policy2-common-nto-sub-policy", "policy3-common-ptp-sub-policy"]
remediationAction モードの確認
- 問題
-
remediationAction
フィールドが、管理ポリシーのspec
でinform
に設定されているかどうかを確認する必要があります。 - 解決方法
以下のコマンドを実行します。
$ oc get policies --all-namespaces
出力例
NAMESPACE NAME REMEDIATION ACTION COMPLIANCE STATE AGE default policy1-common-cluster-version-policy inform NonCompliant 5d21h default policy2-common-nto-sub-policy inform Compliant 5d21h default policy3-common-ptp-sub-policy inform NonCompliant 5d21h default policy4-common-sriov-sub-policy inform NonCompliant 5d21h
ポリシーコンプライアンスの状態の確認
- 問題
- ポリシーのコンプライアンス状態を確認する。
- 解決方法
以下のコマンドを実行します。
$ oc get policies --all-namespaces
出力例
NAMESPACE NAME REMEDIATION ACTION COMPLIANCE STATE AGE default policy1-common-cluster-version-policy inform NonCompliant 5d21h default policy2-common-nto-sub-policy inform Compliant 5d21h default policy3-common-ptp-sub-policy inform NonCompliant 5d21h default policy4-common-sriov-sub-policy inform NonCompliant 5d21h
18.11.9.4. クラスター
マネージドクラスターが存在するかどうかの確認
- 問題
-
ClusterGroupUpgrade
CR のクラスターがマネージドクラスターかどうかを確認します。 - 解決方法
以下のコマンドを実行します。
$ oc get managedclusters
出力例
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE local-cluster true https://api.hub.example.com:6443 True Unknown 13d spoke1 true https://api.spoke1.example.com:6443 True True 13d spoke3 true https://api.spoke3.example.com:6443 True True 27h
または、TALM マネージャーログを確認します。
以下のコマンドを実行して、TALM マネージャーの名前を取得します。
$ oc get pod -n openshift-operators
出力例
NAME READY STATUS RESTARTS AGE cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp 2/2 Running 0 45m
以下のコマンドを実行して、TALM マネージャーログを確認します。
$ oc logs -n openshift-operators \ cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp -c manager
出力例
ERROR controller-runtime.manager.controller.clustergroupupgrade Reconciler error {"reconciler group": "ran.openshift.io", "reconciler kind": "ClusterGroupUpgrade", "name": "lab-upgrade", "namespace": "default", "error": "Cluster spoke5555 is not a ManagedCluster"} 1 sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
- 1
- エラーメッセージには、クラスターがマネージドクラスターではないことが分かります。
マネージドクラスターが利用可能かどうかの確認
- 問題
-
ClusterGroupUpgrade
CR で指定されたマネージドクラスターが利用可能かどうかを確認する必要があります。 - 解決方法
以下のコマンドを実行します。
$ oc get managedclusters
出力例
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE local-cluster true https://api.hub.testlab.com:6443 True Unknown 13d spoke1 true https://api.spoke1.testlab.com:6443 True True 13d 1 spoke3 true https://api.spoke3.testlab.com:6443 True True 27h 2
clusterLabelSelector のチェック
- 問題
-
ClusterGroupUpgrade
CR で指定されたclusterLabelSelector
フィールドが、マネージドクラスターの少なくとも 1 つと一致するか確認します。 - 解決方法
以下のコマンドを実行します。
$ oc get managedcluster --selector=upgrade=true 1
- 1
- 更新するクラスターのラベルは
upgrade:true
です。
出力例
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE spoke1 true https://api.spoke1.testlab.com:6443 True True 13d spoke3 true https://api.spoke3.testlab.com:6443 True True 27h
カナリアクラスターが存在するかどうかの確認
- 問題
カナリアクラスターがクラスターのリストに存在するかどうかを確認します。
ClusterGroupUpgrade
CR の例spec: remediationStrategy: canaries: - spoke3 maxConcurrency: 2 timeout: 240 clusterLabelSelectors: - matchLabels: upgrade: true
- 解決方法
以下のコマンドを実行します。
$ oc get cgu lab-upgrade -ojsonpath='{.spec.clusters}'
出力例
["spoke1", "spoke3"]
以下のコマンドを実行して、カナリアクラスターが
clusterLabelSelector
ラベルに一致するクラスターの一覧に存在するかどうかを確認します。$ oc get managedcluster --selector=upgrade=true
出力例
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE spoke1 true https://api.spoke1.testlab.com:6443 True True 13d spoke3 true https://api.spoke3.testlab.com:6443 True True 27h
クラスターは、spec.clusters
に存在し、spec.clusterLabelSelector
ラベルによって一致する場合もあります。
スポーククラスターでの事前キャッシュステータスの確認
スポーククラスターで以下のコマンドを実行して、事前キャッシュのステータスを確認します。
$ oc get jobs,pods -n openshift-talo-pre-cache
18.11.9.5. 修復ストラテジー
remediationStrategy が ClusterGroupUpgrade CR に存在するかどうかの確認
- 問題
-
remediationStrategy
がClusterGroupUpgrade
CR に存在するかどうかを確認します。 - 解決方法
以下のコマンドを実行します。
$ oc get cgu lab-upgrade -ojsonpath='{.spec.remediationStrategy}'
出力例
{"maxConcurrency":2, "timeout":240}
ClusterGroupUpgrade CR に maxConcurrency が指定されているかどうかの確認
- 問題
-
maxConcurrency
がClusterGroupUpgrade
CR で指定されているかどうかを確認する必要があります。 - 解決方法
以下のコマンドを実行します。
$ oc get cgu lab-upgrade -ojsonpath='{.spec.remediationStrategy.maxConcurrency}'
出力例
2
18.11.9.6. Topology Aware Lifecycle Manager
ClusterGroupUpgrade CR での条件メッセージおよびステータスの確認
- 問題
-
ClusterGroupUpgrade
CR のstatus.conditions
フィールドの値を確認する必要がある場合があります。 - 解決方法
以下のコマンドを実行します。
$ oc get cgu lab-upgrade -ojsonpath='{.status.conditions}'
出力例
{"lastTransitionTime":"2022-02-17T22:25:28Z", "message":"Missing managed policies:[policyList]", "reason":"NotAllManagedPoliciesExist", "status":"False", "type":"Validated"}
対応するコピーされたポリシーの確認
- 問題
-
status.managedPoliciesForUpgrade
からのすべてのポリシーにstatus.copiedPolicies
に対応するポリシーがあるかどうかを確認します。 - 解決方法
以下のコマンドを実行します。
$ oc get cgu lab-upgrade -oyaml
出力例
status: … copiedPolicies: - lab-upgrade-policy3-common-ptp-sub-policy managedPoliciesForUpgrade: - name: policy3-common-ptp-sub-policy namespace: default
status.remediationPlan が計算されたかどうかの確認
- 問題
-
status.remediationPlan
が計算されているかどうかを確認します。 - 解決方法
以下のコマンドを実行します。
$ oc get cgu lab-upgrade -ojsonpath='{.status.remediationPlan}'
出力例
[["spoke2", "spoke3"]]
TALM マネージャーコンテナーのエラー
- 問題
- TALM のマネージャーコンテナーのログを確認する必要がある場合があります。
- 解決方法
以下のコマンドを実行します。
$ oc logs -n openshift-operators \ cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp -c manager
出力例
ERROR controller-runtime.manager.controller.clustergroupupgrade Reconciler error {"reconciler group": "ran.openshift.io", "reconciler kind": "ClusterGroupUpgrade", "name": "lab-upgrade", "namespace": "default", "error": "Cluster spoke5555 is not a ManagedCluster"} 1 sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
- 1
- エラーを表示します。
ClusterGroupUpgrade
CR が完了した後、クラスターが一部のポリシーに準拠していない
- 問題
修復が必要かどうかを判断するために TALM が使用するポリシーコンプライアンスステータスは、まだすべてのクラスターで完全に更新されていません。これには次の理由が考えられます。
- ポリシーの作成または更新後、CGU の実行が早すぎました。
-
ポリシーの修復は、
ClusterGroupUpgrade
CR の後続のポリシーのコンプライアンスに影響します。
- 解決方法
-
同じ仕様で新しい
ClusterGroupUpdate
CR を作成して適用します。
GitOps ZTP ワークフローで自動作成された ClusterGroupUpgrade
CR に管理ポリシーがない
- 問題
-
クラスターが
Ready
になったときにマネージドクラスターのポリシーがない場合、ポリシーのないClusterGroupUpgrade
CR が自動作成されます。ClusterGroupUpgrade
CR が完了すると、マネージドクラスターにはztp-done
というラベルが付けられます。SiteConfig
リソースがプッシュされた後、必要な時間内にPolicyGenTemplate
CR が Git リポジトリーにプッシュされなかった場合、クラスターがReady
になったときに、ターゲットクラスターで使用できるポリシーがなくなる可能性があります。 - 解決方法
-
適用するポリシーがハブクラスターで使用可能であることを確認してから、必要なポリシーを使用して
ClusterGroupUpgrade
CR を作成します。
ClusterGroupUpgrade
CR を手動で作成するか、自動作成を再度トリガーすることができます。ClusterGroupUpgrade
CR の自動作成をトリガーするには、クラスターから ztp-done
ラベルを削除し、以前に zip-install
namespace で作成された空の ClusterGroupUpgrade
CR を削除します。
事前キャッシュに失敗しました
- 問題
事前キャッシュは、次のいずれかの理由で失敗する場合があります。
- ノードに十分な空き容量がありません。
- 非接続環境では、事前キャッシュイメージが適切にミラーリングされていません。
- Pod の作成中に問題が発生しました。
- 解決方法
スペース不足のために事前キャッシュが失敗したかどうかを確認するには、ノードの事前キャッシュ Pod のログを確認します。
次のコマンドを使用して Pod の名前を見つけます。
$ oc get pods -n openshift-talo-pre-cache
次のコマンドを使用してログをチェックし、エラーが容量不足に関連しているかどうかを確認します。
$ oc logs -n openshift-talo-pre-cache <pod name>
ログがない場合は、次のコマンドを使用して Pod のステータスを確認します。
$ oc describe pod -n openshift-talo-pre-cache <pod name>
Pod が存在しない場合は、次のコマンドを使用してジョブのステータスをチェックし、Pod を作成できなかった理由を確認します。
$ oc describe job -n openshift-talo-pre-cache pre-cache
関連情報
- トラブルシューティングに関する詳細は、Operator 関連の問題の OpenShift Container Platform トラブルシューティング を参照してください。
- ZTP ワークフローで Topology Aware Lifecycle Manager を使用する方法の詳細については、Topology Aware Lifecycle Manager を使用した管理ポリシーの更新 を参照してください。
-
PolicyGenTemplate
CRD の詳細は、About the PolicyGenTemplate CRD を参照してください。