Модуль service-with-healthchecks предоставляет в Deckhouse Platform (DP) внутренний балансировщик нагрузки (LoadBalancer) с проверками работоспособности для каждого порта.

Модуль работает с кастомным ресурсом ServiceWithHealthchecks, который определяет балансировщик нагрузки типа Service с независимой проверкой работоспособности (TCP, HTTP или PostgreSQL) для каждого порта.

В отличие от стандартного балансировщика, где readiness-пробы привязаны к состоянию контейнеров, кастомный ресурс ServiceWithHealthchecks позволяет настраивать активные пробы на отдельные TCP-порты. Таким образом, каждый балансировщик, обслуживающий один и тот же под, может работать независимо от других: под, не прошедший пробы одного балансировщика, по-прежнему публикуется остальными.

Пробы группируются по порту, который они проверяют, а не по ресурсу. Если проба не проходит, трафик перестаёт идти на под только через этот порт, а остальные порты того же ресурса продолжают работать. Если один порт проверяют несколько проб, для приёма трафика должны пройти все.

Модуль не зависит от реализации CNI: компоненты controller и agent управляют только стандартными ресурсами Service и EndpointSlice, поэтому трафик по-прежнему маршрутизируется штатным kube-proxy или CNI-плагином кластера — так же, как для обычного Service.

Подробнее с настройками модуля и примерами его использования можно ознакомиться в соответствующем разделе документации.

Архитектура модуля

Для упрощения схемы приняты следующие допущения:

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

Архитектура модуля service-with-healthchecks на уровне 2 модели C4 и его взаимодействие с другими компонентами DP изображены на следующей диаграмме:

Архитектура модуля service-with-healthchecks

Компоненты модуля

Модуль состоит из следующих компонентов:

  1. Controller (Deployment) — контроллер, управляющий кастомным ресурсом ServiceWithHealthchecks и выполняющий следующие операции:

    • создаёт и поддерживает ресурс Service с пустым selector для каждого кастомного ресурса ServiceWithHealthchecks. Балансировка нагрузки полностью определяется ресурсами EndpointSlice, которые создаются компонентом agent для соответствующих ресурсов Service;

    • удаляет ресурсы EndpointSlice, оставшиеся от узлов кластера, которых больше не существует.

    Состоит из следующих контейнеров:

    • controller — основной контейнер;
    • kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для организации защищённого доступа к метрикам контроллера.

  2. Agent (DaemonSet) — компонент, запускающийся на каждом узле кластера и выполняющий активные проверки работоспособности (TCP, HTTP или PostgreSQL) подов, запланированных на его узел, в соответствии со спецификацией соответствующего кастомного ресурса ServiceWithHealthchecks. По результатам проверок agent создаёт и обновляет ресурсы EndpointSlice, привязанные к ресурсу Service. Также компонент следит за ресурсами Secret с типом network.deckhouse.io/postgresql-credentials, используемыми для аутентификации проверок PostgreSQL.

    Состоит из следующих контейнеров:

    • agent — основной контейнер;
    • kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для организации защищённого доступа к метрикам компонента.

Взаимодействия модуля

Модуль взаимодействует со следующими компонентами:

  1. Kube-apiserver:

    • следит и обновляет статус кастомных ресурсов ServiceWithHealthchecks;
    • следит за ресурсами Pod своего узла и ресурсами Secret с типом network.deckhouse.io/postgresql-credentials;
    • управляет ресурсами Service, EndpointSlice и Lease;
    • авторизует запросы на получение метрик.

  2. Пользовательские сервисы, развёрнутые в DP — отправляет активные проверки работоспособности (TCP, HTTP или PostgreSQL) на порты подов своего узла, указанные в ресурсе ServiceWithHealthchecks.

С модулем взаимодействуют следующие внешние компоненты:

  1. Prometheus-main — собирает метрики компонентов agent и controller.

Дополнительные ресурсы