4.6. ノードの再起動について
プラットフォームで実行されているアプリケーションを停止せずにノードを再起動するには、まず Pod の退避を実行することが重要です。ルーティング階層によって可用性が高くなっている Pod については、何も実行する必要はありません。ストレージ (通常はデータベース) を必要とするその他の Pod については、1 つの Pod が一時的にオフラインになってもそれらの Pod が作動状態を維持できることを確認する必要があります。ステートフルな Pod の回復性はアプリケーションごとに異なりますが、いずれの場合でも、ノードの非アフィニティー (node anti-affinity) を使用して Pod が使用可能なノードにわたって適切に分散するようにスケジューラーを設定することが重要になります。
別の課題として、ルーターやレジストリーのような重要なインフラストラクチャーを実行しているノードを処理する方法を検討する必要があります。同じノードの退避プロセスが適用されますが、一部のエッジケースについて理解しておくことが重要です。
4.6.1. インフラストラクチャーノードの再起動について
インフラストラクチャーノードは、OpenShift Container Platform 環境の各部分を実行するようにラベル付けされたノードです。現在、ノードの再起動を管理する最も簡単な方法は、インフラストラクチャーを実行するための少なくとも 3 つのノードを利用可能な状態にすることです。インフラストラクチャーを実行するノードは、マスター ノードと呼ばれます。
以下のシナリオは、2 つのノードのみが利用可能な場合に OpenShift Container Platform で実行されているアプリケーションのサービス中断を引き起こす可能性がある一般的なエラーを示しています。
- ノード A がスケジュール対象外としてマークされており、すべての Pod の退避が行われている。
- このノードで実行されているレジストリー Pod がノード B に再デプロイされる。 これは、ノード B が両方のレジストリー Pod を実行していることを意味します。
- ノード B はスケジュール対象外としてマークされ、退避が行われる。
- ノード B の 2 つの Pod エンドポイントを公開するサービスは、それらがノード A に再デプロイされるまでの短い期間すべてのエンドポイントを失う。
インフラストラクチャーの 3 つのマスターノードを使用する同じプロセスではサービスの中断が生じません。しかし、Pod のスケジューリングにより、退避してローテーションに戻された最後のノードはゼロ (0) レジストリーを実行したままになります。他の 2 つのノードは 2 つのレジストリーと 1 つのレジストリーをそれぞれ実行します。最適なソリューションとして、Pod の非アフィニティーを使用します。
