Kubernetes auf Proxmox: k3s, Talos und produktive HA

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.

Bevor die erste VM entsteht, prägen zwei Entscheidungen den Cluster: die Kubernetes-Distribution (k3s, Talos Linux, RKE2 oder kubeadm) und die Aufteilung der Failure Domains über physische Hosts. Dieser Leitfaden behandelt beides. 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.

Macht Kubernetes auf Proxmox Sinn? Wann es passt und wann nicht

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.

Für die Bestandsaufnahme Ihrer Umgebung: Kubernetes auf Proxmox planen.

Inhaltsverzeichnis

• Proxmox und Kubernetes: Wer übernimmt welche Aufgabe?
• Kubernetes auf Proxmox: VM oder LXC?
• Welche Kubernetes-Distribution auf Proxmox: k3s, Talos Linux, RKE2, kubeadm
• Die Proxmox-Seite: Templates, Talos-Images, CSI und CCM
• 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
• Macht Kubernetes auf Proxmox Sinn? Wann es passt und wann nicht

Proxmox und Kubernetes: Wer übernimmt welche Aufgabe?

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.

Kubernetes auf Proxmox: 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

Weiterlesen: LXC und KVM im Vergleich.

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.

Welche Kubernetes-Distribution auf Proxmox: k3s, Talos Linux, RKE2, kubeadm

Proxmox schreibt keine Kubernetes-Distribution vor. Alle gängigen Varianten laufen in KVM-VMs. Die Unterschiede liegen im Betriebssystemmodell, im Weg zur hochverfügbaren Control Plane und im Upgradeverfahren. Stand Oktober 2026 ist Kubernetes 1.37 (1.37.1) das aktuelle Upstream-Minor-Release; k3s und RKE2 liefern es als v1.37.1+k3s1 und v1.37.1+rke2r1 aus, Talos Linux v1.14.4 enthält Kubernetes 1.37.1.

k3s beschreibt sich als leichtgewichtiges Kubernetes in einem Binary unter 100 MB und bringt Flannel, CoreDNS, Traefik, ServiceLB und den Local-Path-Provisioner mit. Standard-Datastore ist SQLite. Ein hochverfügbarer Cluster braucht drei oder mehr Server-Nodes mit Embedded etcd, in ungerader Anzahl, damit etcd sein Quorum hält. Automatisierte Upgrades laufen über den System Upgrade Controller, wobei Server-Nodes vor den Agents aktualisiert werden.

Talos Linux ersetzt das klassische Gastbetriebssystem. Es wird über eine deklarative gRPC-API verwaltet und bringt laut seinen Designprinzipien weder Shell noch SSH mit. Für den API-Endpunkt bietet Talos eine gemeinsame virtuelle IP, die die Control-Plane-Nodes per etcd-Wahl untereinander vergeben; Voraussetzung ist ein gemeinsames Layer-2-Netz. Betriebssystem-Upgrades nutzen ein A/B-Image-Schema und rollen automatisch zurück, wenn die neue Version nicht bootet. Kubernetes selbst wird in einem separaten Schritt aktualisiert.

RKE2 zielt auf Sicherheit und Compliance, ermöglicht FIPS-140-2-Konformität und besteht den CIS Kubernetes Benchmark mit minimalen Eingriffen. Die Control Plane läuft als Static Pods, containerd ist als Runtime eingebettet. Ein HA-Cluster besteht aus einer ungeraden Anzahl Server-Nodes, empfohlen drei, hinter einer festen Registrierungsadresse wie einem Layer-4-Load-Balancer, Round-Robin-DNS oder einer virtuellen IP. Upgrades lassen sich mit dem System Upgrade Controller automatisieren.

kubeadm ist der Upstream-Referenzweg. Ein HA-Cluster braucht drei oder mehr Control-Plane-Maschinen, entweder mit Stacked etcd oder mit separatem etcd-Cluster, dazu einen Load Balancer für den kube-apiserver. Upgrades laufen erst über die Control Plane, dann über die Worker; das Überspringen von Minor-Versionen wird nicht unterstützt.

Unabhängig von der Distribution liefern drei Control-Plane-VMs nur dann Hochverfügbarkeit, wenn sie auf drei verschiedenen physischen Proxmox-Hosts liegen. Für den API-Endpunkt ohne Talos sind ein externer Load Balancer oder eine virtuelle IP etwa über kube-vip üblich; der Vergleich MetalLB vs. kube-vip trennt beide Aufgaben. Einen ausführlichen Vergleich der drei Hauptoptionen bietet k3s vs. RKE2 vs. Talos.

