Karpenter Core Concepts - Interactive Learning

What is Karpenter?

🎯 Just-in-Time Node Provisioning

Karpenter observes unschedulable pods and provisions exactly the right node in under a minute. No pre-defined node groups needed.

🐳 Pod

→

⚡ Karpenter

→

🖥️ Node

🔄 Continuous Optimization

Consolidates workloads onto fewer nodes, replaces drifted nodes, and expires old nodes — automatically.

🖥️ 3 Nodes

→

🖥️ 1 Node

🛡️ Disruption Budgets

Controls how fast Karpenter replaces nodes. Separate from Pod Disruption Budgets (PDBs) which protect pod availability.

⚙️ Declarative Configuration

Define NodePools and NodeClasses as Kubernetes CRDs. No Auto Scaling Groups — Karpenter talks directly to your cloud provider.

Core Components

🏗️ Karpenter Architecture

Karpenter watches for unschedulable pods, matches NodePools, and provisions nodes using NodeClass templates.

📋 NodePool

Defines constraints for which nodes Karpenter can create:

Instance types / families
Availability zones
Capacity types (on-demand, spot)
Architecture (amd64, arm64)
Disruption budgets

apiVersion: karpenter.sh/v1beta1
kind: NodePool
spec:
  disruption:
    budgets:
      - nodes: "20%"

🖥️ EC2NodeClass

Defines how to provision the cloud instance:

Security groups & subnets
AMI family (AL2, Bottlerocket)
User data / launch templates
Block device mappings
IAM instance profile

apiVersion: karpenter.k8s.aws/v1beta1
kind: EC2NodeClass
spec:
  amiFamily: AL2
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: cluster

Node Lifecycle

Ready

📦 Unscheduled Pods

🐳 request=4CPU

🐳 request=8GPU

⚡

Karpenter
Controller

Watching...

🔧 Provisioning

🟢 Active Nodes

🖥️ c5.xlarge

⚠️ Disruption

💀 Terminated

📜 Event Log

Karpenter Disruption Budgets

📊 What Are Disruption Budgets?

Limits that control how many nodes Karpenter can disrupt at once for consolidation, drift correction, or expiration.

Think of them as a "rate limiter for node churn" — protecting cluster stability from cascading replacements.

🎯 Two Budget Types

Nodes Budget: A count or percentage of nodes allowed to disrupt simultaneously.

Schedule Budget: A time window with its own disruption limit (e.g., allow more during off-hours).

🔑 Node States

✓

HealthyRunning normally

!

Needs ReplaceDrifted / Underutilized / Expired

↻

ReplacingEvicting pods & terminating

✕

GoneReplaced / Terminated

Budget: 2 nodes at a time 2

🎬 Disruption Budget in Action

🛡️ Budget consumed: 0 / 2 nodes

Try it: Adjust the budget slider, then click Start Demo. Karpenter flags nodes that need replacement (drift/consolidation/expiry), but only replaces up to the budget limit at a time. Excess nodes wait in a queue.

📝 Budget YAML Examples

Nodes Budget

spec:
  disruption:
    budgets:
      - nodes: "20%"
        reasons:
          - Drifted
          - UnderUtilized
          - Empty

Schedule Budget

spec:
  disruption:
    budgets:
      - nodes: "1"
      - schedule: "0 2 * * *"
        duration: "6h"
        nodes: "5"
        reason: Drifted

Multiple Budgets

spec:
  disruption:
    budgets:
      - nodes: "2"           # base
      - nodes: "10"          # override
        reasons:
          - Empty
      - schedule: "0 22 * * *"
        duration: "8h"
        nodes: "0"           # block

📜 Disruption Log

Karpenter Disruption Budgets vs Pod Disruption Budgets

🔍 Side-by-Side Comparison

Aspect	🎯 Pod Disruption Budget (PDB)	🚀 Karpenter Disruption Budget
Scope	Protects individual pods	Controls node removal
Unit	`minAvailable` or `maxUnavailable` (pods)	`nodes` (count or %)
Enforced by	Kubernetes Eviction API	Karpenter's disruption controller
Location	Per workload (namespace + label selector)	Per NodePool
Decision	"Can I evict this pod?"	"Can I terminate this node?"
Time windows	❌ Not supported	✅ `schedule` + `duration`
Relationship	Karpenter respects PDBs when evicting pods	PDBs do not control node disruption rate

🔄 How They Work Together

1

Karpenter Budget

Karpenter checks: "Am I disrupting too many nodes?"

▼

2

If within budget

Cordon node → begin pod eviction

3

PDB Check

Eviction API checks: "Will PDB be violated?"

▼

4

Eviction result

✅ Allowed → delete pod

❌ Denied → 429, Karpenter retries

Key insight: You need both. PDBs protect your application's pod availability. Karpenter budgets protect cluster stability from too many simultaneous node replacements.

✅ Best Practices

🛡️ Always pair with PDBs

Set minAvailable: 1 or higher for every critical deployment. Karpenter will never violate your PDB.

📊 Start conservative

Begin with nodes: 1 or nodes: "10%". Gradually increase as you gain confidence.

🕐 Use schedule budgets

Allow aggressive consolidation (nodes: "50%") during off-peak hours with schedule budgets.

🔒 Block during critical windows

Set nodes: "0" during business hours for Drifted/UnderUtilized reasons if needed.