© 1933bkk/123rf.com

In der Welt der Containervirtualisierung sind die Betriebssysteme von Compute-Knoten weitgehend zu Statisten degradiert, die nicht viel mehr können als Container starten und stoppen. Talos Linux treibt das Spiel auf die Spitze und bietet ein System für Kubernetes mit unter 90 Megabyte Größe an.

Wo früher riesige Umgebungen für Automation und Orchestrierung Standard waren – Ansible, Puppet & Co. lassen grüßen – ist das Schlagwort der Stunde eher Reduktion. Logisch: Ein System, das nur Container betreiben soll, braucht kein riesiges Userland, keine zusätzlichen Dienste auf dem System und keine extravaganten Konfigurationen. Streng genommen braucht es nicht mal eine Paketverwaltung. Das gilt zumindest dann, wenn die Devise lautet, dass System nicht mehr im laufenden Betrieb zu aktualisieren. Stattdessen zieht der Admin erst alle Container davon ab und stößt danach eine Neuinstallation mit aktuellerer Software an. Ein einfacher Linux-Kernel mit der absoluten Basis-Ausstattung an Treibern in Kombination mit einer Laufzeitumgebung für Container, meist Docker-CE oder Podman, reichen für solche Szenarien völlig aus.

Die Reduktion ist dabei mehr als eine akademische Übung zum sorgsamen Umgang mit Platz auf Speichergeräten: Sie schafft den Herstellern von Linux-Distributionen viel Arbeit und Wartungsaufwand vom Hals. Sie verlagert einen gehörigen Teil des Support-Aufwands obendrein von den Linux-Anbietern zu den Herstellern der jeweiligen Programme. Denn Red Hat, Suse & Co. dürfen mit Fug und Recht behaupten, dass der Benutzer ja etwa MySQL in Containerform direkt von Oracle bekommt. Die damit anfallenden Probleme sind nach gängiger Lesart der Linux-Distributoren dann zwischen Programmhersteller und Kunde zu regeln, nicht aber zwischen Kunde und Distributor. Kurzum: Aus der Sicht der Linux-Anbieter birgt das Prinzip so viele Vorteile, dass es für große Hersteller unwiderstehlich wirkte.

Längst arbeitet Red Hat an einer Rumpfdistribution, die in Red Hat Enterprise Linux 9 (RHEL) zum Teil schon Wirklichkeit geworden ist. Suse geht es mit ALP ähnlich an. Auch Canonical plant schon ein Mini-Ubuntu. Debian ziert sich noch, dürfte aber früher oder später ebenfalls eine Mikrodistribution entwickeln, die nicht viel mehr enthält als einen Kernel und Podman oder Docker.

Radikaler Ansatz

Streng genommen hecheln selbst Distributionen wie RHEL 9 und Suses ALP schon wieder den Trends hinterher, obwohl sie – wie ALP – noch gar nicht offiziell zur Verfügung stehen. Denn längst haben die Befürworter der “Immutable IT” ihr Konzept weiterentwickelt und radikalisiert: Wo ALP oder RHEL noch SSH und eine lokale Shell vorsehen, gehen solche Ansätze davon aus, dass selbst der Login durch den Administrator auf einem entfernten System per SSH nicht mehr notwendig ist. Eine der Lösungen, die diesen Ansatz für sich auserkoren hat, ist Talos Linux. Die Distribution bringt es im installierten Zustand auf keine 90 Megabyte – anders als Ubuntu, das in der minimalen Installation schon fast 2 Gigabyte beansprucht (Abbildung 1).

Abbildung 1: Selbst eine minimale Ubuntu-Installation bringt im entpackten Zustand mehr als 2 Gigabyte auf die Platte. Talos Linux begnügt sich mit weniger als einem Zwanzigstel davon.

