修復、フェンシング、およびメンテナンス

Workload Availability for Red Hat OpenShift 23.3

ワークロードの可用性の修復、フェンシング、およびメンテナンス

Red Hat Customer Content Services

概要

ワークロード可用性演算子とその使用法に関する情報

はじめに

Workload Availability for Red Hat OpenShift に関するフィードバック

Red Hat ドキュメントに関するご意見やご感想をお寄せください。また、改善点があればお知らせください。これを行うには、以下を行います。

  1. JIRA の Web サイトにアクセスします。
  2. Summary フィールドにわかりやすいタイトルを入力します。
  3. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも追加してください。
  4. Reporter フィールドにユーザー名を入力します。
  5. Affects Version/s フィールドに、影響を受けるバージョンを入力します。
  6. ダイアログの下部にある Create をクリックします。

第1章 ノードの修復、フェンシング、およびメンテナンスについて

ハードウェアは不完全であり、ソフトウェアにはバグが含まれています。カーネルのハングやネットワークインターフェイスコントローラー (NIC) の障害などのノードレベルの障害が発生した場合、クラスターから必要な作業は減少せず、影響を受けるノードからのワークロードをどこかで再起動する必要があります。ただし、ReadWriteOnce (RWO) ボリュームや StatefulSet などの一部のワークロードでは、最大で 1 つのセマンティクスが必要になる場合があります。

これらのワークロードに影響を与える障害は、データの損失、破損、またはその両方のリスクを伴います。ワークロードの回復 (remediation と理想的にはノードの回復とも呼ばれます) を開始する前に、fencing と呼ばれる安全な状態にノードが達していることを確認することが重要です。

ノードとワークロードの true のステータスを確認するために管理者の介入に依存することは、必ずしも現実的ではありません。このような介入を容易にするために、Red Hat OpenShift は、障害検出、フェンシング、および修復を自動化するための複数のコンポーネントを提供します。

1.1. 自己ノード修復

Self Node Remediation Operator は Red Hat OpenShift のアドオン Operator であり、異常なノードを再起動し、Pod や VolumeAttachments などのリソースを削除するフェンシングと修復の外部システムを実装します。再起動により、ワークロードが隔離され、リソースの削除により、影響を受けるワークロードの再スケジュールが加速されます。他の外部システムとは異なり、自己ノード修復には、Intelligent Platform Management Interface (IPMI) やノードプロビジョニング用の API などの管理インターフェイスは必要ありません。

セルフノード修復は、マシンヘルスチェックやノードヘルスチェックなどの障害検出システムで使用できます。

1.2. フェンスエージェントの修正

Fence Agents Remediation (FAR) Operator は、Self Node Remediation Operator と同様に、異常なノードを自動的に修復する Red Hat OpenShift のアドオン Operator です。FAR は、管理インターフェイスまたは従来の API を使用して fence-agent を実行し、ノードの電源を入れ直すことによってノードを異常な状態から修復します。

FAR は、クラスターノードの電源を入れ直すために、IPMI などの従来の API エンドポイントを備えた環境で、既存の一連のアップストリームフェンシングエージェントを実行するように設計されています。

1.3. Machine Deletion Remediation (マシン削除の修復)

Machine Deletion Remediation (MDR) Operator は、マシン API を使用して異常なノードを再プロビジョニングする Red Hat OpenShift アドオン Operator です。MDR は NodeHealthCheck (NHC) と連携して、異常なノードに関する情報を含む MDR のカスタムリソース (CR) を作成します。

MDR は、ノード上のアノテーションをたどって、関連付けられたマシンオブジェクトを確認し、所有するコントローラーがあることを確認します。MDR はマシンの削除を続行し、所有するコントローラーが代替マシンを再作成します。

1.4. Machine Health Check (マシンのヘルスチェック)

Machine Health Check は、マシンのステータスとノードの状態をモニターする Red Hat OpenShift ビルトインの失敗検出、フェンシング、修復システムを利用します。マシンヘルスチェックは、セルフノード修復などの外部フェンシングおよび修復システムをトリガーするように設定できます。

1.5. ノードのヘルスチェック

Node Health Check Operator は、ノードの状態をモニターする障害検出システムを実装する Red Hat OpenShift のアドオン Operator です。フェンシングまたは修復システムが組み込まれていないため、そのような機能を提供する外部システムで設定する必要があります。デフォルトでは、セルフノード修復システムを利用するように設定されています。

1.6. ノードのメンテナンス

管理者は、ドライブ、RAM、または NIC を交換するなど、クラスターを中断する必要がある状況に直面します。

このメンテナンスの前に、影響を受けるノードを封鎖して排水する必要があります。ノードが封鎖されると、そのノードで新しいワークロードをスケジュールできなくなります。ノードがドレインされると、ダウンタイムを回避または最小化するために、影響を受けるノードのワークロードが他のノードに転送されます。

このメンテナンスはコマンドラインツールを使用して実行できますが、Node Maintenance Operator は、カスタムリソースを使用してこれを達成するための宣言的なアプローチを提供します。このようなリソースがノードに存在する場合、Operator はリソースが削除されるまでノードを遮断し、ドレインします。

第2章 Self Node Remediation の使用

Self Node Remediation Operator を使用して、異常なノードを自動的に再起動できます。この修復戦略は、ステートフルアプリケーションと ReadWriteOnce(RWO) ボリュームのダウンタイムを最小限に抑え、一時的な障害が発生した場合に計算能力を回復します。

2.1. Self Node Remediation Operator について

Self Node Remediation Operator はクラスターノードで実行され、正常でないと特定されるノードを再起動します。Operator は、MachineHealthCheck または NodeHealthCheck コントローラーを使用して、クラスター内のノードの正常性を検出します。ノードが異常であると識別されると、MachineHealthCheck または NodeHealthCheck リソースが SelfNodeRemediation カスタムリソース (CR) を作成し、Self NodeRemediationOperator をトリガーします。

SelfNodeRemediation CR は、次の YAML ファイルに似ています。

apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediation
metadata:
  name: selfnoderemediation-sample
  namespace: openshift-operators
spec:
  remediationStrategy: <remediation_strategy> 1
status:
  lastError: <last_error_message> 2
1
ノードの修復ストラテジーを指定します。
2
修復中に発生した最後のエラーを表示します。修復が正常に実行されるか、エラーが発生しない場合は、このフィールドは空になります。

Self Node Remediation Operator は、ステートフルアプリケーションのダウンタイムを最小限に抑え、一時的な障害が発生した場合に計算能力を回復します。この Operator は、IPMI や API などの管理インターフェイスに関係なくノードをプロビジョニングするために使用できます。また、クラスターのインストールタイプ (インストーラーでプロビジョニングされたインフラストラクチャーやユーザーでプロビジョニングされたインフラストラクチャーなど) に関係なく使用できます。

2.1.1. ウォッチドッグデバイスについて

ウォッチドッグデバイスは、次のいずれかになります。

  • 電源が独立しているハードウェアデバイス
  • 制御するホストと電源を共有するハードウェアデバイス
  • ソフトウェアまたは softdog に実装された仮想デバイス

ハードウェアウォッチドッグデバイスと softdog デバイスには、それぞれ電子タイマーまたはソフトウェアタイマーがあります。これらのウォッチドッグデバイスは、エラー状態が検出されたときにマシンが安全な状態になるようにするために使用されます。クラスターは、ウォッチドッグタイマーを繰り返しリセットして、正常な状態にあることを証明する必要があります。このタイマーは、デッドロック、CPU の枯渇、ネットワークまたはディスクアクセスの喪失などの障害状態が原因で経過する可能性があります。タイマーが時間切れになると、ウォッチドッグデバイスは障害が発生したと見なし、デバイスがノードの強制リセットをトリガーします。

ハードウェアウォッチドッグデバイスは、softdog デバイスよりも信頼性があります。

2.1.1.1. ウォッチドッグデバイスを使用した Self Node Remediation Operator の動作の理解

Self Node Remediation Operator は、存在するウォッチドッグデバイスに基づいて修復戦略を決定します。

ハードウェアウォッチドッグデバイスが設定されて使用可能である場合、Operator はそれを修復に使用します。ハードウェアウォッチドッグデバイスが設定されていない場合、Operator は修復のために softdog デバイスを有効にして使用します。

システムまたは設定のどちらかで、いずれのウォッチドッグデバイスもサポートされていない場合、Operator はソフトウェアの再起動を使用してノードを修復します。

2.2. コントロールプレーンフェンシング

以前のリリースでは、ワーカーノードでセルフノード修復とノードヘルスチェックを有効にすることができました。ノード障害が発生した場合、コントロールプレーンノードの修復戦略に従うこともできるようになりました。

自己ノード修復は、主に 2 つのシナリオで発生します。

  • API サーバー接続

    • このシナリオでは、修復されるコントロールプレーンノードは分離されていません。API サーバーに直接接続することも、API サーバーに直接接続されているワーカーノードまたはコントロールプレーンノードを介して API サーバーに間接的に接続することもできます。
    • API サーバー接続がある場合、コントロールプレーンノードは、Node Health Check Operator がノードの SelfNodeRemediation カスタムリソース (CR) を作成した場合にのみ修復されます。
  • API サーバー接続なし

    • このシナリオでは、修復されるコントロールプレーンノードは API サーバーから分離されています。ノードは API サーバーに直接または間接的に接続できません。
    • API サーバー接続がない場合、コントロールプレーンノードは次の手順で説明されているように修正されます。

      • ピアワーカーノードの大部分を含むコントロールプレーンノードのステータスを確認します。ピアワーカーノードの大部分に到達できない場合、ノードはさらに分析されます。

        • コントロールプレーンノードのステータスを自己診断する

          • 自己診断に合格した場合、アクションは実行されません。
          • 自己診断に失敗した場合、ノードは隔離され、修復されます。
          • 現在サポートされている自己診断では、kubelet サービスのステータスをチェックし、opt in 設定を使用してエンドポイントの可用性をチェックしています。
      • ノードがほとんどのワーカーピアと通信できなかった場合は、コントロールプレーンノードと他のコントロールプレーンノードとの接続を確認します。ノードが他のコントロールプレーンピアと通信できる場合、アクションは実行されません。それ以外の場合、ノードは隔離され、修正されます。

