Kubernetes is genuinely good engineering that solves a genuine problem: running many containerised workloads across a fleet of machines, with automatic placement, self-healing and rolling updates. The question is not whether it works. It is whether the problem it solves is one you have, because the cost of running it is charged continuously and the benefit only arrives at a certain scale.
The cost is a person. Not a licence - Kubernetes is free - but someone who understands ingress controllers, persistent volume claims, resource requests and limits, node autoscaling, RBAC, and what to do when a pod is stuck terminating at two in the morning. In practice that means either a platform engineer or a meaningful fraction of every engineer's attention permanently diverted from your product. If you have five engineers and no platform person, that is the real price.
The benefit arrives when you have enough services that manual placement becomes genuinely painful, when you need bin-packing across machines to control cost, when different services have different scaling profiles, or when you need consistent deployment across multiple environments and clouds. Those are real situations. They are not most situations at ten or twenty services.
The alternatives are better than Kubernetes advocates usually admit. Managed container services - Cloud Run, App Runner, Container Apps, Fargate - give you containers, autoscaling, rolling deploys and TLS without a cluster to operate. Plain virtual machines behind a load balancer, with containers deployed by a simple pipeline, still work perfectly well and are debuggable by anyone who understands Linux. A managed platform-as-a-service handles the whole thing for small teams. All of these are unfashionable and all of them are shipping products profitably.
If you do adopt it, use a managed control plane - EKS, GKE, AKS - rather than running your own. Self-managed control planes are where small teams lose weeks to etcd and certificate rotation for no product benefit whatsoever. And set resource requests and limits from the first deployment, because the most common Kubernetes cost failure is not the cluster, it is every workload requesting far more than it uses and the autoscaler dutifully buying machines to satisfy the request.
The question worth asking before adopting it: what specifically breaks today that Kubernetes would fix? If the answer is a concrete operational pain you can describe, adopt it. If the answer is that it seems like where serious companies end up, wait. You can migrate onto Kubernetes later from containers running anywhere, and the migration is far easier than unwinding a cluster nobody understands.
