Ik werk lang genoeg in deze sector om te herkennen hoe het einde van een tijdperk aanvoelt.
Het begint niet met een knal. Het begint met een gewaarwording. Een vermoeden dat wat men jarenlang deed niet fout is — maar niet meer volstaat. Dat de gereedschappen die me door de zwaarste nachten hielpen een grens hebben bereikt die men niet door ijver overschrijdt.
Ik spreek over infrastructuur. Over servers. Over de manier waarop we software draaien. En over Kubernetes — het gereedschap dat niet alleen een technologie maar een denkwijze heeft veranderd.
De oude wereld: servers als huisdieren
Vroeger was een server een individu. Men gaf hem een naam — vaak een held uit de mythologie, een planeet, een sterrenbeeld. Men kende zijn eigenaardigheden. Wist dat op apollo een oude kernel draaide omdat de custom-driver anders niet compileerde. Wist dat orion na een herstart eerst de RAID-controller moest initialiseren voordat de diensten opstartten. Wist dat pegasus ’s avonds om elf uur kort hing omdat daar een cronjob draaide die niemand gedocumenteerd had.
Deze servers waren huisdieren. Als ze ziek werden, verpleegde men ze. Logde in, onderzocht symptomen, tastte door logs, probeerde, draaide terug, probeerde opnieuw. Uren konden verstrijken. En als de server weer liep, was hij dezelfde als tevoren — met al zijn littekens, zijn workarounds, zijn onverklaarbare eigenaardigheden die alleen de administrator begreep die hem gebouwd had.
Dat werkte. Zolang het aantal servers beheersbaar bleef. Zolang de complexiteit houdbaar was. Zolang de administrator die alles kende niet op vakantie ging of het bedrijf verliet.
Toen kwamen Puppet, Chef, SaltStack. De eerste golf van automatisering. Plotseling kon configuratie in code uitgedrukt worden — declaratief, herhaalbaar, geversioneerd. Ansible volgde en maakte het toegankelijker: YAML-playbooks, SSH, geen agent. En later Terraform — cq. OpenTofu, de vrije fork — om niet alleen configuratie maar het bestaan van infrastructuur zelf te beschrijven: servers, netwerken, opslag, load balancers, alles als code.
Dat was enorme vooruitgang. Maar het was vooruitgang binnen hetzelfde paradigma. Servers bleven individuen — slechts beter gedocumenteerde, reproduceerbare individuen. Men bouwde ze sneller. Bouwde ze consistenter. Maar men bouwde nog steeds hen — vaste machines met vaste IP’s, vaste rollen, vaste afhankelijkheden.
De grens lag niet bij de gereedschappen. De grens lag bij het denken.
Het nieuwe paradigma: vee, kuddes, cellen
Kubernetes breekt met dat patroon radicaal. En dat is het punt waar veel administrators voor het eerst aarzelen.
In de Kubernetes-wereld zijn individuele servers geen individuen meer. Ze zijn anoniem, uitwisselbaar, vergeten. Een node is een node. Hij draagt geen betekenisvolle naam — alleen een UUID. Hij heeft geen persoonlijkheid. Hij heeft bronnen: CPU, RAM, opslag. Meer interesseert niet.
Wat erop draait zijn containers. En containers zijn de meest rigoureuze uitvoering van het vee-beginsel: behandel infrastructuur als vee. Een container die crasht wordt niet genezen. Ze wordt gedood. Kubernetes merkt de storing, gooit de kapotte instantie weg en start een verse kopie — ergens, op een beschikbare node. Binnen seconden. Zonder dat een mens het merkt.
Men maakt zich niet meer druk om welke server de code uitvoert. Men maakt zich alleen druk om het gewenste aantal kopieën dat draait. Wil men drie instanties en er crasht een, dan zorgt Kubernetes dat er weer drie draaien. Wil men er vijf en de last daalt, dan schaalt hij omlaag. Valt een hele node uit, dan verdeelt Kubernetes diens workloads over de resterende nodes — automatisch, zonder ingreep.
Dat is geen optimalisatie-feature. Het is een andere verhouding tot infrastructuur. Fundamenteel.
Zelfherstel
Hier wordt het concreet. Zelfherstel is in de oude wereld een wensdroom. In Kubernetes is het de standaardinstelling.
Een proces dat memory leekt wordt door het systeem herkend — OOMKilled, herstart. Een pod die zijn health checks niet meer doorstaat wordt als unhealthy gemarkeerd en vervangen. Een node die niet meer reageert wordt geëvacueerd; zijn pods migreren. CrashLoopBackOff is een staat die men kent — maar hij betekent dat het systeem al handelt, niet wacht.
In de oude wereld betekende “een dienst is down”: alarm, login, onderzoek, reparatie. In de nieuwe wereld betekent het vaak: helemaal niets. De dienst was down. Dertien seconden. En is er weer. De administrator hoort het uit het dashboard, niet uit het telefoontje om drie uur ’s nachts.
Dat verandert niet alleen de exploitatiekwaliteit. Het verandert de rol van de administrator. Van brandweerman tot architect. Van reageren tot ontwerpen.
Schalen
Schalen was vroeger een project. Servers bestellen, wachten, racken, kabels, installeren, configureren, in het loadbalancing opnemen. Weken. Maanden, als hardware schaars was.
Vandaag is schalen een parameter. Men zegt: “Ik wil tien replica’s in plaats van drie.” Kubernetes creëert ze, verdeelt ze, integreert ze. Horizontale Pod Autoscaling bewaakt CPU- en geheugenbelasting en schaalt automatisch bij. Cluster Autoscaler voegt hele nodes toe wanneer nodig — in de cloud of, als men het goed bouwt, in het eigen datacenter.
Wat vroeger een organisatietaak was — wie bestelt? wie keurt goed? wie installeert? — is vandaag een declaratieve aangifte. Een waarde in een YAML-bestand. Een regel die een keten van gebeurtenissen ontketent die vroeger een heel team bezighield.
Hoge beschikbaarheid
Hoge beschikbaarheid was vroeger duur. Redundante hardware, redundante netwerkpaden, clustersoftware, split-brain-risico’s, heartbeat-lijnen, STONITH-devices. Men bouwde het voor de kritiekste diensten — en bad dat de failover werkte als het eropaan kwam.
In Kubernetes is hoge beschikbaarheid een bijproduct van de architectuur. Drie replica’s van een dienst? Een op elk van drie nodes. Valt een node uit, twee overleven. Valt een tweede uit, een overleeft. Het systeem repliceert zichzelf zodra capaciteit beschikbaar is. Anti-affinity-regels zorgen dat instanties niet allemaal op dezelfde node belanden. PodDisruptionBudgets garanderen dat tijdens onderhoud steeds een minimum beschikbaar blijft.
Men definieert niet meer “hoe bereik ik beschikbaarheid”. Men definieert de voorwaarden waaronder beschikbaarheid moet ontstaan — en het systeem zorgt dat ze ontstaat. En blijft.
De leercurve — eerlijk
Nu wordt het ongemakkelijk. Wat ik tot nu toe beschreef klinkt als een belofte. En dat is het. Maar de weg ernaartoe is steil.
Kubernetes heeft een woordenveld dat overweldigend. Pods, Deployments, ReplicaSets, StatefulSets, DaemonSets, Services, Ingress, NetworkPolicies, ConfigMaps, Secrets, Namespaces, PersistentVolumeClaims, StorageClasses, ServiceAccounts, Roles, RoleBindings, ClusterRoles, CRDs, Operators, Helm Charts, Kustomize, kube-scheduler, kube-proxy, etcd, CNI, CSI, CRI — en elke term draagt semantiek die men moet begrijpen om hem juist in te zetten.
Dat is geen klacht. Het is de realiteit van een systeem dat een heel datacenter in software afbeeldt. Natuurlijk is het complex. Natuurlijk overweldigt het in het begin. Natuurlijk zijn er momenten waarop men zich afvraagt of dit allemaal moet.
Het antwoord is: ja. Omdat de complexiteit die men hier leert de complexiteit vervangt die men anders elders draagt — in scripts, wiki’s, hoofden, nachtelijke telefoontjes. Kubernetes centraliseert complexiteit om haar hanteerbaar te maken. Men ruilt chaotische, verspreide complexiteit voor gestructureerde, gedocumenteerde complexiteit.
En dan komt het moment dat het klikt. Dat de termen zich ordenen. Dat men begrijpt dat een Deployment replica’s beheert, een ReplicaSet pods voortbrengt, een Pod containers uitvoert, een Service een stabiele naam ervoor plaatst en een Ingress verkeer van buiten verdeelt. Dat het diagram zin geeft. Dat men voor het eerst een manifest schrijft, deploys en ziet hoe het systeem het uitvoert — precies, deterministisch, zonder verrassing.
Na dat moment wil men niet terug. Nooit.
Een systeem dat niet stilzit
Wie Kubernetes eenmaal begrijpt leert snel nog een eigenschap kennen: het staat nooit stil.
De ontwikkelsnelheid van het project is ongeëvenaard. Elk kwartaal verschijnen nieuwe releases die niet alleen bugs fixen maar concepten vooruit helpen. API’s worden geïntroduceerd, rijpen, worden deprecated, tenslotte verwijderd. Wie vijf jaar geleden leerde moet vandaag veel herleren.
Een voorbeeld: Ingress. Lange tijd was Ingress de standaardmethode om HTTP-verkeer een cluster in te leiden. Maar Ingress had zwaktes — het was HTTP-centristisch, beperkt in mogelijkheden, gefragmenteerd tussen implementaties die zich inconsistent gedroegen. De community erkende dat en ontwikkelde de Gateway API — een nieuw, generiek model voor routing dat niet tot HTTP beperkt is, dat op rollen gebaseerde configuratie mogelijk maakt en de fragmentering doorprecieze specificaties bestrijdt.
Vandaag productief met Kubernetes werken betekent met deze drift leven. Ingress is niet verdwenen, maar Gateway API is de toekomst. Migratie is niet optioneel — het is de normale voortbeweging in een systeem dat zich constant ontwikkelt.
Dat kan vermoeien. Maar het is ook een teken van gezondheid. Een systeem dat zich niet ontwikkelt sterft. Kubernetes leeft. En wie ermee leert leven leert dat ontwikkeling geen bug is maar een feature.
De architectuur beslist
Technologie alleen volstaat niet. Dat is de belangrijkste les die ik in meer dan twee decennia infrastructuurwerk geleerd heb.
Kubernetes is machtig. Maar machtige gereedschappen in slechte handen richten meer schade aan dan zwakke in goede. De keuze van software die op Kubernetes draait bepaalt succes en mislukking. De architectuur van clusters — hoe ze gesegmenteerd zijn, hoe policies doorgevoerd, hoe opstorage aangesloten, hoe netwerken geconfigureerd — beslist of men schaalbaarheid wint of chaos. Of zelfherstel werkt of storingen veroorzaakt. Of hoge beschikbaarheid echt is of een bluf.
Een microservice-architectuur die niet doordacht is wordt op Kubernetes niet beter — alleen sneller verspreid. Een stateful dienst die niet voor orchestrering ontworpen werd wordt onder Kubernetes niet betrouwbaarder — alleen moeilijker te debuggen. Kubernetes lost geen architectuurproblemen op. Het maakt goede architectuur schaalbaar en slechte zichtbaar.
Juist hier scheidt het kaf het koren. Juist hier wordt ervaring voelbaar die niet in boeken staat.
Wat libcom.de onderscheidt
libcom.de exploiteert Kubernetes vanaf de vroege dagen. Niet als experiment — als productie. We hebben clusters door versie-upgrades geleid die meerdere major-releases besloegen. Migraties begeleid waarbij Ingress tot Gateway API werd. Gezien wat misgaat als operators verkeerd ingezet worden, als StorageClasses niet kloppen, als NetworkPolicies gaten scheuren.
Onze ervaring is niet theoretisch. Ze is littekenscherp.
Maar de belangrijkste ervaring is niet technisch. Ze is architecturaal. We weten welke software zich voor Kubernetes leent en welke niet. We weten wanneer een dienst stateless moet worden voor orchestrering. We weten wanneer Helm het juiste gereedschap is en wanneer Kustomize. We weten wanneer een operator helpt en wanneer hij een blackbox creëert die niemand meer begrijpt.
We helpen bij de keuze van software. Bij de architectuur van clusters. Bij het definiëren van policies die veiligheid en flexibiliteit niet tegen elkaar uitspelen maar mogelijk maken. We plannen upgrades, begeleiden migraties, documenteren beslissingen. En we zijn eerlijk als Kubernetes niet het juiste antwoord is — want soms is het dat niet.
Wie Kubernetes invoert zonder de architectuur te heroverwegen bouwt zich een nieuw probleem. Wie het invoert met de juiste architectuur wint iets dat hij niet meer wil prijsgeven: infrastructuur die werkt omdat ze gebouwd is — niet omdat iemand oplette.
Als u zich afvraagt of Kubernetes voor u zinvol is — of of uw bestaande cluster-architectuur nog de juiste is: schrijf ons via contact@libcom.de. We maken een eerlijke inventaris. Zonder verkoopdruk. Met oog voor wat op lange termijn standhoudt.
De paradigma-verschuiving is onvermijdelijk. Wie servers nog als huisdieren behandelt wordt ooit door de complexiteit ingehaald. Wie ze als vee beschouwt heeft de eerste stap gezet. Wie ze begrijpt als cellen van een levend systeem — zelfherstellend, schalend, beschikbaar — heeft begrepen waarheen de reis gaat.
Kubernetes is geen modesneeuw. Het is de architectuur waarop de volgende generatie infrastructuur gebouwd wordt. De vraag is niet of men meedoet. De vraag is wanneer — en met wie.