Kubernetes vs. Docker Swarm vs. Nomad: The 2021 Orchestration Reality Check

Let’s be honest: half of you reading this don’t actually need Kubernetes. I said it. In the last six months, I’ve audited three different startups in Oslo that were burning thousands of kroner a month on managed K8s control planes when a simple systemd unit or a basic Swarm cluster would have sufficed. We are currently living through an era of "resume-driven development," where engineering teams deploy the most complex architecture possible just to prove they can. But when the pager goes off at 3 AM on a freezing Tuesday in February, complexity is not your friend. Complexity is the enemy that hides the root cause while your SLAs bleed out. This guide isn't about what's trending on Hacker News; it is about what actually survives production in the Nordic high-availability landscape right now, in mid-2021.

The Latency Lie and the Storage Bottleneck

Before we even compare the orchestrators, we have to talk about the dirt under the fingernails of these systems: etcd. If you are running Kubernetes, you are effectively running a distributed database that demands millisecond-level write latency. I recall a project last winter where a client migrated their Magento cluster to a budget VPS provider. They cheaped out on the underlying storage. The result? Their K8s control plane kept crashing. Why? Because etcd is sensitive to disk write latency (fsync). If your underlying VPS steals IOPS from you, or if the virtualization layer introduces jitter, the cluster loses consensus. Leaders get demoted. Pods get rescheduled. Chaos ensues. This is why we obsess over NVMe at CoolVDS. It's not just marketing fluff; it is a hard requirement for modern orchestration.

When you are debugging a flapping cluster, the first place you look isn't the pod logs; it's the disk metrics. Here is what I run immediately when I suspect I/O starvation on a controller node:

# Check for disk latency spikes specifically on the partition hosting /var/lib/etcd
iostat -xz 1 | grep sda

# Benchmark fsync specifically for etcd requirements
fio --rw=write --ioengine=sync --fdatasync=1 --directory=/var/lib/etcd --size=22m --bs=2300 --name=etcd_perf

If that fdatasync 99th percentile goes above 10ms, your Kubernetes cluster is living on borrowed time. This is where the hardware reality hits the software dream. You cannot orchestrate effectively on noisy-neighbor clouds.

The Contenders: A 2021 Snapshot

1. Kubernetes (The Standard)

Version 1.21 is out, and with the deprecation of PodSecurityPolicy looming and the Docker shim removal warning, things are shifting. Kubernetes is the operating system of the cloud. It is powerful, extensible, and undeniably heavy. It shines when you have a dedicated platform team. If you are a team of two developers, maintaining a highly available K8s cluster (managing certificates, CNI plugins like Calico or Cilium, CSI drivers, and Ingress controllers) will eat 40% of your week.

However, for granular control, nothing beats it. Let's look at a proper StorageClass configuration for high-performance databases. You don't just take the default. You need to ensure the binding mode waits for pod scheduling to maximize data locality:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nvme-high-perf
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer
parameters:
  type: nvme
  fsType: xfs

2. Docker Swarm (The Undead)

People keep saying Swarm is dead, yet it refuses to die. Why? Because docker stack deploy just works. For many SMBs in Norway, Swarm provides 80% of the value of K8s with 10% of the configuration headache. There is no etcd to manage manually (it's embedded). The mesh networking is built-in. If your architecture is "Nginx + Node.js + Postgres," Swarm is likely the TCO winner. The downside? The ecosystem is stagnant. You won't find the rich Helm chart marketplace or the operator patterns available in K8s.

3. HashiCorp Nomad (The Unix Philosophy)

Nomad v1.1 just dropped recently. It is the dark horse. Unlike K8s, which wants to containerize the world, Nomad just wants to schedule work. That work can be a Docker container, a Java JAR, or a raw binary. For teams running legacy monoliths alongside microservices, Nomad is incredible. It integrates tightly with Consul for service discovery and Vault for secrets. It is a single binary. The simplicity is intoxicating compared to the K8s control plane components (API server, scheduler, controller manager, kubelet, kube-proxy).

The GDPR & Schrems II Elephant in the Room

We need to talk about compliance. Since the Schrems II ruling last year, moving personal data to US-owned cloud providers has become a legal minefield for Norwegian companies. The Datatilsynet (Norwegian Data Protection Authority) is not sleeping on this. If you spin up a managed Kubernetes cluster on a US hyperscaler, even if the region is "Europe," you are subject to the CLOUD Act. This is where self-hosting on sovereign infrastructure becomes a strategic advantage, not just a tech choice.

By deploying your orchestrator (be it K8s or Nomad) on a provider like CoolVDS, where the metal resides in Oslo or nearby European data centers and the legal entity is local, you simplify your DPIA (Data Protection Impact Assessment) significantly. You control the encryption keys. You control the ingress. There is no opaque "managed control plane" accessing your data.

Scenario: The High-Traffic Magento Event

Let’s look at a practical configuration. We recently helped a retailer prepare for a massive sale. They were using Docker Swarm because their team knew it well. The bottleneck wasn't CPU; it was the database connection limit and the ingress throughput. We tuned the sysctl settings on the host nodes to handle the connection floods. Default Linux settings are conservative; for orchestration, you must open the floodgates.

Here is the sysctl.conf tuning we applied to the CoolVDS worker nodes:

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

# Allow reusing sockets in TIME_WAIT state for new connections
net.ipv4.tcp_tw_reuse = 1

# Increase max backlog for incoming connections
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535

# Optimize for low latency
net.ipv4.tcp_low_latency = 1

Pro Tip: Never apply these settings blindly. Monitor your dmesg and /var/log/syslog for "TCP: out of memory" errors. On CoolVDS instances, we provide generous RAM allocation so you can push these TCP buffers higher than on standard cloud instances.

Comparison Matrix: Choosing Your Weapon

Final Verdict: It’s About the Foundation

If you are building the next Spotify, use Kubernetes. If you are a small agency managing twenty client sites, use Swarm. If you are mixing legacy binaries with Docker, use Nomad. But regardless of the scheduler, the physics of the underlying server remains the same. Latency kills. Slow I/O kills.

At CoolVDS, we don’t oversell our cores. When you run top inside your container, the CPU steal time is 0.0%. That means your orchestrator’s scheduler works exactly as predicted. We use KVM virtualization to ensure strict isolation, so a noisy neighbor won't crash your etcd cluster. For the Norwegian market, where latency to the NIX (Norwegian Internet Exchange) matters for user experience, having your compute located physically close to your users is the ultimate optimization.

Don't let your infrastructure be the reason you wake up at 3 AM. Build on solid ground.

Ready to benchmark your cluster? Deploy a high-performance NVMe instance on CoolVDS today and see the difference raw I/O makes to your orchestration stability.