Kubernetes auf Proxmox

Souveräne Kubernetes-Plattform auf Proxmox aufbauen? WZ-IT verbindet Proxmox-Cluster, Kubernetes, Netzwerk, Storage, GitOps und Managed Operations zu einer belastbaren Plattform auf eigener oder europäischer Infrastruktur. Kubernetes auf Proxmox als Leistung

Proxmox und Kubernetes ergänzen sich, weil sie unterschiedliche Ebenen verantworten. Proxmox virtualisiert Compute, Netzwerk und Storage. Kubernetes orchestriert darauf Anwendungen und ihre Container. Gemeinsam entsteht eine souveräne Plattform, die weder an einen Hyperscaler noch an proprietäre Virtualisierung gebunden sein muss.

Die Kombination ist jedoch nicht automatisch hochverfügbar. Werden drei Kubernetes-Nodes als VMs auf demselben Proxmox-Host betrieben, besitzt die Anwendung weiterhin einen einzigen physischen Ausfallpunkt. Eine belastbare Architektur muss die beiden Steuerungsebenen, ihre Failure Domains und ihre Wiederanlaufmechanismen gemeinsam betrachten.

Inhaltsverzeichnis

• Die Aufgabenverteilung
• KVM-VM oder LXC
• Eine belastbare Referenzarchitektur
• Hochverfügbarkeit auf zwei Ebenen
• Netzwerk: vom physischen Uplink bis zum Service
• Storage ohne doppelte Komplexität
• Backup und Disaster Recovery
• Automatisierter Aufbau
• Updates und laufender Betrieb
• Wann Proxmox plus Kubernetes passt

Die Aufgabenverteilung

Eine klare Trennung verhindert, dass dieselbe Funktion auf beiden Ebenen ungeplant doppelt umgesetzt wird.

Proxmox sieht eine Worker-VM, aber nicht die fachliche Bedeutung ihrer Pods. Kubernetes sieht Nodes und Storage-Klassen, aber nicht automatisch, ob zwei VMs auf demselben physischen Server liegen. Die Zielarchitektur muss diese Informationen verbinden.

KVM-VM oder LXC

Proxmox kann vollständige KVM-VMs und Linux-Systemcontainer über LXC betreiben. Kubernetes-Nodes lassen sich technisch in beiden Modellen aufbauen. Für produktive Cluster ist unsere Architektur-Empfehlung dennoch eindeutig: Kubernetes-Nodes als KVM-VMs.

Warum VMs die robuste Standardwahl sind

• Jeder Node besitzt einen eigenen Kernel und eine klare Systemgrenze.
• Kernelmodule, cgroups, iptables/nftables, eBPF und CNI-Funktionen lassen sich unabhängig vom Hypervisor konfigurieren.
• Betriebssystem- und Kubernetes-Upgrades sind besser vom Proxmox-Host entkoppelt.
• Snapshots, Templates, Cloud-Init und VM-Migration sind etablierte Proxmox-Funktionen.
• Sicherheits- und Fehlergrenzen sind leichter nachvollziehbar.

Warum LXC anspruchsvoller ist

Ein Kubernetes-Node in LXC teilt sich den Kernel mit dem Proxmox-Host. Verschachtelte Container, benötigte Kernelmodule, cgroups, AppArmor und Netzwerkfunktionen erfordern oft erweiterte Containerrechte oder spezielle Hostkonfiguration. Das kann in Labor- oder ressourcenoptimierten Umgebungen sinnvoll sein, erhöht aber Kopplung und Fehlersuchaufwand.

Das ist eine WZ-IT-Architekturempfehlung, keine technische Behauptung, dass Kubernetes in LXC grundsätzlich unmöglich wäre.

Eine belastbare Referenzarchitektur

Eine typische, hochverfügbare Ausgangsarchitektur kann so aussehen:

