Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

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

Workload Availability for Red Hat OpenShift 24.2

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

Red Hat Customer Content Services

概要

Workload Availability Operator とその使用法に関する情報

はじめに
リンクのコピー

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
リンクのコピー

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

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

1.2. Fence Agents Remediation
リンクのコピー

Fence Agents Remediation (FAR) Operator は、Self Node Remediation Operator と同様に、異常なノードを自動的に修復する Red Hat OpenShift のアドオン Operator です。既知のエージェント を使用して、異常なノードをフェンスして修復できます。修復には、フェンスエージェントを使用して異常なノードを再起動し、修復ストラテジー に応じて異常なノードからワークロードを削除することが含まれます。

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
リンクのコピー

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

1.6. ノードのメンテナンス
リンクのコピー

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

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

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

1.7. Workload Availability Operator のメトリクスについて
リンクのコピー

データ分析の追加により、Workload Availability Operator の可観測性が向上します。データは、Operator のアクティビティーとクラスターへの影響に関するメトリクスを提供します。これらのメトリクスにより、意思決定能力が向上し、データ駆動型の最適化が可能になり、システム全体のパフォーマンスが向上します。

メトリクスを使用して次のタスクを実行できます。

  • Operator の包括的な追跡データにアクセスして、システム全体の効率を監視します。
  • 頻繁に障害が発生するノードや、Operator の修復によるダウンタイムを特定するなど、追跡データから得られる実用的な洞察にアクセスします。
  • Operator の改善によって実際にシステム効率がどのように向上しているかを視覚化します。

1.7.1. Workload Availability Operator のメトリクスの設定
リンクのコピー

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

前提条件

手順

  1. 次のように、既存の prometheus-user-workload-token シークレットから prometheus-user-token シークレットを作成します。 

    existingPrometheusTokenSecret=$(kubectl get secret --namespace openshift-user-workload-monitoring | grep prometheus-user-workload-token | awk '{print $1}')
    1 
    

kubectl get secret ${existingPrometheusTokenSecret} --namespace=openshift-user-workload-monitoring -o yaml | \
    sed '/namespace: .*==/d;/ca.crt:/d;/serviceCa.crt/d;/creationTimestamp:/d;/resourceVersion:/d;/uid:/d;/annotations/d;/kubernetes.io/d;' | \
    sed 's/namespace: .*/namespace: openshift-workload-availability/' | \
    2 
    
    sed 's/name: .*/name: prometheus-user-workload-token/' | \
    3 
    
    sed 's/type: .*/type: Opaque/' | \
    > prom-token.yaml

kubectl apply -f prom-token.yaml
    1
    prometheus-user-token は、次の手順で作成されるメトリクス ServiceMonitor に必要です。
    2
    新しいシークレットの namespace が NHC Operator がインストールされている namespace (例: openshift-workload-availability) であることを確認します。
    3
    prometheus-user-workload-token は、User Worload Prometheus スクレイピングが有効になっている場合にのみ存在します。

  2. 次のように ServiceMonitor を作成します。 

    apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: node-healthcheck-metrics-monitor
  namespace: openshift-workload-availability
    1 
    
  labels:
    app.kubernetes.io/component: controller-manager
spec:
  endpoints:
  - interval: 30s
    port: https
    scheme: https
    authorization:
      type: Bearer
      credentials:
        name: prometheus-user-workload-token
        key: token
    tlsConfig:
      ca:
        configMap:
          name: nhc-serving-certs-ca-bundle
          key: service-ca.crt
      serverName: node-healthcheck-controller-manager-metrics-service.openshift-workload-availability.svc
    2 
    
  selector:
    matchLabels:
      app.kubernetes.io/component: controller-manager
      app.kubernetes.io/name: node-healthcheck-operator
      app.kubernetes.io/instance: metrics
    1
    メトリクスを設定する namespace を指定します (例: openshift-workload-availability)。
    2
    serverName には、Operator がインストールされているのと同じ namespace が含まれている必要があります。この例では、openshift-workload-availability は、メトリクスサービス名の後、ファイルタイプ拡張子の前に配置されます。

検証

設定が成功したことを確認するには、OCP Web UI の Observe > Targets タブに Endpoint Up と表示されます。

