Orchestration

Kubernetes Autoscaling: Cluster Autoscaler vs Karpenter

August 3, 2026 Kubezilla Team 15 min read

Introduction

In the dynamic world of Kubernetes, efficiently managing your cluster’s compute resources is paramount for both performance and cost-effectiveness. As your application workloads fluctuate, the underlying infrastructure must scale accordingly. Manual scaling is tedious, error-prone, and simply doesn’t cut it in a cloud-native environment. This is where auto-scaling solutions like Kubernetes Cluster Autoscaler and Karpenter step in, promising to optimize your node infrastructure by automatically adding or removing nodes based on demand.

While both tools aim to solve the same fundamental problem – ensuring your pods have enough capacity to run without over-provisioning – their approaches, capabilities, and underlying philosophies differ significantly. Choosing between Cluster Autoscaler and Karpenter can have a profound impact on your operational overhead, cost efficiency, and overall cluster responsiveness. This guide will deep dive into the mechanics of each, compare their strengths and weaknesses, and provide a practical, hands-on approach to implementing both. By the end, you’ll be equipped to make an informed decision tailored to your specific Kubernetes needs.

TL;DR: Cluster Autoscaler vs. Karpenter

Kubernetes Cluster Autoscaler (CA) and Karpenter are both tools for automatically scaling Kubernetes nodes.

  • Cluster Autoscaler (CA):
    • What it does: Scales node groups (e.g., AWS Auto Scaling Groups, Azure VM Scale Sets) up or down.
    • How it works: Watches for unschedulable pods and adds nodes from pre-defined node groups. Removes underutilized nodes.
    • Key feature: Works with existing cloud provider constructs.
    • Best for: Stable workloads, environments where you want more control over node types via managed node groups.
  • Karpenter:
    • What it does: Directly provisions and de-provisions individual nodes based on pending pods, bypassing node groups.
    • How it works: Observes pending pods and makes intelligent decisions about the optimal node type, size, and pricing model (e.g., Spot vs. On-Demand) to provision.
    • Key feature: Just-in-time provisioning, rapid scaling, cost optimization via intelligent instance selection.
    • Best for: Highly dynamic workloads, cost-sensitive environments, rapid scaling needs, leveraging diverse instance types.

Quick Commands:

Deploy Cluster Autoscaler (EKS Example):


# Create an IAM policy for CA (replace <YOUR_CLUSTER_NAME>)
curl -o cluster-autoscaler-policy.json https://raw.githubusercontent.com/kubernetes/autoscaler/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-autodiscover.iam.json
aws iam create-policy \
    --policy-name AmazonEKSClusterAutoscalerPolicy \
    --policy-document file://cluster-autoscaler-policy.json

# Attach policy to an IAM role for your service account
eksctl create iamserviceaccount \
    --cluster <YOUR_CLUSTER_NAME> \
    --namespace kube-system \
    --name cluster-autoscaler \
    --attach-policy-arn "arn:aws:iam::<YOUR_ACCOUNT_ID>:policy/AmazonEKSClusterAutoscalerPolicy" \
    --approve \
    --override-existing-serviceaccounts

# Deploy CA (adjust image and args for your cluster version)
kubectl apply -f https://raw.githubusercontent.com/kubernetes/autoscaler/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-autodiscover.yaml

Deploy Karpenter (EKS Example):


# Create IAM role and service account for Karpenter
eksctl create iamserviceaccount \
  --cluster <YOUR_CLUSTER_NAME> \
  --namespace karpenter \
  --name karpenter \
  --role-name karpenter-controller \
  --attach-policy-arn "arn:aws:iam::<YOUR_ACCOUNT_ID>:policy/KarpenterControllerPolicy-<YOUR_CLUSTER_NAME>" \
  --override-existing-serviceaccounts \
  --approve

# Install Karpenter Helm chart
helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter --version <KARPENTER_VERSION> \
  --namespace karpenter --create-namespace \
  --set serviceAccount.create=false \
  --set serviceAccount.name=karpenter \
  --set clusterName=<YOUR_CLUSTER_NAME> \
  --set clusterEndpoint=<YOUR_CLUSTER_ENDPOINT> \
  --wait # Wait for the deployment to complete

# Create a Provisioner (Karpenter's custom resource)
kubectl apply -f - <<EOF
apiVersion: karpenter.sh/v1beta1
kind: Provisioner
metadata:
  name: default
