Я пытаюсь настроить балансировщик нагрузки HTTPS для GKE, используя балансировщик нагрузки HTTPS L7, но по какой-то причине не работает. Даже балансировщик нагрузки HTTP в пошаговом руководстве по балансировке нагрузки HTTP. IP-адрес правила переадресации создан, и я могу пинговать и телнетить к порту 80. Но при запросе через curl выдает ошибку.
<title>502 Server Error</title> </head> <body text=#000000
bgcolor=#ffffff> <h1>Error: Server Error</h1> <h2>The server
encountered a temporary error and could not complete your request.
<p>Please try again in 30 seconds.</h2> <h2></h2> </body></html>
Все шаги были в порядке, и я создал брандмауэр без каких-либо тегов для $ {NODE_PORT}, но он не работал.
Кто-нибудь сталкивался с этой проблемой?
У меня была такая же проблема с моим приложением, проблема в том, что у нас не было конечной точки, возвращающей "Успех", и проверки работоспособности всегда терпели неудачу.
Похоже, что балансировщик нагрузки HTTP/HTTPS не отправляет запрос узлам кластера, если проверки работоспособности не проходят, поэтому мое решение заключалось в создании конечной точки, которая всегда возвращает 200 OK, и как только проверка работоспособности проходили, LB начал работать.
Я только что прошел через пример и (до открытия брандмауэра для $NODE_PORT) увидел ту же самую ошибку 502.
Если вы посмотрите в облачной консоли на
https://console.developers.google.com/project/<project>/loadbalancing/http/backendServices/details/web-map-backend-service
вы должны увидеть, что бэкэнд показывает 0 из ${num_nodes_in_cluster} как здоровый.
Для определения вашего брандмауэра убедитесь, что исходный фильтр установлен на 130.211.0.0/22 на разрешить трафик из службы балансировки нагрузки и установить разрешенные протоколы и порты в tcp:$NODE_PORT.
Я использую GKE, и я просто прошел через пример, и он отлично работает, но когда я направляюсь к своему собственному сервису, он дозирует не работа. (моя служба - это сервис api rest)
Я обнаружил, что самая большая разница между моей службой и примером заключается в следующем: в примере получен корневой конечный пункт ( "/" ), но я не поддерживаю.
Итак, я решил эту проблему следующим образом: добавьте корневую конечную точку ( "/" ) в мою службу и просто верните успех (пустая конечная точка, которая ничего не возвращает), а затем повторно создайте вход и ждали несколько минут, а затем работает!
Я думаю, что эта проблема должна быть вызвана здоровой проверкой UNHEALTHY instances do not receive new connections.
Вот ссылка на Healthy checks: https://cloud.google.com/compute/docs/load-balancing/health-checks
Проблема решена через несколько минут (например, 5-10 минут) в моем случае.
При использовании входа может быть дополнительная информация в событиях, связанных с входом. Для просмотра этих:
kubectl describe ingress example
В моем случае балансировщик нагрузки возвращал эту ошибку, потому что на моих экземплярах и группах экземпляров не было запущено ни одного веб-сервера для обработки сетевого запроса.
Я установил nginx на все машины, после чего он начал работать.
С этого момента я решил добавить nginx в мой скрипт запуска при создании экземпляра vm/.
Если вы используете nginx позади своего loadbalancer, тогда важно, чтобы default_server возвращал 200 или некоторые другие 2 **. Это означает, что если, например, у вас есть правило перезаписи, которое возвращает 301, то оно не будет выполнено.
Решение состоит в том, чтобы установить default_server на вашем главном сервере:
server {
# Rewrite calls to www
listen 443;
server_name example.com;
return 301 https://www.example.com$request_uri;
}
server {
listen 443 default_server;
server_name www.example.com;
...