Error No Healthy Upstream – Guía Completa para Entender, Arreglar y Prevenirlo

Cuando ves un error “No Healthy Upstream” de aplicaciones web, APIs o servicios, a menudo indica que tu balanceador de carga o puerta de enlace ha agotado su grupo de servidores backend saludables para pasar solicitudes.

Esto significa que el “director de tráfico” no tiene objetivos válidos, y como tal, las solicitudes de tus usuarios no irán a ninguna parte, lo que significa una conexión fallida, una interrupción y clientes descontentos.

Esto puede suceder en prácticamente cualquier tipo de configuración, como proxies inversos de Nginx, clústeres de Kubernetes, contenedores de Docker, o virtualizados como VMware vCenter, etc.

Ahora, la causa raíz real variará según tu configuración, pero en general, aquí está lo que salió mal: tus servicios upstream estaban caídos, tambaleándose con las comprobaciones de salud, o siendo bloqueados por alguna mala configuración.

¿Qué significa el error “No Healthy Upstream”?

Un upstream, en el contexto de arquitecturas balanceadas por carga o de malla de servicios, representa los servidores o servicios backend que manejan las solicitudes que provienen de los clientes.

El balanceador de carga o puerta de enlace (por ejemplo, Nginx, Envoy, API Gateway) toma la decisión sobre qué servidor upstream necesita hacerse responsable de una solicitud.

Si ninguna de las comprobaciones de salud configuradas pasa en ningún upstream, o si no puedes alcanzar ninguno de ellos, recibes el error No Healthy Upstream.

Escenarios típicos donde esto aparece

• Fallo en la comprobación de salud debido a una respuesta lenta o configuración incorrecta.

• Los servicios backend no son accesibles debido a problemas de conectividad de red.

• Si una regla de enrutamiento está configurada incorrectamente, el tráfico va a objetivos incorrectos.

Ejemplos en diferentes sistemas

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

• Kubernetes: 0/3 nodos están disponibles: 3 nodo(s) tenían taints que el pod no toleraba

• Docker: servicio “app” no está saludable

Causas Comunes en Todas las Plataformas

Si bien la razón exacta difiere según el entorno, las causas más comunes incluyen:

2. Los servicios backend se bloquean o se apagan: El servicio se detiene o se bloquea, y no hay más instancias en ejecución.

3. Configuraciones incorrectas de comprobación de salud: Si falla, el balanceador de carga considera que los servidores saludables están “caídos”, eliminándolos del grupo.

4. Problemas de resolución de DNS: El nombre de dominio del backend no puede resolverse a una dirección IP.

5. Desajuste de puertos: La configuración de los ajustes upstream sobre un puerto incorrecto en el que escucha el servicio backend.

6. Políticas de red y cortafuegos: El balanceador de carga no puede comunicarse con el backend debido a reglas de seguridad bloqueadas.

7. Expiración de certificados: En configuraciones SSL/TLS, los certificados expirados pueden interrumpir conexiones seguras.

8. Programación de pods o taints de nodo en Kubernetes: Condiciones de nodo incompatibles pueden causar que los pods no se ejecuten.

Cómo Diagnosticar el Error

La fase inicial para resolver el error No healthy upstream será determinar dónde está fallando, ya sea en el balanceador de carga, la red o el servicio backend.

Paso 1: Verificar Disponibilidad del Backend

• Para servicios de Linux: systemctl status

• Para comprobaciones de puertos de red: netstat -tulpn | grep

Paso 2: Probar Conectividad de Red

• Desde el balanceador de carga hacia el backend:

# Ejemplo (reemplaza los marcadores de posición antes de ejecutar):
curl -v :/

• Probar resolución de DNS: dig backend.example.com

Paso 3 – Revisar Registros

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

• Kubernetes: kubectl describe pod

• Docker: docker logs

• vCenter: Registros de certificados y servicios

Paso 4 – Verificar Comprobaciones de Salud

• Asegúrate de que tu /health endpoint devuelva un estado 200 OK apropiado o similar.

• Asegúrate de que la ruta y el método son lo que el balanceador de carga está configurado para verificar.

Soluciones Específicas de la Plataforma

A. Nginx

Si Nginx muestra no live upstreams, las listas suelen ser un signo de un problema relacionado con tus definiciones de backend o fallo en la comprobación de salud.

Lista de verificación para arreglar Nginx:

2. Confirma que las IP/nombres de host del backend son correctos.

3. Verifica que los servicios backend estén en ejecución y sean accesibles.

