You Probably Don't Need High Availability, You Need Reliable Hardware

I've seen startups burn six months of runway trying to configure a multi-region Istio service mesh before they had ten active users. It’s a disease in our industry. We chase the "Netflix architecture" on a WordPress budget. The reality of container orchestration in 2024 isn't about which tool has the most GitHub stars; it's about which tool won't wake you up at 3 AM because etcd timed out due to noisy neighbor I/O latency.

If your servers are located in Oslo but your orchestration layer adds 200ms of overhead because of bad networking overlays, it doesn't matter if you are GDPR compliant. Your app feels broken.

The War Story: When "Managed" Goes Wrong

Last November, I audited a setup for a fintech client in Stavanger. They were running a managed Kubernetes cluster on a major cloud provider. The bill was astronomical, yet their API latency spiked randomly. The culprit? CPU Steal and slow disk I/O.

Their control plane was starving. Kubernetes is aggressive. It demands immediate acknowledgment for writes to its state store. When the underlying storage (standard SSD) choked, the API server stopped responding. We migrated them to raw Linux instances with dedicated resources and local NVMe storage. The result? Latency dropped by 60%, and the bill was cut in half.

The Contenders: Swarm vs. K8s vs. K3s

1. Docker Swarm: The "Good Enough" Hero

Don't let the Reddit threads fool you. Docker Swarm is still alive and kicking in 2024. If you have a team of two developers and need to deploy a stack with five microservices, Swarm is your best friend. It is built into the Docker engine. There is no extra binary to install.

Pro Tip: Swarm's overlay network encryption uses IPSec. On older kernels or weak vCPUs, this tanks performance. Ensure you have AES-NI enabled on your host. On CoolVDS instances, this is passed through directly from the hardware.

2. Kubernetes (K8s): The Standard

If you need strict RBAC, complex autoscaling (HPA/VPA), or CRDs (Custom Resource Definitions), you need K8s. But K8s is resource-hungry. A vanilla install can eat 2GB of RAM just sitting idle.

3. K3s: The Sweet Spot

Rancher's K3s is a certified Kubernetes distribution designed for IoT and Edge, but it runs beautifully on VPS infrastructure. It replaces etcd with SQLite (by default) or can use external DBs, stripping out legacy cloud provider bloat.

Technical Deep Dive: The Storage Bottleneck

Here is where most deployments fail. Kubernetes relies heavily on etcd for state. etcd is sensitive to disk write latency. If fsync takes too long, the cluster becomes unstable.

Check your disk latency right now:

If you see anything above 10ms average, your K8s cluster will be flaky. This is why we insist on NVMe storage at CoolVDS. Spinning rust or network-attached block storage often introduces jitter that kills distributed consensus.

Configuration: Taming the Beast

When deploying on bare Linux (which you should do for performance), you need to tune the kernel. Here is a standard sysctl configuration we apply to high-performance nodes handling heavy container traffic:

# /etc/sysctl.d/99-k8s-networking.conf

# Allow IP forwarding for CNI plugins
net.ipv4.ip_forward = 1

# Increase the connection tracking table size (critical for high pod counts)
net.netfilter.nf_conntrack_max = 131072

# Optimize ARP cache
net.ipv4.neigh.default.gc_thresh1 = 1024
net.ipv4.neigh.default.gc_thresh2 = 2048
net.ipv4.neigh.default.gc_thresh3 = 4096

# Enhance TCP keepalive to detect dead connections faster
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 60
net.ipv4.tcp_keepalive_probes = 3

Apply it with:

Deploying a Resilient Stack

Let's look at a practical example. We want to deploy a high-availability Nginx ingress. In Docker Swarm, it's startlingly simple, but limited. In Kubernetes, we need to be explicit about resource constraints to prevent the "noisy neighbor" effect inside our own cluster.

Kubernetes Deployment Manifest

Notice the resources block. Never deploy without this. If you don't set limits, a memory leak in one pod can crash the OOMKiller and take down your SSH daemon.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: production-ingress
  namespace: ingress-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ingress-nginx
  template:
    metadata:
      labels:
        app: ingress-nginx
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - ingress-nginx
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: controller
        image: registry.k8s.io/ingress-nginx/controller:v1.9.4
        resources:
          requests:
            cpu: 100m
            memory: 90Mi
          limits:
            cpu: 500m
            memory: 512Mi
        livenessProbe:
          httpGet:
            path: /healthz
            port: 10254
            scheme: HTTP
          initialDelaySeconds: 10
          periodSeconds: 10

This configuration forces K8s to spread the pods across different nodes (using podAntiAffinity), ensuring that if one VPS goes down during maintenance, your service stays up.

The Norwegian Context: Latency and Law

For those of us operating in Norway, the implementation of GDPR and the Schrems II ruling means data residency is not optional. Using a US-based cloud provider's "Oslo region" might technically satisfy the law, but the metadata often flows back to US control planes.

Hosting on a Norwegian VPS provider like CoolVDS ensures that your data—and the orchestration metadata—stays within the jurisdiction. Furthermore, latency to NIX (Norwegian Internet Exchange) is critical. If your users are in Oslo and your servers are in Frankfurt, you are adding 20-30ms of round-trip time unnecessarily.

Checking Connectivity

Before you commit to a cluster, verify the network path:

On our network, you should see single-digit latency.

Automating the Setup

Manual server setup is a sin. Here is an Ansible snippet to prepare a fresh CoolVDS instance for Docker or K8s. It secures SSH and installs dependencies.

---
- hosts: k8s_nodes
  become: yes
  tasks:
    - name: Disable Swap (Required for K8s)
      command: swapoff -a

    - name: Remove Swap from fstab
      replace:
        path: /etc/fstab
        regexp: '^([^#].*?\sswap\s+sw\s+.*)$'
        replace: '# \1'

    - name: Install Container Runtime Prerequisites
      apt:
        name:
          - apt-transport-https
          - ca-certificates
          - curl
          - gnupg
        state: present
        update_cache: yes

    - name: Add Docker GPG Key
      apt_key:
        url: https://download.docker.com/linux/debian/gpg
        state: present

    - name: Setup Docker Repository
      apt_repository:
        repo: deb [arch=amd64] https://download.docker.com/linux/debian bookworm stable
        state: present

Why CoolVDS Works for this Architecture

We don't oversell our CPU cores. When you run kubectl apply, the API server needs CPU cycles now, not when the hypervisor decides to give them to you. We use KVM virtualization which provides strict isolation.

If you are building a cluster:

1. Control Plane: Needs fast CPU and fast disk (NVMe).
2. Worker Nodes: Need RAM and network throughput.

CoolVDS offers NVMe storage standard. This effectively eliminates the etcd timeouts that plague cheap VPS providers.

Conclusion

Complexity is the enemy of stability. If you can get away with Docker Compose or Swarm, do it. If you need Kubernetes, ensure your underlying infrastructure can handle the I/O pressure. Don't build a Ferrari engine and put it inside a rusted chassis.

Ready to build a cluster that actually stays up? Deploy a high-performance NVMe instance on CoolVDS today and see the difference raw I/O speed makes to your deployment times.