Комментарии (1)
Ответ сгенерирован нейросетью и может содержать ошибки
Что планирует планировщик (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 возвращается в очередь планировщика.
Как планировщик взаимодействует с системой?
- API Server помещает новый Pod (с
nodeNameпустым) в очередь планирования. - Scheduler выбирает подходящий Node.
- Scheduler обновляет Pod в API Server, устанавливая
nodeName. - API Server сохраняет это изменение.
- 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, абстрагируясь от низкоуровневого управления инфраструктурой. Настройка его профилей и политик — важная часть оптимизации крупных кластеров.