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

ノード条件のクイックリファレンス

以下の表は、各ノード条件に対応するトリガー、典型的なノード状態、重大度、および関連するトラブルシューティングセクションを一覧化しています。

「InodesPressure」、「DockerOffline」、「RuntimeOffline」、「NTPProblem」などのノード条件を収集するには、クラスターに node-problem-detector をインストールし、イベントセンターを作成してください。イベントセンターは、クラスター作成時に自動的に有効化されます。詳細については、「イベントセンターの作成と使用方法」をご参照ください。

診断手順

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

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

kubelet

kubelet が実行されているノード上で、以下のコマンドを実行します。

ステータスの確認：

systemctl status kubelet

期待される出力：

ログの確認：

journalctl -u kubelet

構成の確認：

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

dockerd

dockerd が実行されているノード上で、以下のコマンドを実行します。

ステータスの確認：

systemctl status docker

期待される出力：

ログの確認：

journalctl -u docker

構成の確認：

cat /etc/docker/daemon.json

containerd

containerd が実行されているノード上で、以下のコマンドを実行します。

ステータスの確認：

systemctl status containerd

期待される出力：

ログの確認：

journalctl -u containerd

NTP

NTP サービスが実行されているノード上で、以下のコマンドを実行します。

ステータスの確認：

systemctl status chronyd

期待される出力：

ログの確認：

journalctl -u chronyd

kubectl describe node <node-name>

Conditions:
  Type                 Status  Reason                       Message
  ----                 ------  ------                       -------
  MemoryPressure       False   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure         False   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure          False   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready                True    KubeletReady                 kubelet is posting ready status

kubelet の例外

原因： kubelet の例外は、通常、kubelet プロセス自体、コンテナランタイム、または無効な kubelet 構成に起因します。

症状： kubelet サービスのステータスが inactive です。

解決方法：

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

   systemctl restart kubelet

2. kubelet が正常に動作しているかどうかを確認します：

   systemctl status kubelet

3. ステータスが依然として異常な場合は、ログを確認します：

   • ログに例外が表示された場合、エラーメッセージに基づいてトラブルシューティングを行います。

   • 構成が無効な場合は、編集して再読み込みします：bash vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf systemctl daemon-reload; systemctl restart kubelet

   journalctl -u kubelet

dockerd の例外 - RuntimeOffline

原因： 多くの場合、dockerd の例外は、dockerd 構成が無効である、dockerd プロセスが過負荷である、またはノードが過負荷であるために発生します。

症状：

• dockerd サービスのステータスが inactive です。

• dockerd サービスのステータスが active (running) ですが、dockerd が正しく機能していません（例： docker ps や docker exec コマンドが失敗する）。

• ノード条件 RuntimeOffline が True です。

• クラスターノードのアラート機能を有効化している場合、dockerd の例外が発生するとアラートが通知されます。「アラート管理」を参照して、アラートルールを設定してください。

解決方法：

1. dockerd を再起動します：

   systemctl restart docker

2. dockerd が正常に動作しているかどうかを確認します：

   systemctl status docker

3. ステータスが依然として異常な場合は、ログを確認します：

   journalctl -u docker

containerd の例外 - RuntimeOffline

原因： 多くの場合、containerd の例外は、containerd 構成が無効である、containerd プロセスが過負荷である、またはノードが過負荷であるために発生します。

症状：

• containerd サービスのステータスが inactive です。

• ノード条件 RuntimeOffline が True です。

• クラスターノードのアラート機能を有効化している場合、containerd の例外が発生するとアラートが通知されます。「アラート管理」を参照して、アラートルールを設定してください。

解決方法：

1. containerd を再起動します：

   systemctl restart containerd

2. containerd が正常に動作しているかどうかを確認します：

   systemctl status containerd

3. ステータスが依然として異常な場合は、ログを確認します：

   journalctl -u containerd

NTP の例外 - NTPProblem

原因： 多くの場合、NTP の例外は、NTP プロセスのステータスが異常であるために発生します。

症状：

• chronyd サービスのステータスが inactive です。

• ノード条件 NTPProblem が True です。

• クラスターノードのアラート機能を有効化している場合、NTP の例外が発生するとアラートが通知されます。「アラート管理」を参照して、アラートルールを設定してください。

解決方法：

1. chronyd を再起動します：

   systemctl restart chronyd

2. chronyd が正常に動作しているかどうかを確認します：

   systemctl status chronyd

3. ステータスが依然として異常な場合は、ログを確認します：

   journalctl -u chronyd

PLEG の例外 - PLEG is not healthy

原因： Pod Lifecycle Event Generator (PLEG) は、コンテナの起動や終了など、Pod のライフサイクル全体にわたってイベントを記録します。PLEG is not healthy の例外は、通常、ノード上のコンテナランタイムが異常であるか、ノードで古い systemd バージョンが使用されている場合に発生します。

