Warum Kubernetes auf einem VPS statt lokal oder in der Cloud?

Wer Kubernetes lernen möchte, hat grundsätzlich drei Optionen: Minikube oder kind auf dem lokalen Laptop, managed Angebote wie Google GKE, AWS EKS oder Azure AKS, sowie selbst verwaltete Cluster auf klassischen VPS-Instanzen. Die lokale Variante eignet sich hervorragend, um YAML-Files zu schreiben, ersetzt aber kein echtes Multi-Node-Setup. Managed Services kosten in der kleinsten Konfiguration zwischen 65 € und 140 € pro Monat – das ist für Hobby-Entwickler und Lernende meist zu teuer. Ein selbst betriebener VPS-Cluster mit drei Nodes liegt bei vergleichbarer Leistung zwischen 18 € und 45 € monatlich und bietet volle Root-Rechte, was für Lernzwecke unschlagbar ist.

Ein weiterer Vorteil: Du lernst die Komponenten wirklich kennen. Bei managed Kubernetes bekommst du ein funktionierendes Cluster, verstehst aber nicht, wie die Control Plane aufgebaut ist, wie ein Upgrade abläuft oder was passiert, wenn ein Node ausfällt. Gerade diese Themen sind im Berufsalltag eines DevOps-Engineers gefragt. Wer versteht, warum ein kubelet mit der API-Server-Komponente spricht oder wie etcd die Cluster-State speichert, kann später auch größere Cluster effizient betreiben oder troubleshooten.

Zudem lässt sich ein VPS-Cluster flexibel skalieren. Du startest mit einer kleinen Single-Master-Architektur, ergänzt später Worker-Nodes oder hängst einen Loadbalancer für mehrere Control Planes an. Viele Anbieter erlauben das Hoch- oder Runterskalieren im laufenden Betrieb, sodass du nicht jedes Mal neu provisionieren musst. Für 2026 empfehlen wir den Start mit einem 1-CPU-Master und zwei 2-CPU-Workern – eine Konfiguration, die für die meisten Lern- und Testzwecke ausreicht.

Hardware-Anforderungen und empfohlene Provider 2026

Die offiziellen Kubernetes-Mindestanforderungen sind mit 2 GB RAM pro Node sehr knapp kalkuliert. In der Praxis benötigst du für ein flüssig laufendes Cluster mindestens 2 vCPUs und 4 GB RAM pro Node. Der Control-Plane-Node sollte sogar mit 4 GB RAM ausgestattet sein, da dort neben kubelet auch die API-Server-Komponente, etcd, scheduler und controller-manager laufen. Für Storage-intensive Workloads oder CI/CD-Pipelines empfehlen wir 8 GB RAM pro Node. Als Storage reichen 40 GB NVMe für den Anfang, plane aber mindestens 80 GB ein, wenn du Container-Images lokal cachen möchtest.

Bei der Wahl des VPS-Providers spielen Standort, Netzwerkperformance und Preis-Leistungs-Verhältnis eine entscheidende Rolle. Deutsche Anbieter punkten mit DSGVO-Konformität und niedrigen Latenzen innerhalb Europas, während US-Anbieter oft günstigere Stundentarife bieten. Achte darauf, dass der Anbieter private Netzwerke (Private Network) und idealerweise Floating-IPs oder Loadbalancer unterstützt – beides ist für ein produktionsnahes Cluster-Setup nahezu Pflicht.

Die folgende Tabelle vergleicht die gängigsten Anbieter für ein typisches 3-Node-Cluster (1× Control Plane, 2× Worker) im März 2026:

AnbieterPlan (Master)Plan (Worker)Monatspreis 3er-ClusterStandort DEPrivates Netz
Hetzner CloudCX22 (2 vCPU, 4 GB)CX22 (2 vCPU, 4 GB)ca. 18,90 €Falkenstein, Nürnbergja, kostenlos
NetcupVPS 1000 G10 (4 vCPU, 8 GB)VPS 1000 G10ca. 27,00 €Wien, Nürnbergja, kostenlos
IONOSVPS XS (1 vCPU, 4 GB)VPS S (2 vCPU, 8 GB)ca. 24,00 €Karlsruheja, 0,50 €/Monat
ContaboVPS S SSD (4 vCPU, 8 GB)VPS S SSDca. 19,99 €Nürnbergja, kostenlos
DigitalOceanDroplet 4 GBDroplet 4 GBca. 36,00 €Frankfurtja, kostenlos