Talos bringt kein SSH mit, bietet keine Login-Shell an, startet dafür aber Container. Obendrein ist Talos Linux per API aus der Ferne zu steuern. So lässt sich etwa konfigurieren, wohin Logdateien zu senden sind. Dabei ist Talos keine General-Purpose-Distribution: Das Werkzeug richtet sich speziell an die Administratoren von Kubernetes-Clustern. Die stehen bisher vor der Herausforderung, dass in einem richtig konfigurierten Kubernetes-Cluster eigentlich Kubernetes mit seinem Kubelet auf den Zielsystemen den allergrößten Teil der Konfiguration beisteuert. Trotzdem brauchen die Systeme, die Compute-Knoten in Kubernetes werden sollen, eine Grundinstallation auf Linux-Basis. Grund genug, genauer hinzusehen: Was treibt die Talos-Entwickler an, welche technischen Konzepte nutzt Talos, und worauf ist bei der Verwendung zu achten?

Immutable IT

Wer das Funktionsprinzip von Talos verstehen möchte, muss sich zunächst mit dem Schlagwort der “Immutable IT” näher befassen. “Immutable” heißt aus dem Englischen übersetzt so viel wie “unveränderbar”. Die Grundidee hinter “Immutable Infrastructure” oder “Immutable IT” besteht darin, auf den einzelnen Systemen so wenig variable Komponenten wie möglich zu haben. Das Prinzip greift mittlerweile auch auf andere Dienste innerhalb des IT-Sektors über, unter anderem auf Speicher. “Immutable Storage” soll WORM-Speicher bieten, der, wenn die Daten einmal auf den Datenträger geschrieben sind, weitere Modifikationen nicht mehr erlaubt. Elemente dieses Ansatzes finden sich auch beim Immutable-Infrastructure-Konzept. Hier gilt es, ein einzelnes System einmalig mittels der RZ-internen Automation auszurollen, ihm auf eine standardisierte Art und Weise eine komplette Konfiguration mit auf den Weg zu geben und das System im Anschluss unverändert zu nutzen.

Vorläufer des Konzepts machten schon 2014 die Runde. Kristian Köhntopp, Urgestein der deutschen IT-Szene, gastierte schon damals auf Konferenzen mit der Behauptung, jedes System sei neu zu installieren, nachdem ein Administrator sich per SSH darauf eingeloggt habe. Denn dann sei nicht mehr mit absoluter Sicherheit davon auszugehen, dass das System allen Sicherheits- und Compliance-Regeln entspräche, und der Aufwand, diesen Zustand händisch wiederherzustellen, sei größer als die Neuinstallation. Obendrein wies Köhntopp darauf hin, dass der Administrator ein internes Ticket zur Fehlersuche für jeden nötigen SSH-Login auf einem System erstellen müsse. Denn das könne nur heißen: Entweder ist die Automation zu schlecht, weil sie ein technisches Problem nicht abgefangen hat, oder das zentrale Sammeln von Log- und Metrikdaten ist nicht gut genug, weil es auf Basis der Daten nicht möglich war, das Problem ohne Login auf dem System zu unterbinden. Damals, als das Private-Cloud-Rad gerade erst in Schwung kam, war Köhntopps Ansatz vielerorts als “zu radikal” und “unpraktikabel” verschrien.

Zehn Jahre später, geben Projekte wie Talos Köhntopp durchaus Recht. Die Kubernetes-Entwicklung darf bei der Betrachtung freilich nicht unter den Tisch fallen. Kubernetes versteht sich im Grunde ja als eine Art “Rechenzentrum in der Box”. Das erklärte Ziel besteht darin, die allermeisten Aufgaben, die im Rechenzentrum täglich anfallen, automatisierbar und per API steuerbar zu machen. Dazu gehören das Anlegen neuer Instanzen, das Beenden laufender Instanzen, das Hinzufügen und Entfernen von einzelnen Netzwerkkonfigurationen oder Diensten und viele weitere Arbeitsschritte. Kubernetes ist über die Jahre so komplex geworden, dass es den größten Teil der nötigen Funktionalität für das “Rechenzentrum in der Box” längst bietet. Das impliziert aber auch, dass immer mehr Funktionalität aus der eigenen Infrastruktur der Knoten auf die Kubernetes-Ebene wandert und die systemeigene Software im Gegenzug kontinuierlich “dümmer” werden kann. Talos funktioniert als sehr konkrete Umsetzung dieses Prinzips: Nach der Installation der Distribution auf einem System soll es möglich sein, die zum System gehörenden Komponenten per API aus der Ferne zwar zu steuern und so auf die Konfiguration Einfluss zu nehmen. Das System selbst ist nach der Installation jedoch kaum noch sichtbar. Stattdessen ist es Kubernetes, das alle anstehenden Aufgaben zentral für das System steuert und erledigt.