症状：

• ノードの状態が NotReady です。

• kubelet のログに以下が含まれています：

  I0729 11:20:59.245243    9575 kubelet.go:1823] skipping pod synchronization - PLEG is not healthy: pleg was last seen active 3m57.138893648s ago; threshold is 3m0s.

• クラスターノードのアラート機能を有効化している場合、PLEG の例外が発生するとアラートが通知されます。「アラート管理」を参照して、アラートルールを設定してください。

解決方法：

以下の手順を、最小限の影響から最大限の影響へと順に試してください：

1. まず dockerd または containerd、次に kubelet の順で、主要コンポーネントを再起動します。ノードが回復するかどうかを確認します。

2. ノードが依然として健全でない場合は、ノードインスタンス全体を再起動します。「インスタンスの再起動」をご参照ください。

   警告

   ノードの再起動は、そのノード上で実行中のすべての Pod も再起動します。慎重に実行してください。

3. ノードが CentOS 7.6 を実行している場合、「CentOS 7.6 を使用している場合に、kubelet のログに「Reason:KubeletNotReady Message:PLEG is not healthy:」というエラーが表示されたときの対処方法」をご参照ください。

スケジューリングのためのノードリソース不足

原因： クラスター内のノードに、新しい Pod をスケジュールするのに十分なリソースがありません。

症状：

以下のエラーのいずれかが表示され、Pod のスケジューリングが失敗します：

• 0/2 nodes are available: 2 Insufficient cpu

• 0/2 nodes are available: 2 Insufficient memory

• 0/2 nodes are available: 2 Insufficient ephemeral-storage

スケジューラは、以下の条件を満たす場合にリソースを「不足」と判断します：

• CPU： Pod の要求 CPU ＞ （ノードの割り当て可能 CPU − ノードで既に割り当て済みの CPU）

• メモリ： Pod の要求メモリ ＞ （ノードの割り当て可能メモリ − ノードで既に割り当て済みのメモリ）

• 一時的ストレージ： Pod の要求一時的ストレージ ＞ （ノードの割り当て可能一時的ストレージ − ノードで既に割り当て済みの一時的ストレージ）

ノード上のリソース割り当てを表示するには、以下のコマンドを実行します：

kubectl describe node <node-name>

期待される出力：

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%)

• Allocatable：ノード上でスケジューリング可能なリソースの総量。

• Allocated resources：スケジュール済みの Pod によってすでに確保されたリソースの量。

解決方法：

ノードの負荷を軽減するには、以下のいずれかの方法を使用します：

• 不要になった Pod を削除します。「Pod の管理」をご参照ください。

• Pod のリソース要求および制限を調整します。「Pod の CPU およびメモリリソースの上限および下限の変更」をご参照ください。過去の使用履歴に基づいた適切なサイズの推奨事項については、「リソースプロファイリング」をご参照ください。

• クラスターにノードを追加します。「ノードプールの作成および管理」をご参照ください。

• ノードのスペックをアップグレードします。「ワーカーノードの構成のアップグレードまたはダウングレード」をご参照ください。

CPU リソース不足

原因： 多くの場合、ノードの CPU リソースが不足するのは、コンテナが過剰な CPU を消費しているためです。

症状：

• ノードのステータスが異常になります。

• クラスターノードのアラート機能を有効化している場合、CPU 使用率が 85 % に達した場合またはそれを超えた場合にアラートが通知されます。「アラート管理」を参照して、アラートルールを設定してください。

解決方法：

1. コンソールの Node Monitoring タブで、CPU 使用率の曲線を確認し、使用率が急増したタイミングを特定します。ノード上のプロセスで、過剰な CPU を消費しているものがないかを確認します。

2. ノードの負荷を軽減します。「スケジューリングのためのノードリソース不足」をご参照ください。

3. 問題が継続する場合は、ノードを再起動します。「インスタンスの再起動」をご参照ください。

   警告

   ノードの再起動は、そのノード上で実行中のすべての Pod も再起動します。慎重に実行してください。

メモリリソース不足 - MemoryPressure

原因： 多くの場合、ノードのメモリリソースが不足するのは、コンテナが過剰なメモリを消費しているためです。

症状：

• 使用可能なメモリが memory.available のしきい値を下回ると、ノード条件 MemoryPressure が True に変わり、コンテナエビクションが発生します。「Node-pressure Eviction」をご参照ください。

• エビクションされたコンテナには、The node was low on resource: memory というイベントが表示されます。

• ノードには、attempting to reclaim memory というイベントが表示されます。

• メモリ不足（OOM）エラーが発生する可能性があります。OOM が発生した場合、ノードには System OOM というイベントが表示されます。

