Site icon bintorosoft.com

Pod hat kein Internet: Troubleshooting (vollständiges Runbook)

Red Snapper

Wenn ein Pod hat kein Internet-Problem in Kubernetes auftritt, wirkt das oft wie ein einzelner Fehler („curl funktioniert nicht“). In der Praxis steckt dahinter jedoch fast immer eine Kette aus Abhängigkeiten: DNS-Auflösung (CoreDNS), Netzwerkpfade im Cluster (CNI), egress-spezifische Policies (NetworkPolicy), Node- oder Cloud-Firewalls (Security Groups/NSGs, NACLs), NAT-Gateways oder Proxy-Vorgaben. Genau deshalb lohnt sich ein vollständiges, reproduzierbares Troubleshooting-Runbook. Es hilft, das Problem schnell einzugrenzen: Ist es wirklich „kein Internet“ oder „kein DNS“, „kein Egress auf Port 443“, „nur bestimmte Ziele“, „nur bestimmte Namespaces“ oder „nur auf bestimmten Nodes“? Dieser Leitfaden führt Schritt für Schritt durch eine praxiserprobte Diagnose – von der ersten Triagierung über gezielte Tests im Pod bis zur Cloud-Netzwerkebene. Sie erhalten konkrete Prüfungen und typische Ursachen, inklusive Maßnahmen, die Sie sicher und nachvollziehbar anwenden können, ohne in unkontrollierte „Allow all“-Änderungen zu verfallen.

Scope und Definition: Was bedeutet „Pod hat kein Internet“ konkret?

Bevor Sie Änderungen vornehmen, definieren Sie die Störung messbar. „Kein Internet“ kann unterschiedliche Symptome meinen. Eine saubere Eingrenzung spart Zeit und verhindert Fehlfixes.

Vorbereitung: Ein Debug-Pod, der verlässliche Tests erlaubt

Für reproduzierbare Tests nutzen Sie einen temporären Debug-Pod im betroffenen Namespace. Das Ziel ist, Standardtools (DNS, TCP, HTTP) verfügbar zu haben. Falls Ihre Security-Policy keine Debug-Images zulässt, nutzen Sie ein freigegebenes internes Debug-Image.

Minimaler Testkatalog im Pod

Schritt 1: Schnelltriage – DNS oder Netzwerk?

Trennen Sie DNS-Probleme konsequent von Transportproblemen. Das verhindert, dass Sie NAT/Firewall anfassen, obwohl CoreDNS die eigentliche Ursache ist.

Test A: DNS-Auflösung

Test B: TCP/HTTPS ohne DNS (nur zur Eingrenzung)

Schritt 2: Cluster-DNS prüfen (CoreDNS, Upstream, Policies)

Wenn DNS nicht funktioniert, ist „kein Internet“ oft nur eine Folge. CoreDNS kann ausfallen, falsch konfiguriert sein oder durch NetworkPolicies blockiert werden.

Typische Fixes bei DNS-Problemen

Schritt 3: Egress-Policies im Kubernetes-Layer (NetworkPolicy) prüfen

Wenn DNS funktioniert, aber HTTP/HTTPS nicht, ist eine egress-blockierende NetworkPolicy sehr wahrscheinlich – insbesondere in Sicherheits-Namespaces. NetworkPolicies sind label-basiert; ein fehlendes Label kann einen Pod „aus Versehen“ komplett isolieren.

Sicherer Ansatz: Minimaler Egress statt „Allow all“

Statt pauschal allen Egress zu erlauben, definieren Sie einen minimalen Satz, der betrieblich nötig ist (DNS, Proxy/Egress Gateway, Paket-Registry, Telemetrie). Langfristig ist das stabiler und auditierbar.

Schritt 4: ServiceAccount, Proxy-Variablen und Applikationskonfiguration prüfen

Manchmal ist das Netzwerk in Ordnung, aber die Anwendung kann dennoch „nicht ins Internet“, weil Proxy- oder TLS-Einstellungen fehlen oder falsch sind.

Fehlerbild: DNS ok, TCP ok, aber TLS bricht

Wenn curl -v zeigt, dass TCP verbindet, aber TLS fehlschlägt, prüfen Sie Zertifikate, Proxy, SNI/ALPN und mögliche Interception. Das ist kein klassisches Routing-/NAT-Problem.

Schritt 5: Node- und CNI-Ebene – wenn nur manche Pods betroffen sind

Wenn nur Pods auf bestimmten Nodes kein Internet haben, liegt die Ursache häufig unterhalb von Kubernetes-Objekten: CNI, Node Routing, iptables/eBPF, Kernel-Parameter oder ein lokaler Security Agent.

MTU-Probleme: „Klein geht, groß bricht“

Wenn kleine Requests funktionieren, größere Downloads aber hängen oder abbrechen, ist MTU/Fragmentierung eine häufige Ursache (Overlay-Netze, VPN, Cloud-Encapsulation). Symptome sind sporadische Timeouts und Retries, besonders bei TLS (größere Handshakes) oder Container-Registries.

Schritt 6: Cloud-Netzwerkebene – Routing, NAT, Firewalls, private Cluster

In Managed Kubernetes liegt „Internet“ fast immer hinter einer Cloud-Netzwerkarchitektur. In privaten Subnetzen braucht Egress typischerweise NAT oder einen zentralen Egress-Proxy. Fehlt dieser Pfad, bleibt der Pod vollständig intern.

Rückverkehr und Ephemeral Ports: Häufige Misskonfiguration

Für ausgehende TCP-Verbindungen brauchen Clients lokale ephemeral source ports. Wenn eine NACL oder Firewall Rücktraffic auf diese Ports blockiert, sehen Sie Timeouts. Als Grundprinzip gilt: Outbound allow allein reicht nicht; Rückrichtung muss stateful oder explizit passend erlaubt sein.

Schritt 7: Egress über DNS/FQDN-Policies und „nur bestimmte Ziele“

Wenn der Pod einige Domains erreicht, andere nicht, ist die Ursache oft policy- oder reputationsbasiert: FQDN-Filter, Proxy-Kategorien, oder restriktive Egress-Allowlisten. Das ist in gehärteten Umgebungen normal, muss aber transparent sein.

Schritt 8: Beobachtbarkeit – welche Logs und Metriken Sie brauchen

Ein gutes Runbook setzt auf Telemetrie statt auf Vermutungen. Ziel ist, die Blockstelle zu lokalisieren: NetworkPolicy? Node-Firewall? Cloud-NACL? NAT-Bottleneck? Proxy-Block?

Schnelle Heuristik: Timeout vs. Refused

Schritt 9: Remediation-Playbook – sichere Fixes in sinnvoller Reihenfolge

Die folgenden Maßnahmen sind so geordnet, dass Sie zuerst die wahrscheinlichsten und risikoärmsten Fixes adressieren. Vermeiden Sie es, mehrere Änderungen gleichzeitig zu machen, sonst verlieren Sie die Ursache-Wirkung-Kette.

Wenn Sie eine temporäre Ausnahme brauchen

In produktiven Incidents ist manchmal eine temporäre Egress-Freigabe nötig. Halten Sie diese Ausnahme so eng wie möglich (nur betroffener Namespace, nur Ports 443/80, nur über Proxy/Egress Gateway) und versehen Sie sie mit Ablaufdatum und Ticket-Referenz im Change-Prozess.

Runbook als Checkliste (Copy-Paste-ready)

Häufige Ursachen im Überblick (mit schnellen Indikatoren)

Outbound-Links zu relevanten Informationsquellen

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