Part 2 of a 3-part series on porting EKS/Karpenter autoscaling patterns to GKE. Part 1 covered the core mental model — a solver searching a space versus an author ranking a list. Part 3 covers accelerators, reservations, and tenant isolation.
Part 1 of a 3-part series on porting EKS/Karpenter autoscaling patterns to GKE. Part 2 covers instance diversity and disruption control; Part 3 covers accelerators, reservations, and tenant isolation.
I’ve spent the last couple of posts trying to get autoscaling knowledge out of my head and onto the page — the ComputeClasses primer, then the curate-or-auto-create follow-up. And every time I finish one, I run into the same wall: a blog post is something you read. It sits there. The person who actually needs it is three Slack threads deep at 11pm with pods stuck Pending, and they are not going to stop and read a primer.
Every GKE platform team I talk to lands somewhere on the same spectrum. On one end are the curators: they hand-build node pools, tune every kubelet flag, pin the machine type to a reservation, and they do not want anything provisioning nodes they didn’t bless. On the other end are the automators: they never want to see a node pool again, and they’ll trade a little control for capacity that just shows up when a workload needs it.
I’m a Product Manager on GKE, and I spend a lot of my time with platform teams who are tired of the node pool tax. You sit down to “just run a workload,” and somehow you’re back in the console hand-crafting a node pool: pick a machine type, set min and max, decide on Spot or on-demand, wire up taints and labels, and pray you guessed the shape right. Then traffic changes, or that machine family runs out of capacity in your zone, and you’re back doing it again.
