Container Service for Kubernetes:ノード例外のトラブルシューティング

目次

診断手順

1. ノードが異常かどうかを確認します。 詳細については、このトピックの「ノードステータスの確認」セクションをご参照ください。

   • ノードがNotReady状態の場合、次の手順を実行して問題をトラブルシューティングします。

     1. PIDPressure、DiskPressure、MemoryPressureのノード条件の値がTrueかどうかを確認します。 ノード条件の1つがTrueの場合、ノード条件のキーワードに基づいて問題をトラブルシューティングします。 詳細については、このトピックの「dockerd exceptions - RuntimeOffline」、「不十分なメモリリソース-MemoryPressure」、または「不十分なinodes - InodesPressure」をご参照ください。

     2. ノードの主要コンポーネントとログを確認します。

        • kubelet

          1. kubeletのステータス、ログ、設定を確認します。 詳細については、このトピックの「ノードの主要コンポーネントの確認」をご参照ください。

          2. kubeletで例外が発生した場合は、例外のトラブルシューティングを行います。 詳細については、このトピックのkubelet例外セクションを参照してください。

        • dockerd

          1. dockerdのステータス、ログ、設定を確認します。 詳細については、このトピックの「ノードの主要コンポーネントの確認」をご参照ください。

          2. dockerdで例外が発生した場合は、例外のトラブルシューティングを行います。 詳細については、このトピックの「dockerd exceptions - RuntimeOffline」をご参照ください。

        • containerd

          1. containerdのステータス、ログ、設定を確認します。 詳細については、このトピックの「ノードの主要コンポーネントの確認」をご参照ください。

          2. containerdで例外が発生した場合は、例外のトラブルシューティングを行います。 詳細については、このトピックのcontainerd exceptions - RuntimeOfflineセクションを参照してください。

        • NTP

          1. Network Time Protocol (NTP) サービスのステータス、ログ、および設定を確認します。 詳細については、このトピックの「ノードの主要コンポーネントの確認」をご参照ください。

          2. NTPサービスで例外が発生した場合は、例外のトラブルシューティングを行います。 詳細については、このトピックの「NTP例外-NTPProblem」セクションをご参照ください。

     3. ノードの診断ログを確認します。 詳細については、このトピックの「ノードの診断ログの確認」をご参照ください。

     4. CPU、メモリ、ネットワークリソースの使用率など、ノードの監視データを確認します。 詳細については、このトピックの「ノードのモニタリングデータの確認」をご参照ください。 リソースの使用状況が異常な場合は、例外のトラブルシューティングを行います。 詳細については、このトピックの「CPUリソース不足」または「メモリリソース不足-MemoryPressure」をご参照ください。

   • ノードの状態が不明の場合は、次の手順を実行して問題をトラブルシューティングします。

     1. ノードをホストするElastic Compute Service (ECS) インスタンスが [実行中] 状態であるかどうかを確認します。

     2. ノードの主要コンポーネントを確認します。

        • kubelet

          1. kubeletのステータス、ログ、設定を確認します。 詳細については、このトピックの「ノードの主要コンポーネントの確認」をご参照ください。

          2. kubeletで例外が発生した場合は、例外のトラブルシューティングを行います。 詳細については、このトピックのkubelet例外セクションを参照してください。

        • dockerd

          1. dockerdのステータス、ログ、設定を確認します。 詳細については、このトピックの「ノードの主要コンポーネントの確認」をご参照ください。

          2. dockerdで例外が発生した場合は、例外のトラブルシューティングを行います。 詳細については、このトピックの「dockerd exceptions - RuntimeOffline」をご参照ください。

        • containerd

          1. containerdのステータス、ログ、設定を確認します。 詳細については、このトピックの「ノードの主要コンポーネントの確認」をご参照ください。

          2. containerdで例外が発生した場合は、例外のトラブルシューティングを行います。 詳細については、このトピックのcontainerd exceptions - RuntimeOfflineセクションを参照してください。

        • NTP

          1. NTPサービスのステータス、ログ、および設定を確認します。 詳細については、このトピックの「ノードの主要コンポーネントの確認」をご参照ください。

          2. NTPサービスで例外が発生した場合は、例外のトラブルシューティングを行います。 詳細については、このトピックの「NTP例外-NTPProblem」セクションをご参照ください。

     3. ノードのネットワーク接続を確認します。 詳細については、このトピックの「ノードのセキュリティグループの確認」をご参照ください。 ネットワーク例外が発生した場合は、例外のトラブルシューティングを行います。 詳細については、このトピックの「ネットワーク例外」セクションをご参照ください。

     4. ノードの診断ログを確認します。 詳細については、このトピックの「ノードの診断ログの確認」をご参照ください。

     5. CPU、メモリ、ネットワークリソースの使用率など、ノードの監視データを確認します。 詳細については、このトピックの「ノードのモニタリングデータの確認」をご参照ください。 リソースの使用状況が異常な場合は、例外のトラブルシューティングを行います。 詳細については、このトピックの「CPUリソース不足」または「メモリリソース不足-MemoryPressure」をご参照ください。

