Yandex Cloud
Поиск
Связаться с намиПодключиться
  • Документация
  • Блог
  • Все сервисы
  • Статус работы сервисов
    • Популярные
    • Инфраструктура и сеть
    • Платформа данных
    • Контейнеры
    • Инструменты разработчика
    • Бессерверные вычисления
    • Безопасность
    • Мониторинг и управление ресурсами
    • Машинное обучение
    • Бизнес-инструменты
  • Все решения
    • По отраслям
    • По типу задач
    • Экономика платформы
    • Безопасность
    • Техническая поддержка
    • Каталог партнёров
    • Обучение и сертификация
    • Облако для стартапов
    • Облако для крупного бизнеса
    • Центр технологий для общества
    • Облако для интеграторов
    • Поддержка IT-бизнеса
    • Облако для фрилансеров
    • Обучение и сертификация
    • Блог
    • Документация
    • Контент-программа
    • Мероприятия и вебинары
    • Контакты, чаты и сообщества
    • Идеи
    • Истории успеха
    • Тарифы Yandex Cloud
    • Промоакции и free tier
    • Правила тарификации
  • Документация
  • Блог
Проект Яндекса
© 2025 ООО «Яндекс.Облако»
Yandex Managed Service for Kubernetes
  • Сопоставление с другими сервисами Yandex Cloud
  • Начало работы
    • Все руководства
    • Создание нового Kubernetes-проекта в Yandex Cloud
    • Создание кластера Kubernetes без доступа в интернет
    • Запуск рабочих нагрузок с GPU
    • Использование групп узлов c GPU без предустановленных драйверов
    • Установка Time-Slicing GPUs
    • Миграция ресурсов в другую зону доступности
    • Использование модулей Yandex Cloud в Terraform
    • Шифрование секретов в Managed Service for Kubernetes
      • Интеграция с Argo CD
      • Интеграция с Crossplane
      • Синхронизация с секретами Yandex Lockbox
      • Настройка Fluent Bit для работы с Cloud Logging
      • Настройка Gateway API
      • Настройка L7-балансировщика Application Load Balancer с помощью Ingress-контроллера
      • Настройка логирования для L7-балансировщика Application Load Balancer с помощью Ingress-контроллера
      • Создание L7-балансировщика с профилем безопасности Smart Web Security через Ingress-контроллер Application Load Balancer
      • Проверка состояния приложений в кластере Managed Service for Kubernetes с помощью L7-балансировщика Application Load Balancer
      • Использование Jaeger для трассировки запросов в Managed Service for YDB
      • Настройка Kyverno & Kyverno Policies
      • Использование Metrics Provider для трансляции метрик
      • Редактирование изображений для сайтов с помощью Thumbor
      • Использование Istio
      • Использование HashiCorp Vault для хранения секретов
  • Управление доступом
  • Правила тарификации
  • Справочник Terraform
  • Метрики Monitoring
  • Аудитные логи Audit Trails
  • История изменений
  • Обучающие курсы

В этой статье:

  • Необходимые платные ресурсы
  • Перед началом работы
  • Настройте ресурс Ingress и тестовые приложения
  • (Опционально) Настройте группу ресурсов Ingress
  • Убедитесь в доступности приложений через L7-балансировщик
  • Удалите созданные ресурсы
  1. Практические руководства
  2. Использование продуктов Cloud Marketplace
  3. Настройка L7-балансировщика Application Load Balancer с помощью Ingress-контроллера

Настройка L7-балансировщика Yandex Application Load Balancer с помощью Ingress-контроллера

Статья создана
Yandex Cloud
Обновлена 28 апреля 2025 г.
  • Необходимые платные ресурсы
  • Перед началом работы
  • Настройте ресурс Ingress и тестовые приложения
  • (Опционально) Настройте группу ресурсов Ingress
  • Убедитесь в доступности приложений через L7-балансировщик
  • Удалите созданные ресурсы

Сервис Yandex Application Load Balancer используется для балансировки нагрузки и распределения трафика между приложениями. Чтобы с его помощью управлять трафиком к приложениям, запущенным в кластере Managed Service for Kubernetes, необходим Ingress-контроллер.

Чтобы настроить доступ к запущенным в кластере Managed Service for Kubernetes приложениям через L7-балансировщик Application Load Balancer:

  1. Настройте тестовые приложения и ресурс Ingress.
  2. (Опционально) Настройте группу ресурсов Ingress.
  3. Убедитесь в доступности приложений кластера Managed Service for Kubernetes через Application Load Balancer.

