3.4. カナリアロールアウト更新の実行
カナリア更新 は、すべてのワーカーノードを同時に更新するのではなく、ワーカーノードの更新を個別の段階に分けて順次実行する更新ストラテジーです。このストラテジーは、次の場合に役立ちます。
- ワーカーノード更新のロールアウトをより細かく制御して、更新プロセスによってアプリケーションが失敗した場合でも、更新全体を通じてミッションクリティカルなアプリケーションが利用可能な状態を維持する必要がある。
- 少数のワーカーノードを更新し、一定期間にわたりクラスターとワークロードの健全性を評価してから、残りのノードを更新する必要がある。
- クラスター全体を一度に更新するために長いメンテナンス期間を取ることができない場合に、通常はホストの再起動が必要となるワーカーノードの更新を、より短い一定のメンテナンス期間内に収める必要がある。
これらのシナリオでは、複数のカスタムマシン設定プール (MCP) を作成して、クラスターを更新するときに特定のワーカーノードが更新されないようにすることができます。残りのクラスターが更新されたら、それらのワーカーノードをバッチで随時更新できます。
3.4.1. カナリア更新ストラテジーの例
次の例では、10% の余剰容量を備えた 100 ノードのクラスターのカナリア更新ストラテジーを説明します。メンテナンス期間は 4 時間未満にする必要があり、ワーカーのドレインと再起動は 8 分未満で完了することがわかっています。
前述の値は単なる例です。ノードのドレインにかかる時間は、ワークロードなどの要因によって異なる場合があります。
カスタムマシン設定プールの定義
ワーカーノードの更新を個別の段階に分けて編成するために、まず次の MCP を定義します。
- 10 個のノードを含む workerpool-canary
- 30 個のノードを含む workerpool-A
- 30 個のノードを含む workerpool-B
- 30 個のノードを含む workerpool-C
カナリアワーカープールの更新
最初のメンテナンス期間中、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 を使用してワーカーノードの更新を管理すると、柔軟性が得られます。一方で、複数のコマンドを実行する必要があるため、時間のかかるプロセスになる可能性があります。この複雑さにより、クラスター全体に影響を及ぼす可能性のあるエラーが発生する可能性があります。開始する前に、組織のニーズを慎重に検討し、プロセスの実装を慎重に計画することを推奨します。
マシン設定プールを一時停止にすると、Machine Config Operator が関連付けられたノードに設定変更を適用できなくなります。MCP を一時停止することにより、kube-apiserver-to-kubelet-signer CA 証明書の自動 CA ローテーションを含め、自動的にローテーションされる証明書が関連付けられたノードにプッシュされないようにします。
kube-apiserver-to-kubelet-signer CA 証明書の有効期限が切れたときに MCP が一時停止され、MCO が証明書を自動的に更新しようとすると、MCO は新しくローテーションされた証明書をそれらのノードにプッシュできません。これにより、oc debug、oc logs、oc exec、oc attach などの複数の oc コマンドでエラーが発生します。証明書がローテーションされたときに MCP が一時停止された場合、OpenShift Container Platform コンソールのアラート UI でアラートを受け取ります。
MCP の一時停止は、kube-apiserver-to-kubelet-signer CA 証明書の有効期限を慎重に考慮して、短期間のみ行う必要があります。
MCP を異なる OpenShift Container Platform バージョンに更新することは推奨されません。たとえば、ある MCP を 4.y.10 から 4.y.11 に更新せず、もう 1 つの MCP を 4.y.12 に更新しないでください。このシナリオはテストされておらず、未定義のクラスターの状態になる可能性があります。
3.4.2. カナリアロールアウト更新プロセスおよび MCP について
OpenShift Container Platform では、ノードは個別に考慮されません。代わりに、ノードはマシン設定プール (MCP) にグループ化されます。デフォルトでは、OpenShift Container Platform クラスター内のノードは 2 つの MCP にグループ化されます。1 つはコントロールプレーンノード用、もう 1 つはワーカーノード用です。OpenShift Container Platform の更新は、すべての MCP に同時に影響します。
更新中、Machine Config Operator (MCO) は、最大数が指定されている場合、指定された maxUnavailable ノード数まで MCP 内のすべてのノードをドレインし、遮断します。デフォルトでは、maxUnavailable は 1 に設定されます。ノードがドレイン (解放) および遮断し、ノード上のすべての Pod のスケジュールを解除し、ノードをスケジュール対象外としてマークします。
ノードがドレイン (解放) されると、Machine Config Daemon は新規マシン設定を適用します。これには、オペレーティングシステム (OS) の更新を含めることができます。OS を更新するには、ホストを再起動する必要があります。
カスタムマシン設定プールの使用
特定のノードが更新されないようにするには、カスタム MCP を作成します。一時停止された MCP 内のノードは、MCO によって更新されません。そのため、クラスターの更新を開始する前に、更新する必要がないノードを含む MCP を一時停止できます。
1 つ以上のカスタム MCP を使用すると、ワーカーノードを更新する順序をより詳細に制御できます。たとえば、最初の MCP のノードを更新した後、アプリケーションの互換性を確認してから、残りのノードを新しいバージョンに段階的に更新できます。
OpenShift Container Platform のすべてのマシン設定プールにおける maxUnavailable のデフォルト設定は 1 です。この値を変更せず、一度に 1 つのコントロールプレーンノードを更新することを推奨します。コントロールプレーンプールのこの値を 3 に変更しないでください。
コントロールプレーンの安定性を確保するには、コントロールプレーンノードからカスタム MCP の作成はサポートされません。Machine Config Operator (MCO) は、コントロールプレーンノード用に作成されるカスタム MCP を無視します。
カスタムマシン設定プールを使用する場合の考慮事項
ワークロードのデプロイメントトポロジーに基づいて、作成する MCP の数と各 MCP 内のノードの数を慎重に検討してください。たとえば、更新を特定のメンテナンス期間に合わせる必要がある場合は、OpenShift Container Platform が一定期間内に更新できるノードの数を把握しておく必要があります。この数は、それぞれのクラスターとワークロードの特性によって異なります。
カスタム MCP の数と各 MCP 内のノードの数を決定するには、クラスター内で利用可能な余剰容量についても考慮する必要があります。新しく更新されたノードでアプリケーションが期待どおりに動作しない場合は、プール内のそのノードを遮断してドレインし、アプリケーション Pod を他のノードに移動できます。ただし、他の MCP 内の使用可能なノードがアプリケーションに十分なサービス品質 (QoS) を提供できるかどうかを確認する必要があります。
この更新プロセスは、文書化されたすべての OpenShift Container Platform 更新プロセスで使用できます。ただし、このプロセスは、Ansible Playbook を使用して更新される Red Hat Enterprise Linux (RHEL) マシンでは機能しません。
3.4.3. カナリアロールアウト更新の実行について
次の手順は、カナリアロールアウト更新プロセスのワークフローの概要を示しています。
ワーカープールに基づいてカスタムマシン設定プール (MCP) を作成します。
注記MCP の
maxUnavailable設定を変更して、任意の時点で更新できるパーセンテージまたはマシン数を指定できます。デフォルトは1です。警告OpenShift Container Platform のすべてのマシン設定プールにおける
maxUnavailableのデフォルト設定は1です。この値を変更せず、一度に 1 つのコントロールプレーンノードを更新することを推奨します。コントロールプレーンプールのこの値を3に変更しないでください。ノードセレクターをカスタム MCP に追加します。残りのクラスターと同時に更新しない各ノードに、一致するラベルをノードに追加します。このラベルは、ノードを MCP に関連付けます。
重要ノードからデフォルトのワーカーラベルを削除しないでください。クラスター内でノードを適切に機能させるには、ノードにロールラベルが必要です。
- 更新プロセスの一部として更新しない MCP を一時停止します。
- クラスターの更新を実行します。更新プロセスでは、コントロールプレーンノードを含む、一時停止されていない MCP が更新されます。
- 更新されたノードでアプリケーションをテストし、期待どおりに動作することを確認します。
- 残りの MCP の 1 つを一時停止解除し、そのプール内のノードの更新が完了するのを待ち、それらのノードでアプリケーションをテストします。すべてのワーカーノードが更新されるまで、このプロセスを繰り返します。
- オプション: 更新されたノードからカスタムラベルを削除し、カスタム MCP を削除します。
3.4.4. カナリアロールアウト更新を実行するためのマシン設定プールの作成
カナリアロールアウト更新を実行するには、まず 1 つ以上のカスタムマシン設定プール (MCP) を作成する必要があります。
手順
次のコマンドを実行して、クラスター内のワーカーノードをリスト表示します。
$ oc get -l 'node-role.kubernetes.io/master!=' -o 'jsonpath={range .items[*]}{.metadata.name}{"\n"}{end}' nodes出力例
ci-ln-pwnll6b-f76d1-s8t9n-worker-a-s75z4 ci-ln-pwnll6b-f76d1-s8t9n-worker-b-dglj2 ci-ln-pwnll6b-f76d1-s8t9n-worker-c-lldbm
更新を遅らせるノードごとに、次のコマンドを実行してカスタムラベルをノードに追加します。
$ oc label node <node_name> node-role.kubernetes.io/<custom_label>=
以下に例を示します。
$ oc label node ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz node-role.kubernetes.io/workerpool-canary=
出力例
node/ci-ln-gtrwm8t-f76d1-spbl7-worker-a-xk76k labeled
新規 MCP を作成します。
MCP の YAML ファイルを作成します。
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool metadata: name: workerpool-canary 1 spec: machineConfigSelector: matchExpressions: - { key: machineconfiguration.openshift.io/role, operator: In, values: [worker,workerpool-canary] 2 } nodeSelector: matchLabels: node-role.kubernetes.io/workerpool-canary: "" 3
次のコマンドを実行して、
MachineConfigPoolオブジェクトを作成します。$ oc create -f <file_name>
出力例
machineconfigpool.machineconfiguration.openshift.io/workerpool-canary created
次のコマンドを実行して、クラスター内の MCP のリストとその現在の状態を表示します。
$ oc get machineconfigpool
出力例
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-b0bb90c4921860f2a5d8a2f8137c1867 True False False 3 3 3 0 97m workerpool-canary rendered-workerpool-canary-87ba3dec1ad78cb6aecebf7fbb476a36 True False False 1 1 1 0 2m42s worker rendered-worker-87ba3dec1ad78cb6aecebf7fbb476a36 True False False 2 2 2 0 97m
新規マシン設定プールの
workerpool-canaryが作成され、カスタムラベルが追加されたノード数がマシン数に表示されます。ワーカー MCP マシン数は同じ数で縮小されます。マシン数の更新に数分かかることがあります。この例では、1 つのノードがworkerMCP からworkerpool-canaryMCP に移動しました。
3.4.5. ワーカープールカナリアのマシン設定継承の管理
既存のマシン設定プール (MCP) に割り当てられている MachineConfig を継承するように、MCP カナリアを設定できます。この設定は、既存の MCP のノードを 1 つずつ更新しながら、MCP カナリアを使用してテストする場合に便利です。
前提条件
- 1 つ以上の MCP を作成した。
手順
次の 2 つのステップに従ってセカンダリー MCP を作成します。
次の設定ファイルを
machineConfigPool.yamlとして保存します。machineConfigPoolYAML の例apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool metadata: name: worker-perf spec: machineConfigSelector: matchExpressions: - { key: machineconfiguration.openshift.io/role, operator: In, values: [worker,worker-perf] } nodeSelector: matchLabels: node-role.kubernetes.io/worker-perf: "" # ...次のコマンドを実行して、新しいマシン設定プールを作成します。
$ oc create -f machineConfigPool.yaml
出力例
machineconfigpool.machineconfiguration.openshift.io/worker-perf created
セカンダリー MCP にいくつかのマシンを追加します。次の例では、ワーカーノード
worker-a、worker-b、worker-cにラベルを付けて、MCPworker-perfに追加します。$ oc label node worker-a node-role.kubernetes.io/worker-perf=''
$ oc label node worker-b node-role.kubernetes.io/worker-perf=''
$ oc label node worker-c node-role.kubernetes.io/worker-perf=''
次の 2 つのステップに従って、MCP
worker-perf用の新しいMachineConfigを作成します。次の
MachineConfigの例をnew-machineconfig.yamlというファイルとして保存します。MachineConfigYAML の例apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker-perf name: 06-kdump-enable-worker-perf spec: config: ignition: version: 3.2.0 systemd: units: - enabled: true name: kdump.service kernelArguments: - crashkernel=512M # ...次のコマンドを実行して
MachineConfigを適用します。$ oc create -f new-machineconfig.yaml
新しいカナリア MCP を作成し、前の手順で作成した MCP からマシンを追加します。次の例では、
worker-perf-canaryという MCP を作成し、以前に作成したworker-perfMCP からマシンを追加します。次のコマンドを実行して、カナリアワーカーノードに
worker-aというラベルを付けます。$ oc label node worker-a node-role.kubernetes.io/worker-perf-canary=''
次のコマンドを実行して、元の MCP からカナリアワーカーノード
worker-aを削除します。$ oc label node worker-a node-role.kubernetes.io/worker-perf-
次のファイルを
machineConfigPool-Canary.yamlとして保存します。machineConfigPool-Canary.yamlファイルの例apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool metadata: name: worker-perf-canary spec: machineConfigSelector: matchExpressions: - { key: machineconfiguration.openshift.io/role, operator: In, values: [worker,worker-perf,worker-perf-canary] 1 } nodeSelector: matchLabels: node-role.kubernetes.io/worker-perf-canary: ""- 1
- オプションの値。この例には、追加の値として
worker-perf-canaryが含まれています。このような形で値を使用すると、追加のMachineConfigのメンバーを設定できます。
次のコマンドを実行して、新しい
worker-perf-canaryを作成します。$ oc create -f machineConfigPool-Canary.yaml
出力例
machineconfigpool.machineconfiguration.openshift.io/worker-perf-canary created
MachineConfigがworker-perf-canaryに継承されているかどうかを確認します。次のコマンドを実行して、MCP がデグレード状態になっていないことを確認します。
$ oc get mcp
出力例
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-2bf1379b39e22bae858ea1a3ff54b2ac True False False 3 3 3 0 5d16h worker rendered-worker-b9576d51e030413cfab12eb5b9841f34 True False False 0 0 0 0 5d16h worker-perf rendered-worker-perf-b98a1f62485fa702c4329d17d9364f6a True False False 2 2 2 0 56m worker-perf-canary rendered-worker-perf-canary-b98a1f62485fa702c4329d17d9364f6a True False False 1 1 1 0 44m
マシンが
worker-perfからworker-perf-canaryに継承されていることを確認します。$ oc get nodes
出力例
NAME STATUS ROLES AGE VERSION ... worker-a Ready worker,worker-perf-canary 5d15h v1.27.13+e709aa5 worker-b Ready worker,worker-perf 5d15h v1.27.13+e709aa5 worker-c Ready worker,worker-perf 5d15h v1.27.13+e709aa5
次のコマンドを実行して、
worker-aでkdumpサービスが有効になっていることを確認します。$ systemctl status kdump.service
出力例
NAME STATUS ROLES AGE VERSION ... kdump.service - Crash recovery kernel arming Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; preset: disabled) Active: active (exited) since Tue 2024-09-03 12:44:43 UTC; 10s ago Process: 4151139 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS) Main PID: 4151139 (code=exited, status=0/SUCCESS)次のコマンドを実行して、MCP が
crashkernelを更新したことを確認します。$ cat /proc/cmdline
出力には更新された
crashekernel値が含まれるはずです。次に例を示します。出力例
crashkernel=512M
オプション: アップグレードに問題がなければ、
worker-aをworker-perfに戻すことができます。次のコマンドを実行して、
worker-aをworker-perfに戻します。$ oc label node worker-a node-role.kubernetes.io/worker-perf=''
次のコマンドを実行して、カナリア MCP から
worker-aを削除します。$ oc label node worker-a node-role.kubernetes.io/worker-perf-canary-
3.4.6. マシン設定プールの一時停止
カスタムマシン設定プール (MCP) を作成したら、それらの MCP を一時停止します。MCP を一時停止にすると、Machine Config Operator (MCO) がその MCP に関連付けられたノードを更新できなくなります。
手順
次のコマンドを実行して、一時停止する MCP にパッチを適用します。
$ oc patch mcp/<mcp_name> --patch '{"spec":{"paused":true}}' --type=merge以下に例を示します。
$ oc patch mcp/workerpool-canary --patch '{"spec":{"paused":true}}' --type=merge出力例
machineconfigpool.machineconfiguration.openshift.io/workerpool-canary patched
3.4.7. クラスターの更新の実行
マシン設定プール (MCP) が準備完了状態になったら、クラスターの更新を実行できます。クラスターに合わせて、以下の更新方法のいずれかを参照してください。
クラスターの更新が完了したら、MCP の一時停止を 1 つずつ解除し始めることができます。
3.4.8. マシン設定プールの一時停止の解除
OpenShift Container Platform の更新が完了したら、カスタムマシン設定プール (MCP) の一時停止を 1 つずつ解除します。MCP の一時停止を解除すると、Machine Config Operator(MCO) はその MCP に関連付けられたノードを更新できます。
手順
一時停止を解除する MCP にパッチを適用します。
$ oc patch mcp/<mcp_name> --patch '{"spec":{"paused":false}}' --type=merge以下に例を示します。
$ oc patch mcp/workerpool-canary --patch '{"spec":{"paused":false}}' --type=merge出力例
machineconfigpool.machineconfiguration.openshift.io/workerpool-canary patched
オプション: 次のいずれかの方法を使用して、更新の進行状況を確認します。
-
Web コンソールから Administration
Cluster settings をクリックして進行状況を確認します。 次のコマンドを実行して進行状況を確認します。
$ oc get machineconfigpools
-
Web コンソールから Administration
- 更新されたノードでアプリケーションをテストし、想定通りに機能していることを確認します。
- 他の一時停止中の MCP についても、1 つずつこのプロセスを繰り返します。
更新されたノードでアプリケーションが機能しないなどの障害が発生した場合は、プール内のノードを遮断してドレイン (解放) できます。これにより、アプリケーション Pod が他のノードに移動され、アプリケーションのサービス品質を維持できます。この最初の MCP は追加の容量よりも大きくすることはできません。
3.4.9. ノードを元のマシン設定プールに移動する
カスタムマシン設定プール (MCP) 内のノード上のアプリケーションを更新して検証したら、ノードに追加したカスタムラベルを削除して、ノードを元の MCP に戻します。
ノードには、クラスター内で適切に機能するロールが必要です。
手順
カスタム MCP 内のノードごとに、次のコマンドを実行してノードからカスタムラベルを削除します。
$ oc label node <node_name> node-role.kubernetes.io/<custom_label>-
以下に例を示します。
$ oc label node ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz node-role.kubernetes.io/workerpool-canary-
出力例
node/ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz labeled
Machine Config Operator がノードを元の MCP に戻し、ノードを MCP 設定に合わせて調整します。
ノードがカスタム MCP から削除されたことを確認するには、次のコマンドを実行して、クラスター内の MCP のリストとその現在の状態を表示します。
$ oc get mcp
出力例
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-1203f157d053fd987c7cbd91e3fbc0ed True False False 3 3 3 0 61m workerpool-canary rendered-mcp-noupdate-5ad4791166c468f3a35cd16e734c9028 True False False 0 0 0 0 21m worker rendered-worker-5ad4791166c468f3a35cd16e734c9028 True False False 3 3 3 0 61m
ノードをカスタム MCP から削除し、元の MCP に戻すると、マシン数の更新に数分かかることがあります。この例では、削除した
workerpool-canaryMCP から 1 つのノードをworkerMCP に移動しました。オプション: 次のコマンドを実行してカスタム MCP を削除します。
$ oc delete mcp <mcp_name>
