Cluster Autoscaler → Karpenter Migration Readiness Checklist (2026)

Click the button above to open print dialog and save as PDF

Purpose: Validate your EKS cluster readiness for safe migration from Cluster Autoscaler to Karpenter. Complete all sections before proceeding with migration.

Document Version: 2026.1 | Last Updated: December 2026

1. Cluster Baseline Checks

Kubernetes version >= 1.26 (recommended >= 1.29)

Verify with: kubectl version --short

Karpenter v1.0+ installed (v1.8 latest as of 2026)

Check installed version: kubectl get deployment karpenter -n karpenter -o jsonpath='{.spec.template.spec.containers[0].image}'

AWS CLI >= 2.15.0, eksctl >= 0.150.0, kubectl >= 1.26

Verify all tools are up to date and compatible

Cluster has stable NodeGroups with documented configuration

Document: instance types, taints, labels, launch templates, AMI IDs

Current node utilization baseline measured

Record: average CPU/memory utilization, peak usage patterns, idle node percentage

Cluster Autoscaler configuration documented

Include: scaling policies, node group configurations, any custom annotations

2. Workload Scheduling Assumptions

All DaemonSets compatible with Karpenter node labels

Verify: node selectors, tolerations, required labels match Karpenter node templates

PodDisruptionBudgets (PDBs) reviewed and validated

Check: kubectl get pdb -A - ensure critical workloads have PDBs

Node selectors and affinity rules documented

Map: required node labels, instance type requirements, zone preferences

Taints and tolerations inventory complete

Document: all taints on current nodes, matching pod tolerations

Stateful workloads identified and migration strategy defined

List: databases, persistent volumes, stateful sets requiring special handling

Workloads categorized by migration priority

Categories: non-critical (pilot), stateless (phase 1), stateful (phase 2), critical (phase 3)

3. Spot Instance Risk Tolerance

Spot interruption handling strategy defined

Decide: spot-only, spot/on-demand mix, or on-demand only for critical workloads

Fault-tolerant workloads identified for spot usage

Evaluate: batch jobs, stateless APIs, worker queues that can tolerate interruptions

Spot capacity limits and fallback strategy configured

Set: maximum spot percentage, automatic fallback to on-demand thresholds

Spot instance interruption handling tested

Validate: pod rescheduling, data persistence, graceful degradation behavior

Cost savings targets for spot usage calculated

Estimate: expected savings (50-70% on spot vs on-demand), risk vs reward analysis

4. IAM and Permissions Readiness

Karpenter controller IAM role configured with required permissions

Verify: EC2 instance creation, VPC configuration, node management, tagging permissions

IRSA (IAM Roles for Service Accounts) properly configured

Check: trust relationship, service account annotations, role ARN mapping

EC2NodeClass IAM permissions validated

Required: ec2:DescribeImages, ec2:DescribeInstanceTypes, ec2:DescribeAvailabilityZones

Subnet and security group permissions verified

Ensure: Karpenter can discover subnets, create ENIs, attach security groups

Launch template permissions if using custom AMIs

Verify: ec2:DescribeLaunchTemplates, ec2:CreateLaunchTemplateVersion permissions

IAM policy tested with least privilege principle

Audit: remove unnecessary permissions, test with minimal required access

5. Observability Prerequisites

Karpenter metrics collection configured

Setup: Prometheus scraping, CloudWatch metrics, or preferred monitoring solution

Node provisioning latency monitoring in place

Track: time from pod pending to node ready, target < 60 seconds

Cost tracking dashboard configured

Monitor: node costs, spot vs on-demand usage, consolidation savings

Pod disruption and eviction metrics tracked

Alert: unexpected pod disruptions, PDB violations, node termination events

Node utilization and bin packing metrics available

Measure: CPU/memory utilization per node, pod density, consolidation opportunities

Alerting rules configured for migration validation

Set: alerts for provisioning failures, cost anomalies, service degradation

6. Rollback Readiness

Cluster Autoscaler remains active during migration

Strategy: Keep CA running, disable per namespace as workloads migrate

Rollback procedure documented and tested

Steps: Re-enable CA, scale NodeGroups, remove Karpenter NodePools, verify workloads

Namespace-level rollback strategy defined

Plan: How to revert specific namespaces without affecting migrated workloads

Rollback decision criteria established

Define: Cost increase thresholds, SLA violations, provisioning failures that trigger rollback

Rollback validation checklist prepared

Verify: Workloads running on CA nodes, NodeGroups scaled appropriately, Karpenter disabled

7. Cost Modeling Sanity Checks

Metric	Current (CA)	Target (Karpenter)
Average node utilization	___________%	70-80%
Monthly node costs	$___________	30-60% reduction
Spot instance usage	___________%	Target: ___________%
Node count (average)	___________	Expected reduction: ___________
Provisioning latency (p95)	3-5 minutes	< 60 seconds

Baseline cost measurement completed (7-30 days)

Record: average daily/weekly costs, peak usage costs, idle node costs

Expected savings calculated with conservative estimates

Estimate: 30-40% for moderate optimization, 50-60% with aggressive spot usage

Cost tracking queries prepared for post-migration validation

Setup: AWS Cost Explorer filters, Karpenter node tagging, cost allocation tags

ROI timeline defined (break-even point calculated)

Consider: migration effort cost, expected monthly savings, time to break even

8. Production Cutover Go/No-Go

Final Validation Before Production Migration

Pilot phase completed successfully (2+ weeks)

Non-critical workloads migrated, validated, and stable

Cost savings validated in pilot

Actual savings match or exceed projections

Zero pod disruptions during pilot migration

No unexpected evictions or scheduling failures

Provisioning latency meets targets (< 60 seconds)

Karpenter nodes provision faster than CA baseline

Rollback procedure tested and validated

Successfully reverted pilot workloads to CA if needed

Team trained on Karpenter operations

Engineers understand NodePool configuration, troubleshooting, monitoring

Monitoring and alerting validated

All dashboards working, alerts firing correctly, on-call rotation aware

Migration schedule approved by stakeholders

Business hours, maintenance windows, communication plan confirmed

Support escalation path defined

Who to contact, when to rollback, emergency procedures documented

Go/No-Go Decision

All items above must be checked before proceeding to production migration.

Go Decision Criteria:

All pilot validations passed
Cost savings targets met or exceeded
Zero critical issues during pilot
Team confidence level: High

No-Go Decision Criteria:

Any critical issues unresolved
Cost savings below 20% threshold
Frequent pod disruptions or scheduling failures
Team confidence level: Low or Medium