Container Service for Kubernetes:ポッドのトラブルシューティング

エラーメッセージ

説明

推奨ソリューション

ポッドをスケジュールするノードがありません。

クラスターには、ポッドスケジューリングに使用できるノードがありません。

1. クラスター内のノードがNotReady状態であるかどうかを確認します。 ノードがNotReady状態の場合は、そのノードのトラブルシューティングと修復を行います。

2. ノードセレクタ、ノードアフィニティルール、またはテイント許容範囲がポッドに設定されているかどうかを確認します。 ポッドにアフィニティルールが設定されていない場合は、ノードプール内のノード数を増やします。

• 0/xノードが使用可能です: x不十分なcpu。

• 0/xノードが使用可能です: xメモリ不足。

クラスターには、ポッドのCPUまたはメモリ要求を実行できるノードがありません。

[ノード] ページで、ポッド、CPU、およびメモリ使用率を表示し、クラスターリソース使用率を確認します。

クラスタ内のCPUまたはメモリリソースが使い果たされた場合、次の方法を使用します。

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

• ポッドのリソース構成を変更します。 詳細については、「ポッドのCPUおよびメモリリソースの上限と下限の変更」をご参照ください。 リソースプロファイリングを有効にして、コンテナーの推奨リソースリクエストと制限を取得します。

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

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

• xノードがノードセレクターと一致しませんでした。

• xノードは、ポッドのアフィニティ /アンチアフィニティと一致しませんでした。

クラスターには、ポッドのノードアフィニティルール (nodeSelector) またはアフィニティとアンチアフィニティルール (podAffinityおよびpodAnitiAffinity) に一致するノードがありません。

1. ノードラベル、nodeSelector、nodeAffinity、taints、tolerationsなど、ポッドのノードアフィニティルールを確認して変更します。

2. ポッドのポッドアフィニティルールを確認して変更します。 ノードがポッドアフィニティ規則に一致できるかどうかを評価します。 podAffinityが設定されている場合は、目的のノードのpodAffinityに一致するポッドを確認します。 podAntiAffinityが設定されている場合は、目的のノードでpodAntiAffinityと一致するポッドを確認します。

0/xノードが利用可能である: xノードは、ボリュームノードアフィニティ競合を有する。

ディスクボリュームをゾーン間でマウントできないため、ポッドで使用されるボリュームでノードアフィニティの競合が発生します。 その結果、ポッドのスケジュールに失敗しました。

• ポッドが静的にプロビジョニングされた永続ボリューム (PV) を使用し、PVのゾーン内のノードにポッドをスケジュールする場合は、ポッドのノードアフィニティ規則を設定する必要があります。

• ポッドが動的にプロビジョニングされたPVを使用する場合、ディスクボリュームのStorageClassのvolumeBindingModeをWaitForFirstConsumerに設定する必要があります。 この方法では、ポッドがノードにスケジュールされた後にのみボリュームが作成されます。 これにより、ポッドをホストするノードのゾーンにボリュームが確実に存在します。

InvalidInstanceType.NotSupportDiskCategory

ディスクタイプはElastic Compute Service (ECS) インスタンスでサポートされていません。

「インスタンスファミリーの概要」を参照し、ECSインスタンスでサポートされているディスクタイプを確認します。 ECSインスタンスでサポートされているディスクをポッドにマウントします。

0/xノードが使用可能です: xノードには、ポッドが許容しなかった汚染がありました。

ノードにtaintがあるため、ポッドを目的のノードにスケジュールできませんでした。

• テイントが手動で追加された場合は、テイントを削除します。 テイントを保持する必要がある場合は、ポッドに許容範囲を追加できます。 詳細については、「テイントと許容範囲」および「テイントの管理」をご参照ください。

• システムによってテイントが追加された場合は、次のソリューションを参照し、スケジューラがポッドのスケジュールを変更するのを待ちます。

  システムによって追加されたテイントの表示

  • node.kubernetes.io/not-ready: ノードはNotReady状態です。

  • node.kubernetes.io/unreachable: ノードコントローラーがノードへのアクセスに失敗しました。 ノードのReadyフィールドの値はUnknownです。

  • node.kubernetes.io/memory-pressure: ノードに十分なメモリリソースがありません。

  • node.kubernetes.io/disk-pressure: ノードに十分なディスク容量がありません。

  • node.kubernetes.io/pid-pressure: ノードに十分なプロセスID (pid) がありません。

  • node.kubernetes.io/network-unavailable: ノードのネットワークが利用できません。

  • node.kubernetes.io/unschedulable: ノードはUnschedulable状態です。

0/xノードが使用可能です: xエフェメラルストレージが不十分です。

ノードに十分な一時的なストレージスペースがありません。

