Kubernetes vs. Docker Swarm: Orchestration Survival Guide for 2017

It is 3:00 AM. Your pager is screaming because the `frontend` container died, and the load balancer is still routing traffic to a black hole. If you are manually SSH-ing into servers to run docker restart, you are doing it wrong. But if you are trying to deploy a full Kubernetes cluster for a simple WordPress shop, you are also doing it wrong.

In 2017, the container wars have shifted. It is no longer about how to containerize (we all use Docker now), but how to manage the chaos across multiple hosts. This is orchestration.

As a Systems Architect operating out of Oslo, I see too many teams paralyzed by choice. Do you go with the Google-backed behemoth, Kubernetes (k8s)? Or stick with the native simplicity of Docker Swarm Mode introduced in 1.12? Let's break down the technical reality, stripping away the marketing noise.

The Contender: Docker Swarm Mode

Since Docker 1.12, Swarm is integrated into the engine. No external key-value store, no complex certificate generation. It just works. For 80% of the setups I see in Norway—small to mid-sized dev teams—this is the pragmatic choice.

The Setup Reality

Setting up Swarm takes three commands. Literally.

# On the Manager Node (e.g., CoolVDS NVMe Instance 1)
root@oslo-mgr-01:~# docker swarm init --advertise-addr 10.0.0.5
Swarm initialized: current node (dxn1...) is now a manager.

# On the Worker Node
root@oslo-wrk-01:~# docker swarm join \
    --token SWMTKN-1-49nj1cmql0n5rusp... \
    10.0.0.5:2377

Compare that to the 15-page guide required to bootstrap a highly available Kubernetes control plane.

The Configuration

Swarm uses the familiar docker-compose.yml (version 3) format. If your developers can write a compose file, they can deploy to production. This lowers the barrier to entry significantly.

version: '3'
services:
  nginx:
    image: nginx:1.11-alpine
    ports:
      - "80:80"
    deploy:
      replicas: 3
      update_config:
        parallelism: 1
        delay: 10s
      restart_policy:
        condition: on-failure

The Heavyweight: Kubernetes (v1.5)

Kubernetes is not just an orchestration tool; it is a framework for distributed systems. It is powerful, verbose, and unforgiving. With the release of 1.5 in December 2016, we finally got StatefulSets (formerly PetSets) in beta, which makes running databases slightly less terrifying.

However, the operational overhead is massive. You need to manage etcd clusters, overlay networking (Flannel, Calico, or Weave), and the sheer volume of YAML required is daunting.

The Kubernetes Complexity

Here is a snippet just to deploy a simple Nginx pod with a service:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
---
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.11
        ports:
        - containerPort: 80

Why choose Kubernetes? If you have a team of 50+ engineers, need complex autoscaling based on custom metrics (not just CPU), or require granular pod disruption budgets, K8s is the standard.

The Hidden Bottleneck: Storage & Virtualization

Regardless of your orchestrator, your containers are only as fast as the kernel they run on. This is where I see most Norwegian deployments fail. They try to run Docker on OpenVZ or LXC containers. Do not do this.

Docker manipulates iptables and cgroups extensively. When you run Docker inside a container-based VPS (like OpenVZ), you are fighting the host's kernel restrictions. You will see "noisy neighbor" issues where CPU steal time spikes because another customer is compiling kernels on the same node.

Pro Tip: Always use KVM-based virtualization for Docker hosts. KVM provides full kernel isolation. We use KVM exclusively at CoolVDS because it allows you to load specific kernel modules required for advanced overlay networks (VXLAN) without begging support for permission.

I/O Latency: The Silent Killer

Container images are composed of layers. Pulling images, untarring layers, and writing logs creates heavy random I/O. On standard spinning HDDs, a docker pull can saturate the disk controller, causing your production API to time out.

We ran a fio benchmark comparing standard SSD VPS providers against our CoolVDS NVMe instances. The difference is not subtle.

Network Latency and Local Compliance

If your users are in Norway, hosting your cluster in Frankfurt adds 20-30ms of latency per round trip. For a microservices architecture where one user request triggers 10 internal service calls, that latency compounds.

Furthermore, with the GDPR enforcement date looming in 2018, data residency is becoming a board-level discussion. Keeping data within Norwegian borders (or at least the EEA) simplifies your compliance posture with Datatilsynet.

Connectivity Check

From a CoolVDS instance in Oslo, ping times to NIX (Norwegian Internet Exchange) are negligible:

root@coolvds-oslo:~# ping -c 4 nix.no
PING nix.no (194.19.96.20) 56(84) bytes of data.
64 bytes from www.nix.no (194.19.96.20): icmp_seq=1 ttl=60 time=0.9 ms
64 bytes from www.nix.no (194.19.96.20): icmp_seq=2 ttl=60 time=0.8 ms
...

The Verdict

If you are a team of three developers managing a Magento store and a few microservices, Kubernetes is over-engineering. The maintenance burden of etcd and the control plane will eat your time. Use Docker Swarm.

If you are building the next Spotify or massive SaaS platform, bite the bullet and learn Kubernetes. But remember: Kubernetes does not fix slow hardware.

Orchestration requires a stable foundation. You need dedicated CPU cycles, guaranteed RAM, and NVMe storage that doesn't choke when you scale up replicas. Don't build your castle on a swamp.

Ready to test your cluster? Spin up three KVM instances on CoolVDS today. With our 10Gbps internal network, your Swarm or Kubernetes nodes talk faster than you can type docker ps.