Mitglied werden – KI-Tutor mit vollen Antworten

Training Module

Kubernetes Pod-Fundamentals — Pause-Container, Multi-Container-Muster & Labels

In diesem 120-Minuten-Modul öffnet ihr den Pod, den ihr im Einführungsmodul bereits gestartet habt, und schaut nach, was darin wirklich passiert. Los geht es mit dem unsichtbaren Pause-Container, den Kubernetes vor jedem eigenen Container startet, um die IP-Adresse des Pods sowie die Linux-Namespaces (Netzwerk, IPC, UTS) über Neustarts des Hauptcontainers hinweg stabil zu halten – und der Abgrenzung, wann ein zweiter Container tatsächlich in denselben Pod gehört. Im Hands-on baut ihr einen Sidecar-Container zur Log-Sammlung: Haupt- und Sidecar-Container teilen sich ein emptyDir-Volume, und ihr bestätigt live per kubectl logs -c, dass der Sidecar die vom Hauptcontainer geschriebenen Zugriffsprotokolle tatsächlich sieht. Eine eigene Übung ergänzt einen Init-Container, der eine Log-Datei vorbereitet, bevor die Hauptcontainer überhaupt starten. Danach ordnet ihr den Pod-Lifecycle korrekt ein: die fünf Phasen Pending/Running/Succeeded/ Failed/Unknown, das Neustartverhalten über restartPolicy und den Graceful-Shutdown-Ablauf SIGTERM → Gnadenfrist → SIGKILL bei kubectl delete pod. Zum Abschluss steht Labels und Annotations als aktive Steuerungssprache des Clusters auf dem Programm, mit einer eigenständigen Übung zu beiden Selektor-Arten: Label-Selektoren (-l, gleichheits- und mengenbasiert) für eure eigenen Labels, und Field-Selektoren ( –field-selector) für automatische Systemfelder wie metadata.name oder status.phase. Voraussetzung ist das Modul “Kubernetes Einführung” – die komplette Session läuft vollständig lokal über Minikube, ohne Cloud-Account und ohne Kostenwirkung.

Academy Briefing vereinbaren

Oder sofort per Mail an mail@mhm-dl.de

Format

120 Minuten, live (remote oder vor Ort), Input & drei eigenständige Hands-on-Übungen

Teilnehmende

Entwickler:innen und Ops, die vor dem ersten eigenen Deployment verstehen wollen, was in einem Pod tatsächlich passiert

Voraussetzungen

Abgeschlossenes Modul “Kubernetes Einführung” oder gleichwertige Vorkenntnisse, lauffähige lokale Docker-Umgebung für Minikube

Warum dieses Training für deine Organisation wirkt

Der Pod ist keine Black Box mehr

Der Pause-Container erklärt, warum ein abstürzender Hauptcontainer die IP-Adresse des Pods nicht verliert – ein Detail, das sonst als “Kubernetes-Magie” hingenommen wird, statt als der einfache, nachvollziehbare Mechanismus, der es tatsächlich ist.

Zwei Container, ein Lebenszyklus

Sidecar zur Log-Sammlung und Init-Container zur Vorbereitung sind die zwei häufigsten Multi-Container-Muster im Alltag – beide werden hier selbst gebaut und live verifiziert, nicht nur an der Tafel erklärt.

Zwei Selektor-Arten sauber getrennt

Label-Selektoren für selbst vergebene Metadaten und Field-Selektoren für automatische Systemfelder werden in der Praxis ständig verwechselt – eine eigene Übung stellt beide nebeneinander, statt Field-Selektoren als Randnotiz abzuhandeln.

