AWS manages the EKS control plane: the etcd cluster, API server, scheduler, and controller manager. It patches and replaces unhealthy control-plane nodes, scales the control plane, and runs it for high availability across Availability Zones. None of that stops a Deployment from getting stuck at 3 of 5 replicas at 2 a.m. while an on-call engineer stares at a dashboard with no idea what to do next.
EKS removes one category of operational toil: operating the Kubernetes control plane. It does not remove the need to understand how Kubernetes schedules workloads, routes traffic, or applies resource requests and limits.
What EKS manages—and what it doesn’t#
AWS runs and secures the EKS control plane. You do not SSH into control-plane nodes, operate etcd yourself, or debug a split-brain failure in the cluster’s key-value store.
Your workloads still run on the data plane. In a conventional EKS setup, that includes your worker nodes, Pods, workload configuration, node groups, VPC and CNI configuration, and IAM setup for workloads. AWS supplies and operates underlying cloud infrastructure, but you remain responsible for defining, configuring, observing, and troubleshooting your applications and their Kubernetes resources. The precise boundary changes if you use options such as EKS Auto Mode, Fargate, or AWS-managed add-ons.
A stuck Deployment still needs Kubernetes knowledge#
Suppose a Deployment update stalls at 3 of 5 replicas. The first move is the same on EKS, GKE, or a self-managed cluster:
kubectl describe pod <pod-name> -n <namespace>The Events section might show:
0/5 nodes are available: 5 Insufficient cpu.That means the scheduler cannot find a node with enough requested CPU for the Pod. Kubernetes schedules based on declared resource requests, not on whether a dashboard suggests that current CPU usage is low. AWS cannot infer your intended capacity or rewrite your Pod specifications for you.
A rollout can also stall because replacement Pods never become Ready, images cannot be pulled, an admission policy rejects a Pod, a quota is exhausted, or the Deployment’s maxUnavailable and maxSurge settings constrain progress.
A PodDisruptionBudget is different: it primarily limits voluntary evictions, such as those used when draining a node. It does not ordinarily govern the Deployment controller’s own rolling-update behavior.
CrashLoopBackOff is not the cause#
CrashLoopBackOff describes Kubernetes backing off after a container repeatedly terminates. It tells you the container is failing; it does not explain why.
Start with the logs from the previous container instance:
kubectl logs <pod-name> -n <namespace> --previousThe --previous flag matters because the newly restarted container may not yet have emitted useful logs. Then inspect the container’s termination reason and exit code in kubectl describe pod.
Exit code 137 often appears when a container was OOM-killed, but the code alone only indicates a SIGKILL. Confirm that the termination reason is OOMKilled before treating it as a memory-limit problem. Exit codes such as 1 and 2 commonly signal application-level errors, but their exact meaning depends on the application.
The EKS-specific networking trap#
EKS adds AWS-specific networking constraints that make Kubernetes fundamentals more—not less—important. With the Amazon VPC CNI’s typical IPv4 configuration, Pods receive IP addresses from VPC networking resources associated with worker-node ENIs. Node instance types have limits on ENIs and addresses per ENI, while subnets have finite available IP space.
If capacity is exhausted, Pods can remain in ContainerCreating and report an error such as:
Failed to assign an IP address to containerThe underlying constraint might be node-level ENI/IP capacity, depleted subnet addresses, or a CNI configuration issue. The response is not simply “restart the Pod.” Check the affected Pod’s events, VPC CNI (aws-node) logs and metrics, and available addresses in the relevant subnets.
Depending on the cause, the fix may include choosing node types with greater network capacity, adding or enlarging subnets, tuning the CNI warm-IP settings, or enabling prefix delegation. Prefix delegation can substantially increase per-node address capacity, but it requires suitable contiguous address space in the subnet.
EKS does not eliminate networking concepts you need to understand. It applies them through AWS’s VPC, ENI, subnet, and IAM model.
Recommended Reading#
- AWS Certified Solutions Architect Study Guide: Associate SAA-C03 Exam, 4th Edition by Ben Piper & David Clinton
- AWS Certified Cloud Practitioner Study Guide: CLF-C01 Exam by Ben Piper & David Clinton
- The Kubernetes Book