Autoscaling policies, health checks, GPUs and TPUs

Speaker notes

• An autoscaling policy can combine CPU utilization, a custom Cloud Monitoring metric, and a schedule — when signals disagree, the autoscaler always takes the LARGER recommendation, biasing toward availability over cost. scale-in-control caps how fast a group can shrink per evaluation, preventing the flapping pattern of scale-in immediately followed by scale-back-up.
• A health check's four timing parameters (interval, timeout, healthy/unhealthy thresholds) trade detection speed against false-positive risk — a too-aggressive check misreads a harmless GC pause or reboot blip as a real failure and triggers an unnecessary, potentially cascading instance recreation.
• GPUs attach to specific compatible machine types and require --maintenance-policy=TERMINATE since live migration isn't supported for GPU-attached VMs; TPUs are Google's own custom silicon for ML training/inference, provisioned as their own dedicated resource type rather than an accelerator bolted onto a general-purpose VM.

Deck map