Skip to content
Go back

Kubernetes bouwen in een kamer zonder internet

Updated:

Bij het Ministerie van Defensie in Den Helder kreeg ik een opdracht die mijn hele idee van DevOps op zijn kop zette: bouw een Kubernetes-platform in een air-gapped omgeving.

Air-gapped betekent: geen internet. Geen enkele verbinding naar buiten. Geen apt-get. Geen pip install. Geen docker pull. Geen Stack Overflow.

Alles wat je nodig hebt, moet je van tevoren klaarmaken, verifiëren, en via een fysieke drager naar binnen brengen. Een USB-stick, een harde schijf, een laptop die je door een sluis haalt. Als je iets vergeet, is het antwoord niet “even snel downloaden.” Het antwoord is: morgen weer een dag.

Waarom air-gapped?

De systemen die ik moest bouwen waren onderdeel van GENIUS — een project dat jaarlijks meedoet aan NAVO-oefeningen. Dit is geen hobbyclub. Dit zijn onbemande systemen, embedded C/C++, mission-critical toepassingen waar buitenlandse mogendheden graag in zouden kijken.

Het beveiligingsniveau was Departementaal Vertrouwd (DepV). Dat betekent: de omgeving is fysiek afgesloten van het internet. En dat is maar goed ook. Maar het maakt je werk als engineer wel… interessant.

Bouwen met VMware en blote handen

De infrastructuur draaide op VMware ESXi met vCenter, VSAN, en VMotion — onze eigen on-premise “cloud”. Hier moest Kubernetes op komen. En niet zomaar Kubernetes — het moest schaalbaar zijn, betrouwbaar tijdens NAVO-oefeningen, en beheersbaar door een team dat geen fulltime K8s-admin was.

Ik koos voor K3s, een lichtgewicht Kubernetes-distributie. Niet omdat K8s te zwaar was — maar omdat K3s met minder dependencies werkt. In een air-gapped omgeving telt elke dependency als een risico.

Alles werd uitgerold met Terraform en Ansible. Cloud-init voor de eerste boot. Packer om images te bouwen. Elke component moest eerst getest worden in een geïsoleerde testomgeving voordat hij naar binnen mocht.

Een voorbeeld van wat normaal triviaal is: een container image. docker pull nginx duurt normaal 10 seconden. In een air-gapped omgeving: image downloaden op een internet-machine, saven als .tar, overzetten naar fysieke drager, fysiek naar binnen brengen, docker load, verifiëren dat de hash klopt, en dan pas deployen. Voor elke image. Voor elke update.

Je leert snel welke images je écht nodig hebt.

Wat erin draaide

Het Kubernetes-platform hostte diverse services die onderdeel waren van de grotere GENIUS-keten:

Elke service moest via een fysieke drager naar binnen. Elke update was een logistieke operatie. Het dwingt je om goed na te denken over wat je écht nodig hebt en wat je een keer per maand wilt updaten.

Wat ik leerde

Een air-gapped omgeving is een spiegel. Het laat zien welke aannames je hebt over hoe software werkt. Alles wat je normaal als vanzelfsprekend beschouwt — een package manager, een DNS-resolver, een NTP-server — wordt een bewuste keuze. Je kunt niks aannemen.

Plannen is een technische vaardigheid. In een normale omgeving kun je itereren: iets werkt niet, je zoekt het op, je past het aan. In air-gapped bestaat die luxe niet. Wat je meeneemt naar binnen, moet werken. Dat betekent: testen, testen, en nog eens testen — in een gespiegelde omgeving — voordat iets door de sluis gaat.

Minimalisme is geen esthetische keuze. Hoe minder componenten je hebt, hoe minder er kapot kan gaan. Hoe kleiner je images, hoe sneller ze door de sluis kunnen. In een normale omgeving is “even een extra service toevoegen” een beslissing van 5 minuten. In air-gapped is het een project van een dag.

De lol van beperkingen. Het klinkt raar, maar er zit een bepaalde voldoening in bouwen met restricties. Je wordt creatiever. Je oplossingen worden eleganter. Omdat “gewoon een library importeren” geen optie is, ga je dingen zélf snappen. En dat maakt je een betere engineer.

Als ik nu een normaal Kubernetes-cluster bouw met internettoegang, voelt het bijna als valsspelen.


Share this post on:

Previous Post
Vier maanden praten om één infrastructuur te verhuizen
Next Post
Een platform bouwen dat niemand had gevraagd