Kubernetes in my work: when it earns its place and how I use it

Kubernetes has a reputation problem: half the industry treats it as a badge, the other half as a tax. For me it is a tool with a clear entry point. A marketing site or an MVP runs perfectly well on one server with a process manager and a CI job - that is how this very site is deployed. Kubernetes starts to earn its place when there are several services, uneven load, and more than one team shipping to the same infrastructure.

Everything starts with the container. Multi-stage Dockerfiles, a small runtime image, no dev dependencies, a non-root user, one process per container. A Next.js app builds in standalone mode; a NestJS API ships only dist and production node_modules. The same image goes from CI to staging to production - only config changes, through environment variables, ConfigMaps, and Secrets, never a rebuild per environment.

The objects I use daily are few: a Deployment per service, a Service in front of it, an Ingress with TLS for public traffic, and a HorizontalPodAutoscaler for the parts that actually get spiky. Every container gets resource requests and limits - without them the scheduler is guessing. Readiness and liveness probes are separate on purpose: readiness says “do not send me traffic yet,” liveness says “restart me.” Mixing them up is how a slow database turns into a restart storm. And every Node.js service handles SIGTERM and finishes in-flight requests, so a rolling update never drops a payment halfway.

Not everything is a web server. Queue workers run as their own Deployments and scale on backlog, not CPU. Scheduled work - reports, cleanups, reconciliation with a payment provider - runs as CronJobs with concurrencyPolicy: Forbid, so a slow run never overlaps the next one. Database migrations run as a Job before the rollout, not on app startup, because five replicas booting at once should not all try to migrate the schema. PostgreSQL itself I prefer managed, like RDS, rather than a StatefulSet - the cluster is for stateless services.

Manifests live in git and get reviewed like code, deployed through a CI pipeline with Helm or Kustomize, or GitOps with Argo CD - so a rollback is a revert, not a late-night kubectl session. kubectl apply from a laptop is for learning, not production. Logs go to stdout and into a central store, metrics into Prometheus and Grafana, and I watch rollouts with kubectl rollout status instead of hoping. On AWS that usually means EKS with managed node groups, so the team spends its time on the product, not the control plane.

What I refuse: Kubernetes for a two-page site, a service mesh before there are services, secrets committed as plain YAML, and pods without limits because “it worked in staging.” If you are not sure you need a cluster, send me your services, traffic, and team size. I will tell you honestly whether it is Kubernetes, a couple of containers on one host, or a platform like Vercel - and roughly what each costs to run every month.