6.6. ポイズンピルオペレーターによるノードの修復
Poison Pill Operator を使用して、異常なノードを自動的に再起動できます。この修復戦略は、ステートフルアプリケーションと ReadWriteOnce(RWO) ボリュームのダウンタイムを最小限に抑え、一時的な障害が発生した場合に計算能力を回復します。
6.6.1. ポイズンピルオペレーターについて
Poison Pill Operator はクラスターノードで実行され、異常と識別されたノードを再起動します。オペレーターは、 MachineHealthCheck
コントローラーを使用して、クラスター内のノードの状態を検出します。ノードが異常であると識別されると、MachineHealthCheck
リソースは PoisonPillRemediation
カスタムリソース (CR) を作成し、 Poison PillOperator をトリガーします。
Poison Pill Operator は、ステートフルアプリケーションのダウンタイムを最小限に抑え、一時的な障害が発生した場合に計算能力を回復します。この Operator は、IPMI や API などの管理インターフェイスに関係なくノードをプロビジョニングするために使用できます。また、クラスターのインストールタイプ (インストーラーでプロビジョニングされたインフラストラクチャーやユーザーでプロビジョニングされたインフラストラクチャーなど) に関係なく使用できます。
6.6.1.1. ポイズンピルオペレーターの設定を理解する
Poison Pill Operator は、 PoisonPillConfig
の名前空間に poison-pill-config
という名前の PoisonPillConfigCR を作成します。この CR を編集できます。ただし、Poison PillOperator の新しい CR を作成することはできません。
PoisonPillConfig
CR を変更すると、PoisonPill デーモンセットが再作成されます。
PoisonPillConfig
CR は、次の YAML ファイルに似ています。
apiVersion: poison-pill.medik8s.io/v1alpha1 kind: PoisonPillConfig metadata: name: poison-pill-config namespace: openshift-operators spec: safeTimeToAssumeNodeRebootedSeconds: 180 1 watchdogFilePath: /test/watchdog1 2 isSoftwareRebootEnabled: true 3 apiServerTimeout: 15s 4 apiCheckInterval: 5s 5 maxApiErrorThreshold: 3 6 peerApiServerTimeout: 5s 7 peerDialTimeout: 5s 8 peerRequestTimeout: 5s 9 peerUpdateInterval: 15m 10
- 1
- 存続しているピアのタイムアウト期間を指定します。その後、オペレーターは異常なノードが再起動されたと見なすことができます。オペレーターは、この値の下限を自動的に計算します。ただし、ノードごとにウォッチドッグタイムアウトが異なる場合は、この値をより高い値に変更する必要があります。
- 2
- ノード内のウォッチドッグデバイスのファイルパスを指定します。ウォッチドッグデバイスへの誤ったパスを入力すると、Poison Pill Operator はソフトドッグデバイスのパスを自動的に検出します。
ウォッチドッグデバイスが使用できない場合、
PoisonPillConfig
CR はソフトウェアの再起動を使用します。 - 3
- 異常なノードのソフトウェア再起動を有効にするかどうかを指定します。デフォルトでは、
is Software Reboot Enabled
の値はtrue
に設定されています。ソフトウェアの再起動を無効にするには、パラメーター値をfalse
に設定します。 - 4
- 各 API サーバーとの接続を確認するためのタイムアウト期間を指定します。この期間が経過すると、Operator は修復を開始します。
- 5
- 各 API サーバーとの接続を確認する頻度を指定します。
- 6
- しきい値を指定します。このしきい値に達した後、ノードはピアへの接続を開始します。
- 7
- ピアが API サーバーに接続するためのタイムアウト期間を指定します。
- 8
- ピアとの接続を確立するためのタイムアウト期間を指定します。
- 9
- ピアからレスポンスを取得するためのタイムアウト期間を指定します。
- 10
- IP アドレスなどのピア情報を更新する頻度を指定します。
6.6.1.2. Poison Pill 修復テンプレートの設定について
Poison Pill Operator は、Poison Pill Operator の namespace に poison-pill-default-template
という名前の PoisonPillRemediationTemplate
CR も作成します。この CR は、ノードの修復ストラテジーを定義します。
デフォルトの修復ストラテジーは、node
オブジェクトを削除する NodeDeletion
です。OpenShift Container Platform 4.10 では、Poison Pill Operator は ResourceDeletion
という新規の修復ストラテジーを導入しています。ResourceDeletion
修復ストラテジーは、node
オブジェクトではなくノードでの Pod および関連付けられたボリュームの割り当てを削除します。このストラテジーは、ワークロードをより迅速に復元するのに役立ちます。
PoisonPillRemediationTemplate
CR は、次の YAML ファイルに似ています。
apiVersion: poison-pill.medik8s.io/v1alpha1
kind: PoisonPillRemediationTemplate
metadata:
creationTimestamp: "2022-03-02T08:02:40Z"
generation: 1
name: poison-pill-default-template
namespace: openshift-operators
resourceVersion: "596469"
uid: 5d29e437-c485-48fa-ba9e-0354649afd31
spec:
template:
spec:
remediationStrategy: NodeDeletion 1
- 1
- 修復ストラテジーを指定します。デフォルトの修復ストラテジーは
NodeDeletion
です。
6.6.1.3. ウォッチドッグデバイスについて
ウォッチドッグデバイスは、次のいずれかになります。
- 電源が独立しているハードウェアデバイス
- 制御するホストと電源を共有するハードウェアデバイス
-
ソフトウェアまたは
softdog
に実装された仮想デバイス
ハードウェアウォッチドッグデバイスと softdog
デバイスには、それぞれ電子タイマーまたはソフトウェアタイマーがあります。これらのウォッチドッグデバイスは、エラー状態が検出されたときにマシンが安全な状態になるようにするために使用されます。クラスターは、ウォッチドッグタイマーを繰り返しリセットして、正常な状態にあることを証明する必要があります。このタイマーは、デッドロック、CPU の枯渇、ネットワークまたはディスクアクセスの喪失などの障害状態が原因で経過する可能性があります。タイマーが時間切れになると、ウォッチドッグデバイスは障害が発生したと見なし、デバイスがノードの強制リセットをトリガーします。
ハードウェアウォッチドッグデバイスは、softdog
デバイスよりも信頼性があります。
6.6.1.3.1. ウォッチドッグデバイスを使用した Poison Pill Operator の動作
Poison Pill Operator は、存在するウォッチドッグデバイスに基づいて修復ストラテジーを決定します。
ハードウェアウォッチドッグデバイスが設定されて使用可能である場合、Operator はそれを修復に使用します。ハードウェアウォッチドッグデバイスが設定されていない場合、Operator は修復のために softdog
デバイスを有効にして使用します。
システムまたは設定のどちらかで、いずれのウォッチドッグデバイスもサポートされていない場合、Operator はソフトウェアの再起動を使用してノードを修復します。
関連情報
6.6.2. Web コンソールを使用した PoisonPillOperator のインストール
OpenShift Container Platform Web コンソールを使用して、Poison PillOperator をインストールできます。
前提条件
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
-
OpenShift Container Platform Web コンソールで、Operators
OperatorHub ページに移動します。 - 使用可能なオペレーターのリストからポイズンピルオペレーターを検索し、Installをクリックします。
-
Operator が
openshift-operators
namespace にインストールされるように、Installation mode と namespace のデフォルトの選択を維持します。 - Install をクリックします。
検証
インストールが正常に行われたことを確認するには、以下を実行します。
-
Operators
Installed Operators ページに移動します。 -
Operator が
openshift-operators
の namespace に設置されていることと、その状態がSucceeded
になっていることを確認してください。
Operator が正常にインストールされていない場合、以下を実行します。
-
Operators
Installed Operators ページに移動し、 Status
列でエラーまたは失敗の有無を確認します。 -
Workloads
Podsページに移動し、問題を報告している poison-pill-controller-manager
プロジェクトの Pod のログを確認します。
6.6.3. CLI を使用した PoisonPillOperator のインストール
OpenShift CLI(oc
) を使用して、Poison PillOperator をインストールできます。
Poison Pill Operator は、独自の namespace または openshift-operators
namespace にインストールできます。
独自の namespace に Operator をインストールするには、手順に従います。
openshift-operators
namespace に Operator をインストールするには、手順の 3 にスキップします。これは、新しい Namespace
カスタムリソース (CR) と OperatorGroup
CR を作成する必要がないためです。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
Poison Pill Operator の
Namespace
カスタムリソース (CR) を作成します。Namespace
CR を定義し、YAML ファイルを保存します (例:poison-pill-namespace.yaml
)。apiVersion: v1 kind: Namespace metadata: name: poison-pill
Namespace
CR を作成するには、次のコマンドを実行します。$ oc create -f poison-pill-namespace.yaml
OperatorGroup
を作成します。OperatorGroup
CR を定義し、YAML ファイルを保存します (例:poison-pill-operator-group.yaml
)。apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: poison-pill-manager namespace: poison-pill
OperatorGroup
CR を作成するには、次のコマンドを実行します。$ oc create -f poison-pill-operator-group.yaml
Subscription
CR を作成します。Subscription
CR を定義し、YAML ファイル (poison-pill-subscription.yaml
など) を保存します。apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: poison-pill-manager namespace: poison-pill 1 spec: channel: stable installPlanApproval: Manual 2 name: poison-pill-manager source: redhat-operators sourceNamespace: openshift-marketplace package: poison-pill-manager
Subscription
CR を作成するには、次のコマンドを実行します。$ oc create -f poison-pill-subscription.yaml
検証
CSV リソースを調べて、インストールが成功したことを確認します。
$ oc get csv -n poison-pill
出力例
NAME DISPLAY VERSION REPLACES PHASE poison-pill.v.0.2.0 Poison Pill Operator 0.2.0 Succeeded
Poison PillOperator が稼働していることを確認します。
$ oc get deploy -n poison-pill
出力例
NAME READY UP-TO-DATE AVAILABLE AGE poison-pill-controller-manager 1/1 1 1 10d
Poison PillOperator が
PoisonPillConfig
CR を作成したことを確認します。$ oc get PoisonPillConfig -n poison-pill
出力例
NAME AGE poison-pill-config 10d
各ポイズンピル Pod がスケジュールされ、各ワーカーノードで実行されていることを確認します。
$ oc get daemonset -n poison-pill
出力例
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE poison-pill-ds 2 2 2 2 2 <none> 10d
注記このコマンドは、コントロールプレーンノードではサポートされていません。
6.6.4. ポイズンピルオペレーターを使用するためのマシンヘルスチェックの設定
次の手順を使用して、Poison PillOperator を修復プロバイダーとして使用するようにマシンヘルスチェックを設定します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
PoisonPillRemediationTemplate
CR を作成します。PoisonPillRemediationTemplate
を定義します。apiVersion: poison-pill.medik8s.io/v1alpha1 kind: PoisonPillRemediationTemplate metadata: namespace: openshift-machine-api name: poisonpillremediationtemplate-sample spec: template: spec: {}
PoisonPillRemediationTemplate
CR を作成するには、次のコマンドを実行します。$ oc create -f <ppr-name>.yaml
PoisonPillRemediationTemplate
CR を指すようにMachineHealthCheck
CR を作成または更新します。MachineHealthCheck
を定義または更新します。apiVersion: machine.openshift.io/v1beta1 kind: MachineHealthCheck metadata: name: machine-health-check namespace: openshift-machine-api spec: selector: matchLabels: machine.openshift.io/cluster-api-machine-role: "worker" machine.openshift.io/cluster-api-machine-type: "worker" unhealthyConditions: - type: "Ready" timeout: "300s" status: "False" - type: "Ready" timeout: "300s" status: "Unknown" maxUnhealthy: "40%" nodeStartupTimeout: "10m" remediationTemplate: 1 kind: PoisonPillRemediationTemplate apiVersion: poison-pill.medik8s.io/v1alpha1 name: poisonpillremediationtemplate-sample
- 1
- 修復テンプレートの詳細を指定します。
MachineHealthCheck
CR を作成するには、次のコマンドを実行します。$ oc create -f <file-name>.yaml
MachineHealthCheck
CR を更新するには、次のコマンドを実行します。$ oc apply -f <file-name>.yaml
6.6.5. ポイズンピルオペレーターのトラブルシューティング
6.6.5.1. 一般的なトラブルシューティング
- 問題
- ポイズンピルオペレーターの問題をトラブルシューティングしたいと考えています。
- 解決策
- オペレーターログを確認してください。
6.6.5.2. デーモンセットの確認
- 問題
- Poison Pill Operator はインストールされていますが、デーモンセットは使用できません。
- 解決策
- エラーまたは警告がないか、オペレーターログを確認してください。
6.6.5.3. 失敗した修復
- 問題
- 不健康なノードは修正されませんでした。
- 解決策
次のコマンドを実行して、
PoisonPillRemediation
CR が作成されたことを確認します。$ oc get ppr -A
ノードが不健康になったときに
MachineHealthCheck
コントローラーがPoisonPillRemediation
CR を作成しなかった場合は、MachineHealthCheck
コントローラーのログを確認してください。さらに、MachineHealthCheck
CR に、修復テンプレートを使用するために必要な仕様が含まれていることを確認してください。PoisonPillRemediation
CR が作成された場合は、その名前が異常なノードまたはマシンオブジェクトと一致することを確認してください。
6.6.5.4. Poison Pill Operator をアンインストールした後でも、デーモンセットおよびその他の Poison Pill Operator リソースが存在する
- 問題
- Poison Pill Operator のリソース (デーモンセット、設定 CR、修復テンプレート CR など) は、Operator をアンインストールした後も存在します。
- 解決策
Poison Pill Operator リソースを削除するには、リソースタイプごとに次のコマンドを実行してリソースを削除します。
$ oc delete ds <poison-pill-ds> -n <namespace>
$ oc delete ppc <poison-pill-config> -n <namespace>
$ oc delete pprt <poison-pill-remediation-template> -n <namespace>
6.6.6. Poison Pill Operator に関するデータの収集
Poison Pill Operator に関するデバッグ情報を収集するには、must-gather
ツールを使用します。Poison Pill Operator の must-gather
イメージに関する詳細は、Gathering data about specific features を参照してください。
6.6.7. 関連情報
- Poison Pill Operator は、制限されたネットワーク環境でサポートされています。詳細は、ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。
- クラスターからの Operator の削除