Beyond Your Bill — selected guide
Autoscaling with GKE: Overview and pods
Eleven episodes on resource ownership, billing analysis, budgets, commitments, and GKE efficiency
Eleven 2019–2021 episodes explain who owns cloud spending, how to analyze it, and where commitments and GKE sizing can reduce waste. Budget alerts notify teams; they do not impose a spending cap.
Google Cloud Tech 8 of 11
In this collection Browse 11 summaries 8 of 11
Autoscaling adds capacity when demand rises and removes it when demand falls. This 2020 Google Kubernetes Engine (GKE) episode compares adding more pods—units running containerized applications—with giving each pod more CPU or memory, and explains why both choices depend on application behavior.
Key Points Covered
- Horizontal scaling spreads work across more copies. The Horizontal Pod Autoscaler compares a demand metric, such as average CPU use or requests per second, with a target. Adding pods should lower the work per pod. Spare capacity must cover startup time: too little risks overload during spikes, while too much wastes money. 01:02–03:08(opens in a new tab)
- Vertical scaling changes the resources per pod. In the behavior shown, the Vertical Pod Autoscaler recommends CPU and memory sizes and can apply them when pods are created or by deleting and recreating pods. A workload must tolerate those restarts and actually benefit from more resources; extra CPU may not help a single-threaded application. 03:08–05:15(opens in a new tab)
- Two autoscalers can react to the same change. The presenter warns against both controllers changing capacity based on the same CPU or memory signal. The alternatives shown are keeping vertical scaling in recommendation-only mode or using a different horizontal metric, such as requests per second. 05:15–07:02(opens in a new tab)
Full video: https://www.youtube.com/watch?v=7naCIxIaV1M(opens in a new tab)