AWS EKS Support
EKS pods stuck Pending or in CrashLoopBackOff: causes and fixes.
Pending means the scheduler cannot place the pod or a dependency is not ready. CrashLoopBackOff means the container starts and exits repeatedly. They look similar in a dashboard but have different causes, and kubectl describe and logs usually show which within minutes.
When You Need This
The situations where this work pays for itself.
Signs it is time
- Pods sit in Pending and the deployment never reaches the desired replicas
- Pods restart repeatedly with CrashLoopBackOff
- Pods show ImagePullBackOff or ErrImagePull
- A new node group or Karpenter change broke scheduling
- Cluster autoscaling does not add nodes when pods are pending
What you get
- Root cause for each failing workload
- Corrected manifests or Helm values
- Right-sized requests and limits
- Alerts for pending pods and restart loops
How we do it
A clear, safe process you can follow along with.
1. Start with describe and events
kubectl describe pod and kubectl get events show the scheduler or kubelet message. For Pending, a FailedScheduling event lists the reason, such as 0/5 nodes are available: insufficient cpu, node(s) had untolerated taint, or didn't match Pod's node affinity/selector.
2. Diagnose Pending by cause
We check requests against node allocatable resources, taints and tolerations, nodeSelector and affinity, topology spread, and PVCs stuck unbound. An EBS-backed volume is zone-bound, so a pod can be unschedulable if no node exists in the volume's Availability Zone. On EKS, max pods per node and exhausted subnet IPs also leave pods Pending.
3. Check the autoscaler
If nodes should be added, we check Cluster Autoscaler or Karpenter logs, node group max size, instance type availability and quotas, and whether pods request more than the largest allowed node.
4. Diagnose CrashLoopBackOff
We read kubectl logs --previous for the crashed container and the last state in describe: exit code, reason and timestamps. Exit 137 with OOMKilled means the memory limit; exit 1 is an application error such as missing configuration, secrets or a failed dependency connection.
5. Check probes and configuration
A liveness probe that fires before the app is ready restarts a healthy container. We tune startup, readiness and liveness probes, and verify ConfigMaps, Secrets, environment variables and mounted volumes exist.
6. Diagnose image pull failures
ImagePullBackOff comes from a wrong tag, a missing imagePullSecret, node IAM role lacking ECR permissions, or no network path to the registry. We test pulling from a node.
7. Fix and verify
We apply the correct requests and limits, selectors or configuration through your deployment pipeline, watch the rollout complete, and add alerts on pending pods and container restarts.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Looking only at pod status
The reason is in events and previous logs, not in the status column.
Setting requests far above real use
Pods that request too much stay Pending while nodes sit idle.
Aggressive liveness probes
They turn slow starts into restart loops.
Ignoring zone-bound volumes
A PVC in one zone cannot be used by a pod scheduled in another.
Frequently Asked Questions
Why are my EKS pods stuck in Pending?
The scheduler cannot find a node that fits. Common reasons are insufficient CPU or memory, taints, selectors, unbound volumes, or no free pod IPs. The FailedScheduling event says which.
What does CrashLoopBackOff mean?
The container keeps starting and exiting, so Kubernetes waits longer between restarts. The cause is in the container logs from the previous run and the exit code.
How do I see logs of a crashed pod?
Run kubectl logs with the pod name and the --previous flag, and add -c for the container name in multi-container pods.
Want Help With EKS pods stuck Pending or in CrashLoopBackOff: causes and fixes?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required