1.2.5. 更新時のマニフェストの適用方法について

リリースイメージで提供される一部のマニフェストは、依存関係があるため、特定の順序で適用する必要があります。

たとえば、CustomResourceDefinition リソースは、一致するカスタムリソースの前に作成する必要があります。さらに、クラスター内の断絶を最小限に抑えるために、個々のクラスター Operator は論理的な順序に従い更新される必要があります。Cluster Version Operator (CVO) は、Runlevels の概念を通じてこの論理的な順序を実装します。

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

0000_<runlevel>_<component>_<manifest-name>.yaml

以下に例を示します。

0000_03_config-operator_01_proxy.crd.yaml

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

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

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

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

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