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

3.2. クラスターの更新の仕組み

以下のセクションでは、OpenShift Container Platform (OCP) 更新プロセスの各腫瘍点について詳しく説明しています。更新の仕組みの概要は、OpenShift 更新の概要 を参照してください。

3.2.1. 更新の可用性評価
リンクのコピー

Cluster Version Operator (CVO) は、OpenShift Update Service (OSUS) に対して、更新の可能性に関する最新データを定期的にクエリーします。このデータは、クラスターがサブスクライブしているチャネルに基づいています。次に、CVO は更新の推奨事項に関する情報を、ClusterVersion リソースの availableUpdates フィールドまたは conditionalUpdates フィールドに保存します。

CVO は、条件付き更新の更新リスクを定期的に確認します。これらのリスクは、OSUS によって提供されるデータを通じて伝えられます。このデータには、そのバージョンに更新されたクラスターに影響を与える可能性がある各バージョンの既知の問題に関する情報が含まれています。ほとんどのリスクは、特定のサイズのクラスターや特定のクラウドプラットフォームにデプロイされたクラスターなど、特定の特性を持つクラスターに限定されます。

CVO は、各条件付き更新の条件付きリスクに関する情報に対して、継続的にクラスターの特性を評価します。CVO は、クラスターが基準に一致することを検出すると、その情報を ClusterVersion リソースの conditionalUpdates フィールドに保存します。CVO は、クラスターが更新のリスクに一致しないこと、または更新に関連するリスクがないことを検出すると、ターゲットバージョンを ClusterVersion リソースの availableUpdates フィールドに保存します。

Web コンソールまたは OpenShift CLI (oc) のユーザーインターフェイスは、この情報をセクションの見出しで表示します。サポートされているが推奨されていない 更新の推奨事項には、管理者が情報に基づいて更新に関する決定を下せるように、リスクに関する詳細リソースへのリンクが含まれています。

以下のコマンドを使用して、利用可能なすべての更新を確認できます。 

$ oc adm upgrade --include-not-recommended
Copy to Clipboard Toggle word wrap

追加の --include-not-recommended パラメーターには、利用可能ではあるが、クラスターに適用される既知のリスクのため推奨されない更新が含まれます。

出力例

Cluster version is 4.10.22

Upstream is unset, so the cluster will use an appropriate default.
Channel: fast-4.11 (available channels: candidate-4.10, candidate-4.11, eus-4.10, fast-4.10, fast-4.11, stable-4.10)

Recommended updates:

  VERSION     IMAGE
  4.10.26     quay.io/openshift-release-dev/ocp-release@sha256:e1fa1f513068082d97d78be643c369398b0e6820afab708d26acda2262940954
  4.10.25     quay.io/openshift-release-dev/ocp-release@sha256:ed84fb3fbe026b3bbb4a2637ddd874452ac49c6ead1e15675f257e28664879cc
  4.10.24     quay.io/openshift-release-dev/ocp-release@sha256:aab51636460b5a9757b736a29bc92ada6e6e6282e46b06e6fd483063d590d62a
  4.10.23     quay.io/openshift-release-dev/ocp-release@sha256:e40e49d722cb36a95fa1c03002942b967ccbd7d68de10e003f0baa69abad457b

Supported but not recommended updates:

  Version: 4.11.0
  Image: quay.io/openshift-release-dev/ocp-release@sha256:300bce8246cf880e792e106607925de0a404484637627edf5f517375517d54a4
  Recommended: False
  Reason: RPMOSTreeTimeout
  Message: Nodes with substantial numbers of containers and CPU contention may not reconcile machine configuration https://bugzilla.redhat.com/show_bug.cgi?id=2111817#c22
Copy to Clipboard Toggle word wrap

CVO によって作成された基礎となる可用性データを検査する方法の 1 つに、次のコマンドを使用して ClusterVersion リソースをクエリーする方法があります。 

$ oc get clusterversion version -o json | jq '.status.availableUpdates'
Copy to Clipboard Toggle word wrap

出力例

[
  {
    "channels": [
      "candidate-4.11",
      "candidate-4.12",
      "fast-4.11",
      "fast-4.12"
    ],
    "image": "quay.io/openshift-release-dev/ocp-release@sha256:400267c7f4e61c6bfa0a59571467e8bd85c9188e442cbd820cc8263809be3775",
    "url": "https://access.redhat.com/errata/RHBA-2023:3213",
    "version": "4.11.41"
  },
  ...
]
Copy to Clipboard Toggle word wrap