spec:
  requirements:
    - key: kubernetes.io/arch
      operator: In
      values: ["amd64"]
    - key: kubernetes.io/os
      operator: In
      values: ["linux"]
    - key: karpenter.sh/capacity-type
      operator: In
      values: ["on-demand", "spot"]
  limits:
    resources:
      cpu: "1000"
  providerRef:
    name: default
---
apiVersion: karpenter.sh/v1beta1
kind: AWSNodeTemplate
metadata:
  name: default
spec:
  amiFamily: AL2 # Amazon Linux 2
  subnetSelector:
    karpenter.sh/discovery: <YOUR_CLUSTER_NAME>
  securityGroupSelector:
    karpenter.sh/discovery: <YOUR_CLUSTER_NAME>
  instanceProfile: KarpenterNodeInstanceProfile-<YOUR_CLUSTER_NAME>
EOF

Prerequisites

To follow along with this guide, you’ll need the following:

  • Kubernetes Cluster: An existing Kubernetes cluster. For demonstration purposes, an Amazon EKS cluster is ideal, as both tools have excellent AWS integration, but the concepts apply broadly to other cloud providers.
  • kubectl: The Kubernetes command-line tool, configured to connect to your cluster. Refer to the official Kubernetes documentation for installation instructions.
  • helm: The Kubernetes package manager, used for deploying Karpenter. Install it from the Helm website.
  • aws CLI: If using EKS, the AWS Command Line Interface configured with appropriate permissions.
  • eksctl: For EKS clusters, eksctl simplifies cluster management and IAM role creation. Install it from the eksctl GitHub repository.
  • IAM Permissions: Sufficient AWS IAM permissions to create policies, roles, and manage EC2 instances, Auto Scaling Groups, and EKS components.
  • Basic Kubernetes Knowledge: Familiarity with Kubernetes concepts like Pods, Deployments, Services, and Nodes.

Kubernetes Cluster Autoscaler (CA)

The Kubernetes Cluster Autoscaler is a well-established tool designed to automatically adjust the size of your Kubernetes cluster. It works by monitoring for pods that fail to schedule due to insufficient resources and, conversely, identifying nodes that are underutilized and can be safely removed. CA operates by interacting with your cloud provider’s auto-scaling mechanisms, such as AWS Auto Scaling Groups (ASGs), Azure VM Scale Sets, or GCP Managed Instance Groups.

CA doesn’t provision individual nodes directly. Instead, it scales existing node groups up or down within the pre-defined minimum and maximum limits of those groups. This means you need to define your desired node types and configurations within these cloud provider constructs beforehand. While this provides a structured approach to node management, it can sometimes lead to slower scaling times and less optimal resource utilization if your workload demands highly varied or specialized instance types that aren’t well-represented in your node groups. For more advanced networking concepts that might influence node selection, consider exploring topics like Cilium WireGuard Encryption for pod-to-pod traffic security.

Step-by-Step Guide: Deploying Cluster Autoscaler on EKS

1. Create IAM Policy and Role for Cluster Autoscaler

The Cluster Autoscaler needs permissions to interact with your cloud provider’s API to scale node groups. For AWS EKS, this involves creating an IAM policy and attaching it to a Kubernetes Service Account that the CA deployment will use. This ensures the principle of least privilege. 


# Define your cluster name and AWS account ID
CLUSTER_NAME="your-eks-cluster-name"
AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

# Download the recommended IAM policy document for EKS Cluster Autoscaler
curl -o cluster-autoscaler-policy.json https://raw.githubusercontent.com/kubernetes/autoscaler/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-autodiscover.iam.json

# Create the IAM policy in your AWS account
aws iam create-policy \
    --policy-name AmazonEKSClusterAutoscalerPolicy-${CLUSTER_NAME} \
    --policy-document file://cluster-autoscaler-policy.json

# Create an IAM Service Account for Cluster Autoscaler
# eksctl will handle creating the IAM role and linking it to the K8s service account
eksctl create iamserviceaccount \
    --cluster ${CLUSTER_NAME} \
    --namespace kube-system \
    --name cluster-autoscaler \
    --attach-policy-arn "arn:aws:iam::${AWS_ACCOUNT_ID}:policy/AmazonEKSClusterAutoscalerPolicy-${CLUSTER_NAME}" \
    --approve \
    --override-existing-serviceaccounts

Verify:

Check if the IAM service account was created successfully. 


kubectl get sa -n kube-system cluster-autoscaler -o yaml

