Talos Linux auf Proxmox installieren: Kubernetes-Cluster Schritt für Schritt

Talos-Cluster auf Proxmox produktiv aufbauen? WZ-IT plant Proxmox-Hosts, Failure Domains, Netzwerk und Storage gemeinsam mit der Kubernetes-Schicht und betreibt die Plattform auf Wunsch weiter. Kubernetes auf Proxmox als Leistung

Talos Linux ist ein unveränderliches Betriebssystem, das ausschließlich Kubernetes ausführt und nur über eine API verwaltet wird. Auf Proxmox läuft es in KVM-VMs, die von einem ISO aus der Image Factory booten. Diese Anleitung führt vom Image bis zum hochverfügbaren Cluster mit drei Control Planes, virtueller IP für die Kubernetes-API, CNI, Proxmox-Storage-Anbindung und Upgradepfad. Die Befehle folgen der offiziellen Talos-Anleitung für Proxmox und den Production Notes, ergänzt um die Proxmox-seitigen Einstellungen.

Ob Talos überhaupt die passende Distribution ist, klärt der Vergleich k3s vs. RKE2 vs. Talos. Die Architekturfragen rund um Proxmox und Kubernetes, etwa VM oder LXC, Storage und Backup, behandelt Kubernetes auf Proxmox.

Inhaltsverzeichnis

• Stand und Voraussetzungen
• Schritt 1: Talos-Image aus der Image Factory
• Schritt 2: Control-Plane- und Worker-VMs in Proxmox anlegen
• Schritt 3: Netzwerkschnittstelle und Disk prüfen
• Schritt 4: Maschinenkonfiguration mit virtueller IP erzeugen
• Schritt 5: Konfiguration anwenden
• Schritt 6: Cluster bootstrappen und kubeconfig abrufen
• CNI: Flannel oder Cilium
• Proxmox CSI und Cloud Controller Manager
• Upgrades: Talos und Kubernetes getrennt
• Typische Fehler
• Ausblick: Terraform und OpenTofu
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

Stand und Voraussetzungen

Stand 18. Oktober 2026 ist Talos Linux v1.14.4 vom 16. Oktober 2026 das aktuelle stabile Release. Es bringt Kubernetes 1.37.1 und Linux 6.18.57 mit; laut Support Matrix unterstützt Talos 1.14 die Kubernetes-Versionen 1.33 bis 1.37. Seit Talos 1.14 wird das Installer-Image nicht mehr unter ghcr.io/siderolabs/installer veröffentlicht, sondern ausschließlich über die Image Factory als factory.talos.dev/metal-installer/<schematic-id>:<version> ausgeliefert.

Für einen hochverfügbaren Cluster werden benötigt:

• Drei Proxmox-Hosts in einem Cluster, damit jede Control-Plane-VM auf einem eigenen physischen Host liegt. Für ein Labor genügt ein Host. Die Proxmox-Grundinstallation beschreibt Proxmox installieren, den Cluster HA-Cluster mit Proxmox aufbauen.
• Ein gemeinsames Layer-2-Netz für die Control-Plane-Nodes. Die virtuelle IP von Talos setzt voraus, dass alle Control Planes ohne Router dazwischen im selben Subnetz liegen.
• Feste Adressen: je eine IP für die Nodes, am einfachsten als DHCP-Reservierung, und eine freie, nicht per DHCP vergebene IP für die virtuelle IP der Kubernetes-API.
• talosctl und kubectl auf der Admin-Maschine. Die Installation von talosctl läuft unter macOS und Linux per Homebrew oder Installationsskript. Die Version von talosctl sollte der Talos-Version der Nodes entsprechen.

brew install siderolabs/tap/talosctl
# alternativ ohne Homebrew: Skript laden, lesen, erst dann ausführen
curl -fsSLo talos-install.sh https://talos.dev/install
less talos-install.sh
sh talos-install.sh

Als Zielbild dient in dieser Anleitung folgender Cluster. Die Werte kombinieren die Empfehlungen der Proxmox-Anleitung mit den Systemanforderungen:

Schematisches Zielbild:

Kubernetes API: VIP 192.168.10.50
              |          |          |
Proxmox Host 1     Host 2     Host 3
        CP .11     CP .12     CP .13
        Worker .21           Worker .22

