Runbook „Alle Services 503 nach Mesh-Deploy“: Recovery-Checkliste

Wenn nach einem Service-Mesh-Deployment plötzlich alle Services 503 liefern, ist das ein klassisches „Blast-Radius“-Szenario: Nicht ein einzelner Microservice ist kaputt, sondern eine gemeinsame Datenebene (Data Plane) oder Steuerungsebene (Control Plane) beeinflusst den gesamten Request-Pfad. Dieses Runbook „Alle Services 503 nach Mesh-Deploy“ ist als Recovery-Checkliste gedacht, die im War Room sofort funktioniert: Sie hilft, die wahrscheinlichsten Ursachen schnell zu bestätigen oder auszuschließen, Recovery-Maßnahmen mit geringem Risiko zu priorisieren und Nebenwirkungen (z. B. Retry Storms, Thundering Herd) zu vermeiden. Dabei ist „503“ im Mesh-Kontext nicht gleich „Service down“: Häufig bedeutet es „Upstream nicht erreichbar“, „Cluster/Endpoint leer“, „mTLS/Policy blockiert“, „Proxy nicht ready“ oder „Gateway/Sidecar kann nicht routen“. Entscheidend ist, dass Sie strukturiert vorgehen und zuerst die gemeinsamen Abhängigkeiten prüfen: Ingress/Gateway, Sidecars, xDS-Konfiguration, Zertifikate, Policies, DNS, Egress und die Rollout-Änderung selbst. Ziel ist eine sichere Stabilisierung (Traffic wiederherstellen), bevor Sie in Ruhe Root Cause Analysis betreiben.

Erste 5 Minuten: Stabilisieren, Scope klären, Schäden begrenzen

Bevor Sie tief debuggen, stellen Sie sicher, dass der Incident nicht durch Lastverstärkung eskaliert. 503 nach Mesh-Deploy führt oft zu Retries auf mehreren Ebenen (Client, Sidecar, Gateway), wodurch die Systeme zusätzlich belastet werden.

• Traffic drosseln: Falls möglich, Rate Limits oder Schutzmechanismen am Edge aktivieren, um das System vor Überlast zu schützen.
• Retries temporär reduzieren: Wenn Sie zentral konfigurierte Retry-Policies im Mesh nutzen, prüfen Sie, ob diese gerade die Lage verschlimmern.
• Scope bestätigen: Betrifft es wirklich „alle Services“ oder nur alle Aufrufe über einen gemeinsamen Eintritt (Ingress/Gateway)?
• Rollback-Bereitschaft: Klären Sie, ob ein Rollback der Mesh-Änderung schnell möglich ist (Revision, Helm-Release, GitOps-Commit).
• Kommunikation: Statuspage/Stakeholder informieren, aber technische Maßnahmen priorisieren.

Symptom präzisieren: Welche Art von 503 ist es?

„503“ ist ein Sammelsymptom. Für ein sauberes Troubleshooting müssen Sie den Ursprung der 503-Antwort identifizieren. Kommt sie vom Ingress-Gateway? Vom Sidecar? Vom Upstream-Service? Oder vom Load Balancer davor?

• Response-Header prüfen: Viele Proxies setzen eigene Header (z. B. Via, Server, x-envoy-*). Das hilft, die Quelle zu lokalisieren.
• Ein Service direkt testen: Wenn möglich, einen Pod intern direkt ansprechen (ClusterIP/PodIP), um Edge/Gateway auszuschließen.
• Vergleich extern vs. intern: Extern 503, intern OK deutet auf Ingress/Gateway/Edge hin.
• Vergleich Sidecar vs. ohne Sidecar: Ein Test-Pod ohne Injection kann helfen, Sidecar-Probleme zu isolieren.

Schnelle Diagnosematrix: Wahrscheinlichkeiten nach Mesh-Deploy

Nach einem Mesh-Deployment sind bestimmte Fehlerklassen besonders häufig. Diese Matrix hilft, ohne lange Diskussionen die nächsten Checks zu priorisieren.