1.7.2. Workload Availability Operator のメトリクスの例
リンクのコピー

以下は、さまざまな Workload Availability Operator からのメトリクスの例です。

メトリクスには、次の指標に関する情報が含まれます。

  • 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 Node Remediation Operator をトリガーします。

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

apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediation
metadata:
  name: selfnoderemediation-sample
  namespace: openshift-workload-availability
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 コンソールで、Operators → OperatorHub に移動します。
  2. 使用可能な Operator のリストから Self Node Remediation Operator を選択し、Install をクリックします。
  3. Operator が openshift-workload-availability namespace にインストールされるように、Installation mode と namespace のデフォルトの選択を維持します。
  4. Install をクリックします。

検証

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

  1. Operators → Installed Operators ページに移動します。
  2. Operator が openshift-workload-availability namespace にインストールされており、そのステータスが Succeeded となっていることを確認します。

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

  1. Operators → Installed Operators ページに移動し、Status 列でエラーまたは失敗の有無を確認します。
  2. Workloads → Pod ページに移動し、openshift-workload-availability プロジェクト内の 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-workload-availability namespace にインストールできます。

前提条件

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

手順

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

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

      apiVersion: v1
kind: Namespace
metadata:
  name: openshift-workload-availability

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

      $ oc create -f workload-availability-namespace.yaml

  2. OperatorGroup を作成します。

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

      apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: workload-availability-operator-group
  namespace: openshift-workload-availability

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

      $ oc create -f workload-availability-operator-group.yaml

  3. Subscription CR を作成します。

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

      apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
    name: self-node-remediation-operator
    namespace: openshift-workload-availability
      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 を指定します。Self Node Remediation Operator を openshift-workload-availability namespace にインストールするには、Subscription CR で openshift-workload-availability を指定します。
      2
      指定したバージョンがカタログの新しいバージョンに置き換えられる場合に備えて、承認ストラテジーを Manual に設定します。これにより、新しいバージョンへの自動アップグレードが阻止され、最初の CSV のインストールが完了する前に手動での承認が必要となります。

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

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

検証

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

    $ oc get csv -n openshift-workload-availability

    出力例

    NAME                               DISPLAY                          VERSION   REPLACES   PHASE
self-node-remediation.v0.9.0       Self Node Remediation Operator   v.0.9.0   self-node-remediation.v0.8.1           Succeeded

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

    $ oc get deployment -n openshift-workload-availability

    出力例

    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 openshift-workload-availability

    出力例

    NAME                           AGE
self-node-remediation-config   28h

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

    $ oc get daemonset -n openshift-workload-availability

    出力例

    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) を作成します。

注記

特定のノードで予期しない再起動が発生しないようにするために、Node Maintenance Operator はノードをメンテナンスモードに設定し、特定のノードで SNR daemonset が実行されないようにするノードセレクターを自動的に追加します。

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-workload-availability
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 

  hostPort: 30001
11 

  customDsTolerations:
12 

      - effect: NoSchedule
        key: node-role.kubernetes.io.infra
        operator: Equal
        value: "value1"
        tolerationSeconds: 3600
1
Operator が、正常でないノードで実行中の影響を受けるワークロードを復元するまで待機する期間を指定します。障害が発生したノードで実行中の代替 Pod を開始すると、データの破損や 1 回実行セマンティクスの違反が生じる可能性があります。期間は、ApiServerTimeout、ApiCheckInterval、maxApiErrorThreshold、peerDialTimeout、および peerRequestTimeout フィールドの値を使用して Operator によって計算された最小値以上である必要があります。ログで、計算された minTimeToAssumeNodeRebooted is: [value] 値を参照して、Operator によって計算された最小値を確認できます。計算された最小値よりも低い値を指定すると、Operator は機能しなくなります。
2
ノード内のウォッチドッグデバイスのファイルパスを指定します。ウォッチドッグデバイスへの誤ったパスを入力すると、Self Node Remediation Operator がソフトドッグデバイスのパスを自動的に検出します。

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

