Kubernetes vs. Docker Swarm vs. Nomad: The 2023 Orchestration Battleground

I have spent the last six months migrating a legacy monolith for a FinTech client in Oslo. The brief was standard: "We want microservices. We want high availability. We want it now." The immediate impulse of the junior devs was to spin up a managed Kubernetes cluster with a service mesh and forty-two sidecars. My response? Stop.

Resume-Driven Development is plaguing the Nordic tech scene. In 2023, complexity is the enemy of uptime. If you are running a team of three developers, maintaining a production-grade Kubernetes control plane is a full-time job that you cannot afford. However, if you are scaling to hundreds of pods across multiple zones, Docker Swarm will eventually choke.

This is a technical breakdown of the three main contenders for container orchestration as of August 2023, analyzing them not by marketing fluff, but by how they handle failure, latency, and resources on bare-metal and VPS infrastructure.

1. Kubernetes (v1.28): The De Facto Standard

Kubernetes (K8s) won the war. With the release of 1.28 this month, it is more stable than ever. But K8s is not just an orchestrator; it is a distributed operating system. The learning curve isn't a curve; it is a wall.

The Hidden Cost: `etcd` Latency

The brain of Kubernetes is `etcd`. It is ruthlessly sensitive to disk I/O latency. If your underlying storage cannot `fsync` fast enough, the cluster leader election fails, and your control plane goes dark. I have seen this happen repeatedly on budget VPS providers that oversell their SSD storage.

Here is a snippet from a `fio` test we run to validate if a node is worthy of hosting `etcd`:

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

If the 99th percentile `fdatasync` exceeds 10ms, do not deploy K8s there. At CoolVDS, our local NVMe storage consistently clocks well below this threshold, which is why our KVM instances are often used as control plane nodes for self-hosted clusters.

Configuration for Stability

When deploying on virtualized hardware, you must be explicit about eviction thresholds to prevent the node from locking up completely.

# kubelet-config.yaml snippet
eviationHard:
  memory.available: "500Mi"
  nodefs.available: "10%"
  imagefs.available: "15%"
systemReserved:
  memory: "1Gi"
  cpu: "500m"
kubeReserved:
  memory: "500Mi"
  cpu: "200m"

This configuration reserves resources for the OS and the K8s daemons. Without this, a memory leak in a single pod can OOM-kill the `kubelet` process.

2. Docker Swarm: The "It Just Works" Solution

Docker Swarm is not dead. For small to medium teams in Norway who need GDPR compliance without the headache of managing ingress controllers, cert-manager, and CSI drivers, Swarm is incredibly efficient.

The beauty of Swarm is its integration with `docker-compose.yml`. You do not need to rewrite your manifests into verbose YAML charts. It uses a gossip protocol that is far less demanding than `etcd`.

Pro Tip: Use Swarm for stateful workloads only if you have pinned containers to specific nodes using constraints. Swarm's volume management is less mature than K8s CSI.

A typical high-availability setup looks like this:

# docker-compose.yml for Swarm
version: "3.8"
services:
  web:
    image: nginx:alpine
    deploy:
      replicas: 3
      update_config:
        parallelism: 1
        delay: 10s
      restart_policy:
        condition: on-failure
      placement:
        constraints:
          - node.role == worker
    ports:
      - "80:80"

You can deploy this in seconds. No Helm charts, no RBAC headaches. However, Swarm lacks the rich ecosystem of Operators. If you need to run a complex database cluster with automated failover, you will be writing custom scripts.

3. HashiCorp Nomad: The Unix Philosophy Alternative

Nomad is the middle ground. It is a single binary. It schedules containers, but also Java JARs, binaries, and virtual machines. It is simpler than K8s but more powerful than Swarm.

The issue with Nomad in Europe is the talent pool. Finding a DevOps engineer in Oslo who knows `hcl` (HashiCorp Configuration Language) is harder than finding one who knows Kubernetes YAML. However, Nomad scales massively. It famously runs the 2M+ container cluster at Cloudflare.

The Infrastructure Reality Check

Regardless of which orchestrator you choose, the software cannot fix broken hardware. The number one cause of "flaky" containers is CPU Steal.

When you rent a cheap VPS, you are often sharing CPU cores with fifty other customers. If one of them decides to mine crypto, your Docker container waits for CPU cycles. This introduces latency spikes that trigger health check timeouts. The orchestrator kills the container, restarts it, and the cycle repeats.

Why CoolVDS Architecture Matters Here

We built CoolVDS on KVM (Kernel-based Virtual Machine) with strict resource isolation. We do not oversell CPU cores to the point of contention. This is critical for Norway-based businesses where latency to the NIX (Norwegian Internet Exchange) needs to be under 5ms.

Deployment: A Real-World Scenario

Let's say you are deploying a Postgres cluster with auto-failover. On Kubernetes, you would use the Zalando Postgres Operator. It relies heavily on the API server.

If you are running this on a shared VPS with HDD or slow SATA SSDs, the Operator will time out during failover. Your database will split-brain. Data corruption follows.

Here is how you verify your disk speed on a Linux node before installing the K8s kubelet:

# Check random read/write IOPS
fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=4k --size=4g --numjobs=1 --iodepth=1 --runtime=60 --time_based --end_fsync=1

On a CoolVDS NVMe instance, you will see IOPS in the tens of thousands. On a standard budget VPS, you might see 300. That difference is the line between a successful deployment and a 3 AM pager duty call.

Conclusion

If you are a massive enterprise with a dedicated platform team, use Kubernetes. If you are a startup or an agency optimizing for speed of delivery, stick to Docker Swarm or look at Nomad.

But never ignore the layer below. Orchestrators are just traffic controllers; they need a solid runway. Don't let IOPS bottlenecks or noisy neighbors kill your uptime.

Ready to build a cluster that actually stays up? Deploy your high-performance control plane on CoolVDS today and experience the stability of true hardware isolation.