Gisteren zag Kubernetes 1.16 het levenslicht. Met ongeveer 4 major releases per jaar ligt het tempo hoog. Toch is het verstandig om enigszins bij te blijven. In dit artikel beschrijf ik de voor-en nadelen van het continu bijwerken van je platform. Daarnaast licht ik nog specifiek wat veranderingen van de huidige nieuwe release toe.
Upgrade planning
Bij een nieuwe release is het belangrijk om de wijzigingen goed te leren kennen. Zelf ben ik direct op de hoogte van nieuwe releases doordat ik op Github releases “watch”. Hierdoor ben ik bij elke nieuwe release direct op de hoogte van de wijzigingen. In eerste instantie lees ik dan de release notes en de changelog om me een beeld te vormen. Voor versie 1.16 kan je he volledige verhaal vinden op: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.16.md
Major upgrades van Kubernetes clusters gaan tegenwoordig best soepel. Het lezen van de changelog wordt dan ook vaak niet gedaan door veel mensen. Dit is verleidelijk maar toch wijs ik gebruikers van onze platformen er elke keer op dat het erg verstandig is om ze te lezen. Naast nieuwe features en verbeteringen zijn er namelijk ook breaking changes. Soms gaat dit gefaseerd en zal iets eerst “deprecated” raken voordat iets echt verdwijnt. In andere keren zul je merken dat de volgende release echt breekt met een oude werkwijze. Je kan er maar beter op voorbereid zijn!
Brekende veranderingen
Per use case verschilt het natuurlijk wat je tegen komt. De een zal bepaalde features niet gebruiken en dus niet merken dat iets veranderd is. De ander zal tegen problemen aanlopen. Als je bijvoorbeeld Kubernetes metrics verzamelt met Prometheus en visualiseert met Grafana, zul je zien dat er mogelijk iets krak zegt na de upgrade. Zo zal Prometheus de labels “pod_name” en “container_name” niet meer kunnen vinden omdat ze vervangen zijn door “pod” en “container”. Als het verzamelen van metrics niet meer gaat is dat vaak jammer maar niet extreem vervelend. De applicatie zelf draait immers gewoon door. Zo’n upgrade kan echter ook daar invloed hebben. Resources die onder “apps/v1beta1” of “apps/v1beta2” vallen, moeten hernoemd worden naar “apps/v1”. Geen schokkende wijziging dus maar het gaat wel stuk als je er geen rekening mee houdt!
Nieuwe features
Daarnaast kunnen er nog nieuwe features zijn waar je al tijden op zit te wachten. Zo kan vanaf release 1.16 Dual stack (via Kubernetes IP address management (IPAM)) geconfigureerd worden waardoor je pods of services zowel een IPv4 als IPv6 adres kunnen krijgen. Dit is best een ingrijpende verandering die ik zelf niet zomaar op een bestaand productie cluster zou instellen. Het is natuurlijk ook maar de vraag of je het nodig hebt.
Tot slot
Het is tijdrovend om goed op de hoogte te blijven als er per jaar 4 nieuwe releases zijn. Toch is het belangrijk om bij te blijven. Je ziet dat in de loop van de tijd bijvoorbeeld meer mensen tegen de zelfde problemen aanlopen en dat er uiteindelijk ook oplossingen komen in de community. Door actief met je platform bezig te zijn zul je zien dat de upgrades en de daarbij komende veranderingen soepeler verlopen. Dit geldt zowel voor de Dev als Ops kant. Vaker een kleinere verandering is nou eenmaal makkelijker te behappen dan slechts af en toe een grote. Zorg er ook voor dat je naast een productieplatform een gescheiden testplatform hebt. Het cluster overleeft de upgrade wel maar de yaml definities van je workloads of bijvoorbeeld de visualisaties van je metrics misschien niet. Een testcluster geeft je meer zekerheid zodat je productieplatform dit soort wijzigingen eenvoudiger doorstaat.
Auteur: Geurt Hakfoort – Cloud Specialist Denit
