Service-Mesh-Troubleshooting: Underlay vs. Sidecar vs. App

Service-Mesh-Troubleshooting: Underlay vs. Sidecar vs. App ist in der Praxis eine der wichtigsten Fähigkeiten, sobald ein Cluster ein Service Mesh wie Istio, Linkerd oder Consul Connect nutzt. Denn ab diesem Moment existieren mehrere „Netzwerkrealitäten“ gleichzeitig: das Underlay (CNI, Routing, Node-Netzwerk), die Sidecars (Proxy-Datapath, mTLS, Retry-/Timeout-Logik, Policy) und die Anwendung selbst (Clients, Connection Pools, DNS, TLS, Fehlerhandling). Wenn ein Request fehlschlägt, ist die erste Frage daher nicht „welche Komponente ist schuld?“, sondern „in welcher Schicht entsteht der Fehler – und wie kann ich das belastbar beweisen?“. Ohne diese Trennung entsteht schnell ein Ping-Pong zwischen Teams: Plattform sagt „App“, App sagt „Netzwerk“, Security sagt „Policy“. Ein gutes Troubleshooting trennt systematisch: Ist der Transport kaputt (Underlay), bricht der Proxy den Flow (Sidecar), oder verhält sich die App ungewöhnlich (App)? Dieser Artikel gibt Ihnen eine praxistaugliche Diagnose-Methodik, inklusive typischer Symptome, schneller Checks, Metriken und Log-Indikatoren. Das Ziel ist, in wenigen Minuten eine belastbare Hypothese zu formulieren, den Blast Radius zu bestimmen und eine sichere Mitigation zu wählen, ohne blind Konfigurationen zu ändern.

Mentales Modell: Drei Schichten, drei Fehlerklassen

Ein Service Mesh fügt zusätzliche Funktionen zwischen Client und Server ein. Das ist gewollt, erhöht aber die Zahl möglicher Fehlerquellen. Für ein sauberes Service-Mesh-Troubleshooting ist die konsequente Schichtentrennung entscheidend:

• Underlay: Pod-/Node-Netzwerk, CNI-Datapath, Routing, MTU, DNS-Erreichbarkeit, Node-CPU/IRQ, conntrack, Load-Balancer-Pfade.
• Sidecar: Proxy-Konfiguration, mTLS, Zertifikate, Listener/Cluster-Config, Outlier Detection, Circuit Breaking, Retries, Timeouts, egress policies.
• App: Client-Libraries, Connection Pools, DNS-Caching, Timeouts, Retries, Threadpools, Backpressure, Payload-Handling.

Die Schwierigkeit: Ein Fehler in Schicht A kann als Symptom in Schicht B erscheinen. Beispielsweise kann ein Underlay-Drop im Sidecar als „upstream reset“ sichtbar werden, und in der App als „timeout“. Deshalb brauchen Sie ein Vorgehen, das nicht bei der Fehlermeldung stehen bleibt.

Startpunkt im Incident: Symptome kategorisieren

Bevor Sie Tools öffnen, ordnen Sie das Symptom in eine Kategorie ein. Das spart Zeit, weil bestimmte Symptome sehr stark auf eine Schicht hinweisen.

• Verbindungsaufbau scheitert: „connection refused“, „no route to host“, „i/o timeout“ beim Connect → häufig Underlay oder Sidecar-Listener/Policy.
• Handshake-/TLS-Probleme: „x509“, „handshake failure“, „tls alert“ → häufig Sidecar (mTLS) oder App-TLS-Stack.
• HTTP-Fehlercodes aus dem Proxy: 503/504/502 mit Proxy-spezifischen Flags → häufig Sidecar oder Upstream-Health/Config.
• Intermittierende Timeouts (P99 kippt): häufig Underlay (Drops/CPU/MTU) oder Sidecar-Queueing/Retry-Stürme.
• Nur ein Service/Namespace betroffen: häufig Sidecar-Policy/Config oder App-Regression.
• Node-/Zone-spezifisch: starkes Underlay-Signal (CNI, Node, Routing, IRQ/CPU).

Erster Pflichtschritt: Blast Radius bestimmen

Ein schneller Blast-Radius-Check ist der effektivste Weg, Underlay vs. Sidecar vs. App zu trennen. Stellen Sie die folgenden Fragen in dieser Reihenfolge:

