Балансировщик нагрузки HTTPS в Google Container Engine

Я пытаюсь настроить балансировщик нагрузки 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}, но он не работал.

Кто-нибудь сталкивался с этой проблемой?

Ответ 1

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

Похоже, что балансировщик нагрузки HTTP/HTTPS не отправляет запрос узлам кластера, если проверки работоспособности не проходят, поэтому мое решение заключалось в создании конечной точки, которая всегда возвращает 200 OK, и как только проверка работоспособности проходили, LB начал работать.

Ответ 2

Я только что прошел через пример и (до открытия брандмауэра для $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.

Ответ 3

Я использую GKE, и я просто прошел через пример, и он отлично работает, но когда я направляюсь к своему собственному сервису, он дозирует не работа. (моя служба - это сервис api rest)

Я обнаружил, что самая большая разница между моей службой и примером заключается в следующем: в примере получен корневой конечный пункт ( "/" ), но я не поддерживаю.

Итак, я решил эту проблему следующим образом: добавьте корневую конечную точку ( "/" ) в мою службу и просто верните успех (пустая конечная точка, которая ничего не возвращает), а затем повторно создайте вход и ждали несколько минут, а затем работает!

Я думаю, что эта проблема должна быть вызвана здоровой проверкой UNHEALTHY instances do not receive new connections.

Вот ссылка на Healthy checks: https://cloud.google.com/compute/docs/load-balancing/health-checks

Ответ 4

Проблема решена через несколько минут (например, 5-10 минут) в моем случае.

При использовании входа может быть дополнительная информация в событиях, связанных с входом. Для просмотра этих:

kubectl describe ingress example

Ответ 5

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

Я установил nginx на все машины, после чего он начал работать.

С этого момента я решил добавить nginx в мой скрипт запуска при создании экземпляра vm/.

Ответ 6

Если вы используете 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;
    ...