Вход на GKE остается в статусе "Backend нездоровый" - PullRequest
Новая
       3

Вход на GKE остается в статусе "Backend нездоровый"

0 голосов
/ 31 мая 2018

Дано:

  • простой модуль, запускающий nginx
  • служба нодпорта
  • вход

При вызове pod внутри кластера мы получаем код ответа 200

При вызове службы из кластера мы получаем код ответа 200

Входотображается в виде аннотации:

ingress.kubernetes.io/backends: '{"k8s-be-30606--559b9972f521fd4f":"UNHEALTHY"}'

Для начала у нас есть другой кластер kubernetes с точно такой же конфигурацией (кроме пространства имен dev vs qa & timestamps & назначенных ips & ports) где все работает должным образом.

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

Судя повыше это проверка работоспособности на модуле, которая по какой-то причине не проходит (хотя, если мы делаем это вручную (сверните к внутреннему ip узла + порт узла из службы из кластера), он возвращает 200 & in qa работает нормально с тем же образом контейнера).

Есть ли какой-либо журнал, доступный в журнале Stackdriver (или где-либо еще), где мы можем видеть, какой именно запрос выполняется этой проверкой работоспособности и какой точный код ответаявляется?(или по какой-то причине истекло время ожидания?)

Можно ли как-то получить больше информации о том, что происходит в процессах Google?

Мы используем стандартный входной контроллер gke.

Некоторая дополнительная информация: при сравнении с совершенно другим приложением я вижу тонны таких запросов: 

10.129.128.10 - - [31/May/2018:11:06:51 +0000] "GET / HTTP/1.1" 200 1049 "-" "GoogleHC/1.0"
10.129.128.8 - - [31/May/2018:11:06:51 +0000] "GET / HTTP/1.1" 200 1049 "-" "GoogleHC/1.0"
10.129.128.12 - - [31/May/2018:11:06:51 +0000] "GET / HTTP/1.1" 200 1049 "-" "GoogleHC/1.0"
10.129.128.10 - - [31/May/2018:11:06:51 +0000] "GET / HTTP/1.1" 200 1049 "-" "GoogleHC/1.0"

Я полагаю, что это проверки работоспособности.Я не вижу подобных журналов для сбойного приложения и рабочей версии в qa.Итак, я думаю, что проверки работоспособности заканчиваются где-то совершенно иначе, и случайно в qa это тоже что-то, что также возвращает 200. Таким образом, остается вопрос: где я могу увидеть реальные запросы, выполненные проверкой работоспособности?

Также для этогоВ конкретном приложении я вижу около 8 проверок работоспособности в секунду для этого отдельного модуля, что мне кажется немного большим (установленный интервал составляет 60 секунд).Возможно ли, что проверки работоспособности для других приложений заканчиваются в этом?

Ответы [ 2 ]

0 голосов
/ 15 июня 2018

К сожалению, нет обращающихся к пользователю журналов, показывающих состояние запросов проверки работоспособности (вероятно, из-за объема журналов, которые это может создать)

Что касается первого вопроса, GKE ДОЛЖЕН обрабатывать все брандмауэрыправила автоматически, если это не в вашем случае, это либо из-за проблемы с версией узла, либо из-за конкретной проблемы пользователя (в этом случае я предлагаю отправить сообщение об ошибке в Google на трекере )

0 голосов
/ 01 июня 2018

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

Еще нужно выяснить:

  • почему портбольше не добавляются автоматически?
  • почему я не вижу проверки работоспособности в журнале доступа?

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

edit :

Ошибка оказалась недействительным сертификатом, используемым завершением tls не связанным (за исключением того, что он управляется тем же сертификатом).контроллер) вход.Как только это было исправлено, правило снова автоматически обновлялось.

...