2.3. Web コンソールを使用した Self Node Remediation Operator のインストール

Red Hat OpenShift Web コンソールを使用して、Self Node Remediation Operator をインストールできます。

注記

Node Health Check Operator は、Self Node Remediation Operator をデフォルトの修復プロバイダーとしてインストールします。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. Red Hat OpenShift Web コンソールで、OperatorsOperatorHub に移動します。
  2. 使用可能な Operator のリストから Self Node Remediation Operator を選択し、Install をクリックします。
  3. Operator が openshift-operators namespace にインストールされるように、Installation modenamespace のデフォルトの選択を維持します。
  4. Install をクリックします。

検証

インストールが正常に行われたことを確認するには、以下を実行します。

  1. OperatorsInstalled Operators ページに移動します。
  2. Operator が openshift-operators の namespace に設置されていることと、その状態が Succeeded になっていることを確認してください。

Operator が正常にインストールされていない場合、以下を実行します。

  1. OperatorsInstalled Operators ページに移動し、Status 列でエラーまたは失敗の有無を確認します。
  2. WorkloadsPod ページに移動し、openshift-operators プロジェクト内の self-node-remediation-controller-manager Pod および self-node-remediation-ds Pod のログで、報告された問題がないか確認します。

2.4. CLI を使用した Self Node Remediation Operator のインストール

OpenShift CLI (oc) を使用して、Self Node Remediation Operator をインストールできます。

Self Node Remediation Operator は、独自の namespace または openshift-operators namespace にインストールできます。

独自の namespace に Operator をインストールするには、手順に従います。

openshift-operators namespace に Operator をインストールするには、手順の 3 にスキップします。これは、新しい Namespace カスタムリソース (CR) と OperatorGroup CR を作成する必要がないためです。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. Self Node Remediation Operator の Namespace カスタムリソース (CR) を作成します。

    1. Namespace CR を定義し、YAML ファイルを保存します (例: self-node-remediation-namespace.yaml)。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: self-node-remediation
    2. NamespaceCR を作成するには、次のコマンドを実行します。

      $ oc create -f self-node-remediation-namespace.yaml
  2. OperatorGroup を作成します。

    1. OperatorGroup CR を定義し、YAML ファイルを保存します (例: self-node-remediation-operator-group.yaml)。

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: self-node-remediation-operator
        namespace: self-node-remediation
    2. OperatorGroup CR を作成するには、次のコマンドを実行します。

      $ oc create -f self-node-remediation-operator-group.yaml
  3. SubscriptionCR を作成します。

    1. Subscription CR を定義し、YAML ファイルを保存します (例: self-node-remediation-subscription.yaml)。

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
          name: self-node-remediation-operator
          namespace: self-node-remediation 1
      spec:
          channel: stable
          installPlanApproval: Manual 2
          name: self-node-remediation-operator
          source: redhat-operators
          sourceNamespace: openshift-marketplace
          package: self-node-remediation
      1
      Self Node Remediation Operator をインストールする Namespace を指定します。セルフノード修復 Operator を openshift-operators namespace にインストールするには、Subscription CR で openshift-operators を指定します。
      2
      指定したバージョンがカタログの新しいバージョンに置き換えられる場合に備えて、承認ストラテジーを Manual に設定します。これにより、新しいバージョンへの自動アップグレードが阻止され、最初の CSV のインストールが完了する前に手動での承認が必要となります。
    2. SubscriptionCR を作成するには、次のコマンドを実行します。

      $ oc create -f self-node-remediation-subscription.yaml

検証

  1. CSV リソースを調べて、インストールが成功したことを確認します。

    $ oc get csv -n self-node-remediation

    出力例

    NAME                               DISPLAY                          VERSION   REPLACES   PHASE
    self-node-remediation.v.0.7.0      Self Node Remediation Operator   v.0.7.0              Succeeded

  2. Self Node Remediation Operator が稼働していることを確認します。

    $ oc get deploy -n self-node-remediation

    出力例

    NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
    self-node-remediation-controller-manager    1/1     1            1           28h

  3. Self Node Remediation Operator が SelfNodeRemediationConfig CR を作成していることを確認します。

    $ oc get selfnoderemediationconfig -n self-node-remediation

    出力例

    NAME                           AGE
    self-node-remediation-config   28h

  4. 各セルフノード修復 Pod がスケジュールされ、各ワーカーノードとコントロールプレーンノードで実行されていることを確認します。

    $ oc get daemonset -n self-node-remediation

    出力例

    NAME                      DESIRED  CURRENT  READY  UP-TO-DATE  AVAILABLE  NODE SELECTOR  AGE
    self-node-remediation-ds  6        6        6      6           6          <none>         28h

2.5. Self Node Remediation Operator の設定

Self Node Remediation Operator は、SelfNodeRemediationConfig CR と SelfNodeRemediationTemplate カスタムリソース定義 (CRD) を作成します。

2.5.1. Self Node Remediation Operator 設定について

Self Node Remediation Operator は、self-node-remediation-config という名前の SelfNodeRemediationConfigCR を作成します。CR は Self Node Remediation Operator の namespace に作成されます。

SelfNodeRemediationConfig CR の変更により、Self Node Remediation デーモンセットが再作成されます。

SelfNodeRemediationConfig CR は以下の YAML ファイルのようになります。

apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediationConfig
metadata:
  name: self-node-remediation-config
  namespace: openshift-operators
spec:
  safeTimeToAssumeNodeRebootedSeconds: 180 1
  watchdogFilePath: /dev/watchdog 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
  customDsTolerations: 11
      - effect: NoSchedule
        key: node-role.kubernetes.io.infra
        operator: Equal
        value: "value1"
        tolerationSeconds: 3600
1
Operator が、正常でないノードで実行中の影響を受けるワークロードを復元するまで待機する期間を指定します。障害が発生したノードで実行中の代替 Pod を開始すると、データの破損や 1 回実行セマンティクスの違反が生じる可能性があります。これを防ぐために、Operator は、ApiServerTimeoutApiCheckIntervalmaxApiErrorThresholdpeerDialTimeout、および peerRequestTimeout フィールドから計算された最小値よりも小さい値を無視します。
2
ノード内のウォッチドッグデバイスのファイルパスを指定します。ウォッチドッグデバイスへの誤ったパスを入力すると、Self Node Remediation Operator がソフトドッグデバイスのパスを自動的に検出します。

ウォッチドッグデバイスが使用できない場合、SelfNodeRemediationConfig CR はソフトウェアの再起動を使用します。

3
異常なノードのソフトウェア再起動を有効にするかどうかを指定します。デフォルトでは、is Software Reboot Enabled の値は true に設定されています。ソフトウェアの再起動を無効にするには、パラメーター値を false に設定します。
4
各 API サーバーとの接続を確認するためのタイムアウト期間を指定します。この期間が経過すると、Operator は修復を開始します。タイムアウト期間は 10 ミリ秒以上である必要があります。
5
各 API サーバーとの接続を確認する頻度を指定します。タイムアウト期間は 1 秒以上である必要があります。
6
しきい値を指定します。このしきい値に達した後、ノードはピアへの接続を開始します。しきい値は 1 秒以上である必要があります。
7
ピアが API サーバーに接続するためのタイムアウトの期間を指定します。タイムアウト期間は 10 ミリ秒以上である必要があります。
8
ピアで接続を確立するためのタイムアウトの期間を指定します。タイムアウト期間は 10 ミリ秒以上である必要があります。
9
ピアから応答を取得するためのタイムアウトの期間を指定します。タイムアウト期間は 10 ミリ秒以上である必要があります。
10
IP アドレスなどのピア情報を更新する頻度を指定します。タイムアウト期間は 10 秒以上である必要があります。
デーモンセットで実行されているカスタム容認の自己ノード修復エージェントを指定して、さまざまなタイプのノードの修復をサポートします。次のフィールドを設定できます。
  • effect: この効果は、一致する Taint 効果を示します。このフィールドが空の場合、すべてのテイント効果が一致します。指定されている場合、許可される値は NoSchedulePreferNoSchedule、および NoExecute です。
  • key: キーは、Toleration が適用される Taint キーです。このフィールドが空の場合、すべてのテイントキーが照合されます。キーが空の場合、Operator フィールドは Exists である必要があります。この組み合わせは、すべての値とすべてのキーを照合することを意味します。
  • Operator: 演算子はキーと値の関係を表します。有効な Operator は Exists および Equal です。デフォルトは Equal です。exists は、値のワイルドカードと同等であるため、Pod は特定のカテゴリーのすべてのテイントを許容できます。
  • Value: Toleration が一致する Taint の値。Operator が Exists の場合、値は空である必要があります。それ以外の場合は、通常の文字列にすぎません。
  • tolerationSeconds: Toleration (effect は NoExecute でなければならず、それ以外はこのフィールドは無視されます)がテイントを許容する期間。デフォルトでは設定されていません。つまり、テイントを永久に許容します(つまり、エビクトしません)。ゼロ値と負の値は、システムによって 0 (すぐにエビクト)として扱われます。
  • カスタム容認により、容認をセルフノード修復エージェント Pod に追加できます。詳細は、容認を使用した OpenShift Logging Pod の配置の制御 を 参照してください。