Woraus Talos besteht

Das wirft beim naturgemäß misstrauischen Administrator die Frage auf, womit er es bei Talos Linux eigentlich zu tun bekommt und welche Komponenten sich im knapp 80 Megabyte großen Abbild finden (Abbildung 2). So viel gleich vorweg: Auch Talos Linux ist eine Linux-Distribution, und der Kern des Systems ist ein Linux-Kernel. Schon der kommt seitens der Entwickler der Distribution allerdings mit einem besonderen Schutzschild daher. Denn der Talos-Kernel ist nach den Vorgaben des Kernel Self Protection Project (KSPP)konfiguriert und gebaut.

Abbildung 2: Talos Linux wirft aus Gewichtsgründen die allermeisten Standardkomponenten moderner Linux-Distributionen über Bord und ersetzt sie durch eigene Teile. Quelle: Talos Linux

KSPP ist technisch hochinteressant: Seine Macher gehen davon aus, dass es im Linux-Kernel zu jeder Zeit (kritische) Fehler gibt, deren Existenz lange unentdeckt bleibt. Sie plädieren deshalb dafür, durch spezielle Konfigurationen und die Einführung verschiedener Funktionen den Linux-Kernel gegen Sicherheitsprobleme insgesamt robuster zu machen. Selbst tatsächlich existierende Sicherheitsprobleme sollen nach dem Willen der KSPP-Leute nicht zwangsläufig zu ausnutzbaren Sicherheitslücken führen. Dafür bekommen interessierte Administratoren einiges an die Hand: Eine Liste der Kernel-Einstellungen mit Empfehlungen des KSPP-Projekts etwa. Sparsamkeit ist dabei die oberste Grundregel: Treiber, die im System nicht vorhanden sind, bieten auch kein Einfallstor. Weil er entsprechend der KSPP-Regeln gebaut ist, kommt der Talos-Kernel schlank daher. Enthalten sind zwar die allermeisten Treiber für moderne Hardware; viel weiteren Schnickschnack sollten Admins jedoch nicht erwarten. Wozu auch? Weil es auf einem Talos-Linux-System ohnehin keinen Weg gibt, sich per SSH einzuloggen, ist das Nachladen irgendwelcher Kernel-Treiber gar nicht vorgesehen – und insbesondere dann nicht, wenn diese sich in Kubernetes nicht mal sinnvoll verwenden lassen.

Aus Sicht des Administrators viel interessanter als der Betriebssystem-Kernel sind ohnehin die zu Talos gehörenden weiteren Kern-Komponenten. Die eigentlichen zentralen Komponenten in Talos Linux aber, also alles, was das System am Laufen hält, sind eine echte Talos-Eigenentwicklung. Das zeigt sich schon daran, dass sich in Talos praktisch keine der bekannten System-Dienste anderer Distributionen wie Systemd finden. Und alles, was Talos doch enthält, fußt unter der Haube auf Go und stammt von Sidero Labs, der Firma hinter Talos Linux.

Fester Bestandteil jeder Talos-Installation ist beispielsweise der »apid«. Er bietet einen gRPC-Endpunkt für jeden einzelnen Talos-Knoten und ermöglicht über diesen das Einspielen einer knoten-spezifischen Konfiguration. Auf der Userland-Seite gibt es ein Gegenstück namens »talosctl«, mit dem der Administrator direkt mit »apid« auf jedem Talos-Knoten kommuniziert und den einzelnen Daemon-Instanzen Befehle mit auf den Weg gibt.

Keine Spur von Systemd

Der Init-Prozess ist bekanntlich jener Prozess in einem Linux-System, den der Linux-Kernel startet und an den er dann die Kontrolle über das gesamte System abgibt. Auf praktisch allen heutigen Distributionen ist der Init-Prozess Systemd. Auch RHEL 9 oder ALP von Suse kommen mit Systemd, nicht zuletzt vermutlich, weil beide Distributoren erheblichen Entwicklungsaufwand in Systemd gesteckt haben. Gleichzeitig war Systemd wegen seiner umfassenden Art, sämtliche Prozesse des Systems unter die eigene Kontrolle bringen zu wollen, in der Vergangenheit regelmäßig ein Zankapfel innerhalb der Linux-Community. Da wirkt es einerseits fast schon revolutionär und andererseits verständlich, dass man bei Talos Linux von Systemd nicht viel hält und die Komponente kurzerhand durch eine eigene Variante des Init-Prozesses ersetzt.