Hetzner bietet aktuell das beste Preis-Leistungs-Verhältnis für einsteigerfreundliche Cluster-Setups, dicht gefolgt von Contabo. Wenn du Wert auf höchste Stabilität und exzellenten Support legst, sind Netcup und DigitalOcean empfehlenswert.

Betriebssystem vorbereiten und Grundkonfiguration

Bevor du mit der Installation beginnst, solltest du auf allen drei VPS-Instanzen ein einheitliches Betriebssystem einsetzen. Wir empfehlen Ubuntu 24.04 LTS, da Canonical bis 2029 Sicherheitsupdates liefert und die Pakete für containerd sowie kubeadm ohne weitere Repository-Anpassungen verfügbar sind. Alternativ funktioniert Debian 12 (Bookworm) identisch, RHEL 9 oder Rocky Linux 9 sind ebenfalls möglich, erfordern aber andere Paketnamen.

Nach dem ersten Login per SSH solltest du folgende Schritte auf allen Nodes ausführen: einen eigenen User mit sudo-Rechten anlegen, die Firewall aktivieren, die Kernel-Module br_netfilter und overlay laden sowie die Swap-Partition deaktivieren. Kubernetes benötigt Swap deaktiviert, weil der Scheduler sonst nicht korrekt mit dem Memory-Management zusammenarbeitet. Auch das iptables-Setup muss angepasst werden, damit die Container-Netzwerk-Bridges korrekt durchgereicht werden.

# System aktualisieren
sudo apt update && sudo apt upgrade -y

# Swap dauerhaft deaktivieren
sudo swapoff -a
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

# Kernel-Module laden
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
br_netfilter
EOF

cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
EOF

sudo sysctl --system

# Hostnamen setzen (auf jedem Node unterschiedlich)
sudo hostnamectl set-hostname k8s-master
sudo hostnamectl set-hostname k8s-worker1
sudo hostnamectl set-hostname k8s-worker2

# /etc/hosts ergänzen
echo "10.0.0.10 k8s-master" | sudo tee -a /etc/hosts
echo "10.0.0.11 k8s-worker1" | sudo tee -a /etc/hosts
echo "10.0.0.12 k8s-worker2" | sudo tee -a /etc/hosts

Die IP-Adressen 10.0.0.10 bis 10.0.0.12 sind Platzhalter für dein privates Netzwerk, das du im Provider-Panel konfigurierst. Hetzner, Netcup und Contabo bieten dafür ein eigenes privates Subnetz, das zwischen den Instanzen kostenlos nutzbar ist. Der Datenverkehr bleibt so im internen Netz und ist nicht öffentlich erreichbar.

Container-Runtime containerd installieren

Seit Kubernetes 1.24 ist Docker als Runtime offiziell deprecated, containerd ist der Standard. containerd ist ein Industriestandard-Runtime, der die Container-Images nach OCI-Spezifikation startet und deutlich schlanker als Docker ist. Die Installation erfolgt über die offiziellen Docker-Repositories, da diese stabile Pakete für Ubuntu und Debian bereitstellen.

Bei der Erstinstallation benötigst du zusätzlich das Paket apt-transport-https, ca-certificates und curl. Anschließend fügst du den GPG-Schlüssel und das Repository hinzu, installierst containerd und passt die Konfiguration an. Wichtig ist, dass das SystemdCgroup-Feature aktiviert wird, da kubelet sonst Probleme beim Ressourcen-Accounting meldet.

# Voraussetzungen installieren
sudo apt install -y apt-transport-https ca-certificates curl gnupg

# Docker-Repository hinzufügen
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# containerd installieren
sudo apt update
sudo apt install -y containerd.io