注記

Self NodeRemediationOperator によって作成された self-node-remediation-config CR を編集できます。ただし、Self Node Remediation Operator の新しい CR を作成しようとすると、次のメッセージがログに表示されます。

controllers.SelfNodeRemediationConfig
ignoring selfnoderemediationconfig CRs that are not named 'self-node-remediation-config'
or not in the namespace of the operator:
'openshift-operators' {"selfnoderemediationconfig":
"openshift-operators/selfnoderemediationconfig-copy"}

2.5.2. 自己ノード修復テンプレートの設定を理解する

Self Node Remediation Operator は、SelfNodeRemediationTemplate カスタムリソース定義 (CRD) も作成します。この CRD は、ノードの修復ストラテジーを定義します。次の修復戦略が利用可能です。

ResourceDeletion
この修復戦略では、ノードオブジェクトではなく、ノード上の Pod と関連するボリュームアタッチメントが削除されます。この戦略により、ワークロードがより迅速に回復されます。ResourceDeletion は、デフォルトの修復戦略です。
OutOfServiceTaint
この修復戦略により、ノードオブジェクトではなく、ノード上の Pod および関連するボリュームアタッチメントが暗黙的に削除されます。これは、OutOfServiceTaint 戦略をノードに配置することで実現します。この戦略により、ワークロードがより迅速に回復されます。このストラテジーは、OpenShift Container Platform バージョン 4.13 以降、および OpenShift Container Platform バージョン 4.15 以降、一般公開(GA)でサポートされます。

Self Node Remediation Operator は、ResourceDeletion 修復ストラテジーが使用するストラテジー self-node-remediation-resource-deletion-templateSelfNodeRemediationTemplate CR を作成します。

SelfNodeRemediationTemplate CR は以下の YAML ファイルのようになります。

apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediationTemplate
metadata:
  creationTimestamp: "2022-03-02T08:02:40Z"
  name: self-node-remediation-<remediation_object>-deletion-template 1
  namespace: openshift-operators
spec:
  template:
    spec:
      remediationStrategy: <remediation_strategy>  2
1
修復ストラテジーに基づいて修復テンプレートのタイプを指定します。<remediation_object>リソース または node のいずれかに置き換えます (例: self-node-remediation-resource-deletion-template)。
2
修復ストラテジーを指定します。修復ストラテジーは ResourceDeletion です。

2.5.3. Self Node Remediation Operator のトラブルシューティング

2.5.3.1. 一般的なトラブルシューティング

問題
Self Node Remediation Operator の問題のトラブルシューティングが必要です。
解決方法
Operator ログを確認してください。

2.5.3.2. デーモンセットの確認

問題
Self Node Remediation Operator はインストールされていますが、デーモンセットはインストールされません。
解決方法
エラーまたは警告がないか、オペレーターログを確認してください。

2.5.3.3. 失敗した修復

問題
不健康なノードは修正されませんでした。
解決方法

以下のコマンドを実行して、SelfNodeRemediation CR が作成されていることを確認します。

$ oc get snr -A

MachineHealthCheck コントローラーがノードが正常でない状態で SelfNodeRemediation CR を作成しなかった場合、MachineHealthCheck コントローラーのログを確認します。さらに、MachineHealthCheck CR に、修復テンプレートを使用するために必要な仕様が含まれていることを確認してください。

SelfNodeRemediation CR が作成される場合、その名前が正常でないノードまたはマシンオブジェクトと一致することを確認します。

2.5.3.4. Operator をアンインストールした後でも、デーモンセットおよびその他の Self Node Remediation Operator リソースが存在する

問題
デーモンセット、設定 CR、修復テンプレート CR などの Self Node Remediation Operator リソースは、Operator をアンインストールした後も存在します。
解決方法

Self Node Remediation Operator リソースを削除するには、リソースタイプごとに次のコマンドを実行してリソースを削除します。

$ oc delete ds <self-node-remediation-ds> -n <namespace>
$ oc delete snrc <self-node-remediation-config> -n <namespace>
$ oc delete snrt <self-node-remediation-template> -n <namespace>

2.5.4. Self Node Remediation Operator に関するデータの収集

Self Node Remediation Operator に関するデバッグ情報を収集するには、must-gather ツールを使用します。Self Node Remediation Operator のmust-gather イメージは、特定の機能に関するデータの収集 を参照してください。

2.5.5. 関連情報

第3章 Fence Agents Remediation の使用

Fence Agent Remediation Operator を使用して、Self Node Remediation Operator と同様に、異常なノードを自動的に修復できます。この Operator は、管理インターフェイスまたは従来の API を使用して fence-agent を実行し、ノードの電源を入れ直すことによってノードを異常な状態から修復します。

3.1. Fence Agent Remediation Operator について

Fence Agents Remediation (FAR) Operator は、外部ツールを使用して異常なノードを フェンス します。これらのツールはフェンスエージェントのセットであり、各フェンスエージェントをさまざまな環境で使用してノードをフェンスし、ノードを再起動する従来のアプリケーションプログラミングインターフェイス (API) 呼び出しを使用できます。これにより、FAR はステートフルアプリケーションのダウンタイムを最小限に抑え、一時的な障害が発生した場合にコンピューティング能力を回復し、ワークロードの可用性を向上させることができます。

FAR は、ノードが異常になったときにノードを隔離するだけでなく、ノードを異常な状態から正常な状態に 修復 しようとします。ステートレス Pod を削除するためのテイントを追加し、フェンスエージェントでノードをフェンスし、再起動後にリソースを削除して修復を完了し、残りのワークロード (ほとんどの場合ステートフルワークロード) を削除します。テイントを追加してワークロードを削除すると、ワークロードの再スケジュールが迅速化されます。

Operator は、FenceAgentsRemediation と呼ばれる新規または削除されたカスタムリソース (CR) を監視します。これにより、CR の名前に基づいてフェンスエージェントがノードを修復します。FAR は、NodeHealthCheck コントローラーを使用してクラスター内のノードの健全性を検出します。ノードが異常であると識別されると、NodeHealthCheck リソースは FenceAgentsRemediationTemplate CR に基づいて FenceAgentsRemediation CR を作成し、Fence Agents Remediation Operator をトリガーします。

FAR は、フェンスエージェントを使用して Kubernetes ノードをフェンスします。一般に、フェンシングは、応答しない/異常なコンピューターを安全な状態にし、コンピューターを隔離するプロセスです。フェンスエージェントは、管理インターフェイスを使用してフェンシングを実行するソフトウェアコードであり、主にコンピューターの電源の入れ直し、リセット、電源オフを可能にする電源ベースのフェンシングです。フェンスエージェントの例は、Intelligent Platform Management Interface (IPMI) 環境で使用される fence_ipmilan です。

apiVersion: fence-agents-remediation.medik8s.io/v1alpha1
kind: FenceAgentsRemediation
metadata:
  name: node-name 1
  namespace: openshift-operators
spec:
1
node-name は、正常でないクラスターノードの名前と一致する必要があります。

Operator には、Red Hat High Availability Add-On でも利用できるフェンスエージェントのセットが含まれており、IPMI や API などの管理インターフェイスを使用して、ベアメタルサーバー、仮想マシン、そしてクラウドプラットフォームのノードをプロビジョニング/再起動します。

3.2. Web コンソールを使用した Fence Agents Remediation Operator のインストール

Red Hat OpenShift Web コンソールを使用して、Fence Agents Remediation Operator をインストールできます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. Red Hat OpenShift Web コンソールで、OperatorsOperatorHub に移動します。
  2. 使用可能な Operator のリストから Fence Agents Remediation Operator (FAR) を選択し、Install をクリックします。
  3. Operator が openshift-operators namespace にインストールされるように、Installation modenamespace のデフォルトの選択を維持します。
  4. Install をクリックします。

検証

インストールが正常に行われたことを確認するには、以下を実行します。

  1. OperatorsInstalled Operators ページに移動します。
  2. Operator が openshift-operators の namespace に設置されていることと、その状態が Succeeded になっていることを確認してください。

Operator が正常にインストールされていない場合、以下を実行します。

  1. OperatorsInstalled Operators ページに移動し、Status 列でエラーまたは失敗の有無を確認します。
  2. WorkloadsPods ページに移動し、fence-agents-remediation-controller-manager Pod のログで報告された問題の有無を確認します。

3.3. CLI を使用した Fence Agents Remediation Operator のインストール

OpenShift CLI (oc) を使用して、Fence Agents Remediation Operator をインストールできます。

Fence Agents Remediation Operator は、独自の namespace または openshift-operators namespace にインストールできます。

独自の namespace に Operator をインストールするには、手順に従います。

openshift-operators namespace に Operator をインストールするには、手順の 3 にスキップします。これは、新しい Namespace カスタムリソース (CR) と OperatorGroup CR を作成する必要がないためです。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. Fence Agents Remediation Operator の namespace カスタムリソース (CR) を作成します。

    1. namespace CR を定義し、YAML ファイル (例: fence-agents-remediation-namespace.yaml) を保存します。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: fence-agents-remediation-namespace
    2. NamespaceCR を作成するには、次のコマンドを実行します。

      $ oc create -f fence-agents-remediation-namespace.yaml
  2. OperatorGroup を作成します。

    1. OperatorGroup CR を定義し、YAML ファイル (例: fence-agents-remediation-operator-group.yaml) を保存します。

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: fence-agents-remediation-operator-group
        namespace: fence-agents-remediation-namespace
    2. OperatorGroup CR を作成するには、次のコマンドを実行します。

      $ oc create -f fence-agents-remediation-operator-group.yaml
  3. SubscriptionCR を作成します。

    1. Subscription CR を定義し、YAML ファイル (例: fence-agents-remediation-subscription.yaml) を保存します。

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
          name: fence-agents-remediation-subscription
          namespace: fence-agents-remediation-namespace 1
      spec:
          channel: stable
          name: fence-agents-remediation
          source: redhat-operators
          sourceNamespace: openshift-marketplace
          package: fence-agents-remediation
      1
      Fence Agents Remediation Operator をインストールする namesoace を指定します (たとえば、この手順で前に説明した fence-agents-remediation-namespace)。一致する OperatorGroup CR がすでに存在する openshift-operators namespace に、Fence Agents Remediation Operator の Subscription CR をインストールできます。
    2. SubscriptionCR を作成するには、次のコマンドを実行します。

      $ oc create -f fence-agents-remediation-subscription.yaml

