Kubernetes vs. K3s vs. Docker Swarm: Picking the Right Poison for Production

I still remember the silence. It wasn't a peaceful silence; it was the deafening quiet of a Slack channel at 3:00 AM after a production cluster decided to eat its own control plane. The culprit? Disk latency on a budget VPS provider in Frankfurt causing etcd to elect a new leader every 45 seconds. The cluster wasn't down technically—it was just too busy fighting itself to serve traffic.

If you are deploying container orchestration in 2024, you aren't just picking software. You are picking a headache you can live with. For teams targeting the Norwegian market, the decision is compounded by data sovereignty laws (Schrems II is still haunting us) and the need for single-digit millisecond latency to Oslo.

Let’s strip away the marketing fluff. We are going to look at the three main contenders: standard Kubernetes (K8s), the lightweight K3s, and the "dead but not really" Docker Swarm. We will focus on what actually matters: resource overhead, complexity, and the underlying iron needed to run them.

1. Kubernetes (The 800lb Gorilla)

Standard Kubernetes is the de facto standard. If you are running a massive microservices architecture with 50+ developers, you probably need it. But for many, it is like using a sledgehammer to crack a nut.

The hidden cost of vanilla K8s is the control plane. You aren't just running your apps; you are running an API server, a scheduler, a controller manager, and the notoriously I/O-hungry etcd database.

The etcd Bottleneck

Most outages I see in Norway aren't code bugs; they are storage failures. etcd demands synchronous writes to disk. If your VPS provider creates IO wait times, your cluster explodes. This is where hardware selection becomes critical. On CoolVDS, we specifically map NVMe storage to handle these fsync operations because standard SSDs often choke under the write pressure of a busy API server.

Here is a standard storage class configuration you should be using to ensure you are hitting the fast disk:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-nvme
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
parameters:
  type: nvme-local

2. K3s (The Sharp Scalpel)

Rancher’s K3s has stripped the bloat. By removing legacy cloud providers and non-essential drivers, they reduced the binary size to less than 100MB. For a startup or a mid-sized Norwegian e-commerce site, this is often the superior choice. It supports SQLite instead of etcd (though you can still use etcd), which lowers the memory footprint drastically.

I recently migrated a client from a managed massive K8s cluster to a three-node K3s cluster hosted on CoolVDS instances in Oslo. Their monthly bill dropped by 60%, and their deployment time went from 4 minutes to 45 seconds.

Pro Tip: If you are running K3s in production, do not use the default Traefik ingress if you have high traffic needs. Swap it for NGINX for better control over header manipulation and caching policies.

Installing K3s without the fluff

Don't just curl the script blindly. Set your flags to disable the parts you will replace later:

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server \
  --disable traefik \
  --disable servicelb \
  --write-kubeconfig-mode 644 \
  --node-ip 10.0.0.5" sh -

3. Docker Swarm (The AK-47)

Tech Twitter loves to say Swarm is dead. Tech Twitter is wrong. For teams that just want to take a docker-compose.yml file and scale it across three servers, Swarm is unbeaten. It lacks the rich ecosystem of K8s (no Helm charts, no Operators), but it is incredibly stable and simple.

If your DevOps team is just one developer who is also the backend lead, use Swarm. You can set up a cluster in 30 seconds:

The Infrastructure Reality Check

Regardless of which orchestrator you choose, the underlying OS tuning is mandatory. Linux default settings are not designed for container networking. You will hit connection tracking limits before you hit CPU limits.

On every node I provision, whether it's a bare-metal server or a CoolVDS instance, I apply the following sysctl tweaks to handle the NAT traffic generated by containers:

# /etc/sysctl.d/99-k8s-networking.conf

# Increase the connection tracking table size
net.netfilter.nf_conntrack_max = 131072

# Shorten the timeout for established connections to free up table space
net.netfilter.nf_conntrack_tcp_timeout_established = 86400

# Allow IP forwarding (Absolute requirement for CNI plugins)
net.ipv4.ip_forward = 1

# Increase the range of ephemeral ports
net.ipv4.ip_local_port_range = 1024 65535

Apply it with sysctl --system.

Latency and Compliance in Norway

Latency is the silent killer of distributed systems. If your worker nodes are in Oslo and your master node is in Amsterdam, the round-trip time (RTT) adds up on every API call. For Norwegian businesses, keeping data inside the borders is also a compliance safety net regarding GDPR and the Datatilsynet guidelines.

We built CoolVDS infrastructure specifically to address this. By placing high-frequency CPU instances directly in Norwegian data centers, we reduce the RTT to the NIX (Norwegian Internet Exchange) to under 2ms for local traffic. This makes your cluster feel instantaneous.

Final Verdict

There is no "best" tool, only the right tool for your constraints.

• Choose Kubernetes if you need the ecosystem (Prometheus, Istio, ArgoCD) and have a dedicated platform engineer.
• Choose K3s if you want the K8s API but don't want to burn 4GB of RAM just to say hello.
• Choose Swarm if you value your sleep and just need to run containers.

Whatever you pick, don't let slow I/O be the reason your cluster fails leader election. High-performance orchestration requires high-performance storage. Deploy a test cluster on CoolVDS today and see what dedicated NVMe resources do for your stability.