Training Module

Kubernetes: Monitoring & Troubleshooting

In diesem Modul (100 Minuten live, davon 40 Minuten Hands-on-Incident) geht es um die Frage, die jeder laufenden Anwendung im Cluster früher oder später gestellt wird: Warum antwortet das hier gerade nicht? Zuerst lest und setzt ihr Prometheus-Scrape-Annotationen wie prometheus.io/scrape, prometheus.io/port und prometheus.io/path auf einem Pod und ordnet ein, warum die Annotation allein noch keine Metriken erzeugt – erst ein /metrics-Endpoint der eigenen Anwendung im Prometheus-Textformat macht sie für einen Scraper überhaupt sichtbar. Dazu kubectl top pods für den schnellen, punktuellen Blick auf den Ressourcenverbrauch, samt seiner Abhängigkeit vom Metrics Server im Cluster. Im zweiten Block steigt ihr ins Debugging laufender Container ein: kubectl exec für Container mit Shell, und kubectl debug für einen Ephemeral Container, wenn ein minimales distroless-Image gar keine Shell mitbringt – er hängt sich live an den laufenden Pod, im selben Netzwerk-Namespace und optional im selben Prozess-Namespace des Zielcontainers, ohne dass irgendetwas neu gebaut oder neu gestartet werden muss. Den größten Block bildet ein Hands-on-Incident: ein absichtlich kaputter Service, den ihr über eine dreistufige Troubleshooting-Kette systematisch eingrenzt – Port-Forward direkt gegen den Pod (umgeht Service und Ingress), kubectl get endpoints (ein Service ohne passende Endpoints leitet keinen Traffic weiter) und zuletzt ein DNS-Test aus einem kurzlebigen Debug-Pod. Voraussetzung ist das Modul “Kubernetes Workloads & Konfiguration” – Probes und Logging gelten als bekannt und werden hier nicht wiederholt. Die 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

100 Minuten live (remote oder vor Ort), davon 40 Minuten Hands-on-Incident

Teilnehmende

Entwickler:innen und Ops, die eine laufende Anwendung im Cluster systematisch diagnostizieren wollen, statt Symptome zu raten

Voraussetzungen

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

Warum dieses Training für deine Organisation wirkt

Eine Annotation erzeugt keine Metriken

prometheus.io/scrape: “true” auf einem Pod sieht nach fertigem Monitoring aus – ist es aber nicht. Ohne einen /metrics-Endpoint im Prometheus-Textformat auf der eigenen Anwendung findet der Scraper trotz korrekt gesetzter Annotation schlicht nichts. Wer diesen Unterschied nicht kennt, hält ein leeres Dashboard für einen Prometheus-Fehler statt für eine fehlende Anwendungs-Integration.

Fehlende Shell ist kein Debugging-Stopp

Minimale distroless-Images haben aus gutem Sicherheitsgrund keine Shell und keine Debugging-Werkzeuge an Bord. Wer dann kubectl exec versucht und scheitert, hält den Container fälschlich für unzugänglich. Ein Ephemeral Container über kubectl debug hängt sich live an denselben Pod, ohne dass der eigentliche Container neu gebaut oder neu gestartet werden muss.

Eine feste Reihenfolge statt Rätselraten

“Der Service geht nicht” hat drei mögliche Ursachen: den Container selbst, die Service-Konfiguration oder die DNS-Auflösung. Wer diese Reihenfolge nicht kennt, springt zwischen Symptomen. Port-Forward, Endpoints, DNS-Test-Pod – in genau dieser Reihenfolge grenzt ihr jede der drei Ursachen einzeln aus.

Was Teilnehmende mitnehmen

  • Prometheus-Scrape-Annotationen (prometheus.io/scrape, prometheus.io/port, prometheus.io/path) auf einem Pod lesen und setzen, und einordnen, dass die Annotation allein noch keine Metriken erzeugt.
  • kubectl top pods für den punktuellen Ressourcenverbrauch nutzen und seine Abhängigkeit vom Metrics Server im Cluster benennen.
  • kubectl exec für Container mit Shell einsetzen und gegen kubectl debug mit Ephemeral Containers abgrenzen, wenn ein distroless-Image keine Shell mitbringt.
  • Einen Ephemeral Container per kubectl debug –target=<container> an einen laufenden Pod hängen und den optional geteilten Prozess-Namespace einordnen.
  • Die dreistufige Service-Troubleshooting-Kette (Port-Forward → Endpoints → DNS-Test-Pod) systematisch anwenden, um zwischen Container-, Service- und DNS-Problem zu unterscheiden.
  • kubectl get endpoints lesen und die häufigste Ursache für einen Service ohne Endpoints benennen: fehlendes Label auf dem Pod oder eine dauerhaft fehlschlagende Readiness-Probe.
  • In einem Hands-on-Incident einen absichtlich kaputten Service eigenständig eingrenzen und die Ursache klar benennen.

Für wen dieses Modul ideal ist

  • • Entwickler:innen und Ops mit abgeschlossenem Modul “Kubernetes Workloads & Konfiguration” oder gleichwertigen Vorkenntnissen
  • • Alle, die kubectl logs und Probes bereits kennen, aber bei “der Service antwortet nicht” noch ohne System suchen
  • • Teams, die Prometheus-Annotationen im Cluster sehen, aber nicht sicher einordnen können, was sie tatsächlich bewirken

