サポートコンソール開発者トライアルの開始お問い合わせ

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 権限を持つユーザーとしてログインしている。

手順

  1. OpenShift Container Platform Web コンソールで、Operators OperatorHub ページに移動します。
  2. 利用可能な Operator のリストから Topology Aware Lifecycle Manager を検索し、Install をクリックします。
  3. Installation mode ["All namespaces on the cluster (default)"] および Installed Namespace ("openshift-operators") のデフォルトの選択を維持し、Operator が適切にインストールされていることを確認します。
  4. Install をクリックします。

検証

インストールが正常に行われたことを確認するには、以下を実行します。

  1. Operators Installed Operators ページに移動します。
  2. Operator が All Namespaces ネームスペースにインストールされ、そのステータスが Succeeded であることを確認します。

Operator が正常にインストールされていない場合、以下を実行します。

  1. Operators Installed Operators ページに移動し、Status 列でエラーまたは失敗の有無を確認します。
  2. 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 権限を持つユーザーとしてログインしている。

手順

  1. Subscription CR を作成します。

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

    2. 以下のコマンドを実行して Subscription CR を作成します。 

      $ oc create -f talm-subscription.yaml

検証

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

  2. 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'

2
Progressing フィールドでは、更新が完了したため、ステータスは false です。クラスターはすべての管理ポリシーに準拠しています。
3
Succeeded フィールドは、検証が正常に完了したことを示しています。
1
status フィールドには、クラスターのリストとそれぞれのステータスが含まれます。クラスターのステータスは、complete または timedout です。

タイムアウト 状態の 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'

1
クラスターの状態が timedout の場合、currentPolicy フィールドにはポリシーの名前とポリシーのステータスが表示されます。
2
succeeded のステータスは false であり、ポリシーの修復に時間がかかりすぎたことを示すメッセージが表示されます。

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 ポリシーを作成している。

手順

  1. 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 の更新を開始します。

  2. 関連する CR ごとに以下のコマンドを実行して ClusterGroupUpgrade CR を作成します。 

    $ oc apply -f <name>.yaml

  3. 関連する各 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 のインストールプランを承認できます。

手順

  1. 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 がレジストリーで利用可能になると、関連するポリシーが非準拠になります。

  2. ClusterGroupUpgrade CR を使用して、変更した Subscription ポリシーをマネージドクラスターに適用します。

18.11.6.2. マネージドクラスターへの更新ポリシーの適用

ポリシーを適用してマネージドクラスターを更新できます。

前提条件

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

手順

  1. 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
    1
    適用するポリシーの名前。
    2
    更新するクラスターのリスト。
    3
    maxConcurrency フィールドは、同時に更新されるクラスターの数を示します。
    4
    更新のタイムアウト (分単位)。
    5
    バッチがタイムアウトした場合の動作を制御します。可能な値は abort または continue です。指定しない場合、デフォルトは continue です。

  2. 以下のコマンドを実行して ClusterGroupUpgrade CR を作成します。 

    $ oc create -f cgu-1.yaml

    1. 以下のコマンドを実行して、ClusterGroupUpgrade CR がハブクラスターに作成されていることを確認します。 

      $ oc get cgu --all-namespaces

      出力例

      NAMESPACE   NAME  AGE  STATE      DETAILS
default     cgu-1 8m55 NotEnabled Not Enabled

    2. 以下のコマンドを実行して更新のステータスを確認します。 

      $ 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 に設定されます。

    3. 以下のコマンドを実行してポリシーのステータスを確認します。 

      $ 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 モードで残ります。

  3. 以下のコマンドを実行して、spec.enable フィールドの値を true に変更します。 

    $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-1 \
--patch '{"spec":{"enable":true}}' --type=merge

検証

  1. 以下のコマンドを実行して更新のステータスを再度確認します。 

    $ 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
    現在のバッチの更新の進捗を反映します。このコマンドを再度実行して、進捗に関する更新情報を取得します。

  2. ポリシーに Operator サブスクリプションが含まれる場合、インストールの進捗を単一ノードクラスターで直接確認できます。

    1. 以下のコマンドを実行して、インストールの進捗を確認するシングルノードクラスターの KUBECONFIG ファイルをエクスポートします。 

      $ export KUBECONFIG=<cluster_kubeconfig_absolute_path>

    2. シングルノードクラスターに存在するすべてのサブスクリプションを確認し、以下のコマンドを実行し、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

  3. 管理ポリシーの 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)

  4. 以下のコマンドを実行して Operator サブスクリプションを確認します。 

    $ oc get subs -n <operator-namespace> <operator-subscription> -ojsonpath="{.status}"

  5. 以下のコマンドを実行して、必要なサブスクリプションに関連付けられているシングルノードのクラスターに存在するインストール計画を確認します。 

    $ 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 つ以上の中間バージョンをアップグレードします。

  6. 以下のコマンドを実行して、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

手順

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

  2. 更新を開始するには、次のコマンドを実行して 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": {}

    1
    1 つのクラスターのバックアップが失敗しました。
    2
    このメッセージは、1 つのクラスターのバックアップが失敗したことを確認します。
    3
    バックアップは部分的に成功しました。
    4
    バックアッププロセスが終了しました。

18.11.7.2. アップグレードが失敗した後のクラスターのリカバリー

クラスターのアップグレードが失敗した場合は、手動でクラスターにログインし、バックアップを使用してクラスターをアップグレード前の状態に戻すことができます。次の 2 つの段階があります。

ロールバック
試行されたアップグレードにプラットフォーム OS 展開への変更が含まれていた場合は、回復スクリプトを実行する前に、以前のバージョンにロールバックする必要があります。
重要

