Capaciteit voelt pas nuttig als je weet wat je ermee oplost
Een team dat “meer” kan draaien, is niet automatisch een team dat beter schaalt.
Een actueel bericht over September 25, 2026 is hier de context. Het nieuws is niet het punt; het maakt de operationele beslisdruk zichtbaar.
Dat zie je vaak pas op het moment dat de infra eindelijk meewerkt en de rest van het systeem begint te piepen. Niet in CPU, maar in IP-adressen. Niet in compute, maar in operability. En dan blijkt dat de echte rem nooit de node was, maar het ontwerp eromheen.
Google’s update van 25 september 2026 is daar een scherp voorbeeld van. GKE Standard-clusters ondersteunen nu tot 512 pods per node, waar dat eerder 256 was. Voor nodes tussen 257 en 512 pods wordt een /22 Pod CIDR-block toegewezen: 1.024 IP-adressen voor één node. Dat is een nuttig detail, maar vooral een signaal. Meer dichtheid vraagt meteen om meer adresruimte, meer netwerkplanning en meer aandacht voor de operationele kant van je platform.
Wat je eerst zou checken voordat je dit een verbetering noemt
Als ik zo’n wijziging zie, is mijn eerste vraag niet: kunnen we nu verdubbelen?
Mijn eerste check is: waar zit de bottleneck eigenlijk vandaag?
In veel teams wordt pod-dichtheid behandeld alsof het een simpele efficiëntiewinst is. Meer pods per node, dus minder nodes, dus goedkoper of netter. Maar die redenering is alleen waar als pod-dichtheid ook echt de beperkende factor was. In de praktijk zie je vaak iets anders:
- de workload is memory-bound, niet density-bound;
- de cluster is al krap op IP-ruimte;
- scheduling wordt onvoorspelbaar door resource-spreiding;
- observability en incident response worden zwaarder omdat meer workloads op minder nodes samenkomen.
Dan verplaats je het probleem. Je lost niet op dat het systeem volloopt; je centraliseert het alleen.
Dat is geen technisch detail. Dat is platformontwerp.
Meer pods per node betekent ook meer gewicht per beslissing
Een node met 512 pods is niet alleen een node met “meer capaciteit”. Het is ook een node met een grotere blast radius, meer afhankelijkheden per failure domain en een zwaardere eis aan je operationele volwassenheid.
Dat hoeft geen bezwaar te zijn. Soms is het precies wat je wilt, bijvoorbeeld bij workloads die goed te consolideren zijn en weinig netwerkverrassing hebben. Maar het is wel een keuze met consequenties. Je koopt dichtheid in, en je betaalt met complexiteit elders.
Dat zie je vooral in teams die al op de grens draaien. De release note leest dan als goed nieuws, maar in de praktijk betekent het dat je netwerkmodel, allocatiepatroon en monitoring mee moeten bewegen. Een /22 Pod CIDR voor nodes boven 256 pods klinkt als een nette technische oplossing. Tegelijk zegt het ook: dit is geen gratis verdubbeling. De adresruimte en de planning eromheen worden onderdeel van de schaalvraag.
En precies daar gaat het vaak mis in softwareorganisaties: capaciteit wordt als eindpunt behandeld, terwijl het eigenlijk alleen een verschuiving van druk is.
De zakelijke fout is niet te weinig capaciteit, maar te snel vertrouwen op capaciteit
Voor softwareleiders is dit herkenbaar. Er komt een ticket, een incident, een roadmapdruk of een klantvraag. Het platformteam ziet een knelpunt en wil ruimte creëren. Logisch. Maar als je dan alleen de grens opschuift, zonder te weten wat die grens definieerde, maak je het volgende probleem groter of moeilijker zichtbaar.
Dat is waarom ik bij dit soort updates eerst naar de echte bottleneck kijk, niet naar de headline. Is het CPU? Is het memory? Is het IP-ruimte? Is het scheduling? Of is het de vraag of je platformteam de extra operationele last nog wil dragen?
Bij GKE is die vraag nu extra relevant, omdat Google niet alleen een limiet optrekt naar 512 pods per node, maar er ook expliciet een nieuw adresblok aan koppelt. Dat is een hint uit de bron zelf: schaal is hier niet één knop. Het is een samenhang van netwerk, capaciteit en beheer.
Wie dat leest als “mooi, we kunnen meer”, mist de tweede helft van het verhaal.
Wat dit mij zegt over volwassen platformteams
Volwassen teams jagen niet op maximale dichtheid. Ze kiezen een dichtheid die past bij hun werkelijke patroon.
Dat klinkt minder spectaculair dan “512 pods per node”, maar het is meestal ook waar de winst zit. Niet in het uiterste opzoeken, maar in het juiste evenwicht tussen benutting en beheersbaarheid. Een platform dat te vol wordt gepropt, wordt zelden echt efficiënter. Het wordt alleen moeilijker om problemen te isoleren.
Daarom vind ik deze release interessant als signaal, niet als uitnodiging om overal meteen hoger te gaan. De technische mogelijkheid is er. De vraag is alleen of jouw systeem er ook beter van wordt.
Mijn standpunt is simpel: verhoog capaciteit pas als je hebt vastgesteld dat capaciteit de rem is. Anders optimaliseer je het verkeerde onderdeel van je platform en noem je dat vooruitgang.
Dat is zelden het hele spel. Maar het is wel vaak de eerste fout die teams maken als de infra ineens meer kan dan het team al had uitgelegd aan zichzelf.