• Ist das Problem clusterweit oder lokal? Clusterweit deutet auf Control Plane, zentrale Policies oder Underlay-Events hin.
• Ist es node-spezifisch? Wenn Fehler sich auf bestimmte Nodes konzentrieren, ist Underlay sehr wahrscheinlich.
• Ist es namespace-/workload-spezifisch? Dann sind Sidecar-Injection, Policies oder App-Config oft der Treiber.
• Ist nur ein Protokoll betroffen (HTTP vs. gRPC vs. TCP)? Protokollspezifische Effekte sprechen eher für Sidecar/App als für reines Underlay.

Wenn Sie Kubernetes-Basics zum Netzwerkpfad auffrischen möchten, sind die Kubernetes-Networking-Konzepte eine solide Referenz: Kubernetes Networking Concepts.

Underlay-Diagnose: Wie Sie den „Transport“ beweisen oder ausschließen

Underlay-Probleme verursachen die härtesten und oft „dreckigsten“ Symptome: Drops, Retransmits, Timeouts, sporadische Verbindungsabbrüche. Im Mesh wirken sie oft wie Proxy-Probleme, weil Sidecars die ersten sind, die den Schaden bemerken.

Underlay-Signale, die sehr aussagekräftig sind

• Node-/Zone-Korrelation: Fehler treten auf denselben Nodes oder in derselben Zone gehäuft auf.
• TCP Retransmits steigen: ein starker Indikator für Verlust oder starkes Queueing.
• Interface Drops/Errors: RX/TX drops, overruns, discards auf Nodes.
• CPU irq/softirq Peaks: Netzwerkverarbeitung läuft in Sättigung, Pakete werden verspätet oder gar nicht verarbeitet.
• Conntrack-Pressure: besonders bei Egress/NAT und vielen kurzlebigen Verbindungen.

MTU und „Small works, large fails“ im Mesh-Kontext

Service Meshes erhöhen die Wahrscheinlichkeit von MTU-Problemen, weil mTLS, zusätzliche Header und ggf. Encapsulation den effektiven Payload-Spielraum reduzieren. Ein klassisches Muster: Kleine Requests funktionieren, größere Responses oder gRPC-Nachrichten timeouten. Das ist häufig kein „Envoy-Bug“, sondern ein Pfad-MTU-/PMTUD-Thema.

• Indikatoren: Timeouts bei größeren Payloads, sporadische TLS-Probleme, erhöhte Retransmits.
• Typische Ursache: Tunnel/Overlay + mTLS + untere Underlay-MTU oder ICMP blockiert.

Als technische Grundlage für Path MTU Discovery sind diese RFCs hilfreich: RFC 1191 und RFC 8201.

Ein einfaches Kriterium, um Underlay-Drops messbar zu machen

Für eine schnelle Einschätzung ist die Retransmit-Quote hilfreich, weil sie meist leichter verfügbar ist als echte Drop-Reasons:

$\mathrm{RetransmitQuote}=\frac{\mathrm{TCP\_Retransmits}}{\mathrm{TCP\_Segments}}$

Steigt diese Quote zeitgleich mit App-Timeouts und Proxy-Errors, ist Underlay als Ursache sehr wahrscheinlich.

Sidecar-Diagnose: Wenn der Proxy der Engpass oder der Gatekeeper ist

Sidecars (häufig Envoy) sind aktiv am Verkehrsfluss beteiligt: Sie terminieren TLS, bauen Upstream-Verbindungen auf, wenden Policies an und können selbst Timeouts, Retries oder Circuit Breaker auslösen. Das macht sie mächtig – und zu einer realen Fehlerquelle.

Typische Sidecar-Fehlerbilder

• mTLS-/Zertifikatsfehler: abgelaufene Zertifikate, falsche Trust-Domains, Identity-Mismatch.
• Policy/Authorization-Denies: Requests werden durch Mesh-Policies blockiert, oft als 403/RBAC denied sichtbar.
• Konfigurationsdrift: Sidecars haben nicht die erwartete Konfiguration (Listener fehlen, Cluster falsch).
• Retry-Stürme: Retries verstärken Last, führen zu Queueing und erhöhen Fehler, statt zu helfen.
• Outlier Detection/Circuit Breaking: Upstreams werden „ejected“, wodurch scheinbar zufällig 503 entstehen.
• Sidecar-Ressourcenlimit: CPU/Memory-Limits führen zu Verzögerungen oder OOM, was wie Netzwerkproblem wirkt.

Proxy-Status: Warum „HTTP 503“ nicht gleich „Server down“ ist