# Standard-Konfiguration generieren und anpassen
sudo containerd config default | sudo tee /etc/containerd/config.toml
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml

# containerd neustarten
sudo systemctl restart containerd
sudo systemctl enable containerd

Prüfe abschließend mit sudo systemctl status containerd, ob der Dienst aktiv läuft. containerd sollte den Status active (running) anzeigen. Mit sudo ctr version kannst du die installierte Version verifizieren – für Kubernetes 1.32 ist containerd 1.7.x oder höher empfohlen.

Kubernetes-Komponenten kubeadm, kubelet und kubectl installieren

Die Kubernetes-Toolchain besteht aus drei Programmen: kubeadm initialisiert den Cluster und joint neue Nodes, kubelet ist der Node-Agent, der mit der API-Server spricht und Pods startet, und kubectl ist das CLI-Werkzeug für die Interaktion mit dem Cluster. Alle drei Komponenten stammen aus dem offiziellen Kubernetes-Repository pkgs.k8s.io, das seit 2024 die alte apt.kubernetes.io-Domain ersetzt hat.

Die Installation läuft auf Master- und Worker-Nodes identisch ab. Du fügst das Repository hinzu, installierst die Pakete und aktivierst den kubelet-Dienst. Der Dienst startet allerdings erst, wenn kubeadm den Node initialisiert hat – das ist normales Verhalten und kein Fehler.

# Kubernetes-Repository hinzufügen
sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl gpg

curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.32/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.32/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list

sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

# IPtables für bridged Traffic konfigurieren
sudo modprobe br_netfilter

Mit apt-mark hold verhinderst du automatische Updates, die das Cluster in einen inkonsistenten Zustand bringen könnten. Kubernetes-Updates werden gezielt mit sudo kubeadm upgrade durchgeführt – ein automatisches apt upgrade würde sonst die Versionsstände auf Master und Workern auseinanderlaufen lassen.

Control Plane initialisieren und Cluster hochfahren

Auf dem Master-Node startest du die Initialisierung mit kubeadm init. Wichtig sind drei Parameter: die Pod-Network-CIDR (muss später mit dem CNI-Plugin übereinstimmen), die API-Server-Adresse und die Wahl des Service-Netzes. Wir verwenden das Standard-CIDR 10.244.0.0/16, das mit Flannel und Cilium kompatibel ist. Für ein produktionsnahes Setup solltest du außerdem die --control-plane-endpoint-Option setzen, falls du später mehrere Master-Nodes ergänzen möchtest.

# Auf dem Master-Node ausführen
sudo kubeadm init \
  --pod-network-cidr=10.244.0.0/16 \
  --control-plane-endpoint=k8s-master:6443 \
  --upload-certs

# Konfiguration für den User einrichten
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

# Join-Befehl für Worker-Nodes erzeugen (24 Stunden gültig)
kubeadm token create --print-join-command

Die Initialisierung dauert je nach VPS-Leistung zwischen 30 und 90 Sekunden. Am Ende gibt kubeadm einen Join-Befehl aus, der in etwa so aussieht: kubeadm join k8s-master:6443 --token abcdef.0123456789abcdef --discovery-token-ca-cert-hash sha256:.... Notiere dir diesen Befehl oder lasse das Terminal offen, denn du benötigst ihn gleich für die Worker-Nodes.

Beachte, dass kubeadm die Standard-CNI-Plugins nicht automatisch installiert. Ohne CNI-Plugin bleiben die Nodes im Status NotReady und keine Pods können gestartet werden. Diesen Schritt behandeln wir im nächsten Abschnitt.

CNI-Netzwerk-Plugin installieren: Flannel vs. Cilium

Das CNI-Plugin (Container Network Interface) ist für die Pod-zu-Pod-Kommunikation verantwortlich. Ohne dieses Plugin kannst du keine Workloads deployen. Die zwei populärsten Optionen für Einsteiger sind Flannel und Cilium. Flannel ist einfach zu installieren und ressourcenschonend, Cilium bietet dafür eBPF-basierte Performance und integrierte Netzwerk-Policies.

