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.
- Talos: Mozilla Public License 2.0
- Omni: Business Source License 1.1
- Neuer Cluster neben dem alten
01Ausgangslage
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.
02
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.
03
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). Talos steht unter der Mozilla Public License 2.0 (Talos auf GitHub).
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).
- Keine Shell, kein SSH, Verwaltung per API (mTLS)
- Unveränderliches SquashFS-Image
- Omni: Cluster erstellen, Updates, Zugriff per Identity Provider
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). Diese Notzugänge gehören in jedes Betriebskonzept und werden von uns getestet.
04Lizenz
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).
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). Das hat zwei Folgen:
- 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.
- 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).
05
Sechs Betriebsmodelle für Omni im Vergleich
Laut Hersteller wird Omni in diesen Modellen betrieben. Die Spalte „Lizenz“ gilt für Produktivnutzung.
| 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) | 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 und Omni: Run Air-Gapped. 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.
06
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). Anschließend Plattformdienste über GitOps, siehe GitOps mit Argo CD.
-
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).
-
Backup und Restore
etcd-Snapshots nach Zeitplan; Omni kann automatische etcd-Backups in S3-Speicher ablegen (Omni: etcd Backups). 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.
07
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). 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
08
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.
- 01
Bestandsaufnahme
Ergebnis: InventarKubernetes-Version, Distribution, CNI, Storage-Klassen, Ingress, Operatoren, Secrets-Verwaltung, Daten in Volumes, Abhängigkeiten nach außen, Hardware- und Treiberbedarf (Talos-Erweiterungen).
- 02
Zielarchitektur
Ergebnis: ZielbildKnotenzahl und -rollen, Netzwerk, CNI, Storage, Zugriffsmodell, Omni-Betriebsmodell laut Vergleichstabelle, Lizenzentscheidung.
- 03
Pilot
Ergebnis: ProbebetriebKleiner Cluster mit repräsentativen Workloads; Test von Upgrade, Knotenaustausch, etcd-Restore und Notzugang.
- 04
Plattform aufbauen
Cluster, Basiskomponenten und GitOps-Struktur. Manifeste, die nur auf dem Altcluster existierten, werden in Git überführt.
- 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.
- 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.
- 07
Abnahme
Funktionstest der Anwendungen, Ausfalltests (Knoten, Control Plane), Upgrade-Probe, Restore-Test.
- 08
Übergabe und Betrieb
Runbooks, Einweisung; auf Wunsch Betrieb durch SKAFFON (Managed Kubernetes).
09
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).
-
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); spezielle Hardware (GPU, Netzwerkkarten) braucht passende Erweiterungen.
10
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.
- 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.
11
Angrenzende Themen rund um Talos-Cluster
-
Air-Gapped Kubernetes
Die vollständig abgeschottete Variante.
-
Edge- und Hybrid-Kubernetes
Cluster über mehrere Netze und Standorte.
-
Kubernetes-Beratung
Allgemein zu Kubernetes.
-
Alle Infrastruktur-Themen
Überblick über die Infrastruktur-Leistungen.
Schildern Sie uns Ihre Cluster-Umgebung
Bare Metal oder VM, Standorte, Anforderungen an Offline-Betrieb: Beschreiben Sie Ihre Umgebung in einer Projektanfrage.