Errore No Healthy Upstream – Guida Completa per Comprendere, Risolvere e Prevenire

Quando vedi un errore “No Healthy Upstream” da applicazioni web, API o servizi, spesso segnala che il tuo bilanciatore di carico o gateway ha esaurito il suo pool di server backend sani a cui inoltrare le richieste.

Questo significa che il “direttore del traffico” non ha obiettivi validi e, di conseguenza, le richieste dei tuoi utenti non andranno da nessuna parte, il che significa una connessione fallita, un’interruzione e clienti scontenti.

Questo può accadere in praticamente qualsiasi tipo di configurazione, come proxy inversi Nginx, cluster Kubernetes, contenitori Docker o virtualizzati come VMware vCenter, ecc.

Ora, la causa principale varierà in base alla tua configurazione, ma in generale, ecco cosa è andato storto: i tuoi servizi upstream erano o inattivi, in bilico con i controlli di salute, o bloccati da qualche misconfigurazione.

Cosa significa l’errore “No Healthy Upstream”?

Un upstream, nel contesto di architetture bilanciate o a mesh di servizi, rappresenta i server o i servizi backend che gestiscono le richieste provenienti dai client.

Il bilanciatore di carico o gateway (ad es., Nginx, Envoy, API Gateway) prende la decisione su quale server upstream deve assumersi la responsabilità di una richiesta.

Se nessuno dei controlli di salute configurati passa su alcun upstream, o se non riesci a raggiungere nessuno di essi, ricevi l’errore No Healthy Upstream.

Scenari tipici in cui appare

• Fallimento nel controllo di salute a causa di una risposta lenta o di una configurazione errata.

• I servizi backend non sono accessibili a causa di problemi di connettività di rete.

• Se una regola di instradamento è configurata in modo errato, il traffico va verso obiettivi errati.

Esempi in diversi sistemi

• Nginx: [error] no live upstreams while connecting to upstream

• Kubernetes: 0/3 nodi disponibili: 3 nodo(i) avevano taints che il pod non tollerava

• Docker: servizio “app” non è sano

Cause comuni su diverse piattaforme

Sebbene il motivo esatto differisca a seconda dell’ambiente, le cause più comuni includono:

2. Crash o arresto del servizio backend: Il servizio si ferma o si arresta, e non ci sono più istanze in esecuzione.

3. Impostazioni errate del controllo di salute: Se fallisce, il bilanciatore di carico considera i server sani come “giù”, rimuovendoli dal pool.

4. Problemi di risoluzione DNS: Il nome di dominio del backend non può essere risolto in un indirizzo IP.

5. Mismatch di porta: La configurazione delle impostazioni upstream riguarda una porta errata su cui il servizio backend ascolta.

6. Politiche di rete e firewall: Il bilanciatore di carico non può comunicare con il backend poiché bloccato da regole di sicurezza.

7. Scadenza del certificato: Nelle configurazioni SSL/TLS, i certificati scaduti possono interrompere le connessioni sicure.

8. Pianificazione dei pod o taints dei nodi in Kubernetes: Condizioni di nodo incompatibili possono causare il non funzionamento dei pod.

Come diagnosticare l’errore

La fase iniziale per risolvere l’errore No healthy upstream sarà determinare dove sta fallendo, sia al bilanciatore di carico, alla rete o al servizio backend.

Passo 1: Controlla la disponibilità del backend

• Per i servizi Linux: systemctl status

• Per controlli delle porte di rete: netstat -tulpn | grep

Passo 2: Testa la connettività di rete

• Dal bilanciatore di carico al backend:

# Esempio (sostituisci i segnaposto prima di eseguire):
curl -v :/

• Testa la risoluzione DNS: dig backend.example.com

Passo 3 – Rivedi i log

• Nginx: /var/log/nginx/error.log

• Kubernetes: kubectl describe pod

• Docker: docker logs

• vCenter: log di certificato e servizio

Passo 4 – Verifica i controlli di salute

• Assicurati che il tuo /health endpoint restituisca un appropriato 200 OK o uno stato simile.

• Assicurati che il percorso e il metodo siano quelli che il bilanciatore di carico è configurato per controllare.

Correzioni specifiche per piattaforma

A. Nginx

Se Nginx mostra nessun upstream attivo, le liste sono solitamente un segno di un problema relativo alle tue definizioni di backend o a un fallimento nel controllo di salute.

Checklist per risolvere Nginx:

2. Conferma che gli IP/nomi host del backend siano corretti.

3. Verifica che i servizi backend siano in esecuzione e raggiungibili.

