vsz

GKE 1.36.4 gives ComputeClasses a real status surface: per-priority conditions with backoff timers, a node annotation that names the priority rule that provisioned it, and an audit-log trail that outlives the nodes themselves. This has been the longest-standing gap in the API, and it’s worth an afternoon of your time to get functional with it.

A new cluster-scoped CRD lets you cap autoscaling by node attribute — machine family, accelerator type, zone, ComputeClass — rather than by namespace. It closes a gap ResourceQuota was never shaped to fill, and it lands upstream in kubernetes/autoscaler, not only in GKE.

Part 3 of a 3-part series on porting EKS/Karpenter autoscaling patterns to GKE. Part 1 covered the mental model — a solver searching a space versus an author ranking a list. Part 2 covered diversity, consolidation, and the where/when split between ComputeClass and WorkloadClass. This one is the expensive end of the fleet, plus the promised answer on portability.

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.

[Image attribution: Dan Maharry ] Last time, we looked at Google Cloud Code’s “Run as Kubernetes” - aka Skaffold - as an elegant way to develop and iterate a Kubernetes application locally. We saw how Skaffold configuration could be used to abstract the build and local deployment process. But we were left with aching questions like:

[Cover Image: my old FJ60] Until recently, I drove an old 80s FJ60 Land Cruiser. Cool, you say? Yes, it was. It was also a lot of work. I did most of that work myself including a carburetor rebuild, head rebuild, radiator, knuckle rebuild, brakes, wiring - you name it. And I learned an awful lot in that process; not just about the Land Cruiser but also about cars, their maintenance, and the tools involved. There was joy, there were tears, too.