IBM Cloud Docs
Critical または NotReady 状態のワーカー・ノードのトラブルシューティング

Critical または NotReady 状態のワーカー・ノードのトラブルシューティング

クラスター・ワーカー・ノードは、クラスター・マスターとの通信を停止すると、 Critical 状態または NotReady 状態になります。 これが発生すると、 IBM Cloud UI で、または ibmcloud ks worker コマンドの実行時に、 Kubernetes ダッシュボードで NotReady として、および kubectl get nodes の実行時に、ワーカー・ノードに Critical のマークが付けられます。 ワーカー・ノードとクラスター・マスターの間の通信が停止する理由はいくつかあります。 これらの状態のワーカー・ノードをトラブルシューティングするには、以下の手順を実行します。

IBM Cloud の正常性と状況のダッシュボードで、ワーカー・ノードに関連する可能性がある通知や保守更新がないかを確認します。 これらの通知または更新は、ワーカー・ノードの障害の原因を判別するのに役立ちます。

ワーカー・ノードの障害の一般的な原因を確認します。

ワーカー・ノードとクラスター・マスターの間の通信が停止する理由はいくつかあります。 以下の一般的な問題が原因で中断が発生しているかどうかを確認します。

ワーカーが削除、再ロード、更新、置換、またはリブートされた
ワーカー・ノードが削除、再ロード、更新、または置換されると、ワーカー・ノードの状態が一時的に Critical または NotReady になる場合があります。 ワーカー・ノードでこれらのアクションのいずれかが開始されている場合は、手動で開始するか、クラスター自動スケーリング機能などの自動セットアップの一部として開始するかにかかわらず、アクションが完了するまで待機します。 その後、ワーカー・ノードの状況を再度確認します。 Critical 状態または NotReady 状態のワーカーが残っている場合は、影響を受けるワーカーを 再ロード または 置換 します。
ワーカー・ノードが再ロードまたは置換され、最初は正しく機能していたが、しばらくして Critical または NotReady 状態に戻った場合は、ワーカーの一部のワークロードまたはコンポーネントが問題の原因である可能性があります。 問題のワークロードを切り分けるには、 ワーカー・ノードのデバッグ を参照してください。

ワーカー・ノードは、最初に閉鎖されてドレーンされずにリブートされた場合、 Critical 状態または NotReady 状態になる可能性があります。 この場合、リブートの完了を待機しても問題は解決されません。 影響を受けるワーカーを 再ロード または 置換 します。 問題が解決しない場合は、トラブルシューティング手順を続行してください。

ワーカー・ノードの電源が意図せず遮断されました
クラシック・クラスターIBM Cloud コンソール・リソース・リストでは、クラシック・インフラストラクチャー上のワーカー・ノードは コンピュート・リソース(仮想マシン) として分類されます。 場合によっては、ユーザーが、これらのリソースがクラスター・ワーカー・ノードとして機能することに気付かず、ワーカー・ノードの電源を誤って遮断する可能性があります。 電源が遮断されたワーカー・ノードは、 Critical 状態または NotReady 状態で表示される可能性があります。 影響を受けるワーカー・ノードの電源が遮断されていないことを確認します。

トラブルシューティング・ステップ

一般的な原因 に対処した後もワーカー・ノードが Critical または NotReady の状態のままである場合は、以下のトラブルシューティング手順に進みます。

以前に再ロードまたは置換したワーカー・ノードが、 ibmcloud ks workers の実行時に deploy_failed または provision_failed 状態になっている場合は、 「クラスター内のすべてのワーカー・ノードが影響を受ける」 セクションの手順に従います (すべてのノードが影響を受けるわけではない場合でも)。 別の状態が示されている場合は、 ワーカー・ノードの状態 を参照して、新しいワーカーのトラブルシューティングの手順を確認してください。 追加のワーカー・ノードを置換したり再ロードしたりしないでください。

1 つ以上のワーカー・ノードが影響を受ける場合