EigenschaftFlannel v0.26Cilium 1.16
Installationsehr einfach, ein YAML-Filemittel, CLI-Tool empfohlen
RAM-Verbrauch~30 MB pro Node~250 MB pro Node
Performancegut für Testshervorragend, eBPF
Netzwerk-Policiesnur via NetworkPolicy-Addonintegriert, L3-L7
EmpfehlungEinsteiger, kleine ClusterProduktion, Lernprojekte

Für deinen ersten Cluster empfehlen wir Flannel, da die Installation mit einem einzigen kubectl-Befehl erledigt ist:

# Flannel installieren (auf dem Master-Node)
kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

# Status prüfen
kubectl get pods -n kube-flannel
kubectl get nodes

Nach 30 bis 60 Sekunden sollte der Master-Node den Status Ready zeigen. Mit Cilium verläuft die Installation etwas aufwändiger, dafür bekommst du eBPF-Dataplane, Hubble für Netzwerk-Visualisierung und native NetworkPolicies. Für produktionsnahe Tests ist Cilium langfristig die bessere Wahl.

Worker-Nodes dem Cluster hinzufügen

Nachdem die Control Plane läuft und das CNI-Plugin installiert ist, joinst du die Worker-Nodes. Wechsle per SSH auf k8s-worker1 und führe den Join-Befehl aus, den du zuvor von kubeadm erhalten hast. Alternativ kannst du jederzeit mit kubeadm token create --print-join-command einen neuen Befehl erzeugen, falls der ursprüngliche Token abgelaufen ist. Tokens sind standardmäßig 24 Stunden gültig.

# Auf Worker1 und Worker2 ausführen
sudo kubeadm join k8s-master:6443 \
  --token abcdef.0123456789abcdef \
  --discovery-token-ca-cert-hash sha256:1234567890abcdef...

# Status auf dem Master prüfen
kubectl get nodes

Die Ausgabe sollte in etwa so aussehen:

NAME           STATUS   ROLES           AGE   VERSION
k8s-master     Ready    control-plane   5m    v1.32.0
k8s-worker1    Ready    <none>          1m    v1.32.0
k8s-worker2    Ready    <none>          1m    v1.32.0

Falls ein Worker im Status NotReady bleibt, prüfe mit kubectl describe node k8s-worker1 die Events. Häufige Ursachen sind eine fehlende Firewall-Regel, falsche Routen im privaten Netzwerk oder ein deaktiviertes br_netfilter-Modul. Auch der Wechsel zwischen privater und öffentlicher IP als Join-Endpoint führt oft zu Verwirrung – stelle sicher, dass Master und Worker über das private Netzwerk miteinander sprechen.

Erste Workload deployen und Cluster testen

Nachdem alle Nodes Ready sind, testest du das Cluster am besten mit einem simplen Nginx-Deployment. Das folgende Manifest erzeugt einen Deployment mit drei Replicas und einen Service vom Typ NodePort, der den Port 30080 auf den Nodes veröffentlicht:

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-test
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.27
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
  - port: 80
      targetPort: 80
      nodePort: 30080
EOF

# Status prüfen
kubectl get pods -o wide
kubectl get svc

Anschließend kannst du im Browser http://<öffentliche-IP-des-Workers>:30080 aufrufen und solltest die Nginx-Default-Seite sehen. Wenn du über jeden der drei Worker auf die Seite kommst, hast du ein vollständig funktionsfähiges Kubernetes-Cluster aufgesetzt – inklusive Service-Loadbalancing und Rolling Updates.

Ein zweiter wichtiger Test ist die Skalierung: kubectl scale deployment nginx-test --replicas=10 verteilt die Pods automatisch auf die verfügbaren Worker-Nodes. Beobachte mit kubectl get pods -w, wie neue Pods in Sekundenschnelle erzeugt und auf den Nodes platziert werden. Das ist der Moment, in dem viele Einsteiger die wahre Stärke von Kubernetes begreifen.

Wichtige kubectl-Befehle für den Alltag

