Q: Why are enterprise platform teams migrating from the traditional Kubernetes Cluster Autoscaler (CAS) to Karpenter on AWS? In a technical interview, contrast their architectural models, instance selection algorithms, node provisioning speeds, and bin-packing consolidation capabilities.

Cluster Autoscaler does not provision VMs directly. Instead, it inspects unschedulable pods, matches them against pre-configured Auto Scaling Groups (ASGs) using node group templates, and increments the desired capacity on the matching ASG. Cloud provider ASGs then initiate EC2 provisioning, running launch templates, user data scripts, and Kubelet bootstrap sequences (often taking 3 to 7 minutes). Karpenter completely eliminates the ASG layer. It acts as an intelligent scheduler that directly queries the EC2 Fleet API (`ec2:CreateFleet`), requesting exact VM configurations tailored to unschedulable pod resource requests, tolerations, and topology spreads in under 45 seconds.

# Karpenter direct fleet orchestration log
{"level":"INFO","time":"2026-10-13T10:00:02Z","message":"Found 4 unschedulable pods"}
{"level":"INFO","time":"2026-10-13T10:00:03Z","message":"Computed optimal instance type: c6i.2xlarge (on-demand)"}
{"level":"INFO","time":"2026-10-13T10:00:04Z","message":"Calling ec2:CreateFleet for instance i-0abcdef1234567890"}
{"level":"INFO","time":"2026-10-13T10:00:38Z","message":"Node ip-10-0-45-12.ec2.internal Ready in 34 seconds"}

With CAS, supporting diverse instance types requires creating dozens of separate ASGs (e.g., one for c5.large, one for m5.large, one for g4dn.xlarge, split across Spot and On-Demand). When Spot capacity dries up in an Availability Zone, CAS struggles to rebalance across disparate ASG pools without complex expander plugins (`priority`, `least-waste`). Karpenter uses multi-attribute criteria in its `NodePool` spec: you define broad requirements (e.g., `cpu: 4-16`, `memory: 8-32Gi`, `instance-family: [c, m, r]`, `capacity-type: [spot, on-demand]`), and Karpenter evaluates over 200 EC2 instance types in real time, selecting the lowest-priced instance available that satisfies pending pods.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: spot-compute
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64", "arm64"]
        - key: karpenter.k8s.aws/instance-family
          operator: In
          values: ["c6i", "c6a", "m6i", "m6a", "c7g", "m7g"]

Cluster Autoscaler scale-down is primitive: when an entire node drops below an unconfigurable utilization threshold (default 50% CPU/memory) for 10 consecutive minutes, and its pods can fit on other existing nodes, CAS drains and terminates the node. Karpenter introduces active, continuous Consolidation. If an active 8-core instance is only running two lightweight pods, Karpenter can replace the node with a cheaper 2-core instance on the fly, or move pods to other underutilized nodes and delete the redundant instance immediately, slashing cloud waste by 20% to 45%.

# Karpenter automatic consolidation configuration
spec:
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s
    expireAfter: 720h # Enforces 30-day node rotation for security hygiene

While Karpenter is dominant on AWS (and expanding to Azure), Cluster Autoscaler remains the upstream, battle-tested standard across Google Cloud (GKE), Microsoft Azure (AKS), on-premises vSphere, and bare-metal clusters. Furthermore, CAS is deeply integrated into managed Kubernetes control planes (GKE NAP, AKS Autoscale) without requiring custom controller deployments.