クラスター内のすべてではなく一部のワーカー・ノードのみが Critical 状態または NotReady 状態である場合は、以下の手順に従って中断の原因を判別し、問題を解決してください。 影響を受けるワーカー・ノードがすべて同じゾーン、サブネット、または VLAN からのものである場合は、次のセクションに進みます。

  1. 特定のノードの詳細を取得する。

    kubectl describe node <node-IP-address>

  2. 出力で、 「条件」 セクションを確認して、ノードでメモリー、ディスク、または PID の問題が発生しているかどうかを判別します。 この情報は、そのタイプのリソースでノードが不足していることを示している可能性があります。 このような状況は、以下のいずれかの理由で発生する可能性がある：

    • ポッドで適切な要求と制限がないことが原因で、メモリーまたは CPU が使い尽くされました。
    • ワーカー・ディスクがフルになっています。ポッド・ログが大きいか、ポッドがノード自体に出力されていることが原因である場合があります。
    • 時間の経過とともに蓄積される低速メモリー・リーク。これにより、1 カ月以上更新されていないワーカーに問題が発生する可能性があります。
    • Linux カーネルに影響するバグと異常終了。

  3. 「条件」 セクションの情報から問題の原因を判別できる場合は、 ワーカー・ノードのデバッグ の手順に従って、問題のワークロードを分離してください。

  4. 前のステップで問題が解決しない場合は、影響を受けたワーカーを一度に 1 つずつ 再ロード または 置き換え ます。

すべてではなく一部のワーカー・ノードが頻繁に Critical 状態または NotReady 状態になる場合は、これらのリカバリー・ステップを自動化するために ワーカー自動リカバリー を有効にすることを検討してください。

単一ゾーン、サブネット、または VLAN 内のすべてのワーカー・ノードが影響を受ける場合

あるゾーン、サブネット、または VLAN 内のすべてのワーカーノードが Critical または NotReady の状態であるにもかかわらず、クラスタ内の他のすべてのワーカーノードが正常に機能している場合は、ネットワークコンポーネントに問題がある可能性があります。 クラスター内のすべてのワーカー・ノードが影響を受ける場合 の手順に従ってください。特に、ゾーン、サブネットまたは VLAN に影響を与える可能性があるネットワーキング・コンポーネント (ファイアウォールまたはゲートウェイのルール、ACL またはカスタム経路、 Calico および Kubernetes ネットワーク・ポリシーなど) に関する手順に従ってください。

ネットワーキング・コンポーネントを確認しても問題を解決できない場合は、 ワーカー・ノード・データを収集 して、サポート・チケットをオープンしてください。

クラスター内のすべてのワーカー・ノードが影響を受ける場合

クラスター内のすべてのワーカー・ノードに Critical または NotReady が同時に表示される場合は、クラスター apiserver 、またはワーカーと apiserver の間のネットワーキング・パスに問題がある可能性があります。 以下のトラブルシューティング手順に従って、原因を判別し、問題を解決してください。

一部のステップは、ネットワーキングや自動化などの特殊な領域に固有のものです。 これらのステップを実行する前に、組織内の関連する管理者またはチームに相談してください。

  1. ワーカー・ノードに影響を与える可能性がある、クラスター、環境、またはアカウントに対する最近の変更があるかどうかを確認します。 その場合は、変更を元に戻してから、ワーカー・ノードの状況を確認して、変更によって問題が発生したかどうかを判別します。

    • クラシック・クラスターの場合は、クラスター・ワーカーのトラフィックを管理するファイアウォールまたはゲートウェイ ( Virtual Router Appliance、Vyatta、Juniper など) を確認します。 クラスター・ワーカーからのトラフィックをドロップまたはリダイレクトする可能性がある変更または問題を探します。
    • VPC クラスターの場合は、VPC またはワーカー・ノードのデフォルトのセキュリティー・グループと ACL に変更が加えられているかどうかを確認します。 何らかの変更を行った場合は、クラスター・ワーカー・ノードからクラスター・マスター、コンテナー・レジストリー、およびその他の重要なサービスへの必要なすべてのトラフィックを許可していることを確認してください。 詳しくは、 VPC セキュリティー・グループによるトラフィックの制御 および ACL によるトラフィックの制御 を参照してください。
    • VPC クラスターの場合は、クラスター apiserver からのトラフィックをブロックしている可能性がある変更について、カスタム・ルーティング・ルールを確認します。
    • クラスターに適用されている Calico または Kubernetes ネットワーク・ポリシーを確認し、ワーカー・ノードからクラスター apiservice、コンテナー・レジストリー、またはその他の重要なサービスへのトラフィックをブロックしていないことを確認します。

  2. クラスター内のアプリケーション、セキュリティー、またはモニター・コンポーネントが要求でクラスター apiserver を過負荷にしているかどうかを確認します。これにより、ワーカー・ノードが中断される可能性があります。

  3. 最近クラスターにコンポーネントを追加した場合は、それらを削除します。 クラスター内の既存のコンポーネントに変更を加えた場合は、その変更を元に戻します。 次に、ワーカー・ノードの状況を調べて、新しいコンポーネントまたは変更が問題の原因であったかどうかを確認します。

  4. クラスター Webhook が変更されていないか確認します。変更されていると、 apiserver 要求が中断されたり、ワーカー・ノードが apiserver に接続できなくなったりする可能性があります。 リクエストを拒否しているウェブフックをチェックする。 以下のコマンドを実行して、リクエストを拒否しているウェブフックのリストを取得する。

    kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds

  5. rejected="true" ステータスのウェブフックの出力を確認してください。

  6. ワーカーノードのステータスを確認してください。 Normal 状態の場合は、ワーカー・ノードの中断の原因となった構成またはコンポーネントを判別できるまで、削除したコンポーネントを再度追加し、元に戻した変更を 1 つずつ再作成します。

  7. それでも問題が解決しない場合は、 ワーカー・ノード・データを収集する 手順に従って、サポート・チケットをオープンしてください。