3
異常なノードのソフトウェア再起動を有効にするかどうかを指定します。デフォルトでは、isSoftwareRebootEnabled の値は true に設定されています。ソフトウェアの再起動を無効にするには、パラメーター値を false に設定します。
4
各 API サーバーとの接続を確認するためのタイムアウト期間を指定します。この期間が経過すると、Operator は修復を開始します。タイムアウト期間は 10 ミリ秒以上である必要があります。
5
各 API サーバーとの接続を確認する頻度を指定します。タイムアウト期間は 1 秒以上である必要があります。
6
しきい値を指定します。このしきい値に達した後、ノードはピアへの接続を開始します。しきい値は 1 秒以上である必要があります。
7
ピアが API サーバーに接続するためのタイムアウトの期間を指定します。タイムアウト期間は 10 ミリ秒以上である必要があります。
8
ピアで接続を確立するためのタイムアウトの期間を指定します。タイムアウト期間は 10 ミリ秒以上である必要があります。
9
ピアから応答を取得するためのタイムアウトの期間を指定します。タイムアウト期間は 10 ミリ秒以上である必要があります。
10
IP アドレスなどのピア情報を更新する頻度を指定します。タイムアウト期間は 10 秒以上である必要があります。
11
任意の値を指定して、Self Node Remediation エージェントが内部通信に使用するポートを変更します。値は 0 より大きくなければなりません。デフォルト値はポート 30001 です。
12
さまざまなタイプのノードの修復をサポートするために、DaemonSet で実行されているカスタム Self Node Remediation エージェントを指定します。次のフィールドを設定できます。
  • effect : effect は一致するテイント効果を示します。このフィールドが空の場合、すべてのテイント効果が一致します。指定する場合、使用な可能な値は NoSchedule、PreferNoSchedule、および NoExecute です。
  • key : キーは、容認が適用されるテイントキーです。このフィールドが空の場合、すべてのテイントキーが一致します。キーが空の場合、Operator フィールドは Exists である必要があります。この組み合わせは、すべての値とすべてのキーが一致することを意味します。
  • Operator: 演算子はキーと値の関係を表します。有効な Operator は Exists および Equal です。デフォルトは Equal です。Exists は、値のワイルドカードと同等であるため、Pod は特定のカテゴリーのすべてのテイントを許容できます。
  • value: 容認が一致するテイントの値です。Operator が Exists の場合、値は空である必要があります。それ以外の場合は、通常の文字列になります。
  • tolerationSeconds: 容認 (NoExecute が有効である必要があり、そうでない場合はこのフィールドは無視されます) がテイントを許容する期間を表します。デフォルトでは設定されていないため、テイントを永久に許容します (エビクトされません)。ゼロ値と負の値は、システムによって 0 (すぐにエビクト) として扱われます。
  • カスタム容認により、容認を Self Node Remediation エージェント Pod に追加できます。詳細は、容認を使用した OpenShift Logging Pod の配置の制御 を参照してください。
注記
  • Self Node Remediation Operator は、deployment namespace にデフォルトで CR を作成します。
  • CR の名前は self-node-remediation-config である必要があります。
  • 指定できるのは、1 つの SelfNodeRemediationConfig CR のみです。
  • SelfNodeRemediationConfig CR を削除すると、セルフノード修復が無効になります。
  • Self Node Remediation Operator によって作成された 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-workload-availability' {"selfnoderemediationconfig":
"openshift-workload-availability/selfnoderemediationconfig-copy"}

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

Self Node Remediation Operator は、SelfNodeRemediationTemplate カスタムリソース定義 (CRD) も作成します。この CRD は、ワークロードをより速く回復することを目的としたノードの修復ストラテジーを定義します。次の修復ストラテジーが利用できます。

自動
この修復ストラテジーでは、Self Node Remediation Operator がクラスターに最適な修復戦略を決定できるようにすることで、修復プロセスを簡素化します。このストラテジーは、OutOfServiceTaint ストラテジーがクラスターで利用できるかどうかを確認します。OutOfServiceTaint ストラテジーが利用可能な場合、Operator は OutOfServiceTaint ストラテジーを選択します。OutOfServiceTaint ストラテジーが利用できない場合、Operator は ResourceDeletion ストラテジーを選択します。Automatic は、デフォルトの修復ストラテジーです。
ResourceDeletion
この修復ストラテジーは、ノードオブジェクトではなく、ノード上の Pod を削除します。
OutOfServiceTaint
この修復戦略により、ノードオブジェクトではなく、ノード上の Pod および関連するボリュームアタッチメントが暗黙的に削除されます。これは、ノードに OutOfServiceTaint ストラテジーを配置することによって実現されます。このストラテジーは、OpenShift Container Platform バージョン 4.13 以降のテクノロジープレビューでサポートされており、OpenShift Container Platform バージョン 4.15 以降の一般提供ではサポートされています。

