Kein gesunder Upstream-Fehler – Vollständiger Leitfaden zum Verständnis, Beheben und Verhindern

Fehlerbehebung

Wenn Sie einen “Kein gesunder Upstream”-Fehler von Webanwendungen, APIs oder Diensten sehen, signalisiert dies oft, dass Ihr Lastenausgleich oder Gateway seinen Pool gesunder Backend-Server erschöpft hat, um Anfragen weiterzuleiten.

Das bedeutet, dass der “Verkehrsleiter” keine gültigen Ziele hat, und somit gehen die Anfragen Ihrer Benutzer ins Leere, was eine fehlgeschlagene Verbindung, einen Ausfall und unzufriedene Kunden bedeutet.

Dies kann in fast jeder Art von Setup passieren, sei es Nginx-Proxy-Server, Kubernetes-Cluster, Docker-Container oder virtualisiert wie VMware vCenter usw.

Die tatsächliche Ursache kann je nach Ihrem Setup variieren, aber im Allgemeinen ist Folgendes schiefgelaufen: Ihre Upstream-Dienste waren entweder ausgefallen, hatten Probleme mit den Gesundheitsprüfungen oder wurden durch eine falsche Konfiguration blockiert.

Was bedeutet der “Kein gesunder Upstream”-Fehler?

Ein Upstream, im Kontext von Lastenausgleichs- oder Service-Mesh-Architekturen, stellt die Backend-Server oder -Dienste dar, die Anfragen von Clients bearbeiten.

Der Lastenausgleich oder Gateway (z. B. Nginx, Envoy, API Gateway) trifft die Entscheidung, welcher Upstream-Server die Verantwortung für eine Anfrage übernehmen muss.

Wenn keine der konfigurierten Gesundheitsprüfungen bei einem Upstream besteht oder wenn Sie keinen von ihnen erreichen können, erhalten Sie den Fehler Kein gesunder Upstream.

Kein gesunder Upstream-Fehler

Typische Szenarien, in denen dies auftritt

Fehler bei der Gesundheitsprüfung aufgrund langsamer Antwort oder falscher Konfiguration.
Die Backend-Dienste sind aufgrund von Netzwerkverbindungsproblemen nicht erreichbar.
Wenn eine Routingregel falsch konfiguriert ist, geht der Verkehr an falsche Ziele.

Beispiele in verschiedenen Systemen

Nginx: [Fehler] keine aktiven Upstreams beim Verbinden mit Upstream
Kubernetes: 0/3 Knoten sind verfügbar: 3 Knoten hatten Taints, die das Pod nicht tolerierte
Docker: Dienst “app” ist nicht gesund

Häufige Ursachen auf verschiedenen Plattformen

Während der genaue Grund je nach Umgebung unterschiedlich ist, sind die häufigsten Ursachen:

Backend-Dienst stürzt ab oder wird heruntergefahren: Dienst stoppt oder stürzt ab, und es sind keine Instanzen mehr aktiv.
Falsche Einstellungen für Gesundheitsprüfungen: Wenn sie fehlschlagen, betrachtet der Lastenausgleich gesunde Server als “ausgefallen” und entfernt sie aus dem Pool.
DNS-Auflösungsprobleme: Der Domainname des Backends kann nicht in eine IP-Adresse aufgelöst werden.
Port-Mismatch: Die Konfiguration der Upstream-Einstellungen bezieht sich auf einen falschen Port, auf dem der Backend-Dienst lauscht.
Netzwerkrichtlinien und Firewalls: Der Lastenausgleich kann nicht mit dem Backend kommunizieren, da es durch Sicherheitsregeln blockiert ist.
Zertifikatsablauf: In SSL/TLS-Konfigurationen können abgelaufene Zertifikate sichere Verbindungen stören.
Pod-Planung oder Knoten-Taints in Kubernetes: Inkompatible Knotenbedingungen können dazu führen, dass Pods nicht ausgeführt werden.

So diagnostizieren Sie den Fehler

Die erste Phase zur Behebung des Kein gesunder Upstream-Fehlers besteht darin, festzustellen, wo das Problem auftritt, entweder beim Lastenausgleich, im Netzwerk oder im Backend-Dienst.