ワーカー・ノードが正常状態とクリティカル状態の間で切り替わる場合

ワーカー・ノードが Normal と Critical または NotReady の状態を切り替える場合は、以下のコンポーネントを調べて、ワーカー・ノードを中断させる可能性のある問題や最近の変更がないかどうかを確認します。

  1. クラシック・クラスターの場合は、ファイアウォールまたはゲートウェイを確認します。 帯域幅の制限または何らかのタイプの誤動作がある場合は、問題を解決してください。 その後、ワーカー・ノードを再度確認します。

  2. クラスター内のアプリケーション、セキュリティー、またはモニター・コンポーネントが要求でクラスター apiserver を過負荷にしているかどうかを確認します。これにより、ワーカー・ノードが中断される可能性があります。

  3. 最近クラスターにコンポーネントを追加した場合は、それらを削除します。 クラスター内の既存のコンポーネントに変更を加えた場合は、その変更を元に戻します。 次に、ワーカー・ノードの状況を調べて、新しいコンポーネントや変更が問題の原因になっていないかを確認します。

  4. クラスター Webhook が変更されていないか確認します。変更されていると、 apiserver 要求が中断されたり、ワーカー・ノードが apiserver に接続できなくなったりする可能性があります。 リクエストを拒否しているウェブフックをチェックする。 以下のコマンドを実行して、リクエストを拒否しているウェブフックのリストを取得する。

    kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds

  5. rejected="true" ステータスのウェブフックの出力を確認してください。

  6. それでも問題が解決しない場合は、 ワーカー・ノード・データを収集する 手順に従って、サポート・チケットをオープンしてください。

サポート Case のデータの収集

トラブルシューティング手順で問題を解決できない場合は、ワーカー・ノードに関する情報を収集します。 次に、 サポート・チケットを開き 、収集したワーカー・ノード情報を含めます。

サポート・チケットを開く前に、情報を確認し、 ワーカー・ノードのデバッグ、 ワーカー・ノードの状態、および Critical または NotReady 状態のワーカー・ノードのトラブルシューティング のトラブルシューティング手順に従ってください。

クラスタ内のすべてのワーカーノード、または 1 つのリージョン、サブネット、または VLAN 内のワーカーノードが影響を受ける場合、データを収集せずに初期サポートチケットを開くことができます。 ただし、後で関連データを収集するように求められる場合があります。 影響を受けるワーカー・ノードが 1 つのみまたは一部のみの場合は、サポート・チケットに含める関連データを収集する必要があります。

開始前に

データを収集する前に、ワーカー・ノードとクラスターの状態を確認します。

  1. ノードの CPU とメモリーのレベルを確認します。 CPU またはメモリーの使用率が 80% を超えるノードがある場合は、さらにノードをプロビジョニングするか、ワークロードを削減することを検討してください。

    kubectl top node

    出力例

    NAME            CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
10.001.1.01     640m         16%    6194Mi          47%       
10.002.2.02     2686m        68%    4024Mi          30%       
10.003.3.03     2088m        53%    10735Mi         81%

  2. クラスター Webhook が変更されていないか確認します。変更されていると、 apiserver 要求が中断されたり、ワーカー・ノードが apiserver に接続できなくなったりする可能性があります。 リクエストを拒否しているウェブフックをチェックする。 以下のコマンドを実行して、リクエストを拒否しているウェブフックのリストを取得する。

    kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds

  3. rejected="true" ステータスのウェブフックの出力を確認してください。

データのギャザリング

