Kubernetes je odličan alat. Nije default za svaku web aplikaciju na jednom VPS-u. Odluka nije „moderno vs zastarjelo“, nego koliko operativnog troška možete nositi za benefite koje stvarno trebate.
Što Kubernetes stvarno kupuje
Kupujete deklarativno pokretanje mnogo servisa s rolling updateima, self-healing i scheduling po više nodeova, plus standardiziran model za više okruženja i timova. Ekosustav (Ingress, HPA, service mesh) postoji kad zatreba.
To plaćate: API surface, networking model, RBAC, storage klase, upgradei control plane-a, observability, i vrijeme ljudi koji moraju znati debugirati CrashLoopBackOff u tri sloja apstrakcije.
Kada je Compose / jedan VPS / Nomad dovoljno
Za većinu malih tvrtki i obrta godinama je dovoljno: jedan ili dva VPS-a, nekoliko kontejnera (web, worker, DB managed ili na volumenu), reverse proxy s TLS-om, i CI koji builda image i deploya preko SSH-a.
Docker Compose u produkciji s healthcheckovima, restart politikama i pinned tagovima pokriva taj scenarij. Ako trebate samo provisionati machine i DNS, Terraform / OpenTofu rješava infrastrukturu bez orkestratora.
HashiCorp Nomad ili „systemd + Docker“ također su legitimni mid-pathovi: manje featurea od K8s-a, manje kognitivnog opterećenja.
Kada Kubernetes počinje imati smisla
Smisao raste kad imate više servisa i okruženja: deseci deployable jedinica, staging/prod parity, česti releasei. Ili stvarnu potrebu za rasporedom po više nodeova i HA, ne „možda jednog dana“. Tim treba barem nekoga tko živi u platformi, ne „svi malo diraju YAML“. Platformski zahtjevi (multi-tenant, strogi isolation, standardni GitOps tok za više aplikacija) također guraju prema clusteru.
Ako imate jednu Django/Node aplikaciju, Redis i Postgres, K8s rijetko skraćuje put do vrijednosti. Ako imate platformu s više timova i servisa, često skraćuje.
Managed vs self-managed
Managed (EKS, GKE, AKS, DigitalOcean Kubernetes, Hetzner managed i slično) znači da plaćate da netko drži control plane. I dalje vi držite workloade, mrežu, IAM i cost. Self-managed (kubeadm, k3s, Talos…) daje full kontrolu i full odgovornost za upgrade i etcd.
Za SMB koji „mora K8s“, managed je obično razumniji prvi korak. Self-managed ima smisla kad imate razlog: air-gap, specijalni CNI, cost na velikoj skali, ili učenje s namjerom.
k3s i slični lightweight distribucijski modeli smanjuju friction za lab i manje clustere. I dalje nisu besplatni u operativnom smislu.
Česte greške prerane adopcije
Klasična greška: premjestiti monolith u K8s „da budemo spremni za scale“ prije nego što postoji scale problem. Drugo: pokretanje stateful baza u clusteru bez storage discipline i backup plana. Treće: nema monitoringa ni budžeta za upgrade, pa cluster ostane na staroj verziji „jer radi“. YAML copy-paste bez NetworkPolicy, resource limits i image pinova. I miješanje „učimo K8s“ s „produkcija sutra mora biti up“.
Praktičan decision checklist
Pitajte se: može li jedan VPS plus Compose podnijeti load sljedećih 12 do 24 mjeseca? Imate li osobu koja će održavati cluster kvartalno (upgradei, CVE, certovi)? Je li problem orkestracija više servisa, ili deploy/process/dokumentacija? Je li managed cluster u budžetu, uključujući load balancere i egress?
Ako tri odgovora vuku na „ne / možda“, ostanite na jednostavnijem stacku i investirajte u CI, backup i monitoring.
Što raditi umjesto K8s-a (konkretno)
Pinned image tagovi i healthcheck u Compose. Jedan reverse proxy s automatskim TLS-om. CI tok: test, build, deploy na VPS. Backup 3-2-1 i monitoring uptimea. Dokumentiran rollback na prethodni image tag.
To rješava veliki dio operativnih problema malih timova bez control plane-a.
Zaključak
Kubernetes nije greška. Premature Kubernetes jest. Birajte orkestraciju prema stvarnom broju servisa, okruženja i ljudi, ne prema CV-u. Za postavljanje razumnog Compose/VPS puta ili kasniji prijelaz na managed cluster, tu su DevOps usluge.