Rahmendaten

  • • Dauer: 100 Minuten live (remote oder vor Ort), davon 40 Minuten Hands-on-Incident
  • • Format: Input, Live-Demo, abschließender Hands-on-Incident mit absichtlich kaputtem Service
  • • Voraussetzungen: abgeschlossenes Modul “Kubernetes Workloads & Konfiguration”, lauffähige lokale Docker-Umgebung, keine Cloud-Kostenwirkung

Modulaufbau & Agenda

  1. Monitoring-Annotationen & Metrics Server (20 min): Prometheus-Scrape-Annotationen wie prometheus.io/scrape, prometheus.io/port und prometheus.io/path lesen und setzen, klare Abgrenzung “Annotation ≠ Metrik”, dazu kubectl top pods und seine Abhängigkeit vom Metrics Server.

  2. Debugging laufender Container inkl. Ephemeral Containers (30 min): kubectl exec für Container mit Shell, kubectl debug für einen Ephemeral Container gegen ein distroless-Image ohne Shell, und kubectl describe pod für die Event-Historie.

  3. Service-Troubleshooting-Playbook als Hands-on-Incident (40 min, Hands-on-Incident): ein absichtlich kaputter Service, den ihr über die dreistufige Kette Port-Forward → Endpoints → DNS-Test-Pod eigenständig eingrenzt.

  4. Zusammenfassung & Referenzkarte (10 min): alle Befehle dieses Moduls als kompakte Referenzkarte für den Arbeitsalltag, plus klare Abgrenzung zu Themen, die bewusst nicht Teil dieses Moduls sind.

Dieses Modul setzt das Aufbaumodul Kubernetes Workloads & Konfiguration — die Objekte für den Alltag voraus. Probes (liveness/readiness) und kubectl logs werden dort erklärt und hier nicht erneut eingeführt – dieses Modul setzt direkt bei der Frage an, wie ihr eine bereits laufende Anwendung im Cluster diagnostiziert.

Ausdrücklich nicht Teil dieses Moduls: Probe-Konfiguration selbst (bereits im Aufbaumodul Kubernetes Workloads & Konfiguration), der Aufbau eines Prometheus-/Grafana-Stacks (dafür Docker Betrieb), Node-Kapazität und kubectl top node (dafür Kubernetes Administration) sowie EndpointSlice-Interna (dafür Kubernetes Networking Vertiefung). Dieses Modul liest kubectl get endpoints nur als Diagnose-Schritt, ohne die EndpointSlice-Mechanik dahinter zu vertiefen.

Dieses Modul ist unabhängig von den weiteren Vertiefungsmodulen auf Kubernetes Workloads & Konfiguration: Kubernetes Administration — RBAC, Node-Betrieb und Cluster-Netzwerk, Kubernetes Networking Vertiefung — Service Discovery, DNS und Ingress-Pfadregeln, Kubernetes Anwendungsdesign — Multi-Container-Patterns, Jobs & Security Context und Kubernetes Storage — Volumes, PersistentVolumes & Claims. Wer stattdessen wissen will, wie viel ein Container verbrauchen darf – requests/limits, die drei QoS-Klassen sowie der HorizontalPodAutoscaler – findet das im weiteren Schwestermodul Kubernetes Ressourcenmanagement & Autoscaling — Requests, Limits und HorizontalPodAutoscaler. Wer stattdessen wissen will, wie sich diese Objekte als wiederverwendbares Paket versionieren und verteilen lassen – Chart-Struktur, values.yaml und Release-Verwaltung – findet das im weiteren Schwestermodul Helm — Paketmanagement für Kubernetes. Alle setzen nur das Workloads-Modul voraus, nicht sich gegenseitig, und lassen sich in beliebiger Reihenfolge buchen.

Hands-on-Incident Inhalte (Auszug)

Ausgangslage: ein absichtlich kaputter Service

  • Ein Deployment mit passendem Service anwenden, dessen Selector bewusst nicht zum Pod-Label passt
  • Die einzige Beobachtung: ein Request gegen den Service liefert keine Antwort

Schritt 1: Port-Forward gegen den Pod

  • kubectl port-forward pod/<pod-name> 8080:80 direkt gegen den Pod, unter Umgehung von Service und Ingress
  • Antwortet die Anwendung hier, liegt das Problem nicht im Container, sondern in der Service- oder Netzwerk-Konfiguration davor

Schritt 2: Endpoints prüfen

  • kubectl get endpoints <service-name> zeigt eine leere Adressliste
  • Den Pod-Selector des Service gegen die tatsächlichen Pod-Labels abgleichen und die Abweichung finden

Schritt 3: DNS-Test-Pod & Ursache benennen

  • kubectl run dns-test –rm -it –image=busybox –restart=Never – nslookup <service-name> zur Kontrolle, dass der Servicename selbst sauber aufgelöst wird
  • Die Ursache in einem Satz benennen: DNS und Container funktionieren, der Service leitet nur mangels passender Endpoints keinen Traffic weiter

Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Zeit bis zur eigenständig eingegrenzten Incident-Ursache) 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