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