Нездоровая цель AWS ALB после обновления обновления развертывания

Question

У меня есть кластер EKS с aws-alb-ingress-controller , управляющий настройкой AWS ALB, указывающей на кластер EKS.

После непрерывного обновления одного из развертываний произошла ошибка приложения, в результате чего Pod никогда не запускался (модуль застрял в состоянии CrashLoopBackOff). Однако предыдущая версия Pod все еще работает. Но похоже, что статус службы все еще нездоров:

Это означает, что теперь весь трафик перенаправляется на бэкэнд по умолчанию, другой сервис. В этом случае в Kubernetes связанная служба для развертывания имеет тип NodePort:

Type:                     NodePort
IP:                       172.20.186.130
Port:                     http-service  80/TCP
TargetPort:               5000/TCP
NodePort:                 http-service  31692/TCP
Endpoints:                10.0.3.55:5000

Что приводит к тому, что конечная точка становится нездоровой? Я ожидал, что он просто перенаправит трафик на старую версию Pod, которая все еще работает. Можно ли как-нибудь убедиться, что конечная точка остается здоровой?

Answer 1

Проблема заключалась в том, что, хотя в Kubernetes приложение работало, балансировщик нагрузки ALB выполнял собственную проверку работоспособности. Эта проверка работоспособности была настроена по умолчанию для ожидания ответа 200 от конечной точки /, однако для этого конкретного приложения он не возвращал ответ 200 для этой конечной точки.

Поскольку ALB контролируется alb-ingress-контроллером, я добавил аннотацию к моему входу для настройки правильного пути: alb.ingress.kubernetes.io/healthcheck-path: /health. Поскольку мы работаем с Spring Microservices, эта конечная точка работает для всех наших приложений.