Scaling Kubernetes nodes from zero can save costs but introduces startup delays. When using autoscalers like Cluster Autoscaler or Karpenter, the time from detecting an unschedulable pod to having a node ready can take anywhere from 60 seconds to several minutes. For example, on AWS, one pod took 59 seconds to be scheduled, while another on the same node started almost instantly. This latency can negatively impact customer experience, particularly if applications need to provision new pods for each user. To mitigate these delays, pre-provisioning nodes becomes essential. Karpenter allows users to specify static node counts, while AWS’s Cluster Autoscaler enables setting minimum and maximum node limits. However, these options have limitations based on cloud provider capabilities. A more flexible approach involves using placeholder pods, which can either reserve nodes or overprovision them. Reservation placeholders are lightweight pods that maintain larger nodes, while overprovisioning placeholders are low-priority pods that can be evicted for higher-priority workloads. The choice between reservation and overprovisioning depends on the workload's predictability. Reservation is ideal when the workload size and timing are known, like launching a new feature that anticipates a spike in user activity. Overprovisioning is better suited for unpredictable workloads, ensuring that each user gets quick access to resources, such as in applications that provide isolated sandboxes on demand. In summary, using placeholders effectively can significantly reduce the delays associated with scaling nodes in Kubernetes environments.