Migrating from Cluster Autoscaler to Karpenter, safely

Study notes

• This is the most common modernisation project on EKS. The safest approach is parallel running. Install Karpenter alongside the existing node groups without touching them. Define a NodePool and EC2NodeClass that mirror your current instance policy. Then reduce the old node group's maximum size so new Pods that need capacity land on Karpenter-provisioned nodes, and confirm with kubectl get nodeclaims and the controller logs. Press the right arrow to step through.
• Next drain the remaining old nodes gradually, checking that workloads reschedule cleanly (PodDisruptionBudgets and graceful termination matter here), and finally delete the old node group, the Cluster Autoscaler deployment and its IAM permissions. Each step is independently verifiable and reversible, which is the same blue and green principle used for node upgrades.
• Two design points. Karpenter itself must not run on nodes it manages exclusively, because if it cannot start, it cannot add nodes; keep a small managed node group (or Fargate) for Karpenter and other system Pods. And pin AMI versions in the EC2NodeClass for production to avoid unannounced node replacement through drift.
• The commands are an excerpt, not a complete runbook: IAM roles for Karpenter, the interruption queue and EventBridge rules must exist first, and the Helm chart version must match your Kubernetes version. Follow the Karpenter documentation for your versions.

Deck map