Erreur No Healthy Upstream – Guide Complet pour Comprendre, Corriger et Prévenir

Dépanner

Lorsque vous voyez une erreur “No Healthy Upstream” provenant d’applications web, d’API ou de services, cela signale souvent que votre répartiteur de charge ou votre passerelle a épuisé son pool de serveurs backend sains pour transmettre les demandes.

Cela signifie que le “directeur de trafic” n’a pas de cibles valides, et en tant que tel, les demandes de vos utilisateurs n’iront nulle part, ce qui signifie une connexion échouée, une panne et des clients mécontents.

Cela peut se produire dans presque tous les types de configurations, comme les proxys inverses Nginx, les clusters Kubernetes, les conteneurs Docker ou les virtualisés comme VMware vCenter, etc.

Maintenant, la véritable cause racine variera en fonction de votre configuration, mais en général, voici ce qui a mal tourné : vos services en amont étaient soit hors service, soit en difficulté avec les vérifications de santé, soit bloqués par une mauvaise configuration.

Que signifie l’erreur “No Healthy Upstream” ?

Un amont, dans le contexte des architectures équilibrées par charge ou de maillage de services, représente les serveurs ou services backend qui gèrent les demandes provenant des clients.

Le répartiteur de charge ou la passerelle (par exemple, Nginx, Envoy, API Gateway) prend la décision de savoir quel serveur en amont doit prendre la responsabilité d’une demande.

Si aucune des vérifications de santé configurées ne passe sur aucun amont, ou si vous ne pouvez atteindre aucun d’eux, vous recevez l’erreur No Healthy Upstream.

Erreur No Healthy Upstream

Scénarios typiques où cela apparaît

Échec de la vérification de santé en raison d’une réponse lente ou d’une configuration incorrecte.
Les services backend ne sont pas accessibles en raison de problèmes de connectivité réseau.
Si une règle de routage est mal configurée, le trafic va vers des cibles incorrectes.

Exemples dans différents systèmes

Nginx : [erreur] pas d’amonts actifs lors de la connexion à l’amont
Kubernetes : 0/3 nœuds disponibles : 3 nœuds avaient des taints que le pod n’a pas tolérés
Docker : le service “app” n’est pas sain

Causes courantes sur les plateformes

Bien que la raison exacte diffère selon l’environnement, les causes les plus courantes incluent :

Les services backend plantent ou s’arrêtent : Le service s’arrête ou plante, et il n’y a plus d’instances en cours d’exécution.
Paramètres de vérification de santé incorrects : S’ils échouent, le répartiteur de charge considère les serveurs sains comme “hors service”, les retirant du pool.
Problèmes de résolution DNS : Le nom de domaine du backend ne peut pas être résolu en une adresse IP.
Mauvais port : La configuration des paramètres en amont concerne un port incorrect sur lequel le service backend écoute.
Politiques réseau et pare-feu : Le répartiteur de charge ne peut pas communiquer avec le backend car bloqué par des règles de sécurité.
Expiration de certificat : Dans les configurations SSL/TLS, les certificats expirés peuvent perturber les connexions sécurisées.
Planification de pod ou taints de nœud dans Kubernetes : Des conditions de nœud incompatibles peuvent empêcher les pods de s’exécuter.

Comment diagnostiquer l’erreur

La phase initiale pour résoudre l’erreur No healthy upstream consistera à déterminer où cela échoue, soit au niveau du répartiteur de charge, du réseau ou du service backend.

Étape 1 : Vérifier la disponibilité du backend

Pour les services Linux : systemctl status
Pour les vérifications de port réseau : netstat -tulpn | grep

Étape 2 : Tester la connectivité réseau

Du répartiteur de charge au backend :

# Exemple (remplacez les espaces réservés avant d'exécuter) :
curl -v :/

Tester la résolution DNS : dig backend.example.com

Étape 3 – Examiner les journaux

Nginx : /var/log/nginx/error.log
Kubernetes : kubectl describe pod
Docker : docker logs
vCenter : journaux de certificat et de service

Étape 4 – Vérifier les vérifications de santé

Assurez-vous que votre /health renvoie un statut 200 OK approprié ou similaire.
Assurez-vous que le chemin et la méthode sont ceux que le répartiteur de charge est configuré pour vérifier.

Corrections spécifiques à la plateforme

A. Nginx

Si Nginx affiche pas d’amonts actifs, les listes sont généralement un signe d’un problème lié à vos définitions backend ou à un échec dans la vérification de santé.

Liste de contrôle pour corriger Nginx :