検証

  1. CSV リソースを調べて、インストールが成功したことを確認します。

    $ oc get csv -n fence-agents-remediation-namespace

    出力例

    NAME                               DISPLAY                          VERSION   REPLACES   PHASE
    fence-agents-remediation.v.0.2.0      Fence Agents Remediation Operator   v.0.2.0              Succeeded

  2. Fence Agents Remediation Operator が稼働していることを確認します。

    $ oc get deploy -n fence-agents-remediation-namespace

    出力例

    NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
    fence-agents-remediation-controller-manager    1/1     1            1           28h

3.4. Fence Agent Remediation Operator の設定

Fence Agents Remediation Operator を使用して、Node Health Check Operator (NHC) によって使用される FenceAgentsRemediationTemplate カスタムリソース (CR) を作成できます。この CR は、ノードを修復するために必要なすべてのパラメーターを備えたクラスターで使用されるフェンスエージェントを定義します。FenceAgentsRemediationTemplate CR は多数存在する可能性があり (フェンスエージェントごとに最大 1 つ)、NHC が使用されている場合、ノードの電源を再投入するために使用する remediationTemplate として FenceAgentsRemediationTemplate を選択できます。

注記

現在のリリースでは、多数の FenceAgentsRemediationTemplate CR が存在する可能性がありますが、フェンスエージェントごとに最大 1 つ存在できます。これは既知の制限事項であり、今後のリリースで対処される予定です。

FenceAgentsRemediationTemplate CR は以下の YAML ファイルのようになります。

apiVersion: fence-agents-remediation.medik8s.io/v1alpha1
kind: FenceAgentsRemediationTemplate
metadata:
  name: fence-agents-remediation-template-fence-ipmilan
  namespace: openshift-operators
spec:
  template:
    spec:
      agent: fence_ipmilan 1
        nodeparameters: 2
          --ipport:
            master-0-0: '6230'
            master-0-1: '6231'
            master-0-2: '6232'
            worker-0-0: '6233'
            worker-0-1: '6234'
            worker-0-2: '6235'
        sharedparameters: 3
          '--action': reboot
          '--ip': 192.168.123.1
          '--lanplus': ''
          '--password': password
          '--username': admin
1
実行されるフェンスエージェントの名前が表示されます (例: fly_ipmilan)。
2
フェンスエージェントを実行するための特定のクラスターノード情報 (例: ipport) を表示します。
3
username など、フェンスエージェントを実行するための一般的なクラスターノード情報を表示します。

3.5. Fence Agent Remediation Operator のトラブルシューティング

3.5.1. 一般的なトラブルシューティング

問題
Fence Agents Remediation Operator の問題のトラブルシューティングが必要です。
解決方法

Operator ログを確認してください。

$ oc logs <fence-agents-remediation-controller-manager-name> -c manager -n <namespace-name>

3.5.2. 失敗した修復

問題
不健康なノードは修正されませんでした。
解決方法

以下のコマンドを実行して、FenceAgentsRemediation CR が作成されていることを確認します。

$ oc get far -A

NodeHealthCheck コントローラーがノードが正常でない状態で FenceAgentsRemediation CR を作成しなかった場合、NodeHealthCheck コントローラーのログを確認します。さらに、NodeHealthCheck CR に、修復テンプレートを使用するために必要な仕様が含まれていることを確認してください。

FenceAgentsRemediation CR が作成された場合は、その名前が異常なノードオブジェクトと一致することを確認してください。

3.5.3. Operator のアンインストール後にフェンスエージェント修復 Operator リソースが存在する

問題
修復 CR や修復テンプレート CR などの Fence Agent 修復オペレータリソースは、Operator をアンインストールした後も存在します。
解決方法

Fence Agents Remediation Operator リソースを削除するには、アンインストールする前にこの Operator のすべてのオペランドインスタンスを削除するチェックボックスを選択してリソースを削除できます。このチェックボックス機能は、バージョン 4.13 以降、Red Hat OpenShift でのみ利用できます。Red Hat OpenShift のすべてのバージョンで、リソースタイプごとに次の関連コマンドを実行してリソースを削除できます。

$ oc delete far <fence-agents-remediation> -n <namespace>
$ oc delete fartemplate <fence-agents-remediation-template> -n <namespace>

修復 CR far は、同じエンティティー (NHC など) によって作成および削除される必要があります。修復 CR far がまだ存在する場合は、FAR Operator とともに削除されます。

修復テンプレート CR fartemplate は、NHC で FAR を使用する場合にのみ存在します。Web コンソールを使用して FAR Operator を削除すると、修復テンプレート CR fartemplate も削除されます。

3.6. Fence Agent Remediation Operator に関するデータの収集

Fence Agents Remediation Operator に関するデバッグ情報を収集するには、must-gather ツールを使用します。Fence Agents Remediation Operator の must-gather イメージについては、特定の機能に関するデータの収集 を参照してください。

3.7. 関連情報

第4章 マシン削除修復の使用

Machine Deletion Remediation Operator を使用すると、Machine API で異常なノードをプロビジョニングし直すことができます。Machine Deletion Remediation Operator は Node Health Check Operator と組み合わせて使用できます。

4.1. Machine Deletion Remediation Operator について

Machine Deletion Remediation (MDR) Operator は NodeHealthCheck コントローラーと連携して、Machine API を使用して異常なノードを再プロビジョニングします。MDR は、ノード上のアノテーションをたどり、関連付けられたマシンオブジェクトにアクセスし、所有するコントローラー (例: MachineSetController) があることを確認して、削除します。マシン CR が削除されると、所有するコントローラーが代わりのコントローラーを作成します。

MDR の前提条件は次のとおりです。

  • プログラムでクラスターノードを破棄および作成できるマシン API ベースのクラスター、
  • マシンに関連付けられたノード、および
  • 宣言的に管理されたマシン。

その後、NodeHealthCheck CR を修正して、MDR を修復手段として使用できます。MDR テンプレートオブジェクトと NodeHealthCheck 設定の例がドキュメントに記載されています。

MDR プロセスは以下のように動作します。

  • Node Health Check Operator は異常なノードを検出し、MDR CR を作成します。
  • MDR Operator は、異常なノードに関連付けられた MDR CR を監視し、マシンに所有コントローラーがある場合は削除します。
  • ノードが再び正常になると、MDR CR は NodeHealthCheck コントローラーによって削除されます。

4.2. Web コンソールを使用した Machine Deletion Remediation Operator のインストール

Red Hat OpenShift Web コンソールを使用して、Machine Deletion Remediation Operator をインストールできます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. Red Hat OpenShift Web コンソールで、OperatorsOperatorHub に移動します。
  2. 使用可能な Operator のリストから Machine Deletion Remediation Operator (MDR) を選択し、Install をクリックします。
  3. Operator が openshift-operators namespace にインストールされるように、Installation modenamespace のデフォルトの選択を維持します。
  4. Install をクリックします。

検証

インストールが正常に行われたことを確認するには、以下を実行します。

  1. OperatorsInstalled Operators ページに移動します。
  2. Operator が openshift-operators の namespace に設置されていることと、その状態が Succeeded になっていることを確認してください。

Operator が正常にインストールされていない場合、以下を実行します。

  1. OperatorsInstalled Operators ページに移動し、Status 列でエラーまたは失敗の有無を確認します。
  2. WorkloadsPods ページに移動し、報告された問題について machine-deletion-remediation-controller Pod のログを確認します。

4.3. CLI を使用した Machine Deletion Remediation Operator のインストール

OpenShift CLI (oc)を使用して、Machine Deletion Remediation Operator をインストールできます。

Machine Deletion Remediation Operator は、独自の namespace または openshift-operators namespace にインストールできます。

独自の namespace に Operator をインストールするには、手順に従います。

openshift-operators namespace に Operator をインストールするには、手順の 3 にスキップします。これは、新しい Namespace カスタムリソース (CR) と OperatorGroup CR を作成する必要がないためです。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. Machine Deletion Remediation Operator の namespace カスタムリソース (CR) を作成します。

    1. namespace CR を定義し、YAML ファイル (machine-deletion-remediation-namespace.yaml など) を保存します。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: machine-deletion-remediation
    2. NamespaceCR を作成するには、次のコマンドを実行します。

      $ oc create -f machine-deletion-remediation-namespace.yaml
  2. OperatorGroup を作成します。

    1. OperatorGroup CR を定義し、YAML ファイル (machine-deletion-remediation-operator-group.yaml など) を保存します。

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: machine-deletion-remediation-operator
        namespace: machine-deletion-remediation
    2. OperatorGroup CR を作成するには、次のコマンドを実行します。

      $ oc create -f machine-deletion-remediation-operator-group.yaml
  3. SubscriptionCR を作成します。

    1. subscription CR を定義し、YAML ファイル (machine-deletion-remediation-subscription.yaml など) を保存します。

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
          name: machine-deletion-remediation-operator
          namespace: machine-deletion-remediation 1
      spec:
          channel: stable
          name: machine-deletion-remediation-operator
          source: redhat-operators
          sourceNamespace: openshift-marketplace
          package: machine-deletion-remediation
      1
      Machine Deletion Remediation Operator をインストールする Namespace を指定します。Machine Deletion Remediation Operator を openshift-operators subscriptuion CR にインストールすると、Namespace CROperatorGroup CR がすでに存在します。
    2. SubscriptionCR を作成するには、次のコマンドを実行します。

      $ oc create -f machine-deletion-remediation-subscription.yaml