Полную конфигурацию ресурсов для Ingress-контроллера Application Load Balancer см. в следующих разделах:

  • Ingress — правила распределения трафика между бэкендами и настройки балансировщика.
  • HttpBackendGroup, GrpcBackendGroup — объединение бэкендов в группы.
  • IngressClass — управление несколькими Ingress-контроллерами в кластере Kubernetes.
  • Service — описание сервисов Kubernetes, используемых в качестве бэкендов.

Необходимые платные ресурсыНеобходимые платные ресурсы

В стоимость поддержки описываемого решения входят:

  • Плата за DNS-зону и DNS-запросы (см. тарифы Cloud DNS).
  • Плата за кластер Managed Service for Kubernetes: использование мастера и исходящий трафик (см. тарифы Managed Service for Kubernetes).
  • Плата за узлы кластера (ВМ): использование вычислительных ресурсов, операционной системы и хранилища (см. тарифы Compute Cloud).
  • Плата за использование вычислительных ресурсов L7-балансировщика (см. тарифы Application Load Balancer).
  • Плата за публичные IP-адреса для узлов кластера и L7-балансировщика (см. тарифы Virtual Private Cloud).
  • Плата за бакет Object Storage: хранение данных и выполнение операций с ними (см. тарифы Object Storage).

Перед началом работыПеред началом работы

  1. Зарегистрируйте публичную доменную зону и делегируйте домен.

  2. Если у вас уже есть сертификат для доменной зоны, добавьте сведения о нем в сервис Yandex Certificate Manager. Или добавьте новый сертификат от Let's Encrypt®.

  3. Получите идентификатор добавленного сертификата:

    yc certificate-manager certificate list
    

    Результат выполнения команды:

    +----------------------+-----------+----------------+---------------------+----------+--------+
    |          ID          |   NAME    |    DOMAINS     |      NOT AFTER      |   TYPE   | STATUS |
    +----------------------+-----------+----------------+---------------------+----------+--------+
    | fpq8diorouhp******** | sert-test |    test.ru     | 2022-01-06 17:19:37 | IMPORTED | ISSUED |
    +----------------------+-----------+----------------+---------------------+----------+--------+
    
  4. Создайте группы безопасности для кластера Managed Service for Kubernetes и входящих в него групп узлов.

    Также настройте группы безопасности, необходимые для работы Application Load Balancer.

    Важно

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

  5. Создайте кластер Managed Service for Kubernetes. При создании укажите группы безопасности, подготовленные ранее.

    Если вы планируете работать с кластером в пределах сети Yandex Cloud, выделять кластеру публичный IP-адрес не нужно. Для подключений извне предоставьте кластеру публичный адрес.

  6. Создайте группу узлов. Выделите ей публичный адрес, чтобы предоставить доступ в интернет и возможность скачивать Docker-образы и компоненты. Укажите группы безопасности, подготовленные ранее.

  7. Установите Ingress-контроллер Application Load Balancer.

  8. (Опционально) Установите ExternalDNS c плагином для Yandex Cloud DNS, чтобы автоматически создать DNS-запись в Yandex Cloud DNS при создании Ingress-контроллера.

  9. Установите kubectl и настройте его на работу с созданным кластером.

    Если для кластера не предоставлен публичный адрес и kubectl настроен через внутренний адрес кластера, выполняйте команды kubectl на ВМ Yandex Cloud, находящейся в одной сети с кластером.

Настройте ресурс Ingress и тестовые приложенияНастройте ресурс Ingress и тестовые приложения

В ресурсе Ingress определяются:

  • Параметры L7-балансировщика, которые задаются с помощью аннотаций.

  • Правила распределения входящего трафика между сервисами Kubernetes.

    Сервисы, выступающие в роли бэкендов Application Load Balancer, могут быть указаны в ресурсе Ingress напрямую или в составе групп бэкендов HttpBackendGroup/GrpcBackendGroup.

Создайте тестовые приложения и ресурс Ingress:

Ресурс Ingress для сервисов Kubernetes
Ресурс Ingress для группы бэкендов
  1. В отдельной директории создайте конфигурационные файлы приложений demo-app-1.yaml и demo-app-2.yaml:

    demo-app-1.yaml
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: alb-demo-1
    data:
      nginx.conf: |
        worker_processes auto;
        events {
        }
        http {
          server {
            listen 80 ;
            location = /_healthz {
              add_header Content-Type text/plain;
              return 200 'ok';
            }
            location / {
              add_header Content-Type text/plain;
              return 200 'Index';
            }
            location = /app1 {
              add_header Content-Type text/plain;
              return 200 'This is APP#1';
            }
          }
        }
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: alb-demo-1
      labels:
        app: alb-demo-1
        version: v1
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: alb-demo-1
      strategy:
        type: RollingUpdate
        rollingUpdate:
          maxSurge: 1
          maxUnavailable: 0
      template:
        metadata:
          labels:
            app: alb-demo-1
            version: v1
        spec:
          terminationGracePeriodSeconds: 5
          volumes:
            - name: alb-demo-1
              configMap:
                name: alb-demo-1
          containers:
            - name: alb-demo-1
              image: nginx:latest
              ports:
                - name: http
                  containerPort: 80
              livenessProbe:
                httpGet:
                  path: /_healthz
                  port: 80
                initialDelaySeconds: 3
                timeoutSeconds: 2
                failureThreshold: 2
              volumeMounts:
                - name: alb-demo-1
                  mountPath: /etc/nginx
                  readOnly: true
              resources:
                limits:
                  cpu: 250m
                  memory: 128Mi
                requests:
                  cpu: 100m
                  memory: 64Mi
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: alb-demo-1
    spec:
      selector:
        app: alb-demo-1
      type: NodePort
      ports:
        - name: http
          port: 80
          targetPort: 80
          protocol: TCP
          nodePort: 30081
    
    demo-app-2.yaml
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: alb-demo-2
    data:
      nginx.conf: |
        worker_processes auto;
        events {
        }
        http {
          server {
            listen 80 ;
            location = /_healthz {
              add_header Content-Type text/plain;
              return 200 'ok';
            }
            location / {
              add_header Content-Type text/plain;
              return 200 'Add app#';
            }
            location = /app2 {
              add_header Content-Type text/plain;
              return 200 'This is APP#2';
            }
          }
        }
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: alb-demo-2
      labels:
        app: alb-demo-2
        version: v1
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: alb-demo-2
      strategy:
        type: RollingUpdate
        rollingUpdate:
          maxSurge: 1
          maxUnavailable: 0
      template:
        metadata:
          labels:
            app: alb-demo-2
            version: v1
        spec:
          terminationGracePeriodSeconds: 5
          volumes:
            - name: alb-demo-2
              configMap:
                name: alb-demo-2
          containers:
            - name: alb-demo-2
              image: nginx:latest
              ports:
                - name: http
                  containerPort: 80
              livenessProbe:
                httpGet:
                  path: /_healthz
                  port: 80
                initialDelaySeconds: 3
                timeoutSeconds: 2
                failureThreshold: 2
              volumeMounts:
                - name: alb-demo-2
                  mountPath: /etc/nginx
                  readOnly: true
              resources:
                limits:
                  cpu: 250m
                  memory: 128Mi
                requests:
                  cpu: 100m
                  memory: 64Mi
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: alb-demo-2
    spec:
      selector:
        app: alb-demo-2
      type: NodePort
      ports:
        - name: http
          port: 80
          targetPort: 80
          protocol: TCP
          nodePort: 30082
    
  2. В той же директории создайте файл ingress.yaml и укажите в нем делегированное ранее доменное имя, идентификатор полученного ранее сертификата и настройки L7-балансировщика Application Load Balancer:

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: alb-demo-tls
      annotations:
        ingress.alb.yc.io/subnets: <список_идентификаторов_подсетей>
        ingress.alb.yc.io/security-groups: <список_идентификаторов_групп_безопасности>
        ingress.alb.yc.io/external-ipv4-address: <способ_назначения_IP-адреса>
        ingress.alb.yc.io/group-name: my-ingress-group
    spec:
      tls:
        - hosts:
            - <доменное_имя>
          secretName: yc-certmgr-cert-id-<идентификатор_TLS-сертификата>
      rules:
        - host: <доменное_имя>
          http:
            paths:
              - path: /app1
                pathType: Prefix
                backend:
                  service:
                    name: alb-demo-1
                    port:
                      number: 80
              - path: /app2
                pathType: Prefix
                backend:
                  service:
                    name: alb-demo-2
                    port:
                      number: 80
              - pathType: Prefix
                path: "/"
                backend:
                  service:
                    name: alb-demo-2
                    port:
                      name: http
    

    Где:

    • ingress.alb.yc.io/subnets — одна или несколько подсетей, в которых будет расположен L7-балансировщик Application Load Balancer.

    • ingress.alb.yc.io/security-groups — одна или несколько групп безопасности для балансировщика. Если параметр не задан, используется группа безопасности по умолчанию. Хотя бы одна из групп безопасности должна разрешать исходящее TCP-соединение к порту 10501 в подсети группы узлов Managed Service for Kubernetes или в ее группу безопасности.

    • ingress.alb.yc.io/external-ipv4-address — предоставление публичного доступа к балансировщику из интернета. Укажите заранее полученный IP-адрес либо установите значение auto, чтобы получить новый.

      Если вы указали значение auto, то при удалении балансировщика из облака также будет удален его IP-адрес. Чтобы избежать этого, используйте имеющийся зарезервированный адрес.

    • ingress.alb.yc.io/group-name — имя группы. Ресурсы Ingress объединяются в группы, каждая из которых обслуживается отдельным балансировщиком.

      Вместо my-ingress-group вы можете указать произвольное имя группы. Убедитесь, что оно соответствует требованиям.

    В версиях ALB Ingress Controller до 0.2.0 каждая группа бэкендов соответствует связке параметров host, http.paths.path и http.paths.pathType. В версиях 0.2.0 и позднее группа бэкендов соответствует параметру backend.service. Из-за этого при обновлении ALB Ingress Controller могут возникнуть коллизии. Чтобы избежать их, узнайте, применимы ли ограничения при обновлении к вашей инфраструктуре.

    (Опционально) Укажите дополнительные настройки балансировщика:

    Дополнительные настройки

    Примечание

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

    К виртуальным хостам остальных ресурсов Ingress в группе эти настройки применены не будут.

    Доступные настройки:

    • ingress.alb.yc.io/group-settings-name — имя для настроек группы ресурсов Ingress, которые должны быть описаны в дополнительном ресурсе IngressGroupSettings. Подробнее см. в разделе Настройте группу ресурсов Ingress.

    • ingress.alb.yc.io/internal-ipv4-address — предоставление внутреннего доступа к балансировщику. Укажите внутренний IP-адрес, либо установите значение auto, чтобы получить IP-адрес автоматически.

      Примечание

      Вы можете одновременно использовать только один тип доступа к балансировщику: ingress.alb.yc.io/external-ipv4-address или ingress.alb.yc.io/internal-ipv4-address.

    • ingress.alb.yc.io/internal-alb-subnet — подсеть, в которой нужно разместить балансировщик. Обязательный параметр, если выбран параметр ingress.alb.yc.io/internal-ipv4-address.

    • ingress.alb.yc.io/protocol — протокол соединений между балансировщиком и бэкендами:

      • http — HTTP/1.1. Значение по умолчанию.
      • http2 — HTTP/2.
      • grpc — gRPC.
    • ingress.alb.yc.io/transport-security — протокол шифрования соединений между балансировщиком и бэкендами.

      Важно

      В ALB Ingress Controller версии 0.2.0 и позднее аннотация используется только в объекте Service.

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

      Допустимое значение: tls — TLS без проверки сертификата.

      Если аннотация не указана, балансировщик соединяется с бэкендами без шифрования.

    • ingress.alb.yc.io/prefix-rewrite — замена пути на указанное значение.

    • ingress.alb.yc.io/upgrade-types — допустимые значения HTTP-заголовка Upgrade, например, websocket.

    • ingress.alb.yc.io/request-timeout — максимальный период, на который может быть установлено соединение.

    • ingress.alb.yc.io/idle-timeout — максимальный период, в течение которого соединение может простаивать без передачи данных.

      Значения для request-timeout и idle-timeout следует указывать с единицами измерения, например: 300ms, 1.5h. Допустимые единицы измерения:

      • ns — наносекунды.
      • us — микросекунды.
      • ms — миллисекунды.
      • s — секунды.
      • m — минуты.
      • h — часы.
    • ingress.alb.yc.io/security-profile-id — поддержка сервиса Yandex Smart Web Security, который позволяет защититься от DDoS-атак и ботов, а также задействовать WAF и ограничить нагрузку на защищаемый ресурс.

      Чтобы включить поддержку сервиса, в аннотации Ingress укажите заранее созданный профиль безопасности Smart Web Security:

      ingress.alb.yc.io/security-profile-id: <идентификатор_профиля_безопасности>
      

      Примечание

      Для подключения профиля безопасности к виртуальному хосту Application Load Balancer у сервисного аккаунта, от имени которого работает Ingress-контроллер, должна быть роль smart-web-security.editor на каталог, в котором размещены ресурсы Application Load Balancer и Smart Web Security. Подробнее см. Назначение роли сервисному аккаунту.

    • ingress.alb.yc.io/use-regex — поддержка регулярных выражений стандарта RE2 при сопоставлении пути запроса. Если передана строка true, поддержка включена. Применимо, только если для параметра pathType указано значение Exact.

    • ingress.alb.yc.io/balancing-panic-threshold — пороговое значения для активации режима паники. Режим включится, если процент работоспособных эндпоинтов опустится ниже указанного значения. Значение по умолчанию — 0, при котором режим паники не активируется никогда.

    • ingress.alb.yc.io/balancing-locality-aware-routing — процент входящего трафика, который балансировщик передает бэкендам из своей зоны доступности. Остальной трафик поровну делится между другими зонами. Значение по умолчанию — 0. Подробнее о локализации трафика.

    • ingress.alb.yc.io/autoscale-max-size — максимальное суммарное количество ресурсных единиц. По умолчанию количество не ограничено. Значение должно быть не меньше, чем количество зон доступности балансировщика, умноженное на минимальное количество ресурсных единиц в каждой зоне. Подробнее о настройках автомасштабирования.

    • ingress.alb.yc.io/modify-header-response-append — добавляет строку к значению заголовка ответа. Заголовок и строка указываются в формате:

      ingress.alb.yc.io/modify-header-response-append: <имя_изменяемого_заголовка>=<строка>
      
    • ingress.alb.yc.io/modify-header-response-replace — заменяет значение заголовка ответа. Заголовок и его новое значение указываются в формате:

      ingress.alb.yc.io/modify-header-response-replace: <имя_изменяемого_заголовка>=<новое_значение_заголовка>
      
    • ingress.alb.yc.io/modify-header-response-rename — переименовывает заголовок ответа. Заголовок и его новое имя указываются в формате:

      ingress.alb.yc.io/modify-header-response-rename: <имя_изменяемого_заголовка>=<новое_имя_заголовка>
      
    • ingress.alb.yc.io/modify-header-response-remove — удаляет заголовок ответа. Заголовок для удаления указывается в формате:

      ingress.alb.yc.io/modify-header-response-remove: <имя_удаляемого_заголовка>=true
      
      
    • ingress.alb.yc.io/modify-header-request-append — добавляет строку к значению заголовка запроса. Заголовок и строка указываются в формате:

      ingress.alb.yc.io/modify-header-request-append: <имя_изменяемого_заголовка>=<строка>
      
    • ingress.alb.yc.io/modify-header-request-replace — заменяет значение заголовка запроса. Заголовок и его новое значение указываются в формате:

      ingress.alb.yc.io/modify-header-request-replace: <имя_изменяемого_заголовка>=<новое_значение_заголовка>
      
    • ingress.alb.yc.io/modify-header-request-rename — переименовывает заголовок запроса. Заголовок и его новое имя указываются в формате:

      ingress.alb.yc.io/modify-header-request-rename: <имя_изменяемого_заголовка>=<новое_имя_заголовка>
      
    • ingress.alb.yc.io/modify-header-request-remove — удаляет заголовок запроса. Заголовок для удаления указывается в формате:

      ingress.alb.yc.io/modify-header-request-remove: <имя_удаляемого_заголовка>=true
      

    Если вы используете несколько Ingress-контроллеров, для каждого из них создайте ресурс IngressClass. В конфигурации Ingress укажите нужный IngressClass в поле spec.ingressClassName.

    Подробное описание настроек ресурса Ingress см. в статье Поля и аннотации ресурса Ingress.

  3. Создайте приложения Kubernetes и ресурс Ingress:

    kubectl apply -f .
    

    ALB Ingress Controller автоматически развернет L7-балансировщик по конфигурации ресурса Ingress.

  4. Дождитесь создания L7-балансировщика Application Load Balancer и получения им публичного IP-адреса, это может занять несколько минут.

    Чтобы отслеживать создание балансировщика и убедиться в отсутствии ошибок, откройте логи пода, в котором запущен процесс создания:

    1. В консоли управления перейдите на страницу каталога и выберите сервис Managed Service for Kubernetes.

    2. Нажмите на имя нужного кластера и на панели слева выберите Рабочая нагрузка.

    3. Выберите один из подов alb-demo-***, в котором запущен процесс создания балансировщика.

    4. На странице пода перейдите на вкладку Логи.

      В режиме реального времени записываются и отображаются логи о создании балансировщика. Если возникла ошибка во время создания, она появится в логах.

  5. Убедитесь, что балансировщик создан. Для этого выполните команду и проверьте, что в поле ADDRESS в выводе команды появилось значение:

    kubectl get ingress alb-demo-tls
    

    Результат:

    NAME          CLASS   HOSTS           ADDRESS     PORTS    AGE
    alb-demo-tls  <none>  <доменное_имя>  <IP-адрес>  80, 443  15h
    
  1. Создайте группу бэкендов с бакетом:

    1. Создайте публичный бакет в Object Storage.
    2. Настройте главную страницу сайта и страницу ошибки.
  2. Создайте конфигурационный файл приложения demo-app-1.yaml:

    demo-app-1.yaml
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: alb-demo-1
    data:
      nginx.conf: |
        worker_processes auto;
        events {
        }
        http {
          server {
            listen 80 ;
            location = /_healthz {
              add_header Content-Type text/plain;
              return 200 'ok';
            }
            location / {
              add_header Content-Type text/plain;
              return 200 'Index';
            }
            location = /app1 {
              add_header Content-Type text/plain;
              return 200 'This is APP#1';
            }
          }
        }
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: alb-demo-1
      labels:
        app: alb-demo-1
        version: v1
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: alb-demo-1
      strategy:
        type: RollingUpdate
        rollingUpdate:
          maxSurge: 1
          maxUnavailable: 0
      template:
        metadata:
          labels:
            app: alb-demo-1
            version: v1
        spec:
          terminationGracePeriodSeconds: 5
          volumes:
            - name: alb-demo-1
              configMap:
                name: alb-demo-1
          containers:
            - name: alb-demo-1
              image: nginx:latest
              ports:
                - name: http
                  containerPort: 80
              livenessProbe:
                httpGet:
                  path: /_healthz
                  port: 80
                initialDelaySeconds: 3
                timeoutSeconds: 2
                failureThreshold: 2
              volumeMounts:
                - name: alb-demo-1
                  mountPath: /etc/nginx
                  readOnly: true
              resources:
                limits:
                  cpu: 250m
                  memory: 128Mi
                requests:
                  cpu: 100m
                  memory: 64Mi
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: alb-demo-1
    spec:
      selector:
        app: alb-demo-1
      type: NodePort
      ports:
        - name: http
          port: 80
          targetPort: 80
          protocol: TCP
          nodePort: 30081
    
  3. В отдельной директории создайте файл http-group.yaml, содержащий настройки ресурса HttpBackendGroup:

    apiVersion: alb.yc.io/v1alpha1
    kind: HttpBackendGroup
    metadata:
      name: example-backend-group
    spec:
      backends: # Список бэкендов.
        - name: alb-demo-1
          weight: 70 # Относительный вес бэкенда при распределении трафика. Нагрузка будет распределяться пропорционально весам других бэкендов из группы. Укажите вес, даже если в группе один бэкенд.
          service:
             name: alb-demo-1
             port:
               number: 80
        - name: bucket-backend
          weight: 30
          storageBucket:
            name: <имя_бакета>
    

    (Опционально) Укажите дополнительные настройки для группы бэкендов:

    • spec.backends.useHttp2 — режим использования протокола HTTP/2.
    • spec.backends.tls — сертификат удостоверяющего центра, которому балансировщик будет доверять при установке безопасного соединения с эндпоинтами бэкендов. Укажите содержимое сертификата в поле trustedCa в открытом виде.

    Подробнее см. в разделе Группы бэкендов.

  4. В той же директории создайте файл ingress-http.yaml и укажите в нем делегированное ранее доменное имя, идентификатор полученного ранее сертификата и настройки L7-балансировщика Application Load Balancer:

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: alb-demo-tls
      annotations:
        ingress.alb.yc.io/subnets: <список_идентификаторов_подсетей>
        ingress.alb.yc.io/security-groups: <список_идентификаторов_групп_безопасности>
        ingress.alb.yc.io/external-ipv4-address: <способ_назначения_IP-адреса>
        ingress.alb.yc.io/group-name: my-ingress-group
    spec:
      tls:
        - hosts:
          - <доменное_имя>
          secretName: yc-certmgr-cert-id-<идентификатор_TLS-сертификата>
      rules:
        - host: <доменное_имя>
          http:
            paths:
              - path: /app1
                pathType: Exact
                backend:
                  resource:
                    apiGroup: alb.yc.io
                    kind: HttpBackendGroup
                    name: example-backend-group
    

    Где:

    • ingress.alb.yc.io/subnets — одна или несколько подсетей, в которых будет расположен L7-балансировщик Application Load Balancer.

    • ingress.alb.yc.io/security-groups — одна или несколько групп безопасности для балансировщика. Если параметр не задан, используется группа безопасности по умолчанию. Хотя бы одна из групп безопасности должна разрешать исходящее TCP-соединение к порту 10501 в подсети группы узлов Managed Service for Kubernetes или в ее группу безопасности.

    • ingress.alb.yc.io/external-ipv4-address — предоставление публичного доступа к балансировщику из интернета. Укажите заранее полученный IP-адрес либо установите значение auto, чтобы получить новый.

      Если вы указали значение auto, то при удалении балансировщика из облака также будет удален его IP-адрес. Чтобы избежать этого, используйте имеющийся зарезервированный адрес.

    • ingress.alb.yc.io/group-name — имя группы. Ресурсы Ingress объединяются в группы, каждая из которых обслуживается отдельным балансировщиком.

      Вместо my-ingress-group вы можете указать произвольное имя группы. Убедитесь, что оно соответствует требованиям.

    (Опционально) Укажите дополнительные настройки балансировщика.

    Примечание

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

    К виртуальным хостам остальных ресурсов Ingress в группе эти настройки применены не будут.

    Доступные настройки:

    • ingress.alb.yc.io/group-settings-name — имя для настроек группы ресурсов Ingress, которые должны быть описаны в дополнительном ресурсе IngressGroupSettings. Подробнее см. в разделе Настройте группу ресурсов Ingress.

    • ingress.alb.yc.io/internal-ipv4-address — предоставление внутреннего доступа к балансировщику. Укажите внутренний IP-адрес, либо установите значение auto, чтобы получить IP-адрес автоматически.

      Примечание

      Вы можете одновременно использовать только один тип доступа к балансировщику: ingress.alb.yc.io/external-ipv4-address или ingress.alb.yc.io/internal-ipv4-address.

    • ingress.alb.yc.io/internal-alb-subnet — подсеть, в которой нужно разместить балансировщик. Обязательный параметр, если выбран параметр ingress.alb.yc.io/internal-ipv4-address.

    • ingress.alb.yc.io/protocol — протокол соединений между балансировщиком и бэкендами:

      • http — HTTP/1.1. Значение по умолчанию.
      • http2 — HTTP/2.
      • grpc — gRPC.
    • ingress.alb.yc.io/prefix-rewrite — замена пути на указанное значение.

    • ingress.alb.yc.io/upgrade-types — допустимые значения HTTP-заголовка Upgrade, например, websocket.

    • ingress.alb.yc.io/request-timeout — максимальный период, на который может быть установлено соединение.

    • ingress.alb.yc.io/idle-timeout — максимальный период, в течение которого соединение может простаивать без передачи данных.

      Значения для request-timeout и idle-timeout следует указывать с единицами измерения, например: 300ms, 1.5h. Допустимые единицы измерения:

      • ns — наносекунды.
      • us — микросекунды.
      • ms — миллисекунды.
      • s — секунды.
      • m — минуты.
      • h — часы.
    • ingress.alb.yc.io/security-profile-id — поддержка сервиса Yandex Smart Web Security, который позволяет защититься от {% if lang == "ru" %}DDoS-атакDDoS-атак{% endif %} и ботов, а также задействовать WAF и ограничить нагрузку на защищаемый ресурс.

      Чтобы включить поддержку сервиса, в аннотации Ingress укажите заранее созданный профиль безопасности Smart Web Security:

      ingress.alb.yc.io/security-profile-id: <идентификатор_профиля_безопасности>
      

      Примечание

      Для подключения профиля безопасности к виртуальному хосту Application Load Balancer у сервисного аккаунта, от имени которого работает Ingress-контроллер, должна быть роль smart-web-security.editor на каталог, в котором размещены ресурсы Application Load Balancer и Smart Web Security. Подробнее см. Назначение роли сервисному аккаунту.

    • ingress.alb.yc.io/use-regex — поддержка регулярных выражений стандарта RE2 при сопоставлении пути запроса. Если передана строка true, поддержка включена. Применимо, только если для параметра pathType указано значение Exact.

    Подробное описание настроек ресурса Ingress см. в статье Поля и аннотации ресурса Ingress.

  5. Создайте приложение Kubernetes, ресурс HttpBackendGroup и ресурс Ingress:

    kubectl apply -f .
    