Der heißt »machined« und fungiert in Talos Linux als Init-Prozess. Der Kernel bekommt »machined« also als Parameter für init= mit auf den Weg. Freilich bietet »machined« nicht annähernd so viele Möglichkeiten wie Systemd. Im Fokus steht stattdessen, alle nötigen Dienste für den Talos-Betrieb wie »apid« zu starten und ansonsten die Funktionalität der OCI-kompatiblen Laufzeitumgebung für Container zu garantieren. Die immerhin bringt Talos in Form von Containerd mit, einer gut etablierten und bekannten Laufzeit, die auf anderen Distributionen durchaus zum Einsatz kommt und eng mit Kubernetes verdrahtet ist. Zur Seite steht »machined« in Talos obendrein der »udevd«, dabei handelt es sich allerdings nicht um die Variante aus dem Systemd-Universum. Stattdessen forkten die Talos-Entwickler »eudev«, den Daemon, der in Gentoo Linux die Verwaltung der Geräte im »dev/«-Verzeichnis verantwortet.

Für jene Knoten einer Installation, auf denen die Kubernetes-Kontrollknoten laufen, rollt Talos zudem noch eine Komponente namens »trustd« aus. Die etabliert eine PKI zwischen den Talos-Knoten und sorgt für eine Vertrauensstellung zwischen den einzelnen Systemen, damit diese beispielsweise Befehle per »apid« untereinander austauschen können. Damit ist das Schaulaufen der Komponenten von Talos Linux bereits beendet: Mehr als die fünf oder sechs beschriebenen Dienste braucht es nicht, um das gesamte Feature-Set von Talos abzurufen.

Der Talos-Workflow

Wer sich als passionierter Linux-Administrator zum ersten Mal mit Talos beschäftigt, kommt sich in gewisser Weise wie im Märchenland vor: Viele bekannte Prozesse und Prozeduren funktionieren hier nämlich fundamental anders als in klassischen Linux-Distributionen. Das geht schon bei der Installation des Systems los. Die Autoren bieten zwar auch ISO-Abbilder an, bevorzugen jedoch offensichtlich die Installation per TFTP und PXE über das Netz. Zumindest ein paar Infrastruktur-Dienste sind aus Sicht des Administrators also nötig: Ein TFTP-Server und ein DHCP-Server allein genügen aber noch nicht. Auch der Einsatz von NTP ist praktisch erforderlich. Obendrein benötigt der Administrator für jedes System, das Talos Linux nutzen soll, eine eigene Konfigurationsdatei. In dieser hinterlegt er alle zentralen Konfigurationseinstellungen der jeweiligen Maschine. Und schnell stellt sich heraus, dass der Absolutheitsanspruch von Talos Linux bezüglich der Kontrolle seiner Umgebung noch weit über das hinausgeht, was Administratoren an Systemd regelmäßig nicht mögen.

Dahinter steckt Kalkül: Die PXE-Methode beispielsweise lässt sich relativ schnell aufsetzen und zugleich mit generischen Abbildern direkt vom Hersteller nutzen. Weil obendrein ohnehin nicht vorgesehen ist, dass es auf den jeweiligen Maschinen lokale Veränderungen gibt, kann eine zentral auf einem Server für eine Instanz hinterlegte Konfigurationsdatei alle nötigen Parameter enthalten. Per »talosctl« lässt sich eine Maschine auf Wunsch neu starten oder in die Neuinstallation per PXE schicken, etwa dann, wenn auf dem System selbst etwas schief gelaufen ist. Sobald Talos einmal ausgerollt ist, konfiguriert das System die verbliebenen nötigen Dienste automatisch. Handelt es sich um einen Controller-Knoten für K8s, rollt Talos automatisiert sämtliche Kubernetes-Komponenten im System aus, freilich in Form von Containern. Dabei lässt das System dem Administrator weitgehend freie Wahl hinsichtlich der zu nutzenden Komponenten, etwa bezüglich des CNI-Plugins für Kubernetes. Ebenso zur Laufzeit konfiguriert der Admin die einzelnen Talos-Instanzen selbst, eben wieder mit »talosctl«, über das er Knotenspezifische Konfigurationsdateien einspielt und aktiviert. Immutable hingegen ist bei Talos praktisch das gesamte Dateisystem zur Laufzeit.

