Plattform und Betriebsgrenzen klären: WZ-IT plant und betreibt Kubernetes auf Proxmox. Beratung umfasst die Aufgabenverteilung zwischen Hypervisor, Cluster und Anwendungen.
Proxmox VE verwaltet virtuelle Maschinen und Linux-Systemcontainer. Kubernetes steuert Container-Workloads über eine eigene API. Der Vergleich betrifft daher unterschiedliche Ebenen: Ein Unternehmen kann Proxmox ohne Kubernetes, Kubernetes ohne Proxmox oder beide gemeinsam einsetzen. Grundlagen: Proxmox-VM-Verwaltung und Kubernetes-Komponenten.
Stand: Oktober 2026. Dieser Artikel ordnet die Entscheidung ein. Die Architekturübersicht behandelt die gemeinsame Plattform; die Installationsanleitung führt durch einen k3s-Aufbau. Eigene Messungen werden hier nicht behauptet.
Inhaltsverzeichnis
- Aufgaben im Vergleich
- Wann welche Plattform passt
- Hochverfügbarkeit hat zwei Ebenen
- Storage und Backup getrennt planen
- Betrieb und Entscheidung
- Quellen
Aufgaben im Vergleich
| Frage | Proxmox VE | Kubernetes |
|---|---|---|
| Was wird verwaltet? | Hosts, KVM-VMs und LXC-Systemcontainer | Pods und deklarierte Anwendungsressourcen |
| Wo läuft das Betriebssystem? | Jede VM besitzt einen eigenen Gastkernel | Anwendungscontainer nutzen den Kernel ihres Nodes |
| Welche Schnittstelle ist zentral? | Proxmox-Weboberfläche und API | Kubernetes-API und deklarative Ressourcen |
| Was wird bei Ausfall ersetzt? | HA kann konfigurierte virtuelle Gäste neu starten | Controller können Workloads auf geeigneten Nodes ersetzen |
| Wer stellt die Infrastruktur bereit? | Proxmox auf vorhandenen Servern und Storage | Physische oder virtuelle Nodes müssen bereitstehen |
Die Tabelle verbindet die dokumentierten VM-Eigenschaften, LXC-Systemcontainer sowie Kubernetes-Komponenten und Container-Isolation. Kubernetes ist keine weitere Bezeichnung für einen Proxmox-Cluster. Auch LXC und ein Pod sind unterschiedliche Betriebsobjekte; der Vergleich Proxmox, Docker und LXC erklärt diese Grenze.
Wann welche Plattform passt
| Ausgangslage | Zu prüfender Weg | Entscheidende Frage |
|---|---|---|
| Windows- und Linux-Server mit getrennten Gastbetriebssystemen | Proxmox als VM-Plattform | Welche Anwendungen und Betriebssysteme müssen unverändert weiterlaufen? |
| Container-Anwendungen mit deklarativem Deployment und mehreren Nodes | Kubernetes auf geeigneter Infrastruktur | Kann das Team Cluster, Add-ons und Anwendungen betreiben? |
| Bestehender Proxmox-Cluster plus Bedarf an Container-Orchestrierung | Kubernetes-Nodes als Proxmox-VMs | Sind physische Ausfalldomänen und Betriebszuständigkeiten geklärt? |
| Wenige Anwendungen ohne Clusterbedarf | VM mit Docker Compose oder Anwendungsplattform prüfen | Rechtfertigt der Bedarf eine zusätzliche Orchestrierungsebene? |
Das sind Entscheidungskriterien, keine universelle Leistungsrangfolge. Kubernetes kann auf physischen oder virtuellen Nodes laufen. Die Kombination ist sinnvoll, wenn VM-Verwaltung und Anwendungsplattform beide benötigt werden. Einen Bedarf an Kubernetes erzeugt die vorhandene Virtualisierung allein nicht. Dazu: Brauchen wir Kubernetes?.
Hochverfügbarkeit hat zwei Ebenen
Proxmox HA betrifft konfigurierte VMs und Container. Kubernetes kontrolliert den gewünschten Anwendungszustand. Ein VM-Neustart und das Ersetzen eines Pods haben unterschiedliche Voraussetzungen; weder Mechanismus garantiert allein die Verfügbarkeit einer Datenbank oder Anwendung.
Bei k3s mit Embedded etcd bilden mindestens drei Server-Nodes die HA-Control-Plane. Die k3s-Dokumentation beschreibt dafür ein Quorum. Für die Planung heißt das: Control-Plane-VMs auf unabhängige Hosts verteilen, deren Platzierung auch nach Wartung prüfen und den API-Endpunkt redundant auslegen. Drei VMs auf demselben Host verlieren bei dessen Ausfall gemeinsam ihre Grundlage. Freie Kapazität, Netze und Storage gehören in denselben Ausfallplan.
Storage und Backup getrennt planen
Proxmox stellt Speicher für virtuelle Gäste bereit. Kubernetes bindet Anwendungsvolumes über Persistent Volumes und Claims ein. Ein vorhandener Proxmox-Datastore wird dadurch nicht automatisch zur Kubernetes-StorageClass. Treiber, Zugriff und Wiederanlauf müssen zum ausgewählten Speichermodell passen.
Für die Sicherung unterscheiden wir VM-Daten, Kubernetes-Zustand und Anwendungsdaten. Bei k3s gehören zum Datastore-Backup auch die Server-Token, die für die Wiederherstellung benötigt werden. Datenbanken und persistente Volumes brauchen zusätzlich geeignete Sicherungen. Der Leitfaden Kubernetes Backup und Restore vertieft die gemeinsame Wiederherstellungsplanung.
Betrieb und Entscheidung
Dokumentieren Sie vor der Auswahl vier Punkte: bestehende VM-Workloads, Anforderungen an Deployments, Verantwortliche für jede Ebene und nachweisbare Wiederherstellungsverfahren. Updates des Hypervisors, der Gastbetriebssysteme, der Distribution und der Add-ons bleiben eigene Aufgaben. Die Kombination fügt eine Verwaltungsebene hinzu; sie hebt diese Aufgaben nicht auf.
Zielarchitektur abstimmen: Kubernetes auf Proxmox umfasst Beratung, Implementierung und den vereinbarten Betrieb. Für den Aufbau führt die k3s-Anleitung durch VMs, Bootstrap und Abnahme.
