<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Autoscaling on vsz@ | Kubernetes, AI, tech stuff</title><link>https://victorszalvay.com/tags/autoscaling/</link><description>Recent content in Autoscaling on vsz@ | Kubernetes, AI, tech stuff</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>Victor Szalvay — All rights reserved</copyright><lastBuildDate>Fri, 05 Jun 2026 09:00:00 -0700</lastBuildDate><atom:link href="https://victorszalvay.com/tags/autoscaling/index.xml" rel="self" type="application/rss+xml"/><item><title>A primer on GKE ComputeClasses</title><link>https://victorszalvay.com/gke-compute-classes-primer/</link><pubDate>Fri, 05 Jun 2026 09:00:00 -0700</pubDate><guid>https://victorszalvay.com/gke-compute-classes-primer/</guid><description>&lt;p&gt;I&amp;rsquo;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 &amp;ldquo;just run a workload,&amp;rdquo; and somehow you&amp;rsquo;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&amp;rsquo;re back doing it again.&lt;/p&gt;</description><media:content xmlns:media="http://search.yahoo.com/mrss/" url="https://victorszalvay.com/gke-compute-classes-primer/cover.jpg"/></item></channel></rss>