KubernetesのPodがPendingのままになる原因｜FailedScheduling・Node・PVC
KubernetesでPodがPendingのまま変わらないとき、ノードへスケジュールできない問題と、配置後のコンテナ準備の問題を分けて調査するガイドです。
この記事の目的
PodのConditionsとEventsから、リソース・Node制約・ストレージ・イメージ取得のどれが原因か絞ります。
まず確認すること
kubectl describe podでPodScheduled条件とEventsを確認し、FailedSchedulingの有無を調べます。
app・APP・POD_NAMEなどは説明用です。作業前にcontext・namespace・対象オブジェクトを照合してください。関連ガイド
Kubernetes基本操作
context・namespaceを確認し、kubectlでPod・Eventsを調査します。
ガイドへ →KubernetesCrashLoopBackOff
終了コード・直前ログ・probe・OOMの原因を切り分けます。
ガイドへ →KubernetesImagePullBackOff
イメージ名・タグ・pull Secret・レジストリ通信を確認します。
ガイドへ →1. Pendingが意味する範囲
PendingはPodが受け付けられてから、すべてのコンテナが正常に開始できるまでの段階を含みます。まだNodeに配置されていない場合だけでなく、配置後のイメージ取得・Volume準備などで止まる場合もあります。
kubectlの一覧に表示されるステータスと、Podのstatus.phaseは同じ意味とは限らないので、詳細情報を確認します。
2. まずkubectlで状態を集める
kubectl describe podのEventsからFailedSchedulingが出ていればscheduler側の理由を調べます。PodScheduled=TrueでNode名がある場合はImagePull・Mount・ContainerCreatingなど別の準備段階を疑います。
3. FailedSchedulingの理由別に分ける
| イベント例 | 想定される領域 | 次の確認 |
|---|---|---|
| Insufficient cpu | PodのCPU requestsとNode allocatable | Pod要求量・各Node割当可能量 |
| Insufficient memory | PodのメモリrequestsとNode allocatable | 実測使用率ではなくschedulerの要求量 |
| untolerated taint | Node taintとPod tolerations | 隔離ポリシーを理解して合わせる |
| didn't match Pod's node affinity/selector | nodeSelector・affinity・ラベル | Pod側制約とNodeラベル |
| unbound immediate PersistentVolumeClaims | PVC・StorageClass・Provisioner | PVCの状態とvolumeBindingMode |
| Node not ready | Node条件・メンテナンス状態 | Node可用性と運用状況 |
4. Node・requests・affinityの調査
NodeのAllocated resourcesはPodのrequests/limitsに基づく情報であり、瞬間的なCPU・メモリ使用率とは異なります。kubectl topが使えなくても、schedulerのEventsやNode定義から確認できます。
Forbiddenを確認し、必要な情報を権限を持つ担当者へ依頼します。5. PVCがPendingになっているとき
PVCの容量・StorageClass・accessModes・Provisioner・Storage容量を確認します。WaitForFirstConsumerはPodの配置とvolumeバインドを連動させるため、PVCだけがPendingという理由で即異常とは断定できません。
6. Nodeへ配置済みだがPendingの場合
PodScheduled=Trueでもコンテナの作成・マウント・イメージ取得が進まないことがあります。ErrImagePull等の理由が出ていれば、CPU不足ではなくImagePullBackOff・認証/通信の切り分けへ進みます。Volumeのマウント失敗ならPod Eventsやkubelet側情報を確認します。
7. Pendingの原因別対処・変更前チェック
想定例（実測ではありません）：0/3 nodes are available: 3 Insufficient cpu はNodeの現在使用率だけではなく、Podのrequestsと割当可能量・予約済み要求量の確認が必要な状態です。まずPodScheduled・配置Node・FailedScheduling Eventsを照合します。
| 確認結果・想定イベント | 次に取る具体的な行動 |
|---|---|
Insufficient cpu / Insufficient memory | Pod requests、Node allocatable/Allocated resources、他Podの予約を比較。要求量が過大なら根拠を確認し管理元で見直すか、運用者へ容量拡張を依頼。原因確認前にrequestsを削らない |
untolerated taint | Nodeのtaint目的とPodのtolerationsを照合。隔離ポリシーを侵さない範囲でスケジューリング設計を調整。Node側のtaintを安易に除去しない |
didn't match node affinity/selector | Pod側のnodeSelector/affinityとNodeラベルを照合し、管理元の正しい配置制約を修正。ラベルを無条件に変更しない |
unbound immediate PersistentVolumeClaims | PVC、StorageClass、provisioner、容量、accessModesを確認。WaitForFirstConsumerならPod配置との連動を踏まえ判断。PVC/PVは削除しない |
PodScheduled=True / FailedMount / ContainerCreating | スケジューリングは完了している可能性。volumeマウントのEvents、Node状態とkubelet・CSI側エラーを担当者へ調査依頼 |
ErrImagePull | リソース不足として処理せず、レジストリ・認証・通信の調査へ進む |
変更前：context・Namespace・対象ワークロード・可用性要件、変更前の管理済みマニフェスト、リソース制約とストレージ保護方針を確認し、運用承認を得ます。完了条件：PodScheduled、Pod Ready、再発する警告がないこと、業務通信の正常性を確認します。改善しない場合はscheduler Events、Node割当量、PVC/CSIの状態と変更履歴を管理担当へ引き継ぎます。Kubernetes公式 — Podのデバッグ。
8. 修正後の確認
スケジューリングが解消しただけではアプリが正常とは限りません。PodのReady状態・コンテナログ・依存サービスへの接続を確認します。起動後にCrashLoopBackOffになるならCrashLoopBackOffの専用調査へ切り替えます。