Даниил Кондрашов

Представьте ситуацию: ваше приложение в Kubernetes работает стабильно, но внезапно начинается пиковая нагрузка. Поды пытаются масштабироваться, HPA увеличивает их количество, но... они висят в статусе Pending. Почему? Потому что в кластере недостаточно ресурсов на нодах. Cluster Autoscaler должен добавить новые ноды, но процесс занимает много времени, иногда нода не создается из-за проблем с облаком. За это время пользователи уже получают ошибки 503, а вы теряете деньги. Знакомо? А теперь обратная ситуация: нагрузка спала, поды удалились, но ноды продолжают работать вхолостую. Вы платите за простаивающие ресурсы, потому что Cluster Autoscaler слишком консервативен в удалении нод или не может оптимально «упаковать» workloads. Есть ли способ сделать это быстрее, умнее и экономичнее? Меня зовут Даниил Кондрашов, я разработчик Managed Kubernetes в Selectel. В этой статье познакомлю вас с Karpenter — современным решением для автоматического управления нодами в Kubernetes, которое решает эти проблемы принципиально иначе. Подробности в статье! Основы автоскейлинга в Kubernetes Прежде чем погружаться в Karpenter, важно понять общую картину автоскейлинга в Kubernetes. Масштабирование происходит на трех уровнях, и каждый решает свою задачу. Уровень 1. Horizontal Pod Autoscaler (HPA) отвечает за горизонтальное масштабирование — увеличение или уменьшение количества подов в Deployment или StatefulSet. HPA мониторит метрики (CPU, память, кастомные метрики) и добавляет реплики, когда нагрузка растет. Это первая линия обороны против перегрузки. Уровень 2. Vertical Pod Autoscaler (VPA) работает на уровне вертикального масштабирования — он изменяет количество ресурсов (CPU, память) внутри самого пода. VPA анализирует реальное потребление и корректирует resource requests и limits. Это полезно для приложений, которые нельзя горизонтально масштабировать, или для оптимизации ресурсов долгоживущих подов. Масштабирование приложений (подов). HPA и VPA. Уровень 3. Cluster Autoscaler (CA) — это инфраструктурный уровень. Когда HPA добавляет поды, но им не хватает места на существующих нодах, в игру вступает Cluster Autoscaler. Он добавляет новые ноды в кластер через взаимодействие с облачным провайдером. И наоборот — удаляет недоиспользуемые ноды для экономии средств. Схема работы Cluster Autoscaler. Cluster Autoscaler: возможности и ограничения Cluster Autoscaler (CA) — это стандартное решение для автоматического управления нодами в Kubernetes. Он работает по довольно простому принципу: периодически проверяет, есть ли в кластере поды в состоянии Pending из-за нехватки ресурсов. Если да — запрашивает у облачного провайдера новые виртуальные машины из заранее настроенных Node Groups. Основные возможности CA Автоматическое добавление нод при нехватке ресурсов Удаление недоиспользуемых нод Поддержка разных облачных провайдеров Звучит неплохо, но в реальной практике начинают проявляться ограничения. 1. Жесткая привязка к Node Groups. Вам нужно заранее создать Node Groups с разными типами инстансов: CPU-оптимизированные, memory-оптимизированные и т. д. CA может выбирать только из этих предопределенных групп. Если вашему workload нужна специфическая конфигурация — придется создавать новую Node Group и переконфигурировать CA. 2. Проблемы с bin packing. CA не всегда оптимально «упаковывает» поды на ноды. Он может оставлять полупустые ноды, которые нельзя удалить, потому что на них висит один маленький под. Это приводит к переплате за ресурсы. 3. Ограниченная гибкость выбора инстансов. Даже если вы настроили несколько типов инстансов в Node Group, CA может не выбрать оптимальный. Например, под запрашивает 2 CPU и 4 ГБ памяти, а CA создает инстанс с 4 CPU и 8 ГБ, потому что так настроена Node Group. Представьте ситуацию: у вас микросервисная архитектура, где одни сервисы требуют много CPU (обработка данных), другие — много памяти (кэширование), третьи — GPU (ML-inference). С Cluster Autoscaler вам придется создать отдельные Node Groups для каждого типа нагрузки, настроить taints и tolerations, node affinity... Конфигурация превращается в лабиринт YAML-файлов. Знакомство с Karpenter Karpenter — это open-source проект автоматического управления нодами, изначально разработанный командой AWS, но работающий с различными облачными провайдерами, включая Selectel, Azure, GCP, и другие. Философия Karpenter принципиально отличается от Cluster Autoscaler: вместо работы через предопределенные Node Groups, Karpenter использует подход just-in-time provisioning — создание нод точно под требования конкретных workloads в момент, когда они нужны. Как это работает? Когда в кластере появляется Pending под, Karpenter мгновенно анализирует его требования (CPU, память, GPU, taints, affinity, topology spread constraints) и напрямую обращается к API облачного провайдера, чтобы создать виртуальную машину с оптимальной конфигурацией. Никаких предопределенных групп, никаких промежуточных абстракций — только прямое взаимодействие с облаком. Ключевые преимущества Karpenter над Cluster Autoscaler Скорость реакции. Karpenter реагирует на события практически мгновенно. Динамический выбор типов инстансов. Karpenter может выбирать из всего каталога типов виртуальных машин провайдера. Вы задаете ограничения, например «только инстансы с не менее чем 2 CPU» или «из линейки Memory», а Karpenter сам подбирает оптимальный вариант. В Selectel это может быть выбор между Standard, CPU, Memory, Shared, GPU и High-Freq линейками в зависимости от требований. Лучшая оптимизация затрат. Karpenter активно использует алгоритмы bin packing для максимально плотной упаковки подов на минимальное количество нод. Более того, у него есть встроенный механизм consolidation (консолидации) — он постоянно анализирует, можно ли перераспределить workloads и использовать более экономичные по стоимости ноды, и делает это автоматически. Automatic deprovisioning. Karpenter не только добавляет ноды, но и умно их удаляет. Он отслеживает недоиспользуемые ноды, пустые ноды, expired ноды (по TTL) и gracefully удаляет их, предварительно перемещая workloads. Простота конфигурации. Вместо множества Node Groups и сложных настроек вы описываете требования в одном или нескольких ресурсах NodePool. Конфигурация более декларативная и понятная. Поддержка spot/preemptible instances. Karpenter может легко миксовать on-demand и spot инстансы для оптимизации затрат, автоматически заменяя прерванные spot-ноды. Как работает Karpenter: архитектура Чтобы эффективно использовать Karpenter, полезно понимать его внутреннее устройство. Архитектура достаточно элегантна и состоит из нескольких ключевых компонентов. Karpenter Controller — это основной мозг системы, работающий как обычный Deployment в вашем кластере. Он выполняет несколько задач одновременно: отслеживает поды в состоянии Pending через Kubernetes API; анализирует требования этих подов (resource requests, node selectors, affinity, taints); принимает решения о создании новых нод; управляет жизненным циклом существующих нод; выполняет consolidation и deprovisioning. Cloud Provider — модуль, который знает, как работать с API конкретного облачного провайдера. Для Selectel это означает знание о доступных типах виртуальных машин (Standard, CPU, Memory, High-Freq, Shared, GPU), регионах (ru-1, ru-2, и т. д). Схема работы Karpenter. Давайте пройдемся по типичному сценарию работы. Шаг 1. Обнаружение Pending-подов. Вы делаете kubectl scale deployment myapp --replicas10, HPA срабатывает, или просто появляется новый workload. Kubernetes Scheduler пытается разместить поды на существующих нодах, но свободных ресурсов нет — поды переходят в состояние Pending. Шаг 2. Анализ требований. Karpenter через мгновенно получает уведомление о Pending-подах. Он анализирует их спецификации: – Resource requests: cpu: 1000m, memory: 2Gi, – Tolerations для определенных taints, – Affinity и anti-affinity правила, – Topology spread constraints. Шаг 3. Выбор оптимального типа инстанса. На основе собранных требований Karpenter обращается к Cloud Provider модулю: «Мне нужен инстанс, минимум 1 vCPU и 2GB RAM, желательно с хорошим соотношением цена/производительность». Модуль возвращает список подходящих типов виртуальных машин из облака, отсортированный по критериям: стоимости, производительности и доступности. Шаг 4. Создание ноды через API. Karpenter делает прямой вызов к API Selectel для создания виртуальной машины выбранного типа. Она создается со всеми необходимыми параметрами. Шаг 5. Регистрация в кластере. Созданная виртуальная машина запускается, устанавливаются необходимые компоненты Kubernetes (kubelet, containerd) и регистрируется в кластере как новая нода. Scheduler сразу же размещает Pending-поды на эту свежую ноду. Параллельный процесс: Consolidation. Одновременно с мониторингом Pending-подов, Karpenter постоянно анализирует существующие ноды. Он спрашивает себя: «Могу ли я перераспределить workloads так, чтобы использовать меньше нод и меньше платить?» Если да — делает gracefully evict подов с одной ноды, переносит их на другие и удаляет освободившуюся ноду. Это происходит без простоев благодаря соблюдению PodDisruptionBudgets. Deprovisioning (удаление нод) происходит в нескольких случаях. Empty nodes — еси нода пустая дольше заданного времени. Expired nodes — если достигнут TTL ноды (полезно для ротации нод со spot инстансами). Consolidation — если workloads можно упаковать плотнее. Drift — если конфигурация NodePool изменилась и нода больше не соответствует требованиям. NodePool определяет требования к нодам (лимиты, instance types), а NodeClass — специфичные для облачного провайдера настройки (AMI, типы инстансов, сетевые настройки, дисков). Базовая установка Karpenter в Selectel Теперь перейдем к практике и установим Karpenter в кластер Managed Kubernetes. Хорошая новость: в Selectel процесс установки значительно упрощен благодаря готовому Helm chart, который уже интегрирован с облачной инфраструктурой. Предварительные требования Минимальная конфигурация кластера Kubernetes версии 1.28. Минимум одна нода с не менее 2 vCPU и 4 ГБ RAM для работы самого Karpenter. Рекомендации для продакшена Нужны две ноды с 2 vCPU и 4 ГБ RAM — для отказоустойчивости компонентов Karpenter. Выключите Cluster Autoscaler в панели управления, если он активен. Karpenter и CA конфликтуют при одновременной работе. Отключите автовосстановление нод для групп, которыми будет управлять Karpenter. Инструменты Kubectl, настроенный для работы с вашим кластером. Helm 3.16+, установленный локально. Для версии 3.17+ синтаксис немного отличается. Kubeconfig-файл для доступа к кластеру. Кластер в панели управления Selectel. Получение необходимой информации Шаг 1. Найдите ID кластера в панели управления Selectel. Для этого перейдите в Верхнее меню → Продукты → Managed Kubernetes, выберите ваш кластер и скопируйте Cluster ID — он находится под именем кластера, рядом с регионом и пулом. Шаг 2. Подготовьте kubeconfig. Если вы еще не скачали kubeconfig-файл, перейдите в панель управления на странице кластера и нажмите Скачать kubeconfig. Сохраните файл, например, как my-cluster.yaml. Установка Karpenter Шаг 1. Экспортируйте путь к kubeconfig и проверьте доступ к кластеру: Шаг 2.1. Установите Karpenter через Helm. Для Helm 3.17 и выше: Для Helm 3.16 и ниже: Шаг 2.2. Замените на ID вашего кластера, который вы скопировали на предыдущем шаге. Пример: При установке Helm скачивает chart из GitHub, создаются Deployment и Service для Karpenter controller, устанавливаются необходимые RBAC права. На последнем этапе Karpenter автоматически получает credentials для работы с Selectel API через интеграцию с Managed Kubernetes. Шаг 3. Проверьте установку. Дождитесь, пока под Karpenter запустится и проверьте логи для подтверждения успешной инициализации: Если в логах есть ошибки аутентификации или подключения к API, проверьте правильность указания Cluster ID. На этом базовая установка завершена! Karpenter запущен, но пока не будет создавать ноды, так как мы ещё не настроили NodePool и NodeClass. Перейдем к настройке в следующем разделе. Настройка Karpenter для Selectel После установки необходимо настроить два ключевых ресурса: NodeClass, который определяет инфраструктурные параметры нод, и NodePool, который описывает правила подбора и масштабирования. Давайте разберемся, как это работает в Selectel. Создание SelectelNodeClass SelectelNodeClass — это Selectel-специфический ресурс, который определяет параметры дисков для создаваемых нод. В отличие от общего Karpenter, где нужно настраивать AMI, security groups и другие низкоуровневые детали, в Selectel все проще — достаточно указать тип и размер загрузочного сетевого диска. Начнем с базовой конфигурации для сетевых дисков: Применяем конфигурацию: Создание NodePool Теперь создадим NodePool — ресурс, который описывает, какие ноды может создавать Karpenter и когда. NodePool использует мощную систему requirements (требований) для фильтрации доступных конфигураций из облака Selectel. Базовый NodePool: Применяем: Важные моменты базовой конфигурации topology.kubernetes.io/zone — определяет зоны доступности в регионе Selectel. Для регионов Selectel это ru-7a/b, ru-2a/b, и т. д. node.kubernetes.io/instance-type — конкретные флейворы (конфигурации виртуальных машин). Полный список доступных флейворов можно посмотреть в документации Selectel. consolidationPolicy — указывает, как Karpenter управляет существующими нодами: WhenEmpty (только полностью пустые ноды, без подов, daemon set не считаются нагрузкой) и рекомендуемый WhenEmptyOrUnderutilized (пустые и недоиспользуемые). Продвинутый Karpenter: использование расширенных фильтров Практический пример: CPU-workload приложение Теперь давайте создадим реальное приложение и посмотрим, как Karpenter справляется с его развертыванием. Мы создадим CPU-workload Deployment, который будет размещен на нодах из нашего cpu-workload NodePool. Применяем Deployment: Наблюдаем за работой Karpenter Сразу после применения откройте несколько терминалов для наблюдения. Терминал 1. Статус подов: Терминал 2. Статус нод: Терминал 3. Логи Karpenter: Что происходит Поды создаются и переходят в статус Pending, так как в кластере нет подходящих нод с label workload-type: cpu-workload. Karpenter обнаруживает Pending поды и анализирует их требования. Требуют 2 vCPU и 2 ГБ RAM каждый (итого: 10 vCPU, 10 ГБ RAM). Имеют toleration для workload-type: cpu-workload. Должны быть размещены на нодах с label workload-type: cpu-workload. В логах Karpenter вы увидите: Karpenter принимает решение создать одну ноду типа SL1.12-49152 (12 vCPU, 48 ГБ RAM) из линейки Standard Line. Для этого есть несколько причин. Требования: минимум 10 vCPU и 10 ГБ RAM. Фильтр instance-cpu > 4 разрешает конфигурации с 8, 16, 32+ vCPU. Karpenter выбирает оптимальную конфигурацию. В логах видим: Karpenter обращается к API Selectel для создания виртуальной машины. Как итог — она создана, запущена и регистрируется в кластере. Созданная нода в панели управления Selectel. Scheduler размещает все пять подов на новую ноду. Поды переходят из Pending в Running. Время от создания Deployment до Running подов составляет примерно 180 секунд! Теперь давайте посмотрим, насколько эффективно Karpenter распределил ресурсы: Отлично! Нода утилизирована на 84% CPU (10 из 16 vCPU используются подами), при этом память практически не используем, так как сценарий — тестовый. Демонстрация умной consolidation Далее давайте уменьшим количество реплик и посмотрим, как Karpenter оптимизирует ресурсы: Что происходит Три пода удаляются, на ноде остается только два пода. Как итог — из 12 vCPU и 48 ГБ используются всего 4 vCPU и 4 ГБ RAM соответственно. Karpenter замечает, что нода сильно недоиспользуется (всего 36% CPU). Благодаря настройке consolidationPolicy: WhenEmptyOrUnderutilized и consolidateAfter: 30s, Karpenter принимает решение об оптимизации. В логах видим: Новая виртуальная машина создана, запущена и регистрируется в кластере. Созданная нода в панели управления Selectel. Scheduler размещает все два пода на новую ноду. Поды переходят из Pending в Running. Давайте посмотрим, насколько эффективно Karpenter подобрал ресурсы: Хороший результат! Нода утилизирована на 68% CPU (4 из 6 vCPU используются подами). После переезда подов прошлая виртуальная машина удаляется. Заключение Karpenter представляет собой современный и эффективный подход к управлению динамическими нагрузками в Kubernetes. В отличие от традиционного Cluster Autoscaler, Karpenter обеспечивает оптимизацию затрат, гибкость и простоту. Умная упаковка workloads и automatic consolidation снижают расходы Есть динамический выбор типов инстансов без предопределенных Node Groups. Декларативная конфигурация через NodePools гарантирует простоту вместо сложных настроек. Для команд, работающих с Managed Kubernetes Selectel, Karpenter особенно полезен при работе с микросервной архитектурой с разнородными требованиями к ресурсам, batch-обработкой с пиковыми нагрузками, Dev-/Staging-окружениями с непредсказуемой активностью и не только. Иначе говоря, решение особенно актуально для cost-sensitive проектов, в которых важна оптимизация затрат, и приложений с SLA, которые требуют быстрого масштабирования. Но помните, Karpenter — не серебряная пуля. Он требует правильной настройки resource requests в подах, понимания динамики системы, мониторинга и alerting, а также регулярного пересмотра конфигурации. Куда двигаться дальше Если вы хотите глубже изучить Karpenter, обратите внимание на официальную документацию и лучшие практики. А если строите инфраструктуру на базе нашего Managed Kubernetes, рекомендуем сохранить в закладки справочник по работе с сервисом.

Даниил Кондрашов

Материалы автора

Как Karpenter помогает управлять динамическими нагрузками в Kubernetes