EKS Auto Mode hands node provisioning, core add-ons, load balancing and block storage to AWS. We moved two clusters from managed node groups and self-managed Karpenter. What Auto Mode manages, what changes for operators, the limits that surprised us, and the migration steps that kept workloads running.
Terraform created our new EKS cluster cleanly, then nobody could use it: kubectl said we must be logged in, and the Helm step in CI failed the same way. The cluster had API-only authentication, no creator admin, and access entries for the wrong role ARNs.
Our managed node group upgrade stalled for two hours on one node. A PodDisruptionBudget with minAvailable equal to the replica count meant no pod could ever be evicted. We switched to maxUnavailable, fixed replica counts and added a pre-upgrade PDB check.
A partial outage in one AWS availability zone took down our search API completely, although it ran three replicas on a three-zone cluster. The scheduler had placed all three in the same zone. How the default spreading works, why it was not enough, and the topologySpreadConstraints we now require.
A routine rollout left 14 Pods Pending with Insufficient cpu while dashboards showed nodes at 30 percent CPU. The scheduler counts requests, not usage, and a new tainted node pool hid the free capacity. Here is how we read the FailedScheduling message and fixed it.
We moved twelve services from IRSA to EKS Pod Identity to simplify IAM. Three of them started failing with AccessDenied or fell back to the node role. Causes: a missing agent add-on on one node group, an old AWS SDK that did not know the new credential provider, and a trust policy without sts:TagSession.
After a node group replacement, a Redis StatefulSet pod stayed Pending with 1 node(s) had volume node affinity conflict. Its EBS volume lived in eu-west-1a, and no node in that zone had room. How zonal volumes, WaitForFirstConsumer and topology interact, and how we made the StatefulSet survive node changes.
We ran everything in one big Kubernetes cluster until a CRD upgrade broke three teams at once. This guide compares one shared cluster, a cluster per environment and a cluster per team on isolation, blast radius, upgrade effort and real cost, with a worked cost model.
After upgrading to Karpenter v1 with WhenEmptyOrUnderutilized consolidation, our EKS cluster replaced nodes constantly and long-running pods were evicted every few minutes. How we read Karpenter's events, tuned consolidateAfter and disruption budgets, and protected jobs that must not be interrupted.