What We Actually Use Kubernetes For (And What We Don’t)

Kubernetes has become the default answer to "how do we deploy this" long before most teams have a workload that actually needs what it provides. We use it constantly, but not reflexively, and the distinction matters enough that we turn clients away from it more often than people expect from an infrastructure-focused team.

What Kubernetes is actually solving

The real value is in three things: rolling deployments without downtime, autoscaling that responds to real traffic patterns rather than fixed capacity, and a consistent way to enforce network policy between services as you add more of them. If you have one service, a monolith, or traffic patterns predictable enough that you can provision for peak without waste, you do not need most of that.

At HostPepper, where uptime is the actual product, Kubernetes earned its place because the failure modes it protects against are the failure modes that would otherwise show up as customer-facing outages: a bad deploy that needs an instant rollback, a traffic spike that needs capacity within seconds rather than the minutes a manual scale-up would take, and dozens of services that need their network permissions locked down individually rather than trusted as a flat network.

Where we have talked clients out of it

More than once, a client has come to us wanting a Kubernetes migration because a previous vendor or a conference talk convinced them it was the professional choice. The conversation that follows is usually the same: how many services do you actually run, what does your traffic pattern look like, and who on your team will actually operate this once we leave? A single service with steady traffic on a managed container platform, or even a well-configured set of autoscaling VMs, is often both cheaper and more reliable in practice, because there is less surface area for something to go quietly wrong.

The operational cost of Kubernetes is real and often underestimated. It is not just the cluster itself; it is the ongoing cost of someone on the team understanding networking policies, resource requests and limits, and what to do when a pod is stuck in a crash loop at 2am. If that person does not exist on the client's team after we leave, we have handed them a system they cannot maintain, which is a worse outcome than the simpler thing that actually gets operated correctly.

What we actually check before recommending it

• More than a handful of independently deployable services, or a clear roadmap to get there
• Traffic patterns variable enough that fixed capacity means meaningfully overpaying or under-provisioning
• A team that will exist after launch to actually operate the cluster
• A real need for the network policy and permission isolation Kubernetes makes easy to enforce consistently

When those are true, we build on it happily, and the zero-trust networking work we describe in Zero-Trust Without Slowing Down Engineers is significantly easier on a Kubernetes-based platform than it would be trying to retrofit the same permission model onto a flat network of VMs. When they are not true, the honest answer is usually a simpler platform and a team that can actually sleep at night operating it.