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

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.

• DNS-Problem: Namen lassen sich nicht auflösen (z. B. nslookup liefert SERVFAIL/NXDOMAIN oder hängt).
• TCP-Problem: DNS geht, aber Verbindungen auf 80/443 schlagen fehl (Timeout, Connection refused).
• Routing/NAT-Problem: IP-Ziele sind nicht erreichbar, häufig nur in privaten Subnetzen oder in privaten Clustern.
• Policy-Problem: Nur bestimmte Pods/Namespaces sind betroffen (NetworkPolicy, egress firewall, egress gateway, Proxy-Regeln).
• Ziel-spezifisch: Nur einzelne Domains oder IP-Ranges sind betroffen (SaaS, CRL/OCSP, Paket-Repos, Registry).
• Node-spezifisch: Pods auf bestimmten Nodes haben kein Internet (Node Routing, CNI, iptables/eBPF, Security Agent).

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.

• Starten Sie einen kurzlebigen Pod mit Tools wie curl, dig/nslookup, ip, traceroute (falls erlaubt) oder zumindest wget.
• Stellen Sie sicher, dass der Debug-Pod die gleiche NetworkPolicy/ServiceAccount/Labels hat wie der betroffene Pod, sonst testen Sie am Problem vorbei.

Minimaler Testkatalog im Pod

• DNS: nslookup example.com oder dig example.com
• IP-Konnektivität: curl -sS https://1.1.1.1 (wenn HTTPS per IP erlaubt ist) oder curl -I https://example.com
• TCP-Port: curl -v https://example.com (zeigt DNS, TCP, TLS Schritt für Schritt)
• Routen: ip route
• DNS-Konfig: cat /etc/resolv.conf

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

• Prüfen Sie im Pod /etc/resolv.conf: Welche Nameserver sind eingetragen? Welche Search-Domains?
• Führen Sie nslookup kubernetes.default.svc aus. Wenn das nicht geht, ist die Cluster-DNS-Funktionalität gestört.
• Führen Sie nslookup example.com aus. Wenn Cluster-intern geht, extern aber nicht, liegt häufig ein Forwarding-/Upstream-DNS-Problem vor.

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

• Wenn erlaubt, testen Sie eine bekannte IP: curl -v https://1.1.1.1. Ein TLS-Fehler ist hier nicht automatisch „schlecht“; wichtig ist, ob überhaupt eine TCP-Verbindung zustande kommt.
• Alternativ: ein kontrollierter externer Endpoint Ihres Unternehmens, der IP-basierte Tests unterstützt.

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.

• CoreDNS Health: Prüfen Sie, ob CoreDNS-Pods laufen und Ready sind. Häufige Symptome sind CrashLoopBackOff, hohe Latenz oder Timeouts.
• DNS-Traffic erlaubt?: NetworkPolicies müssen egress UDP/TCP 53 zum CoreDNS-Service zulassen. In „Default Deny“-Namespaces ist das der Klassiker.
• Upstream DNS erreichbar?: CoreDNS forwarded oft an einen VPC/VNet-Resolver oder Unternehmens-DNS. Wenn dieser Upstream nicht erreichbar ist, gehen externe Domains nicht.
• Search-Domains/ndots: Bei sehr vielen Search-Domains oder hohem ndots können DNS-Queries „explodieren“ und Zeit kosten.

Typische Fixes bei DNS-Problemen

• NetworkPolicy ergänzen: egress zu CoreDNS-Service auf UDP/TCP 53 erlauben.
• CoreDNS-Konfiguration prüfen: Forwarder korrekt? Timeouts? Caching sinnvoll?
• Wenn nur externe Domains scheitern: Upstream Resolver (VPC/VNet DNS, On-Prem DNS) prüfen und dessen Erreichbarkeit sicherstellen.

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.

