11.2. カナリアロールアウト更新プロセスおよび MCP について

OpenShift Container Platform では、ノードは個別に考慮されません。代わりに、ノードはマシン設定プール (MCP) にグループ化されます。デフォルトでは、OpenShift Container Platform クラスター内のノードは 2 つの MCP にグループ化されます。1 つはコントロールプレーンノード用、もう 1 つはワーカーノード用です。OpenShift Container Platform の更新は、すべての MCP に同時に影響します。

更新中、Machine Config Operator (MCO) は、最大数が指定されている場合、指定された maxUnavailable ノード数まで MCP 内のすべてのノードをドレインし、遮断します。デフォルトでは、maxUnavailable は 1 に設定されます。ノードがドレイン (解放) および遮断し、ノード上のすべての Pod のスケジュールを解除し、ノードをスケジュール対象外としてマークします。

ノードがドレイン (解放) されると、Machine Config Daemon は新規マシン設定を適用します。これには、オペレーティングシステム (OS) の更新を含めることができます。OS を更新するには、ホストを再起動する必要があります。

カスタムマシン設定プールの使用

特定のノードが更新されないようにするには、カスタム MCP を作成します。一時停止された MCP 内のノードは、MCO によって更新されません。そのため、クラスターの更新を開始する前に、更新する必要がないノードを含む MCP を一時停止できます。

1 つ以上のカスタム MCP を使用すると、ワーカーノードを更新する順序をより詳細に制御できます。たとえば、最初の MCP のノードを更新した後、アプリケーションの互換性を確認してから、残りのノードを新しいバージョンに段階的に更新できます。

カスタムマシン設定プールを使用する場合の考慮事項

ワークロードのデプロイメントトポロジーに基づいて、作成する MCP の数と各 MCP 内のノードの数を慎重に検討してください。たとえば、更新を特定のメンテナンス期間に合わせる必要がある場合は、OpenShift Container Platform が一定期間内に更新できるノードの数を把握しておく必要があります。この数は、それぞれのクラスターとワークロードの特性によって異なります。

カスタム MCP の数と各 MCP 内のノードの数を決定するには、クラスター内で利用可能な余剰容量についても考慮する必要があります。新しく更新されたノードでアプリケーションが期待どおりに動作しない場合は、プール内のそのノードを遮断してドレインし、アプリケーション Pod を他のノードに移動できます。ただし、他の MCP 内の使用可能なノードがアプリケーションに十分なサービス品質 (QoS) を提供できるかどうかを確認する必要があります。