Ошибка "Нет здорового upstream" – Полное руководство по пониманию, исправлению и предотвращению

Когда вы видите ошибку “Нет здорового upstream” от веб-приложений, API или сервисов, это часто сигнализирует о том, что ваш балансировщик нагрузки или шлюз исчерпал свой пул здоровых серверов для передачи запросов.

Это означает, что “директор трафика” не имеет действительных целей, и, следовательно, запросы ваших пользователей не достигнут цели, что означает сбой соединения, отключение и недовольных клиентов.

Это может произойти практически в любом типе настройки, например, в обратных прокси Nginx, кластерах Kubernetes, контейнерах Docker или виртуализированных системах, таких как VMware vCenter и т. д.

Теперь реальная причина будет варьироваться в зависимости от вашей настройки, но в общем, вот что пошло не так: ваши upstream-сервисы либо были недоступны, либо колебались при проверках состояния, либо блокировались из-за неправильной конфигурации.

Что означает ошибка “Нет здорового upstream”?

Upstream в контексте архитектур с балансировкой нагрузки или сервисной сеткой представляет собой серверы или сервисы на стороне сервера, которые обрабатывают запросы от клиентов.

Балансировщик нагрузки или шлюз (например, Nginx, Envoy, API Gateway) принимает решение о том, какой сервер upstream должен взять на себя ответственность за запрос.

Если ни одна из настроенных проверок состояния не проходит ни на одном upstream, или если вы не можете достичь ни одного из них, вы получаете ошибку “Нет здорового upstream”.

Типичные сценарии, в которых это появляется

• Сбой в проверке состояния из-за медленного ответа или неправильной конфигурации.

• Сервисы на стороне сервера недоступны из-за проблем с сетевым подключением.

• Если правило маршрутизации неправильно настроено, трафик идет к неправильным целям.

Примеры в различных системах

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

• Kubernetes: 0/3 nodes are available: 3 node(s) had taints that the pod didn’t tolerate

• Docker: service “app” is not healthy

Общие причины на разных платформах

Хотя точная причина различается в зависимости от окружения, наиболее распространенные причины включают:

2. Сбой или отключение сервиса на стороне сервера: Сервис останавливается или выходит из строя, и больше нет работающих экземпляров.

3. Неправильные настройки проверки состояния: Если она не проходит, балансировщик нагрузки считает здоровые серверы “неработающими”, исключая их из пула.

4. Проблемы с разрешением DNS: Доменное имя сервиса на стороне сервера не может быть разрешено в IP-адрес.

5. Несоответствие портов: Конфигурация настроек upstream о неправильном порте, на котором слушает сервис на стороне сервера.

6. Сетевые политики и брандмауэры: Балансировщик нагрузки не может связаться с сервером на стороне сервера, так как это блокируется правилами безопасности.

7. Истечение срока действия сертификата: В конфигурациях SSL/TLS истекшие сертификаты могут нарушить безопасные соединения.

8. Проблемы с планированием подов или загрязнения узлов в Kubernetes: Несоответствующие условия узлов могут привести к тому, что поды не будут запущены.

Как диагностировать ошибку

Начальная фаза для решения ошибки “Нет здорового upstream” будет заключаться в определении, где она происходит, либо на балансировщике нагрузки, в сети или на сервисе на стороне сервера.

Шаг 1: Проверьте доступность сервиса на стороне сервера

• Для сервисов Linux: systemctl status

• Для проверки сетевых портов: netstat -tulpn | grep

Шаг 2: Проверьте сетевое подключение

• От балансировщика нагрузки к серверу на стороне сервера:

# Пример (замените заполнители перед выполнением):
curl -v :/

• Проверьте разрешение DNS: dig backend.example.com

Шаг 3 – Просмотрите журналы

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

• Kubernetes: kubectl describe pod

• Docker: docker logs

• vCenter: Журналы сертификатов и сервисов

Шаг 4 – Проверьте проверки состояния

• Убедитесь, что ваш /health конечный пункт возвращает соответствующий статус 200 OK или аналогичный.

• Убедитесь, что путь и метод соответствуют тому, что настроен балансировщик нагрузки для проверки.

Исправления, специфичные для платформы

A. Nginx

Если Nginx показывает отсутствие живых upstream, списки обычно являются признаком проблемы, связанной с вашими определениями сервера на стороне сервера или сбоя в проверке состояния.

Контрольный список для исправления Nginx:

2. Подтвердите, что IP/имена хостов сервера на стороне сервера правильные.