• Existiert eine Default-Deny-Policy? Prüfen Sie, ob im Namespace egress standardmäßig verboten ist.
• Erlaubt die Policy die richtigen Ports? Für Internet-Zugriff sind meist TCP 443 und ggf. 80 nötig. Vergessen werden oft: 123/UDP (NTP), 53/UDP (DNS), 443 zu bestimmten Egress-Gateways.
• Erlaubt die Policy die richtigen Ziele? Viele Policies erlauben nur interne CIDRs; externe IPs fallen dann durch.
• NamespaceSelector/PodSelector korrekt? Ein Selector, der keine Pods matcht, führt effektiv zu „deny“.

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.

• Proxy-Umgebungsvariablen: Prüfen Sie HTTP_PROXY, HTTPS_PROXY, NO_PROXY. Falsches NO_PROXY kann interne Ziele über den Proxy schicken und brechen.
• CA-Zertifikate: Bei TLS-Inspection/Corporate Proxy müssen Root-CAs im Container vorhanden sein. Sonst sehen Sie TLS-Handshake-Fehler statt Timeouts.
• eBPF/Sidecars: In Service-Mesh-Umgebungen kann ein Sidecar Traffic umleiten. Wenn das Sidecar nicht korrekt konfiguriert ist, wirkt es wie „kein Internet“.

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.

• Node-Korrelation: Betroffene Pods nach Node gruppieren. Häufen sich Ausfälle auf einem Node-Pool oder einer AZ?
• CNI-Daemonset: Prüfen Sie, ob die CNI-Pods auf betroffenen Nodes healthy sind.
• iptables/ipvs/eBPF: Bei kube-proxy-Problemen oder eBPF-Umstellungen können NAT/Forwarding-Regeln fehlen oder inkonsistent sein.
• IP Forwarding: Node muss Traffic weiterleiten können; falsche Kernel-Settings oder Security Hardening können Forwarding blockieren.

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.

• Subnetz-Typ: Läuft der Node in einem privaten Subnetz ohne direkte Internet-Route? Dann ist NAT/Firewall-Egress zwingend.
• Route Tables: Gibt es eine Default-Route (0.0.0.0/0) zu NAT/Firewall? Fehlende oder falsche Routen sind ein Klassiker nach Änderungen.
• NAT-Kapazität: Bei hoher Last kann NAT zum Bottleneck werden (Port Exhaustion, Conntrack). Dann wirkt es wie „kein Internet“, aber nur unter Last oder für neue Verbindungen.
• Security Groups/NSGs: Egress kann auf Node- oder Interface-Ebene blockiert werden. Prüfen Sie besonders TCP 443/80 und DNS zu Resolvern.
• NACLs: Subnetzbasierte ACLs können Rückverkehr blockieren, wenn ephemeral ports nicht erlaubt sind.
• Firewall/Proxy-Policies: Zentrale Firewalls blockieren Kategorien/Ziele oder nur bestimmte Ports (z. B. nur 443 erlaubt).

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.

• FQDN-Policies: Einige CNIs/Firewalls erlauben Egress nur zu bestimmten Domains. Prüfen Sie, ob die Domain in der Allowlist ist.
• SNI/HTTPS: Bei TLS-basierten Policies wird häufig SNI verwendet. Fehlt SNI (z. B. bei IP-basiertem Zugriff), kann es blockiert werden.
• CDN/Anycast: Gleiche Domain kann zu wechselnden IPs auflösen. IP-Allowlisten ohne regelmäßige Pflege brechen dann intermittierend.
• OCSP/CRL: TLS-Prüfungen können externe Endpunkte benötigen. Wenn diese blockiert sind, entstehen TLS-Verzögerungen oder Fehler.

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?

• CoreDNS Logs/Metriken: SERVFAIL-Raten, Latenzen, Upstream-Timeouts.
• CNI/NetworkPolicy Logs: Drops, denied flows, policy hits (abhängig vom Plugin).
• Flow Logs (Cloud): Accept/Deny auf Subnetz/Interface, besonders für 443/80 und DNS.
• NAT-Metriken: Verbindungsanzahl, Fehler, Port-Auslastung, Conntrack-Nutzung (je nach Plattform).
• Ingress/Egress Proxy Logs: Blockgründe, Kategorien, Zielhost, Statuscodes.

Schnelle Heuristik: Timeout vs. Refused