Self Node Remediation Operator は、ResourceDeletion 修復ストラテジーが使用するストラテジー self-node-remediation-resource-deletion-template の SelfNodeRemediationTemplate 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-workload-availability
spec:
  template:
    spec:
      remediationStrategy: <remediation_strategy>
2
1
修復ストラテジーに基づいて修復テンプレートのタイプを指定します。<remediation_object> を リソース または node のいずれかに置き換えます (例: self-node-remediation-resource-deletion-template)。
2
修復ストラテジーを指定します。デフォルトの修復ストラテジーは Automatic です。

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

問題
デーモンセット、設定 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 と同様に、異常なノードを自動的に修復できます。FAR は、IPMI などの従来の API エンドポイントを備えた環境で、既存のアップストリームフェンシングエージェントセットを実行してクラスターノードの電源を入れ直す一方で、修復ストラテジー に基づいて Pod を迅速に削除するように設計されています。

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-workload-availability
spec:
  remediationStrategy: <remediation_strategy>
2
1
node-name は、正常でないクラスターノードの名前と一致する必要があります。
2
ノードの修復ストラテジーを指定します。利用可能な修復ストラテジーの詳細は、フェンスエージェント修復テンプレートの設定について を参照してください。

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 コンソールで、Operators → OperatorHub に移動します。
  2. 使用可能な Operator のリストから Fence Agents Remediation Operator (FAR) を選択し、Install をクリックします。
  3. Operator が openshift-workload-availability namespace にインストールされるように、Installation mode と namespace のデフォルトの選択を維持します。
  4. Install をクリックします。

検証

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

  1. Operators → Installed Operators ページに移動します。
  2. Operator が openshift-workload-availability namespace にインストールされており、そのステータスが Succeeded となっていることを確認します。

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

  1. Operators → Installed Operators ページに移動し、Status 列でエラーまたは失敗の有無を確認します。
  2. Workloads → Pods ページに移動し、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-workload-availability namespace にインストールできます。

前提条件

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

手順

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

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

      apiVersion: v1
kind: Namespace
metadata:
  name: openshift-workload-availability

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

      $ oc create -f workload-availability-namespace.yaml

  2. OperatorGroup を作成します。

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

      apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: workload-availability-operator-group
  namespace: openshift-workload-availability

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

      $ oc create -f workload-availability-operator-group.yaml

  3. Subscription CR を作成します。

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

      apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
    name: fence-agents-remediation-subscription
    namespace: openshift-workload-availability
      1 
      
spec:
    channel: stable
    name: fence-agents-remediation
    source: redhat-operators
    sourceNamespace: openshift-marketplace
    package: fence-agents-remediation
      1
      Fence Agents Remediation Operator をインストールする Namespace を指定します (例: この手順で前述した openshift-workload-availability)。一致する OperatorGroup CR がすでに存在する openshift-workload-availability namespace に、Fence Agents Remediation Operator の Subscription CR をインストールできます。

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

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

検証

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

    $ oc get csv -n openshift-workload-availability

    出力例

    NAME                               DISPLAY                          VERSION   REPLACES   PHASE
fence-agents-remediation.v0.4.0      Fence Agents Remediation Operator   0.4.0   fence-agents-remediation.v0.3.0           Succeeded

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

    $ oc get deployment -n openshift-workload-availability

    出力例

    NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
fence-agents-remediation-controller-manager    2/2     2            2           110m

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 は以下の YAML ファイルのようになります。 

apiVersion: fence-agents-remediation.medik8s.io/v1alpha1
kind: FenceAgentsRemediationTemplate
metadata:
  name: fence-agents-remediation-template-fence-ipmilan
  namespace: openshift-workload-availability
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
      retryCount: '5'
4 

      retryInterval: '5s'
5 

      timeout: '60s'