検証

  1. CSV リソースを調べて、インストールが成功したことを確認します。

    $ oc get csv -n machine-deletion-remediation

    出力例

    NAME                               DISPLAY                          VERSION   REPLACES   PHASE
    machine-deletion-remediation.v.0.2.0      Machine Deletion Remediation Operator   v.0.2.0              Succeeded

4.4. Machine Deletion Remediation Operator の設定

Machine Deletion Remediation Operator を Node Health Check Operator とともに使用して、MachineDeletionRemediationTemplate カスタムリソース (CR) を作成できます。この CR は、ノードの修復ストラテジーを定義します。

MachineDeletionRemediationTemplate CR は以下の YAML ファイルのようになります。

apiVersion: machine-deletion-remediation.medik8s.io/v1alpha1
kind: MachineDeletionRemediationTemplate
metadata:
  name: machinedeletionremediationtemplate-sample
  namespace: openshift-operators
spec:
  template:
    spec: {}

4.5. Machine Deletion Remediation Operator のトラブルシューティング

4.5.1. 一般的なトラブルシューティング

問題
Machine Deletion Remediation Operator の問題のトラブルシューティングが必要です。
解決方法

Operator ログを確認してください。

$ oc logs <machine-deletion-remediation-controller-manager-name> -c manager -n <namespace-name>

4.5.2. 失敗した修復

問題
不健康なノードは修正されませんでした。
解決方法

以下のコマンドを実行して、MachineDeletionRemediation CR が作成されていることを確認します。

$ oc get mdr -A

ノードが正常でなくなり、NodeHealthCheck コントローラーが MachineDeletionRemediation CR を作成しなかった場合は、NodeHealthCheck コントローラーのログを確認してください。さらに、NodeHealthCheck CR に、修復テンプレートを使用するために必要な仕様が含まれていることを確認してください。

MachineDeletionRemediation CR が作成された場合は、その名前が異常なノードオブジェクトと一致することを確認してください。

4.5.3. Machine Deletion Remediation Operator リソースは、Operator のアンインストール後も存在する

問題
修復 CR や修復テンプレート CR などの Machine Deletion Remediation Operator リソースは、Operator をアンインストールした後も存在します。
解決方法

Machine Deletion Remediation Operator リソースを削除するには、アンインストールする前に Delete all operand instances for this operator のチェックボックスを選択してリソースを削除できます。このチェックボックス機能は、バージョン 4.13 以降、Red Hat OpenShift でのみ利用できます。Red Hat OpenShift のすべてのバージョンで、リソースタイプごとに次の関連コマンドを実行してリソースを削除できます。

$ oc delete mdr <machine-deletion-remediation> -n <namespace>
$ oc delete mdrt <machine-deletion-remediation-template> -n <namespace>

修復 CR mdr は、同じエンティティー (NHC など) によって作成および削除される必要があります。修復 CR mdr がまだ存在する場合は、MDR Operator とともに削除されます。

修復テンプレート CR mdrt は、NHC で MDR を使用する場合にのみ存在します。Web コンソールを使用して MDR Operator を削除すると、修復テンプレート CR mdrt も削除されます。

4.6. Machine Deletion Remediation Operator に関するデータの収集

Machine Deletion Remediation Operator に関するデバッグ情報を収集するには、must-gather ツールを使用します。Machine Deletion Remediation Operator の must-gather イメージについては、特定の機能に関するデータの収集 を参照してください。

4.7. 関連情報

第5章 マシンヘルスチェックを使用したノードの修復

マシンのヘルスチェックは特定のマシンプールの正常ではないマシンを自動的に修復します。

5.1. マシンのヘルスチェック

注記

マシンのヘルスチェックは、コントロールプレーンマシンセットを使用するクラスター上のコントロールプレーンマシンにのみ適用できます。

マシンの正常性を監視するには、リソースを作成し、コントローラーの設定を定義します。5 分間 NotReady ステータスにすることや、 node-problem-detector に永続的な条件を表示すること、および監視する一連のマシンのラベルなど、チェックする条件を設定します。

MachineHealthCheck リソースを監視するコントローラーは定義済みのステータスをチェックします。マシンがヘルスチェックに失敗した場合、このマシンは自動的に検出され、その代わりとなるマシンが作成されます。マシンが削除されると、machine deleted イベントが表示されます。

マシンの削除による破壊的な影響を制限するために、コントローラーは 1 度に 1 つのノードのみをドレイン (解放) し、これを削除します。マシンのターゲットプールで許可される maxUnhealthy しきい値を上回る数の正常でないマシンがある場合、修復が停止するため、手動による介入が可能になります。

注記

タイムアウトについて注意深い検討が必要であり、ワークロードと要件を考慮してください。

  • タイムアウトの時間が長くなると、正常でないマシンのワークロードのダウンタイムが長くなる可能性があります。
  • タイムアウトが短すぎると、修復ループが生じる可能性があります。たとえば、NotReady ステータスを確認するためのタイムアウトについては、マシンが起動プロセスを完了できるように十分な時間を設定する必要があります。

チェックを停止するには、リソースを削除します。

5.1.1. マシンヘルスチェックのデプロイ時の制限

マシンヘルスチェックをデプロイする前に考慮すべき制限事項があります。

  • マシンセットが所有するマシンのみがマシンヘルスチェックによって修復されます。
  • マシンのノードがクラスターから削除される場合、マシンヘルスチェックはマシンが正常ではないとみなし、すぐにこれを修復します。
  • nodeStartupTimeout の後にマシンの対応するノードがクラスターに加わらない場合、マシンは修復されます。
  • Machine リソースフェーズが Failed の場合、マシンはすぐに修復されます。

5.2. Self Node Remediation Operator を使用するためのマシンヘルスチェックの設定

次の手順を使用して、Self Node Remediation Operator を修復プロバイダーとして使用するようにワーカーまたはコントロールプレーンマシンのヘルスチェックを設定します。

注記

Self Node Remediation Operator をマシンの健全性チェックの修復プロバイダーとして使用するには、マシンに、クラスター内に関連付けられたノードが配置されている必要があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. SelfNodeRemediationTemplate CR を作成します。

    1. SelfNodeRemediationTemplate CR を定義します。

      apiVersion: self-node-remediation.medik8s.io/v1alpha1
      kind: SelfNodeRemediationTemplate
      metadata:
        namespace: openshift-machine-api
        name: selfnoderemediationtemplate-sample
      spec:
        template:
          spec:
            remediationStrategy: ResourceDeletion 1
      1
      修復ストラテジーを指定します。デフォルトのストラテジーは ResourceDeletion です。
    2. SelfNodeRemediationTemplate CR を作成するには、以下のコマンドを実行します。

      $ oc create -f <snrt-name>.yaml
  2. MachineHealthCheck CR を作成し、SelfNodeRemediationTemplate CR を参照するよう更新します。

    1. MachineHealthCheck を定義または更新します。

      apiVersion: machine.openshift.io/v1beta1
      kind: MachineHealthCheck
      metadata:
        name: machine-health-check
        namespace: openshift-machine-api
      spec:
        selector:
          matchLabels: 1
            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: 2
          kind: SelfNodeRemediationTemplate
          apiVersion: self-node-remediation.medik8s.io/v1alpha1
          name: selfnoderemediationtemplate-sample
      1
      マシンのヘルスチェックの対象が worker ノードか control-plane ノードかを選択します。ラベルはユーザー定義にすることもできます。
      2
      修復テンプレートの詳細を指定します。
    2. MachineHealthCheck CR を作成するには、次のコマンドを実行します。

      $ oc create -f <mhc-name>.yaml
    3. MachineHealthCheck CR を更新するには、次のコマンドを実行します。

      $ oc apply -f <mhc-name>.yaml

第6章 ノードヘルスチェックを使用したノードの修復

Node Health Check Operator を使用して、不健全なノードを特定できます。Operator は、Self Node Remediation Operator を使用して、不健全なノードを修復します。

Self Node Remediation Operator の詳細は、自己ノード修復の使用 の章を参照してください。

注記

Red Hat OpenShift Service on AWS (ROSA)クラスターにプリインストールされたマシンヘルスチェックが存在するため、Node Health Check Operator はこのような環境では機能しません。

6.1. Node Health Check Operator について

Node Health Check Operator は、クラスター内のノードの健全性を検出します。NodeHealthCheck コントローラーは、NodeHealthCheck カスタムリソース (CR) を作成します。これは、ノードの状態を判断するための一連の基準としきい値を定義します。

Node Health Check Operator は、Self Node Remediation Operator をデフォルトの修復プロバイダーとしてインストールします。

Node Health Check Operator は異常なノードを検出すると、修復プロバイダーをトリガーする修復 CR を作成します。たとえば、コントローラーは SelfNodeRemediation CR を作成し、Self Node Remediation Operator をトリガーして正常でないノードを修復します。

NodeHealthCheck CR は、修復プロバイダーとして自己ノード修復を使用した次の YAML ファイルに似ています。

