Training Module

Kubernetes Workloads & Konfiguration — die Objekte für den Alltag

In diesem 120-Minuten-Modul schreibt ihr die Manifeste, mit denen ihr im Kubernetes-Alltag tatsächlich arbeitet. Los geht es mit dem Innenleben eines Pods: den fünf Lifecycle-Phasen und den drei Probe-Handlern Exec/TCP/HTTP, die hinter liveness-, readiness- und startupProbe stecken – Selbstheilung und Traffic-Steuerung sind zwei unterschiedliche Dinge, und ihr lernt, wann welche greift. Danach ordnet ihr das ReplicaSet als Nachfolger des veralteten ReplicationControllers ein und arbeitet mit der eigentlichen Deployment-Mechanik: Rolling Update, Rollback und Skalierung über kubectl rollout status/undo/pause/resume. Es folgt ein Vergleich der vier Service-Typen ClusterIP, NodePort, LoadBalancer und ExternalName, danach die Entkopplung von Konfiguration über ConfigMap und Secret – als Volume und als Environment-Variable, mit dem korrekten Unterschied zwischen Klartext (ConfigMap) und Base64-kodiert, aber ausdrücklich NICHT verschlüsselt (Secret). Im Hands-on schreibt und wendet ihr ein eigenes Manifest-Set an, aktualisiert ein Image per Rolling Update und baut bewusst einen falschen Probe-Pfad ein, um den entstehenden Restart-Loop mit kubectl describe pod und kubectl logs –previous zu debuggen. Voraussetzung ist das Modul “Kubernetes Einführung” – die komplette Session läuft weiterhin vollständig lokal über Minikube, ohne Cloud-Account und ohne Kostenwirkung.

Academy Briefing vereinbaren

Oder sofort per Mail an kontakt@codecraft.academy

Format

120 Minuten, live (remote oder vor Ort), Input & Hands-on

Teilnehmende

Entwickler:innen und Ops, die eigene Kubernetes-Manifeste schreiben wollen

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

Vom Lesen zum Schreiben

Nach dem ersten eigenen Cluster kommt jetzt das eigene Manifest: Pod-Lifecycle, die drei Probe-Handler und der Unterschied zwischen Selbstheilung (liveness) und Traffic-Steuerung (readiness) sind das Fundament für jedes produktionsnahe Deployment.

Konfiguration sauber getrennt

ConfigMap und Secret entkoppeln Konfiguration vom Container-Image – inklusive einer ehrlichen Einordnung: Ein Secret ist Base64-kodiert, nicht verschlüsselt. Wer hier eine falsche Erwartung mitnimmt, baut später eine Sicherheitslücke.

Debugging ist Teil des Kurses

Ein bewusst falscher Probe-Pfad erzeugt live einen Restart-Loop – und ihr lernt kubectl describe pod und kubectl logs –previous genau dort einzusetzen, wo sie im echten Betrieb gebraucht werden.

Was Teilnehmende mitnehmen

  • Die Pod-Lifecycle-Phasen (Pending, Running, Succeeded, Failed, Unknown) und die drei Probe-Handler Exec/TCP/HTTP benennen.
  • liveness-, readiness- und startupProbe konfigurieren und den Unterschied zwischen Selbstheilung (liveness) und Traffic-Steuerung (readiness) einordnen.
  • Das ReplicaSet als Nachfolger des veralteten ReplicationControllers einordnen – mit Label-Selector statt reiner Gleichheitsselektion.
  • Ein Deployment für Rolling Update, Rollback und Skalierung nutzen: kubectl rollout status/undo/pause/resume.
  • Die vier Service-Typen ClusterIP, NodePort, LoadBalancer und ExternalName unterscheiden und einem passenden Einsatzzweck zuordnen.
  • ConfigMap und Secret als Volume und als Environment-Variable einbinden – inklusive dem korrekten Unterschied zwischen Klartext (ConfigMap) und Base64-kodiert, aber NICHT verschlüsselt (Secret).
  • Ein eigenes Manifest-Set (Deployment, Service, ConfigMap, Secret) selbst schreiben, anwenden und bei einem kaputten Probe-Pfad gezielt debuggen.

Für wen dieses Modul ideal ist

  • • Entwickler:innen und Ops mit abgeschlossenem Modul “Kubernetes Einführung” oder gleichwertigen Vorkenntnissen
  • • Alle, die jetzt selbst produktionsnahe Manifeste schreiben wollen, statt nur kubectl get-Ausgaben zu lesen
  • • Teams, die vor dem ersten eigenen Secret wissen wollen, was Base64 tatsächlich schützt – und was nicht