6
1
実行されるフェンス エージェント の名前を表示します (例: fence_ipmilan)。
2
ipport など、フェンスエージェントを実行するためのノード固有のパラメーターを表示します。
3
username など、フェンスエージェントを実行するためのクラスター全体のパラメーターを表示します。
4
障害が発生した場合のフェンスエージェントコマンドを再試行する回数を表示します。デフォルトの試行回数は 5 です。
5
再試行の間隔を秒単位で表示します。デフォルトは 5 秒です。
6
フェンスエージェントコマンドのタイムアウト値を表示します。デフォルトは 60 秒です。タイムアウト値が 60 秒以上の場合、YAML ファイルではその値が分と秒の両方で表記されます。

3.4.1. フェンスエージェント修復テンプレートの設定を理解する
リンクのコピー

Fence Agents Remediation Operator は、FenceAgentsRemediationTemplate カスタムリソース定義 (CRD) も作成します。この CRD は、ワークロードをより速く回復することを目的としたノードの修復ストラテジーを定義します。次の修復ストラテジーが利用できます。

ResourceDeletion
この修復ストラテジーにより、ノード上の Pod が削除されます。
OutOfServiceTaint
この修復ストラテジーにより、ノード上の Pod と関連するボリュームアタッチメントが暗黙的に削除されます。これは、ノードに OutOfServiceTaint テイントを配置することによって実現されます。OutOfServiceTaint ストラテジーは、非正常なノードシャットダウンも表します。非正常なノードシャットダウンは、オペレーティングシステム内のシャットダウンをトリガーするのではなく、ノードがシャットダウンされても検出されない場合に発生します。このストラテジーは、OpenShift Container Platform バージョン 4.13 以降のテクノロジープレビューでサポートされており、OpenShift Container Platform バージョン 4.15 以降の一般提供ではサポートされています。

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

apiVersion: fence-agents-remediation.medik8s.io/v1alpha1
kind: FenceAgentsRemediationTemplate
metadata:
  name: fence-agents-remediation-<remediation_object>-deletion-template
1 

  namespace: openshift-workload-availability
spec:
  template:
    spec:
      remediationStrategy: <remediation_strategy>
2
1
修復ストラテジーに基づいて修復テンプレートのタイプを指定します。<remediation_object> を リソース または taint のいずれかに置き換えます (例: fence-agents-remediation-resource-deletion-template)。
2
修復ストラテジーを指定します。修復ストラテジーは、ResourceDeletion または OutOfServiceTaint のいずれかになります。

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 リソースを削除するには、アンインストールする前に "Delete all operand instances for this 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. Fence Agents Remediation Operator でサポートされているエージェント
リンクのコピー

このセクションでは、Fence Agents Remediation Operator によって現在サポートされているエージェントを説明します。

サポートされているエージェントのほとんどは、次のように、ノードのハードウェアのプロプライエタリーと使用法によってグループ化できます。

  1. BareMetal
  2. 仮想化
  3. Intel
  4. HP
  5. IBM
  6. VMware
  7. Cisco
  8. APC
  9. Dell
  10. その他
Expand
表3.1 BareMetal - サポートされていない場合を除き、Redfish 管理インターフェイスの使用を推奨します。
Agent説明

fence_redfish

Redfish API をサポートする Out-of-Band コントローラーで使用できる I/O フェンシングエージェント。

fence_ipmilan [a]

IPMI によって制御されるマシンで使用できる I/O フェンシングエージェント。

[a] この説明は、エージェント fence_ilo3、fence_ilo4、fence_ilo5、fence_imm、fence_idrac、fence_ipmilanplus にも適用されます。
Expand
表3.2 仮想化
Agent説明

fence_rhevm

RHEV-M REST API と組み合わせて 仮想 マシンをフェンスするために使用できる I/O フェンシングエージェント。

fence-virt [a]

仮想 マシンで使用できる I/O フェンシングエージェント。

[a] この説明はエージェント fence_xvm にも適用されます。
Expand
表3.3 Intel
Agent説明

fence_amt_ws

Intel AMT (WS) で使用できる I/O フェンシングエージェント。

fence_intelmodular

Intel モジュラーデバイスで使用できる I/O フェンシングエージェント (Intel MFSYS25 でテスト済み、MFSYS35 でも動作するはずです)。

