Pod-to-Pod Intermittent Drops: Häufige Ursachen (CPU, IRQ, CNI, Policy)

„Pod-to-Pod Intermittent Drops“ sind eines der frustrierendsten Probleme im Kubernetes-Betrieb: Die Anwendung wirkt „meistens“ gesund, Liveness-Probes sind grün, aber vereinzelt scheitern RPCs, Timeouts häufen sich, oder es gibt sporadische connection reset-Fehler. Diese unregelmäßigen Paketverluste oder Verbindungsabbrüche zwischen Pods lassen sich selten mit einer einzelnen Ursache erklären. Häufig entstehen sie durch eine Kombination aus Ressourcendruck (CPU, IRQ/SoftIRQ, Memory Pressure), Kernel- und conntrack-Limits, CNI- und Overlay-Effekten, eBPF/iptables-Interaktionen, sowie Policies oder Service-Mesh-Regeln, die unter Last anders wirken als im Normalbetrieb. Wer Pod-to-Pod Intermittent Drops nachhaltig beheben will, braucht ein strukturiertes Vorgehen: Zuerst Eingrenzen (nur ein Namespace, nur bestimmte Nodes, nur Cross-Zone?), dann Messpunkte definieren (Node, CNI, Policy, Service), und schließlich Hypothesen mit reproduzierbaren Tests bestätigen. Dieser Artikel erklärt die häufigsten Ursachen – mit Schwerpunkt auf CPU/IRQ, CNI und Policy – und zeigt, wie Sie die Fehlerbilder sauber voneinander trennen, ohne in endlosen „es könnte alles sein“-Schleifen stecken zu bleiben.

Was bedeutet „Intermittent Drops“ im Pod-to-Pod-Kontext?

Mit „Drops“ sind nicht immer echte IP-Paketverluste im physikalischen Netzwerk gemeint. In Kubernetes kann ein „Drop“ auf vielen Ebenen entstehen:

• Packet Drop im Kernel (z. B. RX/TX-Drops, Queue Overruns, conntrack-Drops).
• Policy Drop durch NetworkPolicy/eBPF (Cilium) oder iptables (Calico/iptables-mode).
• Service/Load-Balancing-Artefakte (kube-proxy iptables/IPVS, Endpoint-Flaps, conntrack-Stale).
• Overlay-/Encapsulation-Probleme (VXLAN/Geneve/IPIP, MTU, Fragmentation, PMTUD).
• App-nahe Abbrüche, die wie Drops aussehen (Server überlastet, Accept-Queue voll, gRPC Keepalive/MaxConcurrentStreams).

Das Entscheidende ist: Ein sporadischer Fehler auf Anwendungsebene ist oft das erste sichtbare Symptom, während die Root Cause tiefer im Node- oder CNI-Stack liegt.

Schnelle Eingrenzung: Muster erkennen, bevor Sie tiefer debuggen

Bevor Sie in Kernel-Zähler und CNI-Details abtauchen, lohnt ein kurzer „Scope-Check“. Viele Ursachen lassen sich über einfache Muster eingrenzen:

• Node-spezifisch: Nur Pods auf bestimmten Nodes sind betroffen → häufig CPU/IRQ, conntrack, NIC/Driver, CNI-Daemonset-Probleme.
• Pfad-spezifisch: Nur Cross-Node oder Cross-Zone betroffen → Overlay, MTU, Routing, Underlay-Latenz/Jitter, Cloud-Networking.
• Workload-spezifisch: Nur bestimmte Services → Policy/Label-Selektoren, Service-Mesh, einzelne Ports/Protokolle.
• Last-korreliert: Drops steigen bei Deployments, Batch-Jobs, Traffic-Spikes → CPU-Sättigung, SoftIRQ, conntrack, NAT/NodePort.
• Zeit-korreliert: Drops nach Knotenrotation, CNI-Upgrade, Policy-Change → Regression/Config-Drift.

CPU-Sättigung: Wenn Netzwerkprobleme eigentlich Scheduling-Probleme sind

CPU ist eine der häufigsten Ursachen, weil Kubernetes-Netzwerkpfade nicht „kostenlos“ sind. Paketverarbeitung benötigt CPU-Zeit: Interrupts, SoftIRQ, conntrack-Lookups, iptables-Regeln, eBPF-Programme, Encapsulation/Decapsulation und ggf. Verschlüsselung. Wenn ein Node CPU-seitig am Limit ist, kann er Pakete verspätet verarbeiten oder verwerfen. Das zeigt sich als sporadische Drops, hohe Latenz und Retransmits, ohne dass das physische Netzwerk „kaputt“ ist.

