Suppose you increase an application’s replicas, but the new Pods remain Pending because the cluster has no room for them. Cluster autoscaling addresses the node side of that problem: when more capacity is needed, a provider-supported autoscaler can add nodes so the Pods can run. Unlike changing the replica count, it changes the capacity available to run replicas. section 6.1 section 6.3.1
Cluster autoscaling is optional, not part of the base Kubernetes API. Availability and behavior depend on the provider. GKE Autopilot provisions and scales nodes without further configuration; GKE node-pool clusters can enable autoscaling when a pool is created or updated. Check provider documentation for limits, particularly when a Pod is too large for available node configurations. Some autoscalers can add only predefined node types; GKE Autopilot and node-based clusters with Node Auto Provisioning can add other types. section 6.3.1
Pair cluster autoscaling with HorizontalPodAutoscaler for a more hands-off deployment: one can add Pods as workload demands, while the other supplies nodes when those Pods need space. Node autoscaling can also remove unneeded capacity, but a tightly scaled cluster may have no room ready for the next Pod. That Pod must wait for a node to be provisioned and booted before it can start. section 6.3.1 section 6.3.2
Keep capacity ready with placeholder Pods
Deploy low-priority Pods that do no work but request CPU and memory. They keep capacity in the cluster; when regular Pods arrive, those Pods can preempt the placeholders and use the space. Size each placeholder’s requests to fit at least your largest regular Pod, and choose the replica count to reserve the headroom you need. Regular Pods must have a higher priority that permits them to preempt lower-priority Pods. section 6.3.2
Listing 6.10 Chapter06/6.3.2_PlaceholderPod/placeholder-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: placeholder
spec:
replicas: 10 #1
selector:
matchLabels:
pod: placeholder-pod
template:
metadata:
labels:
pod: placeholder-pod
spec:
priorityClassName: placeholder-priority #2
terminationGracePeriodSeconds: 0 #3
containers:
- name: ubuntu
image: ubuntu
command: ["sleep"] #4
args: ["infinity"] #4
resources:
requests:
cpu: 200m #5
memory: 250Mi #5
This Deployment makes the trade-off concrete: ten low-priority, sleeping replicas each request 200m CPU and 250Mi memory to hold capacity ready. section 6.3.2
