Kubernetes in production: what no one tells you before you migrate

Most teams that migrate to Kubernetes get there convinced they are solving an infrastructure problem. What they discover, usually six months later, is that they have swapped one set of problems for a much more sophisticated one — and that the operational complexity they thought they had eliminated has simply moved.

What Kubernetes really does well

Kubernetes was born to solve a concrete problem: orchestrating containers at scale, with resilience and automatic recovery capacity. He does this very well. If your organization operates dozens of services with variable traffic patterns, needs deployments without downtime, and has a mature team to operate the platform, Kubernetes delivers real value.

Workload scheduling, resource management, support for progressive rollout strategies, and integration with observability tools are genuinely good. These benefits are not marketing — they exist, work and make a difference in production.

The problem is not what Kubernetes promises. That's what he demands in return.

The complexity that appears after migration

Networking in Kubernetes is not a simple setup. It's an entire layer of abstraction — CNI plugins, Service meshes, network policies, internal DNS, ingress controllers — that you need to understand, maintain, and debug when something breaks. And something will break.

Storage is another point of friction that most underestimate. Persistent volumes, StorageClasses, access modes, snapshots, backup PVCs: all of these need to be designed carefully. Stateful applications on Kubernetes are significantly more complex than the same applications running on conventional virtual machines.

RBAC, in turn, is the kind of thing that no one documents well during the migration and that turns into technical debt in a matter of weeks. Setting granular permissions for distinct namespaces, service accounts, and workloads requires discipline that teams under delivery pressure can rarely maintain.

Cluster upgrades are another chapter. Kubernetes has an aggressive life cycle: versions become obsolete quickly, and each upgrade requires compatibility validation of APIs, manifests, Helm charts and operators. Ignore this for a few months and you'll be running an unsupported version in production.

The SRE paradox

There is a well-known irony in teams adopting Kubernetes without adequate planning: you need experienced reliability engineers to operate the tool that is supposed to reduce the need for manual operation. Kubernetes was built for Google-scale. He carries this heritage.

Small teams often find that they are spending more time operating the platform than developing the product. Each incident involves logs from multiple pods, tracking of scheduling events, analysis of resource limits and network debugging that only makes sense to those who deeply understand the internal abstractions.

This is not a design defect. It is a direct consequence of the generality of the platform. Kubernetes solves complex problems in complex ways — and that complexity doesn't disappear just because containers are running.

When managed Kubernetes changes the calculation

EKS, GKE, and AKS do not eliminate operational complexity, but they do distribute some of it to the cloud provider. The control plane — etcd, API server, scheduler, controller manager — is the responsibility of the provider. Version upgrades become less traumatic. Integration with the provider's identity, storage and network services comes pre-configured.

For teams already operating within a specific cloud provider, managed Kubernetes significantly reduces the cost of entry. It's not zero, but it's substantially less than operating a self-managed cluster.

The calculation changes again when you consider lock-in. GKE Autopilot, for example, abstracts so much that you lose control over scheduling and node configuration. It's a valid trade for some teams — and unacceptable for others. The choice depends on where you want sovereignty and where you accept delegation.

When a simpler strategy is the smart decision

Kubernetes is not the right answer for every workload. If you operate a well-structured monolith with predictable traffic, a well-configured EC2 instance with an automated deployment process can be more reliable, cheaper and much easier to operate.

Tools like Fly.io, Railway, Render or even AWS App Runner deliver most of the operational benefits of Kubernetes — zero downtime, automatic scaling, rollbacks — without the layer of abstractions that require experts to maintain.

The question teams rarely ask before migrating is straightforward: what specific problem will Kubernetes solve that current infrastructure can't? If the answer is vague — "scalability," "modernization," "better container management" — the operational investment is probably not justified.

Kubernetes makes sense when you have multiple services with independent deployment cycles, the need for isolation between workloads, highly variable traffic patterns, and a team with real capacity to operate the platform. These four criteria together rarely appear before an organization has dozens of engineers and years of container maturity.

The decision that happens at the wrong time

Migration to Kubernetes almost always happens at a time of least preparation. The team is growing, the pressure to scale has appeared, someone saw a talk at KubeCon — and the decision is made before the team has enough experience to understand what they are taking on.

The typical result: six months of effort to migrate, followed by another six trying to stabilize the environment. The problems that motivated the migration — fragile deployments, lack of isolation, difficulty in scaling — continue to exist, now with an additional layer of diagnosis.

This does not mean that the migration was wrong. It means she needed more planning, a realistic schedule and training before execution. Kubernetes is a powerful platform. But power and simplicity rarely coexist — and those who don't understand this distinction learn after the decision has already been made.