A placeholder Pod keeps spare cluster capacity available before a traffic spike. It reserves resources on running nodes but performs no application work. When a real workload needs those resources, Kubernetes preempts the lower-priority placeholder, allowing the workload to start without waiting for new nodes to boot. section 6.3.2
Configure the pattern around three operational decisions:
- Create a PriorityClass below zero so regular workloads can preempt the placeholders. section 6.3.2
- Run a do-nothing Deployment with enough replicas and resource requests to represent the capacity you want standing by. section 6.3.2
- Ensure ordinary workloads use a higher priority and allow preemption; the default priority of 0 does this when configured to preempt lower-priority Pods. section 6.3.2
- Size each placeholder at least as large as the largest regular Pod, while using more replicas instead of excessively large placeholders when reserving extra capacity. section 6.3.2
Fast burst capacity
A cluster autoscaler that keeps costs low may leave no spare capacity. A new workload then waits for a node to be provisioned and booted. With placeholder Pods already occupying standby capacity, the workload preempts them and starts on existing nodes while the autoscaler can adjust the cluster afterward. section 6.3.2 section 6.0
Figure 6.3 Autoscaling with a placeholder Pod, allowing for rapid booting of new Pods using spare capacity
Use the diagram to compare ordinary node provisioning with placeholder-based preemption and rapid workload startup. section 6.3.2
