Site icon bintorosoft.com

NetworkPolicy-Debugging: Die blockierende Rule finden

Red Snapper

NetworkPolicy-Debugging: Die blockierende Rule finden – genau daran scheitern viele Kubernetes-Teams, weil NetworkPolicies auf den ersten Blick simpel wirken, in der Realität aber aus mehreren Ebenen bestehen: Label-Selektoren, Namespace-Selektoren, Ports/Protokolle, Richtungslogik (Ingress/Egress), Default-Deny-Effekte, CNI-spezifische Umsetzung (iptables, nftables, eBPF) und nicht zuletzt die Frage, ob das Cluster überhaupt NetworkPolicy erzwingt. Das typische Fehlerbild ist immer ähnlich: „Gestern ging es noch, heute ist ein Service nicht erreichbar“, „DNS klappt nur sporadisch“, „Pod A erreicht Pod B nicht mehr“ oder „Nur über den Service-Namen geht es nicht“. Um die blockierende Rule zuverlässig zu finden, brauchen Sie eine strukturierte Vorgehensweise: erst feststellen, ob NetworkPolicy überhaupt der Schuldige ist, dann den betroffenen Datenpfad sauber definieren, anschließend die Policy-Menge auf den Ziel-Pod eingrenzen und schließlich die konkrete Ursache isolieren – etwa ein fehlendes Label, eine zu enge Port-Definition, ein falsch gesetzter NamespaceSelector oder eine Egress-Policy, die DNS oder egress NAT unbeabsichtigt blockiert. Dieser Artikel zeigt eine praxistaugliche Schritt-für-Schritt-Methodik, mit der Sie die blockierende NetworkPolicy identifizieren und beheben, ohne stundenlang „rumzuprobieren“.

Grundlagen: Was NetworkPolicy tatsächlich macht (und was nicht)

Kubernetes NetworkPolicy ist ein L3/L4-Mechanismus: Sie steuert, welche Quellen/Ziele (Pods, Namespaces, CIDRs) über welche Ports und Protokolle kommunizieren dürfen. Entscheidend ist: NetworkPolicy ist kein Kubernetes-Core-Feature, das automatisch wirkt. Sie wird von der CNI-Implementierung (oder einem separaten Policy-Controller) umgesetzt. Wenn Ihr CNI NetworkPolicy nicht unterstützt oder Policy-Enforcement deaktiviert ist, sind Policies „nur YAML ohne Wirkung“.

Offizielle Referenzen: Kubernetes Network Policies sowie die Spezifikation der API-Objekte unter NetworkPolicy (policy/v1) API Reference.

Der wichtigste Debugging-Hebel: Verstehen, wann „Default Deny“ aktiv wird

Das häufigste Missverständnis: „Ich habe eine Policy erstellt, die nur einen kleinen Teil regelt.“ In der Praxis löst schon eine einzige Policy für einen Pod-Selektor den Wechsel von „alles erlaubt“ zu „nur explizit erlaubt“ aus – allerdings nur in der jeweils betroffenen Richtung. Sobald ein Pod von mindestens einer Ingress-Policy selektiert wird, ist sein Ingress-Verkehr auf das erlaubt, was durch mindestens eine passende Ingress-Regel abgedeckt ist. Gleiches gilt für Egress, wenn eine Egress-Policy den Pod selektiert.

Wenn Sie die blockierende Rule finden wollen, müssen Sie daher zuerst klären: Ist es ein Ingress- oder Egress-Problem – oder beides?

Schritt 1: Den Datenpfad konkret machen (ohne Annahmen)

NetworkPolicy-Debugging scheitert oft, weil der „Fail“ zu vage beschrieben wird. Formulieren Sie den Pfad so konkret wie möglich:

Wichtig: Wenn ein Zugriff über Service-Namen scheitert, kann die Blockade auch DNS betreffen (UDP/TCP 53 zu CoreDNS) oder Service-Routing (kube-proxy/eBPF) – nicht nur die direkte App-Verbindung.

Schritt 2: Prüfen, ob NetworkPolicy überhaupt die Ursache ist

Bevor Sie Policies sezieren, stellen Sie sicher, dass der Fehler nicht auf einer anderen Ebene liegt. Das spart Zeit und verhindert Fehlfixes.

Gerade der letzte Punkt ist kritisch: Manche CNIs unterstützen NetworkPolicy nur eingeschränkt oder benötigen explizite Aktivierung. Cilium erklärt das Enforcement-Konzept und eBPF-Policy unter Cilium Network Policy, Calico die Policy-Umsetzung unter Calico Kubernetes NetworkPolicy.

Schritt 3: Betroffene Pods identifizieren (welche Policies selektieren wirklich?)

Die „blockierende Rule“ ist oft nicht die Policy, die Sie zuletzt geändert haben, sondern eine Policy, die plötzlich auf mehr Pods zutrifft – weil Labels geändert wurden, Deployments neue Labels bekommen haben oder Namespace-Labels angepasst wurden. Debugging beginnt daher mit der Frage: Welche Policies selektieren den Ziel-Pod (Ingress) und welche selektieren den Quell-Pod (Egress)?

Typische Ursachen für unerwartete Selektoren

Schritt 4: Ingress oder Egress isolieren – mit kontrollierten Tests

Um die blockierende Richtung zu finden, nutzen Sie Tests, die jeweils nur eine Komponente prüfen. Der Wert liegt nicht im konkreten Tool, sondern im Prinzip: erst IP, dann Port, dann Name/HTTP.

Wenn DNS nicht funktioniert, ist häufig eine Egress-Policy schuld, die UDP/TCP 53 Richtung kube-dns/CoreDNS nicht erlaubt. Wenn Pod-IP klappt, aber Service nicht, ist das Problem eher im Service-Layer (kube-proxy/eBPF) oder in einer Policy, die nur den Service-Pfad indirekt betrifft.