ALB Ingress Controller автоматически развернет L7-балансировщик по конфигурации ресурса Ingress.

  1. Дождитесь создания L7-балансировщика Application Load Balancer и получения им публичного IP-адреса, это может занять несколько минут.

    Чтобы отслеживать создание балансировщика и убедиться в отсутствии ошибок, откройте логи пода, в котором запущен процесс создания:

    1. В консоли управления перейдите на страницу каталога и выберите сервис Managed Service for Kubernetes.

    2. Нажмите на имя нужного кластера и на панели слева выберите Рабочая нагрузка.

    3. Выберите один из подов alb-demo-***, в котором запущен процесс создания балансировщика.

    4. На странице пода перейдите на вкладку Логи.

      В режиме реального времени записываются и отображаются логи о создании балансировщика. Если возникла ошибка во время создания, она появится в логах.

  2. Убедитесь, что балансировщик создан. Для этого выполните команду и проверьте, что в поле ADDRESS в выводе команды появилось значение:

    kubectl get ingress alb-demo-tls
    

    Результат:

    NAME          CLASS   HOSTS           ADDRESS     PORTS    AGE
    alb-demo-tls  <none>  <доменное_имя>  <IP-адрес>  80, 443  15h
    

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

В параметрах ресурса HttpBackendGroup/GrpcBackendGroup вы можете настроить собственные проверки состояния. Подробнее см. в разделе Проверка состояния приложений в кластере Yandex Managed Service for Kubernetes с помощью L7-балансировщика Yandex Application Load Balancer.