2. 上記の操作を実行しても問題が解決しない場合は、Container Service for Kubernetes (ACK) が提供する診断機能を使用して問題のトラブルシューティングを行います。 詳細については、「ノード例外のトラブルシューティング」をご参照ください。 このトピックのセクション

3. 問題が解決しない場合は、チケットを起票します。

一般的なトラブルシューティング方法

ノード例外のトラブルシューティング

ノードで例外が発生した場合、ACKが提供する診断機能を使用して例外のトラブルシューティングを行うことができます。

1. ACKコンソールにログインします。

2. ACKコンソールの左側のナビゲーションウィンドウで、[クラスター] をクリックします。

3. [クラスター] ページで、管理するクラスターを見つけ、クラスターの名前をクリックするか、[操作] 列の [詳細] をクリックします。 クラスターの詳細ページが表示されます。

4. 詳細ページの左側のナビゲーションウィンドウで、[ノード] > [ノード] を選択します。

5. On theノードページで、診断するノードを見つけて、例外診断で、アクション列を作成します。

6. On the診断ページで、診断レポートに基づいて問題をトラブルシューティングします。

ノードの詳細の確認

1. ACKコンソールにログインします。

2. ACKコンソールの左側のナビゲーションウィンドウで、[クラスター] をクリックします。

3. [クラスター] ページで、管理するクラスターを見つけ、クラスターの名前をクリックするか、[操作] 列の [詳細] をクリックします。 クラスターの詳細ページが表示されます。

4. 詳細ページの左側のナビゲーションウィンドウで、[ノード] > [ノード] を選択します。

5. ノードページで確認するノードを見つけ、ノードの名前をクリックするか、もっと > 詳細で、アクション列を作成します。

ノードステータスの確認

1. ACKコンソールにログインします。

2. ACKコンソールの左側のナビゲーションウィンドウで、[クラスター] をクリックします。

3. [クラスター] ページで、管理するクラスターを見つけ、クラスターの名前をクリックするか、[操作] 列の [詳細] をクリックします。 クラスターの詳細ページが表示されます。

4. 詳細ページの左側のナビゲーションウィンドウで、[ノード] > [ノード] を選択します。

5. ノードページで、各ノードのステータスを表示します。

   • ノードが [実行中] 状態の場合、ノードは期待どおりに実行されています。

   • ノードが [実行中] 状態でない場合、ノードの名前をクリックするか、ノードの [操作] 列で [詳細] > [詳細] を選択して、ノードの詳細を表示できます。

     説明

     InodesPressure、DockerOffline、RuntimeOfflineなどのノード条件に関する情報を収集する場合は、クラスターにnode-problem-detectorをインストールし、イベントセンターを作成する必要があります。 イベントセンター機能は、クラスターの作成時に自動的に有効になります。 詳細については、「イベントセンターの作成と使用」をご参照ください。

ノードイベントの確認

1. ACKコンソールにログインします。

2. ACKコンソールの左側のナビゲーションウィンドウで、[クラスター] をクリックします。

3. [クラスター] ページで、管理するクラスターを見つけ、クラスターの名前をクリックするか、[操作] 列の [詳細] をクリックします。 クラスターの詳細ページが表示されます。

4. 詳細ページの左側のナビゲーションウィンドウで、[ノード] > [ノード] を選択します。

5. ノードページで、イベントを確認するノードを見つけ、ノードの名前をクリックするか、アクション列もっと > 詳細を選択します。

   ノードの詳細ページの下部には、ノードに関連するイベントが表示されます。

ノードの診断ログの確認

• スクリプトを使用して診断ログを収集する。 詳細については、「」をご参照ください。ACKクラスターの診断データを収集するにはどうすればよいですか? 「クラスター管理に関するFAQ」トピックのセクション。

• コンソールを使用して診断ログを収集します。 詳細については、「ノードの診断ログの収集」をご参照ください。

ノードの主要コンポーネントの確認