Kubernetes in LXC

In Laborumgebungen läuft k3s wegen seines geringen Ressourcenbedarfs mitunter in Proxmox-LXC-Containern. Die oben beschriebenen Einschränkungen gelten trotzdem: gemeinsamer Host-Kernel, privilegierte oder speziell konfigurierte Container und engere Kopplung an den Proxmox-Host. Für produktive Cluster setzen wir KVM-VMs ein.

Die Proxmox-Seite: Templates, Talos-Images, CSI und CCM

VM-Templates mit Cloud-Init sind die übliche Basis für k3s, RKE2 und kubeadm. Proxmox kann eine vorbereitete Cloud-Init-VM in ein Template umwandeln; Linked Clones aus einem Template sind ein schneller Weg, neue VM-Instanzen auszurollen. Hostname, IP-Adresse, SSH-Key und Benutzer werden dann je Klon gesetzt.

Talos nutzt kein klassisches Cloud-Init-Template. Die offizielle Talos-Anleitung für Proxmox bootet die VMs von einem ISO aus der Image Factory, spielt die Maschinenkonfiguration mit talosctl ein und initialisiert anschließend etcd. Als VM-Einstellungen empfiehlt sie unter anderem UEFI (OVMF), Maschinentyp q35, CPU-Typ host, VirtIO SCSI statt VirtIO SCSI Single und deaktiviertes Ballooning, da Talos kein Memory Hotplug unterstützt. Der QEMU Guest Agent setzt ein Image mit der Erweiterung siderolabs/qemu-guest-agent voraus. Netzwerkeinstellungen lassen sich alternativ über den nocloud-Mechanismus übergeben. Den vollständigen Ablauf mit allen Befehlen, von der Image Factory bis zum Upgrade, zeigt die Anleitung Talos Linux auf Proxmox installieren.

Proxmox CSI und CCM verbinden beide Ebenen. Das Open-Source-Proxmox CSI Plugin stellt Persistent Volumes dynamisch als VM-Disks auf Proxmox-Storage bereit, darunter LVM, LVM-thin, ZFS, Ceph und NFS, und bindet sie als Blockgeräte an den Node. Der Proxmox Cloud Controller Manager setzt das Label topology.kubernetes.io/region auf den Proxmox-Cluster und topology.kubernetes.io/zone auf den Hypervisor-Host und entfernt Node-Objekte, wenn ihre VM gelöscht wird. Kubernetes weiß damit, welche VMs sich einen physischen Host teilen, und Topology-Spread- oder Anti-Affinity-Regeln können Pods über Hosts verteilen. Beide Projekte werden von der Community gepflegt, nicht von Proxmox Server Solutions; ihr Release-Stand und ihre Kompatibilität gehören in den Upgradeplan der Plattform.

Eine belastbare Referenzarchitektur

Eine typische, hochverfügbare Ausgangsarchitektur kann so aussehen:

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

Weiterlesen: Proxmox-HA planen.

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

ZFS, Ceph und LVM vergleichen oder Ceph planen und aufbauen lassen.

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.

Eine Kubernetes-eigene Storage-Schicht wie Longhorn repliziert dagegen selbst zwischen Nodes. Der Vergleich Longhorn vs. Rook/Ceph hilft, diese zusätzliche Ebene einzuordnen.

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

Kubernetes Backup und Restore und PBS-Offsite-Backup behandeln die getrennten Sicherungsebenen.

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.

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.

Betrieb übernehmen lassen: Kubernetes auf Proxmox verbindet die vereinbarten Aufgaben für Hypervisor und Kubernetes.

Für die konkrete Umsetzung führt die k3s-Installationsanleitung durch Cloud-Init-VMs, API-Endpunkt und Abnahme. Der Vergleich Proxmox vs Kubernetes grenzt die Aufgaben beider Plattformen ab.

Das Betriebsmodell erklärt Was ist Talos Linux?; den Aufbau als Code zeigt Talos mit OpenTofu automatisieren.

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
• Proxmox VE: Cloud-Init Support
• k3s-Dokumentation und HA mit Embedded etcd
• RKE2-Dokumentation und HA-Installation
• Talos Linux: Proxmox-Installationsanleitung
• Talos Linux: Virtual (shared) IP
• Kubernetes: Hochverfügbare Cluster mit kubeadm
• Proxmox CSI Plugin und Proxmox Cloud Controller Manager