DevOps & Kubernetes (50 Qs)•Part 3: Production K8s Scaling, Reliability & SRE (26 - 35)
Cluster Autoscaling & Karpenter: Kubernetes Cluster Autoscaler vs. Karpenter just-in-time node provisioning.
Node Autoscaling: The Paradigm Shift
When Pods cannot schedule due to insufficient CPU/Memory (PodStatus: Pending), a cluster autoscaler must launch new virtual machines.
ini
1. Legacy Kubernetes Cluster Autoscaler:
[ Pending Pod ] ---> [ K8s Autoscaler ] ---> [ AWS Auto Scaling Group (ASG) ] ---> [ EC2 Launch ]
Bottleneck: Bound to static ASG node groups; takes 3-7 minutes to initialize and join.
2. Modern Karpenter Architecture:
[ Pending Pod ] ---> [ Karpenter Controller ] === Direct AWS API (RunInstances) ===> [ EC2 Launch ]
Advantages: No ASGs; launches heterogeneous mixed Spot/On-Demand in 30-45 seconds; auto-consolidation.
Architectural Comparison
| Feature | Kubernetes Cluster Autoscaler (CAS) | Karpenter (Next-Gen Autoscaler) |
|---|---|---|
| Cloud Integration | Interacts indirectly through cloud Auto Scaling Groups (ASGs). | Calls cloud provider APIs (ec2:RunInstances) directly; zero ASGs required. |
| Provisioning Speed | 3 to 8 minutes per node. | 30 to 60 seconds per node. |
| Instance Selection | Pre-configured in fixed instance types per node group (e.g. only m5.large). | Dynamically chooses optimal instance family, size, architecture (x86 vs ARM Graviton), and pricing model (Spot vs On-Demand) based on pending Pod specs. |
| Node Consolidation | Basic scale-down if node utilization drops below threshold for 10 minutes. | Actively packs pods onto fewer or smaller instances (bin-packing consolidation) to continuously reduce cloud spend. |