Kubernetes vs. Docker Swarm in 2019: Architecting for Low Latency and Norwegian Data Sovereignty

I recently watched a production cluster self-immolate during a Black Friday pre-test. It wasn't because of bad code. It wasn't a memory leak. It was iowait. The underlying infrastructure, hosted on a budget provider somewhere in Central Europe, couldn't handle the etcd write frequency required by Kubernetes 1.16 when traffic spiked. The leader election timed out, the control plane panicked, and the pods entered a crash loop. It was a mess.

We are closing out 2019, and while Kubernetes has effectively won the mindshare war, Docker Swarm remains a stubborn, pragmatic contender for smaller teams. But choosing an orchestrator isn't just about syntax; it's about matching the software complexity to your infrastructure's physical reality—especially here in Norway where latency to NIX (Norwegian Internet Exchange) and data sovereignty under GDPR are critical factors.

The Great Divide: Complexity vs. Velocity

If you are managing a massive microservices architecture, you need Kubernetes. If you are a team of three developers deploying a monolithic rails app with a sidecar Redis, Swarm might still be your friend. But let's look at the resource cost.

Docker Swarm is native. It runs on the Docker engine you already have. It's lightweight. I've run stable Swarm clusters on 1GB RAM instances (though I don't recommend it for production).

Kubernetes, on the other hand, is a beast. It requires a control plane (API server, scheduler, controller manager) and a key-value store (etcd). These components are hungry. If you starve them of CPU cycles or disk I/O, the cluster becomes unstable.

The Hidden Killer: Noisy Neighbors and CPU Steal

In a containerized environment, the "Noisy Neighbor" effect is amplified. If you are sharing a physical core with a crypto-miner on a cheap VPS, your K8s scheduler will lag. This is where virtualization technology matters. We strictly use KVM at CoolVDS because it provides harder isolation than container-based virtualization like OpenVZ. When you run top and see %st (steal time) above 0.0, your orchestration is compromised.

Technical Deep Dive: The Etcd Storage Problem

Kubernetes relies entirely on etcd for state. Etcd is sensitive to disk write latency. If fsync takes too long, the heartbeat fails.

Pro Tip: Never run a production Kubernetes cluster on standard HDD or shared SATA SSDs without guaranteed IOPS. The official etcd documentation recommends 10ms as the 99th percentile for strict write latency.

Here is how we tune disk priority for etcd on our CoolVDS NVMe instances to ensure the kernel prioritizes these writes:

If you are deploying on CoolVDS, our local NVMe storage arrays consistently deliver sub-millisecond latency, which essentially eliminates etcd timeouts even under heavy load.

Configuration Battle: Swarm vs. K8s

Let's look at defining a simple Nginx service. The difference in boilerplate is staggering.

Docker Swarm (Simple)

version: '3.7'
services:
  web:
    image: nginx:alpine
    deploy:
      replicas: 3
      restart_policy:
        condition: on-failure
    ports:
      - "80:80"
    networks:
      - webnet
networks:
  webnet:

Kubernetes (Verbose but Powerful)

In K8s, you need a Deployment and a Service. It's more verbose, but it gives you rolling updates, liveness probes, and readiness probes out of the box.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.5
        ports:
        - containerPort: 80
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 3
          periodSeconds: 3
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

Network Latency: The Oslo Factor

For Norwegian businesses, the physical location of the cluster is often overlooked. If your users are in Oslo or Bergen, routing traffic to a data center in Frankfurt adds 20-30ms of latency per round trip. In a microservices architecture where a single user request might trigger 10 internal service calls, that latency compounds.

By keeping the control plane local, you also satisfy Datatilsynet's stringent requirements regarding data processing locations. Even with the Schrems II case looming in the EU courts (we are all watching the CJEU closely right now), keeping data within Norwegian jurisdiction is the safest bet for compliance.

Ingress Controllers: The Gateway

In 2019, Nginx Ingress is still the king. Configuring it correctly handles SSL termination and routing. A common mistake I see is not tweaking the keepalive connections.

# Inside your nginx-ingress ConfigMap
data:
  keep-alive: "75"
  keep-alive-requests: "100"
  worker-processes: "4"
  # Crucial for preventing buffer overflow attacks
  client-header-buffer-size: "1k"
  large-client-header-buffers: "4 8k"

When to use what?

• Choose Docker Swarm if: You have a small team, limited DevOps resources, and just need to get containers online fast.
• Choose Kubernetes if: You need autoscaling, complex service discovery, secrets management, and you have the budget for the overhead.

Regardless of your choice, the orchestrator is only as good as the hardware it sits on. Containers are ephemeral, but your data isn't. Running Kubernetes on CoolVDS provides the raw NVMe I/O throughput and consistent CPU performance required to keep the API server responsive and etcd happy.

Don't let high latency kill your deployment. Spin up a KVM-based instance with local NVMe in our Oslo facility today. Test your cluster performance where it counts.