The Reality of Container Orchestration in late 2021: K8s isn't always the answer

If I see one more startup team of three developers trying to manage a self-hosted Kubernetes cluster on spinning rust, I might just quit the industry and become a sheep farmer in Vestland. It is December 2021, and we have reached peak complexity. Everyone wants Google-scale infrastructure, but nobody wants to admit they don't have Google-scale problems—or Google-scale budgets.

I've spent the last six months migrating a fintech client back away from Kubernetes. Why? Because the operational overhead cost them more than the actual hosting. But for others, K8s is the only path. The choice isn't about features anymore; it's about Operational Expenditure (OpEx) versus Data Sovereignty.

With the dust settling on the Schrems II ruling, hosting your orchestration layer inside Norway (outside the US cloud act's direct reach) is no longer just a "nice to have" for Oslo-based businesses—it is a compliance necessity. Let's look at the three contenders fighting for your `systemd` slots: Kubernetes, Docker Swarm, and HashiCorp Nomad.

The Heavyweight: Kubernetes (K8s) v1.23

Kubernetes has won the container war. That's a fact. But winning the war doesn't mean it's right for your skirmish. K8s is an operating system for the cloud. It abstracts the underlying hardware so completely that you forget it exists—until it breaks.

The Hidden Cost: Etcd Latency

The single biggest killer of K8s clusters I see in the wild isn't bad YAML; it's slow storage. The K8s control plane relies on etcd. Etcd is brutally sensitive to disk write latency. If your `fsync` takes longer than 10ms, your cluster becomes unstable. Leader elections fail. Pods restart randomly.

Pro Tip: Never run a production K8s cluster on standard SSDs or, god forbid, HDD-backed VPS. You need NVMe. Period. On CoolVDS, we specifically tune our KVM instances to pass through NVMe instructions efficiently to prevent I/O wait from killing your control plane.

Here is what happens when you ignore storage requirements. You have to start tuning heartbeat intervals just to keep the cluster alive, which is a band-aid, not a fix:

# etcd.yaml configuration tweak for slow networks/disks (Not recommended, fix your hardware instead)
heartbeat-interval: 250
election-timeout: 2500

If you are deploying K8s in 2021, you are likely using `kubeadm`. Ensure you are enforcing pod security policies (PSP) before they get deprecated in future versions. Here is a standard aggressive check regarding disk pressure often missed in `kubelet` config:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
evictionHard:
  memory.available: "100Mi"
  nodefs.available: "10%"
  nodefs.inodesFree: "5%"
evictionSoft:
  memory.available: "200Mi"
evictionSoftGracePeriod:
  memory.available: "1m"

The Pragmatist: Docker Swarm

"Docker Swarm is dead." I've heard this since 2018. Yet, here we are in 2021, and Swarm is still the fastest way to go from "code on laptop" to "cluster in Oslo."

For teams under 20 people, Swarm is superior. It is built into the Docker engine. There is no extra binary. No massive control plane tax. You sacrifice CRDs (Custom Resource Definitions) and the massive Helm ecosystem, but you gain sanity. The networking model is simpler, and for standard web apps (Nginx + Python/Node + Postgres), it works seamlessly.

Deploying a stack takes seconds. No manifests, just a compose file:

version: "3.8"
services:
  web:
    image: nginx:alpine
    deploy:
      replicas: 2
      update_config:
        parallelism: 2
        delay: 10s
      restart_policy:
        condition: on-failure
    ports:
      - "80:80"
    networks:
      - webnet
networks:
  webnet:

The issue with Swarm is usually ingress. It doesn't handle Layer 7 routing as natively as K8s Ingress Controllers. However, running Traefik as a reverse proxy on Swarm nodes solves 99% of this. If you host on CoolVDS, our internal network latency between nodes is negligible, making the Swarm overlay network performance nearly indistinguishable from host networking.

The Hipster Hybrid: HashiCorp Nomad

Nomad is for the engineers who think Kubernetes is bloated but Swarm is too simple. It's a single binary. It schedules containers, but also Java JARs, raw binaries, and QEMU virtual machines.

In late 2021, Nomad is gaining traction in scenarios where you have mixed workloads. Maybe you have legacy monolithic apps that can't be containerized yet, sitting next to Docker microservices. Nomad handles both. It integrates perfectly with Consul for service discovery and Vault for secrets.

The downside? The ecosystem is smaller. You will be writing your own HCL (HashiCorp Configuration Language) files.

The "Noisy Neighbor" Problem & Hardware Reality

Regardless of which orchestrator you choose, they all assume one thing: Consistent Compute.

Container schedulers operate on the assumption that 1 CPU share equals 1 CPU share. In a public cloud environment with high steal time (where the hypervisor steals cycles for other tenants), your scheduler gets confused. A K8s liveness probe might timeout not because the app is crashed, but because the CPU was stolen for 200ms.

This leads to the "cascading failure" loop:

1. CPU Steal spikes.
2. Liveness probe times out.
3. K8s kills the pod.
4. Pod restarts (consuming high CPU).
5. Neighboring tenants suffer, causing more steal time.

Comparison: The 2021 Landscape

Legal Latency: The Norway Context

We need to talk about Schrems II. The European Data Protection Board (EDPB) has made it clear: relying on standard contractual clauses (SCCs) with US cloud providers is risky business. If your orchestration layer logs IP addresses or personal data to a control plane hosted in a US-owned jurisdiction (even if the server is in Frankfurt), you are in a grey zone.

Running your own cluster on CoolVDS in Norway solves two problems:

1. Compliance: Your data stays on Norwegian soil, under Norwegian law, on infrastructure owned by a European entity.
2. Latency: If your customers are in Oslo, Bergen, or Trondheim, why route traffic through Sweden or Germany? The round-trip time (RTT) from Oslo to a CoolVDS instance is often under 2ms.

Conclusion: Choose Your Weapon

If you need a complex service mesh, auto-scaling based on custom metrics, and have a team of 5+ DevOps engineers, use Kubernetes. But ensure the underlying hardware is robust. Don't cheap out on IOPS.

If you just want to run containers reliably and go home at 5 PM, use Docker Swarm.

If you have a mix of legacy binaries and containers, look at Nomad.

Whatever you choose, the software is only as good as the metal it runs on. Orchestrators add overhead. To counter that, you need raw performance. High-frequency CPUs and NVMe storage aren't luxuries in 2021; they are requirements for a stable cluster.

Ready to build? Don't let CPU steal time kill your pods. Deploy your cluster on CoolVDS High-Performance NVMe instances today and experience the stability of dedicated resources.