9.2. カナリアロールアウト更新の実行について
このトピックでは、このカナリアロールアウト更新プロセスの一般的なワークフローについて説明します。ワークフローで各タスクを実行する手順は、以下のセクションで説明します。
ワーカープールに基づいて MCP を作成します。各 MCP のノード数は、各 MCP のメンテナンス期間や予約容量 (つまりクラスターで利用可能な追加のワーカーノード) など、いくつかの要素に依存します。
注記MCP の
maxUnavailable
設定を変更して、任意の時点で更新できるパーセンテージまたはマシン数を指定できます。デフォルトでは 1 回です。ノードセレクターをカスタム MCP に追加します。残りのクラスターと同時に更新しない各ノードに、一致するラベルをノードに追加します。このラベルは、ノードを MCP に関連付けます。
注記ノードからデフォルトのワーカーラベルを削除しないでください。クラスターで適切に機能するには、ノードにロールラベルが 必要 です。
更新プロセスの一部として更新しない MCP を一時停止します。
注記MCP を一時停止すると、
kube-apiserver-to-kubelet-signer
自動 CA 証明書のローテーションも一時停止します。新しい CA 証明書は、インストール日と古い証明書の 292 日で生成され、インストール日から 365 日は削除されます。次の自動 CA 証明書のローテーションまでの所要時間については、Understanding CA cert auto updates in Red Hat OpenShift 4 を参照してください。CA 証明書のローテーションが発生したときに、プールが一時停止されていないことを確認してください。MCP が一時停止されている場合、MCO は新しくローテーションされた証明書をそれらのノードにプッシュできません。これにより、クラスターが劣化し、
oc debug
、oc logs
、oc exec
、oc attach
などの複数のoc
コマンドで障害が発生します。証明書がローテーションされたときに MCP が一時停止された場合、OpenShift Container Platform コンソールのアラート UI でアラートを受け取ります。- クラスターの更新を実行します。更新プロセスでは、コントロールプレーンノードを含む、一時停止されない MCP を更新します。
- 更新されたノードでアプリケーションをテストし、想定通りに機能していることを確認します。
-
残りの MCP を 1 つずつ一時停止解除し、すべてのワーカーノードが更新されるまでそれらのノードでアプリケーションをテストします。MCP の一時停止を解除すると、その MCP に関連付けられたノードの更新プロセスが開始されます。Administration
Cluster settings をクリックして、Web コンソールから更新の進捗を確認できます。または、 oc get machineconfigpools
CLI コマンドを使用します。 - 必要に応じて、更新されたノードからカスタムラベルを削除し、カスタム MCP を削除します。