Confirmez que les IP/nom d’hôte backend sont corrects.
Vérifiez que les services backend sont en cours d’exécution et accessibles.
Ajustez les configurations de vérification de santé :

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

Ajoutez éventuellement des vérifications de santé actives (nécessite Nginx Plus ou un module) :

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

Dans l’équilibrage de charge Kubernetes, vous souhaitez des probes de disponibilité et une correspondance service-pod.

Corrections courantes :

Assurez-vous que les pods sont en cours d’exécution : kubectl get pods
Vérifiez les paramètres de probe de disponibilité :

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

Vérifiez que les sélecteurs de service correspondent aux étiquettes des pods.
Inspectez les politiques réseau pour le trafic bloqué.

C. Docker

Dans Docker et Docker Compose, si les vérifications de santé pour un conteneur passent, lorsqu’il est marqué comme sain.

Étapes de correction :

Examinez l’état de santé du conteneur : docker inspect

Implémentez ou corrigez une vérification de santé dans docker-compose.yml :

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

Assurez-vous que votre service sert réellement le point de terminaison /health.

D. VMware vCenter

Souvent, la raison peut être due à des certificats SSL expirés. Cela est principalement pertinent pour les utilisateurs de vCenter. Voici comment vérifier si les certificats sont expirés ou non :

Tout d’abord, lancez vCenter Appliance.
Exécutez cette commande : 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;
Maintenant, vérifiez si les certificats Machine_SSL et Solution User sont expirés. S’ils le sont, remplacez-les.
Vous pouvez également exécuter le vCenter Windows ou PowerShell pour cela : $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”}

Actions de récupération immédiates

Si vous avez besoin d’une restauration rapide pendant que vous travaillez sur la cause profonde :

Réessayez le service sur le backend, ce qui donne des services temporaires dans la version mise à jour du service backend.
Mettez à jour les DNS ou les adresses IP s’il y a un problème de résolution.
Ajoutez un serveur de secours au bloc en amont en tant que gestionnaire temporaire.
Désactivez temporairement les mauvaises vérifications de santé (pas une solution permanente).

Prévenir les erreurs No Healthy Upstream

La prévention concerne la résilience et la visibilité :

Meilleures pratiques de vérification de santé

Chaque service peut offrir des points de terminaison /health
Si le service est opérationnel, il répond simplement avec un 200 OK simple.
Ces délais d’attente + limite de réessai devraient en fait représenter une véritable performance.

Redondance

Utilisez plusieurs instances backend.
Soyez toujours prêt à faire monter au moins un serveur de secours supplémentaire.

Surveillance & Alertes

Prometheus + Grafana, Datadog ou New Relic qui peuvent vous alerter avant une panne totale en amont.
Surveillez la latence, les taux d’erreur et les comptes de connexion.

Hygiène de configuration

Gardez les enregistrements DNS à jour.
Documentez les ports de service et les chemins de vérification de santé.
Utilisez des disjoncteurs pour éviter les pannes en cascade.

Règles de sécurité & réseau

Examinez régulièrement les règles de pare-feu et les politiques réseau Kubernetes
Gardez les certificats SSL à jour.

FAQ

Puis-je corriger cela sans accès au serveur ?

Non, vous devez être administrateur système ou développeur pour corriger les problèmes backend ou de configuration, s’il y en a.

Est-ce toujours un problème backend ?

Pas toujours, sauf lorsque c’est une configuration de répartiteur de charge ou de DNS.

Combien de temps cela prend-il à corriger ?

Les erreurs de configuration mineures peuvent être corrigées en quelques minutes ; les problèmes de réseau ou de mise à l’échelle peuvent prendre des heures.

Cela affecte-t-il les performances même avant une panne totale ?

Oui, les pannes partielles en amont peuvent entraîner des augmentations de latence et de taux d’erreur même avant la panne complète.

Quels outils de surveillance sont les meilleurs ?

Prometheus + Grafana, Datadog, New Relic et la surveillance cloud native sont tous excellents.

Dernières réflexions

L’erreur No Healthy Upstream semble être plus qu’un simple bogue vague ; c’est un indicateur que le système gérant les demandes vers votre infrastructure backend n’a pas accès à ces backends.

Un message d’erreur pour l’utilisateur final et un élément d’action pour l’administrateur. Peu importe si vous exécutez Nginx, Kubernetes, Docker et VMware ; les principes restent les mêmes. Surveillez, vérifiez la configuration, confirmez l’accès au réseau et validez la santé du service.

Grâce à une combinaison de corrections rapides et de solutions à long terme, vous pouvez considérablement réduire la chance que cette erreur ait un impact sur vos services.