Typische CPU-Indikatoren bei Pod-to-Pod Intermittent Drops

• Hohe CPU-Utilization auf Node oder in System-Daemons (kube-proxy, CNI, log agents).
• Load Average hoch, aber nicht unbedingt „CPU 100%“ (Runqueue-Pressure).
• SoftIRQ/NET_RX auffällig: Netzwerk-Interrupt-Handling dominiert CPU-Zeit.
• Steigende TCP-Retransmits und Latenzspitzen bei gleichbleibender RPS.
• Packet Drops in NIC-Queues (RX ring overrun), besonders bei Burst-Traffic.

Warum CPU-Limits in Pods indirekt Netzwerkdrops erzeugen

Auch wenn das Problem „Pod-to-Pod“ aussieht, kann ein einzelner überlasteter Empfänger-Pod Drops provozieren: Wenn der Server-Prozess nicht schnell genug liest, füllen sich Socket-Buffer, Accept-Queues oder die App-Worker sind blockiert. Auf Sender-Seite sieht das wie Netzwerkflakiness aus. Unter CPU-Throttling (CFS) können Pods zudem in kurzen Intervallen „eingefroren“ werden, wodurch Keepalives, ACKs oder Request-Handling verzögert werden.

IRQ und SoftIRQ: Der versteckte Engpass auf dem Node

Wenn „CPU“ als Ursache genannt wird, ist oft nicht die Applikations-CPU gemeint, sondern IRQ/SoftIRQ-Last: Netzwerkpakete lösen Interrupts aus, werden in SoftIRQ-Kontext verarbeitet (z. B. ksoftirqd), und erst dann landen sie in den höheren Netzwerk-Schichten. Wenn diese Pipeline überlastet ist, droppen Pakete oder werden so spät verarbeitet, dass Timeouts entstehen.

Häufige Ursachen für IRQ/SoftIRQ-Probleme

• Ungünstige IRQ-Affinität: Viele NIC-Interrupts landen auf wenigen CPU-Cores.
• Zu kleine RX/TX-Ringe oder fehlendes/inkorrektes NIC-Offloading.
• CPU-Pinning-Konflikte (z. B. isolcpus, Performance-Tuning ohne Netzwerkbezug).
• Sehr viele kleine Pakete (PPS-Last) statt hoher Bandbreite.
• eBPF/iptables-Komplexität, die die Paketverarbeitung pro Paket verteuert.

CNI und Overlay: Encapsulation, MTU und Fragmentation als Drop-Quelle

Viele Cluster nutzen Overlays (VXLAN, Geneve, IPIP) oder eBPF-basierte Datenpfade. Overlays erhöhen Header-Overhead und reduzieren die effektive MTU. Wenn die MTU in der Kette nicht sauber abgestimmt ist, passiert das klassische „Small works, large fails“ – in subtiler Form: nicht komplett, sondern intermittierend, abhängig von Paketgröße, Path MTU Discovery und Paketfragmentierung. Auch wenn alles „meistens“ klappt, können einzelne Flows mit größeren Segmenten scheitern, besonders bei TLS/gRPC oder großen JSON-Payloads.

MTU-Drops erkennt man oft an diesen Symptomen

• Nur bestimmte Requests betroffen (z. B. große Responses, Uploads, gRPC mit großen Messages).
• Retransmits ohne klaren Grund, eventuell ICMP „Fragmentation needed“ fehlt (geblockt).
• Probleme stärker bei Cross-Node/Cross-Zone als bei Same-Node.
• Unterschiedliche Pfade (z. B. Nodes in verschiedenen Subnetzen/ENIs) zeigen unterschiedliche Stabilität.

CNI-spezifische Failure Modes (Calico, Cilium, Flannel & Co.)

• Datapath-Modus-Mix: iptables vs. eBPF, unterschiedliche Semantik bei Policy und Conntrack.
• Encapsulation-Mismatch: z. B. IPIP/VXLAN nicht konsistent, oder nur auf Teilmenge der Nodes aktiv.
• ARP/ND-Probleme bei bestimmten CNI-Setups, die sich als sporadische Erreichbarkeitslücken zeigen.
• Node-to-Node Keying/Encryption (z. B. WireGuard/IPsec) mit CPU/MTU-Overhead.
• Upgrade-Übergänge: kurzzeitige Inkonsistenzen in BPF-Maps oder iptables-Regeln während Rollouts.

Für den grundlegenden Einstieg in Kubernetes-Netzwerkmodelle und CNI-Verständnis ist die offizielle Dokumentation zu Services und Networking hilfreich: Kubernetes Services & Networking.

Conntrack und State: Wenn der Kernel „denkt“, der Flow ist anders

Viele Pod-to-Pod-Verbindungen sind stateful: TCP, aber auch UDP-Flows mit conntrack. In Kubernetes spielen conntrack-Tabellen eine große Rolle, insbesondere bei kube-proxy (iptables) und NAT/NodePort. Wenn conntrack überläuft oder Einträge zu früh auslaufen, entstehen Drops oder unerwartete RSTs. Besonders tückisch: Das kann intermittierend sein – abhängig von Traffic-Spikes und Flow-Churn.

Typische conntrack-Indikatoren

• conntrack table full: Pakete werden gedroppt, neue Verbindungen scheitern sporadisch.
• Hohe Flow-Churn: Viele kurzlebige Verbindungen (z. B. aggressive Retries, fehlendes Keep-Alive).
• Ungünstige Timeouts: UDP- oder TCP-State läuft früher aus als Applikation erwartet.
• NodePort/Service-NAT: Zusätzliche NAT-Stufen erhöhen conntrack-Druck.

Wenn Sie tiefer in kube-proxy-Modi und deren Auswirkungen einsteigen möchten, ist diese Referenz hilfreich: kube-proxy Referenz (iptables/IPVS Kontext).

NetworkPolicy und Security Controls: „Drops“ durch Regeln statt durch Netz

NetworkPolicies oder Provider-spezifische Policies (z. B. CiliumNetworkPolicy) sind eine häufige Quelle intermittierender Drops – nicht weil Regeln „zufällig“ sind, sondern weil sich Labels, Endpoints oder Selektoren dynamisch ändern. Ein Pod-Rollout kann kurzfristig zu einem Zustand führen, in dem neue Pods nicht korrekt selektiert sind, oder ein Policy-Update wird inkonsistent auf Nodes angewendet, bis der Controller converged ist.

Policy-Failure-Muster

• Nur bestimmte Ports/Protokolle betroffen: z. B. gRPC-Port geblockt, Health-Port offen.
• Nur neue Pods betroffen: alte Pods funktionieren, neue Deployment-Replica nicht.
• Cross-Namespace-Kommunikation bricht sporadisch: Label/NamespaceSelector nicht stabil.
• „Default deny“ aktiv, aber Ausnahmen unvollständig oder abhängig von Labels, die erst später gesetzt werden.

Zum Nachschlagen der NetworkPolicy-Semantik eignet sich die offizielle Kubernetes-Dokumentation: Network Policies in Kubernetes.

CNI-Policy-Implementierung: iptables vs. eBPF und die Nebenwirkungen

Ob eine Policy über iptables oder eBPF umgesetzt wird, kann die Failure Modes verändern. iptables-Regeln können sehr umfangreich werden und unter hoher Paketlast CPU kosten. eBPF-Policys können effizient sein, bringen aber eigene Komplexität mit (Map-Pressure, Program-Attachments, Verifier-Limits, Upgrade-Risiken). Intermittent Drops entstehen oft dann, wenn der Datenpfad unter Last an eine Grenze kommt und Pakete nicht mehr rechtzeitig verarbeitet werden.

Service Discovery und Endpoint-Flaps: Wenn „Pod-to-Pod“ eigentlich „Pod-to-Service“ ist

Viele Teams debuggen „Pod A zu Pod B“, obwohl tatsächlich „Pod A zu Service S“ gemeint ist. Wenn Endpoints im Service häufig wechseln (Rollouts, Autoscaling, CrashLoop), kann es zu kurzen Blackholes kommen – insbesondere, wenn Clients aggressiv cachen, DNS TTLs ungünstig sind, oder Connection Pools auf alte Ziele zeigen.

• Endpoints wechseln schnell: Clients mit Keep-Alive halten Verbindungen zu Pods, die gerade terminiert werden.
• Readiness Gates: Traffic geht zu Pods, die zwar „ready“ erscheinen, aber intern noch nicht warm sind (z. B. Sidecar noch nicht verbunden).
• Session Affinity: Unbeabsichtigte Hotspots, die wie Drops wirken (überlastete einzelne Backends).

IRQ/CPU/CNI/Policy in der Praxis korrelieren: Welche Daten sind „Pflicht“?

Intermittent Drops lassen sich selten mit einem einzelnen Log erklären. Bewährt hat sich ein Minimum an Telemetrie, das Node, Netzwerkpfad und Policy-Layer abdeckt:

• Node CPU & Load (inkl. System-CPU-Anteil), plus zeitliche Korrelation zu Drop-Events.
• SoftIRQ/NET_RX und ksoftirqd-Aktivität, besonders auf betroffenen Nodes.
• NIC-Statistiken (RX/TX drops, errors) und Queue-Auslastung.
• Conntrack-Auslastung und Drop-Zähler (table full, insert failed).
• CNI-Metriken/Logs (Policy-Drops, Encapsulation-Stats, BPF map pressure).
• Policy-Events (Änderungen an NetworkPolicies, Controller-Errors).
• Service/Endpoint-Churn (Anzahl Endpoint-Updates pro Minute).

Messbare Definition: Drop-Rate statt „gefühlt flaky“

Für SRE/On-Call hilft es, aus Symptomen eine Metrik zu machen. Eine einfache Drop-Rate kann als Anteil verlorener/abgewiesener Pakete oder Verbindungen pro Zeitfenster betrachtet werden. Auch wenn Sie die „echten“ Paketverluste nicht überall messen können, ist ein konsistentes Verhältnis hilfreich, um Vorher/Nachher zu vergleichen.

$\mathrm{DropRate}=\frac{\mathrm{Drops}}{\mathrm{Total}}$

Wenn Sie z. B. TCP-Retransmits oder Policy-Drops als Drops definieren und die Gesamtzahl relevanter Pakete/Flows als Total, können Sie Änderungen an IRQ-Affinität, MTU oder Policies quantifizieren, statt nur subjektiv zu bewerten.

Konkrete Ursachenliste: Die häufigsten Trigger für Pod-to-Pod Intermittent Drops

• CPU-Pressure auf Nodes durch hohe Paketlast, zu viele iptables-Regeln oder eBPF-Overhead.
• IRQ-Affinität ungünstig, NIC-Interrupts konzentrieren sich auf wenige Cores.
• Conntrack table full durch Flow-Churn, NodePort/NAT oder aggressive Retries.
• MTU-Mismatch im Overlay/Underlay, ICMP gefiltert, Fragmentation-Probleme.
• CNI-Rollout/Regression, inkonsistente Regeln oder BPF-Map-States während Updates.
• NetworkPolicy-Selektoren instabil (Labels fehlen temporär, NamespaceSelector falsch, default deny ohne vollständige Allow-Rules).
• Endpoint-Churn bei Deployments, Traffic zu terminating Pods ohne ausreichendes Draining.
• Service Mesh/Sidecar Limits (z. B. Envoy Ressourcen, Connection Pools, Listener Overload).
• Kernel/Driver-Probleme (Drops auf NIC-Level, Offload-Features inkompatibel mit Overlay).

Praktische Mitigation: Was typischerweise nachhaltig hilft

Die „beste“ Maßnahme hängt von der Ursache ab. Dennoch gibt es wiederkehrende, robuste Verbesserungen, die Intermittent Drops deutlich reduzieren können:

• Node-Ressourcen schützen: System-Reserved/Kernel-Reserved sauber setzen, damit kubelet/CNI/kube-proxy nicht verhungern.
• CPU-Pinning mit Bedacht: IRQ/SoftIRQ nicht aus Versehen auf „die falschen“ Cores drücken.
• Conntrack dimensionieren: Max-Werte und Timeouts passend zum Flow-Profil wählen, Retries entschärfen.
• MTU explizit planen: Effektive MTU für Overlay/Encryption dokumentieren und konsequent konfigurieren.
• Policy-Änderungen kontrollieren: Canary-Policies, stufenweise Rollouts, saubere Label-Standards.
• Endpoint-Handling verbessern: Readiness streng, TerminationGracePeriod und Connection Draining berücksichtigen.
• Lastprofile testen: Nicht nur RPS, sondern PPS/Connection-Churn und „Deployment-Bursts“ simulieren.

Outbound-Links für vertiefende Informationen

• Kubernetes Services & Networking – Konzepte
• NetworkPolicy – Funktionsweise und Semantik
• kube-proxy Referenz – iptables/IPVS Hintergründe
• Cilium Kubernetes Networking – eBPF Datapath und Policies
• Calico Network Policy – Policy-Model und Troubleshooting-Ansätze

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.