Run both in parallel, move capacity gradually, and delete the old setup last.

1 InstallKarpenter beside existing groups.

2 DefineNodePool and EC2NodeClass matching today's policy.

3 ShiftReduce old group max; new Pods land on Karpenter nodes.

4 DrainCordon and drain old nodes; verify.

5 RemoveDelete the group, the autoscaler and its IAM.

Every step is reversible

Until you delete the old node group, you can raise its size and move back.

Pitfalls

Leftover Cluster Autoscaler pods and IAM permissions create noisy errors. System Pods (CoreDNS, Karpenter itself) should run on a small managed group.

runbook excerpt

$ helm install karpenter \
    oci://public.ecr.aws/karpenter/karpenter \
    -n kube-system \
    --set settings.clusterName=shop-eu \
    --set settings.interruptionQueue=shop-eu
$ kubectl apply -f nodepool.yaml -f ec2nodeclass.yaml
$ kubectl get nodeclaims
$ aws eks update-nodegroup-config \
    --cluster-name shop-eu --nodegroup-name std \
    --scaling-config minSize=0,maxSize=0,desiredSize=0
$ kubectl -n kube-system delete deploy \
    cluster-autoscaler

Migrating from Cluster Autoscaler to Karpenter, safely

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.