--- title: "Talos Linux und Omni für Kubernetes-Cluster | SKAFFON" description: "Talos Linux und Omni einführen: Lizenzgrenzen von Omni (BSL), Betriebsmodelle, Provisionierung, Updates und HA. Mit Entscheidungsmatrix." url: https://skaffon.de/infrastruktur/talos-omni/ --- ![Farbig hervorgehobener Programmcode auf einem dunklen Monitor, schräg fotografiert](/_astro/farbig-hervorgehobener-programmcode-monitor.CZeqtxWM_20RVoL.jpg) 1. [Startseite](/) 2. [Infrastruktur](/infrastruktur/) 3. Talos Linux und Omni für Kubernetes-Cluster Kubernetes-Betrieb · Talos Linux · Omni # Talos Linux und Omni für Kubernetes-Cluster Knoten ohne Shell und ohne Konfigurationsdrift: SKAFFON führt Talos Linux ein und richtet Omni für den Cluster-Lebenszyklus ein, wo es zu Ihren Anforderungen und zur Lizenzlage passt. [Projekt anfragen](/projekt-anfragen/) [Betriebsmodelle vergleichen](/infrastruktur/talos-omni/#sechs-betriebsmodelle-fuer-omni) - Talos: Mozilla Public License 2.0 - Omni: Business Source License 1.1 - Neuer Cluster neben dem alten Autor: [Ibrahim Yesilay](/unternehmen/ibrahim-yesilay/), Gründer und Geschäftsführer Stand: 13.11.2026 Ausgangslage ## Kubernetes-Knoten, die niemand per SSH anfasst Wer Kubernetes auf Bare Metal, auf virtuellen Maschinen oder an verteilten Standorten betreibt, kennt das Problem: Installation, Updates und Austausch der Knoten laufen von Hand und von Knoten zu Knoten leicht unterschiedlich. SKAFFON führt dafür Talos Linux als Betriebssystem ein und richtet Omni zur Verwaltung der Cluster ein, wo es zu Ihren Anforderungen passt. Wir sagen offen, wo Lizenzen und Betriebsmodelle Grenzen setzen: Omni ist nicht Open Source im Sinne der OSI-Definition. Herstellersupport für Talos und Omni leistet Sidero Labs; wir arbeiten als Engineering-Dienstleister mit diesen Produkten. Ziel Ein Knoten ist ersetzbar: neues Image, neue Konfiguration aus Git, fertig. ## So greifen Omni, Talos und Ihre Cluster ineinander Omni verwaltet die Talos-Knoten per WireGuard, die Zugriffe laufen über Ihren Identity Provider, die Konfiguration kommt aus Git. Schematische Darstellung: drei Control-Plane-Knoten, zwei Worker-Sätze, Git-Repository und Identity Provider. Schematische Darstellung: drei Control-Plane-Knoten, zwei Worker-Sätze, Git-Repository und Identity Provider. ## Talos Linux und Omni: zwei Produkte, zwei Aufgaben **Talos Linux** ist ein Betriebssystem, das nur dazu da ist, Kubernetes zu betreiben. Laut Hersteller gibt es weder Shell noch SSH; die gesamte Verwaltung läuft über eine API, abgesichert per mTLS. Das Betriebssystem läuft unveränderlich aus einem SquashFS-Image, die beschreibbare Partition ist ausdrücklich „ephemeral“, also nicht für einmalige, unersetzliche Daten gedacht ([Talos: Philosophy](https://docs.siderolabs.com/talos/v1.14/learn-more/philosophy.md)). Talos steht unter der Mozilla Public License 2.0 ([Talos auf GitHub](https://github.com/siderolabs/talos)). **Omni** ist die Verwaltungsplattform darüber: Sie erstellt Cluster, automatisiert Updates von Betriebssystem und Kubernetes, stellt einen hochverfügbaren Kubernetes-API-Endpunkt bereit und bindet Zugriff an Ihren Identity Provider an. Die Kommunikation zwischen Omni und den Maschinen läuft über WireGuard ([Omni: Overview](https://docs.siderolabs.com/omni/overview/what-is-omni.md)). - Keine Shell, kein SSH, Verwaltung per API (mTLS) - Unveränderliches SquashFS-Image - Omni: Cluster erstellen, Updates, Zugriff per Identity Provider ![IT-Techniker mit Brille prüft zwischen gebündelten Netzwerkkabeln die Verkabelung in einem Serverraum](/_astro/techniker-brille-zwischen-gebuendelten.DCj4UkoY_Z1NtBKc.jpg) ## Fällt Omni aus, laufen Ihre Cluster weiter Omni ist nicht Teil der Kubernetes-Control-Plane. Laut Herstellerdokumentation laufen die Cluster bei vorübergehender Nichterreichbarkeit weiter, die Maschinen verbinden sich danach wieder. Der externe Zugriff (kubectl, Dienste) läuft aber über Omni und fehlt bei längerem Ausfall. Dafür gibt es eine „Break-glass“-Konfiguration ([Omni: Options for Running Omni](https://docs.siderolabs.com/omni/self-hosted/options-for-running-omni.md)). Diese Notzugänge gehören in jedes Betriebskonzept und werden von uns getestet. Lizenz ## Omni-Lizenz: die Frage, die vor dem Projekt feststehen muss Omni steht unter der **Business Source License 1.1** (Lizenzgeber Sidero Labs). Die Lizenz erlaubt Lesen, Ändern und Nutzung außerhalb der Produktion; die Zusatzerlaubnis (Additional Use Grant) gestattet Nicht-Produktivnutzung wie Test und Evaluierung von Omni selbst sowie private Heimlabor-Nutzung. Jeder Einsatz, auf den das eigene Geschäft, der eigene Betrieb oder die eigene Entwicklung angewiesen ist, braucht eine kommerzielle Lizenz, unabhängig davon, wie die Umgebung genannt wird. Zum Änderungsdatum 2030-10-23 wechselt die Lizenz laut Lizenztext auf Mozilla Public License 2.0 ([Omni-Lizenz](https://github.com/siderolabs/omni/blob/main/LICENSE)). Die Auslegung des Herstellers ist deutlich: Auch dauerhaft genutzte Staging-, QA- und CI-Umgebungen sowie Disaster-Recovery- oder Standby-Umgebungen zählen als Produktion; ebenso das Verwalten von Kundenclustern als Dienstleister ([Omni: Production vs. Non-Production](https://docs.siderolabs.com/omni/self-hosted/production-vs-non-production.md)). Das hat zwei Folgen: 1. Für produktiven Selbstbetrieb von Omni brauchen Sie eine Subscription für Self-Hosting oder nutzen die gehostete SaaS-Variante von Sidero Labs, die für Produktion lizenziert ist. 2. Wenn SKAFFON Cluster für Sie betreibt und dabei Omni einsetzt, muss die Lizenzfrage vertraglich geklärt sein. Wer die kommerzielle Lizenz hält, legen wir je Kunde fest. Wer Omni nicht lizenzieren möchte, kann Talos allein nutzen, mit `talosctl` und Cluster-Konfiguration aus Git. Das ist möglich und in manchen Umgebungen die richtige Wahl; es bedeutet mehr eigene Automatisierung für Provisionierung, Upgrades und Zugriffsverwaltung. Ohne Omni verwendet Talos zur Knoten-Erkennung standardmäßig den öffentlichen Discovery-Dienst; eine selbst betriebene Instanz setzt laut Dokumentation eine Lizenz von Sidero Labs voraus ([Talos: Air-gapped Environments](https://docs.siderolabs.com/talos/v1.14/platform-specific-installations/air-gapped.md)). Talos Enterprise Linux Sidero bietet eine kommerzielle Distribution mit FIPS-fähigen Builds, SBOMs je Image, VEX-Daten und Schwachstellenberichten an, die Omni einschließt ([Sidero: Talos Enterprise Linux](https://docs.siderolabs.com/talos-enterprise-linux/overview/introducing-talos-enterprise-linux.md)). Ob das relevant ist, hängt von Ihren Compliance-Anforderungen ab. ## Sechs Betriebsmodelle für Omni im Vergleich Laut Hersteller wird Omni in diesen Modellen betrieben. Die Spalte „Lizenz“ gilt für Produktivnutzung. __Omni-Betriebsmodelle: Eignung, Aufwand, Besonderheiten und Lizenz__ | Modell | Passt, wenn | Aufwand bei Ihnen | Besonderheiten laut Hersteller | Lizenz | | -------------------------------------- | ---------------------------------------------------------- | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------- | | Gehostetes Omni (SaaS von Sidero Labs) | Keine strikten Self-Hosting- oder Air-Gap-Vorgaben | Gering: Plattform wird vom Hersteller betrieben | Knoten müssen die Omni-Endpunkte erreichen (TCP 443, UDP 51820; über einen HTTP-Proxy per gRPC-Tunnel möglich, siehe [Egress-Anforderungen](https://docs.siderolabs.com/omni/omni-cluster-setup/omni-firewall-egress-requirement.md)) | Für Produktion lizenziert (SaaS-Angebot) | | Self-Hosted, einzelne VM | Standard für On-Prem; einfach zu sichern | Mittel: VM, Backup, Updates von Omni | Docker Compose, eingebettetes etcd, VM-Snapshots genügen oft für Backup; Ausfall beeinträchtigt laufende Cluster nicht | Kommerzielle Lizenz | | Self-Hosted auf Kubernetes | Schnellere Wiederherstellung gefordert | Höher | Nie in einem Cluster betreiben, den Omni selbst verwaltet; für Air-Gap vom Hersteller nicht empfohlen | Kommerzielle Lizenz | | Mit externem etcd | Produktivbetrieb, größere Umgebungen | Höher: etcd nach Ihren Datenbankpraktiken betreiben | Für Produktion vom Hersteller empfohlen; getestet bis 5.000 verbundene Knoten je Instanz | Kommerzielle Lizenz | | Hochverfügbar | Strenge Verfügbarkeitsanforderungen an den externen Zugang | Sehr hoch | Externes HA-etcd und HA-Registry, Image Factory, Authentifizierung; laut Hersteller mindestens 12 Server; nur eine Omni-Instanz zur Zeit | Kommerzielle Lizenz | | Air-Gapped | Keine Internetverbindung | Hoch | Omni, Image Factory, Registry und Authentifizierung offline; Spiegelung aller Artefakte | Laut Hersteller Supportvertrag für Produktion | Quelle: [Omni: Options for Running Omni](https://docs.siderolabs.com/omni/self-hosted/options-for-running-omni.md) und [Omni: Run Air-Gapped](https://docs.siderolabs.com/omni/self-hosted/run-omni-airgapped.md). Die Herstellerdokumentation ändert sich; wir prüfen die Aussagen zu Beginn jedes Projekts erneut gegen den aktuellen Stand. Zur vollständig abgeschotteten Variante siehe [Air-Gapped Kubernetes](/infrastruktur/air-gapped-kubernetes/). ## Was wir an Ihren Talos-Clustern einrichten - ### Cluster-Provisionierung Maschinen-Registrierung, Cluster-Definition, Control-Plane- und Worker-Sätze, Konfigurationspatches, Cluster-Templates unter Versionskontrolle. Auf Proxmox oder Bare Metal. - ### CNI und Basiskomponenten Cilium auf Talos wird vom Hersteller dokumentiert, mit eigenem Pfad für Omni-Cluster ([Deploy Cilium CNI](https://docs.siderolabs.com/kubernetes-guides/cni/deploying-cilium.md)). Anschließend Plattformdienste über GitOps, siehe [GitOps mit Argo CD](/leistungen/gitops-argocd/). - ### Hochverfügbarer Cluster Mindestens drei Control-Plane-Knoten: Ein Cluster mit drei Knoten toleriert laut Talos-Dokumentation den Ausfall eines Knotens; fallen zwei gleichzeitig aus, ist der Dienst komplett unterbrochen ([Talos: Disaster Recovery](https://docs.siderolabs.com/talos/v1.14/build-and-extend-talos/cluster-operations-and-maintenance/disaster-recovery.md)). - ### Backup und Restore etcd-Snapshots nach Zeitplan; Omni kann automatische etcd-Backups in S3-Speicher ablegen ([Omni: etcd Backups](https://docs.siderolabs.com/omni/cluster-management/etcd-backups.md)). Zusätzlich sichern wir die Maschinenkonfiguration und testen die Wiederherstellung. - ### Zugriff Anbindung an Ihren Identity Provider, Notzugang, Rollenmodell. - ### Hybrid und Edge Cluster über mehrere Netze mit KubeSpan, siehe [Edge- und Hybrid-Kubernetes](/infrastruktur/edge-hybrid-kubernetes/). ## Updates rollen einzeln, nicht auf einen Schlag Omni rollt Konfigurationsänderungen und Talos-Upgrades schrittweise aus. Control-Plane-Knoten kommen immer einzeln dran, und erst nach gesundem etcd geht es zum nächsten Knoten. Worker werden standardmäßig einzeln aktualisiert, mit einstellbarer Parallelität. Knoten lassen sich sperren, um eine Änderung zuerst auf wenigen Knoten zu prüfen ([Omni: Upgrade Clusters](https://docs.siderolabs.com/omni/cluster-management/upgrading-clusters.md)). Upgrades lassen sich zusätzlich an Healthchecks Ihrer Workloads binden. - Control Plane: ein Knoten nach dem anderen, erst bei gesundem etcd weiter - Worker: einzeln, Parallelität einstellbar - Knoten sperren, Änderung zuerst auf wenigen Knoten prüfen ![Aufgerolltes Ethernet-Kabel mit RJ-45-Stecker vor türkisfarbenem Hintergrund](/_astro/aufgerolltes-ethernet-kabel-stecker.Dy3CMami_Z2l5g6k.jpg) ## Migration zu Talos: neuer Cluster neben dem alten Einen bestehenden Cluster stellen wir nicht „um“, sondern bauen einen neuen Talos-Cluster neben dem alten und ziehen die Workloads um. Das ist bewusst konservativ: Das Betriebssystem der Knoten lässt sich nicht per Paketmanager ändern, Talos wird per Image installiert. 1. 01 ### Bestandsaufnahme Ergebnis: Inventar Kubernetes-Version, Distribution, CNI, Storage-Klassen, Ingress, Operatoren, Secrets-Verwaltung, Daten in Volumes, Abhängigkeiten nach außen, Hardware- und Treiberbedarf (Talos-Erweiterungen). 2. 02 ### Zielarchitektur Ergebnis: Zielbild Knotenzahl und -rollen, Netzwerk, CNI, Storage, Zugriffsmodell, Omni-Betriebsmodell laut Vergleichstabelle, Lizenzentscheidung. 3. 03 ### Pilot Ergebnis: Probebetrieb Kleiner Cluster mit repräsentativen Workloads; Test von Upgrade, Knotenaustausch, etcd-Restore und Notzugang. 4. 04 ### Plattform aufbauen Cluster, Basiskomponenten und GitOps-Struktur. Manifeste, die nur auf dem Altcluster existierten, werden in Git überführt. 5. 05 ### Gestaffelte Umschaltung Workloads in Gruppen: zuerst unkritische, zuletzt zustandsbehaftete. Für Daten in Volumes gilt ein eigener Plan (Replikation, Backup/Restore oder Anwendungs-Migration); siehe [Datenbankmigration](/daten/datenbank-migration/). 6. 06 ### Cutover und Rückfall Umschaltung über DNS oder Load Balancer; der Altcluster bleibt bis zur Abnahme unverändert, der Rückweg ist ein Zurückschalten. 7. 07 ### Abnahme Funktionstest der Anwendungen, Ausfalltests (Knoten, Control Plane), Upgrade-Probe, Restore-Test. 8. 08 ### Übergabe und Betrieb Runbooks, Einweisung; auf Wunsch Betrieb durch SKAFFON ([Managed Kubernetes](/managed-services/managed-kubernetes/)). ## Vier Punkte, die Ihr Team einplanen muss - ### Fehleranalyse ohne SSH Sie läuft über API, Logs und Metriken. Teams müssen das einüben; wir schulen bei der Übergabe. - ### Upgrades sind Pflicht Omni verlangt laut Hersteller unterstützte Talos-Versionen ([Talos Version Support Policy](https://docs.siderolabs.com/omni/getting-started/talos-version-support-policy.md)). - ### Lizenz und Herstellerbindung Talos ist offen lizenziert, Omni nicht. Die Cluster laufen auch ohne Omni weiter, die Verwaltung wäre dann anders aufzubauen. Wir dokumentieren diesen Rückweg. - ### Hardware Talos stellt Mindestanforderungen an CPU, RAM und Systemdatenträger ([Talos: System Requirements](https://docs.siderolabs.com/talos/v1.14/getting-started/system-requirements.md)); spezielle Hardware (GPU, Netzwerkkarten) braucht passende Erweiterungen. ## Talos mit SKAFFON, oder besser ein anderer Weg ### Das spricht für Talos und Omni mit uns - Sie betreiben Kubernetes auf Bare Metal, auf virtuellen Maschinen oder an verteilten Standorten. - Sie wollen Installation, Updates und Austausch der Knoten standardisieren. - Sie klären die Omni-Lizenz vor dem Projekt oder setzen Talos allein ein. ### Das spricht dagegen - Sie wollen einen Kubernetes-Dienst ohne eigenen Betrieb: Dann ist ein Managed-Angebot eines Cloud-Anbieters oft einfacher, siehe [STACKIT Managed Kubernetes](/stackit/). - Ihr Team braucht klassische Shell-Administration der Knoten und kann das nicht aufgeben. - Sie erwarten Herstellersupport für Talos oder Omni von uns: Den leistet Sidero Labs über die eigenen Verträge. - Sie wollen Omni produktiv ohne Lizenz nutzen: Das erlaubt die Lizenz nicht. ## Angrenzende Themen rund um Talos-Cluster - ### [Air-Gapped Kubernetes](/infrastruktur/air-gapped-kubernetes/) Die vollständig abgeschottete Variante. Weiter - ### [Edge- und Hybrid-Kubernetes](/infrastruktur/edge-hybrid-kubernetes/) Cluster über mehrere Netze und Standorte. Weiter - ### [Kubernetes-Beratung](/leistungen/kubernetes-beratung/) Allgemein zu Kubernetes. Weiter - ### [Alle Infrastruktur-Themen](/infrastruktur/) Überblick über die Infrastruktur-Leistungen. Weiter ## Schildern Sie uns Ihre Cluster-Umgebung Bare Metal oder VM, Standorte, Anforderungen an Offline-Betrieb: Beschreiben Sie Ihre Umgebung in einer Projektanfrage. [Projekt anfragen](/projekt-anfragen/)