Die Host-Dimensionierung erläutert Proxmox Hardware und Sizing.

Die Beispiele verwenden das Netz 192.168.10.0/24 mit den Control Planes .11 bis .13, den Workern .21 und .22 und der virtuellen IP .50.

Schritt 1: Talos-Image aus der Image Factory

Die Image Factory erzeugt Talos-Images aus einem sogenannten Schematic, das Systemerweiterungen und Kernelparameter festlegt. Schematics sind inhaltsadressiert: Derselbe Inhalt ergibt immer dieselbe ID. Das Standard-Schematic ohne Anpassungen hat die ID 376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba.

Für Proxmox empfiehlt sich die Erweiterung siderolabs/qemu-guest-agent. Sie ist laut Talos-Anleitung optional und wird für das Herunterfahren der VMs über den QEMU Guest Agent benötigt. Das Schematic lässt sich in der Weboberfläche unter factory.talos.dev zusammenklicken oder per API anlegen:

cat > schematic.yaml <<'EOF'
customization:
  systemExtensions:
    officialExtensions:
      - siderolabs/qemu-guest-agent
EOF

curl -X POST --data-binary @schematic.yaml https://factory.talos.dev/schematics
# {"id":"ce4c980550dd2ab1b17bbf2b08801c7eb59418eafe8f279833297925d67c7515", ...}

Mit dieser ID wird das ISO direkt auf einem Proxmox-Host in den ISO-Speicher des Storage local geladen (Verzeichnis /var/lib/vz/template/iso). Alternativ lädt man es im Proxmox-Webinterface unter local > ISO Images > Upload hoch.

export TALOS_VERSION=v1.14.4
export SCHEMATIC_ID=ce4c980550dd2ab1b17bbf2b08801c7eb59418eafe8f279833297925d67c7515

cd /var/lib/vz/template/iso
wget -O talos-${TALOS_VERSION}-qemu-ga-amd64.iso \
  https://factory.talos.dev/image/${SCHEMATIC_ID}/${TALOS_VERSION}/metal-amd64.iso

Zum selben Schematic gehört das Installer-Image factory.talos.dev/metal-installer/ce4c980550dd2ab1b17bbf2b08801c7eb59418eafe8f279833297925d67c7515:v1.14.4. Es wird in Schritt 4 in die Maschinenkonfiguration geschrieben, damit die Erweiterung auch nach der Installation auf der Disk erhalten bleibt, und später für Upgrades verwendet.

Schritt 2: Control-Plane- und Worker-VMs in Proxmox anlegen

Die Talos-Anleitung für Proxmox empfiehlt für alle Talos-Nodes folgende Einstellungen:

Statt sich durch die acht Tabs des Assistenten zu klicken, legt qm auf dem jeweiligen Proxmox-Host die VM mit denselben Werten an. Das Beispiel erzeugt die erste Control Plane; Storage-Namen, VM-IDs und Größen sind an die eigene Umgebung anzupassen. Die Optionen sind im qm-Handbuch beschrieben.

qm create 111 --name talos-cp-1 --ostype l26 \
  --bios ovmf --machine q35 \
  --efidisk0 local-lvm:1,efitype=4m,pre-enrolled-keys=0 \
  --cpu host --cores 4 --memory 4096 --balloon 0 \
  --scsihw virtio-scsi-pci \
  --scsi0 local-lvm:100,cache=writethrough,discard=on,ssd=1 \
  --net0 virtio,bridge=vmbr0 \
  --ide2 local:iso/talos-v1.14.4-qemu-ga-amd64.iso,media=cdrom \
  --boot 'order=scsi0;ide2' \
  --agent enabled=1 \
  --serial0 socket

--scsihw virtio-scsi-pci entspricht „VirtIO SCSI“ im Webinterface, --balloon 0 schaltet den Ballooning-Treiber ab, der laut Proxmox-Dokumentation sonst auch bei fester Speichergröße aktiv ist. Die serielle Konsole empfiehlt die Talos-Anleitung, um frühe Bootmeldungen und Netzwerkprobleme zu sehen. Die Control Planes talos-cp-2 und talos-cp-3 entstehen auf den beiden anderen Proxmox-Hosts, die Worker mit mindestens 4 Kernen und 8 GB RAM.