同様のコマンドを使用して条件付き更新を確認できます。 

$ oc get clusterversion version -o json | jq '.status.conditionalUpdates'
Copy to Clipboard Toggle word wrap

出力例

[
  {
    "conditions": [
      {
        "lastTransitionTime": "2023-05-30T16:28:59Z",
        "message": "The 4.11.36 release only resolves an installation issue https://issues.redhat.com//browse/OCPBUGS-11663 , which does not affect already running clusters. 4.11.36 does not include fixes delivered in recent 4.11.z releases and therefore upgrading from these versions would cause fixed bugs to reappear. Red Hat does not recommend upgrading clusters to 4.11.36 version for this reason. https://access.redhat.com/solutions/7007136",
        "reason": "PatchesOlderRelease",
        "status": "False",
        "type": "Recommended"
      }
    ],
    "release": {
      "channels": [...],
      "image": "quay.io/openshift-release-dev/ocp-release@sha256:8c04176b771a62abd801fcda3e952633566c8b5ff177b93592e8e8d2d1f8471d",
      "url": "https://access.redhat.com/errata/RHBA-2023:1733",
      "version": "4.11.36"
    },
    "risks": [...]
  },
  ...
]
Copy to Clipboard Toggle word wrap

3.2.2. リリースイメージ
リンクのコピー

リリースイメージは、特定の OpenShift Container Platform (OCP)バージョンのディストリビューションメカニズムです。これには、リリースメタデータ、リリースバージョンに一致する Cluster Version Operator (CVO) バイナリー、個々の OpenShift Cluster Operator のデプロイに必要なすべてのマニフェスト、この OpenShift バージョンを構成するすべてのコンテナーイメージへの SHA ダイジェストバージョン参照リストが含まれています。

次のコマンドを実行して、特定のリリースイメージの内容を検査できます。 

$ oc adm release extract <release image>
Copy to Clipboard Toggle word wrap

出力例

$ oc adm release extract quay.io/openshift-release-dev/ocp-release:4.12.6-x86_64
Extracted release payload from digest sha256:800d1e39d145664975a3bb7cbc6e674fbf78e3c45b5dde9ff2c5a11a8690c87b created at 2023-03-01T12:46:29Z

$ ls
0000_03_authorization-openshift_01_rolebindingrestriction.crd.yaml
0000_03_config-operator_01_proxy.crd.yaml
0000_03_marketplace-operator_01_operatorhub.crd.yaml
0000_03_marketplace-operator_02_operatorhub.cr.yaml
0000_03_quota-openshift_01_clusterresourcequota.crd.yaml
1 

...
0000_90_service-ca-operator_02_prometheusrolebinding.yaml
2 

0000_90_service-ca-operator_03_servicemonitor.yaml
0000_99_machine-api-operator_00_tombstones.yaml
image-references
3 

release-metadata
Copy to Clipboard Toggle word wrap

1
Runlevel 03 に適用される ClusterResourceQuota CRD のマニフェスト
2
ランレベル 90 に適用される、service-ca-operator の PrometheusRoleBinding リソースのマニフェスト
3
必要なすべてのイメージへの SHA ダイジェストバージョン参照リスト

3.2.3. プロセスワークフローの更新
リンクのコピー

