Kubernetes in Production:
When It Helps and When It Gets in Your Way

Kubernetes is the right answer to a specific set of problems. For those problems, it is excellent. For everything else, it is an operational liability. The industry has done a poor job of communicating this, which is why so many engineering teams are running Kubernetes clusters to serve three services and eight users — and spending disproportionate time fighting ingress controllers and RBAC instead of building product.

What Kubernetes Actually Solves

Kubernetes is purpose-built for orchestrating large numbers of containers with complex operational requirements. It solves: scheduling and bin-packing (placing containers on nodes with available capacity), rolling deployments without downtime (replacing pods gradually with health-check-gated rollout), horizontal autoscaling on CPU or custom metrics, multi-tenant workload isolation via namespaces and network policies, and self-healing via pod restart policies and liveness probes. If you have these problems — specifically, if you are running 10+ containerised services that need to be deployed, scaled, and isolated independently — Kubernetes addresses them well.

What it does not solve: slow application code, poor database query planning, inadequate caching strategy, or the fundamental difficulty of building distributed systems. Kubernetes is infrastructure, not architecture. A badly-designed monolith on Kubernetes is still a badly-designed monolith.

The Real Operational Cost

A production Kubernetes cluster requires 0.5–1 dedicated SRE to operate well. This is not a conservative estimate — it reflects what it actually costs to manage: cluster version upgrades (which must happen regularly for security reasons and involve testing every workload against the new version), node pool management and instance type optimisation, networking troubleshooting (CNI issues, DNS resolution failures, NetworkPolicy debugging), storage class configuration for stateful workloads, RBAC maintenance as teams change, ingress controller upgrades and TLS certificate management, and incident response when the scheduler makes unexpected decisions.

If you have a 5-person engineering team, 0.5 FTE on cluster operations is 10% of your total engineering capacity spent on infrastructure that may not be necessary at your scale.

Simpler Alternatives Worth Taking Seriously

For 1–3 services: Docker Compose on a VM with systemd watchdog is a legitimate production configuration. It handles restarts, logging, and networking without the operational overhead. For 3–10 services: HashiCorp Nomad is significantly simpler to operate than Kubernetes while providing most of the scheduling and deployment features that matter at that scale. For teams that want zero infrastructure management: managed platforms like Render or Railway handle deployment, scaling, and infrastructure entirely — at the cost of less control over configuration.

When to Use Managed Kubernetes

If you have determined that Kubernetes is the right tool for your scale and architecture, managed Kubernetes (where the control plane is operated for you) removes the hardest part of cluster operations. You still manage node pools, workloads, and networking — but you are not responsible for etcd cluster health, control plane version upgrades, or API server availability. Hyper App's managed Kubernetes removes the control plane burden while keeping your data and compute within Uzbekistan for Law 213 compliance. That combination — operational simplicity plus data sovereignty — is the correct answer for most Uzbek companies that have genuinely reached Kubernetes scale.

"We ran Kubernetes for two years with a 4-person team. We spent about 20% of our engineering time on cluster maintenance. After migrating to managed K8s, that dropped to under 5%. The extra 15% went back into product."
— Engineering Manager, Central Asian SaaS Platform