Zwei Folgen dieser Einstellungen gehören in die Planung:

• CPU-Typ host und Live-Migration: Die Talos-Anleitung weist darauf hin, dass der CPU-Typ host Live-Migration verhindert. Proxmox beschreibt das Problem allgemein: Auf einem Zielhost mit anderer CPU oder anderem Microcode fehlen Flags, und der QEMU-Prozess stoppt. Bei Talos ist das vertretbar, denn Nodes werden für Wartung per talosctl geleert und neu gestartet, statt zwischen Hosts verschoben zu werden.
• Control Planes auseinanderhalten: Werden die Talos-VMs von Proxmox HA verwaltet, verhindert eine Resource-Affinity-Regel mit negativer Affinität, dass HA zwei Control Planes nach einem Ausfall auf demselben Host startet.

ha-manager rules add resource-affinity talos-cp-apart \
  --affinity negative --resources vm:111,vm:112,vm:113

Schritt 3: Netzwerkschnittstelle und Disk prüfen

Nach dem Start booten die VMs vom ISO in den Maintenance-Modus. Das System läuft dann vollständig im Arbeitsspeicher, die Proxmox-Konsole zeigt die per DHCP erhaltene IP-Adresse. Ohne DHCP wird die Adresse laut Anleitung im GRUB-Menü mit e als Kernelparameter ip= angehängt.

Im Maintenance-Modus ist die Talos-API bewusst nicht authentifiziert: Wer das Netz erreicht, kann eine Konfiguration einspielen. Das Installationsnetz gehört deshalb nicht ins Internet.

CONTROL_PLANE_IP=("192.168.10.11" "192.168.10.12" "192.168.10.13")
WORKER_IP=("192.168.10.21" "192.168.10.22")

talosctl --nodes 192.168.10.11 get links --insecure
talosctl get disks --insecure --nodes 192.168.10.11

Aus get links wird der Name der Schnittstelle mit Status up übernommen. Talos vergibt seit Version 1.5 vorhersagbare Schnittstellennamen, daher heißt die Karte nicht zwingend eth0. get disks zeigt die Installationsdisk. Standardziel ist /dev/sda, was bei einer Disk am VirtIO-SCSI-Controller in der Regel passt. Weicht der Pfad ab, wird er beim Erzeugen der Konfiguration mit --install-disk gesetzt.

Schritt 4: Maschinenkonfiguration mit virtueller IP erzeugen

Talos bringt eine virtuelle IP für die Kubernetes-API mit: Die Control-Plane-Nodes vergeben die Adresse per etcd-Wahl untereinander, ein externer Load Balancer entfällt. Fällt der Halter geordnet aus, wechselt die Adresse fast sofort; bei einem Absturz dauert die Übernahme bis zu etwa einer Minute. In Talos 1.14 wird die VIP als eigenes Dokument Layer2VIPConfig konfiguriert:

cat > vip.yaml <<'EOF'
apiVersion: v1alpha1
kind: Layer2VIPConfig
name: 192.168.10.50
link: <schnittstelle-aus-get-links>
EOF

Anschließend entstehen Secrets-Bundle und Maschinenkonfiguration. Das Secrets-Bundle enthält alle Schlüssel, Zertifikate und Tokens des Clusters und wird wie ein Passwortsafe behandelt. Der Kubernetes-Endpunkt zeigt auf die VIP, das Installer-Image stammt aus Schritt 1:

export CLUSTER_NAME=talos-proxmox
export VIP=192.168.10.50

talosctl gen secrets -o secrets.yaml

talosctl gen config --with-secrets secrets.yaml \
  --install-image factory.talos.dev/metal-installer/${SCHEMATIC_ID}:${TALOS_VERSION} \
  --config-patch-control-plane @vip.yaml \
  --output _out \
  $CLUSTER_NAME https://$VIP:6443

Im Verzeichnis _out liegen danach controlplane.yaml, worker.yaml und talosconfig. Weitere Anpassungen, etwa statische Adressen, Labels oder eine andere CNI, kommen nach demselben Muster als Konfigurations-Patches hinzu, statt die erzeugten Dateien von Hand zu bearbeiten.

