<div id="readability-page-1" class="page"><div><img src="https://devstarsj.github.io/assets/https://images.unsplash.com/photo-1667372393119-3d4c48d07fc9?w=1200&amp;q=80">The promise of Kubernetes was always “deploy anywhere, scale automatically.” The reality was years of <code>kubectl cordon</code>, 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.<img src="https://images.unsplash.com/photo-1667372393119-3d4c48d07fc9?w=900&amp;q=80" alt="Kubernetes infrastructure visualization"> Photo by <a href="https://unsplash.com/@growtika">Growtika</a> on Unsplash<h2 id="the-old-way-vs-the-new-way">The Old Way vs. The New Way</h2>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.<h2 id="karpenter-node-provisioning-done-right">Karpenter: Node Provisioning Done Right</h2>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.<h3 id="installation">Installation</h3><div><pre><code># 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
</code></pre></div><h3 id="nodepool-configuration">NodePool Configuration</h3>This is where the magic happens. You define constraints, not specific instance types:<div><pre><code>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
</code></pre></div>Key insight: the <code>consolidateAfter: 30s</code> means Karpenter actively merges underutilized nodes together. Your cluster gets smaller when load drops — automatically.<h3 id="spot-instance-handling">Spot Instance Handling</h3>Karpenter handles Spot interruptions gracefully. When AWS sends a 2-minute interruption notice, Karpenter:<ol><li>Cordons the node</li><li>Triggers pod disruption budgets</li><li>Provisions replacement capacity</li><li>Drains the interrupted node</li></ol><div><pre><code># 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
</code></pre></div><h2 id="keda-event-driven-autoscaling">KEDA: Event-Driven Autoscaling</h2>Karpenter handles nodes. KEDA handles pods — and it goes far beyond CPU/memory metrics.KEDA can scale your deployments based on:<ul><li>Queue depth (SQS, Kafka, RabbitMQ, Azure Service Bus)</li><li>Database query results</li><li>Prometheus metrics</li><li>HTTP request rate</li><li>Cron schedules</li><li>External APIs</li></ul><h3 id="scale-to-zero-for-batch-workloads">Scale-to-Zero for Batch Workloads</h3>This is KEDA’s killer feature. Spin up workers only when there’s work to do:<div><pre><code>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
</code></pre></div>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.<h3 id="kafka-driven-microservices">Kafka-Driven Microservices</h3><div><pre><code>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 &gt; 100 messages
 offsetResetPolicy: latest
</code></pre></div><img src="https://images.unsplash.com/photo-1451187580459-43490279c0fa?w=900&amp;q=80" alt="Cloud infrastructure scaling"> Photo by <a href="https://unsplash.com/@nasa">NASA</a> on Unsplash<h2 id="the-full-stack-putting-it-together">The Full Stack: Putting It Together</h2>Here’s the architecture that’s becoming standard in 2026:<div><pre><code>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
</code></pre></div><h2 id="observability-for-dynamic-clusters">Observability for Dynamic Clusters</h2>With constantly changing infrastructure, observability becomes critical:<div><pre><code># Add node lifecycle events to your dashboards
- alert: KarpenterNodeProvisioningDelay
 expr: |
 histogram_quantile(0.95, 
 karpenter_nodes_provisioner_scheduling_duration_seconds_bucket
 ) &gt; 120
 for: 5m
 annotations:
 summary: "Node provisioning taking &gt;2 minutes at p95"
</code></pre></div>Key metrics to track:<ul><li>Node provisioning latency — should be &lt;90s in normal conditions</li><li>Pod scheduling latency — total time from pending to running</li><li>Spot interruption rate — affects workload continuity planning</li><li>Consolidation efficiency — % of time nodes are well-utilized</li></ul><h2 id="when-serverless-kubernetes-isnt-the-answer">When Serverless Kubernetes Isn’t the Answer</h2>Be honest about the tradeoffs:<ul><li>Latency-sensitive workloads — cold starts (45-90s node provisioning) can hurt</li><li>Stateful workloads — databases, Kafka brokers benefit from stable nodes</li><li>GPU workloads — Karpenter supports GPU instances, but provisioning time is longer</li><li>Regulatory environments — spot instances introduce availability risk</li></ul>For these, keep static node groups. The beauty of Karpenter is you can mix — static groups for stable workloads, dynamic provisioning for burst.<h2 id="conclusion">Conclusion</h2>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. <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

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:
Cordons the node
Triggers pod disruption budgets
Provisions replacement capacity
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.

Serverless Kubernetes in 2026: Karpenter, KEDA, and the Death of Node Management

댓글