Expected Output:


apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::<YOUR_ACCOUNT_ID>:role/eksctl-<YOUR_CLUSTER_NAME>-addon-iamserviceaccount-kube-system-cluster-autoscaler
  creationTimestamp: "..."
  name: cluster-autoscaler
  namespace: kube-system
  resourceVersion: "..."
  uid: "..."

Also, verify the IAM role exists in AWS: 


aws iam get-role --role-name eksctl-${CLUSTER_NAME}-addon-iamserviceaccount-kube-system-cluster-autoscaler

2. Deploy Cluster Autoscaler to your Cluster

Now that the service account with the necessary permissions is ready, we can deploy the Cluster Autoscaler itself. You’ll need to fetch the deployment manifest from the official Cluster Autoscaler GitHub repository and customize it for your EKS cluster, specifically pointing it to the correct service account and setting the --node-group-auto-discovery flag. Ensure the image version matches your Kubernetes cluster version for compatibility. 


# Fetch the Cluster Autoscaler deployment manifest
# Adjust the version to match your Kubernetes cluster version (e.g., 1.28, 1.29)
# Check compatible versions here: https://github.com/kubernetes/autoscaler/releases
CA_VERSION="v1.28.0" # Example: use the version compatible with your EKS cluster

curl -o cluster-autoscaler-deployment.yaml https://raw.githubusercontent.com/kubernetes/autoscaler/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-autodiscover.yaml

# Modify the deployment to use the created service account and EKS-specific arguments
# This sed command is sensitive to the exact YAML structure.
# It injects the serviceAccountName and updates the image and command arguments.
sed -i.bak \
  -e "s/serviceAccount: cluster-autoscaler/serviceAccountName: cluster-autoscaler/" \
  -e "s/image: k8s.gcr.io\/cluster-autoscaler:\(.*\)/image: registry.k8s.io\/autoscaling\/cluster-autoscaler:${CA_VERSION}/" \
  -e "/--node-group-auto-discovery/a\            - --node-group-auto-discovery=asgType=eks,clusterName=${CLUSTER_NAME}" \
  -e "/--node-group-auto-discovery/d" \
  cluster-autoscaler-deployment.yaml

# Apply the modified deployment
kubectl apply -f cluster-autoscaler-deployment.yaml

Verify:

Check if the Cluster Autoscaler pod is running. 


kubectl get pods -n kube-system -l app=cluster-autoscaler

Expected Output:


NAME                                 READY   STATUS    RESTARTS   AGE
cluster-autoscaler-<POD_HASH>        1/1     Running   0          <X>m

You can also check its logs for activity: 


kubectl logs -f -n kube-system -l app=cluster-autoscaler

3. Configure EKS Managed Node Groups for Scaling

For Cluster Autoscaler to work, you need EKS Managed Node Groups (or self-managed ASGs) with defined minimum and maximum sizes. CA will operate within these boundaries. Let’s ensure our node group has scaling capabilities. 


# List your existing EKS node groups
eksctl get nodegroup --cluster ${CLUSTER_NAME}

# If you don't have one, create a new managed node group with auto-scaling enabled
# Replace 'default' with your desired node group name and adjust instance type, min/max size
eksctl create nodegroup \
    --cluster ${CLUSTER_NAME} \
    --name default \
    --node-type t3.medium \
    --nodes 1 \
    --nodes-min 1 \
    --nodes-max 3 \
    --node-volume-size 20 \
    --ssh-access \
    --managed \
    --external-dns-hostname # Optional, if you use external-dns

# Alternatively, update an existing node group to enable scaling
# For an existing node group named 'default', set min/max size
# aws eks update-nodegroup-config \
#     --cluster-name ${CLUSTER_NAME} \
#     --nodegroup-name default \
#     --scaling-config minSize=1,maxSize=3,desiredSize=1

Verify:

Check the configuration of your node group to ensure minSize and maxSize are set appropriately. 


aws eks describe-nodegroup --cluster-name ${CLUSTER_NAME} --nodegroup-name default --query 'nodegroup.scalingConfig'

Expected Output:


{
    "minSize": 1,
    "maxSize": 3,
    "desiredSize": 1
}

4. Test Cluster Autoscaler Scaling

To observe CA in action, we’ll deploy a deployment that requests more resources than currently available on your nodes, forcing new nodes to be provisioned. 


kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ca-test-app
spec:
  replicas: 10 # Request enough pods to exceed current capacity
  selector:
    matchLabels:
      app: ca-test-app
  template:
    metadata:
      labels:
        app: ca-test-app
    spec:
      terminationGracePeriodSeconds: 0
      containers:
      - name: stress
        image: alpine/git
        command: ["/bin/sh", "-c", "while true; do sleep 3600; done"]
        resources:
          requests:
            memory: "500Mi"
            cpu: "250m"
EOF

Verify:

Watch for pending pods and new nodes being added. 


# Watch pods, you should see some in Pending state initially
kubectl get pods -w

# Watch nodes, you should see new nodes appear
kubectl get nodes -w

After a few minutes, Cluster Autoscaler should detect the pending pods and initiate the scaling of your EKS node group. You’ll see new nodes joining the cluster, and eventually, all pods should transition to a Running state.

To see the de-scaling, simply delete the deployment and CA will remove underutilized nodes after a cooldown period. 


kubectl delete deployment ca-test-app

Karpenter

Karpenter is a relatively newer, open-source, high-performance Kubernetes cluster autoscaler built by AWS. Unlike the Cluster Autoscaler, Karpenter does not rely on cloud provider auto-scaling groups. Instead, it directly provisions and de-provisions individual EC2 instances (or VMs in other clouds) in response to unschedulable pods. This fundamental difference allows Karpenter to make highly intelligent, just-in-time provisioning decisions, often leading to faster scaling, better resource utilization, and significant cost savings.

Karpenter observes pending pods and evaluates their resource requests, node selectors, tolerations, and affinities. It then queries the cloud provider’s API (e.g., EC2) to find the most suitable instance type from a wide range of options, including various instance families, sizes, and pricing models (Spot, On-Demand). This “right-sizing” capability is a major differentiator, enabling it to pick the cheapest or most appropriate instance for a given workload. For organizations focused on cost optimization, Karpenter is a game-changer, as detailed in our Karpenter Cost Optimization guide. It integrates seamlessly with other Kubernetes features like GPU scheduling for LLMs, allowing it to provision specialized instances when needed.

Step-by-Step Guide: Deploying Karpenter on EKS

1. Create IAM Role and Service Account for Karpenter

Karpenter requires an IAM role with permissions to launch and terminate EC2 instances, manage instance profiles, and interact with other AWS services like subnets and security groups. Similar to Cluster Autoscaler, we’ll create a Kubernetes Service Account and link it to an IAM role. 


# Define your cluster name and AWS account ID
CLUSTER_NAME="your-eks-cluster-name"
AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

# Create an IAM policy for Karpenter controller
# This policy grants Karpenter permissions to manage EC2 instances, launch templates, etc.
# Refer to official Karpenter documentation for the latest policy:
# https://karpenter.sh/docs/getting-started/getting-started-with-eks/#create-an-iam-role-for-karpenter
cat <<EOF > karpenter-controller-policy.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:CreateLaunchTemplate",
                "ec2:CreateFleet",
                "ec2:RunInstances",
                "ec2:CreateTags",
                "ec2:TerminateInstances",
                "ec2:DeleteLaunchTemplate",
                "ec2:DescribeLaunchTemplates",
                "ec2:DescribeInstances",
                "ec2:DescribeImages",
                "ec2:DescribeSubnets",
                "ec2:DescribeSecurityGroups",
                "ec2:DescribeInstanceTypes",
                "ec2:DescribeInstanceTypeOfferings",
                "ec2:DescribeAvailabilityZones",
                "ec2:DeleteTags",
                "ec2:AssignPrivateIpAddresses",
                "ec2:UnassignPrivateIpAddresses",
                "ec2:DescribeNetworkInterfaces",
                "ec2:DeleteNetworkInterface",
                "ec2:CreateNetworkInterface",
                "ec2:ModifyNetworkInterfaceAttribute"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "arn:aws:iam::${AWS_ACCOUNT_ID}:role/KarpenterNodeInstanceProfile-${CLUSTER_NAME}",
            "Condition": {
                "StringLike": {
                    "iam:PassedToService": "ec2.amazonaws.com"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "ssm:GetParameter",
            "Resource": "arn:aws:ssm:*:${AWS_ACCOUNT_ID}:parameter/aws/service/ami-amazon-linux-2-recommended/recommendation/image_id"
        },
        {
            "Effect": "Allow",
            "Action": "eks:DescribeCluster",
            "Resource": "arn:aws:eks:*:${AWS_ACCOUNT_ID}:cluster/${CLUSTER_NAME}"
        }
    ]
}
EOF