Schritt 5: Konfiguration anwenden

Die Konfiguration wird im Maintenance-Modus mit --insecure eingespielt. Talos installiert sich daraufhin auf die Disk und startet neu.

for ip in "${CONTROL_PLANE_IP[@]}"; do
  talosctl apply-config --insecure --nodes "$ip" --file _out/controlplane.yaml
done

for ip in "${WORKER_IP[@]}"; do
  talosctl apply-config --insecure --nodes "$ip" --file _out/worker.yaml
done

Die Control Planes bleiben bis zum Bootstrap in der Phase Booting. Nach erfolgreicher Installation kann das ISO-Laufwerk aus den VMs entfernt werden; die Production Notes empfehlen das Aushängen des Installationsmediums, damit eindeutig ist, auf welche Disk installiert wird.

Schritt 6: Cluster bootstrappen und kubeconfig abrufen

talosctl spricht ab jetzt authentifiziert per gegenseitigem TLS mit den Nodes. Als Endpunkte werden die drei Control-Plane-IPs eingetragen, nicht die VIP: Die VIP hängt an etcd und kube-apiserver, und bei einem Fehler in einer dieser Komponenten wäre die Talos-API zur Reparatur sonst nicht erreichbar.

export TALOSCONFIG=$PWD/_out/talosconfig
talosctl config endpoint "${CONTROL_PLANE_IP[@]}"
talosctl config node "${CONTROL_PLANE_IP[0]}"

# genau einmal, auf genau einem Control-Plane-Node
talosctl bootstrap --nodes "${CONTROL_PLANE_IP[0]}"

talosctl health
talosctl kubeconfig --nodes "${CONTROL_PLANE_IP[0]}"
kubectl get nodes -o wide

talosctl bootstrap initialisiert etcd. Der Befehl wird laut Production Notes nur einmal auf einem einzigen Control-Plane-Node ausgeführt; die übrigen Control Planes treten dem etcd-Cluster selbst bei. Erst danach wird die VIP aktiv. talosctl kubeconfig führt die Zugangsdaten in die Standard-kubeconfig zusammen. Statt einer Shell dient talosctl dashboard als Übersicht über Dienste, Logs und Ressourcen eines Nodes.

CNI: Flannel oder Cilium

Ohne weitere Angaben installiert Talos Flannel als Standard-CNI im VXLAN-Modus, kube-proxy übernimmt das Service-Routing. Seit Talos 1.13 kann Flannel NetworkPolicies durchsetzen, in Talos 1.14 per Dokument KubeFlannelCNIConfig mit kubeNetworkPoliciesEnabled: true.

Cilium ist die verbreitete Alternative, wenn eBPF, feinere NetworkPolicies, kube-proxy-freier Betrieb oder die Gateway API benötigt werden. Die Entscheidung fällt vor dem Bootstrap: Die CNI wird per Patch auf „none“ gesetzt, in Talos 1.14 durch Löschen des Flannel-Dokuments, und Cilium anschließend per Helm installiert.

apiVersion: v1alpha1
kind: KubeFlannelCNIConfig
$patch: delete

Talos stellt für Cilium bereits cgroupv2 und bpffs bereit, erlaubt Workloads kein Laden von Kernelmodulen und erwartet IPAM im Modus kubernetes; diese Punkte nennt die Cilium-Anleitung als feste Voraussetzungen. Für Services vom Typ LoadBalancer braucht ein Proxmox-Cluster zusätzlich eine Lösung wie MetalLB oder kube-vip; den Unterschied zwischen Service-LB und Control-Plane-VIP erklärt MetalLB vs. kube-vip.

Proxmox CSI und Cloud Controller Manager

Zwei Open-Source-Projekte verbinden Kubernetes mit der Proxmox-Ebene. Beide werden von der Community gepflegt, nicht von Proxmox Server Solutions oder Sidero Labs.

