Munca ascunsă dintre „Kubernetes rulează” și „gata de producție”

Toți am trecut prin asta. Aplicația merge perfect pe laptop, în Docker. O containerizăm, pornim un cluster Kubernetes și brusc devine „deployed”. CTO-ul se entuziasmează. Echipa sărbătorește.

Apoi vine realitatea.

Setup-ul de Kubernetes care ne-a dus la „merge” nu e același cu cel care poate suporta utilizatori reali, date reale și probleme la 3 dimineața.

De ce „rulează pe Kubernetes” nu înseamnă producție

Un cluster de development și unul de producție au în comun doar orchestratorul de containere. Restul e complet diferit.

În development vezi:

• clustere locale cu minikube
• certificate auto-semnate care merg doar pe mașina ta
• domenii de test (*.127.0.0.1.nip.io)
• credențiale hard-coded în variabile de mediu
• comenzi Helm rulate manual de o singură persoană
• monitorizare amânată pentru „mai târziu”
• backup-uri netestate

În producție trebuie să răspunzi la întrebări mai dure:

• Cum facem deploy fără intervenție manuală?
• Unde stau secretele și cine are acces la ele？
• Ce se întâmplă când storage-ul cade?
• Putem restaura backup-urile când apare o problemă reală?
• Respectăm politicile de securitate?
• Știm ce se strică înainte ca utilizatorii să ne sune?

Acestea nu sunt opțiuni extra. Ele fac diferența între un proiect de hobby și un sistem de care depinde o afacere.

Secvența reală de lucru

Treptarea de la „merge pe mașina mea” la „poate fi operat în siguranță” se întâmplaa în pași clar definiți. Nu construim funcționalități noi. Construim maturitate operațională.

Faza 1: Fundația funcționează

Prima etapă e să facem componentele de bază să comunice în condiții reale:

• Folosim domenii reale, nu domenii de test
• Integrăm un identity provider real (OIDC sau SAML)
• Mutăm datele persistente afară din cluster (database și object storage)
• Configurăm un sistem de secrete care nu depinde de fișiere YAML

Această etapa e invizibilă pentru utilizatori. Nu se „lansă” nimic. T<|eos|>