Zones

Wir jonglieren heute mit etcd-Clustern, CNI-Plugins, Service Meshes und Sidecars. Wir verbringen Wochen damit, ein Overlay-Netzwerk zu debuggen, nur um eine Applikation vom “Host” zu isolieren.

Wir haben ein gewaltiges, verteiltes System gebaut – das komplexeste, das die Mainstream-IT je gesehen hat – um ein Problem zu lösen, das Solaris bereits 2004 gelöst hatte. Mit zwei Befehlen.

Was wir hatten (Solaris Zonen, ca. 2004)

Wenn du damals einen Prozess isolieren wolltest, hast du nicht “das Internet heruntergeladen”. Du hast eine Zone erstellt.

1. zonecfg: Definieren, was die Zone darf (Ressourcen, Netzwerk-Interface).
2. zoneadm boot: Starten.

Das war’s.

Du hattest echte OS-Virtualisierung. Kein eigener Kernel, aber eine komplette, saubere Isolation auf Prozess- und Netzwerkebene. Jede Zone hatte ihren eigenen Netzwerk-Stack (erinnerst du dich an Crossbow?), ihre eigenen Prozesse, ihre eigenen User.

Der Overhead? Fast null. Es war eine Kernel-Funktion. Es war so leichtgewichtig, dass man Tausende davon auf einem einzigen System laufen lassen konnte, ohne dass die Kiste ins Schwitzen kam. Es war stabil. Es war langweilig. Es hat einfach funktioniert.

Was wir heute bauen (Der Docker/K8s-Turmbau)

Und heute? Wenn wir einen Prozess isolieren wollen, starten wir eine Lawine:

1. Wir nehmen den Linux-Kernel, der nie wirklich für diese Art von Isolation gebaut wurde.
2. Wir pferchen Prozesse mittels cgroups (Ressourcen) und namespaces (Sichtbarkeit) ein – ein Flickenteppich aus Kernel-Hacks, der Zonen nachempfunden ist.
3. Wir starten einen Docker-Daemon, der als Root läuft und diese cgroups/namespaces verwaltet.
4. Wir definieren ein Dockerfile (eine Art Shell-Skript auf Valium), um ein Image zu bauen.
5. Wir laden 800 MB an “Basis-Layern” (weil jede App ja ihr eigenes Ubuntu braucht) aus einem “Hub” herunter.
6. Wir starten ein Overlay-Netzwerk (wie VXLAN, hallo NSX-Trauma!), damit die Container überhaupt miteinander reden können, weil sie ja im Host-Netzwerk sonst verloren wären.

Und weil das Managen von drei Containern schon zu kompliziert ist (weil der Daemon stirbt oder das Netzwerk klemmt), klatschen wir Kubernetes obendrauf.

Jetzt brauchen wir:

• Ein 3-Node etcd-Cluster (eine verteilte Datenbank, nur um den Zustand zu speichern).
• Einen API-Server.
• Einen Scheduler.
• Einen Controller-Manager.
• Kubelets auf jedem Node.
• Ein CNI-Plugin (weil K8s selbst keine Ahnung von Netzwerk hat).

Fazit: Vom Präzisionswerkzeug zum Cluster-Moloch

Wir haben die eleganteste, leichteste Isolationstechnologie der Welt (Solaris Zonen) ignoriert, weil, sie war halt von Sun und nicht “Hype”.

Stattdessen haben wir zehn Jahre damit verbracht, Zonen mühsam auf Linux nachzubauen (Docker), nur um dann festzustellen, dass wir einen gigantischen Cluster-Manager (Kubernetes) brauchen, um den Zoo zu verwalten, den wir gerade erst geschaffen haben.

Wir haben ein robustes Kernel-Feature ersetzt durch einen verteilten System-Moloch, der eine eigene Job-Rolle (SRE/Platform Engineer) erfordert, nur um ihn am Leben zu erhalten.

Aber hey, die YAMLs sehen cool aus.

Dieser Artikel ist der Auftakt zur Serie “Technologie-Amnäsie”. Alle Türchen findest du unter /tags/techamnesia.

Alle Artikel dieser Serie