Yandex.Cloud
  • Сервисы
  • Почему Yandex.Cloud
  • Сообщество
  • Тарифы
  • Документация
  • Связаться с нами
Подключиться
Yandex Managed Service for Kubernetes
  • Начало работы
  • Пошаговые инструкции
    • Все инструкции
    • Подключение к узлу по SSH
    • Создание файла конфигурации
    • Сетевые сценарии
      • Обеспечение доступа к приложению, запущенному в кластере Kubernetes
      • Работа с сетевыми политиками кластера Kubernetes
    • Шифрование секретов
    • Работа с постоянными томами
      • Динамическая подготовка тома
      • Статическая подготовка тома
      • Управление классами хранилищ
      • Увеличение размера тома
      • Подключение тома в блочном режиме
    • Управление кластером Kubernetes
      • Добавление учетных данных кластера Kubernetes в конфигурационный файл kubectl
      • Получение информации о кластере Kubernetes
      • Создание кластера Kubernetes
      • Изменение кластера Kubernetes
      • Удаление кластера Kubernetes
    • Управление группой узлов
      • Получение информации о группе узлов
      • Создание группы узлов
      • Изменение группы узлов
      • Удаление группы узлов
  • Сценарии использования
    • Интеграция с Container Registry
    • Запуск рабочих нагрузок с GPU
    • Резервное копирование в Object Storage
  • Концепции
    • Взаимосвязь ресурсов сервиса
    • Релизные каналы и обновления
    • Использование объектов API Kubernetes
      • Том
      • Сервис
    • Группа узлов
      • Автоматическое масштабирование группы узлов
      • Расселение подов с узла
      • Динамическое резервирование ресурсов для узла
      • Группы узлов с GPU
    • Сетевые политики кластера Kubernetes
    • Квоты и лимиты
  • Управление доступом
  • Правила тарификации
  • Справочник API
    • Аутентификация в API
    • gRPC
      • Обзор
      • ClusterService
      • NodeGroupService
      • VersionService
      • OperationService
    • REST
      • Обзор
      • Cluster
        • Обзор
        • create
        • delete
        • get
        • list
        • listNodeGroups
        • listOperations
        • update
      • NodeGroup
        • Обзор
        • create
        • delete
        • get
        • list
        • listOperations
        • update
      • Version
        • Обзор
        • list
  • Вопросы и ответы
  1. Концепции
  2. Группа узлов
  3. Расселение подов с узла

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

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

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

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

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

    Важно

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

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

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