Rahmendaten

  • • Dauer: 120 Minuten live (remote oder vor Ort)
  • • Format: Input, Live-Demo, ausführliches Hands-on mit eigenem Manifest-Set
  • • Voraussetzungen: abgeschlossenes Modul “Kubernetes Einführung”, lauffähige lokale Docker-Umgebung, keine Cloud-Kostenwirkung

Modulaufbau & Agenda

  1. Pod-Innenleben & Health-Checks (25 min): die fünf Lifecycle-Phasen Pending/Running/Succeeded/Failed/Unknown, die drei Probe-Handler Exec/TCP/HTTP, und der Unterschied zwischen liveness (Selbstheilung), readiness (Traffic-Steuerung) und startupProbe.

  2. ReplicaSet & Deployment-Mechanik (30 min): das ReplicaSet als Nachfolger des veralteten ReplicationControllers mit Label-Selector, und das Deployment für Rolling Update, Rollback und Skalierung über kubectl rollout status/undo/pause/resume.

  3. Service-Typen im Vergleich (20 min): ClusterIP, NodePort, LoadBalancer und ExternalName im direkten Vergleich – wann welcher Typ der richtige ist.

  4. Konfiguration entkoppeln: ConfigMap & Secret (25 min): beide als Volume und als Environment-Variable einbinden, sowie der korrekte Unterschied zwischen Klartext (ConfigMap) und Base64-kodiert, aber ausdrücklich NICHT verschlüsselt (Secret).

  5. Hands-on: eigenes Manifest-Set, Image-Update, Debugging (20 min): Deployment, Service, ConfigMap und Secret selbst schreiben und anwenden, ein Image-Update per Rolling Update fahren und einen bewusst kaputten Probe-Pfad debuggen.

Dieses Modul setzt das Einstiegsmodul Kubernetes Einführung — der erste Blick unter die Haube voraus. Control-Plane-/Worker-Architektur, der Pod als kleinste Einheit und das eigene erste Cluster werden dort erklärt und hier nicht erneut eingeführt – dieses Aufbaumodul beginnt direkt beim Schreiben eigener Manifeste.

Wer die Service-Grundlagen und die readinessProbe aus diesem Modul bereits beherrscht und tiefer einsteigen will – Endpoints/ EndpointSlices, SRV-Records, dnsPolicy/dnsConfig sowie Ingress- Pfad-Routing – findet das im Vertiefungsmodul Kubernetes Networking Vertiefung — Service Discovery, DNS und Ingress-Pfadregeln.

Wer stattdessen die Betreiber-Perspektive einnehmen will – Namespace/ResourceQuota, RBAC, Cluster-Netzwerk-Grundmodell, Node-Administration und High Availability als Konzept – findet das im gleichrangigen, unabhängigen Vertiefungsmodul Kubernetes Administration — RBAC, Node-Betrieb und Cluster-Netzwerk.

Wer stattdessen die Anwendungsdesign-Perspektive einnehmen will – Multi-Container-Pod-Patterns (Sidecar/Ambassador/Adapter), Job/CronJob für Batch-Workloads sowie securityContext und ServiceAccount zur Runtime-Absicherung – findet das im gleichrangigen, unabhängigen Vertiefungsmodul Kubernetes Anwendungsdesign — Multi-Container-Patterns, Jobs & Security Context.

Wer stattdessen die Storage-Perspektive einnehmen will – emptyDir und hostPath im Vergleich zu PersistentVolume, PersistentVolumeClaim mit Binding-Regel, AccessModes und StorageClass – findet das im gleichrangigen, unabhängigen Vertiefungsmodul Kubernetes Storage — Volumes, PersistentVolumes & Claims.

Wer stattdessen wissen will, wie sich eine bereits laufende Anwendung diagnostizieren lässt – Prometheus-Scrape-Annotationen, kubectl top pods, Ephemeral Containers per kubectl debug und die dreistufige Service-Troubleshooting-Kette Port-Forward → Endpoints → DNS-Test-Pod – findet das im gleichrangigen, unabhängigen Vertiefungsmodul Kubernetes: Monitoring & Troubleshooting.

Wer stattdessen wissen will, wie viel ein Container verbrauchen darf – requests/limits, die drei QoS-Klassen, LimitRange als Namespace-Default sowie der HorizontalPodAutoscaler mit seiner harten Kopplung an requests.cpu – findet das im gleichrangigen, unabhängigen Vertiefungsmodul Kubernetes Ressourcenmanagement & Autoscaling — Requests, Limits und HorizontalPodAutoscaler.

