Kubernetes autoscaling: meeschalen met je verkeer, niet met je hoop

De HPA rekent in procenten van de request, niet van de node. Staat de CPU-request van een PHP-FPM-pod op 100m terwijl hij onder normale belasting 600m gebruikt, dan staat de HPA permanent op maximaal. Staat de request op 2 cores terwijl hij er 0,3 gebruikt, dan schaalt hij nooit, en betaal je voor lucht. Autoscaling begint dus met meten.

We draaien de VPA eerst in Off-modus, of lezen het verbruik uit Prometheus, over minimaal een week met normaal verkeer. Daarop zetten we de requests. Voor geheugen kiezen we bij PHP een limit gelijk aan de request. PHP-FPM-geheugen groeit met het aantal actieve workers, en een node die geheugen overboekt, gaat pods killen op het slechtste moment.

Bij CPU zijn we terughoudend met limits. Een CPU-limit leidt tot throttling: de container krijgt zijn quotum niet en wacht, ook als de node vrije capaciteit heeft. Bij PHP zie je dat als willekeurig trage requests. We meten throttling per container en zetten een CPU-limit alleen waar je een luidruchtige buur moet afschermen.

De andere helft zit in de container. pm.max_children in PHP-FPM bepaalt hoeveel requests één pod tegelijk aankan. Die waarde moet passen bij de geheugenlimit: max_children maal het geheugen per worker, plus de basis. Te hoog en de pod gaat OOM. Te laag en de pod weigert werk terwijl de CPU laag staat, en dan schaalt een CPU-HPA ook niet. Dan schalen we op PHP-FPM-bezetting via een custom metric.

Een ScaledObject voor Laravel ziet er in de kern zo uit: scaleTargetRef wijst naar de Deployment met queue-workers, minReplicaCount 1, maxReplicaCount 15, en een trigger van type redis met listName queues:orders en listLength 20. Bij 200 wachtende jobs wil KEDA dan tien workers. Het maximum kiezen we niet op gevoel, maar op wat de database en externe API's aankunnen. Twintig workers die tegelijk het ERP aanroepen, kunnen dat ERP platleggen.

Workers moeten netjes kunnen stoppen. Bij afschalen krijgt een pod een SIGTERM. Laravel-workers en Horizon handelen dat af door de huidige job af te maken. We zetten terminationGracePeriodSeconds ruimer dan je langste normale job, en bij Magento-consumers een max-messages-waarde zodat processen regelmatig vers starten. Lange imports zetten we liever in een ScaledJob dan in een worker die halverwege wordt afgeschaald.

Pods schalen is zinloos als er geen node is om ze op te zetten. De cluster-autoscaler kijkt naar pods in Pending en voegt een node toe uit een vooraf gedefinieerde node group. Dat werkt bij vrijwel elke managed Kubernetes-aanbieder, van EKS, GKE en AKS tot Europese aanbieders zoals Scaleway en OVHcloud. Je kiest zelf de nodetypes per groep.

Karpenter kiest het nodetype zelf, op basis van wat de wachtende pods nodig hebben, en consolideert actief: halflege nodes worden leeggemaakt en vervangen door kleinere of minder nodes. Karpenter is ontstaan bij AWS en is daar het meest volwassen. Azure biedt node auto-provisioning in AKS, gebouwd op Karpenter. Bij andere aanbieders blijft de cluster-autoscaler meestal de keuze.

Een nieuwe node kost tijd: machine starten, aan het cluster koppelen, images ophalen. Reken op minuten, niet seconden. Daarom houden we buffer aan. Dat kan met een paar placeholder-pods met lage prioriteit die direct plaatsmaken voor echte pods, waarna de autoscaler op de achtergrond een nieuwe node bijzet. Consolidatie temperen we met PodDisruptionBudgets, zodat Karpenter of de cluster-autoscaler nooit alle webpods tegelijk verplaatst.

Kostenkant: autoscaling verlaagt vooral de rekening als je basislast laag en je pieken kort zijn. Bij een vlakke belasting levert het weinig op. Spot- of preemptible nodes kunnen goedkoper zijn voor queue-workers die tegen een onderbreking kunnen, maar niet voor je database of je enige Varnish-pod. Ons artikel over Kubernetes-kosten zet de posten op een rij.