Red Hat Summit1.4. OpenShift Container Platform の更新期間について
OpenShift Container Platform の更新期間は、デプロイメントのトポロジーによって異なります。このページは、更新期間に影響を与える要因を理解し、ご使用の環境でクラスターの更新にかかる時間を見積もるのに役立ちます。
1.4.1. 更新期間に影響する要因
次の要因は、クラスターの更新期間に影響を与える可能性があります。
Machine Config Operator (MCO) による新しいマシン設定へのコンピュートノードの再起動
マシン設定プールの
MaxUnavailableの値警告OpenShift Container Platform のすべてのマシン設定プールにおける
maxUnavailableのデフォルト設定は1です。この値を変更せず、一度に 1 つのコントロールプレーンノードを更新することを推奨します。コントロールプレーンプールのこの値を3に変更しないでください。- Pod 中断バジェット (PDB) に設定されたレプリカの最小数またはパーセンテージ
- クラスター内のノード数
- クラスターノードの健全性
1.4.2. クラスターの更新フェーズ
OpenShift Container Platform では、クラスターの更新は 2 つのフェーズで行われます。
- Cluster Version Operator (CVO) ターゲット更新ペイロードのデプロイメント
- Machine Config Operator (MCO) ノードの更新
1.4.2.1. Cluster Version Operator ターゲット更新ペイロードのデプロイメント
Cluster Version Operator (CVO) は、ターゲットの更新リリースイメージを取得し、クラスターに適用します。Pod として実行されるすべてのコンポーネントはこのフェーズ中に更新されますが、ホストコンポーネントは Machine Config Operator (MCO) によって更新されます。このプロセスには 60 ~ 120 分かかる場合があります。
更新の CVO フェーズでは、ノードは再起動されません。
1.4.2.2. Machine Config Operator ノードの更新
Machine Config Operator (MCO) は、新しいマシン設定を各コントロールプレーンとコンピュートノードに適用します。このプロセス中に、MCO はクラスターの各ノードで次の一連のアクションを実行します。
- すべてのノードを遮断してドレインします
- オペレーティングシステム (OS) を更新します
- ノードを再起動します
- すべてのノードの遮断を解除し、ノードでワークロードをスケジュールします
ノードが遮断されている場合、ワークロードをそのノードにスケジュールすることはできません。
このプロセスが完了するまでの時間は、ノードやインフラストラクチャーの設定など、いくつかの要因によって異なります。このプロセスは、ノードごとに完了するまでに 5 分以上かかる場合があります。
MCO に加えて、次のパラメーターの影響を考慮する必要があります。
- コントロールプレーンノードの更新期間は予測可能であり、多くの場合、コンピュートノードよりも短くなります。これは、コントロールプレーンのワークロードが適切な更新と迅速なドレインに合わせて調整されているためです。
-
Machine Config Pool (MCP) で
maxUnavailableフィールドを1より大きい値に設定することで、コンピュートノードを並行して更新できます。MCO は、maxUnavailableで指定された数のノードを遮断し、それらを更新不可としてマークします。 -
MCP で
maxUnavailableを増やすと、プールがより迅速に更新されるのに役立ちます。ただし、maxUnavailableの設定が高すぎて、複数のノードが同時に遮断されている場合、レプリカを実行するスケジュール可能なノードが見つからないため、Pod 中断バジェット (PDB) で保護されたワークロードのドレインに失敗する可能性があります。MCP のmaxUnavailableを増やす場合は、PDB で保護されたワークロードを排出できるように、スケジュール可能なノードがまだ十分にあることを確認してください。 更新を開始する前に、すべてのノードが使用可能であることを確認する必要があります。ノードが利用できないと、
maxUnavailableおよび Pod 中断バジェットに影響するため、利用できないノードがあると、更新期間に大きな影響を与える可能性があります。ターミナルからノードのステータスを確認するには、次のコマンドを実行します。
oc get node
$ oc get nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ノードのステータスが
NotReadyまたはSchedulingDisabledの場合、ノードは使用できず、更新期間に影響します。Compute
Node を展開することで、Web コンソールの Administrator パースペクティブからノードのステータスを確認できます。
1.4.2.3. クラスター Operator の更新期間の例
前の図は、クラスター Operator が新しいバージョンに更新するのにかかる時間の例を示しています。この例は、3 ノードの AWS OVN クラスターに基づいています。このクラスターには、正常なコンピュート MachineConfigPool があり、ドレインに時間がかかるワークロードがなく、4.13 から 4.14 に更新されます。
- クラスターとその Operator の具体的な更新期間は、ターゲットバージョン、ノードの量、ノードにスケジュールされたワークロードの種類など、クラスターのいくつかの特性に基づいて変化する可能性があります。
- Cluster Version Operator などの一部のオペレーターは、短時間で自身を更新します。これらの Operator は図から省略されているか、「並列のその他の Operator」というラベルが付いたより広範な Operator のグループに含まれています。
各クラスター 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 の更新にかかる時間が長くなります。
各クラスター Operator には、更新できるステージが割り当てられます。同じステージ内の Operator は同時に更新できますが、特定のステージの Operator は、前のステージがすべて完了するまで更新を開始できません。詳細は、「関連情報」セクションの「更新中にマニフェストが適用される方法について」を参照してください。
1.4.3. クラスター更新時間の概算
同様のクラスターの履歴更新期間は、将来のクラスター更新の最適な概算を提供します。ただし、履歴データが利用できない場合は、次の規則を使用してクラスターの更新時間を概算することができます。
Cluster update time = CVO target update payload deployment time + (# node update iterations x MCO node update time)
Cluster update time = CVO target update payload deployment time + (# node update iterations x MCO node update time)
ノード更新反復は、並行して更新される 1 つ以上のノードで構成されます。コントロールプレーンノードは常に、コンピュートノードと並行して更新されます。さらに、maxUnavailable 値に基づいて、1 つ以上のコンピュートノードを並行して更新できます。
OpenShift Container Platform のすべてのマシン設定プールにおける maxUnavailable のデフォルト設定は 1 です。この値を変更せず、一度に 1 つのコントロールプレーンノードを更新することを推奨します。コントロールプレーンプールのこの値を 3 に変更しないでください。
例えば、更新時間を概算するには、3 つのコントロールプレーンノードと 6 つのコンピュートノードを持つ OpenShift Container Platform クラスターがあり、各ホストの再起動に約 5 分かかるとします。
特定のノードの再起動にかかる時間は、大幅に異なります。クラウドインスタンスでは、再起動に約 1 ~ 2 分かかる場合がありますが、物理的なベアメタルホストでは、再起動に 15 分以上かかる場合があります。
シナリオ 1:
コントロールプレーンとコンピュートノードの Machine Config Pool (MCP) の両方で maxUnavailable を 1 に設定すると、6 つのコンピュートノードすべてが反復ごとに次々と更新されます。
Cluster update time = 60 + (6 x 5) = 90 minutes
Cluster update time = 60 + (6 x 5) = 90 minutesシナリオ 2
コンピュートノード MCP の maxUnavailable を 2 に設定すると、2 つのコンピュートノードが反復ごとに並行して更新されます。したがって、すべてのノードを更新するには合計 3 回の反復が必要です。
Cluster update time = 60 + (3 x 5) = 75 minutes
Cluster update time = 60 + (3 x 5) = 75 minutes
maxUnavailable のデフォルト設定は、OpenShift Container Platform のすべての MCP で 1 です。コントロールプレーン MCP で maxUnavailable を変更しないことを推奨します。
1.4.4. Red Hat Enterprise Linux (RHEL) コンピュートノード
Red Hat Enterprise Linux (RHEL) コンピュートノードでは、ノードのバイナリーコンポーネントを更新するために openshift-ansible を追加で使用する必要があります。RHEL コンピュートノードの更新に費やされる実際の時間は、Red Hat Enterprise Linux CoreOS (RHCOS) コンピュートノードと大きく変わらないはずです。
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}