Поля ресурса HttpBackendGroup

Ресурс HttpBackendGroup позволяет объединять бэкенды — сервисы Kubernetes, между которыми распределяется трафик, — в группу. По таким ресурсам Ingress-контроллер Application Load Balancer создает группы бэкендов.

Указание на HttpBackendGroup нужно добавить в ресурс Ingress.

При использовании HttpBackendGroup доступна расширенная функциональность Application Load Balancer. Бэкендами в такой группе могут быть сервисы Kubernetes и бакеты Yandex Object Storage. Также в HttpBackendGroup можно указывать относительные веса бэкендов для пропорционального распределения трафика между ними.

HttpBackendGroup — custom resource из группы API alb.yc.io, предоставляемой Ingress-контроллером.

HttpBackendGroupHttpBackendGroup

apiVersion: alb.yc.io/v1alpha1
kind: HttpBackendGroup
metadata:
  name: <string>
spec:
  backends:
    - name: <string>
      weight: <int64>
      useHttp2: <bool>
      service:
         name: <int64>
         port:
           name: <string>
           number: <int32>
      storageBucket:
        name: <string>
      tls:
        sni: <string>
        trustedCa: <string>
      healthChecks:
        - http:
            path: <string>
          port: <int32>
          healthyThreshold: <int32>
          unhealthyThreshold: <int32>
          timeout: <string>
          interval: <string>
    - ...

Где:

• apiVersion: alb.yc.io/v1alpha1

• kind: HttpBackendGroup

• metadata (ObjectMeta, обязательное)

  Метаданные ресурса.

  • name (string, обязательное)

    Имя ресурса. Подробнее о формате см. в документации Kubernetes.

    Это имя нужно указать в поле spec.rules.http.paths.backend.resource.name ресурса Ingress (см. конфигурацию).

    Не является именем группы бэкендов в Application Load Balancer.

• spec (HttpBackendGroupSpec)

  Спецификация ресурса.

  • backends ([]HttpBackend)

    Список бэкендов, входящих в группу.

    • name (string, обязательное)

      Имя бэкенда.

    • weight (int64)

      Относительный вес бэкенда. Трафик между бэкендами в группе распределяется пропорционально их весам.

      Веса должны быть указаны либо у всех бэкендов в группе, либо ни у одного из них. Между бэкендами без указанных весов трафик распределяется, как если бы у них были указаны одинаковые положительные веса.

      Если указан неположительный вес, бэкенд не будет получать трафик.

    • useHttp2 (bool)

      Разрешает устанавливать HTTP/2-соединения между узлами балансировщика и эндпоинтами бэкенда.

      Значение по умолчанию — false: устанавливаются HTTP/1.1-соединения.

    • service (ServiceBackend)

      Указание на сервис Kubernetes, который должен обрабатывать запросы в качестве бэкенда.

      Ресурс Service, на который указывает это поле, должен быть описан по принятой конфигурации.

      Для бэкенда должен быть указан либо сервис, либо бакет Object Storage (storageBucket), но не оба одновременно.

      • name (string, обязательное)

        Имя сервиса Kubernetes.

      • port (ServiceBackendPort, обязательное)

        Порт сервиса, к которому будет обращаться Ingress.

        Поле предназначено для работы Ingress-контроллера и не соответствует ни одному из полей ресурсов Application Load Balancer.

        • name (string)

          Имя порта сервиса.

          Имя должно совпадать с одним из имен портов, указанных в полях spec.ports.name ресурса Service. Подробнее см. в спецификации ресурса.

          Для порта сервиса должно быть указано либо имя, либо номер (number), но не оба одновременно.

        • number (int32)

          Номер порта сервиса.

          Номер должен совпадать с одним из номеров портов, указанных в полях spec.ports.port ресурса Service. Подробнее см. в спецификации ресурса.

          Для порта сервиса должен быть указан либо номер, либо имя (name), но не оба одновременно.

    • storageBucket (StorageBucketBackend)

      Указание на бакет Yandex Object Storage, который должен обрабатывать запросы в качестве бэкенда. Подробнее об использовании бакета как бэкенда см. в разделе Типы бэкендов.

      Важно

      Чтобы бакет можно было использовать в качестве бэкенда, откройте публичный доступ к списку объектов в бакете и к их чтению.

      Для бэкенда должен быть указан либо бакет, либо сервис Kubernetes (service), но не оба одновременно.

      • name (string, обязательное)

        Имя бакета.

    • tls (BackendTLS)

      Настройки TLS-соединений между узлами балансировщика и эндпоинтами бэкенда.

      Если поле указано, балансировщик устанавливает с бэкендом TLS-соединения и сравнивает полученные сертификаты с сертификатом, указанным в поле trustedCa. Если поле не указано, балансировщик устанавливает с бэкендом незащищенные соединения.

      • sni (string)

        Доменное имя, указываемое как значение TLS-расширения Server Name Indication (SNI).

      • trustedCa (string)

        Содержимое X.509-сертификата, выпущенного центром сертификации, в формате PEM.

    • healthChecks ([]HealthChecks)

      Настройки пользовательских проверок состояния приложений в кластере Managed Service for Kubernetes.

      По умолчанию Ingress-контроллер Application Load Balancer принимает от L7-балансировщика проверочные запросы на TCP-порт 10501 и проверяет работоспособность подов kube-proxy на каждом узле кластера. Суть проверки состояния заключается в том, что когда kube-proxy работоспособен, то даже если приложение в конкретном поде не отвечает, Kubernetes перенаправит трафик в другой под с этим приложением или на другой узел.

      С помощью параметров healthChecks вы можете настроить собственные проверки состояния приложений.

      • http (HttpBackend)

        Протокол, по которому будет осуществляться проверка — HTTP.

        • path (string)

          Путь в URI запроса к эндпоинту приложения для проверок состояния, например /health.

      • port (int32)

        Порт на узлах кластера для проверки доступности приложения. Значение совпадает с портом, указанным в ресурсе Service типа NodePort, в параметре spec.ports.nodePort.

        Приложение будет доступно для проверок состояния по адресу http://<IP-адрес_узла>:<порт>/<путь>.

      • healthyThreshold (int32)

        Количество последовательных успешных проверок, после которых эндпоинт приложения считается работоспособным.

      • unhealthyThreshold (int32)

        Количество последовательных неуспешных проверок, после которых эндпоинт приложения считается неработоспособным.

      • timeout (string)

        Время ожидания ответа в секундах. Возможные значения — от 1s до 60s.

      • interval (string)

        Интервал отправки проверочных запросов в секундах.

        Возможные значения — от 1s до 60s. Значение interval должно быть больше значения timeout минимум на одну секунду.

      Примечание

      Настроить проверки состояния приложения также можно с помощью аннотации ingress.alb.yc.io/health-checks ресурса Service.