Schritt 1: Überprüfen Sie die Verfügbarkeit des Backends

Für Linux-Dienste: systemctl status
Für Netzwerkportprüfungen: netstat -tulpn | grep

Schritt 2: Testen Sie die Netzwerkverbindung

Vom Lastenausgleich zum Backend:

# Beispiel (Platzhalter vor dem Ausführen ersetzen):
curl -v :/

Testen Sie die DNS-Auflösung: dig backend.example.com

Schritt 3 – Protokolle überprüfen

Nginx: /var/log/nginx/error.log
Kubernetes: kubectl describe pod
Docker: docker logs
vCenter: Zertifikats- und Dienstprotokolle

Schritt 4 – Gesundheitsprüfungen überprüfen

Stellen Sie sicher, dass Ihr /health-Endpunkt einen angemessenen 200 OK-Status oder einen ähnlichen Status zurückgibt.
Stellen Sie sicher, dass der Pfad und die Methode dem entsprechen, was der Lastenausgleich überprüfen soll.

Plattform-spezifische Lösungen

A. Nginx

Wenn Nginx keine aktiven Upstreams anzeigt, sind Listen in der Regel ein Zeichen für ein Problem, das mit Ihren Backend-Definitionen oder einem Fehler in der Gesundheitsprüfung zusammenhängt.

Checkliste zur Behebung von Nginx:

Bestätigen Sie, dass die Backend-IP/Hostnamen korrekt sind.
Überprüfen Sie, ob die Backend-Dienste laufen und erreichbar sind.
Passen Sie die Konfigurationen der Gesundheitsprüfungen an:

upstream backend {
    server backend1.example.com:8080 max_fails=3 fail_timeout=30s;
    server backend2.example.com:8080 backup;
}

Fügen Sie optional aktive Gesundheitsprüfungen hinzu (benötigt Nginx Plus oder ein Modul):

check interval=3000 rise=2 fall=5 timeout=1000 type=http;
check_http_send "HEAD / HTTP/1.0\r\n\r\n";
check_http_expect_alive http_2xx http_3xx;

B. Kubernetes

Im Kubernetes-Lastenausgleich möchten Sie, dass die Readiness-Proben und die Zuordnung von Diensten zu Pods korrekt sind.

Häufige Lösungen:

Stellen Sie sicher, dass Pods ausgeführt werden: kubectl get pods
Überprüfen Sie die Einstellungen der Readiness-Probe:

readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

Überprüfen Sie, ob die Dienst-Selektoren mit den Pod-Labels übereinstimmen.
Überprüfen Sie die Netzwerkrichtlinien auf blockierten Verkehr.

C. Docker

In Docker und Docker Compose, wenn die Gesundheitsprüfungen für einen Container bestehen, wenn er als gesund markiert ist.

Schritte zur Behebung:

Überprüfen Sie den Gesundheitsstatus des Containers: docker inspect

Implementieren oder korrigieren Sie eine Gesundheitsprüfung in docker-compose.yml:

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost/health"]
  interval: 30s
  timeout: 10s
  retries: 3

Stellen Sie sicher, dass Ihr Dienst tatsächlich den /health-Endpunkt bereitstellt.

D. VMware vCenter

Oft kann der Grund auf abgelaufene SSL-Zertifikate zurückzuführen sein. Dies ist hauptsächlich für vCenter-Benutzer relevant. So überprüfen Sie, ob die Zertifikate abgelaufen sind oder nicht:

Starten Sie zunächst die vCenter Appliance.
Führen Sie diesen Befehl aus: for store in $(/usr/lib/vmware-vmafd/bin/vecs-cli store list | grep -v TRUSTED_ROOT_CRLS); do echo “[*] Store :” $store; /usr/lib/vmware-vmafd/bin/vecs-cli entry list –store $store –text | grep -ie “Alias” -ie “Not After”;done;
Überprüfen Sie nun, ob die Machine_SSL- und die Solution User-Zertifikate abgelaufen sind. Wenn ja, ersetzen Sie sie.
Sie können auch die vCenter Windows oder PowerShell dafür ausführen: $VCInstallHome = [System.Environment]::ExpandEnvironmentVariables(“%VMWARE_CIS_HOME%”);foreach ($STORE in & “$VCInstallHome\vmafdd\vecs-cli” store list){Write-host STORE: $STORE;& “$VCInstallHome\vmafdd\vecs-cli” entry list –store $STORE –text | findstr /C:”Alias” /C:”Not After”}