Proxmox-Node A        Proxmox-Node B        Proxmox-Node C
├─ Control Plane 1    ├─ Control Plane 2    ├─ Control Plane 3
├─ Worker 1           ├─ Worker 2           ├─ Worker 3
└─ Infrastruktur-VMs  └─ Infrastruktur-VMs  └─ Backup/Tools
          │                    │                    │
          └──── VLANs / Storage / Cluster-Netze ───┘

Die drei Control-Plane-VMs liegen auf unterschiedlichen physischen Hosts. Worker werden ebenfalls verteilt. Ein Load-Balancer oder virtueller Endpunkt stellt die Kubernetes-API bereit. Platzierungs- beziehungsweise Anti-Affinity-Regeln auf Proxmox-Ebene verhindern, dass kritische VMs unbeabsichtigt auf demselben Host landen.

Das ist keine universelle Mindestarchitektur. Ein Edge-System, ein Entwicklungscluster oder ein GPU-Cluster kann anders aussehen. Die offizielle Kubernetes-Dokumentation zu Produktionsumgebungen verlangt nicht ein bestimmtes Herstellerdesign, macht aber die Bedeutung einer replizierten Control Plane, eines lastverteilten API-Endpunkts und ausreichender Worker-Kapazität deutlich.

Physische Failure Domains zuerst

Vor der VM-Größe stehen die realen Ausfallgrenzen:

• separate physische Proxmox-Nodes,
• nach Möglichkeit unabhängige Strom- und Netzwerkpfade,
• redundante Switches und Bonds entsprechend dem Verfügbarkeitsziel,
• Storage ohne einzelnen Controller oder einzelnen Server als kritischen Punkt,
• genug freie Kapazität, um den Ausfall eines Hosts aufzunehmen.

Ein Cluster kann nur gegen Ausfälle schützen, die seine Architektur tatsächlich trennt.

Hochverfügbarkeit auf zwei Ebenen

Proxmox HA und Kubernetes-Selbstheilung sind keine direkten Konkurrenten.

Kubernetes reagiert auf Workload- und Node-Ebene

Fällt ein Pod aus, ersetzt ihn der zuständige Controller. Ist ein Worker länger nicht verfügbar, können geeignete Workloads auf anderen Workern neu eingeplant werden. Voraussetzung sind freie Ressourcen, erreichbarer Storage und eine Anwendung, die mehrere Instanzen oder einen Neustart verträgt.

Proxmox HA reagiert auf VM-Ebene

Die Proxmox-HA-Funktion kann eine betroffene VM nach einem physischen Hostausfall auf einem verbleibenden Node neu starten, wenn Storage und Quorum verfügbar sind. Das kann einen Kubernetes-Node oder weitere Infrastrukturkomponenten zurückbringen.

Gemeinsam planen

Für austauschbare Worker kann Kubernetes die Workloads zunächst anderweitig verteilen; ein späterer VM-Neustart stellt Kapazität wieder her. Bei Control-Plane-VMs sorgt deren eigene Replikation dafür, dass die API währenddessen verfügbar bleibt. Unkoordinierte HA auf beiden Ebenen kann jedoch zu unnötigen Bewegungen führen. Deshalb werden Timeouts, Kapazitätsreserve, Placement und Wartungsprozesse zusammen dokumentiert.

Netzwerk: vom physischen Uplink bis zum Service

Das Netzwerk besitzt mehrere Schichten, deren Adressbereiche sich nicht überschneiden dürfen:

1. Physische und Proxmox-Ebene: Uplinks, Bonds, Linux Bridges oder Open vSwitch, VLANs und Proxmox Firewall.
2. Node-Netz: IP-Adressen der Control Plane und Worker, API-Endpunkt und gegebenenfalls Storage-Netz.
3. Pod-Netz: durch das CNI-Plugin bereitgestellte Adressen und Routing.
4. Service-Netz: virtuelle ClusterIP-Bereiche für Kubernetes Services.
5. North-South-Zugriff: LoadBalancer, Ingress oder Gateway API für Anwendungsverkehr.
6. Management-Zugriff: privater Zugang zu API, GitOps, Monitoring und internen Diensten.