4. Regola le configurazioni dei controlli di salute:

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

2. Facoltativamente aggiungi controlli di salute attivi (richiede Nginx Plus o un modulo):

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

Nel bilanciamento del carico di Kubernetes, desideri probe di prontezza e mappatura servizio-pod.

Correzioni comuni:

2. Assicurati che i pod siano in esecuzione: kubectl get pods

3. Controlla le impostazioni della probe di prontezza:

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

2. Verifica che i selettori di servizio corrispondano alle etichette dei pod.

3. Ispeziona le politiche di rete per il traffico bloccato.

C. Docker

In Docker e Docker Compose, se i controlli di salute per un contenitore stanno passando, quando contrassegnato come sano.

Passi di correzione:

2. Rivedi lo stato di salute del contenitore: docker inspect

Implementa o correggi un controllo di salute in docker-compose.yml:

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

2. Assicurati che il tuo servizio serva effettivamente l’endpoint /health.

D. VMware vCenter

Spesso, il motivo può essere dovuto a certificati SSL scaduti. Questo è principalmente rilevante per gli utenti di vCenter. Ecco come controllare se i certificati sono scaduti o meno:

• Inizialmente, avvia vCenter Appliance.

• Esegui questo comando: 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;

• Ora, controlla se i certificati Machine_SSL e Solution User sono scaduti. Se lo sono, sostituiscili.

• Puoi anche eseguire il vCenter Windows o PowerShell per questo: $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”}

Azioni di recupero immediate

Se hai bisogno di un ripristino rapido mentre lavori sulla causa principale:

• Ripeti il servizio sul backend, che fornisce servizi temporanei nella versione aggiornata del servizio backend.

• Aggiorna DNS o indirizzi IP se c’è un problema di risoluzione.

• Aggiungi un server di backup al blocco upstream come gestore temporaneo.

• Disabilita temporaneamente i controlli di salute errati (non è una soluzione permanente).

Prevenire errori No Healthy Upstream

La prevenzione riguarda la resilienza e la visibilità:

2. Migliori pratiche per i controlli di salute

• Ogni servizio può offrire endpoint /health
• Se il servizio è attivo, risponde semplicemente con un semplice 200 OK.
• Questi timeout + limite di ripetizione dovrebbero effettivamente rappresentare una reale performance.

4. Ridondanza

• Usa più istanze backend.
• Sii sempre pronto a far partire almeno un altro server di backup.

6. Monitoraggio e avvisi

• Prometheus + Grafana, Datadog o New Relic che possono avvisarti prima di un totale fallimento upstream.
• Monitora latenza, tassi di errore e conteggi di connessione.

8. Igiene della configurazione

• Tieni aggiornati i record DNS.
• Documenta le porte dei servizi e i percorsi dei controlli di salute.
• Usa interruttori di circuito per prevenire fallimenti a cascata.

10. Regole di sicurezza e rete

• Rivedi regolarmente le regole del firewall e le politiche di rete di Kubernetes
• Tieni aggiornati i certificati SSL.

FAQ

Posso risolvere questo senza accesso al server?

No, devi essere un amministratore di sistema o uno sviluppatore per risolvere problemi di backend o di configurazione, se ce ne sono.

È sempre un problema di backend?

Non sempre, tranne quando si tratta di una configurazione del bilanciatore di carico o DNS.

Quanto tempo ci vuole per risolvere?

Misconfigurazioni minori possono essere risolte in pochi minuti; problemi di rete o di scalabilità possono richiedere ore.

Questo influisce sulle prestazioni anche prima del fallimento totale?

Sì, i fallimenti parziali upstream possono portare a un aumento della latenza e dei tassi di errore anche prima dell’interruzione totale.

Quali strumenti di monitoraggio sono i migliori?

Prometheus + Grafana, Datadog, New Relic e il monitoraggio nativo del cloud sono tutti ottimi.

Considerazioni finali

L’errore No Healthy Upstream sembra essere più di un semplice bug vago; questo è un indicatore che il sistema che gestisce le richieste verso la tua infrastruttura backend non ha accesso a quei backend.

Un messaggio di errore per l’utente finale e un’azione per l’amministratore. Non importa se stai eseguendo Nginx, Kubernetes, Docker e VMware; i principi rimangono gli stessi. Monitora, verifica la configurazione, conferma l’accesso alla rete e valida la salute del servizio.

Attraverso una combinazione di correzioni rapide e soluzioni a lungo termine, puoi ridurre notevolmente la possibilità che questo errore influisca mai sui tuoi servizi.