7.2. カナリアロールアウト更新の実行について

このトピックでは、このカナリアロールアウト更新プロセスの一般的なワークフローについて説明します。ワークフローで各タスクを実行する手順は、以下のセクションで説明します。

  1. ワーカープールに基づいて MCP を作成します。各 MCP のノード数は、各 MCP のメンテナンス期間や予約容量 (つまりクラスターで利用可能な追加のワーカーノード) など、いくつかの要素に依存します。

    注記

    MCP の maxUnavailable 設定を変更して、任意の時点で更新できるパーセンテージまたはマシン数を指定できます。デフォルトでは 1 回です。

  2. ノードセレクターをカスタム MCP に追加します。残りのクラスターと同時に更新しない各ノードに、一致するラベルをノードに追加します。このラベルは、ノードを MCP に関連付けます。

    注記

    ノードからデフォルトのワーカーラベルを削除しないでください。クラスターで適切に機能するには、ノードにロールラベルが 必要 です。

  3. 更新プロセスの一部として更新しない MCP を一時停止します。

    注記

    MCP を一時停止すると、kube-apiserver-to-kubelet-signer 自動 CA 証明書のローテーションも一時停止します。新しい CA 証明書は、インストール日と古い証明書の 292 日で生成され、インストール日から 365 日は削除されます。次の自動 CA 証明書のローテーションまでの所要時間については、Understanding CA cert auto updates in Red Hat OpenShift 4 を参照してください。CA 証明書のローテーションが行われると、プールが一時停止されていないことを確認します。MCP が一時停止すると、証明書のローテーションが発生しません。これにより、クラスターは劣化し、複数の oc コマンドで失敗の原因となります。これには、oc debug、oc logs、oc exec、および oc attach が含まれますが、これに限定されません。

  4. クラスターの更新を実行します。更新プロセスでは、コントロールプレーンノード (別名マスターノード) を含む、一時停止されない MCP を更新します。
  5. 更新されたノードでアプリケーションをテストし、想定通りに機能していることを確認します。
  6. 残りの MCP を 1 つずつ一時停止解除し、すべてのワーカーノードが更新されるまでそれらのノードでアプリケーションをテストします。MCP の一時停止を解除すると、その MCP に関連付けられたノードの更新プロセスが開始されます。Administration → Cluster settings をクリックして、Web コンソールから更新の進捗を確認できます。または、oc get machineconfigpools CLI コマンドを使用します。
  7. 必要に応じて、更新されたノードからカスタムラベルを削除し、カスタム MCP を削除します。