Für On-Prem- und Proxmox-Umgebungen stellt ein Projekt wie MetalLB LoadBalancer-Adressen über Layer 2 oder BGP bereit. Alternativ können externe Load Balancer oder Provider-Netzwerkfunktionen verwendet werden. Welche Variante passt, hängt von Netzhoheit, Routing, Redundanz und gewünschter Automatisierung ab.

Die Kubernetes-API und interne Admin-Dienste müssen nicht öffentlich exponiert sein. Der Leitfaden Kubernetes privat über NetBird erreichen zeigt den identitätsbasierten Zugang über ein WireGuard-Overlay.

Storage ohne doppelte Komplexität

Proxmox unterstützt laut Administrationshandbuch unter anderem ZFS, Ceph RBD/CephFS, LVM, NFS und iSCSI. Kubernetes konsumiert persistenten Speicher über CSI-Treiber, StorageClasses und PersistentVolumeClaims. Daraus ergeben sich mehrere Architekturmodelle.

Modell A: zentraler Ceph-Cluster, direkt per CSI

Ein vorhandener Ceph-Cluster kann Block- oder Dateispeicher direkt an Kubernetes bereitstellen. Der CSI-Treiber erstellt und bindet Volumes, während Ceph Replikation und Verteilung übernimmt. Die Berechtigungs- und Netzwerkgrenzen zwischen Proxmox und Kubernetes müssen dabei sauber getrennt werden.

Modell B: virtuelle Disks auf Proxmox-Storage

Worker-VMs erhalten virtuelle Disks auf ZFS, Ceph oder SAN. Anwendungen nutzen lokale Volumes oder eine darauf aufbauende Storage-Lösung. Das ist einfach zu verstehen, kann aber Replikation auf mehreren Ebenen stapeln. Beispiel: Ein Kubernetes-Storage-System repliziert dreifach, während jede virtuelle Disk bereits dreifach in Ceph repliziert wird. Das erhöht Kapazitätsbedarf und Schreibpfad ohne automatisch dreifach mehr Sicherheit zu schaffen.

Modell C: externer Storage

Ein separates NFS-, Ceph-, SAN- oder Cloud-Storage-System wird über einen geeigneten CSI-Treiber angebunden. Das trennt Lifecycle und Ressourcen von der Proxmox-Plattform, schafft aber eine weitere Infrastrukturdomäne.

Modell D: lokaler Storage mit anwendungseigener Replikation

Datenbanken oder verteilte Systeme können lokale, performante Volumes verwenden und Replikation selbst übernehmen. Dafür müssen Pod-Platzierung, Node-Ausfall, Wiederaufbau und Backup exakt zur Anwendung passen.

Es gibt keine pauschal beste Variante. Entscheidend sind Latenz, IOPS, Datenmenge, Ausfallziel, Restore-Zeit und wer die Storage-Ebene betreiben kann.

Backup und Disaster Recovery

Für Kubernetes auf Proxmox unterscheiden wir drei Sicherungsebenen:

1. Infrastruktur und VMs

Proxmox Backup Server kann VM-Disks inkrementell und dedupliziert sichern. Das erleichtert den Wiederanlauf vollständiger Nodes und Infrastruktur-VMs. Ein VM-Snapshot allein garantiert jedoch keine anwendungskonsistente Sicherung verteilter Datenbanken.

2. Clusterzustand

etcd braucht geplante Snapshots, getrennte Aufbewahrung und einen getesteten Restore. Kubernetes- und Plattformdefinitionen gehören zusätzlich versioniert in Git, inklusive dokumentierter Bootstrap-Reihenfolge.

3. Anwendungsdaten

Datenbanken, Object Storage und Volumes benötigen anwendungsspezifische Backups. RPO, RTO, Aufbewahrung, Verschlüsselung und Offsite-Kopie werden fachlich festgelegt. Ein Tool wie Velero kann Ressourcen und unterstützte Volumes sichern, ersetzt aber nicht automatisch native Datenbank-Backups.

