La câteva luni, o echipă de trei până la cinci ingineri ne întreabă dacă ar trebui să se mute pe Kubernetes. Aplicația e un front-end web, un API, câțiva workeri și o bază de date. Rulează pe unul sau două servere, sau pe o platformă-ca-serviciu care devine scumpă. Cineva a citit că Kubernetes e felul în care fac companiile adevărate și ar vrea să fie o companie adevărată.
Răspunsul pe care îl dăm, aproape de fiecare dată, e nu. Nu „nu încă”. Nu. Și pentru că răspunsul ăla sună a lene sau a contrarianism, articolul ăsta e raționamentul din spatele lui, alternativa pe care am construi-o în loc, cât costă, și condițiile specifice în care răspunsul se schimbă.
Pentru ce e Kubernetes
Kubernetes rezolvă planificarea: dată o flotă de mașini și un set de workload-uri cu cerințe de resurse, plasează workload-urile pe mașini, ține-le în viață, înlocuiește-le când mor și expune-le una alteia și lumii. Rezolvă asta extrem de bine, la orice scară, pentru orice fel de workload, cu un ecosistem pentru tot ce ai putea vrea.
Observă ce cere enunțul problemei: o flotă de mașini. Dacă n-ai o flotă, n-ai problema de planificare, iar Kubernetes devine un răspuns foarte sofisticat la o întrebare pe care n-ai pus-o. O echipă cu trei servicii n-are nevoie de bin-packing. Are nevoie ca acele containere să ruleze, să repornească, să scaleze de la două la șase când e trafic și să primească un URL HTTPS.
Ce primești oricum cu un cluster managed
„Kubernetes managed” (EKS, GKE, AKS) gestionează control plane-ul. Nu gestionează restul, iar restul e unde se duce timpul. Pentru un cluster de producție vei deține:
- Grupurile de noduri, tipurile lor de instanțe, actualizările lor de AMI, autoscaling-ul lor.
- Rețeaua: un CNI, un ingress controller, un load balancer per ingress sau unul comun, cert-manager pentru TLS, external-dns pentru înregistrări.
- Observabilitatea: metrics-server, un agent de logging și tot ce ai fi avut nevoie oricum.
- Securitatea: pod security standards, network policies, IRSA sau workload identity pentru acces la AWS, scanare de imagini, un admission controller dacă ești serios.
- Upgrade-urile: Kubernetes are trei release-uri pe an, iar furnizorii managed renunță la suportul pentru versiunile vechi cam la un an de la release. Fiecare upgrade atinge API server-ul, nodurile și, ocazional, manifestele, pentru că ceva s-a depreciat.
- Tooling-ul de deployment: Helm sau Kustomize, o strategie de medii și probabil ArgoCD sau Flux, odată ce „kubectl apply de pe laptop” te-a mușcat o dată.
Nimic din asta nu e greu pentru oamenii care au mai făcut-o. Totul e o taxă permanentă pentru o echipă care n-a făcut-o, și pentru o echipă de trei e o persoană. Am văzut cum se întâmplă: cel mai bun inginer devine inginerul clusterului, viteza produsului se înjumătățește, iar optsprezece luni mai târziu au o platformă frumoasă sub un produs care a încetat să crească.
Ce construim în loc
Un Dockerfile bun și un runtime managed care ia o imagine și dă înapoi un URL. Pe AWS, asta înseamnă App Runner pentru cazul simplu și ECS Fargate când ai nevoie de un serviciu intern în VPC sau de mai mult control; echivalentele pe celelalte clouduri sunt Cloud Run și Container Apps, iar argumentul e identic.
Dockerfile-ul e locul unde se duce efortul de inginerie, și e efort care s-ar fi dus și pe Kubernetes: build multi-stage, un utilizator non-root, o imagine de bază fixată, un HEALTHCHECK, fără secrete copte înăuntru, o imagine sub 200 MB ca pornirile la rece să fie rapide. Am scris despre versiunea pentru Node a acestei rețete. Fă-l bine o dată și e același fișier pe orice runtime, inclusiv Kubernetes, dacă te muți vreodată.
Runtime-ul face ce ar fi făcut clusterul: trage imaginea, rulează N copii, le verifică sănătatea, le înlocuiește pe cele moarte, scalează între min și max, termină TLS-ul, rutează traficul. O face cu o definiție de serviciu de vreo douăzeci de linii de CDK, și o face fără un OS de nod pe care să-l patch-uiești tu.
Restul stack-ului nu se schimbă. Aurora sau DynamoDB pentru date, SQS pentru cozi, Lambda pentru lucrurile cu adevărat în formă de eveniment, collector-ul OpenTelemetry pentru observabilitate. Nimic din lista aia n-a avut vreodată nevoie de un cluster.
Costul, sincer
Apărarea obișnuită a Kubernetes-ului pe cost e că Fargate și App Runner taxează o primă per vCPU-oră față de EC2 brut. Adevărat. Iată ce cumpără prima aia la scara în discuție, pentru trei servicii cu câte două instanțe calde fiecare în producție:
| Kubernetes managed (EKS) | Containere pe App Runner / Fargate | |
|---|---|---|
| Control plane | $73 / lună | $0 |
| Noduri / compute | 3 × m6i.large ≈ $210, în mare parte inactive, pentru rezervă | 6 × 1 vCPU / 2 GB ≈ $250 la tarifele App Runner |
| Load balancer | 1 ALB ≈ $25 + LCU-uri | inclus (App Runner) sau același ALB (Fargate) |
| Add-on-uri care consumă capacitate de nod | ingress, cert-manager, DNS, metrici, logging ≈ un nod întreg | niciunul |
| Upgrade-uri și patch-uri | 3 upgrade-uri de cluster / an, rotație lunară de AMI | schimbi tag-ul imaginii de bază |
| Timp de inginerie | ≈ 0,5–1 FTE | ≈ 0,05 FTE |
| Lunar, cu tot | ~$310 + $5.000–10.000 de inginer | ~$275 + ~$500 de inginer |
Liniile de infrastructură sunt la $50 una de alta. Linia de inginerie e toată comparația. La trei servicii, Kubernetes nu e mai scump de rulat; e mai scump de deținut, cu un ordin de mărime, iar prima per vCPU-oră e zgomot pe lângă asta.
Când se schimbă răspunsul
Nu suntem împotriva Kubernetes. Îl rulăm, pentru clienții care au nevoie de el. Răspunsul se întoarce când una dintre condițiile astea e adevărată, și de obicei e nevoie de două:
- Multe servicii, multe echipe. Peste cam cincisprezece-douăzeci de servicii, cu mai multe echipe care fac deploy independent, configurația per serviciu a runtime-urilor managed devine propria ei împrăștiere, iar un cluster cu namespace-uri, cote și un controller GitOps e cu adevărat mai simplu.
- Workload-uri care nu se potrivesc cu forma runtime-ului. Request-uri mai lungi decât timeout-ul runtime-ului, GPU-uri, stateful set-uri, daemoni care au nevoie de acces la host, rețea custom. Limita de 120 de secunde a App Runner e reală; dacă workload-ul tău are nevoie de 20 de minute de websocket, l-ai depășit.
- Compute mare și constant. La sute de vCPU care rulează non-stop, prima per vCPU nu mai e zgomot, iar nodurile rezervate într-un cluster sunt considerabil mai ieftine. Ăsta e punctul de încrucișare al costului, și e mult mai sus decât presupune lumea.
- Portabilitatea ca cerință. Dacă un contract zice „trebuie să fie desfășurabil în clusterul propriu al clientului”, runtime-ul e Kubernetes pentru că al clientului e. Asta e situația cu platforma noastră de agenți, motiv pentru care se livrează ca Helm chart-uri și motiv pentru care cunoaștem taxa la prima mână.
- Ai deja persoana. Dacă cineva din echipă a rulat clustere de producție și vrea să continue, costul de deținere scade și calculul se schimbă. Asigură-te că vrea, și asigură-te ce se întâmplă când pleacă.
Obiecția: „dar va trebui să migrăm mai târziu”
Poate. Iată ce implică de fapt o migrare ulterioară de pe un runtime managed pe Kubernetes, pentru o echipă care a construit cum am descris: Dockerfile-urile rămân neschimbate; rutele de health rămân neschimbate; variabilele de mediu și referințele la secrete devin un ConfigMap și un ExternalSecret; cele douăzeci de linii de CDK per serviciu devin patruzeci de linii de Helm values. Agentul de observabilitate se mută din sidecar în DaemonSet cu aceeași configurație. E un proiect de două săptămâni pentru cineva care a mai făcut-o, iar până ai nevoie de el vei avea persoana, pentru că nevoia de el e ce justifică angajarea ei.
Ce nu e recuperabil sunt cele optsprezece luni de atenție ale unei echipe mici cheltuite pe un cluster de care n-avea nevoie. Ăsta e costul despre care ne certăm de fapt.
Versiunea scurtă
Kubernetes e un planificator pentru flote. Dacă n-ai o flotă, rulează-ți containerele pe ceva care îți dă un URL, pune-ți efortul în Dockerfile și în health check, și revino la întrebare când ai cincisprezece servicii, un GPU sau un client care insistă. Până atunci, cel mai senior inginer din echipa ta ar trebui să construiască produsul.
Dacă decizi asta chiar acum și vrei o a doua opinie care nu vinde niciunul dintre răspunsuri, hai să vorbim.