Mit den folgenden Befehlen bist du für 90 % der alltäglichen Aufgaben gerüstet. Drucke dir diese Liste am besten aus oder lege sie als Alias-Datei ab:

# Allgemeine Informationen
kubectl get nodes -o wide
kubectl get pods -A
kubectl get svc -A
kubectl cluster-info

# Details und Debugging
kubectl describe pod <pod-name>
kubectl logs <pod-name>
kubectl logs -f <pod-name>            # follow-Modus
kubectl exec -it <pod-name> -- bash   # Container betreten

# Ressourcen anwenden oder löschen
kubectl apply -f datei.yaml
kubectl delete -f datei.yaml
kubectl delete pod <pod-name>

# Skalierung und Updates
kubectl scale deployment nginx-test --replicas=5
kubectl set image deployment/nginx-test nginx=nginx:1.27.1
kubectl rollout status deployment/nginx-test
kubectl rollout undo deployment/nginx-test

# Konfiguration
kubectl config get-contexts
kubectl config use-context <context-name>

Ein hilfreicher Trick ist das Anlegen von Aliases in der ~/.bashrc:

alias k='kubectl'
alias kg='kubectl get'
alias kd='kubectl describe'
alias kl='kubectl logs'
alias kex='kubectl exec -it'
complete -F __start_kubectl k

Mit diesen Aliases sparst du dir pro Tag bis zu 200 Tastenanschläge und arbeitest deutlich flüssiger. Zusätzlich empfehlen wir die Tools k9s (Terminal-UI), Lens (Desktop-UI) und stern (Multi-Pod-Logs) – alle drei sind Open Source und erleichtern den Einstieg erheblich.

Wartung, Updates und Backup-Strategie

Ein produktionsnahes Cluster lebt von regelmäßiger Wartung. Kubernetes veröffentlicht alle vier Monate eine neue Minor-Version, Sicherheitspatches erscheinen regelmäßig. Mit dem Kommando sudo kubeadm upgrade plan erhältst du eine Übersicht der verfügbaren Updates und kannst das Upgrade gezielt durchführen. Wichtig: Aktualisiere immer zuerst den Master, dann die Worker – niemals umgekehrt.

Für das Backup ist vor allem etcd entscheidend, da dort der komplette Cluster-Zustand liegt. Mit sudo ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db erzeugst du in unter zehn Sekunden ein vollständiges Backup. Bewahre die Snapshots idealerweise extern auf (S3, Hetzner Storage Box, rsync auf einen Backup-Server), denn ein VPS-Ausfall würde sonst auch dein Backup verlieren. Für den Restore nutzt du etcdctl snapshot restore und passt die Pfade in /etc/kubernetes/manifests/etcd.yaml an.

Plan außerdem wöchentlich kubectl drain für Nodes ein, die du neu starten möchtest, sowie monatliche Security-Updates mit sudo apt update && sudo apt upgrade. Beim Upgrade der Kubernetes-Version halte dich an die offizielle kubeadm-Anleitung – ein Sprung über mehrere Minor-Versionen wird offiziell nicht unterstützt. Wenn du diese Routine etablierst, läuft dein VPS-Cluster genauso stabil wie ein managed Service, nur zu einem Bruchteil der Kosten.

Mit diesem Setup hast du ein vollständiges Kubernetes-Cluster aufgebaut, das du für Lernzwecke, Home-Lab-Experimente oder kleinere Produktionsworkloads nutzen kannst. Die monatlichen Kosten zwischen 18 € und 45 € sind überschaubar, die gewonnene Praxiserfahrung mit kubeadm, containerd und kubectl ist im DevOps-Arbeitsmarkt sehr gefragt. Wenn du tiefer einsteigen möchtest, beschäftige dich als Nächstes mit Helm für Paketmanagement, Ingress-NGINX oder Traefik für HTTP-Routing und cert-manager für TLS-Zertifikate. Diese drei Tools bilden die Grundlage für produktionsreife Kubernetes-Deployments und sind in den meisten Stellenbeschreibungen für Cloud-Engineers zu finden.