3. Убедитесь, что сервисы на стороне сервера работают и доступны.

4. Настройте конфигурации проверки состояния:

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

2. При желании добавьте активные проверки состояния (требуется Nginx Plus или модуль):

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

В балансировке нагрузки Kubernetes вы хотите, чтобы проверки готовности и сопоставление сервисов с подами работали.

Распространенные исправления:

2. Убедитесь, что поды работают: kubectl get pods

3. Проверьте настройки проверки готовности:

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

2. Убедитесь, что селекторы сервиса соответствуют меткам подов.

3. Проверьте сетевые политики на предмет заблокированного трафика.

C. Docker

В Docker и Docker Compose, если проверки состояния для контейнера проходят, когда он помечен как здоровый.

Шаги исправления:

2. Проверьте статус здоровья контейнера: docker inspect

Реализуйте или исправьте проверку состояния в docker-compose.yml:

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

2. Убедитесь, что ваш сервис действительно обслуживает конечный пункт /health.

D. VMware vCenter

Часто причиной может быть истечение срока действия SSL-сертификатов. Это в основном актуально для пользователей vCenter. Вот как вы можете проверить, истекли ли сертификаты или нет:

• Сначала запустите vCenter Appliance.

• Выполните эту команду: 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;

• Теперь посмотрите, истекли ли сертификаты Machine_SSL и Solution User. Если да, то замените их.

• Вы также можете выполнить vCenter Windows или PowerShell для этого: $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”}

Немедленные действия по восстановлению

Если вам нужно быстрое восстановление, пока вы работаете над основной причиной:

• Повторите сервис на стороне сервера, который предоставляет временные услуги в обновленной версии сервиса на стороне сервера.

• Обновите DNS или IP-адреса, если есть проблема с разрешением.

• Добавьте резервный сервер в блок upstream в качестве временного обработчика.

• Временно отключите плохие проверки состояния (это не постоянное решение).

Предотвращение ошибок “Нет здорового upstream”

Предотвращение связано с устойчивостью и видимостью:

2. Лучшие практики проверки состояния

• Каждый сервис может предлагать конечные точки /health

• Если сервис работает, он просто отвечает простым 200 OK.

• Эти таймауты + лимит повторных попыток должны действительно представлять реальную производительность.

4. Резервирование

• Используйте несколько экземпляров на стороне сервера.

• Всегда будьте готовы поднять хотя бы один резервный сервер.

6. Мониторинг и оповещения

• Prometheus + Grafana, Datadog или New Relic, которые могут предупредить вас до полного сбоя upstream.

• Мониторьте задержку, уровень ошибок и количество соединений.

8. Чистота конфигурации

• Держите записи DNS обновленными.

• Документируйте порты сервисов и пути проверки состояния.

• Используйте автоматические выключатели, чтобы предотвратить каскадные сбои.

10. Правила безопасности и сети

• Регулярно проверяйте правила брандмауэра и сетевые политики Kubernetes

• Держите SSL-сертификаты актуальными.

Часто задаваемые вопросы

Могу ли я исправить это без доступа к серверу?

Нет, вам нужно быть системным администратором или разработчиком, чтобы исправить проблемы с сервером или конфигурацией, если таковые имеются.

Это всегда проблема на стороне сервера?

Не всегда, кроме случаев, когда это проблема с балансировщиком нагрузки или конфигурацией DNS.

Сколько времени занимает исправление?

Небольшие неправильные конфигурации могут быть исправлены за минуты; проблемы с сетью или масштабированием могут занять часы.

Влияет ли это на производительность даже до полного сбоя?

Да, частичные сбои upstream могут привести к увеличению задержки и уровня ошибок даже до полного отключения.

Какие инструменты мониторинга лучше всего?

Prometheus + Grafana, Datadog, New Relic и нативный мониторинг облака – все это отличные инструменты.

Заключительные мысли

Ошибка “Нет здорового upstream” кажется больше, чем просто неопределенная ошибка; это индикатор того, что система, обрабатывающая запросы к вашей инфраструктуре на стороне сервера, не имеет доступа к этим серверам.

Сообщение об ошибке для конечного пользователя и пункт действия для администратора. Не имеет значения, используете ли вы Nginx, Kubernetes, Docker или VMware; принципы остаются прежними. Мониторьте, проверяйте конфигурацию, подтверждайте доступ к сети и проверяйте здоровье сервиса.

Сочетание быстрых исправлений и долгосрочных решений может значительно снизить вероятность того, что эта ошибка когда-либо повлияет на ваши услуги.