Kubernetes vs. Docker Swarm: A 2023 Reality Check for Norwegian DevOps

It was 3:00 AM in Oslo, and the latency on our primary ingress controller had just spiked from 15ms to 400ms. We weren't under a DDoS attack. We hadn't deployed new code. The culprit? Noisy neighbors on a generic public cloud stealing CPU cycles from our control plane. That night taught me a lesson that no certification course covers: your orchestrator is only as reliable as the metal it runs on.

In 2023, the pressure on Norwegian engineering teams is twofold: deliver high-availability services that compete globally while navigating the strict data sovereignty requirements of Datatilsynet and GDPR (post-Schrems II). Whether you are running a fintech stack requiring milliseconds at NIX (Norwegian Internet Exchange) or a simple CMS, choosing the right orchestration tool isn't just about features—it's about operational sanity.

The Latency & Compliance Trap

Before we look at the YAML, let's talk about the infrastructure. If you are hosting customer data for Norwegian entities, keeping that data within national borders isn't just a "nice to have"; it is often a legal necessity. Furthermore, physics still applies. Routing traffic from Oslo to a data center in Frankfurt and back adds unavoidable latency.

Pro Tip: When benchmarking your orchestration layer, always check /proc/stat for 'st' (steal time). If you see anything above 0.0 on a consistent basis, your VPS provider is overselling their CPU. This causes jitter in etcd leader elections, leading to cluster instability.

Docker Swarm: The "Just Works" Solution

Don't believe the Reddit threads claiming Swarm is dead. For teams of less than 10 engineers, Docker Swarm remains the most efficient path to production. It lacks the complex networking overlay overhead of Kubernetes, meaning simpler debugging and often faster packet processing.

Initialization is instantaneous. You don't need a PhD in networking to set this up:

Here is a real-world example of a Swarm stack optimized for a CoolVDS instance. Note the resource limits—crucial for preventing a single container from starving the host.

version: '3.8'
services:
  nginx:
    image: nginx:1.23-alpine
    ports:
      - "80:80"
      - "443:443"
    deploy:
      replicas: 3
      update_config:
        parallelism: 1
        delay: 10s
      restart_policy:
        condition: on-failure
      resources:
        limits:
          cpus: '0.50'
          memory: 512M
        reservations:
          cpus: '0.25'
          memory: 256M
    networks:
      - webnet

networks:
  webnet:
    driver: overlay
    driver_opts:
      encrypted: "true"

The Trade-off: Swarm struggles with stateful workloads. If you need complex persistent volume claims (PVCs) attached to specific pods moving across nodes, Swarm's CSI support is limited compared to K8s.

Kubernetes (K8s): The Standard for a Reason

Kubernetes (v1.26 as of writing) is the heavy lifter. It is necessary when you have microservices that need sophisticated service discovery, autoscaling based on custom metrics, or granular role-based access control (RBAC).

However, K8s is resource-hungry. A base control plane can easily consume 2GB of RAM just to exist. This is where underlying hardware quality becomes critical. Running K8s on slow spinning disks is a death sentence because etcd requires very low fsync latency.

To prepare a node for K8s, you must disable swap and tune the kernel. I run this script on every CoolVDS node before bootstrapping:

#!/bin/bash
# Disable swap explicitly
swapoff -a
sed -i '/ swap / s/^/#/' /etc/fstab

# Load kernel modules
cat <