• Ingress/Gateway-Konfiguration fehlerhaft: Listener/Routes nicht geladen, falscher Gateway-Selector, falsche Service-Ports.
• Control Plane / xDS-Distribution gestört: Sidecars bekommen keine Konfiguration, bleiben „unconfigured“, Routen fehlen.
• mTLS/Certificates: Zertifikate abgelaufen, Trust Domain geändert, falsche CA/Bundle, Zeitdrift.
• Authorization/Policy: Default-deny greift nach Upgrade, Identity/Principal ändert sich, Namespaces falsch selektiert.
• Sidecar-Injection/Revision-Mismatch: Teilweise Injection, falsche Versionen, inkompatible Filterketten.
• DNS/Service Discovery: CoreDNS, ServiceEntries, interne Auflösung, SNI/Host-Header-Route-Matches.

Recovery-Checkliste: Ingress/Gateway zuerst prüfen

Wenn „alle Services 503“ vor allem über den zentralen Eintrittspunkt sichtbar werden, liegt die höchste Hebelwirkung meist beim Ingress-Gateway oder API-Gateway. Prüfen Sie dort zuerst den Ist-Zustand und die jüngste Änderung.

• Gateway-Pods ready? Readiness/Health-Probes, CrashLoops, Restarts, OOMKills.
• Service/Endpoints vorhanden? Hat der Gateway-Service Endpoints? Sind die TargetPorts korrekt?
• Listener und Routes aktiv? Prüfen Sie, ob die erwarteten Hosts/Paths tatsächlich geroutet werden.
• Konfigurationsänderung seit Deploy? Diff der Gateway-Ressourcen (Helm/GitOps) auf offensichtliche Fehler.
• Port/Protocol-Mismatch? Häufige Ursache: HTTP vs. HTTPS vs. HTTP/2 falsch deklariert, Backend-Port verwechselt.

Eine hilfreiche Referenz für Envoy-basierte Gateways ist die Dokumentation zur Observability und Tracing/Logging (auch ohne Tracing nützlich, weil dort viele Debug-Konzepte erklärt sind): Envoy Admin Interface.

Control Plane prüfen: Bekommen Sidecars überhaupt Konfiguration?

Ein globaler 503 nach Mesh-Deploy ist häufig ein „xDS-Problem“: Sidecars sind zwar gestartet, aber sie haben keine gültige Konfiguration (Cluster/Listener/Routes). Dann können sie Upstreams nicht erreichen oder leiten gar nicht korrekt weiter.

• Control-Plane-Pods healthy? Ist die Control Plane bereit, skaliert, nicht überlastet, keine CrashLoops.
• Push-/Sync-Fehler? Suchen Sie nach Meldungen wie „config rejected“, „xDS stream closed“, „NACK“.
• Version-Kompatibilität: Wurde Control Plane aktualisiert, aber Sidecars sind noch alt (oder umgekehrt)?
• RBAC/Network Policies: Können Sidecars die Control Plane erreichen (mTLS, Ports, DNS)?

Wenn Sie OpenTelemetry im Stack haben und Ihr Mesh Telemetrie exportiert, kann es helfen, Control-Plane-Fehler über Export-/Queue-Backpressure zu erkennen. Überblick: OpenTelemetry Collector.

mTLS und Identität: Wenn alles plötzlich „unauthorized“ wird

Nach einem Upgrade ändern sich manchmal Zertifikatsketten, Trust Domains oder Workload-Identitäten. Das kann zu flächendeckenden Verbindungsabbrüchen führen, die sich als 503 manifestieren (z. B. Upstream connect error oder TLS handshake failure). Auch Zeitdrift zwischen Nodes kann Zertifikate „ungültig“ machen.

• Zertifikatsgültigkeit: Prüfen Sie, ob Zertifikate abgelaufen sind oder NotBefore/NotAfter wegen Zeitdrift scheitern.
• Trust Domain/CA-Änderung: Wurde die CA rotiert oder die Trust Domain geändert?
• mTLS-Modus: Wurde permissive → strict umgestellt, ohne dass alle Workloads kompatibel sind?
• SNI/Host-Matching: TLS-SNI passt nicht mehr zur Route oder zum Zielservice.

Wenn Sie W3C Trace Context oder Baggage transportieren und Header-Filter nutzen, gilt: Security-Härtung darf nicht „nebenbei“ kritische Signale entfernen. Spezifikationen: W3C Trace Context und W3C Baggage.

Policies als Outage-Auslöser: Authorization, PeerAuthentication, Default-Deny