• kubelet:

  • kubeletのステータスを確認する

    kubeletが実行されているノードにログインし、次のコマンドを実行してkubeletプロセスのステータスを照会します。

    systemctl status kubelet

    期待される出力:

    

  • kubeletのログを確認する

    kubeletが実行されているノードにログインし、次のコマンドを実行してkubeletのログを出力します。kubeletのログを確認する方法の詳細については、このトピックの「ノードの診断ログの確認」をご参照ください。

    journalctl -u kubelet

  • kubeletの設定を確認する

    kubeletが実行されているノードにログインし、次のコマンドを実行してkubeletの設定を確認します。

    cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

• Runtime:

  • チェックdockerd

    • dockerdのステータスを確認する

      dockerdが実行されているノードにログインし、次のコマンドを実行してdockerdプロセスのステータスを照会します。

      systemctl status docker

      期待される出力:

      

    • dockerdのログを確認する

      dockerdが実行されているノードにログインし、次のコマンドを実行してdockerdのログを印刷します。dockerdのログを確認する方法の詳細については、このトピックの「ノードの診断ログの確認」をご参照ください。

      journalctl -u docker

    • dockerdの設定を確認する

      dockerdが実行されているノードにログインし、次のコマンドを実行してdockerdの設定を照会します。

      cat /etc/docker/daemon.json

  • containerdをチェック

    • containerdのステータスを確認する

      containerdが実行されているノードにログインし、次のコマンドを実行してcontainerdプロセスのステータスを照会します。

      systemctl status containerd

      期待される出力:

      

    • containerdのログを確認する

      containerdが実行されているノードにログインし、次のコマンドを実行してcontainerdのログを印刷します。containerdのログを確認する方法の詳細については、このトピックの「ノードの診断ログの確認」をご参照ください。

      journalctl -u containerd

• NTP:

  • NTPサービスのステータスを確認する

    NTPサービスが実行されているノードにログインし、次のコマンドを実行してchronydプロセスのステータスを照会します。

    systemctl status chronyd

    期待される出力:

    

  • NTPサービスのログを確認する

    NTPサービスが実行されているノードにログインし、次のコマンドを実行してNTPサービスのログを出力します。

    journalctl -u chronyd

ノードのモニタリングデータの確認

• CloudMonitor

  ACKはCloudMonitorと統合されています。 CloudMonitorコンソールにログインして、ACKクラスターにデプロイされているECSインスタンスのモニタリングデータを表示できます。 ノードを監視する方法の詳細については、「ノードの監視」をご参照ください。

• Prometheusのマネージドサービス

  1. ACK コンソールにログインします。

  2. ACK コンソールの左側のナビゲーションウィンドウで、[クラスター] をクリックします。

  3. [クラスター] ページで、管理するクラスターを見つけます。 次に、クラスターの名前をクリックするか、[操作] 列の [詳細] をクリックします。

  4. クラスターの詳細ページの左側のナビゲーションウィンドウで、[操作] > [Prometheusモニタリング] を選択します。

  5. [Prometheusモニタリング] ページで、[ノードモニタリング] タブをクリックし、[ノード] タブをクリックします。 [ノード] タブで、ドロップダウンリストからノードを選択して、CPU、メモリ、ディスクリソースなどのノードのモニタリングデータを表示します。

ノードのセキュリティグループの確認

詳細については、「概要」および「クラスターのセキュリティグループの設定」をご参照ください。

kubelet例外

原因

ほとんどの場合、kubelet例外は、kubeletプロセスまたはランタイムで例外が発生するか、kubelet構成が無効なために発生します。

問題

kubeletのステータスが非アクティブです。

解決策

1. 次のコマンドを実行してkubeletを再起動します。 再起動操作は、実行中のコンテナには影響しません。

   systemctl restart kubelet

2. kubeletの再起動後、kubeletが実行されているノードにログインし、次のコマンドを実行してkubeletのステータスが正常かどうかを確認します。

   systemctl status kubelet

3. kubeletのステータスが異常の場合、ノードで次のコマンドを実行してkubeletのログを出力します。

   journalctl -u kubelet

   • kubeletログで例外が見つかった場合は、キーワードに基づいて例外のトラブルシューティングを行います。

   • kubelet設定が無効な場合は、次のコマンドを実行して設定を変更します。

     vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf   #Modify the configurations of kubelet. 
     systemctl daemon-reload;systemctl restart kubelet         #Reload the configurations and restart kubelet.

dockerd例外-RuntimeOffline

原因