• クラスターノードのアラート機能を有効化している場合、メモリ使用率が 85 % に達した場合またはそれを超えた場合にアラートが通知されます。「アラート管理」を参照して、アラートルールを設定してください。

解決方法：

1. コンソールの Node Monitoring タブで、メモリ使用率の曲線を確認し、使用率が急増したタイミングを特定します。ノード上のプロセスで、メモリリークが発生していないかを確認します。

2. ノードの負荷を軽減します。「スケジューリングのためのノードリソース不足」をご参照ください。

3. 問題が継続する場合は、ノードを再起動します。「インスタンスの再起動」をご参照ください。

   警告

   ノードの再起動は、そのノード上で実行中のすべての Pod も再起動します。慎重に実行してください。

inode 数不足 - InodesPressure

原因： 多くの場合、ノードの inode 数が不足するのは、コンテナが過剰な数の inode を消費しているためです。

症状：

• 使用可能な inode 数が inodesFree のしきい値を下回ると、ノード条件 InodesPressure が True に変わり、コンテナエビクションが発生します。「Node-pressure Eviction」をご参照ください。

• エビクションされたコンテナには、The node was low on resource: inodes というイベントが表示されます。

• ノードには、attempting to reclaim inodes というイベントが表示されます。

• クラスターノードのアラート機能を有効化している場合、inode 使用率が不足した場合にアラートが通知されます。「アラート管理」を参照して、アラートルールを設定してください。

解決方法：

1. コンソールの Node Monitoring タブで、inode 使用率の曲線を確認し、使用率が急増したタイミングを特定します。ノード上のプロセスで、過剰な inode を消費しているものがないかを確認します。

2. その他の修復手順については、「Linux インスタンスのディスク領域不足の問題を解決する方法」をご参照ください。

PID 数不足 - NodePIDPressure

原因： 多くの場合、ノードのプロセス ID（PID）数が不足するのは、コンテナが過剰な数の PID を消費しているためです。

症状：

• 使用可能な PID 数が pid.available のしきい値を下回ると、ノード条件 NodePIDPressure が True に変わり、コンテナエビクションが発生します。「Node-pressure Eviction」をご参照ください。

• クラスターノードのアラート機能を有効化している場合、PID リソースが不足した場合にアラートが通知されます。「アラート管理」を参照して、アラートルールを設定してください。

解決方法：

1. 最大 PID 制限および現在の最高 PID 値を照会します：

   sysctl kernel.pid_max
   ps -eLf | awk '{print $2}' | sort -rn | head -n 1

2. PID 数の上位 5 つのプロセスを特定します：

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

   期待される出力（列 1：PID 数、列 2：プロセス ID）：

   73 9743
   75 9316
   76 2812
   77 5726
   93 5691

3. プロセス ID を使用して、対応するプロセスおよび Pod を特定し、根本原因を診断してコードを最適化します。

4. ノードの負荷を軽減します。「スケジューリングのためのノードリソース不足」をご参照ください。

5. 問題が継続する場合は、ノードを再起動します。「インスタンスの再起動」をご参照ください。

   警告

   ノードの再起動は、そのノード上で実行中のすべての Pod も再起動します。慎重に実行してください。

ディスク領域不足 - DiskPressure

原因： 多くの場合、ノードのディスク領域が不足するのは、コンテナが過剰なディスク領域を消費しているか、コンテナイメージが大きすぎるためです。

症状：

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

• 使用可能なディスクが nodefs.available のしきい値を下回った場合、ノード上のすべてのコンテナがエビクションされます。「Node-pressure Eviction」をご参照ください。

• イメージのガーベジコレクション後に、ディスク領域が健全性しきい値（デフォルト：80 %）を下回り続けている場合、ノードには failed to garbage collect required amount of images というイベントが表示されます。

• エビクションされたコンテナには、The node was low on resource: [DiskPressure] というイベントが表示されます。

• ノードには、attempting to reclaim ephemeral-storage または attempting to reclaim nodefs というイベントが表示されます。

• クラスターノードのアラート機能を有効化している場合、ディスク使用率が 85 % に達した場合またはそれを超えた場合にアラートが通知されます。「アラート管理」を参照して、アラートルールを設定してください。

解決方法：

1. コンソールの Node Monitoring タブで、ディスク使用率の曲線を確認し、使用率が急増したタイミングを特定します。ノード上のプロセスで、過剰なディスク領域を消費しているものがないかを確認します。

2. 不要になったファイルを削除します。「Linux インスタンスのディスク領域不足の問題を解決する方法」をご参照ください。

3. Pod に対して ephemeral-storage 制限を設定して、ディスク使用量を制限します。「Pod の CPU およびメモリリソースの上限および下限の変更」をご参照ください。

