У меня есть среда AWS Elastic beanstalk, которая может масштабироваться от 2 до 3 экземпляров, настроенных с помощью балансировщика нагрузки приложений. В балансировщике нагрузки настроена проверка работоспособности HTTP для получения ответа 200.
Когда среда автоматически масштабируется до трех экземпляров, новый экземпляр начинает получать трафик до того, как будет готов. Если я вручную проверю URL-адрес проверки работоспособности, я вижу, что 1 из 3 раз он возвращает 404, потому что новый экземпляр не готов. Другие URL-адреса приложения тоже ошибаются, 1 из 3 раз, потому что они не существуют.
Насколько я понимаю, весь смысл URL-адреса проверки работоспособности состоит в том, чтобы справиться с этим. Итак, что могло вызвать проблему, пожалуйста?
Некоторые фрагменты информации, которые могут иметь отношение:
Если я вручную проверю URL-адрес проверки работоспособности, я вижу, что 1 из 3 раз он возвращает 404, потому что новый экземпляр не готов.
Тот факт, что URL-адрес проверки работоспособности работает с исправными узлами, когда вы получаете доступ к одному из них через балансировщик, не обязательно то же самое, что URL-адрес проверки работоспособности работает правильно, когда балансировщик обращается к нему для проверки работоспособности.
Современные версии HTTP требуют, чтобы Host заголовок будет присутствовать в каждом входящем запросе, и балансировщик установит HTTP-заголовок узла на частный IP-адрес экземпляра для запросов проверки работоспособности, но будет передавать значение, установленное браузером при обычных запросах - и ваш браузер устанавливает то же самое заголовок к имени хоста, который вы используете для доступа к балансировщику.
Если вы (и ваши серверы / фреймворк / приложение) не учитываете это, и ваш сервер обрабатывает их по-разному, то все ваши экземпляры могут постоянно не проходить проверки работоспособности, несмотря на то, что ручные проверки работают, когда вы их пытаетесь. Когда происходит это состояние «все цели неработоспособны», ALB предполагает, что самым безопасным способом является пересылка трафика всем экземплярам, как если бы они все были исправны (отказоустойчивый, но не обязательно интуитивно понятный дизайн), что точно объясняет происходящее.
Если целевая группа содержит только нездоровые зарегистрированные целевые объекты, узлы балансировщика нагрузки направляют запросы по своим нездоровым целям.
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html