1. ポッドYAMLファイルのspec.containers.resources.request.ephemeral-storageで指定されているエフェメラルボリュームに制限があるかどうかを確認します。 値がノードの一時的なストレージ容量を超える場合、ポッドのスケジュールに失敗しました。

2. kubectl describe node | grep -A10 Capacityコマンドを実行して、すべてのノードの一時的なストレージ容量の合計を表示します。 ストレージ容量が要件を満たしていない場合は、ノードのディスクを拡張するか、ノードを追加します。

0/xノードが利用可能です: ポッドにバインド解除されたPersistentVolumeClaimesがあります。

永続ボリューム要求 (PVC) がポッドにバインドできませんでした。

ポッドに指定されたPVCまたはPVが作成されているかどうかを確認します。 kubectl describe pvc <pvc-name> またはkubectl describe pv <pv-name> コマンドを実行して、PVCまたはPVのイベントを表示できます。 詳細については、「」をご参照ください。ポッドに対して「0/xノードが利用可能: x pod has unbound immediate PersistentVolumeClaims」イベントが生成されるのはなぜですか?

エラーメッセージ

説明

推奨ソリューション

ポッドはInit:N/M状態のままです。

ポッドにはM個のInitコンテナが含まれています。 N個のコンテナが開始されました。 M-N Initコンテナーが開始されていません。

1. kubectl describe pod -n <ns> <pod name> コマンドを実行して、ポッドのイベントを表示します。 開始していないInitコンテナで異常が発生しないことを確認します。

2. kubectl logs -n <ns> <pod name> -c <container name> コマンドを実行して、ポッドで開始されていないInitコンテナのログを表示し、ログデータに基づいてエラーをトラブルシューティングします。

3. ポッド構成のInitコンテナー構成にヘルスチェック構成などのエラーが含まれているかどうかを確認します。

initコンテナーの詳細については、「initコンテナーのデバッグ」をご参照ください。

ポッドはInit:Error状態のままです。

ポッド内のInitコンテナーの起動に失敗しました。

ポッドはInit:CrashLoopBackOff状態のままです。

ポッド内のInitコンテナーの起動に失敗し、繰り返し再起動しました。

エラーメッセージ

説明

推奨ソリューション

範囲0の割り当てに失敗しました: 範囲セットで使用可能なIPアドレスがありません: xx.xxx.xx.xx-xx.xx.xx.xx

このエラーは、Flannelネットワークプラグインの設計が原因で予想されます。

フランネルをv0.15.1.11-7e95fe23-aliyun以降に更新します。 詳細については、「フランネル」をご参照ください。

クラスターが1.20より前のバージョンのKubernetesを実行し、ポッドが繰り返し再起動するか、CronJobによって作成されたポッドがタスクを完了し、短時間で終了すると、IPリークが発生する可能性があります。

クラスターのKubernetesバージョンを1.20以降に更新します。 最新バージョンに更新することを推奨します。 詳細については、「手動でACKクラスターをアップグレード」をご参照ください。

containerdとrunCには欠陥があります。

詳細については、「」をご参照ください。ポッドの起動に失敗し、「範囲内で使用可能なIPアドレスはありません」というエラーメッセージが表示された場合はどうすればよいですか?

エラー解析設定、can't found dev by mac 00:16:3e:01:c2:e8: not found

Terwayによって維持され、ポッドのノードでelastic network Interface (ENI) を追跡および管理するために使用される内部データベースのステータスが、実際のネットワークデバイス構成と一致していません。 その結果、ENIの割り当てに失敗した。

1. ENIは非同期にロードされます。 CNIを設定すると、システムはまだENIをロードしている可能性があります。 これにより、CNIはENIの割り当てを再試行できます。 これは最終的なENI割り当て結果には影響しません。 ポッドの最終状態に基づいて、操作が成功したかどうかを判断できます。

2. ポッドの作成に長時間失敗し、前述のエラーがスローされた場合、高レベルメモリが不足しているため、ENIのアタッチ中にドライバをロードできませんでした。 この問題に対処するには、対応するECSインスタンスを再起動します。 詳細は、「インスタンスの再起動」をご参照ください。

• cmdAdd: エラーalloc ip rpcエラー: code = DeadlineExceeded desc=コンテキストの期限を超えました

• cmdAdd: error alloc ip rpc error: code = Unknown desc = error wait pod eni info, timed out waiting for the condition

TerwayはvSwitchからIPアドレスを要求できませんでした。

1. ポッドをホストするノードでTerwayポッドのコンテナログを表示し、ENIの割り当てプロセスを確認します。

2. kubectl logs -n kube-system <terwayPodName > -c terway | grep <podName> コマンドを実行し、TerwayポッドのENI情報を表示します。 IPアドレスを要求するために実行される操作の要求IDと、APIによって返されるエラーメッセージを取得します。