Ein häufiger Fehlschluss ist: 503 kommt, also ist der Backend-Service kaputt. Im Mesh kann 503 aber auch bedeuten: Der Proxy findet keinen gesunden Upstream, die Verbindung kann nicht aufgebaut werden, oder Policy/Timeout greift. Entscheidend sind Proxy-Metadaten (z. B. Response Flags), die zeigen, ob der Proxy selbst die Entscheidung getroffen hat oder ob der Server geantwortet hat.

Für Envoy-spezifische Grundlagen zur Konfiguration und zum Betriebsmodell ist die Dokumentation hilfreich: Envoy Proxy Documentation.

Sidecar vs. App: Der „Direct-to-Pod“-Vergleich

Eine der saubersten Methoden, Sidecar-Effekte zu isolieren, ist ein Vergleich zwischen Traffic „durch den Sidecar“ und Traffic „direkt“ (sofern in Ihrer Umgebung zulässig und sicher). In vielen Meshes können Sie testweise einen Pod ohne Sidecar starten oder in einem Debug-Namespace ohne Injection arbeiten. Wenn „ohne Sidecar“ stabil ist und „mit Sidecar“ nicht, ist die Ursache mit hoher Wahrscheinlichkeit in Sidecar/Policy/Control Plane zu finden.

Control Plane des Meshes: Wenn Sidecars korrekt sind, aber falsch gesteuert werden

Viele Sidecar-Probleme sind eigentlich Control-Plane-Probleme: Konfiguration wird zu spät verteilt, ist inkonsistent oder fehlerhaft. Typische Ursachen sind Controller-Überlast, fehlerhafte Ressourcen (VirtualServices, DestinationRules, Policies) oder Version-Mismatches nach Upgrades.

• Konfigurationsverteilung verzögert: neue Policies greifen nicht oder greifen nur auf manchen Pods.
• Version-/API-Mismatch: CRDs oder Konfigurationsmodelle passen nicht zur Mesh-Version.
• Spikes bei xDS/Config Push: bei großen Clustern können Pushes Latenz erzeugen oder Sidecars überfordern.

Wenn Sie Istio nutzen, sind die offiziellen Betriebs- und Troubleshooting-Seiten ein guter Anker: Istio Operations. Für Linkerd gilt entsprechend: Linkerd Troubleshooting.

App-Diagnose: Wenn der Fehler im Client- oder Serververhalten steckt

Auch im Service Mesh bleiben Anwendungen die Quelle vieler Probleme. Der entscheidende Unterschied: Ein Mesh kann Fehler sichtbarer machen (weil Metriken/Traces vorhanden sind), aber es kann auch Symptome verändern (Retries, Timeouts, mTLS). Ein gutes Troubleshooting prüft daher die App-Schicht gezielt, statt sie pauschal verantwortlich zu machen.

Typische App-Ursachen, die im Mesh wie Netzwerk wirken

• Zu aggressive Timeouts: App-Timeout < Proxy-Timeout oder umgekehrt; führt zu widersprüchlichen Fehlerbildern.
• Fehlkonfigurierte Connection Pools: zu wenige Verbindungen, zu kleine Pools, zu kurze Keep-Alive-Zeiten.
• Threadpool-/Eventloop-Saturation: Server nimmt Verbindungen an, beantwortet aber nicht rechtzeitig; Proxy meldet 504.
• DNS-Caching/Resolver-Verhalten: fehlerhafte TTL-Interpretation, zu häufige Lookups, Probleme mit Search Domains.
• Payload-/Streaming-Probleme: große Responses, gRPC-Streams, Backpressure und Flusskontrolle.

Gerade bei gRPC/HTTP/2 ist es wichtig, zwischen Transport- und Applikationsebene zu unterscheiden. Ein Server kann „gesund“ sein, aber bei bestimmten Methoden durch CPU- oder DB-Limits in Tail-Latency kippen, was dann wie Netzwerkproblem wirkt.

App vs. Sidecar mit Tracing sauber trennen

Distributed Tracing ist im Mesh besonders nützlich, weil es häufig Proxy-Spans und App-Spans kombiniert. Damit können Sie sehen, ob die Zeit im Connect/Handshake, im Proxy-Queueing oder in der App-Verarbeitung verbrannt wird. Als Standard für Instrumentierung ist OpenTelemetry eine sinnvolle Referenz: OpenTelemetry Dokumentation.

Die wichtigste Praxisregel: Eine Hypothese pro Schritt, nicht zehn Änderungen auf einmal