Was Teilnehmende mitnehmen

  • Erklären, warum jeder Pod zuerst einen unsichtbaren Pause-Container startet und was das für IP-Adresse und Linux-Namespaces (Netzwerk, IPC, UTS) über Neustarts des Hauptcontainers hinweg bedeutet.
  • Begründen, wann ein zweiter Container tatsächlich in denselben Pod gehört (geteiltes Dateisystem, localhost-Kommunikation, gemeinsamer Lebenszyklus) – und das Sidecar-Muster an einem selbst gebauten Log-Sammler über ein geteiltes emptyDir demonstrieren.
  • Einen Init-Container einsetzen, der sequenziell vor den Hauptcontainern läuft und sich mit Exit-Code 0 beenden muss, bevor diese überhaupt starten.
  • Die fünf Pod-Phasen Pending/Running/Succeeded/Failed/Unknown, restartPolicy (Always/OnFailure/Never) und den Graceful-Shutdown-Ablauf SIGTERM → Gnadenfrist → SIGKILL korrekt benennen.
  • Labels von Annotations unterscheiden und die empfohlenen app.kubernetes.io/-Standard-Labels selbst einsetzen.
  • Pods über Label-Selektoren filtern: gleichheitsbasiert (-l environment=production), Ungleichheit und mengenbasiert (-l ‘environment in (…)’).
  • Pods über Field-Selektoren (–field-selector) nach Systemfeldern wie metadata.name oder status.phase filtern – als eigenständige Übung, getrennt von den Label-Selektoren.

Für wen dieses Modul ideal ist

  • • Entwickler:innen und Ops mit abgeschlossenem Modul “Kubernetes Einführung” oder gleichwertigen Vorkenntnissen
  • • Alle, die vor dem ersten eigenen Deployment verstehen wollen, was in einem Pod tatsächlich passiert, bevor die eigene Anwendung überhaupt startet
  • • Teams, die Labels bislang nur kopiert statt bewusst gesetzt haben und Label- von Field-Selektoren sauber trennen wollen

Rahmendaten

  • • Dauer: 120 Minuten live (remote oder vor Ort)
  • • Format: Input, Live-Demo, drei eigenständige Hands-on-Übungen (Sidecar, Init-Container, Labels & Selektoren)
  • • Voraussetzungen: abgeschlossenes Modul “Kubernetes Einführung”, lauffähige lokale Docker-Umgebung, keine Cloud-Kostenwirkung

Modulaufbau & Agenda

  1. Pod-Konzept & Pause-Container (20 min): wann mehrere Container in denselben Pod gehören, und der Pause-Container-Mechanismus, der IP-Adresse und Linux-Namespaces unabhängig vom Hauptcontainer stabil hält.

  2. Multi-Container-Patterns & Hands-on: Sidecar zur Log-Sammlung (30 min): Sidecar/Ambassador/Adapter im Überblick, danach einen eigenen Pod mit Sidecar-Container und geteiltem emptyDir anwenden und die gesammelten Logs live prüfen.

  3. Init-Container & Hands-on (20 min): Eigenschaften von Init-Containern (sequenziell, vor den Anwendungscontainern, Exit-Code 0 zwingend), danach das Sidecar-Manifest um einen Init-Container erweitern, der die Log-Datei vorbereitet.

  4. Pod-Lifecycle: Phasen, Container-Status, Shutdown (20 min): die fünf Pod-Phasen, restartPolicy und der Graceful-Shutdown-Ablauf SIGTERM → Gnadenfrist (terminationGracePeriodSeconds) → SIGKILL.

  5. Labels, Annotations & Selektoren inkl. Hands-on (30 min): Labels vs. Annotations, app.kubernetes.io/-Standard-Labels, danach drei Pods mit Labels anlegen und per Label-Selektor sowie per Field-Selektor gezielt filtern.

Dieses Modul setzt das Einstiegsmodul Kubernetes Einführung — der erste Blick unter die Haube voraus. Control-Plane-/Worker-Architektur und das eigene erste Cluster werden dort erklärt und hier nicht erneut eingeführt – dieses Modul beginnt direkt beim Innenleben des Pods.

Aufbauend auf diesem Modul folgt Kubernetes Workloads & Konfiguration — die Objekte für den Alltag: Dort werden dieselben fünf Pod-Phasen noch einmal kurz benannt, aber sofort mit den drei Probe-Handlern (liveness/readiness/ startupProbe) verknüpft – dieses Modul hier liefert die Phasen, das Aufbaumodul liefert, wie Kubernetes sie aktiv über Probes beeinflusst. ReplicaSet/Deployment, Service- Typen sowie ConfigMap und Secret sind ausschließlich dort Thema.