Der Restore-Test muss zeigen, ob aus Infrastruktur, Clusterzustand und Daten tatsächlich wieder ein funktionsfähiges System entsteht.

Automatisierter Aufbau

Ein reproduzierbarer Aufbau kann folgende Kette verwenden:

1. Proxmox-Cluster und Storage als dokumentierte Basis.
2. VM-Templates mit Cloud-Init.
3. Terraform oder OpenTofu zur Erstellung und Platzierung der Node-VMs.
4. Ansible oder eine Clusterdistribution für Betriebssystem- und Kubernetes-Bootstrap.
5. GitOps, etwa Argo CD oder Flux, für CNI, Ingress/Gateway, Zertifikate, Observability und Workloads.
6. Secret- und Identitätsintegration getrennt von Klartext-Repositories.

Automatisierung ist nicht nur Komfort. Sie macht Ersatz, Testcluster, Upgrades und Disaster Recovery nachvollziehbar. Manuell konfigurierte Abweichungen zwischen Nodes werden reduziert.

Updates und laufender Betrieb

Die Plattform besitzt zwei unabhängige, aber koordinierte Lebenszyklen:

• Proxmox, Kernel, Ceph und physische Firmware,
• Gastbetriebssysteme und Kubernetes-Nodes,
• Kubernetes-Control-Plane und Worker-Versionen,
• CNI, CSI, Ingress/Gateway und weitere Add-ons,
• Anwendungen und deren Datenmigrationen.

Wartung wird rollierend geplant: Kapazität prüfen, Workloads kontrolliert evakuieren, Node oder Hypervisor aktualisieren, Health und Storage verifizieren und erst dann fortfahren. Kubernetes unterstützt Version Skew Policies, aber sie ersetzen keinen Upgradeplan.

Monitoring muss beide Ebenen korrelieren. Ein Kubernetes-Alarm „Node NotReady“ reicht nicht, wenn die Ursache im Proxmox-Host, Ceph oder physischen Netzwerk liegt. Umgekehrt sagt ein gesunder VM-Status noch nichts über Pods und Anwendungen aus.

Wann Proxmox plus Kubernetes passt

Die Kombination ist besonders stark, wenn:

• Datenhoheit und europäische oder eigene Infrastruktur wichtig sind,
• bereits ein belastbarer Proxmox-Cluster vorhanden ist,
• mehrere Anwendungen eine gemeinsame Delivery- und Betriebsplattform benötigen,
• VMware ersetzt und gleichzeitig die Anwendungsebene modernisiert werden soll,
• Bare-Metal-Ressourcen, GPUs oder spezielle Netzwerke kontrolliert bereitgestellt werden müssen,
• ein Partner Infrastruktur und Kubernetes Ende zu Ende verantwortet.

Für wenige einfache Anwendungen kann Proxmox mit separaten VMs, LXC, Compose oder Coolify die wirtschaftlichere Architektur sein. Unsere Entscheidungshilfe trennt diese Fälle.

Fazit

Proxmox bildet das souveräne Infrastruktur-Fundament, Kubernetes die standardisierte Anwendungsebene. Eine belastbare Umsetzung verbindet beide, ohne ihre Aufgaben zu vermischen: physische Failure Domains, VM-Platzierung, Pod-Orchestrierung, Netzwerk, Storage, Backup und Updates werden als zusammenhängendes System geplant.

So entsteht mehr als „Kubernetes in drei VMs“: eine reproduzierbare Plattform, die Anwendungen migrieren, modernisieren und langfristig betreiben kann.

Quellen

• Proxmox VE Administration Guide
• Proxmox VE: High Availability Manager
• Proxmox VE: Storage
• Kubernetes-Dokumentation: Produktionsumgebungen
• Kubernetes-Dokumentation: Storage
• Kubernetes: Version Skew Policy
• MetalLB: Konzepte