Wer stattdessen eigene und fremde Anwendungen als versionierte Releases statt loser Manifest-Dateien betreiben will – Chart/ Release/Repository als Grundbegriffe, Chart-Struktur und Go-Template-Syntax, das komplette Lifecycle-Management helm install/upgrade/rollback/history sowie die Installation eines realen, öffentlichen Charts – findet das im gleichrangigen, unabhängigen Vertiefungsmodul Helm — Paketmanagement für Kubernetes. Alle sieben Vertiefungsmodule setzen nur dieses Aufbaumodul voraus, nicht sich gegenseitig, und lassen sich in beliebiger Reihenfolge buchen.

Wer beim Secret aus diesem Modul über den Merksatz “Base64-kodiert, aber NICHT verschlüsselt” hinaus wissen will, wie sich Secrets tatsächlich vor unautorisiertem etcd-Zugriff schützen lassen – Secrets-Encryption-at-Rest über eine EncryptionConfiguration, dazu Namespace-weite Pod-Härtung über Pod Security Admission – findet das im Aufbaumodul Kubernetes Security Vertiefung — Pod Security Admission & Secrets-Härtung, das die zwei Vertiefungsmodule “Kubernetes Administration” und “Kubernetes Anwendungsdesign” voraussetzt.

Wer die PersistentVolumeClaim aus diesem Modul mit einem Workload-Typ kombinieren will, der pro Replica automatisch eine eigene PVC erhält – stabile, geordnete Pod-Identität statt austauschbarer Pods, volumeClaimTemplates sowie die Kopplung an einen Headless Service für stabile Pro-Pod-DNS-Namen – findet das im Aufbaumodul Kubernetes StatefulSets — Stabile Identität für zustandsbehaftete Workloads, das die zwei Vertiefungsmodule “Kubernetes Storage” und “Kubernetes Networking Vertiefung” voraussetzt.

Wer die Deployment-Richtung aus diesem Modul umdrehen will – statt einer CI-Pipeline, die mit kubectl apply aktiv in den Cluster schreibt, ein GitOps-Operator, der sich Änderungen selbst aus Git holt –, dazu die ArgoCD-Application-CRD, Sync-Status gegen Health-Status, Drift Detection & Self-Healing sowie Rollback per git revert statt dem hier gelehrten kubectl rollout undo – findet das im Aufbaumodul Kubernetes GitOps — Deklaratives Deployment mit ArgoCD, das dieses Aufbaumodul voraussetzt; “Helm — Paketmanagement für Kubernetes” ist dafür empfohlen, aber keine Pflicht.

Hands-on Inhalte (Auszug)

Eigenes Manifest-Set schreiben

  • Ein Deployment mit 2 Replicas inklusive livenessProbe und readinessProbe, deklariert mit apiVersion: apps/v1 – nicht mit dem seit Kubernetes 1.16 entfernten extensions/v1beta1
  • Ein passender Service, eine ConfigMap und ein Secret, alle vier Manifeste per kubectl apply -f gemeinsam angewendet
  • Kontrolle über kubectl get pods/deployment/service/configmap/secret, ob alle vier Objekte wie erwartet laufen

Image-Update & Rollback

  • Ein neues Image mit kubectl set image ausrollen und den Fortschritt live mit kubectl rollout status verfolgen
  • Mit kubectl rollout undo gezielt auf die vorherige, funktionierende Version zurückrollen
  • Den Unterschied zwischen Rolling Update (schrittweise) und einem harten Neustart aller Replicas gleichzeitig einordnen

Debugging: kaputte Probe

  • Bewusst einen falschen Probe-Pfad einbauen und live beobachten, wie Kubernetes daraufhin in einen Restart-Loop geht
  • Mit kubectl describe pod die Events und den Grund für den Neustart einsehen
  • Mit kubectl logs –previous die Logs des bereits neu gestarteten, vorherigen Containers auslesen

ConfigMap ändern, Volume vs. Env-Var

  • Die ConfigMap nachträglich ändern und zeigen, dass der Volume-Mount die neuen Werte automatisch nachzieht
  • Denselben Wert zusätzlich als Environment-Variable einbinden und beobachten, dass diese erst nach einem Neustart des Pods aktualisiert wird
  • Klartext-ConfigMap und Base64-kodiertes-aber-nicht-verschlüsseltes Secret nebeneinander per kubectl get -o yaml vergleichen

Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Zeit bis zum lauffähigen eigenen Manifest-Set) 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-Übung auf euren Erfahrungsstand und eure Zielumgebung an.

Academy Briefing anfragen