Das häufigste Troubleshooting-Anti-Pattern im Service Mesh ist „wir ändern gleichzeitig Timeouts, Retries, Policies und Ressourcen“. Das zerstört die Ursache-Wirkung-Kette. Stattdessen arbeiten Sie mit Hypothesen und Tests, die jeweils eine Schicht priorisieren:

• Hypothese Underlay: Node-/Zone-Korrelation, Retransmits, Drops, irq/softirq → dann zuerst Node-Signale prüfen und Workloads umverteilen.
• Hypothese Sidecar: Proxy-Flags, mTLS-Fehler, Outlier/Circuit Breaking, Config-Drift → dann Sidecar-Status und Control Plane prüfen.
• Hypothese App: methodenspezifische Latenz, Pool-Sättigung, Timeouts/Retry-Logik → dann App-Metriken und Limits prüfen.

Konkreter Diagnosepfad: „In 10 Minuten zur Schicht“

Dieser Ablauf ist bewusst kurz und wiederholbar. Er hilft, die richtige Schicht zu identifizieren, bevor Sie tiefer graben.

• Schritt A: Betroffene Workloads, Zeitfenster, Fehlerklasse (timeout, reset, 503, TLS) festhalten.
• Schritt B: Korrelation prüfen: Ist es node-/zone-spezifisch oder service-/namespace-spezifisch?
• Schritt C: Underlay-Signale prüfen: Retransmits, Drops, irq/softirq, conntrack, MTU-Indikatoren.
• Schritt D: Sidecar-Signale prüfen: Proxy-Errors/Flags, mTLS, Config-Status, Ressourcenlimits, ejections.
• Schritt E: App-Signale prüfen: Timeouts, Threadpools, Connection Pools, methodenspezifische Latenz, Backpressure.
• Schritt F: Mitigation wählen, die den Blast Radius minimiert (z. B. Workloads von problematischen Nodes weg, Retries reduzieren, Sidecar-Ressourcen erhöhen, Policy-Freigabe korrigieren).

Mitigation-Optionen nach Schicht, ohne riskante Nebenwirkungen

Eine Mitigation soll stabilisieren, nicht „dauerhaft umkonfigurieren“, ohne die Ursache zu kennen. Die folgenden Optionen sind typischerweise sicherer als große Umbauten.

• Underlay-Mitigation: betroffene Nodes isolieren (cordon/drain), Nodepool wechseln, Kapazität erhöhen, conntrack-Pressure senken (Verbindungs-Churn reduzieren), MTU-Konsistenz herstellen.
• Sidecar-Mitigation: Retries begrenzen, Timeouts harmonisieren, Sidecar-CPU/Memory erhöhen, mTLS-Policy temporär entschärfen (nur mit klarer Security-Freigabe), ejection-Parameter prüfen.
• App-Mitigation: Client-Timeouts/Backoff korrekt setzen, Connection Pools anpassen, serverseitige Limits erhöhen, Hotpaths optimieren, DNS-Nutzung stabilisieren.

Checkliste: Signale, die Sie dauerhaft als Pflicht-Observability brauchen

Service-Mesh-Troubleshooting wird deutlich schneller, wenn bestimmte Pflichtsignale immer verfügbar sind. Damit vermeiden Sie, im Incident erst Monitoring nachzurüsten.

• Underlay: Retransmits, Interface Drops/Errors, conntrack current/max/drops, CPU irq/softirq, Node-Latenz-/Drop-Korrelation nach Zone.
• Sidecar: Proxy Request Rate, Fehlercodes, Response Flags, Upstream Connect Failures, TLS Handshake Errors, CPU/Memory, Queueing-Indikatoren.
• App: Request-Latenz P50/P95/P99, Timeouts, Threadpool-Saturation, Connection Pool Stats, Retry-Raten.

Outbound-Quellen für vertiefende Informationen

• Kubernetes Networking Concepts: Grundlagen zum Underlay und Pod-/Service-Pfaden
• Envoy Proxy Documentation: Proxy-Verhalten, Fehlerbilder und Konfigurationskonzepte
• Istio Operations: Betrieb, Upgrades und Troubleshooting im Service Mesh
• Linkerd Troubleshooting: Diagnosepfade und typische Mesh-Probleme
• OpenTelemetry Dokumentation: Tracing und Metriken zur Schichtentrennung
• RFC 1191: Path MTU Discovery (IPv4) für MTU-Fehlerbilder
• RFC 8201: Path MTU Discovery (IPv6) für MTU-Fehlerbilder

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.