以下の手順は、OpenShift Container Platform (OCP) 更新プロセスの詳細なワークフローを示しています。

  1. ターゲットバージョンは、ClusterVersion リソースの spec.desiredUpdate.version フィールドに保存され、Web コンソールまたは CLI から管理されます。
  2. Cluster Version Operator (CVO) は、ClusterVersion リソースの desiredUpdate が現在のクラスターのバージョンとは異なることを検出します。OpenShift Update Service からのグラフデータを使用して、CVO は必要なクラスターバージョンをリリースイメージのプル仕様に解決します。
  3. CVO は、リリースイメージの整合性と信頼性を検証します。Red Hat は、イメージ SHA ダイジェストを一意で不変のリリースイメージ識別子として使用し、公開されたリリースイメージに関する暗号署名されたステートメントを事前定義された場所に公開します。CVO はビルトイン公開鍵のリストを使用して、チェックされたリリースイメージに一致するステートメントの存在と署名を検証します。
  4. CVO は、openshift-cluster-version namespace に version-$version-$hash という名前のジョブを作成します。このジョブはリリースイメージを実行しているコンテナーを使用するため、クラスターはコンテナーランタイムを通じてイメージをダウンロードします。次に、ジョブはマニフェストとメタデータをリリースイメージから CVO がアクセス可能な共有ボリュームに展開します。
  5. CVO は、展開されたマニフェストとメタデータを検証します。
  6. CVO はいくつかの前提条件をチェックして、クラスター内で問題のある状態が検出されないことを確認します。特定の状態により、更新が続行できない場合があります。これらの状態は、CVO 自体によって決定されるか、Operator が更新に問題ありと判断するクラスターの詳細を検出する個々のクラスター Operator によって報告されます。
  7. CVO は、承認されたリリースを status.desired に記録し、新しい更新に関する status.history エントリーを作成します。
  8. CVO は、リリースイメージからマニフェストの適用を開始します。クラスター Operator は Runlevels と呼ばれる別のステージで更新され、CVO は次のレベルに進む前に Runlevel 内のすべての Operator が更新を完了するようにします。
  9. CVO 自体のマニフェストはプロセスの早い段階で適用されます。CVO デプロイメントが適用されると、現在の CVO Pod が終了し、新しいバージョンを使用する CVO Pod が開始されます。新しい CVO は残りのマニフェストの適用を続行します。
  10. 更新は、コントロールプレーン全体が新しいバージョンに更新されるまで続行されます。個々のクラスター Operator は、クラスターのドメインで更新タスクを実行することがあり、その場合は実行中に、Progressing=True 状態を通して状態を報告します。
  11. Machine Config Operator (MCO) マニフェストはプロセスの最後に適用されます。その後、更新された MCO は、すべてのノードのシステム設定とオペレーティングシステムの更新を開始します。各ノードは、再びワークロードの受け入れを開始する前に、ドレイン、更新、および再起動される可能性があります。

クラスターは、コントロールプレーンの更新が完了した後、通常はすべてのノードが更新される前に更新済みであることを報告します。更新後、CVO はすべてのクラスターリソースを、リリースイメージで提供される状態と一致するように維持します。

3.2.4. 更新時のマニフェストの適用方法について
リンクのコピー

リリースイメージで提供される一部のマニフェストは、依存関係があるため、特定の順序で適用する必要があります。たとえば、CustomResourceDefinition リソースは、一致するカスタムリソースの前に作成する必要があります。さらに、クラスター内の断絶を最小限に抑えるために、個々のクラスター Operator は論理的な順序に従い更新される必要があります。Cluster Version Operator (CVO) は、Runlevels の概念を通じてこの論理的な順序を実装します。

これらの依存関係は、リリースイメージのマニフェストのファイル名でエンコードされます。 

0000_<runlevel>_<component>_<manifest-name>.yaml
Copy to Clipboard Toggle word wrap

以下に例を示します。 

0000_03_config-operator_01_proxy.crd.yaml
Copy to Clipboard Toggle word wrap

CVO は内部でマニフェストの依存関係グラフをビルドします。ここで CVO は次のルールに従います。

  • 更新中、より低位の Runlevel のマニフェストは、高位の Runlevel のマニフェストよりも先に適用されます。
  • 1 つの Runlevel 内で、異なるコンポーネントのマニフェストを並行して適用できます。
  • 1 つの Runlevel 内で、単一のコンポーネントのマニフェストは辞書式の順序で適用されます。

次に、CVO は生成された依存関係グラフの順にマニフェストを適用します。

注記

一部のリソースタイプでは、CVO はマニフェストの適用後にリソースを監視し、リソースが安定した状態に達して場合に限り正常に更新されたと見なします。この安定した状態を実現するには時間がかかる場合があります。これは、CVO が新しいバージョンをデプロイした後、クラスター内で独自の更新アクションを実行する可能性があるクラスター Operator に特に当てはまります。追加の更新アクションが実行される間、これらのクラスター Operator では一時的に Progressing の状態が True に設定されます。

CVO は、Runlevel のすべてのクラスター Operator が以下の状態になるまで待機してから、次の Runlevel に進みます。

  • クラスター Operator は Available=True の状態です。
  • クラスター Operator は Degraded=False の状態です。
  • クラスター Operator は、ClusterOperator リソースで必要なバージョンになったことを宣言します。

