Yandex Cloud
Поиск
Связаться с намиПодключиться
  • Документация
  • Блог
  • Все сервисы
  • Статус работы сервисов
    • Популярные
    • Инфраструктура и сеть
    • Платформа данных
    • Контейнеры
    • Инструменты разработчика
    • Бессерверные вычисления
    • Безопасность
    • Мониторинг и управление ресурсами
    • Машинное обучение
    • Бизнес-инструменты
  • Все решения
    • По отраслям
    • По типу задач
    • Экономика платформы
    • Безопасность
    • Техническая поддержка
    • Каталог партнёров
    • Обучение и сертификация
    • Облако для стартапов
    • Облако для крупного бизнеса
    • Центр технологий для общества
    • Облако для интеграторов
    • Поддержка IT-бизнеса
    • Облако для фрилансеров
    • Обучение и сертификация
    • Блог
    • Документация
    • Контент-программа
    • Мероприятия и вебинары
    • Контакты, чаты и сообщества
    • Идеи
    • Истории успеха
    • Тарифы Yandex Cloud
    • Промоакции и free tier
    • Правила тарификации
  • Документация
  • Блог
Проект Яндекса
© 2025 ООО «Яндекс.Облако»
Yandex Managed Service for Kubernetes
  • Сопоставление с другими сервисами Yandex Cloud
  • Начало работы
    • Все инструкции
    • Подключение к узлу по SSH
    • Подключение к узлу через OS Login
    • Обновление Kubernetes
    • Настройка автомасштабирования
    • Подключение Terraform-провайдера Kubernetes
      • Основы работы с Cloud Marketplace
      • Установка Argo CD
      • Установка Chaos Mesh
      • Установка cert-manager c плагином Cloud DNS ACME webhook
      • Установка Container Storage Interface для S3
      • Установка Crossplane
      • Установка External Secrets Operator
      • Установка ExternalDNS c плагином для Cloud DNS
      • Установка Falco
      • Установка Filebeat OSS
      • Установка Fluent Bit
      • Установка Gatekeeper
      • Установка Gateway API
      • Установка GitLab Agent
      • Установка GitLab Runner
      • Установка HashiCorp Vault
      • Установка Ingress NGINX
      • Установка Ingress-контроллера Application Load Balancer
      • Обновление Ingress-контроллера Application Load Balancer
      • Установка Istio
      • Установка Jaeger
      • Установка Kruise
      • Установка Kyverno & Kyverno Policies
      • Установка Loki
      • Установка Metrics Provider
      • Установка NodeLocal DNS
      • Установка Policy Reporter
      • Установка Prometheus Operator
      • Установка Thumbor
      • Установка Velero
    • Подключение внешних узлов к кластеру
  • Управление доступом
  • Правила тарификации
  • Справочник Terraform
  • Метрики Monitoring
  • Аудитные логи Audit Trails
  • История изменений
  • Обучающие курсы
  1. Пошаговые инструкции
  2. Установка приложений из Cloud Marketplace
  3. Обновление Ingress-контроллера Application Load Balancer

Обновление Ingress-контроллера Application Load Balancer

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

Версии ALB Ingress Controller 0.2.0 и позднее не совместимы с версиями 0.1.x. Из-за этого возникают ограничения, связанные с группами бэкендов.

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

Если вы обновляете ALB Ingress Controller с версии 0.1.x до версии 0.2.0 или позднее, проверьте, применимы ли следующие случаи к вашим группам ресурсов Ingress (группы формируются по значению аннотации ingress.alb.yc.io/group-name в ресурсах Ingress):

  • В конфигурациях встречаются одинаковые значения параметров host, http.paths.path и http.paths.pathType, при этом указаны разные сервисы Kubernetes в параметрах backend.service.name. В этом случае пересоздайте группы бэкендов с помощью объектов HttpBackendGroup.

  • На несколько связок параметров host, http.paths.path и http.paths.pathType приходится один сервис Kubernetes. В этом случае проверьте, различаются ли настройки бэкендов в параметре backend. Например, одна группа ресурсов Ingress может устанавливать соединения по протоколу gRPC, а другая — по протоколу HTTP.

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

    1. Для каждой группы ресурсов Ingress создайте отдельный файл с конфигурацией объекта Service. В объекте укажите:

      • Его название — для каждого сервиса используйте разные названия.
      • Название объекта Deployment — для каждого сервиса это название должно быть одинаковым, так как ранее использовался только один сервис Kubernetes.
      • Настройки бэкендов, которыми различаются группы ресурсов Ingress.
      Пример конфигурационного файла
      apiVersion: v1
      kind: Service
      metadata:
        name: alb-demo-service-1 # Укажите разные названия для каждого сервиса.
      spec:
        selector:
          app: alb-demo-app # Укажите один Deployment для каждого сервиса.
        type: NodePort
        ports:
          ... # Укажите настройки, которыми отличаются группы ресурсов Ingress.
      
    2. Примените полученные конфигурации:

      kubectl apply -f <названия_конфигурационных_файлов>
      
    3. Измените названия сервисов Kubernetes в ресурсах Ingress. В параметре backend.service.name укажите название сервиса в соответствии с той группой, в которой находится ресурс Ingress.

    4. Примените конфигурации измененных ресурсов Ingress:

      kubectl apply -f <названия_файлов_с_ресурсами_Ingress>
      

Примечание

Если нет возможности изменить конфигурацию ресурсов Ingress, не обновляйте ALB Ingress Controller. Иначе возникнут коллизии.

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

Предыдущая
Установка Ingress-контроллера Application Load Balancer
Следующая
Установка Istio
Проект Яндекса
© 2025 ООО «Яндекс.Облако»