4. hostPath ボリュームの代わりに、Alibaba Cloud のストレージサービスを使用します。「ストレージ」をご参照ください。

5. ノードのディスクをリサイズします。

6. ノードの負荷を軽減します。「スケジューリングのためのノードリソース不足」をご参照ください。

IP アドレス不足 - InvalidVSwitchId.IpNotEnough

原因： 多くの場合、IP アドレスが不足するのは、コンテナが vSwitch から過剰な数の IP アドレスを消費しているためです。

症状：

• Pod が起動できず、ContainerCreating 状態のままになります。Pod のログには以下が含まれます：

  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 固有の IP アドレスの問題については、以下の記事をご参照ください：

• Terway を使用するクラスターで vSwitch が提供する IP アドレスが不足した場合の対処方法

• Terway モードで vSwitch を追加した後、新しく作成された Pod の IP アドレスが vSwitch CIDR ブロック内に収まらない場合の対処方法

ネットワーク例外

原因： 多くの場合、ネットワーク例外は、ノードの状態が異常である、セキュリティグループの構成が無効である、またはネットワークが過負荷であるために発生します。

症状：

• ノードにログインできません。

• ノードの状態が Unknown です。

• クラスターノードのアラート機能を有効化している場合、アウトバウンドインターネット帯域幅使用率が 85 % に達した場合またはそれを超えた場合にアラートが通知されます。「アラート管理」を参照して、アラートルールを設定してください。

解決方法：

ノードにログインできない場合：

1. ノードが Running 状態であるかどうかを確認します。

2. セキュリティグループの構成を確認します。「セキュリティグループの確認」をご参照ください。

ネットワークが過負荷の場合：

1. コンソールの Node Monitoring タブで、ネットワークパフォーマンスの曲線を確認し、帯域幅使用量の急増を探します。

2. Pod トラフィックを制御するために、ネットワークポリシーを適用します。「ACK クラスターでのネットワークポリシーの使用方法」をご参照ください。

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

原因： 多くの場合、ノードが予期せず再起動するのは、ノードが過負荷であるためです。

症状：

• 再起動中にノードの状態が NotReady になります。

• クラスターノードのアラート機能を有効化している場合、ノードが予期せず再起動した場合にアラートが通知されます。「アラート管理」を参照して、アラートルールを設定してください。

解決方法：

1. ノードが再起動したタイミングを特定します：

   last reboot

   期待される出力：

   

2. そのタイミング付近のノードモニタリングデータを確認し、異常なリソース使用量を特定します。「モニタリングデータの確認」をご参照ください。

3. そのタイミング付近のノードカーネルログを確認します。「診断ログの収集」をご参照ください。

auditd による高いディスク I/O またはシステムログ内の「audit: backlog limit exceeded」

原因： クラスター内の既存のノードの一部は、デフォルトで Docker 用の auditd の監査ルールが設定されています。コンテナが頻繁に再起動する、コンテナへの大量のデータ書き込みが発生する、またはカーネルのバグが発生する場合、監査ログの書き込み量が急増し、auditd プロセスのディスク I/O が高くなるとともに、システムログに audit: backlog limit exceeded というエラーが表示されます。

この問題は、Docker を実行しているノード（containerd を実行しているノードは除く）にのみ影響します。

症状：

• iotop -o -d 1 の出力で、DISK WRITE が一貫して 1 MB/s 以上であることが確認できます。

• dmesg -d の出力に audit_printk_skb: 100 callbacks suppressed が含まれています。

• dmesg -d の出力に audit: backlog limit exceeded が含まれています。

原因の確認：

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

2. 問題が auditd Docker ルールによって引き起こされているかどうかを確認します：

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

   出力に -w /var/lib/docker -k docker が含まれている場合、問題は auditd ルールによって引き起こされています。

解決方法：

以下のいずれかの方法を、優先順位の高い順に使用します：

クラスターのアップグレード

クラスターの Kubernetes バージョンをアップグレードします。「クラスターの手動アップグレード」をご参照ください。

コンテナランタイムを containerd に切り替える

アップグレードが不可能な場合、Docker ノードプールから containerd へのノードプールの移行を行います：

1. 既存の Docker ノードプールを複製して、新しいノードプールを作成します。新しいノードプールのコンテナランタイムを containerd に設定し、その他の設定はすべて同一に保ちます。

2. トラフィックが少ない時間帯に、Docker ノードプールからノードを 1 つずつドレインし、すべてのアプリケーションポッドが containerd ノードプール上で実行されるようにします。

auditd 構成を手動で更新する

上記のいずれも適用できない場合、Docker 用の auditd ルールを削除します：

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

2. 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. 更新されたルールを適用します：

   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