4. Ajusta las configuraciones de comprobación de salud:

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

2. Opcionalmente, añade comprobaciones de salud activas (requiere Nginx Plus o un módulo):

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

En el balanceo de carga de Kubernetes, deseas sondas de disponibilidad y mapeo de servicio a pod.

Soluciones comunes:

2. Asegúrate de que los pods estén en ejecución: kubectl get pods

3. Verifica la configuración de las sondas de disponibilidad:

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

2. Verifica que los selectores de servicio coincidan con las etiquetas de los pods.

3. Inspecciona las políticas de red para tráfico bloqueado.

C. Docker

En Docker y Docker Compose, si las comprobaciones de salud para un contenedor están pasando, cuando se marca como saludable.

Pasos para arreglar:

2. Revisa el estado de salud del contenedor: docker inspect

Implementa o corrige una comprobación de salud en docker-compose.yml:

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

2. Asegúrate de que tu servicio realmente sirva el endpoint /health.

D. VMware vCenter

A menudo, la razón puede deberse a certificados SSL expirados. Esto es principalmente relevante para los usuarios de vCenter. Aquí cómo verificar si los certificados están expirados o no:

• Inicialmente, lanza vCenter Appliance.

• Ejecuta este 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;

• Ahora, verifica si los certificados Machine_SSL y Solution User están expirados. Si lo están, reemplázalos.

• También puedes ejecutar el vCenter de Windows o PowerShell para esto: $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”}

Acciones de Recuperación Inmediata

Si necesitas una restauración rápida mientras trabajas en la causa raíz:

• Reintenta el servicio en el backend, lo que proporciona servicios temporales en la versión actualizada del Servicio Backend.

• Actualiza DNS o direcciones IP si hay un problema de resolución.

• Añade un servidor de respaldo al bloque upstream como un manejador temporal.

• Desactiva temporalmente las malas comprobaciones de salud (no es una solución permanente).

Prevención de Errores No Healthy Upstream

La prevención se trata de resiliencia y visibilidad:

2. Mejores Prácticas de Comprobación de Salud

• Cada servicio puede ofrecer endpoints /health

• Si el servicio está activo, simplemente responde con un simple 200 OK.

• Estos tiempos de espera + límite de reintentos deberían representar un rendimiento real.

4. Redundancia

• Usa múltiples instancias backend.

• Siempre está listo para activar al menos un servidor de respaldo más.

6. Monitoreo y Alertas

• Prometheus + Grafana, Datadog o New Relic que pueden alertarte antes de una falla total del upstream.

• Monitorea latencia, tasas de error y conteos de conexiones.

8. Higiene de Configuración

• Mantén los registros DNS actualizados.

• Documenta los puertos de servicio y las rutas de comprobación de salud.

• Usa interruptores de circuito para prevenir fallas en cascada.

10. Reglas de Seguridad y Red

• Revisa regularmente las reglas de cortafuegos y políticas de red de Kubernetes

• Mantén los certificados SSL actualizados.

Preguntas Frecuentes

¿Puedo arreglar esto sin acceso al servidor?

No, necesitas ser un administrador del sistema o desarrollador para arreglar problemas de backend o configuración, si los hay.

¿Siempre es un problema de backend?

No siempre, excepto cuando se trata de una configuración de balanceador de carga o DNS.

¿Cuánto tiempo lleva arreglarlo?

Las configuraciones incorrectas menores pueden arreglarse en minutos; los problemas de red o escalado pueden tardar horas.

¿Esto afecta el rendimiento incluso antes de una falla total?

Sí, las fallas parciales del upstream pueden llevar a aumentos en la latencia y la tasa de errores incluso antes de la interrupción total.

¿Cuáles son las mejores herramientas de monitoreo?

Prometheus + Grafana, Datadog, New Relic y el monitoreo nativo en la nube son todos excelentes.

Reflexiones Finales

El error No Healthy Upstream parece ser más que un simple error vago; es un indicador de que el sistema que maneja las solicitudes hacia tu infraestructura backend no tiene acceso a esos backends.

Un mensaje de error para el usuario final y un ítem de acción para el Administrador. No importa si estás ejecutando Nginx, Kubernetes, Docker y VMware; los principios siguen siendo los mismos. Monitorea, verifica la configuración, confirma el acceso a la red y valida la salud del servicio.

A través de una combinación de soluciones rápidas y soluciones a largo plazo, puedes reducir en gran medida la posibilidad de que este error afecte tus servicios.