Aflevering 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 de pod daarna weer verdwijnt.

Twee harde eisen. containerd 1.x moet eruit en cgroup v1 moet eruit. Allebei niet nieuw: failCgroupV1 staat sinds 1.35 standaard op true. Jan vertelt hoe dat bij kube-spray in de praktijk uitpakte. Een mismatch tussen de cgroup-driver van de kubelet en die van de runtime levert het vervelendste type storing op. Niet kapot, maar onvoorspelbaar, met de OOM killer die processen afschiet die er niets aan kunnen doen. Bij ACC ICT wordt zoiets standaard eerst getest en worden nodes vaak simpelweg vervangen door nieuwe machines in plaats van online geüpgraded.

containerd 2.0 verandert ook je security-defaults. Containers zonder host-netwerk of user namespaces mogen nu poorten onder 1024 binden zonder CAP_NET_BIND_SERVICE, en ping draaien zonder CAP_NET_RAW. Een afspraak van decennia oud, stilzwijgend versoepeld. Terug te draaien, maar je moet het nu bewust configureren.

Verder in deze aflevering: waarom Ubuntu geen excuus meer is, hoe een onbewaakte auto-update je zomaar een major containerd-versie kan opleveren, wat managed clusters wél en niet voor je regelen, en Jans terugkerende standpunt door de hele aflevering heen: het meeste hiervan is geen probleem zodra je je machines gewoon actueel houdt.

‍