Ein häufiger Upgrade-Effekt ist Policy-Verhalten, das sich „korrekter“ anfühlt, aber produktiv zu streng ist. Beispiele: Standardmäßig wird mehr blockiert, Selektoren matchen anders, Principals ändern sich durch Revision/Injection. Das Ergebnis ist: Requests kommen an, aber dürfen nicht weiter, und am Ende sehen Clients 503.

• Neu eingeführte Default-Deny-Policy? Prüfen Sie, ob ein globales deny nach dem Deploy aktiv wurde.
• Namespace-Selektoren: Stimmen Labels/Selectors noch? Wurden Labels im Deploy verändert?
• Service Account / Identity Drift: Hat sich die Workload-Identität verändert (z. B. andere SA, andere Revision)?
• Ingress/Egress-Richtungen: Blockieren Policies Control Plane, DNS oder Telemetrie?

Sidecar-Injection und Revision-Mismatch: „Halb im Mesh“ ist gefährlich

Viele Mesh-Rollouts erfolgen über Revisionen oder „Canary“-Control-Planes. Wenn nach dem Deploy ein Teil der Workloads mit neuer Sidecar-Version läuft, ein anderer Teil mit alter oder ohne Sidecar, entstehen inkompatible Annahmen (z. B. mTLS strikt, aber alte Workloads sprechen plaintext). Das kann sehr schnell „alles 503“ erzeugen, weil jede Abhängigkeit irgendwo scheitert.

• Injection-Status prüfen: Haben alle relevanten Pods tatsächlich einen Sidecar? Oder sind einige „nackt“?
• Revision konsistent? Stimmen Labels/Annotations, die die Revision steuern?
• Rollout-Strategie: Wurden kritische Shared Services (DNS, Auth, Config) als erstes umgestellt?
• Gateway vs. Workloads: Läuft das Gateway auf einer anderen Revision als die Workloads?

DNS und Service Discovery: Unsichtbare Ursache für globale 503

DNS ist eine der häufigsten „Hidden Layers“, die nach Mesh-Änderungen auffallen. Wenn Sidecars oder Gateways Services nicht resolven können (oder auf falsche IPs resolven), wirkt es wie ein globaler Ausfall. Auch ServiceEntries oder interne FQDN-Patterns können nach Änderungen nicht mehr matchen.

• CoreDNS/Resolver gesund? Läuft DNS stabil, gibt es Timeouts, NXDOMAIN-Spikes?
• Search Domains / ndots: Haben sich DNS-Settings durch Sidecar/Init-Container verändert?
• ServiceEntries/VirtualServices: Werden interne/externen Ziele korrekt „discovered“?
• Cluster-DNS erreichbar: Blockieren NetworkPolicies oder egress control den DNS-Port?

Eine solide technische Referenz zu DNS in Kubernetes ist die offizielle Doku: Kubernetes DNS für Services und Pods.

Beobachtbarkeit im Incident: Welche Daten sind jetzt am wertvollsten?

Bei einem globalen 503 ist Zeit der limitierende Faktor. Statt „alles gleichzeitig“ zu prüfen, konzentrieren Sie sich auf Signale, die den Breakpoint lokalisieren. Nützlich sind vor allem: Gateway-Access-Logs, Sidecar-Stats, Control-Plane-Logs und ein einzelner, reproduzierbarer Request-Pfad.

• Gateway-Access-Logs: Status, Upstream-Cluster, Response-Flags, Latenz.
• Sidecar-Metriken: Upstream-Connection-Failures, TLS-Handshake-Failures, „no healthy upstream“.
• Control-Plane-Logs: NACKs, Rejected Config, Push Errors.
• Kubernetes Events: Pull Errors, CrashLoops, Readiness flapping.

Priorisierte Recovery-Aktionen: Was tun, wenn Sie schnell wieder online müssen?

Die folgenden Maßnahmen sind bewusst als „Recovery-first“ formuliert. Sie sind nicht alle schön, aber im Incident oft sinnvoll, wenn sie kontrolliert und reversibel eingesetzt werden.

Rollback der Mesh-Änderung (höchste Erfolgsquote bei klarer Deploy-Ursache)

• Rollback auf die letzte bekannte stabile Control-Plane-/Chart-/Manifest-Version.
• Gateway zuerst zurückrollen, wenn der Ausfall primär am Edge sichtbar ist.
• Wenn Revisionen genutzt werden: Traffic zurück auf die alte Revision schwenken (Labels/Selectors).

Temporäre Entschärfung von Strict mTLS oder Policies