3. リクエストIDとエラーメッセージに基づいて原因を特定します。

エラーメッセージ

説明

推奨ソリューション

ログにexit (0) が表示されます。

1. 異常なワークロードがデプロイされているノードにログインします。

2. docker ps -a | grep $podNameコマンドを実行します。 ポッドに永続プロセスが存在しない場合、exit (0) が表示されます。

イベント情報には、Liveness probe failed: Get http… が表示されます。

ヘルスチェックに失敗しました。

ポッドのlivenessプローブポリシーを確認します。 livenessプローブの結果が、ポッドのコンテナーで実行されているアプリケーションの実際のステータスを示すことができることを確認します。

ポッドログには左スペースなしが表示されます。

ディスク容量が不足しています。

• 手順1: ディスクのサイズを変更してディスクの容量を拡張するを参照してください。

• 未使用のイメージを削除してディスク領域を解放し、imageGCHighThresholdPercentを設定して、ノードでイメージガベージコレクションをトリガーするためのしきい値を調整します。

ポッドの起動に失敗し、イベントが生成されません

ポッドのリソース制限は、ポッドによって要求されたリソースよりも低くなっています。 その結果、ポッド内のコンテナは起動できませんでした。

ポッドのリソース設定を確認します。 リソースプロファイリングを有効にして、推奨リソースリクエストとリソース制限を取得できます。

ポッドログに [アドレスは既に使用中] が表示されます。

ポッド内のコンテナがポート競合に遭遇します。

1. hostNetwork: trueがポッドに設定されているかどうかを確認します。 存在する場合、ポッド内のコンテナはホストとENIとポートを共有します。 ホストネットワークを使用しない場合は、hostNetwork: falseを指定します。

2. hostNetwork: trueが設定されている場合、同じレプリカセットのポッドが同じノードにスケジュールされないように、ポッドアンチアフィニティ規則を設定します。

3. 同じポートを使用するポッドが同じノードにスケジュールされていないことを確認してください。

ポッドログには、container init caused \"setenv: invalid argument\": unknownが表示されます。

ワークロードはシークレットでマウントされます。 Secretのキー値はBase64を使用してエンコードされません。

• コンソールで作成されたSecretsのキー値は、Base64を使用して自動的にエンコードされます。 詳細については、「シークレットの管理」をご参照ください。

• YAMLを使用してシークレットを作成し、echo -n "xxxxx" | base64コマンドを実行して、base64を使用してキー値を暗号化します。

ビジネス上の問題が存在します。

ポッドログに基づいて原因を特定します。

OOMレベル

説明

推奨ソリューション

OSレベル

ポッドをホストするノードのカーネルログ (/var/log/messages) には、killedプロセスが表示されますが、cgroupログは生成されません。 これは、OOMエラーがOSレベルであることを意味します。

考えられる原因は、メモリ断片化中のシステムグローバルメモリ不足、ノードメモリ不足、またはバディシステムメモリ不足です。 メモリ不足の原因の詳細については、「考えられる原因」をご参照ください。 ソリューションの詳細については、「ソリューション」をご参照ください。

cgroupレベル

ポッドをホストするノードのカーネルログ (/var/log/messages) には、次のようなエラーメッセージが表示されます。Task in /kubepods.slice/xxxxx kill after of limit of /kubepods.slice/xxxx これは、OOMエラーがcgroupレベルであることを意味します。

プロセスが通常どおりに実行される場合は、それに応じてポッドのメモリ制限を増やします。 ポッドの実際のメモリ使用量がメモリ制限の80% を超えないようにしてください。 詳細については、「ポッドのCPUおよびメモリリソースの上限と下限の変更」をご参照ください。 リソースプロファイリングを有効にして、コンテナーの推奨リソースリクエストとリソース制限を取得できます。

考えられる原因

説明

推奨ソリューション

ノードが異常で、NotReady状態です。

NotReadyノードは、回復後に自動的に削除されます。

ファイナライザーはポッド用に設定されています。

ポッドにファイナライザーが設定されている場合、Kubernetesはポッドを削除する前にファイナライザーによって指定されたクリーンアップ操作を実行します。 クリーンアップ操作に対して応答が返されない場合、ポッドは終了状態のままです。

kubectl get pod -n <ns> <pod name> -o yamlコマンドを実行して、ポッドのファイナライザー設定を表示し、原因を特定します。

ポッドのpreStopフックが無効です。

preStopフックがポッドに設定されている場合、Kubernetesはポッドを終了する前にpreStopフックで指定された操作を実行します。 ポッドはpreStop段階にあり、終了状態になります。

kubectl get pod -n <ns> <pod name> -o yamlコマンドを実行して、ポッドのpreStop設定を表示し、原因を特定します。

ポッドは、グレースフルシャットダウン期間で設定されています。