手順に従って、関連するワーカー・ノード・データを収集します。

  1. 各ノードの詳細を取得します。 サポート・チケットに含める出力の詳細を保存します。

    kubectl describe node <node-ip-address>

  2. Diagnostics and Debug Tool を実行します。 kube およびネットワーク・テスト結果を圧縮ファイルにエクスポートし、サポート・チケットに含めるファイルを保存します。 クラスター内のすべてのワーカーが影響を受ける場合は、すべてのワーカー・ノードが中断されてもデバッグ・ツールが正しく機能しないため、このステップをスキップできます。

  3. Webhook の詳細を取得して、クラスター内に追加された変更 Webhook や検証 Webhook が残っていないことを示します。 コマンド出力を保存して、サポート・チケットに含めます。 alertmanagerconfigs.openshift、 managed-storage-validation-webhooks、 multus.openshift.io、 performance-addon-operator、 prometheusrules.openshift.io、snapshot.storage.k8s.io のミュータブル Webhook が残っている可能性があり、削除する必要がないことに注意してください。

    kubectl get mutatingwebhookconfigurations

    kubectl get validatingwebhookconfigurations

  4. クラシック・クラスター: 影響を受けるいずれかのワーカーの KVM コンソールにアクセスします。 次に、関連するログと出力を収集します。

    1. KVM コンソール にアクセスするには、以下の手順に従ってください。

    2. 以下のログを収集して保存します。 ワーカー・ノードの中断の考えられる原因 (メモリーまたはディスク・スペースの不足、ディスクの読み取り専用モードへの移行、その他の問題など) をログで確認します。

      • /var/log/containerd.log
      • /var/log/kern.log
      • /var/log/kube-proxy.log
      • /var/log/syslog
      • /var/log/kubelet.log

    3. 以下のコマンドを実行し、出力を保存してサポート・チケットに添付します。

      • ps -aux # ダンプ実行プロセス
      • df -H # ディスク使用情報をダンプします
      • vmstat # メモリー使用量情報をダンプします
      • lshw # ハードウェア情報をダンプします。
      • last -Fxn2 shutdown reboot # 最後の再始動が正常終了したかどうかを判別します。
      • mount | grep -i "(ro" # ディスクの読み取り専用の問題を除外します。 注: tmpfs ro は問題ありません。
      • touch /this # ディスクの読み取り専用の問題を除外する

  5. VPC クラスタ ：以下の例のように、 kubectl top コマンドを使用して、ワーカーノードのリソース使用量を収集する。

    kubectl top nodes

    出力例は、CPU使用量をミリコア（m）単位で、メモリー使用量をメガバイト（Mi）単位で示す。

    NAME          CPU(cores)    CPU%   MEMORY(bytes)   MEMORY%
k8s-node-1      250m              12%    800Mi                         40%
k8s-node-2      180m               9%     600Mi                         30%
k8s-node-3      250m               22%    700Mi                        50%
    名前
    ノードの名前。
    CPU (コア)
    ミリコア（m）単位の現在のCPU使用率。 1000m は1コアに相当する。
    CPU%
    ノードで使用されているCPU容量の割合。
    メモリー (バイト)
    現在のメモリ使用量を MiB （メガバイト）または GiB （ギガバイト）で示す。
    メモリー
    総メモリ容量に対する使用率。

    CPU%またはMEMORY%が高い（80%以上）ノードは、過負荷になっている可能性があり、追加リソースが必要になる可能性があります。 CPU%またはMEMORY%が低い（20%以下）ノードは、ワークロードを再分配する余地があることを示す、使用率が低い可能性がある。 ノードのCPUまたはメモリ使用率が100%に達すると、新しいワークロードのスケジューリングに失敗したり、パフォーマンスが低下したりする可能性がある。

  6. 以下のコマンドを使用して、ポッドからリソースの使用量を収集する。

    kubectl top pods --all-namespaces

    出力例

    NAMESPACE       NAME                                  CPU(cores)   MEMORY(bytes)
default            my-app-564bc58dad-hk5gn       120m            256Mi
default             my-db-789d9c6c4f-tn7mv         300m            512Mi
    名前
    ポッドの名前。
    CPU (コア)
    すべてのコンテナでポッドが使用するCPUの合計。
    メモリー (バイト)
    すべてのコンテナでポッドが使用するメモリの合計。

    ポッドのCPU使用率が高い場合、パフォーマンスに影響するCPUスロットリングが発生している可能性があります。 ポッドのメモリ使用量が限界に近い場合、OOM（Out of Memory）エラーの危険性があります。OOMエラーでは、 Kubernetes、メモリを解放するためにプロセスが終了します。 リソースの使用量が少ないポッドでは、リクエストが過剰に割り当てられ、リソースが無駄になる可能性がある。

  7. top pod コマンドを実行して、コンテナ・レベルのメトリクスを確認する。

    kubectl top pod pod-a --containers -n appns