ほとんどの場合、dockerdの設定が無効であるか、dockerdプロセスがオーバーロードされているか、ノードがオーバーロードされているため、dockerd例外が発生します。

問題

• dockerdのステータスが非アクティブです。

• dockerdのステータスはアクティブ (実行中) ですが、dockerdが期待どおりに実行されません。 その結果、ノードで例外が発生します。 この場合、docker psまたはdocker execコマンドの実行に失敗する可能性があります。

• ノード条件RuntimeOfflineの値はTrueです。

• クラスターノードのアラート機能を有効にした場合、dockerdが実行されているノードで例外が発生したときにアラートを受信できます。 アラートルールの設定方法の詳細については、「アラート管理」をご参照ください。

解決策

1. 次のコマンドを実行してdockerdを再起動します。

   systemctl restart docker

2. dockerdの再起動後、ノードにログインし、次のコマンドを実行して、dockerdのステータスが正常かどうかを確認します。

   systemctl status docker

3. dockerdのステータスが異常の場合は、ノードで次のコマンドを実行して、dockerdのログを印刷します。

   journalctl -u docker

containerd例外-RuntimeOffline

原因

ほとんどの場合、containerd構成が無効であるか、containerdプロセスがオーバーロードされているか、ノードがオーバーロードされているため、containerd例外が発生します。

• containerdのステータスが非アクティブです。

• ノード条件RuntimeOfflineの値はTrueです。

• クラスターノードのアラート機能を有効にした場合、containerdが実行されているノードで例外が発生したときにアラートを受信できます。 アラートルールの設定方法の詳細については、「アラート管理」をご参照ください。

解決策

1. 次のコマンドを実行してcontainerdを再起動します。

   systemctl restart containerd

2. containerdの再起動後、ノードにログインし、次のコマンドを実行してcontainerdのステータスが正常かどうかを確認します。

   systemctl status containerd

3. containerdのステータスが異常の場合は、ノードで次のコマンドを実行して、containerdのログを出力します。

   journalctl -u containerd

NTP例外-NTPProblem

原因

ほとんどの場合、NTPプロセスのステータスが異常であるため、NTP例外が発生します。

問題

• chronydのステータスは非アクティブです。

• ノード条件NTPProblemの値はTrueです。

• クラスターノードのアラート機能を有効にした場合、NTPサービスが実行されているノードで例外が発生したときにアラートを受信できます。 アラートルールの設定方法の詳細については、「アラート管理」をご参照ください。

解決策

1. 次のコマンドを実行してchronydを再起動します。

   systemctl restart chronyd

2. chronydの再起動後、ノードにログインし、次のコマンドを実行して、chronydのステータスが正常かどうかを確認します。

   systemctl status chronyd

3. chronydのステータスが異常の場合は、ノードで次のコマンドを実行して、chronydのログを出力します。

   journalctl -u chronyd

PLEG例外-PLEGは健康ではありません

原因

ポッドライフサイクルイベントジェネレーター (PLEG) は、コンテナーの起動や終了に関連するイベントなど、ポッドのライフサイクル全体で発生するすべてのイベントを記録します。 ほとんどの場合、ノードのコンテナランタイムが異常であるか、ノードが以前のsystemdバージョンを使用しているため、PLEG is not healthy例外が発生します。

問題

• ノードのステータスはNotReadyです。

• kubeletのログには次の内容があります。

  I0729 11:20:59.245243 9575 kubelet.go:1823] ポッド同期のスキップ-PLEGは正常ではありません。プレグは3m57.138893648s前に最後にアクティブになりました。しきい値は3m0sです。

• クラスターノードのアラート機能を有効にした場合、PLEG例外が発生したときにアラートを受信できます。 アラートルールの設定方法の詳細については、「アラート管理」をご参照ください。

解決策

1. ノード上の次の主要コンポーネント、dockerd、containerd、kubeletを順番に再起動します。 次に、ノードのステータスが正常かどうかを確認します。

2. 主要コンポーネントを再起動した後、ノードのステータスが異常な場合は、ノードを再起動します。 詳細については、「インスタンスの再起動」をご参照ください。

   警告

   再起動操作では、ノード上のポッドも再起動します。 作業は慎重に行ってください。

3. 異常なノードがCentOS 7.6を実行している場合は、を参照して例外のトラブルシューティングを行います。 kubeletのログに "Reason:KubeletNotReady Message:PLEG is not healthy:" エラーが含まれている場合、CentOS 7.6が使用されている場合はどうすればよいですか。

スケジューリングに不十分なノードリソース

原因

