12.5. コントロールプレーンの回復力と回復
コントロールプレーンマシンセットを使用して、OpenShift Container Platform クラスターのコントロールプレーンの回復力を向上させることができます。
12.5.1. 障害ドメインによる高可用性と耐障害性
可能な場合、コントロールプレーンマシンセットは、コントロールプレーンマシンを複数の障害ドメインに分散します。この設定は、コントロールプレーン内で高可用性とフォールトトレランスを提供します。この戦略は、インフラストラクチャープロバイダー内で問題が発生した場合に、コントロールプレーンを保護するのに役立ちます。
12.5.1.1. 障害ドメインプラットフォームのサポートと設定
障害ドメインのコントロールプレーンマシンセットの概念は、クラウドプロバイダーの既存の概念に似ています。すべてのプラットフォームが障害ドメインの使用をサポートしているわけではありません。
| クラウドプロバイダー | 障害ドメインのサポート | プロバイダーの命名法 |
|---|---|---|
| Amazon Web Services (AWS) | X | |
| Google Cloud Platform (GCP) | X | |
| Nutanix | 該当なし[1] | |
| Microsoft Azure | X | |
| VMware vSphere | 該当なし | |
| Red Hat OpenStack Platform (RHOSP) | X |
- Nutanix には障害ドメインの概念がありますが、OpenShift Container Platform 4.14 にはこの機能のサポートが含まれていません。
コントロールプレーンマシンセットカスタムリソース (CR) の障害ドメイン設定は、プラットフォーム固有です。CR の障害ドメインパラメーターの詳細は、プロバイダーの障害ドメイン設定のサンプルを参照してください。
12.5.1.2. コントロールプレーンマシンのバランス調整
コントロールプレーンマシンセットは、カスタムリソース (CR) で指定された障害ドメイン全体でコントロールプレーンマシンのバランスをとります。
可能な場合、コントロールプレーンマシンセットは各障害ドメインを均等に使用して、適切なフォールトトレランスを確保します。コントロールプレーンマシンよりも障害ドメインが少ない場合、障害ドメインは名前のアルファベット順に選択されて再利用されます。障害ドメインが指定されていないクラスターの場合、すべてのコントロールプレーンマシンが単一の障害ドメイン内に配置されます。
障害ドメインの設定にいくつかの変更を加えると、コントロールプレーンマシンセットがコントロールプレーンマシンのバランスを再調整します。たとえば、障害ドメインがコントロールプレーンマシンよりも少ないクラスターに障害ドメインを追加すると、コントロールプレーンマシンセットは、使用可能なすべての障害ドメイン間でマシンのバランスを再調整します。
12.5.2. 障害が発生したコントロールプレーンマシンの復旧
Control Plane Machine Set Operator は、コントロールプレーンマシンの復旧を自動化します。コントロールプレーンマシンが削除されると、Operator は ControlPlaneMachineSet カスタムリソース (CR) で指定された設定で置換を作成します。
コントロールプレーンマシンセットを使用するクラスターの場合、マシンのヘルスチェックを設定できます。マシンのヘルスチェックでは、異常なコントロールプレーンマシンが削除され、置き換えられます。
コントロールプレーンの MachineHealthCheck リソースを設定する場合は、maxUnhealthy の値を 1 に設定します。
この設定により、複数のコントロールプレーンマシンが異常であると思われる場合に、マシンのヘルスチェックがアクションを実行しないことが保証されます。複数の異常なコントロールプレーンマシンは、etcd クラスターが劣化していること、または障害が発生したマシンを置き換えるためのスケーリング操作が進行中であることを示している可能性があります。
etcd クラスターが劣化している場合は、手動での介入が必要になる場合があります。スケーリング操作が進行中の場合は、マシンのヘルスチェックで完了できるようにする必要があります。
関連情報
12.5.3. マシンライフサイクルフックによるクォーラム保護
Machine API Operator を使用する OpenShift Container Platform クラスターの場合、etcd Operator はマシン削除フェーズのライフサイクルフックを使用して、クォーラム保護メカニズムを実装します。
preDrain ライフサイクルフックを使用することにより、etcd Operator は、コントロールプレーンマシン上の Pod がいつドレインされ、削除されるかを制御できます。etcd クォーラムを保護するために、etcd Operator は、etcd メンバーをクラスター内の新しいノードに移行するまで、そのメンバーの削除を防ぎます。
このメカニズムにより、etcd クラスターの具体的な運用上の知識がなくても、etcd Operator によって etcd クォーラムのメンバーを正確に制御できるようになり、Machine API Operator によってコントロールプレーンマシンを安全に作成および削除できるようになります。
12.5.3.1. クォーラム保護処理順序によるコントロールプレーンの削除
コントロールプレーンマシンセットを使用するクラスター上でコントロールプレーンマシンが置き換えられると、クラスターには一時的に 4 つのコントロールプレーンマシンが存在します。4 番目のコントロールプレーンノードがクラスターに参加すると、etcd Operator は代替ノードで新しい etcd メンバーを開始します。etcd Operator は、古いコントロールプレーンマシンが削除対象としてマークされていることを確認すると、古いノード上の etcd メンバーを停止し、代替の etcd メンバーをクラスターのクォーラムに参加するように昇格させます。
コントロールプレーンマシンの Deleting フェーズは、以下の順序で続行されます。
- コントロールプレーンマシンは削除される予定です。
-
コントロールプレーンマシンは
Deletingフェーズに入ります。 preDrainライフサイクルフックを満たすために、etcd Operator は次のアクションを実行します。-
etcd Operator は、4 番目のコントロールプレーンマシンが etcd メンバーとしてクラスターに追加されるまで待機します。この新しい etcd メンバーの状態は
Runningですが、etcd リーダーから完全なデータベース更新を受信するまではreadyができていません。 - 新しい etcd メンバーが完全なデータベース更新を受け取ると、etcd Operator は新しい etcd メンバーを投票メンバーに昇格させ、古い etcd メンバーをクラスターから削除します。
この移行が完了すると、古い etcd Pod とそのデータは安全に削除されるため、
preDrainライフサイクルフックが削除されます。-
etcd Operator は、4 番目のコントロールプレーンマシンが etcd メンバーとしてクラスターに追加されるまで待機します。この新しい etcd メンバーの状態は
-
コントロールプレーンマシンのステータス条件
DrainableがTrueに設定されます。 マシンコントローラーは、コントロールプレーンマシンによってサポートされているノードをドレインしようとします。
-
ドレインが失敗した場合、
Drainedは、Falseに設定され、マシンコントローラーはノードのドレインを再度試行します。 -
ドレインに成功すると、
DrainedはTrueに設定されます。
-
ドレインが失敗した場合、
-
コントロールプレーンマシンのステータス条件
DrainedがTrueに設定されます。 -
他の Operator が
preTerminateライフサイクルフックを追加していない場合、コントロールプレーンのマシンステータス条件TerminableはTrueに設定されます。 - マシンコントローラーは、インフラストラクチャープロバイダーからインスタンスを削除します。
-
マシンコントローラーは
Nodeオブジェクトを削除します。
etcd クォーラム保護の preDrain ライフサイクルフックを示す YAML スニペット
apiVersion: machine.openshift.io/v1beta1
kind: Machine
metadata:
...
spec:
lifecycleHooks:
preDrain:
- name: EtcdQuorumOperator 1
owner: clusteroperator/etcd 2
...
関連情報