Sofortige Wiederherstellungsmaßnahmen

Wenn Sie eine schnelle Wiederherstellung benötigen, während Sie an der Ursache arbeiten:

Versuchen Sie den Dienst im Backend erneut, was vorübergehend Dienste in der aktualisierten Version des Backend-Dienstes bereitstellt.
Aktualisieren Sie DNS- oder IP-Adressen, wenn es ein Auflösungsproblem gibt.
Fügen Sie einen Backup-Server zum Upstream-Block als vorübergehenden Handler hinzu.
Deaktivieren Sie vorübergehend fehlerhafte Gesundheitsprüfungen (keine dauerhafte Lösung).

Verhindern von Kein gesunder Upstream-Fehlern

Prävention dreht sich um Resilienz und Sichtbarkeit:

Best Practices für Gesundheitsprüfungen

Jeder Dienst kann /health-Endpunkte anbieten
Wenn der Dienst aktiv ist, antwortet er einfach mit einem einfachen 200 OK.
Diese Timeouts + Wiederholungsgrenzen sollten tatsächlich eine echte Leistung darstellen.

Redundanz

Verwenden Sie mehrere Backend-Instanzen.
Seien Sie immer bereit, mindestens einen weiteren Backup-Server bereitzustellen.

Überwachung & Warnungen

Prometheus + Grafana, Datadog oder New Relic, die Sie vor einem vollständigen Ausfall des Upstreams warnen können.
Überwachen Sie Latenz, Fehlerquoten und Verbindungszahlen.

Konfigurationshygiene

Halten Sie DNS-Einträge aktuell.
Dokumentieren Sie Dienstports und Pfade für Gesundheitsprüfungen.
Verwenden Sie Schaltungsschutzschalter, um kaskadierende Fehler zu verhindern.

Sicherheits- & Netzwerkrichtlinien

Überprüfen Sie regelmäßig die Firewall-Regeln und Kubernetes-Netzwerkrichtlinien
Halten Sie SSL-Zertifikate aktuell.

FAQs

Kann ich das ohne Serverzugang beheben?

Nein, Sie müssen Systemadministrator oder Entwickler sein, um Backend- oder Konfigurationsprobleme zu beheben, falls vorhanden.

Ist es immer ein Backend-Problem?

Nicht immer, es sei denn, es handelt sich um eine Lastenausgleichs- oder DNS-Konfiguration.

Wie lange dauert es, es zu beheben?

Kleinere Fehlkonfigurationen können in Minuten behoben werden; Netzwerk- oder Skalierungsprobleme können Stunden in Anspruch nehmen.

Beeinflusst dies die Leistung sogar vor einem vollständigen Ausfall?

Ja, partielle Ausfälle des Upstreams können zu Latenz- und Fehlerquotensteigerungen führen, selbst bevor der vollständige Ausfall eintritt.

Welche Überwachungstools sind am besten?

Prometheus + Grafana, Datadog, New Relic und native Cloud-Überwachung sind alle großartig.

Abschließende Gedanken

Der Kein gesunder Upstream-Fehler scheint mehr als nur ein vager Fehler zu sein; dies ist ein Indikator dafür, dass das System, das Anfragen an Ihre Backend-Infrastruktur verarbeitet, keinen Zugriff auf diese Backends hat.

Eine Fehlermeldung für den Endbenutzer und ein Aktionspunkt für den Administrator. Es spielt keine Rolle, ob Sie Nginx, Kubernetes, Docker und VMware ausführen; die Prinzipien bleiben gleich. Überwachen, Konfiguration überprüfen, Zugriff auf das Netzwerk bestätigen und die Gesundheit des Dienstes validieren.

Durch eine Kombination aus schnellen Lösungen und langfristigen Strategien können Sie die Wahrscheinlichkeit erheblich verringern, dass dieser Fehler jemals Ihre Dienste beeinträchtigt.