# #kubernetes #google-cloud-platform #google-kubernetes-engine #kubernetes-ingress #google-cloud-load-balancer
Вопрос:
У меня есть вход k8s, за которым стоит более 5 серверных служб. Вход порождает балансировщик нагрузки GoogleCloud.
Каждая из служб перенаправляет трафик по path правилу http. Например, одно приложение включено /foo , другое включено /bar и т. Д. Все они прекрасно работают. Затем я добавил новое приложение с внутренней службой и правилом маршрутизации, все так же, как и другие.
Но я постоянно получаю эту ошибку, когда нажимаю URL-адрес нового приложения:
Error: Server Error
The server encountered a temporary error and could not complete your request.
Please try again in 30 seconds.
Когда я открываю вход в консоли GCP, я вижу это предупреждение: 
и нездоровая служба-это та, что была в моем недавно добавленном приложении.
Странно то, что приложение действительно получает трафик, когда я нажимаю на URL-адрес. Я вижу это в журналах. Но я все равно получаю ошибку 502, и серверная служба отображается как неработоспособная.
Я не совсем уверен, как это отладить, чтобы понять, в чем проблема.
Комментарии:
1. возвращает ли URL-адрес проверки работоспособности вашей внутренней службы ответ 200? Возможно, проверка работоспособности не выполняется из-за того, что ваше приложение перенаправляется на страницу входа в систему(ответ 302) в вашем тесте готовности/готовности.
2. У меня нет конечной точки проверки работоспособности в этом приложении. Это просто node.js сервер, на котором хранятся статические файлы. Он настроен так, что попадание в любую конечную точку (aka
*) будет либо перенаправляться в другое приложение (если маркер доступа недоступен), либо просто обслуживать статические файлы.3. При настройке входного ресурса GCP создает проверки работоспособности для всех внутренних служб, которые являются частью балансировщика нагрузки. Путь по умолчанию-корневой URL-адрес’/’. Если вы хотите, чтобы URL-адрес проверки работоспособности был чем-то другим, вам нужно прикрепить датчик готовности к вашим блокам.
4. Как отмечали другие, если серверная часть получает трафик, А балансировщик нагрузки сообщает о НЕРАБОТОСПОСОБНОСТИ, ваша проверка работоспособности завершается неудачно. Как только вы решите эту проблему, опубликуйте ответ, показывающий проблему и решение в интересах других.
5. Я вижу в документах GCP ingress , что путь по умолчанию
/-корневой URL-адрес для проверки работоспособности. Но если у меня естьreadinessзонд, вход перенаправит его проверку работоспособности на путьreadinessзонда. Я добавил зонд, но служба все еще застряла вUNHEALTHYсостоянии. И когда я открываю объект проверки работоспособности в консоли GCP, он все еще имеет/свой путь.
Ответ №1:
Итак, проблема заключалась в том, что проверка работоспособности LB поражала / несуществующую конечную точку приложения (она же. он не возвращался OK 200 ).
Я добавил readiness зонд к развертыванию k8s. Согласно документам GCP Ingress, если есть readiness зонд, то входное устройство заберет его и будет использовать в качестве проверки работоспособности LB.
Мне также пришлось вручную обновить путь, по которому шел объект проверки работоспособности серверной службы. Я предполагаю, что модуль с датчиком готовности должен существовать до настройки входа, иначе он не обновит объект проверки работоспособности автоматически.