ほとんどの場合、この例外は、クラスタ内のノードによって提供されるリソースが十分であるために発生します。

問題

ポッドによって要求されたリソースの量が、ノードによって提供される割り当て可能なリソースの総量とノードから割り当てられたリソースの量との間の差よりも大きい場合、ポッドはノードにスケジュールされない。

kubectl describe node [$nodeName]

Allocatable:
  cpu:                3900m
  ephemeral-storage:  114022843818
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             12601Mi
  pods:               60
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests    Limits
  --------           --------    ------
  cpu                725m (18%)  6600m (169%)
  memory             977Mi (7%)  16640Mi (132%)
  ephemeral-storage  0 (0%)      0 (0%)
  hugepages-1Gi      0 (0%)      0 (0%)
  hugepages-2Mi      0 (0%)      0 (0%)

解決策

ノードが提供するリソースが不足している場合は、次のいずれかの方法でノードの負荷を軽減できます。

• 不要になったポッドを削除します。 詳細については、「ポッドの管理」をご参照ください。

• ビジネス要件に基づいて、ポッドのリソース構成を変更します。 詳細については、「ポッドの管理」トピックの「ポッドのCPUおよびメモリリソースの上限と下限の変更」をご参照ください。

  リソースプロファイリング機能は、リソース使用の履歴データに基づいて、コンテナに関するリソース仕様の推奨を提供することができる。 これにより、リソース要求の設定とコンテナの制限が大幅に簡素化されます。 詳細については、「リソースプロファイリング」をご参照ください。

• クラスターにノードを追加します。 詳細については、「ノードプールの作成」をご参照ください。

• クラスター内のノードをアップグレードします。 詳細については、「ワーカーノードの設定のアップグレード」をご参照ください。

詳細については、このトピックの「CPUリソース不足」、「メモリリソース不足-MemoryPressure」、および「ディスク容量不足-DiskPressure」をご参照ください。

CPUリソース不足

原因

ほとんどの場合、ノード上のコンテナが過剰な量のCPUリソースを占有しているため、ノードによって提供されるCPUリソースが不足します。

問題

• ノードに十分なCPUリソースがない場合、ノードの状態が異常になることがあります。

• クラスターノードのアラート機能を有効にした場合、ノードのCPU使用率が85% 以上になったときにアラートを受信できます。 アラートルールの設定方法の詳細については、「アラート管理」をご参照ください。

解決策

• コンソールの [ノード監視] タブでCPU使用率曲線を確認し、CPU使用率が急上昇した時点を特定します。 次に、ノードで実行されるプロセスが過剰なCPUリソースを占有しているかどうかを確認します。 詳細については、このトピックの「ノードのモニタリングデータの確認」をご参照ください。

• ノードの負荷を減らす方法の詳細については、このトピックの「スケジューリングに不十分なノードリソース」をご参照ください。

• ノードを再起動します。 詳細は、「インスタンスの再起動」をご参照ください。

  警告

  再起動操作では、ノード上のポッドも再起動します。 作業は慎重に行ってください。

メモリリソース不足-MemoryPressure

原因

ほとんどの場合、ノード上のコンテナが過剰な量のメモリリソースを占有しているため、ノードによって提供されるメモリリソースが不十分になります。

問題

• ノードで使用可能なメモリリソースの量がmemory.availableしきい値を下回ると、ノード条件MemoryPressureの値がTrueに変わります。 コンテナはノードから追い出されます。 コンテナーの削除の詳細については、 ノード圧力回避。

• ノードに十分なメモリリソースがない場合、次の問題が発生します。

  • ノード条件MemoryPressureの値がTrueに変わります。

  • コンテナはノードから追い出されます。

    • the node was low on resource: memory情報は、追い出されたコンテナのイベントに含まれています。

    • ノードが発生した場合、メモリの再利用情報を見つけることができます。

  • メモリ不足 (OOM) エラーが発生する可能性があります。 OOMエラーが発生した場合、ノードのイベントでシステムOOM情報を見つけることができます。

• クラスターノードのアラート機能を有効にした場合、ノードのメモリ使用量が85% 以上になったときにアラートを受信できます。 アラートルールの設定方法の詳細については、「アラート管理」をご参照ください。

解決策

• コンソールの [ノード監視] タブでメモリ使用量曲線を確認し、メモリ使用量が急増した時点を特定します。 次に、ノードで実行されているプロセスでメモリリークが発生していないかを確認します。 詳細については、このトピックの「ノードのモニタリングデータの確認」をご参照ください。

