De onzichtbare stappen van Kubernetes naar echte productie

Iedereen kent het moment. Je app draait prima in Docker op je laptop. Je zet hem in containers, draait een Kubernetes-cluster op, en denkt dat je klaar bent. De CTO is blij, het team viert feest.

Totdat de echte wereld eraan komt.

Een Kubernetes-omgeving die “werkt” is niet hetzelfde als een omgeving die 24/7 onder druk kan staan. Wat op je laptop of in een testcluster prima functioneert, valt vaak al bij de eerste echte gebruiker of om 3 uur ’s nachts uit elkaar.

Waarom een ontwikkelcluster geen productie is

De meeste ontwikkelclusters zien er zo uit: lokale Minikube-omgevingen, self-signed certificaten, nep-domeinen en handmatig draaien van Helm-commando’s. Credentials staan hard-coded in YAML-bestanden en monitoring komt “later wel”.

In productie gelden andere eisen. Je moet kunnen antwoorden op vragen als:
Hoe deploy je zonder handmatig ingrijpen? Waar staan je secrets en wie heeft er toegang toe? Wat als storage uitvalt? Kun je snel herstellen na een incident? En weet je wat er misgaat voordat gebruikers het merken?

Dat zijn geen extra’s. Dat zijn de dingen die bepalen of een systeem een speelveld of een betrouwbare dienst is.

De route naar productie: vijf fases

De weg van “het werkt” naar “we kunnen dit veilig draaien” volgt een vaste orde. Je bouwt geen nieuwe features, je bouwt betrouwbaarheid.

Fase 1: De basis op orde

Eerst zorg je dat de fundamentele onderdelen met elkaar praten:

• Echte domeinnamen in plaats van test-adressen
• Een echte identity provider (OIDC of SAML)
• Databases en object storage buiten het cluster
• Een fatsoenlijke secrets-manager in plaats van YAML met wachtwoorden

Deze fase is onzichtbaar voor eindgebruikers, maar zonder hem is alles wat daarna komt kwetsbaar.

Fase 2: De applicatie laten werken

Nu de infrastructuur stabieler is, moet de app zelf ook meedoen. Auth-flows moeten end-to-end werken, uploads moeten veilig landen, caching moet consistent zijn en ingress moet echte traffic aankunnen. Veel ontwikkel-aannames breken hier.

Fase 3: Veranderingen beheersen

Handmatig Helm installeren wordt een risico. Je hebt GitOps nodig: alles staat in Git, elke verandering is traceerbaar en reviewbaar. Met automated validation en rollback-mogelijkheden wordt deploying niet meer een hoopvol commando, <|eos|>