Проверка здоровья Traefik с помощью аннотации kubernetes - PullRequest
Новая
       7

Проверка здоровья Traefik с помощью аннотации kubernetes

0 голосов
/ 11 сентября 2018

Я хочу настроить проверку работоспособности бэкэнда Traefik с помощью аннотации Kubernetes, но похоже, что Kubernetes Ingress не поддерживает эту функциональность в соответствии с официальной документацией.

Есть ли какая-либо конкретная причина, по которой Traefik не поддерживает эту функциональность для Kubernetes Ingress? Мне интересно, потому что Mesos поддерживает проверки работоспособности для бэкенда.

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

UPD:

  • Единственный лидер может принять соединение от Traefik; подписчик откажется от соединения.
  • У меня в уме две проверки готовности:
    • Служба запущена и работает и готова к избранию в качестве лидера (проверка готовности к кубернетам)
    • Служба запущена и работает как лидер (проверка здоровья traefik)

1 Ответ

0 голосов
/ 11 сентября 2018

Traefik полагается на Kubernetes, чтобы предоставить информацию о состоянии базовых контейнеров, чтобы выяснить, готовы ли они предоставлять услуги. Kubernetes предоставляет два механизма для передачи информации на уровень оркестровки:

  • Проверка живучести , чтобы предоставить Kubernetes указание, когда процессы, выполняющиеся в модуле, перешли в нерабочее состояние. Неудачная проверка живучести заставит Кубернетеса уничтожить стручок и воссоздать его.
  • Проверка готовности , чтобы определить, когда контейнер готов предоставить услугу. Неудачная проверка готовности заставит контроллер конечной точки удалить модуль из списка конечных точек любых служб, которые он предоставляет. Тем не менее, он будет работать.

В этом случае вы предоставили бы информацию Traefik через проверку готовности. Настройте свои модули на проверку готовности, которая не проходит, если они находятся в состоянии, в котором они не должны получать трафик. Когда состояние готовности изменится, Kubernetes обновит список конечных точек для любых служб, которые направляют трафик на модуль, чтобы добавить или удалить модуль. Соответственно, Traefik обновит свой взгляд на мир, добавив или удалив модуль из списка конечных точек, поддерживающих Ingress.

Нет причин для того, чтобы эта модель была несовместима с вашей архитектурой ведущий / ведомый, при условии, что каждый модуль может определить, является ли он ведущим или ведомым, и предоставить соответствующую индикацию при проверке готовности. Однако, без особой осторожности, будут расы между изменением состояния мастер / последователь и Kubernetes, обновляющими его конечные точки, поскольку проверки готовности выполняются только периодически. Я рекомендую предположить, что так будет и должна быть встроенная логика для отклонения запросов, полученных неосновными модулями.

В качестве будущего подхода к повышению надежности вы можете отделить входной слой вашего сервиса от бизнес-логики, реализующей систему мастер / подписчик, позволяя всем экземплярам связываться с Traefik и ставить работу на рассмотрение любому «хозяину». узел в этой точке.

...