• ノードの負荷を減らす方法の詳細については、このトピックの「スケジューリングに不十分なノードリソース」をご参照ください。

• ノードを再起動します。 詳細は、「インスタンスの再起動」をご参照ください。

  警告

  再起動操作では、ノード上のポッドも再起動します。 作業は慎重に行ってください。

不十分なinodes - InodesPressure

原因

ほとんどの場合、ノード上のコンテナが過剰な数のinodeを占有しているため、ノードによって提供されるinodeが不十分になります。

問題

• ノードで使用可能なinodeの数がinodesFreeしきい値を下回ると、ノード条件InodesPressureの値がTrueに変わります。 コンテナはノードから追い出されます。 コンテナーの削除の詳細については、 ノード圧力回避。

• ノードによって提供されるinodeが不十分になると、次の問題が発生します。

  • ノード条件InodesPressureの値がTrueに変わります。

  • コンテナはノードから追い出されます。

    • the node was low on resource: inodesの情報は、追い出されたコンテナのイベントにあります。

    • ノードのイベントでは、inodeを再利用しようとしている情報を見つけることができます。

• クラスターノードのアラート機能を有効にした場合、ノードに十分なinodeがない場合にアラートを受信できます。 アラートルールの設定方法の詳細については、「アラート管理」をご参照ください。

解決策

• コンソールの [ノード監視] タブでinode使用率曲線を確認し、inode使用率が急上昇した時点を特定します。 次に、ノードで実行されるプロセスが過剰な数のinodeを占有しているかどうかを確認します。 詳細については、このトピックの「ノードのモニタリングデータの確認」をご参照ください。

• その他の問題のトラブルシューティング方法の詳細については、「Linuxインスタンスのディスク容量不足の問題の解決」をご参照ください。

不十分なPID-NodePIDPressure

原因

ほとんどの場合、ノード上のコンテナが過剰な数のPIDを占有しているため、ノードによって提供されるプロセスID (PID) が不十分になる。

問題

• ノード上の利用可能なpidの数がpid.availableしきい値を下回ると、ノード条件NodePIDPressureの値はTrueに変わります。 コンテナはノードから追い出されます。 コンテナーの削除の詳細については、 ノード圧力回避。

• クラスターノードのアラート機能を有効にした場合、ノードに十分なPIDがない場合にアラートを受信できます。 アラートルールの設定方法の詳細については、「アラート管理」をご参照ください。

解決策

1. 次のコマンドを実行して、PIDの最大数とノードの最大PID値を照会します。

   sysctl kernel.pid_max  #Query the maximum number of PIDs. 
   ps -eLf|awk '{print $2}' | sort -rn| head -n 1   #Query the greatest PID value.

2. 次のコマンドを実行して、PIDの数が最も多い上位5つのプロセスを照会します。

   ps -elT | awk '{print $4}' | sort | uniq -c | sort -k1 -g | tail -5

   期待される出力:

   #The first column displays the numbers of PIDs that are occupied by the processes. The second column displays the IDs of the processes. 
   73 9743
   75 9316
   76 2812
   77 5726
   93 5691

3. プロセスIDを使用して、対応するプロセスとポッドを見つけ、問題を診断し、コードを最適化できます。

4. ノードの負荷を減らします。 詳細については、このトピックの「スケジューリングに不十分なノードリソース」をご参照ください。

5. ノードを再起動します。 詳細については、「インスタンスの再起動」をご参照ください。

   警告

   再起動操作では、ノード上のポッドも再起動します。 作業は慎重に行ってください。

ディスク容量不足-DiskPressure

原因

ほとんどの場合、ノード上のコンテナが過剰な量のディスク空間を占有しているか、コンテナイメージのサイズが過剰に大きいため、ノードによって提供されるディスク空間が不十分になります。

問題

• ノードの使用可能なディスク容量がimagefs.availableしきい値を下回ると、ノード条件DiskPressureの値がTrueに変わります。

• 使用可能なディスク領域の量がnodefs.availableしきい値を下回ると、ノード上のすべてのコンテナが追い出されます。 コンテナーの削除の詳細については、 ノード圧力回避。

• ノードのディスク容量が不足すると、次の問題が発生します。

  • ノード条件DiskPressureの値がTrueに変わります。

  • イメージ再利用ポリシーがトリガーされた後も、使用可能なディスク領域の量がヘルスしきい値を下回っている場合は、ノードのイベントでfailed to garbage collect required amount of imagesの情報を見つけることができます。 ヘルスしきい値のデフォルト値は80% です。

  • コンテナはノードから追い出されます。

    • the node was low on resource: [DiskPressure] の情報は、追い出されたコンテナのイベントにあります。

    • ノードのイベントでは、[ephemeral-storageを再利用しようとしている] または [nodefsを再利用しようとしている] の情報を見つけることができます。

