Kubernetes Complexity: Starting From a Job Interview Question

I recently went through a job interview where the interviewer posed a seemingly routine question: “In your opinion, when should you use Kubernetes, and when is it unnecessary and just adds complexity?”

I answered it fairly smoothly at the time, but the question lingered in my mind long afterward. What made it so “sharp” was that it stepped beyond the technical details of “how to use K8s” and cut straight to the core trade-off in architecture design: Are we introducing a tech stack to solve a real business pain point, or just to satisfy the team’s “anxiety about being cutting-edge”?

Many teams treat Kubernetes as the default starting point for modern development, but the reality is often harsh: adopting Kubernetes doesn’t automatically grant you the infrastructure capabilities of Google, AWS, or Azure. Instead, it’s only after adopting Kubernetes that you begin to bear the heavy cost of managing a distributed system.

The Essence of Kubernetes: “Trading” Complexity, Not “Eliminating” It

The core value of Kubernetes has never been about “running containers”—Docker Compose can do that, and even systemd can. Its core value lies in the Control Plane: it provides a set of declarative APIs that allow us to describe the “desired state” of a system, and the system automatically converges the “actual state” toward that desired state.

This is a trade-off of complexity:

• What we gain: Standardized application delivery models, automated scheduling and self-healing, and unified resource abstraction.
• What we pay for: The operational cost of maintaining a distributed system, plus the need to introduce a whole ecosystem of components—networking (CNI), storage (CSI), security policies, certificate management, observability, and more.

If the complexity of your system hasn’t yet reached the point where a “control plane” is necessary for governance, then introducing K8s is purely additive—and what you’re adding is debt.

An Anti-Pattern Story: Mistaking a “Deployment Problem” for a “Platform Problem”

I once saw a classic case of “over-engineering” that I’m sure many infrastructure engineers will find familiar.

Background: A startup team, just getting off the ground, with only 3 backend services, 1 frontend project, plus MySQL and Redis. Traffic was stable, with occasional releases.

Decision: To “embrace cloud-native,” the team decided to go straight to Kubernetes. They set up a highly available control plane, configured an Ingress Controller, deployed Cert-manager, and a bunch of Prometheus Operator components.

Result (six months later):

1. Releases didn’t get faster; they got slower: The simple git pull && restart was replaced by a lengthy CI/CD pipeline—building images, pushing images, updating YAML. Developers now had to write code and learn what Pods, Services, and Ingresses were.
2. Troubleshooting complexity skyrocketed: Before, if a service went down, you checked the logs. Now, a service going down could mean a failed Liveness Probe, an OOMKilled event, an exhausted CNI IP pool, or a CoreDNS resolution timeout.
3. Infrastructure decay: Without a dedicated SRE, the cluster version fell 4 major versions behind the community, no one dared to upgrade, expired certificates caused a full-site outage, and there was even an etcd split-brain incident.

What this team really needed was probably just a well-written Ansible Playbook or a simple PaaS service.

Decision Signals: When Kubernetes is a “Must-Have”

The core criterion for deciding whether to introduce Kubernetes is: Has your pain point evolved from “single-point operations” to “large-scale governance”?

The more of the following signals you see, the clearer the benefits of K8s become:

1. Scaling and Collaboration Complexity Surge

When the number of services grows from single digits to dozens, involving multiple teams, “deployment difficulties” caused by environment differences and dependency conflicts become a bottleneck. Here, K8s’ unified delivery standard (Pod/Deployment) and namespace isolation can significantly reduce collaboration friction costs.

2. Elasticity and Scheduling Become Hard Requirements

If your business has clear traffic peaks and valleys, requiring auto-scaling (HPA/VPA); or if you need to run workloads with special scheduling requirements like AI training (e.g., Gang Scheduling), manual resource management is no longer feasible. This is where K8s’ scheduler provides immense value.

3. Multi-Tenancy and Unified Governance

When an infrastructure platform needs to support multiple business lines with strict isolation in networking (NetworkPolicy), permissions (RBAC), and resources (Quota), K8s is currently the most mature, standardized multi-tenant foundation in the industry.

4. Genuine Readiness for “Platform Engineering”

This is the most important point. Kubernetes is suitable for organizations willing to invest headcount in building a platform. This means having people responsible for cluster lifecycle management, packaging Helm Chart templates, and building an observability system. Only then can K8s become a lever for development efficiency.

Decision Signals: When Kubernetes is “Over-Engineering”

Conversely, if the following characteristics apply, proceed with caution:

• Monolithic architecture or very few microservices: The system topology is simple, dependencies are clear, and Systemd or Docker Compose is sufficient.
• Team lacks operational expertise: No dedicated engineers understand low-level networking (iptables/nftables/eBPF), storage, or container runtimes. When K8s breaks, it’s a black box.
• The only need is to “deploy containers”: Cloud providers’ serverless container services (e.g., AWS Fargate, Google Cloud Run) are a much better choice. They offer the benefits of containers while abstracting away the pain of cluster management.

Conclusion: Let Technology Return to Solving Problems

At the end of that interview, I realized: A mature architect isn’t someone who sees everything as a nail because they’re holding a hammer; it’s someone who knows when to put the hammer down.

Kubernetes is a powerful weapon, but it’s also a beast that devours operational energy. Before you decide to bring it home, make sure you truly need it to fight your battles—and that you have enough resources to feed it.

Source