ロールバックは、TALM およびシングルノード OpenShift からのアップグレードにのみ適用されます。このプロセスは、他のアップグレードタイプからのロールバックには適用されません。

復元
リカバリーはコンテナーをシャットダウンし、バックアップパーティションのファイルを使用してコンテナーを再起動し、クラスターを復元します。

前提条件

  • Topology Aware Lifecycle Manager (TALM) をインストールしている。
  • 1 つ以上のマネージドクラスターをプロビジョニングします。
  • Red Hat Advanced Cluster Management 2.2.4 をインストールします。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • バックアップ用に設定されたアップグレードを実行します。

手順

  1. 次のコマンドを実行して、以前に作成した ClusterGroupUpgrade カスタムリソース (CR) を削除します。 

    $ oc delete cgu/du-upgrade-4918 -n ztp-group-du-sno
  2. リカバリーするクラスターにログインします。

  3. 次のコマンドを実行して、プラットフォーム 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
    1
    このプラットフォーム OS の展開は、ロールバックの対象としてマークされています。
    2
    以前の展開は固定されており、ロールバックできます。

  4. プラットフォーム OS 展開のロールバックをトリガーするには、次のコマンドを実行します。 

    $ rpm-ostree rollback -r

  5. 復元の最初のフェーズでは、コンテナーをシャットダウンし、ファイルをバックアップパーティションから対象のディレクトリーに復元します。リカバリーを開始するには、次のコマンドを実行します。 

    $ /var/recovery/upgrade-recovery.sh

  6. プロンプトが表示されたら、次のコマンドを実行してクラスターを再起動します。 

    $ systemctl reboot

  7. 再起動後、次のコマンドを実行してリカバリーを再開します。 

    $ /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


..............

    1
    クラスターのバージョンが利用可能であり、正しいバージョンを持っています。
    2
    ノードのステータスは Ready です。
    3
    ClusterOperator オブジェクトの可用性は True です。

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 権限を持つユーザーとしてログインしている。

手順

  1. 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 がコンテナーイメージをプルできます。

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

    $ oc apply -f clustergroupupgrades-group-du.yaml

検証

  1. 以下のコマンドを実行して、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 が作成されます。

  2. 以下のコマンドを実行して、事前キャッシュタスクのステータスを確認します。 

    $ 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
    特定されたクラスターの一覧を表示します。

  3. スポーククラスターで以下のコマンドを実行して、事前キャッシュジョブのステータスを確認します。 

    $ 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

  4. 以下のコマンドを実行して 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 コマンドを使用して詳細およびログを収集し、問題のデバッグ手順を行います。

関連トピックの詳細は、以下のドキュメントを参照してください。

18.11.9.1. 一般的なトラブルシューティング

以下の質問を確認して、問題の原因を特定できます。

ClusterGroupUpgrade 設定が機能するようにするには、以下を実行できます。

  1. spec.enable フィールドを false に設定して ClusterGroupUpgrade CR を作成します。
  2. ステータスが更新され、トラブルシューティングの質問を確認するのを待ちます。
  3. すべてが予想通りに機能する場合は、ClusterGroupUpgrade CR で spec.enable フィールドを true に設定します。
警告

ClusterUpgradeGroup CR で spec.enable フィールドを true に設定すると、更新手順が起動し、CR の spec フィールドを編集することができなくなります。

18.11.9.2. ClusterUpgradeGroup CR を変更できません。

問題
更新を有効にした後に、ClusterUpgradeGroup CR を編集することはできません。
解決方法

以下の手順を実行して手順を再起動します。

  1. 以下のコマンドを実行して古い ClusterGroupUpgrade CR を削除します。 

    $ oc delete cgu -n <ClusterGroupUpgradeCR_namespace> <ClusterGroupUpgradeCR_name>

  2. マネージドクラスターおよびポリシーに関する既存の問題を確認し、修正します。

    1. すべてのクラスターがマネージドクラスターで、利用可能であることを確認します。
    2. すべてのポリシーが存在し、spec.remediationAction フィールドが inform に設定されていることを確認します。

  3. 正しい設定で新規の 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

  1. または、TALM マネージャーログを確認します。

    1. 以下のコマンドを実行して、TALM マネージャーの名前を取得します。 

      $ oc get pod -n openshift-operators

      出力例

      NAME                                                         READY   STATUS    RESTARTS   AGE
cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp   2/2     Running   0          45m

    2. 以下のコマンドを実行して、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

1 2
マネージドクラスターの AVAILABLE フィールドの値は True です。
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"]

  1. 以下のコマンドを実行して、カナリアクラスターが 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 ラベルによって一致する場合もあります。

スポーククラスターでの事前キャッシュステータスの確認

  1. スポーククラスターで以下のコマンドを実行して、事前キャッシュのステータスを確認します。 

    $ 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 の作成中に問題が発生しました。
解決方法

  1. スペース不足のために事前キャッシュが失敗したかどうかを確認するには、ノードの事前キャッシュ Pod のログを確認します。

    1. 次のコマンドを使用して Pod の名前を見つけます。 

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

    2. 次のコマンドを使用してログをチェックし、エラーが容量不足に関連しているかどうかを確認します。 

      $ oc logs -n openshift-talo-pre-cache <pod name>

  2. ログがない場合は、次のコマンドを使用して Pod のステータスを確認します。 

    $ oc describe pod -n openshift-talo-pre-cache <pod name>

  3. Pod が存在しない場合は、次のコマンドを使用してジョブのステータスをチェックし、Pod を作成できなかった理由を確認します。 

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

関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.