What Kubernetes is for
When the orchestrator earns its complexity — and when a simpler runtime is the senior choice.
Kubernetes schedules, heals, and exposes container workloads from a declared desired state. It does not replace good service design, observability, or CI.
Where it pays off
- many services that need rolling deploys, health checks, and horizontal scale
- teams that benefit from a shared runtime contract (same probes, same secrets pattern, same networking model)
- platforms that already run on containers and need portable scheduling across nodes
On AWS/EKS, Rancher, or on-prem, the value is consistent deployment and recovery mechanics — not “Kubernetes” as a résumé checkbox.
Where it costs you
- small systems that would be fine on a managed service or a few VMs
- stateful data stores dropped onto the cluster without operators, backup, and storage expertise
- treating the cluster as a PET zoo of one-off kubectl snowflakes
If your pain is product clarity or database ownership, YAML will not fix it.
Mental model
You declare what should run. Controllers reconcile toward that state. When reality diverges (node death, OOM, failed probe), Kubernetes acts on the rules you gave it. Bad rules produce bad automation.
Smell test
Prefer Kubernetes when you need orchestration primitives you will actually use: deployments, probes, HPA, standardized networking and identity. Prefer something smaller when the team’s bottleneck is still “what should this service own?”