(Опционально) Настройте группу ресурсов Ingress(Опционально) Настройте группу ресурсов Ingress

Если при настройке ресурса Ingress вы указали имя для настроек группы ресурсов Ingress в аннотации ingress.alb.yc.io/group-settings-name, то вы можете задать настройки логирования для L7-балансировщика. Для этого создайте пользовательскую лог-группу и укажите настройки группы ресурсов Ingress в дополнительном ресурсе IngressGroupSettings:

  1. Создайте файл settings.yaml и укажите в нем настройки логирования и идентификатор пользовательской лог-группы, например:

    apiVersion: alb.yc.io/v1alpha1
    kind: IngressGroupSettings
    metadata:
      name: <имя_для_настроек_группы_ресурсов_Ingress>
    logOptions:
      logGroupID: <идентификатор_пользовательской_лог-группы>
      discardRules:
        - discardPercent: 50
          grpcCodes:
            - OK
            - CANCELLED
            - UNKNOWN
        - discardPercent: 67
          httpCodeIntervals:
            - HTTP_1XX
        - discardPercent: 20
          httpCodes:
            - 200
            - 404
    

    Где name — имя для настроек группы ресурсов Ingress в аннотации ingress.alb.yc.io/group-settings-name.

  2. Примените настройки для группы ресурсов Ingress:

    kubectl apply -f settings.yaml
    

