Why Deploying Kubernetes on Just Three Servers Is Overkill

Interviewers often expect candidates to recite Kubernetes concepts, yet most early‑stage startups run only a few machines and manage services with a simple ssh + git pull workflow.

One friend spent three months learning K8s, debugging YAML and service meshes, only to discover his product served a few dozen users on two servers, while the deployment method remained a single systemd service.

The author likens this to buying a fifty‑seat bus for a two‑person family – the capacity exists, but the cost and effort are wasted.

Kubernetes, originally named after the Greek word for “pilot,” was open‑sourced by Google as a solution for managing hundreds of thousands of machines, but the crucial question remains: how many servers do you actually have?

Typical early‑stage infrastructure consists of:

One primary server running the application

One managed database server (Postgres or MySQL)

One Redis cache instance

Background tasks can be handled by a systemd timer plus a Bash script, and backups by a nightly cron job – all achievable with a few dozen lines of configuration.

Example systemd unit file:

[Unit]
Description=Application Server
After=network.target

[Service]
User=app
WorkingDirectory=/app
ExecStart=/app/bin/server
Restart=on-failure
RestartSec=10
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Common systemd commands (cheat sheet):

# View service status
systemctl status app.service

# Start / stop / restart
systemctl start app.service
systemctl stop app.service
systemctl restart app.service

# View logs
journalctl -u app.service --since today
journalctl -u app.service -f

# Enable at boot
systemctl enable app.service

# List timers (cron‑style)
systemctl list-timers

In contrast, a minimal Kubernetes deployment for a single service requires at least five YAML files (Deployment, Service, ConfigMap, Secret, Ingress), each dozens of lines, not counting additional manifests for monitoring, logging, or network policies.

The author calls the rush to adopt K8s an “optimization theater” – impressive on stage but rarely useful for small teams whose real bottleneck is focus, not orchestration.

Linear growth (three servers → five → ten) does not demand a distributed‑systems research effort; systemd comfortably handles such scaling.

Cost comparison: a t3.large instance (~$100 / month), managed Postgres with backup (~$200 / month), and monitoring/logging (~$50 / month) total about $350 / month and can sustain high traffic. Kubernetes adds control‑plane fees, node costs, storage, load balancers, and the salary of an on‑call engineer, turning the primary expense into time rather than money.

Learning and maintaining Kubernetes consumes developer days that could be spent gathering user feedback or shipping features.

Only when a service outgrows a few machines, requires dozens of daily deployments, or needs sophisticated scheduling does Kubernetes become a justified investment; premature migration leads to unnecessary pain.

Ultimately, the most resilient tools are the unglamorous ones – Nginx, Postgres, MySQL, Bash, and systemd – which are predictable, well‑documented, and keep infrastructure invisible, allowing teams to focus on product development.