Yandex Cloud
Поиск
Связаться с намиПодключиться
  • Документация
  • Блог
  • Все сервисы
  • Статус работы сервисов
    • Популярные
    • Инфраструктура и сеть
    • Платформа данных
    • Контейнеры
    • Инструменты разработчика
    • Бессерверные вычисления
    • Безопасность
    • Мониторинг и управление ресурсами
    • Машинное обучение
    • Бизнес-инструменты
  • Все решения
    • По отраслям
    • По типу задач
    • Экономика платформы
    • Безопасность
    • Техническая поддержка
    • Каталог партнёров
    • Обучение и сертификация
    • Облако для стартапов
    • Облако для крупного бизнеса
    • Центр технологий для общества
    • Облако для интеграторов
    • Поддержка IT-бизнеса
    • Облако для фрилансеров
    • Обучение и сертификация
    • Блог
    • Документация
    • Контент-программа
    • Мероприятия и вебинары
    • Контакты, чаты и сообщества
    • Идеи
    • Истории успеха
    • Тарифы Yandex Cloud
    • Промоакции и free tier
    • Правила тарификации
  • Документация
  • Блог
Проект Яндекса
© 2025 ООО «Яндекс.Облако»
Yandex Managed Service for Kubernetes
  • Сопоставление с другими сервисами Yandex Cloud
  • Начало работы
  • Управление доступом
  • Правила тарификации
  • Справочник Terraform
  • Метрики Monitoring
  • Аудитные логи Audit Trails
    • Обзор
      • Ingress
      • HttpBackendGroup
      • GrpcBackendGroup
      • IngressClass
      • Service для Ingress
  • История изменений
  • Обучающие курсы
  1. Инструменты Application Load Balancer
  2. Ingress-контроллер
  3. HttpBackendGroup

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

Статья создана
Yandex Cloud
Обновлена 24 февраля 2025 г.

Ресурс 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-контроллером.

HttpBackendGroup

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>
      loadBalancingConfig:
        balancerMode: <string>
        panicThreshold: <int64>
        localityAwareRouting: <int64>
    - ...

Где:

  • 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.

      • loadBalancingConfig (LoadBalancingConfig)

        Настройки балансировки.

        • balancerMode (string)

          Режим распределения трафика между эндпоинтами бэкенда. Возможные значения — ROUND_ROBIN, RANDOM, LEAST_REQUEST, MAGLEV_HASH. Подробнее о каждом режиме.

        • panicThreshold (int64)

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

          Значение по умолчанию — 0, при котором режим паники не активируется никогда.

        • localityAwareRouting (int64)

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

          Значение по умолчанию — 0.

Была ли статья полезна?

Предыдущая
Ingress
Следующая
GrpcBackendGroup
Проект Яндекса
© 2025 ООО «Яндекс.Облако»