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

Расселение подов с узла

Статья создана
Yandex Cloud
Обновлена 1 декабря 2023 г.

При обновлении группы узлов со старого узла поды расселяются — переносятся на новый узел. Для того чтобы расселение не сказывалось на доступности сервисов, обслуживаемых приложениями в кластере Kubernetes, сконфигурируйте объект API Kubernetes PodDisruptionBudget для подов приложения.

Объект PodDisruptionBudget описывается тремя полями:

  • .spec.selector — Kubernetes-метка селектора для указания набора подов, к которому он применяется. Обязательное поле.
  • .spec.minAvailable — минимальное количество подов из набора, которые должны быть доступны после расселения. Можно указать в процентах.
  • .spec.maxUnavailable — максимальное количество подов из набора, которые могут быть недоступны после расселения. Можно указать в процентах.

Если не описать политику PodDisruptionBudget, поды будут расселяться единовременно, что может привести к проблемам приложения.

Важно

  • Расселение подов происходит только в том случае, если они были созданы под управлением одного из контроллеров репликаций приложений: ReplicaSet, Deployment или StatefulSet. Если под был создан без контроллера, он будет потерян в процессе обновления.
  • Постоянные тома (объекты PersistentVolumes), которые используются подами под управлением контроллера StatefulSet, могут быть перенесены между узлами только в пределах одной зоны доступности.

Особенности расселения подов с узла:

  • Необходимо настроить политику PodDisruptionBudgets так, чтобы нельзя было расселить слишком много подов одновременно, но можно было расселить хотя бы один.
  • При расселении есть таймаут до остановки узла (7 минут). Если расселение подов не будет завершено за это время, то узел будет остановлен, несмотря на оставшиеся поды.
  • При уменьшении размера группы узлов для расселения подов и последующего удаления узла в первую очередь расселяются и удаляются узлы без подов. Также вы можете расселить необходимые узлы вручную, используя команду kubectl drain.
  • Узлы, которые будут расселены и остановлены, помечаются как Unschedulable. Это позволяет не создавать на них новые поды.
  • Расселение узлов в группе происходит по одному.
  • Узлы не расселяются при удалении группы узлов. Если к подам удаляемых узлов поступают запросы, они не будут обрабатываться, пока Kubernetes не диагностирует неработоспособность узлов и не создаст поды на работающих узлах. Чтобы этого избежать, измените размер группы узлов до нуля, дождитесь завершения операции и удалите группу узлов.

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

Предыдущая
Автоматическое масштабирование группы узлов
Следующая
Динамическое резервирование ресурсов для узла
Проект Яндекса
© 2025 ООО «Яндекс.Облако»