Schema eines Kubernetes-Clusters: mehrere Rechenknoten, auf denen jeweils Pods liegen; jeder Pod umschließt einen oder zwei Container und teilt sich eine Netzwerkadresse; ein Scheduler ordnet neue Pods den Knoten zu.

Pod

Ein Pod ist die kleinste Einheit, die man in Kubernetes starten kann: eine oder mehrere eng zusammengehörende Anwendungen, die sich Netzwerk und Speicher teilen. In der KI-Welt meint „Pod" außerdem einen großen Verbund von Google-Rechenchips, der wie ein einziger Supercomputer arbeitet.

Große Internetdienste laufen nicht auf einem einzelnen Computer, sondern auf tausenden Rechnern in einem Rechenzentrum. Damit das beherrschbar bleibt, packt man Programme in abgeschlossene Pakete, sogenannte Container. Ein Container enthält ein Programm samt allem, was es zum Laufen braucht, und funktioniert deshalb auf jedem Rechner gleich. Ein Pod ist die Verpackung um einen oder mehrere solcher Container herum. Die Software Kubernetes, die solche Rechnerflotten automatisch verwaltet, startet und stoppt niemals einzelne Container, sondern immer nur ganze Pods. Verwirrend ist: In Meldungen über KI-Chips bedeutet dasselbe Wort etwas anderes, nämlich einen großen zusammengeschalteten Verbund von Rechenchips.

Warum Kubernetes nicht einzelne Container verwaltet

Manche Programme gehören untrennbar zusammen. Ein Webserver braucht zum Beispiel oft ein zweites kleines Programm daneben, das seine Protokolldateien einsammelt und weiterschickt. Diese beiden Teile auf verschiedene Rechner zu verteilen wäre unsinnig. Der Pod garantiert, dass sie immer gemeinsam auf derselben Maschine landen.

Alle Container in einem Pod teilen sich außerdem eine Netzwerkadresse und können sich gemeinsame Speicherbereiche teilen. Sie erreichen einander deshalb so einfach, als liefen sie auf demselben Laptop. Nach außen tritt der Pod dagegen als eine einzige Einheit auf. Das macht die Regeln für Netzwerk und Zugriffsrechte deutlich übersichtlicher.

Ein Pod ist bewusst kurzlebig gedacht. Fällt ein Rechner aus, wird der Pod nicht repariert, sondern gelöscht und anderswo neu gestartet. Man behandelt ihn also wie einen Einwegbecher, nicht wie eine Lieblingstasse. Wichtige Daten gehören deshalb nie in den Pod selbst, sondern in eine angebundene Datenbank oder einen dauerhaften Speicher.

Vom Wunschzustand zum laufenden Pod

Entwickler beschreiben in einer Textdatei, was laufen soll: welches Container-Abbild, wie viel Arbeitsspeicher, wie viele Kopien. Diese Datei beschreibt einen Wunschzustand, keine Befehlsliste. Kubernetes vergleicht dann laufend den Wunschzustand mit der Realität und gleicht Unterschiede aus.

Ein Bestandteil namens Scheduler sucht für jeden neuen Pod einen passenden Rechner. Er prüft, wo genug Arbeitsspeicher und Rechenleistung frei sind. Braucht ein Pod einen Grafikchip fürs KI-Rechnen, kommen nur Rechner mit solchen Chips infrage. Danach startet ein Dienst auf dem gewählten Rechner die Container des Pods.

Stürzt ein Pod ab, bemerkt das System die Abweichung vom Wunschzustand und startet Ersatz. Steigt die Last, kann es automatisch weitere Kopien desselben Pods hochfahren. Diese Selbstheilung ist der eigentliche Grund für den Aufwand. Ein Mensch müsste sonst nachts aufstehen, um abgestürzte Programme neu zu starten.

Pods bei Cloud-Anbietern und in KI-Rechenzentren

Fast jeder große Onlinedienst läuft heute in Pods, ohne dass Nutzer davon etwas merken. Amazon, Google und Microsoft bieten Kubernetes als fertigen Dienst an. Wer dort ein Konto hat, bezahlt am Ende für die Rechenzeit, die seine Pods verbrauchen. In Stellenanzeigen für DevOps- oder Cloud-Jobs ist Kubernetes-Erfahrung deshalb eine Standardanforderung.

Auch KI-Modelle werden meist in Pods betrieben. Ein Pod enthält dann das Modell und belegt einen oder mehrere Spezialchips. Wird ein Chatbot stark genutzt, startet der Anbieter einfach mehr Pods davon.

Die zweite Bedeutung begegnet einem in Nachrichten über Rechenzentren. Google nennt einen Verbund seiner KI-Chips, der Tensor Processing Units, ebenfalls Pod. Ein solcher TPU-Pod besteht aus tausenden Chips, die mit sehr schnellen Leitungen verbunden sind und gemeinsam ein großes Modell trainieren. Mit Kubernetes hat das nichts zu tun. Welche Bedeutung gemeint ist, erkennt man am Zusammenhang: Geht es um Software-Betrieb oder um Hardware im Rechenzentrum?

Subscribe free. Unsubscribe the second it sucks.

High-signal news across AI, business, UX, and tech. Every morning.