Thomas.will: Die Seite wurde neu angelegt: „Dieser Artikel behandelt zwei Themen, die den Kurs abschließen: Netzwerk-Segmentierung mit NetworkPolicies und ein systematisches Vorgehen beim Debuggen kaput…“

2026-08-09T08:11:55Z

Die Seite wurde neu angelegt: „Dieser Artikel behandelt zwei Themen, die den Kurs abschließen: Netzwerk-Segmentierung mit NetworkPolicies und ein systematisches Vorgehen beim Debuggen kaput…“

Neue Seite

Dieser Artikel behandelt zwei Themen, die den Kurs abschließen: Netzwerk-Segmentierung mit NetworkPolicies und ein systematisches Vorgehen beim Debuggen kaputter Pods.

==Netzwerk-Segmentierung mit NetworkPolicies==

; Ausgangslage ohne Policy
* Standardmäßig darf in Kubernetes jeder Pod mit jedem anderen Pod im Cluster kommunizieren – unabhängig von Namespace oder Anwendung. Das entspricht in etwa einem einzigen, komplett offenen Netz.

; Die Analogie zu nftables
* Eine '''NetworkPolicy''' funktioniert im Prinzip wie eine Firewall-Regel, nur auf Pod-Ebene statt auf Interface- oder IP-Ebene. Statt Quell-IPs und Ports zu filtern, werden Pods über ihre Labels ausgewählt – das grundsätzliche Prinzip "erlaubt ist nur, was explizit erlaubt wird" ist identisch zu dem, was aus nftables-Regelwerken bekannt ist.

; Voraussetzung
* NetworkPolicies werden nicht von Kubernetes selbst durchgesetzt, sondern vom eingesetzten Netzwerk-Plugin (CNI). Das bei k3s standardmäßig verwendete Flannel unterstützt sie '''nicht'''. Für diese Übung wird deshalb ein Policy-fähiges CNI wie Calico benötigt, oder die Policy wird nur zur Veranschaulichung des YAML-Aufbaus besprochen, ohne die Durchsetzung praktisch zu erzwingen. Welcher Weg gewählt wird, hängt vom vorbereiteten Kurs-Image ab.

===Beispiel: nur web darf zu db===

Ziel: Ausschließlich Pods mit dem Label <code>app: web</code> dürfen Verbindungen zum <code>db</code>-Pod aufbauen. Jeder andere Zugriff wird verweigert.

<syntaxhighlight lang="yaml">
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: db-allow-web-only
spec:
podSelector:
matchLabels:
app: db
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: web
ports:
- protocol: TCP
port: 5432
</syntaxhighlight>

; Wichtig zum Verständnis
* Sobald für einen Pod '''irgendeine''' NetworkPolicy mit <code>Ingress</code> existiert, gilt ab diesem Moment für diesen Pod: alles ist verboten außer dem, was explizit erlaubt wurde. Vorher galt "alles erlaubt", danach "alles verboten außer den Ausnahmen" – ein Umdenken, das viele Einsteiger überrascht.

; Anwenden
* <code>kubectl apply -f db-networkpolicy.yaml</code>

; Wirkung testen
* Von einem Pod ohne das Label <code>app: web</code> aus (zum Beispiel einem frisch gestarteten Test-Pod) sollte die Verbindung zu <code>db:5432</code> nun fehlschlagen, während sie vom <code>web</code>-Pod aus weiterhin funktioniert.

==Systematisches Troubleshooting==

Bei Problemen mit einem Pod hilft ein festes Vorgehen, statt wahllos Befehle auszuprobieren.

; Schritt 1: Überblick verschaffen
* <code>kubectl get pods -o wide</code>
* Zeigt Status, Neustarts und den Node, auf dem der Pod läuft.

; Schritt 2: Details und Ereignisse ansehen
* <code>kubectl describe pod <pod-name></code>
* Der Abschnitt <code>Events</code> am Ende der Ausgabe verrät in den meisten Fällen sofort die Ursache – falsches Image, fehlende Ressourcen, fehlgeschlagene Probe.

