Yandex Cloud
Поиск
Связаться с экспертомПопробовать бесплатно
  • Кейсы
  • Документация
  • Блог
  • Все сервисы
    • Cloud Interconnect
    • Cloud Backup
    • Compute Cloud
    • Object Storage
    • Managed Service for Kubernetes®
    • Managed Service for PostgreSQL
    • Managed Service for ClickHouse®
    • Monium
    • Cloud CDN
    • Network Load Balancer
    • Virtual Private Cloud
    • Cloud DNS
    • Application Load Balancer
    • Yandex Cloud Router
    • Managed Service for MySQL®
    • Managed Service for Valkey™
    • Managed Service for Apache Spark™
    • Managed Service for OpenSearch
    • Managed Service for Apache Kafka®
    • Data Transfer
    • Yandex MPP Analytics Engine for PostgreSQL
    • Managed Service for YDB
    • SpeechKit
    • Yandex Identity Hub
    • Key Management Service
    • Certificate Manager
    • Yandex Lockbox
    • Audit Trails
    • Container Registry
    • Managed Service for Prometheus®
    • Message Queue
    • Identity and Access Management
    • Yandex Cloud Console
    • Resource Manager
    • Yandex Cloud Billing
    • Cloud Apps
    • Yandex AI Studio
    • Yandex BareMetal
    • Smart Web Security
    • Security Deck
    • Yandex Cloud Video
    • Stackland
    • Yandex StoreDoc
    • Yandex Managed Service for Apache Airflow®
    • Data Processing
    • Yandex MetaData Hub
    • Yandex WebSQL
    • DataLens
    • Yandex Search API
    • SpeechSense
    • DataSphere
    • Vision OCR
    • Translate
    • Cloud Registry
    • SmartCaptcha
    • Cloud Desktop
    • SourceCraft Code Assistant
    • Managed Service for GitLab
    • Cloud Functions
    • API Gateway
    • Yandex Cloud Postbox
    • Serverless Integrations
    • IoT Core
    • Serverless Containers
    • Cloud Notification Service
    • Yandex Query
  • Статус работы сервисов
  • Marketplace
    • Доступны в регионе
    • Инфраструктура и сеть
    • Платформа данных
    • Искусственный интеллект
    • Безопасность
    • Инструменты DevOps
    • Бессерверные вычисления
    • Управление ресурсами
  • Все решения
    • По отраслям
    • По типу задач
    • Экономика платформы
    • Безопасность
    • Техническая поддержка
    • Каталог партнёров
    • Обучение и сертификация
    • Облако для стартапов
    • Облако для крупного бизнеса
    • Центр технологий для общества
    • Партнёрская программа
    • Поддержка IT-бизнеса
    • Облако для фрилансеров
    • Обучение и сертификация
    • Блог
    • Документация
    • Мероприятия и вебинары
    • Контакты, чаты и сообщества
    • Идеи
    • Калькулятор цен
    • Тарифы
    • Акции и free tier
  • Кейсы
  • Документация
  • Блог
Создавайте контент и получайте гранты!Готовы написать своё руководство? Участвуйте в контент-программе и получайте гранты на работу с облачными сервисами!
Подробнее о программе
Проект Яндекса
© 2026 ТОО «Облачные Сервисы Казахстан»
Yandex Application Load Balancer
KZ
  • Начало работы
    • Обзор
      • Обзор
      • Принципы работы
      • Установить Ingress-контроллер
      • Обновить Ingress-контроллер
        • Ingress
        • HttpBackendGroup
        • GrpcBackendGroup
        • IngressClass
        • Service для Ingress
    • Настройка групп безопасности
    • Работа с сервисными аккаунтами
    • Создание и изменение ресурсов по конфигурации
  • Управление доступом
  • Правила тарификации
  • Справочник Terraform
  • Метрики Monitoring
  • Аудитные логи Audit Trails
  • Логи L7-балансировщика
  • История изменений
  • Обучающие курсы
  1. Инструменты для Managed Service for Kubernetes
  2. Ingress-контроллер
  3. Конфигурация ресурсов
  4. HttpBackendGroup

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

Статья создана
Yandex Cloud
Обновлена 24 июня 2026 г.
Открыть в Markdown

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

Совет

Вместо ALB Ingress-контроллера и Gateway API рекомендуется использовать новый контроллер Yandex Cloud Gwin.

Указание на 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>
      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
Создавайте контент и получайте гранты!Готовы написать своё руководство? Участвуйте в контент-программе и получайте гранты на работу с облачными сервисами!
Подробнее о программе
Проект Яндекса
© 2026 ТОО «Облачные Сервисы Казахстан»