Eine eigene Image-Factory

Umsteigewilligen Talos-Neulingen macht Sidero Labs es übrigens angenehm leicht: Der Anbieter stellt im Netz eine Image-Factory (Abbildung 3) zur freien Verfügung, mit deren Hilfe sich ISO-Images, Abbilder für PXE-Boot, Images für den Betrieb in der Cloud und für diverse andere Anlässe maßgeschneidert bauen lassen. Hier greift einmal mehr die “Frugal-First”-Doktrin, also Talos’ Lehre der weitgehenden Sparsamkeit: Während andere Hersteller ihre Distributions-Kernel mit einem Feuerwerk aus Treibern ausrüsten, damit sich Dienste wie DRBD oder Nvidia-GPUs nutzen lassen, fehlen diese in den Talos-Standard-Abbildern samt und sonders. Wer sie braucht, klickt sich stattdessen per Image-Factory auf der Talos-Website [1] passende Abbilder zusammen. Secure Boot-Unterstützung fehlt in den Standard-Images gleichfalls, lässt sich aber per Mausklick hinzufügen. Obendrein stehen fertige Abbilder von Talos für die Verwendung auf den meisten Einplatinen-Computern zur Verfügung, etwa für den Raspberry Pi. Auch im Kontext eines Homelab lässt sich Talos damit einfach nutzen und empfiehlt sich so für diesen Einsatzzweck.

Abbildung 3: Die Image Factory von Talos gibt Admins die Möglichkeit, sich maßgeschneiderte Abbilder der Distribution zu bauen, die auch Zusatzkomponenten wie die kommerziellen Nvidia-Treiber enthalten können.

Einfache Aufgaben, kompliziert zu erledigen

Wer sich erstmals mit Talos befasst, gerät schnell ins Schwärmen ob der Architektur der Lösung und ihrer vermeintlichen Klarheit und Stromlinienform. Ein in sich unveränderliches System, das sich per API von außen steuern und vollständig kontrollieren lässt – das macht Lust auf mehr. Noch dazu, wenn sich für Talos die gesamte Konfiguration als Infrastructure-as-Code hinterlegen und mithin in Github verwalten lässt.

Zur Wahrheit gehört aber: Die fehlende Möglichkeit, sich flott auf einem System einzuloggen und Dinge selbst nachzuvollziehen, gerät im Falle von Schwierigkeiten zur nervtötenden Angelegenheit. Das erfährt schnell, wer durch die Talos-Doku pflügt um herauszufinden, wie zentralisiertes Logging und das zentralisierte Sammeln von Metrikdaten hier überhaupt funktionieren sollen. Beim Logging tut sich schon fast ein Abgrund auf: Talos nämlich unterscheidet zwischen den Logdateien der eigenen Dienste, Kernel-Logs und den Diensten, die die per Container gestarteten Zusatzdienste erzeugen. Für Talos selbst lässt sich ein Log-Ziel in der Talos-Konfiguration des Knotens definieren, an den Talos im Anschluss Logdateien per UDP oder TCP im Json-Format schickt. Damit kann dann zum Beispiel Grafana arbeiten. Auch die Kernel-Logs lassen sich auf diese Art und Weise per JSON woandershin exportieren.

Abbildung 4: Es fühlt sich wie eine Sisyphos-Aufgabe an, Logdateien sinnvoll aus Talos zu extrahieren. Das Beispiel für Filebeat zeigt, wie eine Lösung aussehen kann.

