The promise of Kubernetes was always “deploy anywhere, scale automatically.” The reality was years of kubectl cordon, manual node group sizing, and 3am PagerDuty alerts about cluster autoscaler lag. That gap is closing fast. In 2026, the combination of Karpenter, KEDA, and managed control planes is delivering on the original promise.

Photo by Growtika on Unsplash

The Old Way vs. The New Way

Old way: Define node groups → set min/max → hope your workload fits → overprovision to be safe → pay for idle capacity.

New way: Define what your workloads need → let the system provision the right nodes on demand → scale to zero when idle.

This isn’t theoretical. Teams are reporting 40–60% cost reductions moving from static node groups to Karpenter-driven dynamic provisioning.

Karpenter: Node Provisioning Done Right

Karpenter replaces the Cluster Autoscaler with a fundamentally different approach. Instead of scaling predefined node groups, it looks at pending pods and provisions the exact node type those pods need.

Installation

# Add Karpenter to your EKS cluster
helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter \
  --version "1.0.6" \
  --namespace karpenter \
  --create-namespace \
  --set "settings.clusterName=${CLUSTER_NAME}" \
  --set "settings.interruptionQueue=${INTERRUPTION_QUEUE}" \
  --set controller.resources.requests.cpu=1 \
  --set controller.resources.requests.memory=1Gi

NodePool Configuration

This is where the magic happens. You define constraints, not specific instance types:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    metadata:
      labels:
        intent: apps
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default
      requirements:
        - key: "karpenter.k8s.aws/instance-category"
          operator: In
          values: ["c", "m", "r"]
        - key: "karpenter.k8s.aws/instance-cpu"
          operator: In
          values: ["4", "8", "16", "32"]
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot", "on-demand"]    # Spot first, fallback to on-demand
        - key: "kubernetes.io/arch"
          operator: In
          values: ["amd64", "arm64"]       # Support Graviton too
  limits:
    cpu: 1000
  disruption:
    consolidationPolicy: WhenUnderutilized
    consolidateAfter: 30s    # Aggressive consolidation

Key insight: the consolidateAfter: 30s means Karpenter actively merges underutilized nodes together. Your cluster gets smaller when load drops — automatically.

Spot Instance Handling

Karpenter handles Spot interruptions gracefully. When AWS sends a 2-minute interruption notice, Karpenter:

1. Cordons the node
2. Triggers pod disruption budgets
3. Provisions replacement capacity
4. Drains the interrupted node

# EC2NodeClass for Spot-aware provisioning
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiSelectorTerms:
    - alias: al2023@latest
  subnetSelectorTerms:
    - tags:
        karpenter.sh/discovery: "${CLUSTER_NAME}"
  securityGroupSelectorTerms:
    - tags:
        karpenter.sh/discovery: "${CLUSTER_NAME}"
  instanceStorePolicy: RAID0   # Use NVMe instance store for temp data

KEDA: Event-Driven Autoscaling

Karpenter handles nodes. KEDA handles pods — and it goes far beyond CPU/memory metrics.

KEDA can scale your deployments based on:

• Queue depth (SQS, Kafka, RabbitMQ, Azure Service Bus)
• Database query results
• Prometheus metrics
• HTTP request rate
• Cron schedules
• External APIs

Scale-to-Zero for Batch Workloads

This is KEDA’s killer feature. Spin up workers only when there’s work to do:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: sqs-consumer
spec:
  scaleTargetRef:
    name: message-processor
  minReplicaCount: 0        # Scale to ZERO when queue is empty
  maxReplicaCount: 50
  pollingInterval: 15
  cooldownPeriod: 60
  triggers:
    - type: aws-sqs-queue
      metadata:
        queueURL: https://sqs.us-east-1.amazonaws.com/123456789/my-queue
        queueLength: "5"      # 1 pod per 5 messages
        awsRegion: us-east-1
      authenticationRef:
        name: keda-aws-credentials

When the SQS queue is empty: 0 pods, 0 nodes (Karpenter consolidates). When messages arrive: pods spin up within seconds, Karpenter provisions nodes as needed.

Kafka-Driven Microservices

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: kafka-consumer-scaler
spec:
  scaleTargetRef:
    name: kafka-consumer-deployment
  triggers:
    - type: kafka
      metadata:
        bootstrapServers: kafka-broker:9092
        consumerGroup: my-consumer-group
        topic: events
        lagThreshold: "100"     # Scale up when lag > 100 messages
        offsetResetPolicy: latest

Photo by NASA on Unsplash

The Full Stack: Putting It Together

Here’s the architecture that’s becoming standard in 2026:

Workload arrives (HTTP/queue/event)
    ↓
KEDA detects demand → scales pods from 0
    ↓
Kubernetes scheduler → pods are Pending (no nodes)
    ↓
Karpenter → provisions right-sized node in ~45s
    ↓
Pods start processing
    ↓
Demand drops → KEDA scales pods to 0
    ↓
Karpenter consolidates → node terminates
    ↓
Cost: $0 at idle

Observability for Dynamic Clusters

With constantly changing infrastructure, observability becomes critical:

# Add node lifecycle events to your dashboards
- alert: KarpenterNodeProvisioningDelay
  expr: |
    histogram_quantile(0.95, 
      karpenter_nodes_provisioner_scheduling_duration_seconds_bucket
    ) > 120
  for: 5m
  annotations:
    summary: "Node provisioning taking >2 minutes at p95"

Key metrics to track:

• Node provisioning latency — should be <90s in normal conditions
• Pod scheduling latency — total time from pending to running
• Spot interruption rate — affects workload continuity planning
• Consolidation efficiency — % of time nodes are well-utilized

When Serverless Kubernetes Isn’t the Answer

Be honest about the tradeoffs:

• Latency-sensitive workloads — cold starts (45-90s node provisioning) can hurt
• Stateful workloads — databases, Kafka brokers benefit from stable nodes
• GPU workloads — Karpenter supports GPU instances, but provisioning time is longer
• Regulatory environments — spot instances introduce availability risk

For these, keep static node groups. The beauty of Karpenter is you can mix — static groups for stable workloads, dynamic provisioning for burst.

Conclusion

Serverless Kubernetes in 2026 is real, production-ready, and delivering genuine cost savings. The combination of Karpenter (right nodes, right time) and KEDA (right pods, right time) means you can run infrastructure that scales to zero at idle and handles spikes automatically. The node management toil that defined Kubernetes operations for years is becoming optional.

Your future self at 3am will thank you.

이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :)