Intermittierende Drops: IRQ/CPU-Saturation auf Nodes

Intermittierende Drops: IRQ/CPU-Saturation auf Nodes sind eines der typischsten „Geisterprobleme“ in Kubernetes- und Cloud-Umgebungen: Es gibt Paketverlust, Timeouts und sporadische Verbindungsabbrüche – aber nur zeitweise. Die Dashboards zeigen vielleicht keine dauerhafte Überlast, die Applikation sieht nur erhöhte Retries, und ein klassischer Netzwerk-Test wirkt unauffällig. In der Praxis steckt dahinter oft keine „mystische“ Netzwerkanomalie, sondern ein sehr konkreter Engpass auf dem Node: CPU-Saturation im Kernelpfad, überlastete IRQ-Handler, SoftIRQ-Spitzen oder ein unglückliches Zusammenspiel aus NIC-Queues, Interrupt-Affinität, CNI-Datapath und Pod-Workload. Gerade weil das Problem intermittierend ist, wird es häufig in die falsche Richtung diagnostiziert (Load Balancer, CNI, DNS, Firewall), obwohl die eigentliche Ursache auf dem Host liegt. Wer Intermittierende Drops: IRQ/CPU-Saturation auf Nodes sauber versteht, kann Incidents erheblich schneller eingrenzen: Sind es echte Netzwerkdrops auf der Leitung, oder fehlen schlicht CPU-Zyklen, um Pakete rechtzeitig zu verarbeiten? Dieser Artikel erklärt die Mechanik hinter IRQs und SoftIRQs, typische Failure-Patterns in Kubernetes, die wichtigsten Metriken und Logs, sowie praxisnahe Maßnahmen, um Node-Netzwerkpfade stabil zu halten – ohne die Produktionsumgebung unnötig zu gefährden.

Was bedeutet „intermittierender Drop“ auf Node-Ebene?

Ein intermittierender Drop ist kein konstantes „Netzwerk ist kaputt“, sondern ein zeitweiser Verlust oder eine zeitweilige Verzögerung in der Paketverarbeitung. Auf Node-Ebene entstehen diese Effekte häufig dann, wenn die Paketverarbeitung im Kernel nicht mehr mit der eingehenden oder ausgehenden Paketrate Schritt halten kann. Das Resultat ist nicht immer ein sichtbarer „Packet Drop“-Counter an der NIC. Häufiger sehen Sie:

• TCP Retransmits: Die Anwendung merkt es als Latenzspitzen oder Timeouts.
• Verbindungsabbrüche: „connection reset“, „broken pipe“, gRPC-Stream-Resets.
• Nur bestimmte Nodes betroffen: Workloads, die dort landen, wirken instabil, andere sind unauffällig.
• Periodische Muster: Drops in Wellen (z. B. während Batch-Jobs, Deployments oder Telemetrie-Spikes).

Wichtig: Ein „Drop“ kann ein echter Paketverlust sein, oder ein Timing-Problem, das wie Verlust aussieht (weil TCP neu sendet oder Timeouts ablaufen). Genau deshalb ist die Zuordnung zu IRQ/CPU-Saturation so wertvoll.

IRQ, SoftIRQ und der Linux-Netzwerkpfad in Kurzform

Linux verarbeitet eingehende Pakete grob in zwei Stufen: Hardware-Interrupts (IRQs) und SoftIRQs. Moderne NICs nutzen dabei Mechanismen wie NAPI, um nicht für jedes Paket sofort einen Interrupt zu erzeugen, sondern Pakete in Batches abzuarbeiten. Trotzdem gilt: Irgendwo muss CPU-Zeit bereitstehen, um die Pakete aus den NIC-Ringen zu holen und durch den Netzwerkstack zu schieben.

• IRQ (Hardware Interrupt): Signal der NIC an die CPU, dass Arbeit anliegt.
• SoftIRQ: „Deferred Work“ im Kernel, u. a. Netzwerkverarbeitung (z. B. NET_RX).
• NAPI: Polling/Batching, um Interrupt-Stürme zu vermeiden.
• ksoftirqd: Kernel-Threads, die SoftIRQ-Arbeit übernehmen, wenn sie nicht inline abgearbeitet wird.

Wenn IRQ/SoftIRQ oder ksoftirqd dauerhaft oder in Bursts an Grenzen stoßen, steigt die Latenz im Paketpfad oder Pakete werden verworfen, weil Buffers/Ringe überlaufen.

Warum Kubernetes das Problem verstärken kann

Kubernetes bringt zusätzliche Verarbeitungsschritte und mögliche Hotspots, die in klassischen VM-Setups weniger ausgeprägt sind. Beispiele:

• CNI-Datapath: eBPF-Programme, iptables-Regeln, Encapsulation (VXLAN/Geneve), Policy-Matches.
• Service-Translation: kube-proxy (iptables/ipvs) oder eBPF-Service-LB.
• NAT/Masquerade: Conntrack-Last steigt bei viel Egress oder bei Service-NAT.
• Sidecars/Proxies: Zusätzliche Socket- und Copy-Pfade, mehr Kontextwechsel, mehr CPU.

Das bedeutet nicht, dass Kubernetes „schuld“ ist – aber es verschiebt das System in Bereiche, in denen CPU-Engpässe im Netzwerkpfad eher auftreten. Als Einstieg in die Konzepte rund um Kubernetes Networking ist die offizielle Dokumentation hilfreich: Kubernetes Networking Concepts.

Typische Ursachen für IRQ/CPU-Saturation auf Nodes

Intermittierende Drops entstehen meist durch eine Kombination aus Lastmustern und ungünstiger Verteilung. Häufige Ursachen sind:

• Zu hohe Packet Rate (pps): Viele kleine Pakete belasten CPU stärker als wenige große bei gleichem Durchsatz.
• IRQ-Affinität auf wenigen Cores: NIC-Interrupts landen auf 1–2 CPUs, die dadurch saturieren.
• Ungünstige RSS/RPS-Konfiguration: Receive-Side-Scaling verteilt nicht sauber über Queues/Cores.
• CPU-Throttling: Besonders bei Burstable Nodes oder aggressivem Power-Management kann die verfügbare CPU-Leistung kurzfristig sinken.
• Host-CPU durch Pods belegt: „Noisy Neighbor“: CPU-lastige Pods verdrängen Kernelarbeit, obwohl Node-CPU im Schnitt nicht „100 %“ wirkt.
• Große iptables-Regelsätze: Viele Regeln erhöhen die Kosten pro Paket (Match-Ketten).
• Conntrack-Pressure: Viele neue Verbindungen pro Sekunde (NAT) erzeugen Zusatzkosten und Drops.
• NIC- oder Treiberlimits: Ring-Buffer, Queue-Limits oder fehlerhafte Offload-Settings.

Warum das Problem oft „intermittierend“ ist und nicht dauerhaft

Ein dauerhaftes CPU-Limit wäre leichter zu erkennen. Intermittierende Drops entstehen meist durch Bursts, die kurzzeitig über die Kapazität schießen. Das kann durch Traffic-Spitzen oder durch Systemereignisse passieren:

• Deployments/Scaling: Viele neue Pods erzeugen gleichzeitig neue Verbindungen (Warm-up, Healthchecks).
• Batch-Jobs: Kurzzeitige Spitzen in pps oder in parallel geöffneten Sockets.
• DNS- oder Telemetrie-Stürme: Viele kleine UDP-Pakete, hohe pps, oft unterschätzt.
• Retry-Stürme: Ein kleiner Verlust triggert Retries, die die Last weiter erhöhen (positive Rückkopplung).

Die Kernidee ist: Kurzzeitige Peaks können ksoftirqd und IRQs saturieren, bevor „Durchschnitts-CPU“ im Monitoring überhaupt auffällig wird.

Pflicht-Metriken, die IRQ/CPU-Saturation sichtbar machen

Um Intermittierende Drops: IRQ/CPU-Saturation auf Nodes zu diagnostizieren, brauchen Sie Metriken, die den Kernelpfad abbilden, nicht nur Applikationsmetriken. Besonders relevant sind:

• CPU nach Modi: user, system, irq, softirq, iowait (pro Node und pro Core).
• SoftIRQ-Auslastung: NET_RX/NET_TX, ksoftirqd CPU-Zeit.
• Interface Drops/Errors: RX/TX drops, overruns, ring buffer drops (pro Interface).
• TCP Retransmits: als indirektes Drop-/Queueing-Signal.
• Conntrack Counters: current, max, drops, insert_failed (wenn NAT im Pfad ist).
• Queueing: NIC Queue-Backlog, ggf. qdisc-Stats (je nach Setup).

Wichtig ist die Granularität: pro Node und idealerweise pro CPU-Core. Ein Node kann 64 Cores haben, aber wenn 2 Cores mit IRQ/softirq bei 100 % kleben, haben Sie trotzdem Drops, obwohl „gesamt“ nur 20–30 % CPU angezeigt werden.

Ein einfaches Verhältnis zur Einordnung

Ein nützlicher KPI ist der Anteil der Kernelzeit, die in IRQ/SoftIRQ geht. Das ist kein universeller Grenzwert, aber ein starkes Warnsignal, wenn es plötzlich steigt.

$\mathrm{IRQ\_Anteil}=\frac{\mathrm{CPU\_irq}+\mathrm{CPU\_softirq}}{\mathrm{CPU\_total}}$

Steigt dieser Anteil sprunghaft während der Drops, ist das ein sehr starker Hinweis auf Engpässe im Netzwerkpfad.

Erste Eingrenzung: Netzwerkproblem oder Node-CPU?

Ein pragmatischer Diagnosepfad hilft, nicht in Tooling zu versinken. Stellen Sie diese Fragen in der Reihenfolge:

• Ist es node-spezifisch? Wenn ja: Host-/IRQ-/CPU-Thema sehr wahrscheinlich.
• Korrelieren Drops mit CPU irq/softirq? Wenn ja: Fokus auf Kernelpfad.
• Sehen Sie TCP Retransmits ohne Interface Errors? Dann ist oft Queueing/CPU/Conntrack statt „kaputtes Kabel“ der Treiber.
• Gibt es einen Trigger? Deployments, Batch, neue Policy-Regeln, erhöhte DNS-Last.

Wenn Sie diesen Pfad konsequent gehen, vermeiden Sie den häufigen Fehler, zuerst an Load Balancer, Registry oder CNI-Config zu drehen, obwohl der Node schlicht keine CPU-Zeit für Paketverarbeitung hat.

Häufige Fehlinterpretationen in der Praxis

• „CPU ist nicht hoch, also nicht CPU“: Gesamt-CPU kann niedrig wirken, während einzelne Cores saturiert sind.
• „Keine Drops am Interface, also kein Verlust“: Drops können höher im Stack passieren (Softnet backlog, conntrack).
• „Nur ein Service betroffen, also Policy“: Ein Service kann zufällig auf den betroffenen Nodes liegen oder bestimmte pps-Muster erzeugen.
• „iperf sieht gut aus“: iperf misst oft Durchsatz, nicht pps- oder Tail-Latency-Probleme eines realen Workloads.

Konkrete technische Hebel: IRQ-Verteilung und RSS/RPS

Wenn Interrupthandling auf wenigen CPUs konzentriert ist, hilft häufig eine bessere Verteilung der Last. Zwei Schlüsselbegriffe:

• RSS (Receive-Side Scaling): Die NIC verteilt RX über mehrere Hardware-Queues, die idealerweise auf mehrere Cores gemappt sind.
• RPS/RFS (Receive Packet Steering / Flow Steering): Kernelmechanismen, um Pakete auf andere Cores zu verteilen, wenn RSS nicht reicht oder nicht verfügbar ist.

In vielen Umgebungen sind Defaults nicht optimal, besonders wenn Node-Typen wechseln oder Kernel-/Treiber-Versionen variieren. Eine saubere IRQ-Affinität und Queue-Zuordnung kann intermittierende Drops deutlich reduzieren. Für Hintergrundwissen zur Netzwerkverarbeitung im Linux-Kernel sind die Kernel-Dokumentationen ein guter Ausgangspunkt: Linux Kernel Networking Documentation.

Softnet backlog: Wenn der Kernel Pakete nicht schnell genug abarbeitet

Ein häufig übersehener Indikator ist der „softnet backlog“. Wenn der Kernel Pakete in Warteschlangen hält und nicht schnell genug abarbeitet, entstehen Drops, die nicht wie klassische NIC-Drops aussehen. Typische Symptome:

• Spitzen in softirq/ksoftirqd CPU-Zeit
• TCP Retransmits steigen, Latenzspitzen in P99
• Besonders stark bei vielen kleinen UDP-Paketen (z. B. DNS) oder vielen kurzen TCP-Verbindungen

In dieser Situation ist „mehr Bandbreite“ wirkungslos. Sie brauchen mehr CPU-Kapazität für Paketverarbeitung oder weniger pps/Overhead pro Paket.

Conntrack und NAT: Der unsichtbare Verstärker

Wenn Egress über Masquerade/NAT läuft, ist Conntrack fast immer Teil des Problems. Ein Node, der viele Outbound-Verbindungen terminieren oder SNATen muss, kann bei Peaks in Conntrack-Pressure geraten. Das führt zu Drops und Timeouts, die wie „Netzwerk instabil“ wirken, tatsächlich aber Zustandsmangel sind.

• Hohe new connections/s: viele kurze Verbindungen erzeugen viel conntrack churn.
• Conntrack nahe am Limit: kleine zusätzliche Bursts führen sofort zu Drops.
• Ungünstige Egress-Bündelung: viele Pods teilen wenige SNAT-IPs/Ports, was Concurrency und Zustände bündelt.

Ein Egress-Gateway-Pattern oder eine Entzerrung der NAT-Domäne kann hier helfen, ist aber ein Architekturthema. Für Kubernetes NetworkPolicy-Grundlagen, die oft mit Egress zusammenspielen: Kubernetes Network Policies.

Workload-Muster, die IRQ/CPU-Saturation besonders häufig auslösen

• DNS-lastige Systeme: Viele kleine UDP-Queries, besonders bei Cache-Misses.
• Telemetrie-Bursts: Logs/Metrics/Traces in Peaks, viele Targets, viele kleine Pakete.
• Chatty Microservices: Viele kurze HTTP-Calls statt weniger gebündelter Requests.
• Load Tests mit hoher Concurrency: Oft pps-lastiger als der produktive Mix, wenn nicht realistisch modelliert.
• Sidecar-heavy Deployments: Mehr Hop-Kosten, mehr Kopien, mehr Kontextwechsel.

Wenn Sie diese Muster erkennen, können Sie schon vor dem Incident Gegenmaßnahmen planen: Caching, Connection Reuse, Rate-Limits, Batching und bewusstes Sizing der Nodes.

Mitigation in der Praxis: Stabilisieren ohne „blindes Tuning“

Bei intermittierenden Drops ist es verlockend, an vielen Stellschrauben gleichzeitig zu drehen. Besser ist ein gestuftes Vorgehen mit klaren Zielen.

• Hotspot entschärfen: Betroffene Nodes identifizieren und Workloads umverteilen (z. B. cordon/drain als temporäre Maßnahme).
• CPU-Headroom schaffen: Node-Größe erhöhen oder CPU-intensive Pods begrenzen, damit Kernelarbeit nicht verdrängt wird.
• IRQ/Queue-Verteilung verbessern: RSS/IRQ-Affinität prüfen, ungleichmäßige Core-Last reduzieren.
• pps reduzieren: Connection Reuse, Keep-Alive, HTTP/2/gRPC, Caching, Batching.
• NAT/Conntrack entlasten: Egress entbündeln, conntrack-Auslastung überwachen, Verbindungs-Churn reduzieren.
• Observability schärfen: per-Core CPU irq/softirq, retransmits, drops und conntrack als Pflichtsignale etablieren.

Produktionssichere Tests: Wie Sie das Problem reproduzierbar sichtbar machen

Ein guter Test muss nicht „viel Bandbreite“ erzeugen, sondern die richtige Art von Last: hohe Paketanzahl, viele Verbindungen oder DNS-Bursts. Achten Sie dabei auf Produktionssicherheit:

• Testen Sie kontrolliert: limitierte Dauer, klarer Ramp-up, klare Abbruchkriterien.
• Testen Sie an realen Punkten: Pod↔Pod und Pod↔extern (Egress) getrennt, weil Pfade unterschiedlich sind.
• Messen Sie die richtigen Signale: per-core irq/softirq, retransmits, conntrack, interface drops.
• Isolieren Sie Variablen: Sidecar an/aus, Policy an/aus, andere Nodepools, unterschiedliche MTU.

Für die Einordnung von Performance-Tests und ihre Grenzen ist ein Tool-Überblick wie iperf3 hilfreich, aber die Interpretation muss immer pps- und latency-orientiert sein: iperf3 Dokumentation.

Checkliste: Was Sie in Ihren Plattform-Standards verankern sollten

• Per-Core Monitoring: irq/softirq, ksoftirqd, SoftIRQ-Stats, nicht nur „CPU total“.
• Node-Netzwerk-Baselines: RX/TX drops, errors, retransmits, conntrack-Auslastung.
• Nodepool-Disziplin: Homogene Kernel-/Treiber-Versionen, konsistente Offload-Settings, keine Drift.
• Traffic-Design: Connection Reuse, Backoff/Jitter für Retries, DNS-Caching, Batching.
• Capacity Headroom: Kernelarbeit braucht CPU-Reserve; zu knappe Node-Sizing-Modelle erhöhen Drop-Risiko.
• Incident-Runbook: schneller Pfad von Symptom → Node → irq/softirq → Mitigation.

Outbound-Quellen für vertiefende Informationen

• Linux Kernel Networking Documentation: Hintergründe zu Netzwerkpfaden, NAPI und SoftIRQ
• Kubernetes Networking Concepts: Einordnung von CNI, Service-Pfaden und Datenflüssen
• Kubernetes Network Policies: Egress/Ingress-Regeln und typische Blockade-Muster
• iperf3 Dokumentation: Parameter und sinnvolle Nutzung für Baselines

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.