; Schritt 3: Logs des aktuellen Containers prüfen
* <code>kubectl logs <pod-name></code>

; Schritt 4: Bei Neustart-Schleifen die Logs des vorherigen Versuchs prüfen
* Nach einem Absturz sind die aktuellen Logs oft leer oder nutzlos, weil der Container gerade erst wieder gestartet ist.
* <code>kubectl logs <pod-name> --previous</code>

; Schritt 5: Cluster-weite Ereignisse prüfen
* Hilfreich, wenn ein Pod gar nicht erst startet (zum Beispiel wegen fehlender Ressourcen im Cluster).
* <code>kubectl get events --sort-by='.lastTimestamp'</code>

; Schritt 6: Bei Bedarf direkt in den Container
* <code>kubectl exec -it <pod-name> -- /bin/sh</code>

===Typische Fehlerbilder===

{| class="wikitable"
! Status !! Typische Ursache !! Erster Debugging-Schritt
|-
| ImagePullBackOff || Image-Name falsch geschrieben oder Tag existiert nicht || <code>kubectl describe pod</code>, Abschnitt Events
|-
| CrashLoopBackOff || Anwendung stürzt beim Start ab || <code>kubectl logs --previous</code>
|-
| Pending || Zu wenig Ressourcen im Cluster oder kein passender Node || <code>kubectl describe pod</code>, Abschnitt Events
|-
| Running, aber nicht erreichbar || Falscher Service-Selector oder fehlende Readiness || <code>kubectl get endpoints</code>, Labels prüfen
|}

==Übung: NetworkPolicy verifizieren==

# Wendet die oben gezeigte Policy an.
# Startet einen Test-Pod ohne das Label <code>app: web</code>: <code>kubectl run test --rm -it --image=curlimages/curl -- sh</code>
# Versucht von dort aus, <code>db:5432</code> zu erreichen, und bestätigt, dass die Verbindung blockiert wird.
# Wechselt in den <code>web</code>-Pod und bestätigt, dass die Verbindung zu <code>db:5432</code> von dort weiterhin funktioniert.

==Übung: Geführtes Troubleshooting==

In dieser Übung wird absichtlich ein Fehler eingebaut, den es systematisch mit den oben gezeigten Schritten zu finden gilt, ohne die Lösung vorher zu kennen.

# Wendet ein Deployment mit einem absichtlich falschen Image-Namen an.
# Findet mit dem beschriebenen Vorgehen (nicht durch Raten) die genaue Fehlerursache.
# Korrigiert den Fehler und bestätigt, dass der Pod danach normal läuft.
# Wiederholt die Übung mit einem zweiten, unangekündigten Fehler (zum Beispiel einer fehlerhaften Readiness Probe, die auf einen falschen Port zeigt) und wendet dasselbe Vorgehen erneut an.

==Übung: Alles zusammenführen==

Als Abschluss wird die komplette Anwendung aus den vorherigen Artikeln noch einmal von Grund auf neu aufgesetzt, diesmal ohne Anleitung Schritt für Schritt, nur anhand der eigenen Notizen:

# Erstellt alle benötigten Objekte (ConfigMap, Secret, PVC, beide Deployments, beide Services, Ingress, NetworkPolicy) in einer sinnvollen Reihenfolge.
# Prüft den vollständigen Zustand mit <code>kubectl get all</code> und <code>kubectl get pvc,ingress,networkpolicy</code>.
# Führt ein Rolling Update durch und bestätigt es mit <code>kubectl rollout status</code>.
# Simuliert einen Ausfall (Pod löschen) und beobachtet die Selbstheilung.
# Räumt zum Abschluss den gesamten Namespace auf: <code>kubectl delete all --all</code>

Kubernetes NetworkPolicies Troubleshooting - Versionsgeschichte

Thomas.will: Die Seite wurde neu angelegt: „Dieser Artikel behandelt zwei Themen, die den Kurs abschließen: Netzwerk-Segmentierung mit NetworkPolicies und ein systematisches Vorgehen beim Debuggen kaput…“