Expand
表3.4 HP - iLO 管理インターフェイスまたは BladeSystem 用のエージェント。
Agent説明

fence_ilo [a]

Integrated Light Out (iLO) PCI カードを搭載した HP サーバーで使用できる I/O フェンシングエージェント。

fence_ilo_ssh [b]

iLO デバイスに接続するために使用できるフェンシングエージェント。ssh 経由でデバイスにログインし、指定されたコンセントを再起動します。

fence_ilo_moonshot

HP Moonshot iLO で使用できる I/O フェンシングエージェント。

fence_ilo_mp

HP iLO MP で使用できる I/O フェンシングエージェント。

fence_hpblade

HP BladeSystem および HP Integrity Superdome X で使用できる I/O フェンシングエージェント。

[a] この説明はエージェント fence_ilo2 にも適用されます。
[b] この説明は、エージェント fence_ilo3_ssh、fence_ilo4_ssh、および fence_ilo5_ssh にも適用されます。
Expand
表3.5 IBM
Agent説明

fence_bladecenter

telnet サポートを含む最新のファームウェアを搭載した IBM Bladecenter で使用できる I/O フェンシングエージェント。

fence_ibmblade

IBM BladeCenter シャーシで使用できる I/O フェンシングエージェント。

fence_ipdu

IBM iPDU ネットワーク電源スイッチで使用できる I/O フェンシングエージェント。

fence_rsa

IBM RSA II 管理インターフェイスで使用できる I/O フェンシングエージェント。

Expand
表3.6 VMware
Agent説明

fence_vmware_rest

VMware API と組み合わせて仮想マシンをフェンスするために使用できる I/O フェンシングエージェント。

fence_vmware_soap

SOAP API v4.1 以降を備えた VMWare 製品によって管理される仮想マシンで使用できる I/O フェンシングエージェント。

Expand
表3.7 Cisco
Agent説明

fence_cisco_mds

SNMP 対応デバイスを搭載した Cisco MDS 9000 シリーズで使用できる I/O フェンシングエージェント。

fence_cisco_ucs

Cisco UCS でマシンをフェンスするために使用できる I/O フェンシングエージェント。

Expand
表3.8 APC
Agent説明

fence_apc

APC ネットワーク電源スイッチで使用できる I/O フェンシングエージェント。

fence_apc_snmp

APC ネットワーク電源スイッチまたは Tripplite PDU デバイスで使用できる I/O フェンシングエージェント。

Expand
表3.9 Dell
Agent説明

fence_drac5

Dell リモートアクセスカード v5 または CMC (DRAC) で使用できる I/O フェンシングエージェント。

Expand
表3.10 その他 - 前の表に記載されていない使用目的のエージェント。
Agent説明

fence_brocade

Brocade FC スイッチで使用できる I/O フェンシングエージェント。

fence_compute

コンピュートノードがダウンしていることを Nova に通知し、フラグが付けられたインスタンスを再スケジュールするために使用できるリソース。

fence_eaton_snmp

Eaton ネットワーク電源スイッチで使用できる I/O フェンシングエージェント。

fence_emerson

MPX および MPH2 管理ラック PDU で使用できる I/O フェンシングエージェント。

fence_eps

ePowerSwitch 8M+ 電源スイッチと組み合わせて使用し、接続されたマシンをフェンスできる I/O フェンシングエージェント。

fence_evacuate

フラグが付けられたインスタンスを再スケジュールするために使用できるリソース。

fence_heuristics_ping

同じフェンシングレベルにある別のフェンスエージェントの実行を制御するために ping ヒューリスティックで使用できるリソース。

fence_ifmib

任意の SNMP IF-MIB 対応デバイスで使用できる I/O フェンシングエージェント。

fence_kdump

kdump クラッシュ回復サービスで使用できる I/O フェンシングエージェント。

fence_mpath

SCSI-3 永続予約を使用してマルチパスデバイスへのアクセスを制御できる I/O フェンシングエージェント。

fence_rsb

Fujitsu-Siemens RSB 管理インターフェイスで使用できる I/O フェンシングエージェント。

fence_sbd

