Pods und Services klingen ähnlich, gehören aber zu verschiedenen Welten. Der eine ist ein Arbeiter, der kommt und geht – der andere ist das Schild am Gebäude.

Verwechselt werden beide, weil sie im Alltag zusammen auftreten. Immer wenn eine Anwendung Pods startet, steht ein Service davor.

Ein Pod ist die kleinste Einheit in Kubernetes und enthält einen oder mehrere Container, die sich Netzwerk und Speicher teilen. Ein Deployment hält eine gewünschte Anzahl gleicher Pods am Laufen. Pods sind bewusst kurzlebig: Bei jedem Update, bei Knotenausfall oder Neustart ersetzt Kubernetes alte Pods durch neue – und jeder neue Pod erhält eine neue Cluster-IP. Ein Webshop-Deployment verwaltet etwa drei Pods, von denen jeder Neustart mit einer frischen IP startet.

Ein Service ist dagegen eine feste Adresse für diese wechselnde Gruppe. Er besitzt eine eigene IP-Adresse und einen DNS-Namen (DNS übersetzt Namen in IP-Adressen) innerhalb des Clusters, die sich nicht ändern, solange der Service existiert. Der Service wählt seine Pods über ein Label-Selektor-Kriterium aus: Alle Pods mit einem bestimmten Label gehören zur Gruppe. Der Service „frontend“ verteilt alle Aufrufe von „frontend“ immer auf einen der gerade laufenden Pods – egal, wer gerade neu gestartet wurde.

Der Pod liefert die Arbeit, der Service liefert die Erreichbarkeit. Pod-IPs bleiben hinter dem Service verborgen; fällt ein Pod aus, wandern seine Anfragen automatisch zu den verbleibenden.

Faustregel: Pods nie direkt adressieren, sondern immer über den Service – eine Pod-IP in einer Konfiguration ist nach dem nächsten Neustart unbrauchbar.

Der Service heißt nicht Lastverteiler für Container, sondern feste Anlaufstelle vor kurzlebigen Pods.

📌 Pod · Service · Label-Selektor

📚 Cloud von Grund auf · Tag 4 von 30
#kubernetes #CloudHosting #devops