第10章 カナリアロールアウト更新の実行
更新プロセスによってアプリケーションが失敗した場合でも、更新全体を通じてミッションクリティカルなアプリケーションを利用できるようにするために、ワーカーノードへの更新のより制御されたロールアウトが必要なシナリオがいくつかある場合があります。組織のニーズによっては、ワーカーノードの小規模なサブセットを更新し、一定期間でクラスターおよびワークロードの正常性を評価し、残りのノードを更新する必要が生じる場合があります。通常、これは カナリア 更新と呼ばれます。または、クラスター全体を一度に更新するために大きなメンテナンスウィンドウを使用できない場合は、ホストの再起動が必要になることが多いワーカーノードの更新を、定義済みの小さなメンテナンスウィンドウに収めることもできます。
これらのシナリオでは、複数のカスタムマシン設定プール (MCP) を作成して、クラスターを更新するときに特定のワーカーノードが更新されないようにすることができます。残りのクラスターが更新されたら、それらのワーカーノードをバッチで随時更新できます。
たとえば、クラスターに 10% 超過する容量が 100 個あるクラスターがあり、4 時間を超えないようにメンテナンスウィンドウがあり、ワーカーノードをドレイン (解放) および再起動するのに 8 分未満になったことが分かっている場合は、MCP を使用して目標を達成できます。たとえば、workerpool-canary、workerpool-A、workerpool-B、および workerpool-C という名前の 4 つの MCP を、それぞれ 10、30、30、30 ノードで定義できます。
最初のメンテナンス期間中、workerpool-A、workerpool-B、および workerpool-C の MCP を一時停止してから、クラスターの更新を開始します。これにより、プールが一時停止されていないため、OpenShift Container Platform の上部で実行されるコンポーネントと workerpool-canary MCP のメンバーである 10 ノードが更新されます。他の 3 つの MCP は一時停止されているため、更新されません。何らかの理由で、クラスターまたはワークロードの正常性が workerpool-canary 更新によって悪影響を受けると判断すると、問題を診断するまで十分な容量を維持しながら、そのプールのすべてのノードを遮断およびドレイン (解放) します。すべてが期待どおりに機能している場合は、一時停止を解除することを決定する前にクラスターおよびワークロードの状態を評価し、追加のメンテナンスウィンドウごとに workerpool-A、workerpool-B、および workerpool-C を連続して更新します。
カスタム MCP を使用してワーカーノードの更新を管理する一方で、複数のコマンドを実行する必要がある時間のかかるプロセスがある場合があります。この複雑さにより、クラスター全体に影響を与える可能性のあるエラーが発生する場合があります。組織のニーズを考慮し、開始する前にプロセスの実装を慎重に検討することが推奨されます。
MCP を異なる OpenShift Container Platform バージョンに更新することは推奨されません。たとえば、ある MCP を 4.y.10 から 4.y.11 に更新せず、もう 1 つの MCP を 4.y.12 に更新しないでください。このシナリオはテストされておらず、未定義のクラスターの状態になる可能性があります。
マシン設定プールを一時停止にすると、Machine Config Operator が関連付けられたノードに設定変更を適用できなくなります。MCP を一時停止することにより、kube-apiserver-to-kubelet-signer CA 証明書の自動 CA ローテーションを含め、自動的にローテーションされる証明書が関連付けられたノードにプッシュされないようにします。MCP が kube-apiserver-to-kubelet-signer CA 証明書の期限が切れ、MCO が証明書を自動的に更新しようとすると、新規証明書が作成されますが、適切なマシン設定プールのノード全体では適用されません。これにより、oc debug、oc logs、oc exec、oc attach など、複数の oc コマンドで問題が発生します。MCP の一時停止は、kube-apiserver-to-kubelet-signer CA 証明書の有効期限を慎重に考慮して、短期間のみ行う必要があります。
10.1. カナリアロールアウト更新プロセスおよび MCP について
OpenShift Container Platform では、ノードを個別に考慮しません。ノードはマシン設定プール (MCP) にグループ化されます。デフォルトの OpenShift Container Platform クラスターには 2 つの MCP があります。1 つはコントロールプレーンノード用であり、もう 1 つはワーカーノードになります。OpenShift Container Platform の更新は、すべての MCP を同時に影響します。
更新中、Machine Config Operator (MCO) は、MCP 内のすべてのノードを、指定された maxUnavailable ノード数 (指定されている場合) (デフォルトでは 1) までドレイン (解放) および遮断します。ノードがドレイン (解放) および遮断し、ノード上のすべての Pod のスケジュールを解除し、ノードをスケジュール対象外としてマークします。ノードがドレイン (解放) されると、Machine Config Daemon は新規マシン設定を適用します。これには、オペレーティングシステム (OS) の更新を含めることができます。OS を更新するには、ホストを再起動する必要があります。
特定のノードが更新されないようにするために、つまり、ドレイン (解放)、遮断、および更新されないようにするために、カスタム MCP を作成できます。次に、これらの MCP を一時停止して、それらの MCP に関連付けられたノードが更新されないようにします。MCO は一時停止された MCP を更新しません。1 つ以上のカスタム MCP を作成して、それらのノードを更新するシーケンスをより詳細に制御できます。最初の MCP でノードを更新した後に、アプリケーションの互換性を確認し、残りのノードを新規バージョンに段階的に更新できます。
コントロールプレーンの安定性を確保するには、コントロールプレーンノードからカスタム MCP の作成はサポートされません。Machine Config Operator (MCO) は、コントロールプレーンノード用に作成されるカスタム MCP を無視します。
ワークロードのデプロイメントトポロジーに基づいて、作成する MCP の数および各 MCP のノード数について慎重に考慮する必要があります。たとえば、更新を特定のメンテナンスウィンドウに合わせる必要がある場合は、OpenShift Container Platform がウィンドウ内で更新できるノードの数を把握しておく必要があります。この数は、一意のクラスターおよびワークロードの特性によって異なります。
また、クラスターで利用可能な容量の数を考慮する必要があります。たとえば、アプリケーションが更新されたノードで予想通りに機能しない場合は、プール内のそれらのノードを遮断およびドレイン (解放) できます。これにより、アプリケーション Pod を他のノードに移動します。必要なカスタム MCP の数および各 MCP のノード数を判別するために、利用可能な追加容量を考慮する必要があります。たとえば、ノードが各プールにある 2 つのカスタム MCP と 50% を使用する場合は、ノードの 50% が実行されているかどうかを判断する必要があります。この場合は、アプリケーション用に十分な QoS (quality-of-service) が提供されます。
この更新プロセスは、文書化されたすべての OpenShift Container Platform 更新プロセスで使用できます。ただし、このプロセスは、Ansible Playbook を使用して更新される Red Hat Enterprise Linux (RHEL) マシンでは機能しません。