Deutlich kniffliger entwickelt sich die Angelegenheit, wenn zusätzliche Logdateien aus K8s-Diensten an einen Logging-Host zu senden sind, etwa jene von Kubelet. Dafür setzt Talos auf Filebeat (Abbildung 4), Fluentd oder Vector, die es aber allesamt erst per eigener Talos-Konfiguration einzurichten gilt. Dabei immerhin lässt sich der Pfad auf dem Zielsystem in /var/log angeben, von dem die gewünschten Logs einzusammeln sind. Es gilt jedoch: Was sich über die verschiedenen Log-Mechanismen an Infos nicht aus dem System kitzeln lässt, ist auf anderem Wege schlicht nicht zugänglich. Solange alles klappt wie geplant, macht das nichts, kommt es aber zu Fehlfunktionen oder Schwierigkeiten, ist direktes Debugging unmöglich.

Abbildung 5: Nicht nur lässt Prometheus sich nicht einfach auf Talos ausrollen – wer das tun will, muss erstmal mühsam die Default-Pod-Definitionen aufweichen, weil der Node Exporter sonst erst gar nicht starten kann.

Zudem fehlt es der Einbindung von Talos-Instanzen in Monitoring-Systeme wie Prometheus ebenso an Komfort. Der Prometheus Node Exporter etwa, der zentrale Metrikdaten des physischen Systems einsammelt, ist vom Administrator zunächst mühsam händisch per »talosctl« in das Setup zu integrieren. Dazu muss im Regelfall zudem das Sicherheitsframework von Talos leicht aufgebohrt werden, weil dem Exporter sonst der Zugriff auf die Hardwarekomponenten fehlt, die er überwachen möchte (Abbildung 5). Generell fällt auf, dass das Thema Observability bei der Entwicklung von Talos wohl nicht im Fokus steht. Hier gibt es an einigen Stellen Luft nach oben. Dass es komplex ist, notwendige Informationen aus Talos-Systemen zu extrahieren, an die man aber sonst erst gar nicht herankäme, drückt im Hinblick auf das ansonsten sehr coole Produkt merklich auf die Stimmung.

Fazit: Gemischte Gefühle

Wer sich mit Talos Linux befasst, muss sich zunächst vor Augen halten, wer die Zielgruppe dieser Linux-Distribution ist und worauf sie eigentlich ausgelegt ist. Talos will ganz klar eine perfekte Distribution für den Betrieb von Systemen sein, deren Kernaufgabe darin besteht, Teil eines Kubernetes-Clusters zu sein. Für diesen sehr engen Use Case ist der größte Teil der Standardkomponenten, die sich auf Linux-Systemen sonst finden, schlicht nicht nötig. Dass Talos sie weglässt, ist folgerichtig. Jeden Gedanken, Talos als Linux-Distribution für Aufgaben außerhalb des Kubernetes-Kontexts zu verwenden, sollten Administratoren schnell wieder verwerfen. Hier wäre es allenfalls möglich, eine eigene Distribution als Talos-Fork zu entwickeln, die andere Prioritäten setzt und bei anderen Themen brilliert. Als General-Purpose-Distribution jedenfalls eignet Talos sich zweifelsohne nicht.

Obendrein müssen die Talos-Entwickler sich die Frage gefallen lassen, ob Talos nicht an manchen Stellen etwas zu viel Abstraktion bietet und die Dinge zu kompliziert gestaltet. Dass sich per »talosctl« die Netzwerkkonfiguration eines Talos-Knotens aus der Ferne ändern lässt, ist auf der einen Seite zwar technisch cool. Wieso dieses Prozedere aber besser sein soll als das Ändern einer Network-Manager-Datei per Ansible, erschließt sich dem versierten Beobachter nicht. Der vollständige Verzicht auf SSH zwingt den Administrator obendrein dazu, sich auf die Talos-Art einzulassen, um Aufgaben zu erledigen. So geraten die Konfiguration für Monitoring, Alerting und Trending ebenso wie die für zentralisiertes Logging schnell zur nervenden Fleißarbeit.

Im Gegenzug erhält der Administrator eine auf das absolute Minimum reduzierte Linux-Distribution, deren Angriffsvektor deutlich kleiner sein dürfte als selbst jener von Linux-Distributionen, die sich als besonders sicher anpreisen. Wer Kubernetes auf dem Radar hat und kennenlernen möchte, sollte Talos Linux ruhig ausprobieren und ausgiebig testen. Gerade am Beginn der Evaluation dürfte einiger Frust aber programmiert sein. (jcb)