← Назад к вопросам

Что планирует планировщик в Kubernetes

2.0 Middle🔥 201 комментариев
#Kubernetes

Комментарии (1)

🐱
deepseek-v3.2PrepBro AI6 апр. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Что планирует планировщик (Scheduler) в Kubernetes?

Планировщик (kube-scheduler) — это один из ключевых компонентов Control Plane Kubernetes, отвечающий за автоматическое распределение подов (Pods) на доступные узлы кластера (Nodes). Его основная задача — принимать новые или незапланированные пода и выбирать для них наиболее подходящий узлы, обеспечивая оптимальную работоспособность, эффективность и соблюдение ограничений кластера.

Процесс планирования можно разделить на три основные фазы: фильтрация, оценка и привязка.

1. Фаза фильтрации (Filtering)

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

  • Запросы ресурсов (requests) пода (CPU, память) vs доступные ресурсы узла.
  • Привязка к узлу (nodeSelector) или привязка к регионам/зонам (nodeAffinity).
  • Тaints и Tolerations: узлы могут иметь "загрязнения" (taints), которые пода должен "терпеть" (tolerations) для запуска.
  • Проверка портов: конфликты запрошенных портов на узле.
  • Тип узла: например, исключение мастер-узлов (часто имеют taint: node-role.kubernetes.io/master:NoSchedule).
  • Состояние узла: готовность, давление памяти/диска.

Пример фильтрации по nodeSelector в манифесте пода:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
  nodeSelector:
    diskType: ssd # Pod будет запущен только на узлах с label `diskType=ssd`

2. Фаза оценки (Scoring)

Для каждого узла из списка кандидатов планировщик вычисляет score (оценку) с помощью наборов стратегий оценки (score plugins). Узел с наивысшим общим счетом считается наиболее оптимальным. Основные стратегии:

  • LeastAllocated: предпочтение узлам с наибольшим количеством свободных ресурсов (CPU, память). Равномерное распределение нагрузки.
  • BalancedResourceAllocation: баланс между свободными CPU и памятью, избегая ситуаций, где на узле много свободной памяти, но мало CPU.
  • ImageLocality: предпочтение узлам, где уже есть часть образа контейнера (уменьшает время загрузки).
  • InterPodAffinity/AntiAffinity: учет правил сродства и антисродства между подами (например, разместить связанные пода вместе или разнести для устойчивости).
  • NodeAffinity: усиление правил привязки к узлам из фазы фильтрации.

Планировщик суммирует оценки от всех активных стратегий. Их можно настраивать через профиль планирования (SchedulerProfile) в конфигурации kube-scheduler.

3. Фаза привязки (Binding)

После выбора оптимального узла планировщик выполняет привязку (Binding): он создает объект Binding в API Kubernetes, который указывает, что данный Pod должен быть запущен на конкретном Node. Затем этот Binding отправляется на соответствующий kubelet узла, который и запускает контейнеры пода.

Если фаза привязки временно не удается (например, узлу стало недостаточно ресурсов), Pod возвращается в очередь планировщика.

Как планировщик взаимодействует с системой?

  1. API Server помещает новый Pod (с nodeName пустым) в очередь планирования.
  2. Scheduler выбирает подходящий Node.
  3. Scheduler обновляет Pod в API Server, устанавливая nodeName.
  4. API Server сохраняет это изменение.
  5. Kubelet на назначенном Node, наблюдая за изменениями Pods, видит новый Pod с назначенным ему nodeName и начинает его запуск.

Пример работы с ограничениями (Taints & Tolerations)

Узел мастер часто имеет Taint для защиты:

kubectl taint nodes node01 node-role.kubernetes.io/master:NoSchedule

Pod для системного компонента может иметь Toleration для запуска на мастере:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  tolerations:
  - key: "node-role.kubernetes.io/master"
    operator: "Exists"
    effect: "NoSchedule"
  containers:
  - name: app
    image: my-app:latest

Планирование с учетом топологии (Topology Spread Constraints)

Для распределения Pods по зонам (например, в мульти-AZ кластере):

spec:
  topologySpreadConstraints:
  - maxSkew: 1 # Максимальная разница количества Pods между зонами
    topologyKey: topology.kubernetes.io/zone # Ключ label зоны
    whenUnsatisfiable: DoNotSchedule # Не планировать, если условие не выполняется
    labelSelector:
      matchLabels:
        app: my-app # Ограничение применяется только к Pods с этим label

Планировщик — это "интеллектуальный диспетчер", который постоянно оценивает состояние кластера и принимает решения, обеспечивая стабильность, высокую доступность и эффективное использование ресурсов. Он позволяет администраторам задавать сложные политики размещения через Declarative API, абстрагируясь от низкоуровневого управления инфраструктурой. Настройка его профилей и политик — важная часть оптимизации крупных кластеров.

Что планирует планировщик в Kubernetes | PrepBro