WZ-IT plant, implementiert und betreibt Kubernetes auf Proxmox, auch mit Talos. Distribution, Netzwerk und Storage werden gemeinsam eingeordnet.
Talos Linux ist ein Linux-Betriebssystem für Kubernetes-Nodes. Es wird deklarativ über eine API verwaltet. Der reguläre Verwaltungsweg verwendet keine SSH-Sitzung und keinen Paketmanager. Das grenzt Talos von einer allgemeinen Linux-Distribution ab (Systemkonzept).
Stand: Oktober 2026, Bezug auf Talos-Dokumentation v1.14. Dieser Artikel erklärt das Betriebsmodell. Die Installation auf Proxmox und die Automatisierung mit OpenTofu stehen in eigenen Anleitungen.
Inhaltsverzeichnis
- API statt Server-Shell
- Open Source und zusätzliche Produkte
- Talos, Kubernetes und Proxmox
- Alltag mit talosctl
- Was im Betrieb bleibt
- Wann Talos passt
- Quellen
API statt Server-Shell
Mit talosctl werden Maschinenkonfigurationen angewendet und Diagnosedaten abgerufen. Die Talos-API authentifiziert reguläre Verwaltungszugriffe mit gegenseitigem TLS. Zugangsdaten und die erreichbaren Management-Netze gehören deshalb zur Sicherheitsplanung (talosctl).
Unveränderlich bedeutet kein frei beschreibbares Basissystem für manuelle Paketinstallation. Benötigte Host-Erweiterungen gehören in ein passendes Image aus der Image Factory. Konfigurationsänderungen, Wartung und Updates bleiben erforderlich. Anwendungen werden über Kubernetes ausgerollt, nicht durch Installation auf dem Host.
Open Source und zusätzliche Produkte
Der Talos-Quellcode steht unter MPL-2.0. Lizenzbedingungen für Änderungen und Weitergabe sind von Betriebsaufgaben und zusätzlichen Herstellerprodukten zu unterscheiden.
Omni ist eine zusätzliche Verwaltungsebene. Für den dokumentierten Aufbau auf Proxmox genügt der in der Herstelleranleitung gezeigte Weg mit Image Factory und talosctl. Ein Open-Source-Betriebssystem bedeutet weder kostenlosen Support noch einen Betrieb ohne Wartung.
Talos, Kubernetes und Proxmox
| Ebene | Aufgabe | Daraus folgt nicht |
|---|---|---|
| Proxmox VE | Virtuelle Maschinen und deren Ressourcen bereitstellen | Kubernetes-Workloads verwalten |
| Talos Linux | Betriebssystem der Kubernetes-Nodes bereitstellen | Allgemeiner Linux-Server mit beliebigen Paketen sein |
| Kubernetes | Containerisierte Workloads orchestrieren | Anwendungsdaten automatisch sichern |
Die Aufgaben folgen der Talos-Proxmox-Anleitung und den Kubernetes-Komponenten. Talos läuft dort in KVM-VMs. Der Ansatz ist von Proxmox-LXC-Containern mit gemeinsamem Hostkernel zu unterscheiden.
Für die Distributionswahl hilft k3s vs. RKE2 vs. Talos. Talos verändert vor allem das Node-Betriebsmodell; die Kubernetes-API für Anwendungen bleibt die darüberliegende Schnittstelle.
Alltag mit talosctl
Wer Linux-Server per SSH betreut, findet für die gewohnten Handgriffe ein Gegenstück in talosctl. Die Befehle laufen von der Admin-Maschine aus gegen die Talos-API der Nodes:
| Aufgabe | Klassisches Linux | Talos Linux |
|---|---|---|
| Dienstzustand prüfen | systemctl status kubelet |
talosctl services --nodes 192.168.10.11 |
| Dienst-Logs lesen | journalctl -u kubelet |
talosctl logs kubelet --nodes 192.168.10.11 |
| Kernel-Meldungen lesen | dmesg |
talosctl dmesg --nodes 192.168.10.11 |
| Konfiguration ändern | Datei bearbeiten | talosctl edit machineconfig --nodes 192.168.10.11 oder talosctl patch machineconfig |
| Neustart | reboot |
talosctl reboot --nodes 192.168.10.11 |
| Zusätzliche Software | Paket installieren | Erweiterung im Schematic der Image Factory, danach talosctl upgrade |
| Gesundheit des Clusters | Einzelprüfungen | talosctl health |
| etcd sichern | Skript auf dem Host | talosctl etcd snapshot etcd-backup.db |
| Node ausmustern | Neu aufsetzen | talosctl reset --nodes 192.168.10.11 |
Das Betriebssystem wird nicht gepatcht, sondern ersetzt: talosctl upgrade schreibt ein neues Image auf die zweite Partition (A/B) und startet den Node neu; bei Problemen kehrt Talos zum vorigen Image zurück. Kubernetes aktualisiert talosctl upgrade-k8s getrennt davon. Die konkreten Aufrufe für Installation, Bootstrap und Upgrades stehen in der Anleitung zur Installation auf Proxmox.
Was im Betrieb bleibt
Die Production Notes behandeln Control Plane, API-Endpunkt und Betriebsanforderungen. Mehrere Control Planes müssen auf unabhängige Ausfallbereiche verteilt werden. Drei VMs auf demselben Proxmox-Host schützen nicht gegen dessen Ausfall.
Zur Abnahme gehören erreichbare APIs, funktionierendes Pod-Netz, geeigneter Storage und überprüfte Zugänge. Ein Node-Image ist kein Backup der Anwendungen. Für etcd, persistente Daten und Wiederanlauf bleibt ein eigener Backup- und Restore-Plan erforderlich.
Wann Talos passt
Talos ist zu prüfen, wenn ein Team Maschinenkonfiguration als Code pflegen und Hosteingriffe über eine API standardisieren will. Benötigt eine Anwendung zusätzliche Hostpakete oder besondere Treiber, sollten diese vor der Distributionswahl gegen die Image- und Erweiterungswege geprüft werden. Ein allgemeines Linux mit k3s oder RKE2 bleibt eine Vergleichsoption.
Für die Auslegung verbindet WZ-IT Kubernetes auf Proxmox mit Hosts, Netzwerk, Storage und Betriebsprozessen. Die Auswahl folgt den Anforderungen der Umgebung.
