1.4.2.3. クラスター Operator の更新期間の例

クラスター Operator の更新期間の例を確認することで、更新期間に影響を与える要因をより深く理解できます。

前の図は、クラスター Operator が新しいバージョンに更新するのにかかる時間の例を示しています。この例は、3 ノードの AWS OVN クラスターに基づいています。このクラスターには、正常なコンピュート MachineConfigPool があり、ドレインに時間がかかるワークロードがなく、4.13 から 4.14 に更新されます。

各クラスター Operator には、それ自体の更新にかかる時間に影響する特性があります。たとえば、この例の Kube API Server Operator の更新には 11 分以上かかりました。これは、kube-apiserver が正常な終了サポートを提供しているためです。つまり、実行中の既存のリクエストは正常に完了できます。これにより、kube-apiserver のシャットダウンに時間がかかる可能性があります。この Operator の場合は、更新中のクラスター機能の中断を防止および制限するために、更新速度が犠牲になります。

Operator の更新期間に影響を与えるもう 1 つの特性は、Operator が DaemonSet を利用するかどうかです。Network Operator と DNS Operator はフルクラスター DaemonSet を利用するため、バージョン変更のデプロイメントに時間がかかる場合があります。これが、これらの Operator の更新に時間がかかる理由の 1 つです。

さらに、一部の Operator の更新期間は、クラスター自体の特性に大きく依存します。たとえば、Machine Config Operator の更新では、マシン設定の変更がクラスター内の各ノードに適用されます。多くのノードを含むクラスターは、ノードが少ないクラスターと比較して、Machine Config Operator の更新にかかる時間が長くなります。