• クラスターノードのアラート機能を有効にした場合、そのノードのディスク使用量が85% に達したとき、またはそれを超えたときにアラートを受け取ることができます。 アラートルールの設定方法の詳細については、「アラート管理」をご参照ください。

解決策

• コンソールの [ノード監視] タブでディスク使用率曲線を確認し、ディスク使用率が急上昇した時点を特定します。 次に、ノードで実行されるプロセスが過剰なディスク容量を占有しているかどうかを確認します。 詳細については、このトピックの「ノードのモニタリングデータの確認」をご参照ください。

• 大量のファイルがディスク容量を占有している場合は, 不要になったファイルを削除してください。 詳細については、「Linuxインスタンスのディスク容量不足の問題の解決」をご参照ください。

• ノード上のポッドに割り当てられている一時ストレージを制限します。 詳細については、「ポッドの管理」トピックの「ポッドのCPUおよびメモリリソースの上限と下限の変更」をご参照ください。

• Alibaba Cloudが提供するストレージサービスを使用し、hostPathボリュームを使用しないことを推奨します。 詳細については、「CSIの概要」をご参照ください。

• ノードのディスクのサイズを変更します。

• ノードの負荷を減らします。 詳細については、このトピックの「スケジューリングに不十分なノードリソース」をご参照ください。

不十分なIPアドレス-InvalidVSwitchId.IpNotEnough

原因

ほとんどの場合、ノード上のコンテナが過剰な数のIPアドレスを占有しているため、ノードによって提供されるIPアドレスが不十分になります。

問題

• ポッドを起動できません。 これらのポッドのステータスはContainerCreatingです。 ポッドのログにInvalidVSwitchId.IpNotEnough情報があります。 ポッドのログを確認する方法の詳細については、「ポッドのトラブルシューティング」トピックの「ポッドのログの確認」セクションをご参照ください。

  time="2020-03-17T07:03:40Z" level=warning msg="Assign private ip address failed: Aliyun API Error: RequestId: 2095E971-E473-4BA0-853F-0C41CF52651D Status Code: 403 Code: InvalidVSwitchId.IpNotEnough Message: The specified VSwitch \"vsw-AAA\" has not enough IpAddress., retrying"

• クラスターノードのアラート機能を有効にした場合、ノードが十分なIPアドレスを提供できない場合にアラートを受信できます。 アラートルールの設定方法の詳細については、「アラート管理」をご参照ください。

解決策

ノード上のコンテナの数を減らします。 詳細については、このトピックの「スケジューリングに不十分なノードリソース」をご参照ください。 その他の関連操作の詳細については、 Terwayを使用するクラスターでvSwitchが提供するIPアドレスが不十分な場合はどうすればよいですか? とTerwayモードでvSwitchを追加した後、新しく作成されたポッドのIPアドレスがvSwitch CIDRブロックに含まれない場合はどうすればよいですか?

ネットワーク例外

原因

ほとんどの場合、ノードのステータスが異常であるか、ノードのセキュリティグループの設定が無効であるか、ネットワークが過負荷になっているため、ネットワーク例外が発生します。

問題

• ノードへのログインに失敗しました。

• ノードのステータスは不明です。

• クラスターノードのアラート機能を有効にした場合、ノードのアウトバウンドインターネット帯域幅使用量が85% 以上になったときにアラートを受信できます。 アラートルールの設定方法の詳細については、「アラート管理」をご参照ください。

解決策

• ノードへのログインに失敗した場合は、次の手順を実行して問題をトラブルシューティングします。

  • ノードの状態が実行中かどうかを確認します。

  • ノードのセキュリティグループの設定を確認します。 詳細については、このトピックの「ノードのセキュリティグループの確認」をご参照ください。

• ノードのネットワークが過負荷になっている場合は、次の手順を実行して問題をトラブルシューティングします。

  • コンソールの [ノード監視] タブでノードのネットワークパフォーマンス曲線を確認し、帯域幅使用量の急上昇を探します。 詳細については、このトピックの「ノードのモニタリングデータの確認」をご参照ください。

  • ネットワークポリシーを使用してポッドトラフィックを抑制します。 詳細については、「ACKクラスターでのネットワークポリシーの使用」をご参照ください。

予期しないノードの再起動

