第1章 Red Hat OpenShift Service on AWS クラスターを更新する
Red Hat OpenShift Service on AWS では、アップデートによって更新されたソフトウェアを含む新しいコンポーネントがプロビジョニングされ、古いソフトウェアを使用している既存のコンポーネントと置き換えられます。
1.1. Red Hat ビルドの Karpenter で設定された Red Hat OpenShift Service on AWS クラスターの更新オプション リンクのコピーリンクがクリップボードにコピーされました!
クラスターのどの部分を更新するかを制御することで、ワークロードへの更新の影響を制御できます。
- Hosted Control Plane のみを更新する
-
これにより、Hosted Control Plane の更新が開始されます。クラスターが Red Hat 版の Karpenter で設定されていない場合、ワーカーノードには影響しません。クラスターが Red Hat ビルドの Karpenter で設定されている場合、Karpenter によって管理されるデフォルトの
EC2NodeClassリソースの一部であるワーカーノードは、Hosted Control Plane とともに更新されます。 - マシンプール内のノードを更新する
- Red Hat OpenShift Service on AWS マシンプールアップデートは、アップデート処理中にマシンプール内の各ノードを完全に置き換えるように設計されています。これは、インプレースアップデートを実行する場合と比較して、セキュリティーと安定性においてさらなる利点をもたらします。マシンプール内のノードを更新すると、指定されたマシンプール内のノードのローリング置換が開始され、そのマシンプール上のワーカーノードに一時的に影響が出ます。複数のマシンプールを同時に更新することも可能です。
- Karpenter が管理する
EC2NodeClass内のノードを更新する -
Red Hat 版 Karpenter が有効になっている場合、クラスター内に作成された
OpenshiftEC2NodeClassリソースをアップグレードできます。
Hosted Control Plane の更新は、マシンプールの更新と同時に行うことはできません。まず Hosted Control Plane を更新し、次にマシンプールを更新する必要があります。
クラスター内のノード間の互換性を維持するために、マシンプール内のノードは Hosted Control Plane よりも新しいバージョンを使用できません。これは、マシンプールを同じバージョンに更新する前に、必ず Hosted Control Plane を特定のバージョンに更新する必要があることを意味します。
各マシンプールの --max-surge および --max-unavailable の 値を編集することで、マシンプールの更新に必要な時間や、更新がワークロードに与える影響をさらに制御できます。これらのオプションは、マシンプール上で同時に更新できるノードの数、および更新によって余剰ノードがプロビジョニングされるか、既存のノードの一部が使用不能になるか、あるいはその両方が行われるかを制御します。例:
-
高いワークロードの可用性を優先するには、
--max-surgeに高い値を設定し、--max-unavailableを0に設定することで、既存のノードを使用不可にする代わりに余分なノードをプロビジョニングできます。 -
インフラストラクチャーコストの削減を優先するには、
--max-unavailableに高い値を設定し、--max-surgeを0に設定することで、既存のノードの一部を利用不可にし、余分なノードのプロビジョニングを回避することができます。 -
複数のノードを同時に更新して更新速度を優先するには、余剰のノードをプロビジョニングし、
--max-surgeと--max-unavailableの両方に中程度の値を設定することで、既存のノードの一部を使用不可にすることができます。
これらのパラメーターとその使用方法の詳細は、ROSA CLI リファレンス の rosa edit machinepool を参照してください。