Балансировщик нагрузки GCP не может подключиться к группе экземпляров: ошибка нездорового источника.

Содержание

Вопрос или проблема
Моя цель
Моя проблема
Настройка GCP
Ответ или решение
Теоретическая часть
Пример из практики
Применение и решение проблемы

Вопрос или проблема

Моя цель

Я хочу подключить свой домен (dashboards.example.com) к своему экземпляру Google VM на порт 3000, чтобы продемонстрировать Metabase. Я делаю это через Google DNS и балансировщик нагрузки.

Моя проблема

При попытке сделать это и получить доступ к Metabase, перейдя по адресу https://dashboards.example.com, я сталкиваюсь с черным экраном, показывающим no unhealthy upstream. Кроме того, проверки состояния балансировщиков нагрузки (http & https) говорят, что службы бэкэнда нездоровы.

Есть ли кто-нибудь, кто мог бы знать, что я упускаю? Думаю, я что-то упускаю, однако, просматривая весь интернет, я не могу найти решение.

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

Настройка GCP

DNS
Мой DNS класса A указывает на два IP-адреса из балансировщиков нагрузки (глобальный внешний). Когда я пингую домен dashboards.example.com, я правильно вижу IP одного из балансировщиков нагрузки.

Балансировщики нагрузки

HTTPS У меня есть глобальный внешний HTTPS-балансировщик нагрузки с SSL-сертификатом, управляемым Google. На фронтенде используется эфемерный IP-адрес и порт 443. Уровень сетевых сервисов — premium. Бэкэнд backend-https указывает на группу экземпляров, использует протокол HTTPS с именованным портом https. Группа экземпляров находится в europe-west4, и я добавил номер порта 3000. Проверка состояния также указывает на этот порт. Маршрут маршрутизации — основной, с пустыми host и path, указывающими на тот же бэкэнд.
HTTP У меня также есть глобальный внешний HTTP-балансировщик нагрузки. На фронтенде используется эфемерный IP-адрес и порт 80. Уровень сетевых сервисов — premium. Бэкэнд backend-http (различный бэкэнд, указывающий на ту же группу экземпляров) использует протокол HTTP с именованным портом http. Группа экземпляров находится в europe-west4, и я добавил номер порта 3000. Проверка состояния также указывает на этот порт. Маршрут маршрутизации — основной, с пустыми host и path, указывающими на тот же бэкэнд.

Затем в обзоре проверки состояния уже не проходят, и я не могу понять, почему.

Группа экземпляров
Группа экземпляров находится в зоне europe-west4-a и содержит один экземпляр VM. Кроме того, у нее есть два именованных порта, называемых https и http, оба ведущих на порт 3000.

Сеть
Все добавлено в одну подсеть или VPC. Я добавил правила брандмауэра, чтобы разрешить трафик от проверок состояния, SSH и балансировщиков нагрузки ко всем экземплярам в сети по TCP-порту 3000.

Дополнительно
Еще одно странное, что я заметил, — проверка состояния оказывается здоровой, когда я выключаю VM.

Кто-нибудь может заметить мою ошибку?

Я пробовал такие вещи, как перезапуск своего компьютера или очистка кеша домена и браузера. Также я пытался несколько раз переконфигурировать балансировщики нагрузки. Безуспешно, к сожалению.

Ответ или решение

Конфигурация Google Cloud Platform (GCP) с использованием балансировщика нагрузки и группы экземпляров для запуска Metabase на виртуальной машине (VM) через домен dashboards.example.com, кажется, сталкивается с проблемой соединения. Сообщение об ошибке “no unhealthy upstream” указывает на то, что балансировщик нагрузки не может установить успешное соединение с бэкендом из-за проблем со здоровьем инфраструктуры. Давайте рассмотрим возможные причины и решения этой проблемы.

Теоретическая часть

Любая инфраструктура, использующая балансировку нагрузки, должна обеспечивать поддержание здоровья бэкендов, чтобы запросы от клиентов могли корректно маршрутизироваться. В контексте GCP, бэкенды могут быть признаны нездоровыми, если они не проходят проверки здоровья, которые настраиваются как часть определения балансировщика нагрузки.

Основные факторы, определяющие успешное прохождение проверки здоровья:

Конфигурация проверки здоровья: она должна быть правильно настроена для проверки конкретного порта и пути, который доступен и отвечает на запросы.
Конфигурация фаервола: должна разрешать трафик от балансировщиков нагрузки и системы проверки здоровья GCP на порты, используемые для работы приложения.
Состояние приложения: приложение должно быть развернуто и отвечать на запросы на указанном порту.

Пример из практики

В вашем случае, вы указали следующие настройки:

DNS правильно настроен на IP-адреса балансировщиков нагрузки.
Настроены два различных балансировщика нагрузки (HTTP и HTTPS), каждый с разными IP и портами (80 и 443 соответственно).
Оба балансировщика обращаются к одному и тому же экземпляру через порт 3000.
Проверка здоровья настроена на порт 3000 как для HTTP, так и для HTTPS.
Фаерволы настроены для разрешения трафика на порт 3000 от балансировщиков нагрузки и проверок здоровья.

Применение и решение проблемы

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

Проверка здоровья: Метаданные указанных проверок здоровья должны соответствовать действительно доступной эндпоинт-точке, к которой может подключаться проверка здоровья. Если, например, проверка здоровья пытается получить доступ к несуществующему URL или порт 3000 не отвечает в том формате, который ожидается, то это может стать источником проблемы. Убедитесь, что приложение, развернутое на VM, правильно отвечает на запрос проверки здоровья.
Настройки сети и фаервола: Необходимо убедиться, что все сети и списки контроля доступа действительно позволяют трафик от IP-адресов, указанных для балансировщиков нагрузки и проверок здоровья. Вы также можете рассмотреть возможность временного добавления логов по пакетам для выявления необработанных запросов.
Конфигурация back-end: Проблемы могут скрываться в конфигурации комплектов бэкендов или групп экземпляров. Проверьте, что экземпляры настроены правильно и что Service Port соответствует настроенному порту в группе экземпляров.
Методология тестирования: Попробуйте симулировать запросы проверки здоровья вручную с территории VM, чтобы убедиться в их проходимости. Если такие запросы не проходят, проанализируйте логи и сообщения об ошибках, чтобы найти источник отказа.
Обрабатываемый контент: Если вендорское приложение Metabase требует дополнительной конфигурации для работы над определёнными портами, необходимо провести ее исследование и корректировку.

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

Проблема, когда проверки здоровья выглядят здоровыми при выключенном VM, может указывать на неправильные исключения в правилах маршрутизации или неверные пробросы портов. Это может быть полезно для диагностики того, какой маршрут используется при отсутствии трафика; возможно, есть мусорные или остаточные маршруты. Проверьте также, нет ли каких-либо специфических ошибок на уровне группы экземпляров, которые могут блокировать запросы.

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