Cluster Autoscaler vs Karpenter: The Simplified Guide

Author

Govardhana M K
October 25, 2025

In partnership with

TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to another technical edition.

Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.

Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.

👋 👋 A big thank you to today's sponsor THE DEEP VIEW

Become An AI Expert In Just 5 Minutes

If you’re a decision maker at your company, you need to be on the bleeding edge of, well, everything. But before you go signing up for seminars, conferences, lunch ‘n learns, and all that jazz, just know there’s a far better (and simpler) way: Subscribing to The Deep View.

This daily newsletter condenses everything you need to know about the latest and greatest AI developments into a 5-minute read. Squeeze it into your morning coffee break and before you know it, you’ll be an expert too.

Subscribe right here. It’s totally free, wildly informative, and trusted by 600,000+ readers at Google, Meta, Microsoft, and beyond.

👀 Remote Jobs

📚️ Resources

🧠 DEEP DIVE USE CASE

Cluster Autoscaler vs Karpenter: The Simplified Guide

Kubernetes gives you multiple ways to scale pods, nodes, or both.

But when it comes to scaling infrastructure, engineers often ask

  1. Should I rely on Cluster Autoscaler or move to Karpenter?

  2. Is Karpenter just a faster version of Cluster Autoscaler or a complete rethink?

  3. If both can scale nodes, which one gives better efficiency in real workloads?

Before getting there, let us tighten up the scaling basics.

HPA vs VPA

Horizontal Pod Autoscaler (HPA) increases or decreases the number of pods based on workload demand. When CPU or memory usage goes up, HPA creates more pod replicas to handle the load. When usage drops, it removes the extra pods.

Vertical Pod Autoscaler (VPA) adjusts the CPU and memory limits of a pod instead of changing the number of pods. It makes a single pod bigger or smaller depending on how much resource it actually needs.

In short, HPA scales out by adding pods. VPA scales up by giving a pod more power.

Node Groups

A Kubernetes cluster runs multiple nodes that are grouped based on instance type or purpose. Each node group contains identical nodes managed together.

For example, one group may use m5.large instances for general workloads, while another uses c6i.xlarge for compute heavy tasks. Pods are scheduled across these groups depending on resource requests and placement rules.

Node groups make it easier to manage scaling, updates, and lifecycle operations for a specific set of nodes with similar configurations.

Cluster Autoscaler

Cluster Autoscaler adds or removes nodes in a Kubernetes cluster based on pending pods.

When a pod cannot be scheduled because no existing node has enough CPU or memory, the autoscaler detects it and requests new nodes from the cloud provider. Once the pods are placed and utilization drops, it can also remove underused nodes to save cost.

It works with predefined node groups and relies on the cloud’s scaling APIs, such as AWS Auto Scaling Groups, to manage capacity.

Behind the Scenes

The Cluster Autoscaler continuously monitors the Kubernetes API for pods that are stuck in a Pending state. These are pods that the scheduler cannot place on any existing node due to insufficient CPU, memory, or resource constraints.

When the Autoscaler detects such pods, it:

  1. Checks all node groups

    It inspects each node group to see if adding a node of that type would help schedule the pending pods.

  2. Selects a suitable node group

    Once a compatible node group is found, the Autoscaler asks the cloud provider (like AWS, GCP, or Azure) to scale out that group by adding a new node through an Auto Scaling Group (ASG).

  3. New node joins the cluster

    The ASG provisions a new VM. Once the node registers with the API server, the Kubernetes scheduler places pending pods on it automatically.

  4. Monitors for scale down

    The Autoscaler also looks for nodes that are underused for a certain period (for example, less than 50% utilization for 10 minutes). It cordons and drains such nodes, ensuring pods are rescheduled elsewhere before terminating them.

❝

Cluster Autoscaler doesn’t replace the scheduler. It only adds or removes nodes based on what the scheduler cannot do.

The scheduler decides where pods go.

With this basic understanding, let us continue where the Cluster Autoscaler becomes a bottleneck, how Karpenter works, and which one to choose.

Looking to promote your company, product, service, or event to 56,000+ Cloud Native Professionals? Let's work together. Advertise With Us

Upgrade to Paid to read the rest.

Become a paying subscriber to get access to this post and other subscriber-only content.

Already a paying subscriber? Sign In.

Paid subscriptions get you:

  • • Access to archive of 200+ use cases
  • • Deep Dive use case editions (Thursdays and Saturdays)
  • • Access to Private Discord Community
  • • Invitations to monthly Zoom calls for use case discussions and industry leaders meetups
  • • Quarterly 1:1 'Ask Me Anything' power session