De afgelopen weken heb ik een Kubernetes omgeving opgebouwd op basis van K3s op Ubuntu. Niet als demo, maar als serieus leertraject (Ongoing!). Het uitgangspunt was vanaf dag een duidelijk: GitOps only. Alles declaratief in Git, deploys via GitLab CI CD en ArgoCD, geen structurele kubectl handelingen.
Architectuur en uitgangspunten
Het cluster draait single node, maar wel met productieachtige keuzes:
- K3s zonder Traefik en servicelb
- Cilium als CNI
- Gateway API als standaard voor extern verkeer
- ArgoCD self managed
- DNS extern geregeld, cluster is niet leidend voor DNS
- Alles gescheiden per namespace
- Geen externe manifests via URLs, alles lokaal versiebeheer
Het doel was niet snelheid, maar controle en inzicht.
Networking bleek de echte complexiteit
In de eerste iteratie draaide Cilium in host networking mode met verhoogde privileges om Gateway API werkend te krijgen. Dit loste bereikbaarheid op, maar introduceerde direct een aantal risico s:
- Pods delen het host netwerk, minder isolatie
- Grotere impact bij configuratiefouten
- Moeilijker te beveiligen in een multi tenant scenario
- Debuggen wordt lastiger omdat node en cluster verkeer door elkaar lopen
Daarbovenop liep ik tegen een bleeding edge bug aan in Cilium in combinatie met host networking. Geen crash, maar wel onvoorspelbaar gedrag. Dat is precies het soort signaal waar je niet omheen wilt werken met workarounds die de security verder verzwakken.
Bewuste security en netwerk afwegingen
Dit leidde tot een duidelijke keuze: niet optimaliseren voor vandaag, maar voor de gewenste eindstaat. De homelab is daarom uitgebreid met:
- Een extra NIC
- Een tweede WAN IP
- Cilium loadbalancing in plaats van host networking
Hiermee kon host networking volledig verdwijnen en is het netwerkpad nu veel explicieter:
- Extern verkeer komt binnen via Gateway API
- Cilium LB handelt IP allocatie af
- Services zijn standaard intern
- Alleen expliciet exposed workloads zijn bereikbaar
- Node netwerk en cluster netwerk zijn logisch gescheiden
Het resultaat is een setup die voorspelbaarder is, beter te beveiligen en dichter bij hoe dit in grotere omgevingen wordt ingericht.
GitOps als leerinstrument
GitOps bleek niet alleen een deployment model, maar ook een leermiddel. Doordat alles declaratief is vastgelegd:
- Fouten zijn reproduceerbaar
- Configuratie is te reviewen
- Rollbacks zijn triviaal
- Drift is zichtbaar
Elke misconfiguratie werd geen frustratie, maar een datapunt. Wat ging hier mis en waarom.
Huidige status en volgende fase
De basis staat nu. Networking is stabiel, security keuzes zijn expliciet en het platform gedraagt zich voorspelbaar. ArgoCD bewaakt de gewenste staat en het cluster volgt.
De volgende fase is waar het leuk wordt. Applicaties bouwen en deployen:
- Images bouwen via CI CD
- Configuratie volledig via Git
- Services correct exposen via Gateway API
- Observability toevoegen waar nodig
De fundering ligt er. Vanaf hier draait het niet meer om het cluster werkend krijgen, maar om er daadwerkelijk waarde op te draaien.
Dit traject heeft mijn beeld van Kubernetes flink aangescherpt. Verslaven leuk en interessant als je merkt wat het kan.
#kubernetes #k3s #gitops #argocd #cilium #gatewayapi #homelab #devops #infrastructureascode