• Timeout deutet häufig auf Drop/Block im Pfad hin (Policy/Routing/NACL/Firewall/NAT).
• Connection refused deutet eher auf Ziel erreichbar, aber Port/Service nicht offen (falscher Port, falscher Endpoint).
• TLS-Fehler deutet häufig auf Zertifikate/Proxy/Inspection hin, nicht auf reines Routing.

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.

• DNS wiederherstellen: CoreDNS stabilisieren, DNS-Egress erlauben, Upstream Resolver erreichbar machen.
• NetworkPolicy minimal erweitern: DNS + erforderliche Ports zu definierten Zielen (Proxy/Egress Gateway) erlauben.
• Proxy/CA korrekt konfigurieren: HTTPS-Proxy und Root-CAs sauber verteilen, NO_PROXY prüfen.
• Cloud Routing korrigieren: Default-Route zu NAT/Firewall sicherstellen, falsche Route Tables beheben.
• NACL/Firewall Rückpfade fixen: Ephemeral Ports/Rückrichtung korrekt, stateful Verhalten prüfen.
• NAT-Bottleneck entschärfen: Skalierung/Mehrfach-NAT, Workload-Verteilung, Timeouts/Keepalive prüfen.
• Node/CNI reparieren: CNI Daemonset neu starten/rollen, Node drain/replace bei node-spezifischen Defekten.

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)

• Symptom definieren: DNS vs. TCP vs. TLS; betroffen: alle Pods oder subset (Namespace/Node)?
• Debug-Pod starten: gleicher Namespace, gleiche Policies/Labels; Tests: resolv.conf, DNS, curl -v, ip route.
• DNS prüfen: CoreDNS healthy? DNS-Egress erlaubt? Upstream Resolver erreichbar?
• NetworkPolicy prüfen: Default deny? Egress zu DNS/443/80 erlaubt? Selector korrekt?
• Proxy/TLS prüfen: Proxy-Variablen, NO_PROXY, CA-Bundles, TLS-Inspection.
• Node-Scope prüfen: Nur bestimmte Nodes betroffen? CNI/kube-proxy/eBPF healthy?
• Cloud Routing prüfen: Private Subnetze haben NAT/Firewall? Default-Route korrekt?
• Cloud Firewalls/NACLs: Egress + Rückrichtung (ephemeral ports/stateful) korrekt?
• NAT-Bottleneck prüfen: Port Exhaustion/Conntrack/Fehlerraten; nur unter Last?
• Telemetrie sammeln: DNS-Logs, Flow Logs, Policy-Drops, Proxy-Logs; Korrelation mit Zeitfenster.
• Fix kontrolliert ausrollen: Eine Änderung, messen, dann nächste. Rollback-Schritt definieren.

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

• NetworkPolicy blockt DNS: Cluster-DNS geht nicht, Pods melden „name resolution failed“.
• Private Subnet ohne NAT: DNS ok, aber HTTP/HTTPS Timeouts; Route Table fehlt 0.0.0.0/0 zu NAT/Firewall.
• NACL blockt Rückverkehr: Unregelmäßige Timeouts, besonders bei neuen Verbindungen; deny in Flow Logs.
• Proxy/CA fehlt: TCP verbindet, TLS schlägt fehl; Logs zeigen Zertifikats-/Handshake-Probleme.
• NAT Port Exhaustion: Unter Last bricht Egress, neue Verbindungen schlagen fehl; Metriken zeigen hohe Auslastung.
• Node/CNI defekt: Nur einzelne Nodes betroffen; Pods nach Reschedule funktionieren wieder.

Outbound-Links zu relevanten Informationsquellen

• Kubernetes DNS für Pods und Services (CoreDNS-Grundlagen)
• Kubernetes NetworkPolicies: Egress/Ingress steuern
• Kubernetes Services: Port/TargetPort und Service-Typen
• Kubernetes Debugging Guide: Anwendungen und Pods debuggen
• CNI-Spezifikation: Container Network Interface
• AWS NAT Gateway: Funktionsweise und typische Limits
• Azure NAT Gateway: Überblick und Einsatz
• Google Cloud NAT: Überblick und Betrieb

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:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

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.