```sh
{: pre}

Example output
```sh
NAME           CONTAINER      CPU(cores)   MEMORY(bytes)
pod-a            app-container        100m         300Mi
pod-a            db-container           50m          200Mi
```sh
{: screen}

  8. kubectl top コマンドは実際の使用量を表示するだけで、要求されたリソースや制限されたリソースを表示するわけではない。 top コマンドの出力を比較・分析するには、以下のコマンドを使ってポッドの仕様をチェックする。

    kubectl describe pod <pod-name> -n <namespace>

    出力例

    Containers:
 app-container:
   Requests:
  cpu: 250m
  memory: 512Mi
  Limits:
  cpu: 500m
  memory: 1Gi

    CPUやメモリーの使用量がリクエストを上回っている場合、プロビジョニング不足を示す可能性があり、パフォーマンスの問題につながる。 使用量が限界に近い場合、コンテナはスロットルされるか、リソースが制約されたときに終了されるかもしれない。 使用量がリクエストより大幅に少ない場合、ポッドは過剰にプロビジョニングされ、リソースを浪費している可能性がある。

  9. どのポッドが最もCPUを消費しているかを特定する。

    kubectl top pod --all-namespaces | sort -k3 -nr | head -10

  10. メモリ消費量の多いポッドを特定する。

    kubectl top pod --all-namespaces | sort -k4 -nr | head -10

  11. システムデーモンのリソース使用量を監視する。 DaemonSets, kube-proxy 、あるいは監視エージェントなど、予期せぬリソースを消費することがある。

    kubectl top pod -n kube-system
```sh
{: pre}

  12. 特定のシステムポッドがCPUやメモリを過剰に消費する場合、チューニング要求や制限が必要になることがある。 リソースの変更を継続的に追跡するには、 watch。

    watch -n 5 kubectl top pod --all-namespaces
```sh
{: pre}

This command updates the output every 5 seconds, helping to spot spikes or anomalies in resource usage.

  13. OOMKilled。 Kubernetes が OOMKilled を報告すると、ポッドはメモリ制限を超えて終了した。 ポッドのステータスは crashloopbackoff に変わる。

    kubectl get events --field-selector involvedObject.name=your-pod-name -n your-namespace

  14. ログから OOM のメッセージを探す。

    kubectl logs your-pod-name -n your-namespace | grep -i "out of memory"

  15. OOM 、コンテナの最後の状態をチェックする。

    kubectl describe pod your-pod-name -n your-namespace | grep -A 10 "Last State"

ワーカーノードのログを収集する

ワーカーにアクセス し、ワーカーノードのログを収集する手順に従ってください。

  1. 以下のログファイルを収集し、保存する。 ワーカー・ノードの中断の考えられる原因 (メモリーまたはディスク・スペースの不足、ディスクの読み取り専用モードへの移行、その他の問題など) をログで確認します。

    • /var/log/containerd.log
    • /var/log/kern.log
    • /var/log/kube-proxy.log
    • /var/log/syslog
    • /var/log/kubelet.log

  2. 以下のコマンドを実行し、出力を保存してサポート・チケットに添付します。

    コンテナの統計情報を取得する（ノードへのSSHアクセスが必要）。

    crictl stats

    特定のコンテナの詳細な統計情報を取得する。

    crictl stats --id <container-id> --output json

    実行中のプロセスをダンプするコマンドを実行する。

    ps -aux

    実行中のプロセスやカーネルが管理するタスク、CPUやメモリの使用率などのリソースの使用状況を、動的かつリアルタイムに表示します。

    top

    現在のシステム状態を取得する。

    htop

    過去のデータを含む包括的なモニタリング・レポートを入手できます。

    atop

    システムプロセスに関するリアルタイムの情報を得る。

    btop

    ネットワーク接続の詳細を取得する。

    netstat

    ディスクの使用情報を取得する。

    df -H

    vmstat を実行して、プロセス、メモリ、ページング、ブロックIO、トラップ、CPUアクティビティに関するレポートを取得する。 このコマンドは2秒間隔で5回情報を取得する。

    vmstat 2 5

    iostat を実行して、スループット、利用率、キュー長、トランザクション・レートなどを網羅するディスク使用統計を収集する。

    iostat -x 1 5

    ハードウェア情報を収集する。

    lshw

    前回の再起動がグレースフルだったかどうかは、以下のコマンドで調べることができる。

    last -Fxn2 shutdown reboot

    ディスクの問題を除外するには、ディスクが書き込み可能であることを確認する。

    mount | grep -i "(ro"
touch /this

  3. 問題が解決しない場合は、 サポートチケットを開き、前のステップで保存したすべての出力を添付してください。