🤖 Для ИИ-задач часто нужны значительные ресурсы, но постоянно держать их занятыми не получается. Во время обучения модели мощностей требуется больше, между запусками — меньше. Поэтому важно уметь быстро перераспределять ресурсы между задачами и командами.

Kubernetes решает сразу две задачи: помогает эффективнее использовать GPU и упрощает управление инфраструктурой.

➡️ Подробнее о том, как Kubernetes используют для ИИ-задач и какую роль здесь играет Managed Kubernetes, читайте на Хабре.

📬 Мы в MAX

GPU в Kubernetes становятся гибче

Обычный device plugin работает с GPU как со счетчиком целых устройств: под запрашивает карту и получает ее целиком. DRA делает модель гибче: можно указать модель, поколение и объем видеопамяти, а планировщик подберет подходящее устройство.

Несколько подов можно привязать к одному ResourceClaim. Более гибкое деление GPU между независимыми нагрузками пока остается в beta, а отбор устройств по атрибутам стабилен с Kubernetes 1.34.

Подробнее о DRA и работе с GPU в Kubernetes — в статье.

📬 Мы в MAX

⚡️ Высокая загрузка CPU сама по себе — еще не сигнал для Cluster Autoscaler.

Автоскейлер реагирует на ситуацию, когда планировщик Kubernetes не может разместить поды и они остаются в Pending. Тогда Cluster Autoscaler проверяет, поможет ли добавление нового узла в одну из групп.

🧮 При расчете он смотрит на resources.requests: сколько CPU и памяти запросили поды, а не сколько ресурсов они потребляют прямо сейчас. Поэтому поды без корректно заданных requests могут не создать повода для масштабирования, даже если нагрузка на существующие узлы высокая.

⤵️ В обратную сторону работает похожая логика. Если нагрузка снизилась и поды можно разместить на меньшем числе узлов, автоскейлер расселяет недозагруженный узел и после периода простоя удаляет его. В Managed Containers от VK Cloud пустой узел должен оставаться таким пять минут.

При этом группа может не вырасти, даже если поды остаются в Pending. Например, если достигнут заданный максимум узлов, закончились квоты или требования nodeSelector, nodeAffinity и tolerations не позволяют разместить под на новом узле.

📃 В статье разобрали, как Cluster Autoscaler принимает решения о росте и сжатии группы, как выбирает узлы и с чего начинать диагностику, если автомасштабирование не сработало.

Читать статью →

📬 Мы в MAX

В Managed Containers второго поколения PV можно перенести из сервисного проекта в пользовательский. После этого диск станет обычным ресурсом проекта: его можно подключить к виртуальной машине, создать снимок или использовать для дальнейшей работы с данными.

Такой перенос пригодится в четырех случаях:

🔵пересоздание кластера
🔵миграция между кластерами второго поколения
🔵разбор инцидента в изоляции
🔵хранение архива по требованию регулятора.

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

📃 Читать статью →

📬 Мы в MAX

⚡️Автоскейлер Netflix сокращал потребление ресурсов на 25–45%. Для сложных Flink-задач этого оказалось недостаточно. Перевели для вас этот кейс.

Изначально Netflix использовал собственный автоскейлер. Он смотрел на CPU, сеть, Kafka lag и другие внешние метрики и менял общее число TaskManager, поэтому все операторы задачи масштабировались вместе. С ростом числа stateful-задач Netflix перешел на Apache Flink Autoscaler: он оценивает пропускную способность отдельных операторов и меняет параллелизм для конкретных вершин графа.

📃 В статье разобрали оба подхода, доработки Flink Autoscaler для масштаба Netflix и результаты перехода.

Полную версию читайте по ссылке 👈

📬 Мы в MAX

В Managed Containers появилась поддержка Dynamic Resource Allocation (DRA). Она позволяет динамически и декларативно назначать специализированные ресурсы Kubernetes, в том числе GPU.

DRA поможет:

✅ эффективнее использовать большие и дорогостоящие GPU
✅ снижать стоимость владения
✅ запускать ресурсоемкие AI/ML-нагрузки без ручной логики размещения.

На первом этапе DRA поддерживает выбранные GPU, совместимые группы узлов, драйверы и версии Kubernetes.

➡️ Подробнее о DRA — в документации.

📬 Мы в MAX

22 октября в Москве соберутся инженеры, архитекторы и DevOps-специалисты, которые работают с Kubernetes и Cloud-Native-инфраструктурой.

В программе — экономика платформ, эксплуатация Kubernetes, наблюдаемость, Service Mesh, безопасность в эпоху LLM, железо и bare metal. Между докладами будет время на нетворкинг, а завершится конференция афтепати. 

🗓 22 октября, 11:00–19:00
 📍 Москва, Connect

👉 Подробности о докладах и расписании конференции уже на сайте. Изучайте и регистрируйтесь

📬 Мы в MAX

🔹 Kubernetes проще учить через несколько базовых принципов, а не через всю экосистему сразу.

🔹 Например, желаемое состояние и reconciliation объясняют сразу несколько механизмов Kubernetes: самовосстановление, масштабирование и rollout. Система постоянно сравнивает фактическое состояние с заданным и устраняет расхождения.

Еще одна база — requests и limits. По requests Scheduler решает, на какой ноде разместить под, а limits задают верхнюю границу потребления ресурсов. Ошибка в настройках может привести либо к лишним расходам на мощности, либо к вытеснению подов.

📃 В статье разобрали пять опорных принципов, с которых стоит начинать изучение Kubernetes.

Читать на Хабре →

📬 Мы в MAX