apiVersion: remediation.medik8s.io/v1alpha1
kind: NodeHealthCheck
metadata:
  name: nodehealthcheck-sample
spec:
  minHealthy: 51% 1
  pauseRequests: 2
    - <pause-test-cluster>
  remediationTemplate: 3
    apiVersion: self-node-remediation.medik8s.io/v1alpha1
    name: self-node-remediation-resource-deletion-template
    namespace: <openshift-operators>
    kind: SelfNodeRemediationTemplate
  escalatingRemediations: 4
    - remediationTemplate:
        apiVersion: self-node-remediation.medik8s.io/v1alpha1
        name: self-node-remediation-resource-deletion-template
        namespace: openshift-operators
        kind: SelfNodeRemediationTemplate
    order: 1
    timeout: 300s
  selector: 5
    matchExpressions:
      - key: node-role.kubernetes.io/worker
        operator: Exists
  unhealthyConditions: 6
    - type: Ready
      status: "False"
      duration: 300s 7
    - type: Ready
      status: Unknown
      duration: 300s 8
1
修復プロバイダーがターゲットプール内のノードを同時に修復するために必要な正常なノードの数 (パーセンテージまたは数) を指定します。正常なノードの数が minHealthy で設定された制限以上の場合、修復が行われます。デフォルト値は 51% です。
2
新しい修復が開始されないようにし、進行中の修復を継続できるようにします。デフォルト値は空です。ただし、修復を一時停止する原因を特定する文字列の配列を入力できます。たとえば、 pause-test-cluster
注記

アップグレードプロセス中に、クラスター内のノードが一時的に使用できなくなり、異常として識別される場合があります。ワーカーノードの場合、オペレーターはクラスターがアップグレード中であることを検出すると、新しい異常なノードの修正を停止して、そのようなノードが再起動しないようにします。

3
修復プロバイダーからの修復テンプレートを指定します。たとえば、Self Node Remediation Operator のようになります。remediationTemplateescalatingRemediation と相互排他的です。
4
順序フィールドとタイムアウトフィールドを含む RemediationTemplate のリストを指定します。正常なノードを取得するには、このフィールドを使用して複数の修復を順序付けし、設定します。この戦略により、成功しない可能性のある単一の修復に依存するのではなく、正常なノードを取得できる可能性が高まります。order フィールドは、修復が呼び出される順序を決定します (低い順序 = 早い呼び出し)。timeout フィールドは、次の修復がいつ呼び出されるかを決定します。escalatingRemediationremediationTemplate と相互排他的です。
5
チェックするラベルまたは式に一致する selector を指定します。1 つの CR でコントロールプレーンノードとワーカーノードの両方を選択しないでください。
6
ノードが異常と見なされるかどうかを決定する条件のリストを指定します。
7 8
ノード条件のタイムアウト期間を指定します。タイムアウトの期間中に条件が満たされた場合、ノードは修正されます。タイムアウトが長いと、異常なノードのワークロードで長期間のダウンタイムが発生する可能性があります。

NodeHealthCheck CR は、修復プロバイダーとして metal3 を使用した、次の YAML ファイルに似ています。

apiVersion: remediation.medik8s.io/v1alpha1
kind: NodeHealthCheck
metadata:
  name: nhc-worker-metal3
spec:
  minHealthy: 30%
  remediationTemplate:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: Metal3RemediationTemplate
    name: metal3-remediation
    namespace: openshift-machine-api
  selector:
    matchExpressions:
    - key: node-role.kubernetes.io/worker
      operator: Exists
  unhealthyConditions:
  - duration: 300s
    status: 'False'
    type: Ready
  - duration: 300s
    status: 'Unknown'
    type: Ready
注記

matchExpressions は例です。特定のニーズに基づいてマシングループをマッピングする必要があります。

Metal3RemediationTemplate は、修復プロバイダーとして metal3 を使用した、次の YAML ファイルに似ています。

apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3RemediationTemplate
metadata:
  name: metal3-remediation
  namespace: openshift-machine-api
spec:
  template:
    spec:
      strategy:
        retryLimit: 1
        timeout: 5m0s
        type: Reboot
注記

NodeHealthCheck CR の作成に加えて、Metal3RemediationTemplate も作成する必要があります。

6.1.1. Node Health Check Operator のワークフローを理解する

ノードが異常であると識別されると、Node Health Check Operator は他にいくつのノードが異常であるかをチェックします。健康なノードの数が NodeHealthCheck CR の minHealthy フィールドで指定された量を超えた場合、コントローラーは、修復プロバイダーによって外部の修復テンプレートで提供される詳細から修復 CR を作成します。修復後、kubelet はノードのヘルスステータスを更新します。

ノードが正常になると、コントローラーは外部修復テンプレートを削除します。

6.1.2. ノードのヘルスチェックによるマシンヘルスチェックの競合

ノードヘルスチェックとマシンヘルスチェックの両方がデプロイメントされている場合、ノードヘルスチェックはマシンヘルスチェックとの競合を回避します。

注記

Red Hat OpenShift は machine-api-termination-handler をデフォルトの MachineHealthCheck リソースとしてデプロイします。

次のリストは、ノードヘルスチェックとマシンヘルスチェックがデプロイメントされたときのシステムの動作をまとめたものです。

  • デフォルトのマシンヘルスチェックのみが存在する場合、ノードヘルスチェックは引き続き異常なノードを識別します。ただし、ノードヘルスチェックは、Terminating 状態の異常なノードを無視します。デフォルトのマシンヘルスチェックは、異常なノードを Terminating 状態で処理します。

    ログメッセージの例

    INFO MHCChecker	ignoring unhealthy Node, it is terminating and will be handled by MHC	{"NodeName": "node-1.example.com"}

  • デフォルトのマシンヘルスチェックが変更された場合 (たとえば、unhealthyConditionsReady の場合)、または追加のマシンヘルスチェックが作成された場合、ノードヘルスチェックは無効になります。

    ログメッセージの例

    INFO controllers.NodeHealthCheck disabling NHC in order to avoid conflict with custom MHCs configured in the cluster {"NodeHealthCheck": "/nhc-worker-default"}

  • ここでも、デフォルトのマシンヘルスチェックのみが存在する場合、ノードヘルスチェックが再度有効になります。

    ログメッセージの例

    INFO controllers.NodeHealthCheck re-enabling NHC, no conflicting MHC configured in the cluster {"NodeHealthCheck": "/nhc-worker-default"}

6.2. コントロールプレーンフェンシング

以前のリリースでは、ワーカーノードでセルフノード修復とノードヘルスチェックを有効にすることができました。ノード障害が発生した場合、コントロールプレーンノードの修復戦略に従うこともできるようになりました。

ワーカーノードとコントロールプレーンノードに同じ NodeHealthCheck CR を使用しないでください。ワーカーノードとコントロールプレーンノードを一緒にグループ化すると、正常なノードの最小数が正しく評価されず、予期しない修復または欠落した修復が発生する可能性があります。これは、Node Health Check Operator がコントロールプレーンノードを処理する方法が原因です。コントロールプレーンノードを独自のグループにグループ化し、ワーカーノードを独自のグループにグループ化する必要があります。必要に応じて、複数のワーカーノードグループを作成することもできます。

修復戦略に関する考慮事項:

  • 予期しない動作が発生する可能性があるため、同じノードに重複する複数の設定を含むノードヘルスチェック設定は避けてください。この提案は、ワーカープレーンノードとコントロールプレーンノードの両方に適用されます。
  • Node Health Check Operator は、一度に最大 1 つのコントロールプレーンノードを修正するというハードコーディングされた制限を実装します。複数のコントロールプレーンノードを同時に修復しないでください。

6.3. Web コンソールを使用したノードヘルスチェックオペレーターのインストール

Red Hat OpenShift Web コンソールを使用して、Node Health Check Operator をインストールできます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. Red Hat OpenShift Web コンソールで、OperatorsOperatorHub に移動します。
  2. Node Health Check Operator を選択し、Install をクリックします。
  3. Operator が openshift-operators namespace にインストールされるように、Installation modenamespace のデフォルトの選択を維持します。
  4. Console plug-inEnable に設定されていることを確認します。
  5. Install をクリックします。

検証

インストールが正常に行われたことを確認するには、以下を実行します。

  1. OperatorsInstalled Operators ページに移動します。
  2. Operator が openshift-operators の namespace 内に設置されていることと、その状態が Succeeded となっていることを確認してください。

Operator が正常にインストールされていない場合、以下を実行します。

  1. OperatorsInstalled Operators ページに移動し、Status 列でエラーまたは失敗の有無を確認します。
  2. WorkloadsPodsページにナビゲートし、問題を報告している openshift-operators プロジェクトの Pod のログを確認します。

6.4. CLI を使用した Node Health Check Operator のインストール

OpenShift CLI( oc ) を使用して、Node Health Check Operator をインストールできます。

独自の namespace に Operator をインストールするには、手順に従います。