# Create the IAM policy
aws iam create-policy \
    --policy-name KarpenterControllerPolicy-${CLUSTER_NAME} \
    --policy-document file://karpenter-controller-policy.json

# Create the Karpenter controller service account and attach the policy
eksctl create iamserviceaccount \
  --cluster ${CLUSTER_NAME} \
  --namespace karpenter \
  --name karpenter \
  --role-name karpenter-controller-${CLUSTER_NAME} \
  --attach-policy-arn "arn:aws:iam::${AWS_ACCOUNT_ID}:policy/KarpenterControllerPolicy-${CLUSTER_NAME}" \
  --override-existing-serviceaccounts \
  --approve

# Create an EC2 Instance Profile for Karpenter-provisioned nodes
# This profile will be used by the nodes Karpenter creates
aws iam create-instance-profile --instance-profile-name KarpenterNodeInstanceProfile-${CLUSTER_NAME}
aws iam add-role-to-instance-profile --instance-profile-name KarpenterNodeInstanceProfile-${CLUSTER_NAME} --role-name eksctl-${CLUSTER_NAME}-nodegroup-default-NodeInstanceRole # Replace 'default' with your base node group role

Verify:

Check the service account and instance profile. 


kubectl get sa -n karpenter karpenter -o yaml
aws iam get-instance-profile --instance-profile-name KarpenterNodeInstanceProfile-${CLUSTER_NAME}

2. Install Karpenter using Helm

Karpenter is typically deployed via Helm. You’ll need to specify your cluster name and endpoint, and importantly, disable service account creation as we’ve already created it manually. 


# Get your cluster's endpoint
CLUSTER_ENDPOINT=$(aws eks describe-cluster --name ${CLUSTER_NAME} --query "cluster.endpoint" --output text)

# Add Karpenter Helm chart repository
helm repo add karpenter https://charts.karpenter.sh/
helm repo update

# Install Karpenter. Replace <KARPENTER_VERSION> with the latest stable version (e.g., v0.33.0)
# Check https://karpenter.sh/docs/getting-started/getting-started-with-eks/#install-karpenter for the latest
KARPENTER_VERSION="v0.33.0" 

helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter --version ${KARPENTER_VERSION} \
  --namespace karpenter --create-namespace \
  --set serviceAccount.create=false \
  --set serviceAccount.name=karpenter \
  --set clusterName=${CLUSTER_NAME} \
  --set clusterEndpoint=${CLUSTER_ENDPOINT} \
  --wait # Wait for the deployment to complete

Verify:

Ensure Karpenter controller pod is running. 


kubectl get pods -n karpenter -l app.kubernetes.io/name=karpenter

Expected Output:


NAME                                READY   STATUS    RESTARTS   AGE
karpenter-controller-<POD_HASH>     1/1     Running   0          <X>m

3. Create Karpenter Provisioner and AWSNodeTemplate

Karpenter uses Custom Resources Definitions (CRDs) called Provisioner and AWSNodeTemplate (for AWS) to define how it should provision nodes. The Provisioner specifies the general requirements for nodes, while AWSNodeTemplate provides AWS-specific configurations like AMI family, subnet, and security group selectors. Karpenter discovers subnets and security groups by looking for specific tags, so we’ll ensure our EKS cluster’s resources are tagged correctly. 


# Tag your subnets and security groups for Karpenter discovery
# This is usually done by eksctl automatically, but verify.
# For subnets:
for SUBNET_ID in $(aws ec2 describe-subnets --filters "Name=tag:eks:cluster-name,Values=${CLUSTER_NAME}" --query "Subnets[*].SubnetId" --output text); do
    aws ec2 create-tags --resources ${SUBNET_ID} --tags Key=karpenter.sh/discovery,Value=${CLUSTER_NAME}
done

# For security groups:
for SG_ID in $(aws ec2 describe-security-groups --filters "Name=tag:eks:cluster-name,Values=${CLUSTER_NAME}" --query "SecurityGroups[*].GroupId" --output text); do
    aws ec2 create-tags --resources ${SG_ID} --tags Key=karpenter.sh/discovery,Value=${CLUSTER_NAME}
done

# Create a default Provisioner and AWSNodeTemplate
kubectl apply -f - <<EOF
apiVersion: karpenter.sh/v1beta1
kind: Provisioner
metadata:
  name: default
