The other day, while chatting with a friend, he was talking about setting up infrastructure for his personal website. “Mustafa, do you think I should set up Kubernetes for this site?” he asked. I paused and thought to myself, “Again?” As someone running over 13 Docker containers on my own VPS — including this blog and four side products on a single server — I sometimes struggle to understand this “let’s solve everything with Kubernetes” approach.
For a simple blog, the static front-end of an e-commerce site, or just a handful of microservices, getting into a structure this complex feels like unnecessary operational overhead and cost. My experience has shown me that the latest, most popular tech is not necessarily the best solution to every problem. In fact, sometimes it’s the shortest path to making the existing problem worse.
The Allure of Kubernetes and the Real Trap
Kubernetes is genuinely a dazzling technology with promises of scalability, high availability and automation. It’s a beast designed to manage large, distributed systems and run thousands of microservices in coordination. But taming that beast — understanding it and operating it — takes far more effort, knowledge and resources than we tend to assume.
I see lots of developers and architects starting projects with the bias of “we should use Kubernetes” before they’ve even begun. That’s usually a choice made without fully analyzing the actual size of the problem and the existing alternatives. It’s the classic situation: when you have a hammer in your hand, everything starts to look like a nail.
Turning a Small Problem Into a Giant Solution
Let me give you a simple example: take my own financial calculator site, hesapciyiz.com. It’s an Astro-built structure, made of static files and fed by a few Node.js APIs. What would I need to run a project like that on Kubernetes? At minimum a 3-node cluster, an Ingress Controller, a Load Balancer, Persistent Volumes, various Deployments, Services, ConfigMaps, and probably a Helm chart.
The time and money I’d spend setting up, managing, monitoring and troubleshooting all those layers would be absurd compared to the value the site provides. I brought this site up on my own VPS using Nginx, PM2 and systemd — much simpler, cheaper and faster. For a site receiving a few hundred requests a day, the benefit Kubernetes brings would stay marginal while the operational complexity would multiply.
My Experience With My Own VPS, and Some Comparisons
My VPS is, in a way, an example of “minimalist orchestration.” It runs more than 13 Docker containers — PostgreSQL, Redis, this blog, hesapciyiz.com, islistesi.com and a few other tools. I manage all of them with docker compose and systemd services. Everything works smoothly, and my operational load is quite low.
Of course, problems pop up from time to time. Take the disk-100%-full incident on my VPS on the morning of April 28. I had forgotten to run docker system prune, so 33 GB of build cache and 23 GB of unused images had piled up. In that situation kcompactd %92 CPU was making the box unable to even accept ssh connections. The extra complexity Kubernetes would bring in this scenario would only deepen the problem. In that moment all I wanted was to clean up with a simple command and breathe — otherwise even finding the root cause becomes harder.
Operational Simplicity With Docker and systemd
For small and mid-sized projects, the Docker + systemd duo can deliver a huge chunk of the automation Kubernetes provides at far lower complexity. With docker compose I easily define my services, manage their networks and persistent volumes. With systemd services I get auto-start at boot, restart on crash, and resource limit enforcement.
For example, this blog’s Astro build sometimes eats 2.5 GB of RAM and goes OOM (Out Of Memory) while the system already has 7.6 GB used. Even managing a single such process on Kubernetes requires a bunch of resource request, limit, liveness/readiness probe definitions. For me, a systemd service, a restart=on-failure parameter and a simple MemoryMax setting are enough. I don’t see any logic in sacrificing such a simple solution to the complexity of a giant system like Kubernetes.
Cost, Complexity and Learning Curve
Moving to Kubernetes is not just a technical decision — it’s a serious cost and human-resource investment. Using a managed Kubernetes service (EKS, GKE, AKS) is much pricier than just renting a plain VM. Setting up and managing your own Kubernetes cluster is a domain that requires expertise and increases operational cost.
In addition, Kubernetes has a steep learning curve. It takes time for everyone on your team to understand the system, troubleshoot problems and deploy new applications. For a small team or a one-person project, that investment often turns into a non-recoverable expense. When you need to do CVE mitigation (like blacklisting the algif_aead module), Kubernetes’ layered structure can make things even harder. On a plain Linux server, those tasks are far simpler.
When Is Kubernetes Really Necessary?
After saying so many “no to Kubernetes,” let me also explain when I say yes. Kubernetes is genuinely indispensable in certain scenarios:
- Large-scale microservice architectures: Systems with hundreds or thousands of microservices, constantly changing and interacting with each other.
- High-availability and auto-scaling needs: When your applications need to handle hundreds of thousands of instantaneous requests and scale horizontally on their own.
- Complex deployment strategies: When you want to automate advanced deployment patterns like canary or blue/green deployments.
- Resource optimization: When you want to use server resources very efficiently and run various applications in isolation on the same cluster.
- Team size and expertise: When you have a large DevOps team that genuinely owns Kubernetes operations.
Outside these scenarios, simpler and more cost-effective solutions are usually available.
A Pragmatic Approach: Picking the Right Tool
My architectural philosophy is always built on pragmatism. Instead of picking the most complex or most popular tool to solve a problem, I try to pick the most appropriate, most sustainable and most cost-effective tool. Sometimes that’s a plain VM and Docker Compose; sometimes a simple PaaS solution (Heroku, Render); and yes, sometimes Kubernetes.
Even while building my AI-driven content pipeline, I implemented patterns like preflight resource guard, auto-fix and dedup-alert without needing Kubernetes — just with simple systemd services and custom scripts on my VPS. That gave me both control and a way to avoid unnecessary complexity.
In short, Kubernetes is a tremendous tool that saves lives when used in the right place at the right time. But like hammering every nail, trying to solve every problem with Kubernetes can turn into an operational nightmare. For my own small projects or simple internal services at companies, I still believe in the power of a plain VM, Docker Compose and systemd. So what do you think? Have you had a project where you said “did we really need Kubernetes here?” Feel free to share in the comments.