Убедитесь в доступности приложений через L7-балансировщикУбедитесь в доступности приложений через L7-балансировщик

  1. Если вы не устанавливали ExternalDNS c плагином для Cloud DNS, добавьте A-запись в зону вашего домена. В поле Значение укажите публичный IP-адрес L7-балансировщика Application Load Balancer. При использовании ExternalDNS c плагином для Yandex Cloud DNS запись создастся автоматически.

  2. Проверьте работу балансировщика:

    Ресурс Ingress для сервисов Kubernetes
    Ресурс Ingress для группы бэкендов

    Откройте в браузере URI приложений:

    https://<ваш_домен>/app1
    https://<ваш_домен>/app2
    

    Убедитесь, что приложения доступны через L7-балансировщик Application Load Balancer и возвращают страницы с текстом This is APP#1 и This is APP#2 соответственно.

    Примечание

    Если ресурс недоступен по указанному URL, то убедитесь, что группы безопасности для кластера Managed Service for Kubernetes и его групп узлов настроены корректно. Если отсутствует какое-либо из правил — добавьте его.

    Откройте в браузере URI приложения:

    https://<ваш_домен>/app1
    

    Убедитесь, что целевые ресурсы доступны через L7-балансировщик Application Load Balancer.

    Примечание

    Если ресурс недоступен по указанному URL, то убедитесь, что группы безопасности для кластера Managed Service for Kubernetes и его групп узлов настроены корректно. Если отсутствует какое-либо из правил — добавьте его.

Удалите созданные ресурсыУдалите созданные ресурсы

Некоторые ресурсы платные. Чтобы за них не списывалась плата, удалите ресурсы, которые вы больше не будете использовать:

  1. Удалите кластер Managed Service for Kubernetes.
  2. Удалите целевые группы Application Load Balancer.
  3. Удалите бакет Object Storage.

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

Предыдущая
Настройка Gateway API
Следующая
Настройка логирования для L7-балансировщика Application Load Balancer с помощью Ingress-контроллера
Проект Яндекса
© 2025 ООО «Яндекс.Облако»