Schritt 5: Die Policy-Logik korrekt „lesen“ (Additivität statt Priorität)

Standard-Kubernetes-NetworkPolicies kennen keine Prioritäten. Es gibt nicht „die eine“ Regel, die gewinnt. Stattdessen gilt: Für einen Pod ist ein Flow erlaubt, wenn mindestens eine passende Policy in der jeweiligen Richtung den Flow erlaubt. Das ist die zentrale Denkweise, um die blockierende Rule zu finden: Sie suchen nicht nach „Deny“, sondern nach dem fehlenden „Allow“.

Praktische Konsequenz

Die häufigsten Blocker-Muster und wie Sie sie schnell erkennen

DNS wird blockiert (der Klassiker bei Egress Default Deny)

Symptome: Service-Namen lösen nicht auf, externe Namen ebenfalls nicht, Workloads melden „no such host“, „i/o timeout“, „temporary failure in name resolution“. Ursache: Eine Egress-Policy selektiert den Pod, erlaubt aber keinen Verkehr zu CoreDNS (kube-system) auf UDP/TCP 53.

Hintergrund zu DNS in Kubernetes: DNS for Services and Pods.

NamespaceSelector passt nicht (fehlende Namespace-Labels)

Symptome: Eine Policy „sollte“ Zugriff aus einem Namespace erlauben, aber in der Praxis wird geblockt. Ursache: namespaceSelector matcht nur Namespaces mit bestimmten Labels; wenn diese Labels fehlen, ist der Namespace nicht eingeschlossen.

Ports sind zu eng definiert (TCP 443 erlaubt, aber Healthcheck auf 10254 blockiert)

Symptome: App funktioniert teilweise, aber Healthchecks, Metrics oder Sidecar-Kommunikation schlägt fehl. Ursache: Die Policy erlaubt nur den „Hauptport“, aber nicht Nebenports (Prometheus Scrape, Envoy Admin, gRPC Health, Webhooks).

Egress zu externen Zielen ist blockiert (CIDR fehlt oder ist falsch)

Symptome: Interne Calls funktionieren, externe APIs nicht, Container können keine Pakete ziehen, Timeouts bei Outbound HTTPS. Ursache: Egress-Policy erlaubt nur clusterinterne Ziele oder nur bestimmte CIDRs.

Service-Mesh/mTLS verändert Datenpfade

Symptome: Vor Einführung eines Sidecars funktionierte der Traffic, danach nicht. Ursache: Sidecars bauen eigene Verbindungen zu Control Planes, Telemetry, Zertifikatsdiensten auf; außerdem ändern sich Ports und Ziel-IPs aus Sicht der Policies.

Systematisches Vorgehen: Die blockierende Rule in 8 klaren Schritten

Debugging-Tools und Signale: Was Ihnen wirklich hilft

Ohne Observability bleibt NetworkPolicy-Debugging mühsam. Welche Tools sinnvoll sind, hängt vom CNI ab. Der gemeinsame Nenner: Sie brauchen entweder Policy-Entscheidungslogs („dropped because…“) oder zumindest Paket-/Flow-Signale (Drops, Conntrack, iptables counters).

Wenn Ihr CNI iptables/nftables nutzt

Wenn Ihr CNI eBPF nutzt

eBPF-basierte CNIs können oft bessere Einsicht liefern, weil Policy-Entscheidungen näher am Datenpfad beobachtbar sind. Bei Cilium sind z. B. Hubble und Policy-Visibility ein verbreiteter Ansatz für „wer redet mit wem und was wird gedroppt“. Einstieg: Cilium Hubble Observability.

Wichtige Debugging-Signale unabhängig vom Tool

Mehrere Policies gleichzeitig: So vermeiden Sie falsche Schlüsse

In größeren Clustern existieren meist mehrere Policy-Schichten: Baseline-Policies (z. B. Default Deny im Namespace), team-spezifische Policies und manchmal zusätzliche CNI-spezifische Erweiterungen (z. B. Calico GlobalNetworkPolicy oder CiliumClusterwideNetworkPolicy). Das kann Debugging verkomplizieren, weil der „Block“ nicht aus einer einzigen NetworkPolicy stammen muss.

Wenn Sie in so einer Umgebung arbeiten, prüfen Sie explizit, ob neben Standard-NetworkPolicies zusätzliche Policy-CRDs aktiv sind. Calico und Cilium dokumentieren ihre erweiterten Policy-Modelle jeweils in ihren offiziellen Guides, z. B. Calico GlobalNetworkPolicy oder Cilium Policy Language.

Die häufigsten „blockierenden Regeln“ sind eigentlich Datenqualitätsprobleme

In der Praxis liegt die Ursache sehr oft nicht in „falscher Logik“, sondern in Datenqualität: Labels, die nicht gesetzt sind, Namespaces, die uneinheitlich klassifiziert sind, oder Workloads, die Ports dynamisch nutzen. Deshalb lohnt es sich, Debugging-Erkenntnisse in Standards zu überführen.

Minimal-invasive Fixes: Wie Sie schnell wieder Betrieb herstellen, ohne Sicherheit zu verlieren

Wenn Produktion brennt, ist die Versuchung groß, eine Policy „kurz zu öffnen“. Change Safety bedeutet, dass Sie temporäre Ausnahmen so klein wie möglich halten, klar dokumentieren und wieder entfernen. Der beste Fix ist meist eine präzise Allow-Regel statt einer breiten CIDR-Öffnung.

Checkliste: Schnell die blockierende Rule finden

Weiterführende Quellen für NetworkPolicy-Debugging und Implementierungen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Lieferumfang:

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.

 

Exit mobile version