• Wenn mTLS-Umstellung die Ursache ist: temporär „permissive“ aktivieren (nur als Notmaßnahme).
• Wenn Authorization-Policies blockieren: eng begrenzte Allow-Regel für kritische Pfade hinzufügen.
• Keine „global allow all“ ohne Zeitlimit und Dokumentation, sonst bleibt es als Tech Debt liegen.

Bypass für kritische Pfade

• Für absolut kritische Services kann ein temporärer Bypass über einen separaten Ingress oder direkten ClusterIP-Zugriff helfen.
• Wenn möglich, internes Traffic-Routing ohne Mesh (nur für den Notfall) aktivieren, um Kernfunktionen wiederherzustellen.

Risiko-Check: Vermeiden Sie sekundäre Ausfälle während der Recovery

Ein globaler 503 ist selten stabil – oft wechseln Systeme zwischen „teilweise geht’s“ und „wieder tot“. Häufige sekundäre Ausfälle werden durch Retries, Connection-Churn und instabile Readiness ausgelöst. Prüfen Sie daher konsequent:

• Retry Storm Risiko: Mehrere Ebenen retryen gleichzeitig (Client + Sidecar + Gateway).
• Connection Pools: Massives Neuaufbauen von TLS-Verbindungen nach Policy-/Cert-Änderungen.
• Autoscaling: HPA reagiert auf falsche Signale (CPU hoch wegen Retries) und verschlimmert das Chaos.
• Readiness Flapping: Pods werden ständig rein/raus genommen, Endpoints werden „leer“.

Messbar machen: 503-Rate und Impact quantifizieren

Für Priorisierung und Kommunikation ist eine einfache Kennzahl hilfreich: die 503-Fehlerrate pro Zeitfenster. Falls Sie eine Gesamtrate aus Requests und 503-Antworten berechnen, kann folgende Formel (als MathML) zur Standardisierung dienen:

$r=\frac{N(503)}{N(\mathrm{gesamt})}$

Nutzen Sie diese Rate, um zu prüfen, ob Recovery-Maßnahmen wirken (r fällt), und um festzustellen, ob es sich um eine partielle oder totale Störung handelt.

Verifikation nach Recovery: Was muss „grün“ sein, bevor Sie weitergehen?

Sobald Traffic wieder fließt, sollten Sie nicht sofort in „Business as usual“ zurückspringen. Verifizieren Sie anhand einer kurzen Liste, dass das System stabil ist und nicht in wenigen Minuten wieder kippt.

• Edge stabil: Gateway-Error-Rate normalisiert sich, Latenzen sind im erwarteten Bereich.
• Service Discovery stabil: Keine DNS-Timeout-Spikes, keine massiven NXDOMAIN-Anstiege.
• mTLS stabil: Keine Welle an Handshake-Fehlern, Zertifikatsrotation kontrolliert.
• Policies nachvollziehbar: Temporäre Allow-Regeln dokumentiert und mit Rückbauplan versehen.
• Keine Lastverstärkung: Retry-Raten wieder normal, keine übermäßigen Connection-Resets.

Häufige Root Causes nach Mesh-Deploy (für schnelle Wiedererkennung)

Auch wenn dieses Runbook auf Recovery fokussiert, hilft eine kurze Liste typischer Root Causes, damit Teams schneller „Pattern Matching“ betreiben können:

• Gateway-Routes/Hosts matchen nicht mehr (z. B. Hostname geändert, VirtualService falsch selektiert).
• Sidecars erhalten keine xDS-Konfiguration (Control Plane erreichbar, aber Rejected Config).
• mTLS strict aktiviert, aber nicht alle Workloads sprechen mTLS (Mischbetrieb ohne Übergang).
• CA/Trust Bundle rotiert, alte Sidecars vertrauen nicht (oder Zeitdrift).
• Authorization/NetworkPolicy blockiert DNS oder Control Plane.
• Revision-Mismatch: Gateway auf neuer Revision, Workloads auf alter (oder umgekehrt).

Outbound-Links für gezielte Vertiefung im Incident

• Envoy Admin Interface: Live-Debugging von Listenern, Clustern und Stats
• Kubernetes DNS: Wie Service-Discovery im Cluster funktioniert
• OpenTelemetry Collector: Telemetrie-Pipelines und typische Betriebsprobleme
• W3C Trace Context: Standard-Header für Trace-Propagation

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.