• Das Proxmox CSI Plugin (Stand Oktober 2026 Version v0.21.0) legt Persistent Volumes als VM-Disks auf Proxmox-Storage an und hängt sie als Blockgeräte an den Node. Volumes auf lokalem Storage wie LVM oder ZFS bleiben an ihren Proxmox-Host gebunden, Volumes auf Ceph oder NFS können Pods zwischen Hosts folgen. Voraussetzung ist ein Proxmox-Cluster, notfalls aus einem einzelnen Node.
• Der Proxmox Cloud Controller Manager (Version v0.16.1) setzt topology.kubernetes.io/region auf den Proxmox-Cluster und topology.kubernetes.io/zone auf den Hypervisor-Host und entfernt Node-Objekte, wenn die VM gelöscht wird. Er setzt voraus, dass der Kubelet mit --cloud-provider=external läuft. In Talos geschieht das über cluster.externalCloudProvider.enabled: true in der Maschinenkonfiguration; das Projekt liefert ein eigenes Manifest für Talos mit.

Mit diesen Labels kann Kubernetes Pods per Topology Spread oder Anti-Affinity über physische Hosts verteilen. Ob Proxmox-Volumes, Longhorn oder Rook-Ceph die richtige Storage-Schicht sind, vergleicht Longhorn vs. Rook-Ceph.

Lokaler und geteilter Proxmox-Storage werden in ZFS, Ceph und LVM gegenübergestellt.

Upgrades: Talos und Kubernetes getrennt

Betriebssystem und Kubernetes haben bei Talos getrennte Lebenszyklen. Ein Talos-Upgrade aktualisiert Kubernetes nicht automatisch mit.

Talos-Upgrade: talosctl upgrade übergibt einem Node das Installer-Image der Zielversion. Wichtig ist, dasselbe Schematic zu verwenden, mit dem der Node installiert wurde, sonst fehlt danach die Guest-Agent-Erweiterung. Talos nutzt ein A/B-Schema und kehrt automatisch zur vorherigen Version zurück, wenn die neue nicht bootet. Standardmäßig wird der Node vorher geleert. Getestet sind Upgrades nur zwischen benachbarten Minor-Versionen, daher führt der Weg über die jeweils letzte Patch-Version jeder Zwischenversion. Control Planes aktualisieren wir einzeln nacheinander, damit das etcd-Quorum jederzeit erhalten bleibt.

# vorher: etcd-Snapshot sichern
talosctl --nodes 192.168.10.11 etcd snapshot etcd-backup.db

talosctl upgrade --nodes 192.168.10.11 \
  --image factory.talos.dev/metal-installer/${SCHEMATIC_ID}:v1.14.4

Kubernetes-Upgrade: talosctl upgrade-k8s aktualisiert alle Kubernetes-Komponenten im Cluster, auch wenn mit --nodes nur ein Control-Plane-Node angesprochen wird. Ein Trockenlauf zeigt vorab den Plan und veraltete API-Ressourcen.

talosctl --nodes 192.168.10.11 upgrade-k8s --to 1.37.1 --dry-run
talosctl --nodes 192.168.10.11 upgrade-k8s --to 1.37.1

Proxmox-Snapshots der VMs ersetzen weder etcd-Snapshots noch Anwendungsbackups. Die vier Sicherungsebenen beschreibt Kubernetes-Backup und Restore.

Typische Fehler

• VirtIO SCSI Single als Controller: Der Bootstrap hängt oder Disks werden nicht erkannt. Richtig ist VirtIO SCSI.
• CPU-Typ kvm64: Talos-Images für amd64 verlangen x86-64-v2. Ein älteres CPU-Modell führt laut Systemanforderungen zum Halt beim Booten mit der Meldung „x86_64 microarchitecture level 2 or higher is required“.
• Ballooning aktiv: Talos sieht nicht den gesamten zugewiesenen Arbeitsspeicher.
• Guest Agent ohne Erweiterung: Ist in Proxmox der QEMU Guest Agent aktiv, das Image aber ohne siderolabs/qemu-guest-agent gebaut, entstehen nur Log-Meldungen.
• VIP als talosctl-Endpunkt: Bei einem etcd-Problem ist die Talos-API dann nicht mehr erreichbar.
• Alle Control Planes auf einem Host: Drei VMs ergeben nur dann Hochverfügbarkeit, wenn sie auf drei physischen Hosts laufen.
• Wechselnde DHCP-Adressen: Ohne Reservierung oder statische Konfiguration ändern sich Node-IPs, und talosconfig-Endpunkte laufen ins Leere.