openshift-operators namespace に Operator をインストールするには、手順の 3 にスキップします。これは、新しい Namespace カスタムリソース (CR) と OperatorGroup CR を作成する必要がないためです。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. Node Health Check Operator の Namespace カスタムリソース (CR) を作成します。

    1. NamespaceCR を定義し、YAML ファイルを保存します (例: node-health-check-namespace.yaml)。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: node-health-check
    2. NamespaceCR を作成するには、次のコマンドを実行します。

      $ oc create -f node-health-check-namespace.yaml
  2. OperatorGroup を作成します。

    1. OperatorGroup CR を定義し、YAML ファイルを保存します (例: node-health-check-operator-group.yaml)。

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: node-health-check-operator
        namespace: node-health-check
    2. OperatorGroup CR を作成するには、次のコマンドを実行します。

      $ oc create -f node-health-check-operator-group.yaml
  3. SubscriptionCR を作成します。

    1. SubscriptionCR を定義し、YAML ファイルを保存します (例: node-health-check-subscription.yaml)。

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
          name: node-health-check-operator
          namespace: node-health-check 1
      spec:
          channel: stable 2
          installPlanApproval: Manual 3
          name: node-healthcheck-operator
          source: redhat-operators
          sourceNamespace: openshift-marketplace
          package: node-healthcheck-operator
      1
      Node Health Check Operator をインストールする Namespace を指定します。Node Health Check Operator を openshift-operators namespace にインストールするには、Subscription CR で openshift-operators を指定します。
      2
      サブスクリプションのチャネル名を指定します。Node Health Check Operator の最新バージョンにアップグレードするには、サブスクリプションのチャネル名を candidate から stable に手動で変更する必要があります。
      3
      指定したバージョンがカタログの新しいバージョンに置き換えられる場合に備えて、承認ストラテジーを Manual に設定します。これにより、新しいバージョンへの自動アップグレードが阻止され、最初の CSV のインストールが完了する前に手動での承認が必要となります。
    2. SubscriptionCR を作成するには、次のコマンドを実行します。

      $ oc create -f node-health-check-subscription.yaml

検証

  1. CSV リソースを調べて、インストールが成功したことを確認します。

    $ oc get csv -n openshift-operators

    出力例

    NAME                              DISPLAY                     VERSION  REPLACES PHASE
    node-healthcheck-operator.v0.6.0. Node Health Check Operator  0.6.0             Succeeded

  2. Node Health CheckOperator が稼働していることを確認します。

    $ oc get deploy -n openshift-operators

    出力例

    NAME                                           READY   UP-TO-DATE   AVAILABLE   AGE
    node-health-check-operator-controller-manager  1/1     1            1           10d

6.5. ノードヘルスチェックの作成

Web コンソールを使用して、ノードヘルスチェックを作成して異常なノードを特定し、修正する修復タイプとストラテジーを指定できます。

手順

  1. Red Hat OpenShift Web コンソールの Administrator の観点から、ComputeNodeHealthChecksCreateNodeHealthCheck をクリックします。
  2. Form ビュー または YAML ビュー を使用してノードのヘルスチェックを設定するかどうかを指定します。
  3. ノードヘルスチェックの 名前 を入力します。名前は小文字、英数字、'-'、または..で設定され、英数字で開始および終了する必要があります。
  4. Remediator タイプ、および Self node remediation または Other を指定します。Self node remediation オプションは、Node Health Check Operator でインストールされる Self Node Remediation Operator の一部です。Other を選択するには、API バージョンKindName、および Namespace を入力する必要があります。これは、修正の修復テンプレートリソースを指します。
  5. 修復する ノード のラベルを指定して、ノードを選択します。選択した内容は、確認するラベルと一致します。複数のラベルを指定する場合、ノードには各ラベルが含まれている必要があります。デフォルト値は空で、ワーカーノードとコントロールプレーンノードの両方を選択します。

    注記

    Self Node Remediation Operator を使用してノードヘルスチェックを作成する場合、node-role.kubernetes.io/worker または node-role.kubernetes.io/control-plane のいずれかを値として選択する必要があります。

  6. NodeHealthCheck がターゲットプール内のノードを修復するために必要な、正常なノードの最小数をパーセンテージまたは数値で指定します。正常なノードの数が Min healthy によって設定された制限以上の場合には、修復が行われます。デフォルト値は 51% です。
  7. ノードが一致した場合に、ノードが異常であると見なされ、修復が必要かどうかを決定する、異常な条件 のリストを指定します。TypeStatus、および Duration を指定できます。独自のカスタムタイプを作成することもできます。
  8. Create をクリックしてノードヘルスチェックを作成します。

検証

  • ComputeNodeHealthCheck ページに移動し、対応するノードヘルスチェックが一覧表示され、それらのステータスが表示されることを確認します。作成が完了すると、ノードヘルスチェックを一時停止、変更、および削除できます。

6.6. Node Health Check Operator に関するデータの収集

Node Health Check Operator に関するデバッグ情報を収集するには、must-gather ツールを使用します。Node Health Check Operator の must-gather イメージについては、特定の機能に関するデータの収集 を参照してください。

6.7. 関連情報

第7章 Node Maintenance Operator を使用してノードをメンテナンスモードにする

oc adm ユーティリティーまたは NodeMaintenance カスタムリソース (CR) を使用して、Node Maintenance Operator を使用してノードをメンテナンスモードにすることができます。

7.1. Node Maintenance Operator について

Node Maintenance Operator は、新規または削除された NodeMaintenance CR をモニタリングします。新規の NodeMaintenance CR が検出されると、新規ワークロードはスケジュールされず、ノードは残りのクラスターから遮断されます。エビクトできるすべての Pod はノードからエビクトされます。NodeMaintenance CR が削除されると、CR で参照されるノードは新規ワークロードで利用可能になります。

注記

ノードのメンテナンスタスクに NodeMaintenance CR を使用すると、標準の Red Hat OpenShift CR 処理を使用して oc adm cordon および oc adm drain コマンドの場合と同じ結果が得られます。

7.2. Node Maintenance Operator のインストール

Node Maintenance Operator は、Web コンソールまたは Open Shift CLI (oc) を使用してインストールできます。

注記

OpenShift Virtualization バージョン 4.10 以下がクラスターにインストールされている場合は、古いバージョンの Node Maintenance Operator が含まれています。

7.2.1. Web コンソールを使用した Node Maintenance Operator のインストール

Red Hat OpenShift Web コンソールを使用して、Node Maintenance Operator をインストールできます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. Red Hat OpenShift Web コンソールで、OperatorsOperatorHub に移動します。
  2. Node Maintenance Operator を選択し、Install をクリックします。
  3. Operator が openshift-operators namespace にインストールされるように、Installation modenamespace のデフォルトの選択を維持します。
  4. Install をクリックします。

検証

インストールが正常に行われたことを確認するには、以下を実行します。

  1. OperatorsInstalled Operators ページに移動します。
  2. Operator が openshift-operators の namespace 内に設置されていることと、その状態が Succeeded となっていることを確認してください。

Operator が正常にインストールされていない場合、以下を実行します。

  1. OperatorsInstalled Operators ページに移動し、Status 列でエラーまたは失敗の有無を確認します。
  2. OperatorsInstalled OperatorsNode Maintenance OperatorDetails ページに移動し、Pod を作成する前に Conditions セクションでエラーを調べます。
  3. WorkloadsPods ページに移動し、インストールされた namespace で Node Maintenance Operator Pod を検索し、Logs タブでログを確認します。

7.2.2. CLI を使用した Node Maintenance Operator のインストール

OpenShift CLI (oc) を使用して、Node Maintenance Operator をインストールできます。

Node Maintenance Operator は、独自の namespace または openshift-operators namespace にインストールできます。

独自の namespace に Operator をインストールするには、手順に従います。

openshift-operators namespace に Operator をインストールするには、手順の 3 にスキップします。これは、新しい Namespace カスタムリソース (CR) と OperatorGroup CR を作成する必要がないためです。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  1. Node Maintenance Operator のNamespace CR を作成します。

    1. Namespace CR を定義し、YAML ファイルを保存します (例: node-maintenance-namespace.yaml)。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: nmo-test
    2. NamespaceCR を作成するには、次のコマンドを実行します。

      $ oc create -f node-maintenance-namespace.yaml
  2. OperatorGroup を作成します。

    1. OperatorGroup CR を定義し、YAML ファイルを保存します (例: node-maintenance-operator-group.yaml)。

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: node-maintenance-operator
        namespace: nmo-test
    2. OperatorGroup CR を作成するには、次のコマンドを実行します。

      $ oc create -f node-maintenance-operator-group.yaml
  3. SubscriptionCR を作成します。

    1. Subscription CR を定義し、YAML ファイルを保存します (例: node-maintenance-subscription.yaml)。

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: node-maintenance-operator
        namespace: nmo-test 1
      spec:
        channel: stable
        installPlanApproval: Automatic
        name: node-maintenance-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
        package: node-maintenance-operator
      1
      Node Maintenance Operator をインストールする Namespace を指定します。
      重要

      Node Maintenance Operator を openshift-operators namespace にインストールするには、Subscription CR で openshift-operators を指定します。

    2. SubscriptionCR を作成するには、次のコマンドを実行します。

      $ oc create -f node-maintenance-subscription.yaml

検証

  1. CSV リソースを調べて、インストールが成功したことを確認します。

    $ oc get csv -n openshift-operators

    出力例

    NAME                               DISPLAY                     VERSION   REPLACES  PHASE
    node-maintenance-operator.v5.0.0   Node Maintenance Operator   5.0.0               Succeeded

  2. Node Maintenance Operator が実行されていることを確認します。

    $ oc get deploy -n openshift-operators

    出力例

    NAME                                           READY   UP-TO-DATE   AVAILABLE   AGE
    node-maintenance-operator-controller-manager   1/1     1            1           10d

Node Maintenance Operator は、制限されたネットワーク環境でサポートされています。詳細は、ネットワークが制限された環境での Operator Lifecycle Manager の使用 を参照してください。

7.3. ノードのメンテナンスモードへの設定

NodeMaintenance CR を使用して、Web コンソールまたは CLI からノードをメンテナンスモードにすることができます。

7.3.1. Web コンソールでのノードのメンテナンスモードへの設定

ノードをメンテナンスモードに設定するために、Web コンソールを使用して NodeMaintenance カスタムリソース (CR) を作成できます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • OperatorHub から Node Maintenance Operator をインストールします。

