Das passende Training Kubernetes Einführung Training – 3 Tage Praxis mit Live-Cluster
Alles in einen Pod? Dann hättest du bei einem Server bleiben können
Ganz ehrlich: Die Frage “Wie viele Container gehören in einen Pod?” hat eine kurze Antwort. Einer, der die Arbeit macht. Dazu höchstens ein paar Helfer, die ohne ihn keinen Sinn ergeben. Alles andere kommt in eigene Pods.
Klingt simpel. Ist es auch. Und trotzdem sehe ich regelmäßig das Gegenteil.
Der Pod als Sammelbehälter
Bei einem großen Konzern habe ich erlebt, dass einfach alles in einen Pod reingeschmissen wurde. Nicht aus Bosheit, sondern weil es geht: Kubernetes lässt dich so viele Container in einen Pod packen, wie du willst. Es läuft ja.
Nur: Alle Container eines Pods landen zwangsläufig auf derselben Maschine. Und keiner davon lässt sich unabhängig von den anderen skalieren. Damit hast du genau die Vorteile weggeworfen, für die du Kubernetes überhaupt eingeführt hast. Du hast ein Orchestrierungssystem gekauft und benutzt es wie einen einzelnen Server. Mit mehr YAML.
Ein Pod ist eine Schicksalsgemeinschaft
Was ein Pod technisch ist, passt in drei Sätze. Alle Container darin laufen auf derselben Node. Sie teilen sich eine IP-Adresse und erreichen sich über localhost. Und sie hängen am selben Lebenszyklus: Der Pod wird als Ganzes geplant, als Ganzes ausgerollt, als Ganzes vervielfacht.
Das ist kein Konstruktionsfehler, das ist Absicht. Genau diese enge Kopplung macht Helfer-Container so praktisch. Aber sie ist eben auch der Grund, warum du nicht deine ganze Anwendung da reinstopfen willst.
Was du wegwirfst, wenn du alles reinpackst
Erstens die Skalierung. Drei Replicas von einem Pod mit App, Datenbank und Cache heißen drei Apps, drei Datenbanken, drei Caches. Auch wenn nur die App mehr Last hat.
Zweitens die Rollouts. Ein neues App-Image? Dann rollt Kubernetes den ganzen Pod neu aus, samt Datenbank-Container, der sich gar nicht geändert hat. Stürzt ein Container ab, startet das Kubelet ihn zwar einzeln neu. Aber ausrollen oder vervielfachen kannst du ihn nur im Paket.
Drittens den Scheduler. Der ist das Beste an Kubernetes: Er verteilt deine Pods dahin, wo Platz ist. Ein Pod, der alles enthält, braucht auf einer Node Platz für alles. Der Scheduler kann nichts mehr verteilen, weil du ihm nichts zum Verteilen gelassen hast.
Woher dieses “alles rein” kommt, merke ich in fast jedem Einführungstraining. Ein Teilnehmer hatte sich gemerkt, ein Pod müsse einer eigenen Cloud-Instanz entsprechen, und war verwirrt, wie das auf seinem Laptop laufen soll. Ein anderer fragte, ob ein Pod gleichzeitig auf mehreren Nodes laufen kann. Beides derselbe Kurzschluss: Pod gleich Maschine. Wer so denkt, packt in den Pod alles rein, was früher auf den Server kam.
Wann mehrere Container richtig sind
Es gibt sie, die guten Gründe für einen zweiten Container. Ein Log-Shipper, der die Ausgabe der App wegschickt. Ein Proxy, der vor der App sitzt. Ein Vault-Agent, der Secrets holt und erneuert, so zeige ich das im Training: ein Init-Container holt das Secret einmalig beim Start, ein Sidecar erneuert es dauerhaft, und die App weiß von beidem nichts.
Die Regel dahinter: Der Helfer hat ohne den Hauptcontainer keinen Zweck. Er skaliert mit ihm, lebt mit ihm, stirbt mit ihm. Passt das auf deine Datenbank? Eben.
| Fakt | Wert | Quelle |
|---|---|---|
| Grenzwerte, für die Kubernetes ausgelegt ist | höchstens 110 Pods pro Node, 5.000 Nodes, 150.000 Pods und 300.000 Container pro Cluster | Kubernetes-Doku, “Considerations for large clusters”, Stand v1.37 |
| Sidecar-Container als eigenes Konzept | eingeführt mit 1.28, standardmäßig aktiv seit 1.29, stabil seit 1.33 (Init-Container mit restartPolicy: Always) | Kubernetes-Doku, “Sidecar Containers” |
| Was die Doku selbst zu mehreren Containern sagt | “Grouping multiple co-located and co-managed containers in a single Pod is a relatively advanced use case. You should use this pattern only in specific instances in which your containers are tightly coupled.” | Kubernetes-Doku, “Pods” |
Die Doku sagt es also selbst, nur höflicher als ich.
Meine klare Ansage
Ein Container macht die Arbeit. Ein paar Helfer dürfen dazu, wenn sie ohne ihn nutzlos sind. Datenbank, Cache, Frontend, Backend: eigene Pods, eigene Deployments, dazwischen Services. Erst dann kann Kubernetes das tun, wofür du es dir geholt hast: verteilen, skalieren, einzeln ausrollen.
Wenn du beim Anlegen eines Pods merkst, dass du gerade deinen alten Server nachbaust, halt kurz an. Genau an diesem Punkt trennen sich in meinem Training “Kubernetes Einführung” die, die Kubernetes benutzen, von denen, die es nur installiert haben.