Aufbauend ist außerdem Kubernetes Anwendungsdesign — Multi-Container-Patterns, Jobs & Security Context: Das Sidecar-Muster aus diesem Modul wird dort um Ambassador und Adapter sowie um die Abgrenzung “eigener Pod oder eigenes Deployment?” vertieft, dazu nodeSelector, Job/ CronJob und securityContext. Dieses Modul ist eine empfohlene Vorstufe zu Kubernetes Workloads & Konfiguration sowie zu Kubernetes Anwendungsdesign und vertieft Konzepte, auf denen beide aufbauen – als formale Voraussetzung führen beide Zielseiten weiterhin ausschließlich Kubernetes Einführung.

Wer von den Labels aus diesem Modul direkt zur Node-Platzierung weiterdenkt, findet den passenden nächsten Schritt in Kubernetes Node-Placement & Taints — nodeSelector, Pod Anti-Affinity und Toleration auf dem Multi-Node-Cluster: Dort werden die hier gelernten Labels erstmals aktiv fürs Scheduling eingesetzt – nodeSelector und hostname-basierte Pod Anti-Affinity auf einem echten k3d-Multi-Node-Cluster, dazu der vollständige Taint-Zyklus (setzen, tolerieren, entfernen). Das Modul setzt ausschließlich dieses Pod-Fundamentals-Modul sowie k3d-Grundwissen voraus, ausdrücklich nicht “Kubernetes Administration” oder “Kubernetes Hochverfügbarkeit” – Administration zeigt Taints bislang nur im Negativfall (Pod ohne Toleration bleibt Pending), Hochverfügbarkeit behandelt Node-Placement/Taints gar nicht. Für den hier beschriebenen nächsten Schritt ist keins von beiden Voraussetzung.

Aufbauend ist außerdem Kubernetes DaemonSets, Downward API & Pod Priority: Knotenweite Dienste, Metadaten-Injektion und Preemption: Dort setzt ihr erstmals einen knotenweiten Infrastruktur-Workload per DaemonSet um, injiziert Pod-Metadaten per Downward API in eure Anwendung und schützt kritische Pods per PriorityClass vor Verdrängung. Formale Voraussetzung dafür ist “Kubernetes Node-Placement & Taints”, nicht dieses Modul direkt.

Hands-on Inhalte (Auszug)

Sidecar zur Log-Sammlung

  • Einen Pod mit Webserver-Container und einem log-collector-Sidecar anwenden, beide über ein gemeinsames emptyDir-Volume verbunden
  • Mit kubectl exec … -c webserver – wget -qO- http://localhost Traffic erzeugen und mit kubectl exec … -c log-collector – cat … live bestätigen, dass der Sidecar die Zugriffsprotokolle tatsächlich sieht

Init-Container ergänzen

  • Das Sidecar-Manifest um einen Init-Container erweitern, der die Log-Datei vor dem Start der Hauptcontainer anlegt und initialisiert
  • Mit kubectl get pod den Zwischenstatus Init:0/1 beobachten, bevor beide Hauptcontainer auf 2/2 Running wechseln

Label-Selektoren live filtern

  • Drei Pods mit unterschiedlichen app.kubernetes.io/- und eigenen Labels anlegen (Frontend/Backend, Produktion/Staging)
  • Mit kubectl get pods -l gleichheitsbasiert, mit Ungleichheit und mengenbasiert (in (…)) filtern

Field-Selektoren als eigene Übung

  • Denselben Pod gezielt über –field-selector metadata.name=… statt über ein Label abfragen
  • Alle laufenden bzw. noch initialisierenden Pods über –field-selector status.phase=Running und status.phase=Pending gegenüberstellen

Mehr zu Ambassador und Adapter als weiteren Multi-Container-Mustern sowie zur Abgrenzung “eigener Pod oder eigenes Deployment?” findet ihr im Aufbaumodul Kubernetes Anwendungsdesign — Multi-Container-Patterns, Jobs & Security Context. Hier diente der Sidecar nur als erster, vollständig nachvollzogener Einstieg in Multi-Container-Pods.

Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Zeit bis zum funktionierenden Sidecar-Nachweis) und werten sie im Anschluss transparent aus. Ergebnisse veröffentlichen wir, sobald sie belastbar sind.

Bereit, das Modul zu buchen?

Wir passen die Hands-on-Übungen auf euren Erfahrungsstand an.

Academy Briefing anfragen