Flatcar Container Linux: Die sichere Basis für Kubernetes-Nodes

Ein Kubernetes-Node hat eine überschaubare Aufgabe. Er startet Container, meldet sich beim Cluster und tut sonst möglichst wenig. Trotzdem laufen die meisten Nodes, die wir in Bestandsumgebungen sehen, auf einer allgemeinen Server-Distribution: mit Paketmanager, ein paar hundert installierten Paketen, einem Golden Image pro Umgebung und einem Update-Prozess, der irgendwo zwischen „monatlich per Skript“ und „wenn jemand Zeit hat“ liegt.

Das funktioniert, bis es nicht mehr funktioniert. Nach einem Jahr sind sich keine zwei Nodes mehr ganz gleich, und niemand kann genau sagen, warum.

Flatcar Container Linux ist die Gegenthese: ein Betriebssystem, das nur Container ausführen soll und sich im Betrieb nicht verändern lässt.

Herkunft

Flatcar ist der Nachfolger von CoreOS Container Linux. Das Berliner Unternehmen Kinvolk startete es 2018 als Fork, kurz nachdem Red Hat CoreOS übernommen hatte. Als Container Linux 2020 eingestellt wurde, war Flatcar der naheliegende Weg für alle, die dabei bleiben wollten. Kinvolk gehört heute zu Microsoft, Flatcar selbst ist seit 2024 ein Incubating-Projekt der CNCF und damit nicht mehr an einen einzelnen Hersteller gebunden. Für eine souveräne Plattform ist das kein Detail.

Was Flatcar anders macht

Das Image enthält nur, was zum Betrieb von Containern nötig ist. Einen Paketmanager gibt es nicht. Wer zum ersten Mal apt oder dnf eintippt und eine Fehlermeldung bekommt, hält das für eine Einschränkung. Es ist aber der eigentliche Punkt: Was nicht installiert ist, muss weder gepatcht noch auditiert werden.

Das System selbst liegt auf einer schreibgeschützten /usr-Partition. Daneben gibt es eine zweite, gleich große Partition. Ein Update schreibt das neue, vollständige Image dorthin, und beim nächsten Neustart bootet der Node die neue Version. Startet sie nicht sauber, bootet er wieder die alte. Es gibt also keine halb installierten Updates und keine Pakete in gemischten Versionen. Ein Node läuft entweder auf Version A oder auf Version B.

Konfiguriert wird der Node genau einmal, beim ersten Start, durch Ignition. Ignition liest eine deklarative Beschreibung im JSON-Format, legt Benutzer, Dateien und systemd-Units an und ist dann fertig. Danach wird der Node nicht mehr von Hand verändert. Braucht man etwas anderes, baut man einen neuen.

Zusätzliche Software, die wirklich auf dem Host laufen muss, kommt als System-Extension (sysext): ein Image, das beim Start über /usr gelegt wird, ebenfalls schreibgeschützt.

Ein Node als Konfiguration

Ignition-JSON schreibt niemand von Hand. Man beschreibt den Node in Butane, einem lesbaren YAML-Format, und übersetzt es mit butane nach Ignition:

variant: flatcar
version: 1.0.0
passwd:
  users:
    - name: core
      ssh_authorized_keys:
        - ssh-ed25519 AAAAC3Nza... [email protected]
storage:
  files:
    - path: /etc/flatcar/update.conf
      mode: 0644
      contents:
        inline: |
          GROUP=stable
          SERVER=https://updates.example.de/v1/update/
          REBOOT_STRATEGY=off

butane --strict < node.bu > node.ign

Das Beispiel hinterlegt einen SSH-Schlüssel für den Notfall und richtet den Update-Kanal ein. Zwei Zeilen darin verdienen eine Erklärung.

SERVER zeigt auf einen eigenen Update-Server. Flatcar verwendet dafür Nebraska, das sich selbst betreiben lässt. Damit entscheiden Sie, wann welche Nodes welche Version bekommen, und die Plattform funktioniert auch in Umgebungen ohne Internetzugang. Zur Auswahl stehen die Kanäle Stable, Beta, Alpha und LTS.

REBOOT_STRATEGY=off verhindert, dass der Node nach einem Update auf eigene Faust neu startet. In einem Kubernetes-Cluster soll das ein Operator koordinieren, der Nodes nacheinander leert, neu startet und wieder freigibt. Sonst starten im ungünstigsten Fall alle Nodes gleichzeitig neu.

Flatcar unter Kubermatic

In der Praxis schreiben wir diese Konfiguration selten selbst. Die Kubermatic Kubernetes Platform unterstützt Flatcar als Node-Betriebssystem und erzeugt die Ignition-Konfiguration für jeden Node über ihren Operating System Manager. Anpassungen, etwa eigene CA-Zertifikate oder ein interner Update-Server, hinterlegt man einmal zentral in einem Operating System Profile.

Welche Infrastrukturen mit Flatcar unterstützt werden, hängt von der KKP-Version ab. In der Support-Matrix für Version 2.27 sind unter anderem OpenStack, VMware vSphere, VMware Cloud Director und KubeVirt aufgeführt. Für die Portabilität ist das der eigentliche Gewinn: Bei jedem Anbieter läuft dasselbe Betriebssystem in derselben Version, konfiguriert aus derselben Quelle. Golden Images pro Plattform entfallen.

Was sich für das Betriebsteam ändert

Wir wollen nicht verschweigen, dass Flatcar eine andere Arbeitsweise verlangt. Wer gewohnt ist, sich bei Problemen per SSH auf einen Node einzuloggen und dort ein Diagnosewerkzeug nachzuinstallieren, wird das anfangs vermissen. Monitoring-Agenten, Log-Shipper und Security-Werkzeuge laufen als DaemonSet im Cluster, nicht als Paket auf dem Host. Das ist ohnehin die sauberere Lösung, verlangt aber Umgewöhnung.

Updates bedeuten Neustarts. Damit das ohne Ausfall geht, müssen die Anwendungen es vertragen, dass ihre Pods auf andere Nodes umziehen, und PodDisruptionBudgets müssen sinnvoll gesetzt sein. Eine Plattform, die das nicht aushält, hat ein Problem, das unabhängig vom Betriebssystem besteht. Flatcar macht es nur früher sichtbar.

---

Für Kubernetes-Nodes sehen wir wenig Gründe, an einer allgemeinen Server-Distribution festzuhalten. Flatcar ist minimal, unveränderlich, aktualisiert sich atomar und kann zurückrollen. Als CNCF-Projekt mit selbst betreibbarem Update-Server passt es außerdem zu dem, was wir unter Souveränität verstehen: Kontrolle über jede Schicht der Plattform, auch die unterste.