Ausblick: Terraform und OpenTofu

Für reproduzierbare Cluster lässt sich der gesamte Ablauf als Code abbilden. Der Provider siderolabs/talos (Stand Oktober 2026 v0.12.0) bildet Image-Factory-Schematics, Secrets, Maschinenkonfiguration, apply-config, Bootstrap und kubeconfig als Ressourcen und Datenquellen ab. Der Community-Provider bpg/proxmox (v0.117.0) erstellt die VMs in Proxmox VE. Beide sind auch in der OpenTofu-Registry verfügbar. Zusammen ergibt sich eine Kette aus VM-Erzeugung, Konfiguration und Bootstrap, an die GitOps für CNI, CSI und Workloads anschließt.

Alternativ übergibt Talos die Maschinenkonfiguration über den nocloud-Mechanismus, etwa per Cloud-Init-Laufwerk oder SMBIOS-Seriennummer in Proxmox. Dann entfällt das manuelle apply-config im Maintenance-Modus.

Die Folgeanleitung Talos auf Proxmox mit OpenTofu automatisieren zeigt VM-Deklaration, Maschinenkonfiguration, Bootstrap und State-Verwaltung als zusammenhängenden Ablauf.

Unser Vorgehen bei WZ-IT

Bei Kubernetes auf Proxmox planen wir Infrastruktur und Cluster gemeinsam:

1. Sizing und Failure Domains: Workloads, Verfügbarkeitsziele und Wachstum bestimmen Anzahl und Größe der Proxmox-Hosts und Node-VMs.
2. Proxmox-Design: Compute, Storage, Netzwerksegmente, Quorum und Backup-Architektur werden festgelegt, bevor die erste Talos-VM entsteht.
3. Automatisierter Cluster-Aufbau: Node-VMs, Maschinenkonfiguration und Plattformbaseline entstehen reproduzierbar als Code, ergänzt um GitOps aus dem Platform Engineering.
4. Onboarding und Lifecycle: Anwendungen werden kontrolliert übernommen, Upgrades von Proxmox, Talos und Kubernetes koordiniert und dokumentiert, auf Wunsch im laufenden Betrieb über Managed Kubernetes.

Die Distribution folgt dem Betriebsmodell. Talos Linux passt, wenn ein deklarativ verwalteter, minimaler Node-Unterbau gewünscht ist; für andere Anforderungen kommen k3s oder RKE2 infrage.

Weiterführende Guides

• Kubernetes auf Proxmox: Architektur, VM oder LXC, Hochverfügbarkeit auf zwei Ebenen, Storage und Backup.
• k3s vs. RKE2 vs. Talos: welche Distribution zu welchem Betriebsmodell passt.
• MetalLB vs. kube-vip: Load Balancing für Services auf Bare Metal und Proxmox.
• Longhorn vs. Rook-Ceph: Kubernetes-eigene Storage-Schichten im Vergleich.
• Kubernetes privat über NetBird erreichen: Cluster-API und Talos-API ohne öffentliche Exposition.
• Proxmox: LXC vs. KVM: wann Container und wann VMs.

Für Planung, Aufbau oder Betrieb eines Talos-Clusters auf Proxmox: Kubernetes auf Proxmox mit WZ-IT.

Die Grundlagen erklärt Was ist Talos Linux?.

Quellen

• Talos Linux: Proxmox-Installationsanleitung (v1.14)

• Talos Linux: Production Notes

• Talos Linux: Systemanforderungen und Support Matrix

• Talos Linux: Image Factory

• Talos Linux: Virtual (shared) IP

• Talos Linux: Upgrading Talos und Upgrading Kubernetes

• Talos Linux: talosctl-CLI-Referenz

• Talos Linux: Flannel und Cilium

• Talos Linux: Designprinzipien

• Talos Linux v1.14.4 Release Notes

• Proxmox VE: qm-Handbuch und High Availability

• Proxmox VE: Linux Container

• Proxmox CSI Plugin und Proxmox Cloud Controller Manager

• Terraform-Provider siderolabs/talos und bpg/proxmox

• Talos MPL-2.0

• Proxmox CSI v0.21.0

• bpg/proxmox v0.117.0