Kube-scheduler: как Kubernetes назначает поды на ноды При создании пода в Kubernetes он не появляется на конкретной ноде автоматически. За выбор подходящего узла отвечает kube-scheduler — компонент control plane, который принимает решение, на какую ноду отправить новый или ожидающий назначения под. 🔭 Что делает kube-scheduler? Основная задача — найти для каждого пода ноду, которая: — соответствует всем жёстким требованиям (например, достаточно CPU и памяти, нужные метки, отсутствие запрещающих taint'ов); — является наилучшей по ряду критериев (например, более свободная, с меньшей загрузкой, предпочитаемая по affinity). После выбора scheduler сообщает API-серверу о назначении, и kubelet на выбранной ноде запускает под. ✍️ Как происходит планирование: Процесс планирования логически делится на два этапа: 📌 Фильтрация (Predicates / Filtering) Отсеиваются все ноды, которые не могут запустить под. Проверяются: 🔵достаточно ли свободных ресурсов (CPU, память, диски, порты); 🔵соответствуют ли нода меткам, указанным в nodeSelector или nodeAffinity; 🔵не запрещают ли taints запуск пода без соответствующих tolerations; 🔵соблюдены ли правила Pod Affinity/Anti-Affinity; 🔵не конфликтуют ли с уже запущенными подами (например, занятые порты hostPort). Результат — список подходящих нод. 📌 Оценка (Scoring / Prioritization) Каждая оставшаяся нода получает баллы по различным критериям. Чем больше баллов, тем предпочтительнее нода. Критерии могут быть разными: 🔵количество свободных ресурсов после запуска пода, 🔵сбалансированность использования ресурсов, 🔵близость к другим заданным подам (для уменьшения сетевых задержек), 🔵выполнение правил предпочтений (preferred affinity) и т.д. По итогам выбирается нода с наибольшей суммой баллов. Если подходящих нод нет — под остаётся в статусе Pending, и scheduler будет периодически повторять попытки. ⚙️ Ключевые механизмы управления планированием 💬 nodeSelector — Простейший способ указать, что под должен быть размещён на ноде с определённой меткой. 💬 Affinity и Anti-Affinity — Более выразительные правила, поддерживающие условия и уровни строгости (requiredDuringSchedulingIgnoredDuringExecution — жёсткое требование, preferredDuringSchedulingIgnoredDuringExecution — предпочтение). — Node affinity: привязка к характеристикам ноды — Pod affinity/anti-affinity: привязка к расположению других подов (например, требование запускать под на той же ноде, где уже работает под с меткой app=frontend, или, наоборот, избегать одной ноды с подами другого приложения). 💬 Taints и Tolerations — Taints (метка) наносятся на ноды и отталкивают поды, у которых нет соответствующих tolerations (переносимости). Позволяет выделять ноды под специальные задачи (например, только для GPU-нагрузок) или защищать мастер-ноды. 💬 Resource Requests и Limits — Scheduler учитывает запрошенные подом ресурсы (requests) и доступные на ноде. Без указания requests под может быть запланирован на перегруженную ноду, что приведёт к нехватке ресурсов для других. 💬 Приоритеты подов (Pod Priority and Preemption) — Поды можно разделять по приоритетам. Если высокоприоритетный под не может быть запланирован, scheduler может вытеснить (preempt) один или несколько низкоприоритетных подов с ноды, чтобы освободить место. Kube-scheduler — это мозг Kubernetes по размещению подов. Он не просто выбирает первую попавшуюся ноду, а принимает взвешенное решение на основе множества факторов. Управление его поведением через манифесты позволяет строить эффективные и надёжные системы, максимально использующие мощности кластера. #заметкиИнженера