ポッドにグレースフルシャットダウン期間 (terminationGracePeriodSeconds) が設定されている場合、kubectl delete pod <pod_name> などの終了コマンドを受信すると、ポッドは終了状態になります。 Kubernetesは、グレースフルシャットダウン期間 (terminationGracePeriodSeconds) が終了した後にポッドが終了するか、グレースフルシャットダウン期間が終了する前にポッド内のすべてのコンテナが終了すると見なします。

コンテナーが正常に終了すると、Kubernetesはポッドを削除します。

コンテナは応答しません。

ポッドを終了または削除するリクエストを開始すると、KubernetesはSIGTERMシグナルをポッド内のコンテナーに送信します。 コンテナがSIGTERM信号に応答しない場合、ポッドは終了状態のままになります。

1. kubectl delete pod <pod-name> -- grace-period=0 -- forceコマンドを実行して、ポッドを強制的に削除します。

2. ポッドをホストするノードのcontainerdまたはDockerログを確認し、原因を特定します。

考えられる原因

説明

推奨ソリューション

ノードにメモリやディスク領域のリソースなどの十分なリソースがありません。 その結果、kubeletはノード上の1つ以上のポッドを追い出し、リソースを再利用します。

ノードに十分なメモリ、ディスク容量、またはPIDがない場合があります。 kubectl describe node <node name> | grep Taintsコマンドを実行して、ノードテイントを照会します。

• メモリ不足: ノードにnode.kubernetes.io/memory-pressureテイントがあります。

• ディスク容量が不足: ノードにnode.kubernetes.io/disk-pressureテイントがあります。

• pidが不十分: ノードにnode.kubernetes.io/pid-pressureのテイントがあります。

• メモリ不足:

  • ポッドのリソース設定を調整します。 詳細については、「ポッドの管理」をご参照ください。

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

• ディスク容量不足:

  • ノード上のアプリケーションポッドのログを定期的に削除します。

  • ノードのディスクを展開します。 詳細については、「手順1: ディスクのサイズを変更してディスクの容量を拡張する」をご参照ください。

• PIDが不十分: ポッドのリソース設定を変更します。 詳細については、「プロセスIDの制限と予約」をご参照ください。

予期しない立ち退きが発生します。

ポッドをホストするノードにNoExecute taintがあります。 その結果、予期しない追い出しが起こる。

kubectl describe node <node name> | grep Taintsコマンドを実行し、ノードにNoExecuteテイントがあるかどうかを確認します。 はいの場合、テイントを削除します。

ポッドは予想どおりに追い出されません。

• -- pod-eviction-timeout: ポッドの削除タイムアウト期間。 ノードのダウンタイムが指定されたタイムアウト期間を超えると、ポッドはノードから追い出されます。 デフォルトのタイムアウト時間は5分です。

• -- node-eviction-rate: 1秒あたりに追い出されるポッドの数。 デフォルトは0.1です。つまり、10秒ごとにノードから少なくとも1つのポッドが削除されます。

• -- secondary-node-eviction-rate: セカンダリポッドの削除率。 過剰な数のノードがダウンしている場合、ポッドの削除はセカンダリレートに調整されます。 デフォルト値は0.01です。

• -- unhealthy-zone-threshold: 不健全なゾーンのしきい値。 デフォルト値は0.55です。 失敗したノードの数がノードの総数の55% を超えると、ゾーンは異常と見なされます。

• -- large-cluster-size-threshold: 大きいクラスターのしきい値。 デフォルト値は50です。 クラスターノードの数が50を超えると、クラスターは大規模クラスターと見なされます。

50ノード以下の小さなクラスターでは、55% を超えるノードがダウンしている場合、ポッドの削除が停止されます。 詳細については、「立ち退きのレート制限」をご参照ください。

50を超えるノードを含む大規模なクラスターでは、異常なノードとノードの合計の比率が -- unhealthy-zone-thresholdの値を超える場合 (デフォルトは0.55) 、削除率は -- secondary-node-eviction-rateの値に設定されます。 このパラメータは、1分あたりに追い出されるポッドの最大割合を指定します。 デフォルト値は0.01です。 詳細については、「立ち退きのレート制限」をご参照ください。

ポッドは、追い出された後も、元のノードに頻繁にスケジュールされます。

ポッドは、ノードのリソース使用量に基づいてノードから追い出される。 ポッドスケジューリングルールは、ノードに割り当てられたリソースに依存します。 追い出されたポッドは、元のノードに再びスケジュールされ得る。

ノードの割り当て可能なリソースに基づいて、ポッドのリソース要求が適切に構成されているかどうかを確認します。 詳細については、「ポッドのCPUおよびメモリリソースの上限と下限の変更」をご参照ください。 リソースプロファイリングを有効にして、コンテナーの推奨リソースリクエストとリソース制限を取得できます。