sbd を使用できる環境 (共有ストレージ) で使用できる I/O フェンシングエージェント。

fence_scsi

SCSI-3 永続予約を使用して共有ストレージデバイスへのアクセスを制御できる I/O フェンシングエージェント。

fence_wti

WTI ネットワーク電源スイッチ (NPS) で使用できる I/O フェンシングエージェント。

3.8. 関連情報
リンクのコピー

第4章 Machine Deletion Remediation の使用
リンクのコピー

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 コンソールで、Operators → OperatorHub に移動します。
  2. 使用可能な Operator のリストから Machine Deletion Remediation Operator (MDR) を選択し、Install をクリックします。
  3. Operator が openshift-workload-availability namespace にインストールされるように、Installation mode と namespace のデフォルトの選択を維持します。
  4. Install をクリックします。

検証

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

  1. Operators → Installed Operators ページに移動します。
  2. Operator が openshift-workload-availability namespace にインストールされており、そのステータスが Succeeded となっていることを確認します。

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

  1. Operators → Installed Operators ページに移動し、Status 列でエラーまたは失敗の有無を確認します。
  2. Workloads → Pod ページに移動し、openshift-workload-availability プロジェクトの Pod のログで報告された問題がないか確認します。

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

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

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

前提条件

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

手順

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

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

      apiVersion: v1
kind: Namespace
metadata:
  name: openshift-workload-availability

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

      $ oc create -f workload-availability-namespace.yaml

  2. OperatorGroup を作成します。

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

      apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: workload-availability-operator-group
  namespace: openshift-workload-availability

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

      $ oc create -f workload-availability-operator-group.yaml

  3. Subscription CR を作成します。

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

      apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
    name: machine-deletion-remediation-operator
    namespace: openshift-workload-availability
      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-workload-availability Subscription CR にインストールすると、Namespace と OperatorGroup CR はすでに存在します。

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

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

検証

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

    $ oc get csv -n openshift-workload-availability

    出力例

    NAME                               DISPLAY                          VERSION   REPLACES   PHASE
machine-deletion-remediation.v0.3.0      Machine Deletion Remediation Operator   0.3.0   machine-deletion-remediation.v0.2.1           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-workload-availability
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: Automatic
      1
      1
      修復ストラテジーを指定します。デフォルトの修復ストラテジーは Automatic です。

    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-workload-availability
    kind: SelfNodeRemediationTemplate
  escalatingRemediations:
4 

    - remediationTemplate:
        apiVersion: self-node-remediation.medik8s.io/v1alpha1
        name: self-node-remediation-resource-deletion-template
        namespace: openshift-workload-availability
        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 のようになります。remediationTemplate は escalatingRemediation と相互排他的です。
4
順序フィールドとタイムアウトフィールドを含む RemediationTemplate のリストを指定します。正常なノードを取得するには、このフィールドを使用して複数の修復を順序付けし、設定します。この戦略により、成功しない可能性のある単一の修復に依存するのではなく、正常なノードを取得できる可能性が高まります。order フィールドは、修復が呼び出される順序を決定します (低い順序 = 早い呼び出し)。timeout フィールドは、次の修復がいつ呼び出されるかを決定します。escalatingRemediation は remediationTemplate と相互排他的です。
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"}

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

    ログメッセージの例

    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 コンソールで、Operators → OperatorHub に移動します。
  2. Node Health Check Operator を選択し、Install をクリックします。
  3. Operator が openshift-workload-availability namespace にインストールされるように、Installation mode と namespace のデフォルトの選択を維持します。
  4. Console plug-in が Enable に設定されていることを確認します。
  5. Install をクリックします。

検証

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

  1. Operators → Installed Operators ページに移動します。
  2. Operator が openshift-workload-availability namespace にインストールされており、そのステータスが Succeeded となっていることを確認します。

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

  1. Operators → Installed Operators ページに移動し、Status 列でエラーまたは失敗の有無を確認します。
  2. Workloads → Pods ページに移動し、openshift-workload-availability プロジェクトの Pod で問題を報告しているログの有無を確認します。

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

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

Node Health Check Operator は、独自の namespace または openshift-workload-availability namespace にインストールできます。

前提条件

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

手順

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

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

      apiVersion: v1
