Orchestrator Wars 2024: Kubernetes, K3s, or Swarm?

Let’s get one thing straight: You probably don't need a 50-node Kubernetes cluster to host a WordPress site and a couple of microservices. I have seen too many engineering teams in Oslo burn through their budget and sanity trying to maintain a vanilla Kubernetes (K8s) control plane when a simpler solution would have sufficed.

However, the moment you need actual high availability (HA) and zero-downtime deployments, manual Docker containers via `docker-compose` won't cut it. You need an orchestrator.

As of late 2024, the landscape has settled. The "hype" years are over. We are in the implementation phase. For the Nordic market, where data sovereignty (Schrems II) and latency to NIX (Norwegian Internet Exchange) are critical, the choice of orchestrator is tightly coupled with your underlying infrastructure. Here is the battle-hardened reality of running containers on bare-metal performance VPS.

The Heavyweight: Vanilla Kubernetes (v1.31+)

Kubernetes is the industry standard. It creates a Resume-Driven Development culture, but it also solves massive scale problems. If you are running hundreds of microservices, K8s is the only logical choice.

The Trade-off: Complexity and Resource Overhead. A standard HA control plane (3 master nodes) consumes significant CPU and RAM just to keep itself alive. If you are deploying on a VPS, you need to ensure the underlying virtualization doesn't steal CPU cycles.

We see this constantly with `etcd`. Etcd is the brain of K8s. It is extremely sensitive to disk write latency (fsync). If your VPS provider puts you on shared HDD storage or oversold SSDs, your cluster will crash. This isn't a maybe; it's a guarantee.

Here is a typical `fio` test we run to verify if a node can handle `etcd` requirements. If your provider can't pass this, don't install K8s there.

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

On CoolVDS NVMe instances, we typically see fsync latencies well below the 10ms danger zone required by etcd. On budget hosts, this often spikes to 40ms+, causing leader election failures.

Configuration Reality Check

To run K8s securely in 2024, you aren't just applying manifests. You are dealing with complex Network Policies. Here is a snippet of a `NetworkPolicy` you must have to isolate namespaces, something Swarm struggles with natively:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

The Pragmatic Choice: K3s

For 90% of the projects I consult on in Europe, K3s (by Rancher/SUSE) is superior to vanilla K8s. It is a fully certified Kubernetes distribution but stripped of legacy cloud provider add-ons and bloated drivers. It runs as a single binary.

Why it wins on VPS: Memory footprint. You can run a functional master node with 512MB of RAM, though I recommend 2GB for stability. It replaces `etcd` with SQLite by default, but for HA, you can use embedded `etcd` or an external SQL database.

Pro Tip: When initializing K3s on a public-facing VPS, always bind the API server to the private network interface to avoid exposing your control plane to the entire internet. Use a VPN (like WireGuard) to manage it.

curl -sfL https://get.k3s.io | sh -s - server \
  --tls-san="k8s.my-coolvds-node.no" \
  --node-external-ip="185.x.x.x" \
  --flannel-backend=wireguard-native

The `--flannel-backend=wireguard-native` flag (stabilized around late 2023) is a lifesaver. It encrypts all pod-to-pod traffic automatically using the kernel's WireGuard module. This is crucial for GDPR compliance if your nodes are spread across different availability zones or data centers.

The Undead: Docker Swarm

Every year, pundits declare Swarm dead. Every year, it remains the fastest way to deploy a stack. If you don't need complex CRDs (Custom Resource Definitions) or Operator patterns, Swarm is incredibly robust.

The `docker-compose.yml` format is something every developer knows. Moving from dev to prod is seamless.

version: "3.8"
services:
  web:
    image: nginx:alpine
    deploy:
      replicas: 3
      update_config:
        parallelism: 2
        delay: 10s
      restart_policy:
        condition: on-failure
    ports:
      - "80:80"
    networks:
      - webnet

networks:
  webnet:

Running `docker stack deploy -c docker-compose.yml production` takes seconds. There is no `kubectl` version mismatch hell.

However, Swarm has limitations. Its secrets management is basic, and its networking can be flaky under high churn. If you expect to scale pods up and down every minute, the overlay network overhead might bite you unless the underlying network stack is performant. This is where the CoolVDS KVM implementation helps—we don't oversubscribe the network interface cards, ensuring your VXLAN packets don't get dropped during traffic spikes.

Storage: The Silent Killer of Orchestration

Regardless of whether you choose K8s or Swarm, stateful workloads (Databases, Redis, Elasticsearch) are the hardest part. In a containerized environment, the "noisy neighbor" effect is amplified.

If you run a Postgres container on a VPS with shared spinning rust (HDD), and another tenant on that physical host decides to compile the Linux kernel, your database transaction times will skyrocket. Your application will time out. Your customers will leave.

This is why we standardized on NVMe storage at CoolVDS. The queue depth on NVMe is massive compared to SATA SSDs. It allows for high I/O concurrency, which is exactly what microservices generate.

Benchmarking Storage for Containers

Before deploying your cluster, run an ioping test to see what kind of latency you are dealing with.

ioping -c 10 .

Target metrics for 2024:

• Excellent (CoolVDS NVMe): < 0.05 ms
• Acceptable (Standard SSD): 0.2 ms - 0.5 ms
• Danger Zone (Oversold/HDD): > 1.0 ms

Norwegian Context: Latency and Law

Hosting in Norway isn't just about patriotism; it's about physics and law. The Datatilsynet (Norwegian Data Protection Authority) has been increasingly strict regarding data transfers to non-adequate third countries.

By running your orchestration layer on CoolVDS servers physically located in Oslo, you reduce the legal headache of Schrems II compliance. Furthermore, if your user base is in Scandinavia, the latency difference is palpable.

Ping times to typical Norwegian ISPs:

Verdict: What should you use?

1. Choose K3s if you need the Kubernetes ecosystem (Helm charts, operators) but want to run efficiently on 2-4GB RAM VPS instances. This is the modern default for serious ops.
2. Choose Docker Swarm if you are a small team (1-3 devs), hate YAML complexity, and just need to keep services running.
3. Choose Vanilla K8s only if you are building a platform for other teams and have the budget for dedicated control plane nodes.

Orchestration adds overhead. Don't let your infrastructure provider add more. You need raw CPU power, predictable disk I/O, and low latency.

Ready to build a cluster that doesn't page you at 3 AM? Deploy a high-performance NVMe instance on CoolVDS today and see how fast `kubectl` can actually respond.