spec:
  # Provisioners can be constrained by requirements, similar to pod node selectors.
  # This example ensures only amd64 Linux nodes are provisioned.
  requirements:
    - key: kubernetes.io/arch
      operator: In
      values: ["amd64"]
    - key: kubernetes.io/os
      operator: In
      values: ["linux"]
    - key: karpenter.sh/capacity-type
      operator: In
      values: ["on-demand", "spot"] # Allow Karpenter to provision both On-Demand and Spot instances
  
  # Limits can be set to constrain the total resources Karpenter can provision.
  limits:
    resources:
      cpu: "1000" # Max 1000 CPU cores for this provisioner
  
  # TTLSecondsAfterEmpty allows Karpenter to deprovision nodes that have been empty for a specified duration.
  ttlSecondsAfterEmpty: 30s # Remove nodes 30 seconds after they become empty

  # TTLSecondsUntilExpired causes nodes to expire after a certain time, forcing a refresh.
  ttlSecondsUntilExpired: 604800 # 7 days (60 * 60 * 24 * 7)

  # Consolidate nodes to reduce waste by moving pods to smaller nodes or combining pods onto fewer nodes.
  consolidation:
    enabled: true

  # ProviderRef links to the cloud provider specific template (e.g., AWSNodeTemplate)
  providerRef:
    name: default
---
apiVersion: karpenter.sh/v1beta1
kind: AWSNodeTemplate
metadata:
  name: default
spec:
  amiFamily: AL2 # Use Amazon Linux 2 AMIs
  # SubnetSelector and SecurityGroupSelector use tags to find appropriate resources.
  # Ensure your EKS subnets and security groups are tagged with karpenter.sh/discovery: ${CLUSTER_NAME}
  subnetSelector:
    karpenter.sh/discovery: "${CLUSTER_NAME}"
  securityGroupSelector:
    karpenter.sh/discovery: "${CLUSTER_NAME}"
  # The instanceProfile Karpenter nodes will use. This should have permissions for Kubelet to join the cluster.
  instanceProfile: KarpenterNodeInstanceProfile-${CLUSTER_NAME}
  # BlockDeviceMappings to customize root volume size or add additional volumes.
  blockDeviceMappings:
    - deviceName: /dev/xvda
      ebs:
        volumeSize: 20Gi
        volumeType: gp3
        encrypted: true
  # Tags to apply to instances launched by this template.
  tags:
    karpenter.sh/provisioner-name: default
    environment: production
EOF

Verify:

Check if the Provisioner and AWSNodeTemplate CRDs are created. 


kubectl get provisioners
kubectl get awsnodetemplates

Expected Output:


NAME      AGE
default   <X>m

NAME      AGE
default   <X>m

4. Test Karpenter Scaling

Similar to CA, we’ll deploy a workload that exceeds current capacity to trigger Karpenter. Karpenter should provision new nodes much faster and potentially more efficiently than CA. 


kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: karpenter-test-app
spec:
  replicas: 10 # Request enough pods to exceed current capacity
  selector:
    matchLabels:
      app: karpenter-test-app
  template:
    metadata:
      labels:
        app: karpenter-test-app
    spec:
      # Optional: Use a node selector to target specific provisioners if you have multiple
      # nodeSelector:
      #   karpenter.sh/provisioner-name: default
      terminationGracePeriodSeconds: 0
      containers:
      - name: stress
        image: alpine/git
        command: ["/bin/sh", "-c", "while true; do sleep 3600; done"]
        resources:
          requests:
            memory: "500Mi"
            cpu: "250m"
EOF

Verify:

Watch for pending pods and new nodes being added by Karpenter. 


# Watch pods, you should see some in Pending state initially
kubectl get pods -w

# Watch nodes, you should see new nodes appear rapidly, often with karpenter.sh/provisioner-name label
kubectl get nodes -w -L karpenter.sh/provisioner-name

Karpenter should quickly detect the pending pods and provision new EC2 instances. You’ll notice these nodes often have the karpenter.sh/provisioner-name label. Once the pods are running, delete the deployment to see Karpenter’s de-provisioning in action. 


kubectl delete deployment karpenter-test-app

Production Considerations

Deploying auto-scaling solutions in production requires careful planning beyond basic setup.

  • Cost Optimization:

    • Karpenter: Excels here. Leverage Spot instances heavily (e.g

Leave a comment