一部のアクションは、完了するまでにかなりの時間がかかる場合があります。CVO は、後続の Runlevel で安全に続行できるように、アクションが完了するのを待ちます。すべてのマニフェストを適用するプロセスには、合計で 60 ~ 120 分かかることが予想されます。更新期間に影響を与える要因の詳細は、OpenShift Container Platform の更新期間について を参照してください。

一連の Runlevel と各レベル内のコンポーネントのマニフェストを示す図
View larger image
一連の Runlevel と各レベル内のコンポーネントのマニフェストを示す図

前のサンプル図では、CVO は Runlevel 20 ですべての作業が完了するまで待機しています。CVO はすべてのマニフェストを Runlevel の Operator に適用しましたが、kube-apiserver-operator ClusterOperator は一部のアクションを新しいバージョンがデプロイされた後に実行します。kube-apiserver-operator ClusterOperator は、 Progressing=True の状態であることと、新しいバージョンを status.versions で調整済みとして宣言しないことによって、進捗を宣言します。CVO は、ClusterOperator が許容可能なステータスを報告するまで待機し、その後、Runlevel 25 でマニフェストの適用を開始します。

3.2.5. Machine Config Operator によるノードの更新方法
リンクのコピー

Machine Config Operator (MCO) は、新しいマシン設定を各コントロールプレーンノードとコンピュートノードに適用します。マシン設定の更新時に、コントロールプレーンノードとコンピュートノードは、マシンプールが並行して更新される独自のマシン設定プールに編成されます。.spec.maxUnavailable パラメーター (デフォルト値は 1) は、マシン設定プール内の更新プロセスを同時に実行できるノードの数を決定します。

マシン設定の更新プロセスが開始されると、MCO はプール内の現在利用できないノードの数を確認します。使用できないノードの数が .spec.maxUnavailable の値よりも少ない場合、MCO はプール内の使用可能なノードに対して次の一連のアクションを開始します。

  1. ノードを遮断してドレインします。

    注記

    ノードが遮断されている場合、ワークロードをそのノードにスケジュールすることはできません。

  2. ノードのシステム設定およびオペレーティングシステム (OS) を更新します。
  3. ノードを再起動します。
  4. ノードの遮断を解除します。

このプロセスが実行されているノードは、社団が解除されてワークロードが再度スケジュールされるまで使用できません。MCO は、使用できないノードの数が .spec.maxUnavailable の値と等しくなるまでノードの更新を開始します。

ノードが更新を完了して使用可能になると、マシン設定プール内の使用不可ノードの数は再び .spec.maxUnavailable より少なくなります。更新する必要があるノードが残っている場合、MCO は .spec.maxUnavailable 制限に再度達するまで、ノード上で更新プロセスを開始します。このプロセスは、各コントロールプレーンノードとコンピュートノードが更新されるまで繰り返されます。

次のワークフロー例は、5 つのノードを持つマシン設定プールでこのプロセスがどのように発生するかを示しています。ここでの .spec.maxUnavailable は 3 で、最初はすべてのノードが使用可能です。

  1. MCO はノード 1、2、3 を遮断し、それらのドレインを開始します。
  2. ノード 2 は、ドレインを完了して再起動すると再び使用可能になります。MCO はノード 4 を遮断し、そのドレインを開始します。
  3. ノード 1 は、ドレインを完了して再起動すると再び使用可能になります。MCO はノード 5 を遮断し、そのドレインを開始します。
  4. ノード 3 は、ドレインを完了して再起動すると再び使用可能になります。
  5. ノード 5 は、ドレインを完了して再起動すると再び使用可能になります。
  6. ノード 4 は、ドレインを完了して再起動すると再び使用可能になります。

各ノードの更新プロセスは他のノードから独立しているため、上記の例におけるノードの一部は、MCO によって遮断された順序とは異なる順序で更新を終了します。

次のコマンドを実行して、マシン設定の更新ステータスを確認できます。 

$ oc get mcp
Copy to Clipboard Toggle word wrap

出力例

NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master       rendered-master-acd1358917e9f98cbdb599aea622d78b       True      False      False      3              3                   3                     0                      22h
worker       rendered-worker-1d871ac76e1951d32b2fe92369879826       False     True       False      2              1                   1                     0                      22h
Copy to Clipboard Toggle word wrap

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat