7.2. カナリアロールアウト更新の実行
特定のユースケースでは、特定ノードを残りのクラスターと同時に更新しない、制御された更新プロセスが必要になる場合があります。これらのユースケースには、以下のようなものがありますが、これに限定されません。
- 更新時に利用できないミッションクリティカルなアプリケーションがあります。更新後の小規模なバッチで、ノードのアプリケーションを徐々にテストすることができます。
- すべてのノードを更新することができない小規模なメンテナンス期間がある場合や、複数のメンテナンスウィンドウがあります。
ローリング更新のプロセスは、通常の更新ワークフロー ではありません。大規模なクラスターの場合は、複数のコマンドを実行する必要がある時間のかかるプロセスになります。この複雑さにより、クラスター全体に影響を与える可能性のあるエラーが発生する場合があります。組織がローリング更新を使用し、開始前にプロセスの実装を慎重に計画するかどうかを慎重に検討することが推奨されます。
本トピックで説明されているローリング更新プロセスでは、以下が関係します。
- 1 つ以上のカスタムマシン設定プール (MCP) の作成。
- これらのノードをカスタム MCP に移動するためにすぐに更新しない各ノードのラベル付け。
- カスタム MCP の一時停止。これにより、それらのノードへの更新が回避されます。
- クラスターの更新の実行。
- それらのノードで更新をトリガーする 1 つのカスタム MCP の一時停止解除。
- これらのノードでアプリケーションをテストし、新たに更新されたノードでアプリケーションが想定どおりに機能していることを確認。
- 必要に応じて、小規模なバッチの残りのノードからカスタムラベルを削除し、それらのノードでアプリケーションのテスト。
MCP を一時停止にすると、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 が一時停止された場合、OpenShift Container Platform コンソールのアラート UI でアラートを受け取ります。
MCP の一時停止は、kube-apiserver-to-kubelet-signer CA 証明書の有効期限を慎重に考慮して、短期間のみ行う必要があります。
カナリアロールアウト更新プロセスを使用する場合は、カナリアロールアウト更新の実行 を参照してください。