kind: Namespace
metadata:
  name: openshift-workload-availability

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

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

  2. OperatorGroup を作成します。

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

      apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: workload-availability-operator-group
  namespace: openshift-workload-availability

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

      $ oc create -f workload-availability-operator-group.yaml

  3. Subscription CR を作成します。

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

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

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

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

検証

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

    $ oc get csv -n openshift-workload-availability

    出力例

    NAME                              DISPLAY                     VERSION  REPLACES PHASE
node-healthcheck-operator.v0.8.0  Node Health Check Operator  0.8.0   node-healthcheck-operator.v0.7.0           Succeeded

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

    $ oc get deployment -n openshift-workload-availability

    出力例

    NAME                                           READY   UP-TO-DATE   AVAILABLE   AGE
node-healthcheck-controller-manager            2/2     2            2           10d

6.5. ノードヘルスチェックの作成
リンクのコピー

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

手順

  1. Red Hat OpenShift Web コンソールの Administrator の観点から、Compute → NodeHealthChecks → CreateNodeHealthCheck をクリックします。
  2. Form ビュー または YAML ビュー を使用してノードのヘルスチェックを設定するかどうかを指定します。
  3. ノードヘルスチェックの 名前 を入力します。名前は小文字、英数字、'-'、または '.' で構成され、英数字で開始および終了する必要があります。
  4. Remediator タイプ、および Self node remediation または Other を指定します。Self node remediation オプションは、Node Health Check Operator でインストールされる Self Node Remediation Operator の一部です。Other を選択するには、API バージョン、Kind、Name、および Namespace を入力する必要があります。これは、修正の修復テンプレートリソースを指します。

  5. 修復する ノード のラベルを指定して、ノードを選択します。選択した内容は、確認するラベルと一致します。複数のラベルを指定する場合、ノードには各ラベルが含まれている必要があります。デフォルト値は空で、ワーカーノードとコントロールプレーンノードの両方を選択します。

    注記

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

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

検証

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

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 コンソールまたは OpenShift 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 コンソールで、Operators → OperatorHub に移動します。
  2. Node Maintenance Operator を選択し、Install をクリックします。
  3. Operator が openshift-workload-availability namespace にインストールされるように、Installation mode と namespace のデフォルトの選択を維持します。
  4. Install をクリックします。

検証

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

  1. Operators → Installed Operators ページに移動します。
  2. Operator が openshift-workload-availability namespace にインストールされており、そのステータスが Succeeded となっていることを確認します。

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

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

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

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

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

前提条件

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

手順

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

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

      apiVersion: v1
kind: Namespace
metadata:
  name: openshift-workload-availability

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

      $ oc create -f workload-availability-namespace.yaml

  2. OperatorGroup を作成します。

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

      apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: workload-availability-operator-group
  namespace: openshift-workload-availability

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

      $ oc create -f workload-availability-operator-group.yaml

  3. Subscription CR を作成します。

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

      apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: node-maintenance-operator
  namespace: openshift-workload-availability
      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-workload-availability namespace にインストールするには、Subscription CR で openshift-workload-availability を指定します。

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

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

検証

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

    $ oc get csv -n openshift-workload-availability

    出力例

    NAME                               DISPLAY                     VERSION   REPLACES  PHASE
node-maintenance-operator.v5.3.0   Node Maintenance Operator   5.3.0   node-maintenance-operator.v5.2.1            Succeeded

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

    $ oc get deployment -n openshift-workload-availability

    出力例

    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 パースペクティブで、Operators → Installed 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 パースペクティブで、Operators → Installed 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. ベアメタルノードをメンテナンスモードに設定する
リンクのコピー

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

手順

  1. Web コンソールの 管理者 パースペクティブから、Compute → Nodes をクリックします。

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

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

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

検証

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

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

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

手順

  1. Web コンソールの 管理者 パースペクティブから、Compute → Nodes をクリックします。

  2. 複数のノードでアクションを簡単に実行できるこの画面からノードを再開できます。または、選択したノードの包括的な詳細を表示できる Node Details 画面からもノードを再開できます。

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

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

検証

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

7.6. Node Maintenance Operator に関するデータの収集
リンクのコピー

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

法律上の通知
リンクのコピー

Copyright © 2025 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.
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る