#142 Kubernetes 1.37 Garhwal

Kubernetes 1.37 verscheen eind augustus onder de naam Garhwal, genoemd naar de Noord-Indiase regio waar de release lead zelf vandaan komt. Op papier een rustige release: 67 enhancements, waarvan zestien naar Stable, drieëntwintig naar Beta en zevenentwintig nieuw in Alpha. Jan constateert dat Kubernetes al een tijd steeds stabieler wordt en dat breaking changes zeldzamer worden. Goed nieuws, al maakt het de zoektocht naar een spannend verhaal voor een release-aflevering er niet makkelijker op. Deze keer valt er genoeg uit te diepen.

IPVS gaat eruit. Jan legt uit wat kube-proxy doet en waarom IPVS-mode, ooit geïntroduceerd omdat iptables te klein werd, nu zelf wordt uitgefaseerd. Het probleem is structureel: elke node draagt de IP-adressen van elke service. Bij twintig services merk je daar niks van, bij tweeduizend wel. In 1.43 verdwijnt IPVS volledig, maar het moment waarop je het gaat voelen ligt eerder. De praktische boodschap: stap over naar nftables vóór 1.40, en besef dat een upgrade dat niet voor je doet. Je moet het expliciet instellen.

iptables versus nftables. Een heldere uitleg van wat iptables eigenlijk is, namelijk firewall én routing op Linux met één lineaire regellijst die per pakket wordt doorlopen, en waarom dat in Kubernetes tegen een plafond loopt. De API ondersteunt geen incrementele updates, dus voor één regel moet de hele set opnieuw geladen worden. nftables gebruikt sets, maps en efficiëntere datastructuren, en biedt één uniform framework voor IPv4, IPv6, ARP en bridge filtering. Wel opletten: de twee zijn niet volledig compatibel met elkaar, en je hebt een recente kernel nodig.

Scale-to-zero is nu native. De HPA kan naar nul zonder dat je iets aan je bestaande configuratie hoeft te veranderen. Waar eerst één stond, kan nu nul staan. De afweging is opstarttijd bij de eerste request, maar als er niets draait betaal je ook niets. Jan wijst op het slimme detail: de HPA schaalt alleen terug omhoog als hij zelf naar nul is gegaan. Zet je de replicas handmatig op nul om iets immutables aan te passen, dan laat de autoscaler je met rust. Een herkenbare praktijkergernis, opgelost.

En KEDA dan? Ronald en Jan zetten ze naast elkaar en komen uit op complementair in plaats van concurrerend. KEDA's voordeel is dat het buiten het cluster kan kijken: een firewall of een externe dienst kan het signaal geven dat een pod moet starten. Jan schetst een bijna-serverless patroon waarin verkeer binnenkomt, KEDA de pod start, het request wordt afgehandeld en