Kubernetes has become the tool that simultaneously solves everything and creates a pile of problems you didn’t know you had. If you’ve spent any time managing infrastructure in the last five years, you’ve either built a shrine to it or cursed its existence.
There is a very active Hacker News thread underway that dives straight into this discussion, offering an unfiltered, brutally honest look at why Kubernetes is both the savior and scourge of modern DevOps.
Here’s a few highlights of what the community really thinks when the gloves come off.
Kubernetes is Overkill for Most
One thing stood out among the commenters…most of you don’t need Kubernetes, and this thread pulls no punches about it. “Why does every startup with three developers and a glorified CRUD app think they need Kubernetes?” writes one commenter. Another quips, “We ran everything on a single VPS for years, and somehow, the world didn’t end.”
The sentiment is clear…Kubernetes is often a solution looking for a problem. Sure, it makes sense for Google-scale workloads with thousands of services and deployments, but for most companies, it’s just a costly vanity project. One user points out, “If you have fewer than 50 microservices, you’re wasting time and money. A couple of VMs and a load balancer would do just fine.”
Even startups chasing the unicorn dream of infinite scaling miss the point. “You don’t need to worry about scaling until you actually have customers. Spend that time fixing your product, not wrestling with YAML files,” said a weary contributor.
YAML Hell and the Curse of Copy-Paste Ops
Let’s talk YAML, the configuration language that makes even the most seasoned engineers mutter obscenities under their breath while writing it. As one user put it, “All I ever do with Kubernetes is update and break YAML files, then spend the rest of the day on Stack Overflow trying to figure out why it doesn’t work.”
Another comment was: “YAML is just a format, not a strategy. The real problem is the ecosystem—there’s always one more magical sidecar or service mesh that someone swears is necessary. You end up drowning in configuration spaghetti.”
Kubernetes promises standardization, but in reality, it often delivers chaos. One commenter described their experience with a team that added new tools and features at every turn, creating a monster no one could maintain. “It’s not always the junior devs causing this,” they noted. “Sometimes, senior engineers overcomplicate things to justify their existence.”
Resume-Driven Development: A Dirty Secret
Let’s address the elephant in the server room. Why do so many teams adopt Kubernetes when they don’t need it? Simple: it looks good on a resume. “The reality is, Kubernetes adoption is often driven by engineers who want to play with the latest shiny thing or add buzzwords to their CV,” one commenter said bluntly. Another user took it a step further, labeling it as “a conspiracy of senior engineers and managers to over-engineer systems, all under the guise of progress.”
This isn’t just a junior developer issue either. “Even the seniors do it,” another contributor explained. “They’ll push Kubernetes into environments that don’t need it, then spend months building out a bespoke PaaS no one asked for. Meanwhile, the business foots the bill.”
The Good, the Bad, and the Ugly of Scale
Kubernetes thrives at scale, but most companies don’t need it to get there. “If you hit tens of millions of users, maybe Kubernetes makes sense,” one commenter admitted. “But until then, you’re better off with a few VMs and some decent monitoring.”
That said, the benefits at scale are undeniable. Kubernetes provides abstraction, portability, and resilience that few other tools can match. For companies with massive workloads, it’s a godsend. One contributor managing thousands of clusters explained: “The key is keeping it simple. Use only the core features, and you’ll love it. Add a million sidecars, and you’ll spend your life debugging.”
But there’s a dark side to this success. “Kubernetes doesn’t just solve your problems—it shifts them,” noted another user. “Instead of managing VMs, you’re managing nodes, control planes, and a sprawling YAML forest. It’s trading one complexity for another.”
Managed Kubernetes: The Middle Ground
If you’re determined to use Kubernetes, why not let someone else do the hard stuff? Managed services like AWS EKS or GCP GKE take much of the operational burden off your plate. “For small teams, managed Kubernetes is a no-brainer,” one commenter said. “It’s like hiring a babysitter for your cluster.”
But even managed Kubernetes has its limits. One critic pointed out, “Managed clusters are just training wheels. Eventually, you’ll outgrow them and face the same issues you tried to avoid.”
Others raised concerns about cost. “The price of an empty EKS cluster is ridiculous,” one user lamented. “At $70 a month, you might as well just stick to VMs until you really need the complexity.”
The Alternatives You’re Ignoring
So, what’s the alternative? The thread was full of practical suggestions:
- PaaS Solutions: Heroku, Google App Engine, and AWS Elastic Beanstalk remain favorites for teams that value simplicity. “Why reinvent the wheel when PaaS handles 99% of use cases?” asked one advocate.
- Managed Kubernetes on Cloud: Get the best of low-maintenance and look for offerings (e.g. EMP) with cost-optimized management planes that can get you out of the weeds and out of the CFO’s bad books.
- Lightweight Kubernetes: Tools like K3s offer Kubernetes-like functionality without the bloat. “For small setups, K3s is brilliant. It’s Kubernetes without the baggage,” one user shared.
- Good Old VMs: Sometimes, the simplest solution is the best. “A couple of VMs, a load balancer, and some shell scripts can go a long way,” another user said. “Don’t underestimate the power of keeping it simple.”
The Philosophy Problem
At its heart, the Kubernetes debate is about philosophy. Are we chasing elegance or pragmatism? “Kubernetes is great if you’re Google,” one user argued. “But most businesses aren’t Google, and they don’t need Google’s tools.”
Another commenter summed it up quite nicely: “Do you want to build a product, or do you want to build an infrastructure team? Kubernetes makes sense for the latter, but it’s often overkill for the former.”
General Thoughts from the Community
Kubernetes isn’t inherently bad. It’s a powerful tool that solves real problems for the right teams. But as this thread proves, it’s not the panacea it’s often made out to be. Too many organizations adopt it prematurely, chasing scale they don’t need and complexity they can’t afford.
The lesson here is simple: Use Kubernetes when you must, but don’t fool yourself into thinking it’s the only way. Sometimes, the best infrastructure is the one you barely notice. As one wise commenter put it: “Kubernetes is like driving a Ferrari to the grocery store. Sure, it’s cool, but do you really need it?”
Use Cases Where Kubernetes Shines
Square peg, meet round hole. This is what we think of when we have the wrong infrastructure choice. Kubernetes does shine brightly in some very key situations.
- High Availability and Scalability: Kubernetes excels in environments requiring robust scaling and fault tolerance, such as multi-region deployments or large-scale microservices architectures.
- Multi-Cloud and Portability: Kubernetes provides a consistent API across environments, enabling organizations to manage workloads across multiple cloud providers or on-prem setups.
- Bare Metal and K3s: Lightweight Kubernetes distributions like K3s were suggested for those wanting Kubernetes’ features without the full complexity.
Remember to always put the workload and operational patterns into context when evaluating if Kuberenetes is the right choice.
Costs and Operational Overheads
We often say “it’s the cost of doing business”, but we can also optimize the cost of doing business.
- Infrastructure Costs: The high baseline cost of Kubernetes clusters, particularly for managed services like AWS EKS or GCP GKE, is a major concern for small teams.
- Operational Complexity: Maintaining a Kubernetes cluster, whether self-managed or through a provider, often requires dedicated expertise, which may not be justified for small-scale operations.
Staffing and skill challenges create both tangible and intangible costs for Kubernetes operations.
General Kubernetes Operator Sentiments
These two really sum it up well:
- It’s a Love-Hate Relationship: Some users find Kubernetes indispensable for complex setups, while others resent the operational headaches it introduces.
- It’s a Balance of Simplicity and Features: The discussion underscores the need to balance adopting powerful tools like Kubernetes with simpler, more appropriate solutions.
We all seek balance, and balance means weighing one side against the other. This is also why we are enterprise architects and builders. We love finding equilibrium in the face of challenge and chaos.
More to Come, and Lots to Think About
The discussion thread and what I summarized here is meant to show a balanced and very user-driven view of Kubernetes. We need to emphasize that it’s not a one-size-fits-all solution. While it is an ideal fit for certain large-scale and complex scenarios, its adoption should be carefully evaluated against the needs and capabilities of the team or organization.
There are a lot of challenges but also some advantages with adopting the patterns that Kubernetes supports. This is likely going to remain a contentious discussion for quite a few years to come. It may also end up the same as many other transition discussions of the past.