1.4.2.2. Machine Config Operator ノードの更新
アップデートの第 2 段階では、Machine Config Operator (MCO) が各制御プレーンおよびコンピュートノードに新しいマシン設定を適用します。
このプロセス中に、MCO はクラスターの各ノードで次の一連のアクションを実行します。
- すべてのノードを遮断してドレインします
- オペレーティングシステム (OS) を更新します
- ノードを再起動します
- すべてのノードの遮断を解除し、ノードでワークロードをスケジュールします
ノードが遮断されている場合、ワークロードをそのノードにスケジュールすることはできません。
このプロセスが完了するまでの時間は、ノードやインフラストラクチャーの設定など、いくつかの要因によって異なります。このプロセスは、ノードごとに完了するまでに 5 分以上かかる場合があります。
MCO に加えて、次のパラメーターの影響を考慮する必要があります。
- コントロールプレーンノードの更新期間は予測可能であり、多くの場合、コンピュートノードよりも短くなります。これは、コントロールプレーンのワークロードが適切な更新と迅速なドレインに合わせて調整されているためです。
-
Machine Config Pool (MCP) で
maxUnavailableフィールドを1より大きい値に設定することで、コンピュートノードを並行して更新できます。MCO は、maxUnavailableで指定された数のノードを遮断し、それらを更新不可としてマークします。 -
MCP で
maxUnavailableを増やすと、プールがより迅速に更新されるのに役立ちます。ただし、maxUnavailableの設定が高すぎる場合、複数のノードが同時に cordon されると、レプリカを実行するためのスケジュール可能なノードが見つからないため、Pod Disruption Budget (PDB) で保護されたワークロードの drain が失敗する可能性があります。MCP のmaxUnavailableを引き上げる場合は、PDB で保護されたワークロードを drain できるように、スケジュール可能なノードが十分に残ることを確認してください。 更新を開始する前に、すべてのノードが利用可能であることを確認する必要があります。利用不可のノードは、
maxUnavailableと Pod Disruption Budget に影響するため、更新期間に大きな影響を与える可能性があります。ターミナルからノードのステータスを確認するには、次のコマンドを実行します。
$ oc get node出力例
NAME STATUS ROLES AGE VERSION ip-10-0-137-31.us-east-2.compute.internal Ready,SchedulingDisabled worker 12d v1.23.5+3afdacb ip-10-0-151-208.us-east-2.compute.internal Ready master 12d v1.23.5+3afdacb ip-10-0-176-138.us-east-2.compute.internal Ready master 12d v1.23.5+3afdacb ip-10-0-183-194.us-east-2.compute.internal Ready worker 12d v1.23.5+3afdacb ip-10-0-204-102.us-east-2.compute.internal Ready master 12d v1.23.5+3afdacb ip-10-0-207-224.us-east-2.compute.internal Ready worker 12d v1.23.5+3afdacbノードのステータスが
NotReadyまたはSchedulingDisabledの場合、ノードは使用できず、更新期間に影響します。管理者 視点から Web コンソールで コンピュート
ノード を展開すると、ノードの状態を確認することもできます。