Kubernetes are o problemă de reputație: jumătate din industrie îl poartă ca pe o insignă, cealaltă jumătate îl vede ca pe o taxă. Pentru mine este un instrument cu un prag clar de utilizare. Un site de marketing sau un MVP funcționează foarte bine pe un singur server cu un manager de procese și o sarcină CI — exact așa este implementat acest site. Kubernetes începe să-și merite locul când ai mai multe servicii, încărcare variabilă și mai multe echipe care livrează pe aceeași infrastructură.
Totul începe cu containerul. Dockerfile-uri multi-stage, o imagine runtime mică, fără dependențe de dezvoltare, utilizator non-root și un singur proces per container. O aplicație Next.js se construiește în modul standalone; un API NestJS include doar dist și node_modules pentru producție. Aceeași imagine trece din CI în staging și apoi în producție. Se schimbă doar configurația, prin variabile de mediu, ConfigMaps și Secrets — nu reconstruim imaginea pentru fiecare mediu.
Obiectele pe care le folosesc zilnic sunt puține: un Deployment pentru fiecare serviciu, un Service în fața lui, un Ingress cu TLS pentru traficul public și un HorizontalPodAutoscaler pentru componentele a căror încărcare chiar are vârfuri. Fiecare container primește requests și limits de resurse; fără ele, scheduler-ul doar ghicește. Probele readiness și liveness sunt separate intenționat: readiness spune „nu-mi trimite trafic încă”, iar liveness „repornește-mă”. Dacă le încurci, o bază de date lentă se transformă într-o avalanșă de restarturi. Fiecare serviciu Node.js tratează și SIGTERM și termină cererile în curs, astfel încât un rolling update să nu întrerupă o plată la jumătate.
Nu totul este server web. Worker-ele de coadă rulează în Deployment-uri proprii și se scalează după restanța cozii, nu după CPU. Lucrările programate — rapoarte, curățări, reconcilierea cu un procesator de plăți — rulează ca CronJobs cu concurrencyPolicy: Forbid, ca o execuție lentă să nu se suprapună cu următoarea. Migrațiile bazei de date rulează într-un Job înainte de rollout, nu la pornirea aplicației: cinci replici pornite simultan nu trebuie să încerce toate migrarea schemei. Prefer PostgreSQL gestionat, precum RDS, în loc de StatefulSet — clusterul este pentru servicii stateless.
Manifestele sunt în Git și se revizuiesc ca orice cod. Implementarea trece printr-un pipeline CI cu Helm sau Kustomize ori prin GitOps cu Argo CD; astfel, revenirea este un revert, nu o sesiune nocturnă cu kubectl. kubectl apply de pe laptop este pentru învățare, nu pentru producție. Logurile ajung în stdout și apoi într-un depozit central, metricile în Prometheus și Grafana; urmăresc rollout-ul cu kubectl rollout status în loc să sper că merge. Pe AWS asta înseamnă de obicei EKS cu grupuri de noduri gestionate, astfel încât echipa să se ocupe de produs, nu de control plane.
Refuz Kubernetes pentru un site de două pagini, un service mesh înainte să existe mai multe servicii, secrete în YAML simplu în repo și poduri fără limite doar pentru că „mergea în staging”. Dacă nu știi dacă ai nevoie de un cluster, trimite-mi serviciile, traficul și mărimea echipei. Îți spun sincer dacă ai nevoie de Kubernetes, câteva containere pe o singură gazdă sau o platformă precum Vercel — și cam cât costă lunar fiecare variantă.
Oferă-i următorului produs cuiva care rămâne.
Ești gata să începem? Trimite-mi un mesaj - pot începe acum și pot rămâne alături de produs. Colaborări pe termen lung, nu o predare în două săptămâni. Să discutăm proiectul, cerințele și cea mai bună cale de urmat.