原因

ほとんどの場合、ノードが過負荷になっているため、ノードが予期せず再起動します。

問題

• ノードの再起動プロセス中、ノードのステータスはNotReadyです。

• クラスターノードのアラート機能を有効にした場合、ノードが予期せず再起動したときにアラートを受信できます。 アラートルールの設定方法の詳細については、「アラート管理」をご参照ください。

解決策

1. 次のコマンドを実行して、ノードが再起動した時点を照会します。

   last reboot

   期待される出力:

2. ノードのモニタリングデータを確認し、ノードが再起動した時点に基づいて異常なリソース使用量をトラブルシューティングします。 詳細については、このトピックの「ノードのモニタリングデータの確認」をご参照ください。

3. ノードのカーネルログを確認し、ノードが再起動された時点に基づいて例外をトラブルシューティングします。 詳細については、このトピックの「ノードの診断ログの確認」をご参照ください。

auditプロセスのディスクI/O使用率が高い、またはシステムログに次のエラーメッセージが表示されるという問題を解決するにはどうすればよいですか。

原因

クラスター内の一部の既存ノードは、デフォルトでauditd for Dockerの監査ルールで設定されています。 ノードがDockerを実行している場合、システムはauditdの監査ルールに基づいてDockerの監査ログを生成します。 多数のコンテナが同時に繰り返し再起動したり、コンテナに大量のデータが書き込まれたり、カーネルバグが発生したりすると、多数の監査ログが生成されることがあります。 このような場合、auditdプロセスのディスクI/O使用率が高く、システムログにaudit: backlog limit exceededというエラーメッセージが表示されることがあります。

問題

この問題は、Dockerを実行するノードにのみ影響します。 ノードで特定のコマンドを実行した後、次の状況が発生します。

• iotop -o -d 1コマンドを実行すると、結果はDISK WRITEの値が1メガバイト/秒以上のままであることを示します。

• dmesg -dコマンドを実行すると、audit_printk_skbというキーワードを含むログが結果に含まれます。 例: audit_printk_skb: 100コールバックの抑制

• dmesg -dコマンドを実行すると、audit: backlog limit exceededというキーワードが表示されます。

解決策

次の操作を実行して、上記の問題がauditdの監査ルールによって発生しているかどうかを確認します。

1. ノードにログインします。

2. 次のコマンドを実行してauditdルールを照会します。

   sudo auditctl -l | grep -- ' -k docker'

   次の出力が返された場合、前述の問題はauditdの監査ルールによって発生します。

   -w /var/lib/docker -k docker

この問題を解決するには、次のいずれかのソリューションを使用します。

• クラスターのKubernetesバージョンの更新

  クラスターのKubernetesバージョンを後のメジャーバージョンに更新します。 詳細については、「手動でACKクラスターをアップグレード」をご参照ください。

• コンテナーランタイムをcontainerdに変更

  クラスターのKubernetesバージョンを更新できない場合は、コンテナランタイムをcontainerdに変更して、この問題を回避できます。 Dockerをコンテナランタイムとして使用するノードプールで次の操作を実行します。

  1. Dockerを実行するノードプールのクローンを作成して、新しいノードプールを作成します。 新しいノードプールは、containerdをコンテナランタイムとして使用します。 新しいノードプールの設定が、コンテナランタイムを除いて、クローンされたノードプールの設定と同じであることを確認します。

  2. すべてのアプリケーションポッドがノードプールから追い出されるまで、オフピーク時にDockerを実行するノードプールからノードを1つずつ排出します。

• auditdの設定の更新

  上記のソリューションが適用されない場合は、ノードのauditdの設定を手動で更新して、この問題を解決できます。 Dockerをコンテナーランタイムとして使用するノードで次の操作を実行します。

  説明

  ノードをバッチで管理できます。 詳細については、「ノードのバッチ管理」をご参照ください。

  1. ノードにログインします。

  2. 次のコマンドを実行して、Dockerのauditdルールを削除します。

     sudo test -f /etc/audit/rules.d/audit.rules && sudo sed -i.bak '/ -k docker/d' /etc/audit/rules.d/audit.rules
     sudo test -f /etc/audit/audit.rules && sudo sed -i.bak '/ -k docker/d' /etc/audit/audit.rules

  3. 次のコマンドを実行して、新しいauditdルールを適用します。

     if service auditd status |grep running || systemctl status auditd |grep running; then
         sudo service auditd restart || sudo systemctl restart auditd
         sudo service auditd status || sudo systemctl status auditd
     fi