手順

  1. Web コンソールの Administrator パースペクティブで、OperatorsInstalled Operators に移動します。
  2. Operator リストから Node Maintenance Operator を選択します。
  3. Node Maintenance タブで Create NodeMaintenance をクリックします。
  4. Create NodeMaintenance ページで、Form view または YAML view t を選択して NodeMaintenance CR を設定します。
  5. 設定した NodeMaintenance CR を適用するには、Create をクリックします。

検証

Node Maintenance タブで Status 列を調べ、そのステータスが Succeeded であることを確認します。

7.3.2. CLI を使用してノードをメンテナンスモードに設定する場合

NodeMaintenance カスタムリソース (CR) を使用して、ノードをメンテナンスモードにすることができます。NodeMaintenance CR を適用すると、許可されているすべての Pod が削除され、ノードがスケジュール不能になります。エビクトされた Pod は、クラスター内の別のノードに移動するようにキューに置かれます。

前提条件

  • Red Hat OpenShift CLI (oc) をインストールしている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしている。

手順

  1. 次の NodeMaintenance CR を作成し、ファイルを nodemaintenance-cr.yaml として保存します。

    apiVersion: nodemaintenance.medik8s.io/v1beta1
    kind: NodeMaintenance
    metadata:
      name: nodemaintenance-cr  1
    spec:
      nodeName: node-1.example.com 2
      reason: "NIC replacement" 3
    1
    ノードメンテナンス CR の名前。
    2
    メンテナンスモードにするノードの名前。
    3
    メンテナンスの理由を説明するプレーンテキスト。
  2. 次のコマンドを実行して、ノードメンテナンス CR を適用します。

    $ oc apply -f nodemaintenance-cr.yaml

検証

  1. 次のコマンドを実行して、メンテナンスタスクの進捗状況を確認します。

    $ oc describe node <node-name>

    <node-name> はノードの名前です。たとえば、node-1.example.com などになります。

  2. 出力例を確認します。

    Events:
      Type     Reason                     Age                   From     Message
      ----     ------                     ----                  ----     -------
      Normal   NodeNotSchedulable         61m                   kubelet  Node node-1.example.com status is now: NodeNotSchedulable

7.3.3. 現在の NodeMaintenance CR タスクのステータスの確認

現在の NodeMaintenance CR タスクのステータスを確認できます。

前提条件

  • Red Hat OpenShift CLI (oc) をインストールしている。
  • cluster-admin 権限を持つユーザーとしてログインしている。

手順

  • 以下のコマンドを実行して、現在のノードのメンテナンスタスクのステータスを確認します (例: NodeMaintenance CR または nm)。

    $ oc get nm -o yaml

    出力例

    apiVersion: v1
    items:
    - apiVersion: nodemaintenance.medik8s.io/v1beta1
      kind: NodeMaintenance
      metadata:
    ...
      spec:
        nodeName: node-1.example.com
        reason: Node maintenance
      status:
        drainProgress: 100   1
        evictionPods: 3   2
        lastError: "Last failure message" 3
        lastUpdate: "2022-06-23T11:43:18Z" 4
        phase: Succeeded
        totalpods: 5 5
    ...

    1
    ノードのドレインの完了率。
    2
    エビクションにスケジュールされる Pod 数。
    3
    最新のエビクションエラー (ある場合)。
    4
    ステータスが最後に更新された時刻。
    5
    ノードがメンテナンスモードに入る前の Pod の総数。

7.4. メンテナンスモードからのノードの再開

NodeMaintenance CR を使用して、Web コンソールまたは CLI から、メンテナンスモードからノードを再開できます。ノードを再起動することにより、ノードをメンテナンスモードから切り替え、再度スケジュール可能な状態にできます。

7.4.1. Web コンソールを使用してノードをメンテナンスモードから再開する方法

ノードをメンテナンスモードから再開するために、Web コンソールを使用して NodeMaintenance カスタムリソース (CR) を削除できます。

前提条件

  • cluster-admin 権限を持つユーザーとしてログインしている。
  • OperatorHub から Node Maintenance Operator をインストールします。

手順

  1. Web コンソールの Administrator パースペクティブで、OperatorsInstalled Operators に移動します。
  2. Operator リストから Node Maintenance Operator を選択します。
  3. Node Maintenance タブで、削除する NodeMaintenance CR を選択します。
  4. ノードの末尾の Options メニュー kebab をクリックし、Delete NodeMaintenance を選択します。

検証

  1. Red Hat OpenShift コンソールで、Compute → Nodes をクリックします。
  2. NodeMaintenance CR を削除したノードの Status 列を調べて、その状況が Ready であることを確認します。

7.4.2. CLI を使用してノードをメンテナンスモードから再開する方法

NodeMaintenance CR を削除することにより、NodeMaintenance CR で開始されたメンテナンスモードからノードを再開できます。

前提条件

  • Red Hat OpenShift CLI (oc) をインストールしている。
  • cluster-admin 権限を持つユーザーとしてクラスターにログインしている。

手順

  • ノードのメンテナンスタスクが完了したら、アクティブな NodeMaintenance CR を削除します。

    $ oc delete -f nodemaintenance-cr.yaml

    出力例

    nodemaintenance.nodemaintenance.medik8s.io "maintenance-example" deleted

検証

  1. 次のコマンドを実行して、メンテナンスタスクの進捗状況を確認します。

    $ oc describe node <node-name>

    <node-name> はノードの名前です。たとえば、node-1.example.com などになります。

  2. 出力例を確認します。

    Events:
      Type     Reason                  Age                   From     Message
      ----     ------                  ----                  ----     -------
      Normal   NodeSchedulable         2m                    kubelet  Node node-1.example.com status is now: NodeSchedulable

7.5. ベアメタルノードの操作

ベアメタルノードを含むクラスターの場合、Web コンソールの アクション コントロールを使用して、ノードをメンテナンスモードにしたり、ノードをメンテナンスモードから再開したりできます。

注記

ベアメタルノードを含むクラスターは、概説したように、Web コンソールと CLI を使用して、ノードをメンテナンスモードにしたり、ノードをメンテナンスモードから再開したりすることもできます。これらのメソッドは、Web コンソールの アクション コントロールを使用して、ベアメタルクラスターにのみ適用できます。

7.5.1. ベアメタルノードのメンテナンス

Red Hat OpenShift をベアメタルインフラストラクチャーにデプロイする場合、クラウドインフラストラクチャーにデプロイする場合と比較すると、追加で考慮する必要のある点があります。クラスターノードが一時的とみなされるクラウド環境とは異なり、ベアメタルノードを再プロビジョニングするには、メンテナンスタスクにより多くの時間と作業が必要になります。

カーネルエラーや NIC カードのハードウェア障害が原因でベアメタルノードに障害が発生した場合には、障害のあるノードが修復または置き換えられている間に、障害が発生したノード上のワークロードをクラスターのノードで再起動する必要があります。ノードのメンテナンスモードにより、クラスター管理者はノードを正常にオフにし、ワークロードをクラスターの他の部分に移動させ、ワークロードが中断されないようにします。詳細な進捗とノードのステータスについての詳細は、メンテナンス時に提供されます。

7.5.2. ベアメタルノードをメンテナンスモードに設定する

ComputeNodes 一覧で各ノードにある Options メニュー kebab を使用するか、Node Details 画面の Actions コントロールを使用して、ベアメタルノードをメンテナンスモードに設定します。

手順

  1. Web コンソールの 管理者 パースペクティブから、ComputeNodes をクリックします。
  2. この画面からノードをメンテナンスモードに設定することができます。これにより、複数のノードでアクションを簡単に実行できるようになります。または、選択したノードの包括的な詳細を表示できる Node Details 画面からも実行できるようになります。

    • ノードの末尾の Options メニュー kebab をクリックし、Start Maintenance を選択します。
    • ノード名をクリックし、Node Details 画面を開いて ActionsStat Maintenance をクリックします。
  3. 確認ウィンドウで Start Maintenance をクリックします。

ノードはスケジュール可能ではなくなりました。LiveMigration エビクションストラテジーを使用する仮想マシンがあった場合は、それらをライブマイグレーションします。このノードの他のすべての Pod および仮想マシンは削除され、別のノードで再作成されます。

検証

  • ComputeNodes ページに移動し、対応するノードのステータスが Under maintenance であることを確認します。

7.5.3. メンテナンスモードからのベアメタルノードの再開

ComputeNodes リストの各ノードにあるオプションメニュー kebab を使用して、または Node Details 画面の Actions コントロールを使用して、メンテナンスモードからベアメタルノードを再開します。

手順

  1. Web コンソールの 管理者 パースペクティブから、ComputeNodes をクリックします。
  2. 複数のノードでアクションを簡単に実行できるこの画面からノードを再開できます。または、選択したノードの包括的な詳細を表示できる Node Details 画面からもノードを再開できます。

    • ノードの末尾の Options メニュー kebab をクリックし、Stop Maintenance を選択します。
    • ノード名をクリックし、Node Details 画面を開いて ActionsStop Maintenance をクリックします。
  3. 確認ウィンドウで Stop Maintenance をクリックします。

ノードがスケジュール可能になります。メンテナンス前にノードで実行されていた仮想マシンインスタンスがあった場合、それらは自動的にこのノードに移行されません。

検証

  • ComputeNodes ページに移動し、対応するノードのステータスが Ready であることを確認します。

7.6. Node Maintenance Operator に関するデータの収集

Node Maintenance Operator に関するデバッグ情報を収集するには、must-gather ツールを使用します。Node Maintenance Operator の must-gather イメージは、特定の機能に関するデータの収集 を参照してください。

7.7. 関連情報

法律上の通知

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.