Вокруг Kubernetes в VK

⚙️ Что происходит с GPU, пока никто не смотрит на метрики?

В Adobe столкнулись с проблемой: метрики GPU собирались централизованно, но дать командам прямой доступ к Prometheus было нельзя — вместе со своими данными они могли увидеть чужие.

Решение собрали без нового стека метрик. Перед Prometheus поставили мультитенантный прокси, который отдает каждой команде только ее данные. Доступ настраивается через объект MetricAccess в Kubernetes.

В карточках — четыре интересных детали, а в статье — весь разбор архитектуры, изоляции метрик и способов, которые помогут находить неэффективные GPU.

📃 Читайте статью на Хабре →

🆕 В Managed Containers появился аддон HAMi. С его помощью одну GPU можно разделить между несколькими нагрузками и для каждой задать долю видеопамяти и вычислительных ресурсов.

HAMi помогает:

🔵 запускать несколько нагрузок на одной GPU
🔵 распределять между ними видеопамять и вычислительные ресурсы
🔵 повышать загрузку GPU
🔵 не устанавливать и не сопровождать middleware для GPU sharing самостоятельно.

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

⚙️ Стабильная работа ИИ в продакшене требует больше, чем просто запустить модель в Kubernetes.

По данным CNCF, 66% организаций, которые размещают генеративные ИИ-модели, используют Kubernetes для всех или части инференс-нагрузок. При этом ежедневно развертывают ИИ-модели только 7%.

Разобрали, что нужно учесть платформенным командам, чтобы Kubernetes стал полноценной средой для ИИ-нагрузок. На карточках — пять признаков готовой платформы.

📃 Больше подробностей — на Хабре →

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

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

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

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

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

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

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

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

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

❓Как использовать на 50% меньше дисковой емкости без снижения надежности

При тройной репликации каждый объект хранится в трех экземплярах, поэтому на 1 ПБ данных требуется 3 ПБ дисковой емкости. Такой подход к отказоустойчивости заметно увеличивает требования к инфраструктуре и ее стоимость.

В VK Object Storage для On-Premise теперь доступен Erasure Coding x1,75. Вместо нескольких полных копий система хранит данные вместе с дополнительными фрагментами для восстановления.

Что это меняет для бизнеса:

🔹 на 1 ПБ полезных данных требуется около 1,75 ПБ дисковой емкости вместо 3 ПБ при тройной репликации

🔹 в одном из реализованных сценариев при эквивалентной надежности требуемая емкость составила 5,3 ПБ вместо 10,5 ПБ

🔹 Erasure Coding позволяет пережить одновременный отказ как минимум двух дисков, а в конфигурации из трех и более ЦОДов при аварии одного дата-центра данные остаются доступны для чтения.

Для компаний с крупной On-Premise инфраструктурой это позволяет иметь меньше дисков и серверного оборудования в закупке без снижения требований к надежности. Особенно эффект заметен для банков, госсектора и других организаций, работающих с большими объемами данных.

Есть и еще одна практическая польза: Erasure Coding входит в обязательные требования многих тендеров и RFI на S3 On-Premise. Без его поддержки решение в части закупок не проходит технический отбор.

Теперь этот сценарий поддерживает и VK Object Storage.

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

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

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

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

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

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

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

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

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

Во втором поколении Managed Containers меняется граница ответственности между пользователем и платформой.

Системный слой размещается в сервисном проекте и обслуживается VK Cloud. Пользователь управляет приложениями и данными, обновляет версию Kubernetes и аддоны.

➡️ Подготовили разбор архитектуры второго поколения, встроенных сервисов, доступных инструментов и порядка миграции с первого поколения на второе.

Главное собрали на карточках. Подробнее — в статье VK Cloud.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

За второй квартал Managed Kubernetes получил новое поколение сервиса, поддержку Cilium и Kubernetes 1.34, новые аддоны и обновления безопасности.

Собрали главное в карточках. Скорее листайте 👆

💙 Ingress в Kubernetes: выбор контроллера, маршрутизация и TLS

Ingress кажется простой точкой входа в Kubernetes, пока не появляются дополнительные маршруты, TLS и настройки конкретного контроллера.

Разобрали три важных аспекта:
🔵 как этот ресурс обрабатывает трафик
🔵 что учитывать при маршрутизации и TLS
🔵 откуда берется зависимость от контроллера.

👉 Подробнее — в нашем блоге

В Managed Kubernetes доступна новая версия Kubernetes 1.35.

Обновление приносит актуальные исправления безопасности и стабильности, улучшает работу платформы и снижает риски эксплуатации, а также упрощает дальнейшие обновления и использование новых возможностей экосистемы Kubernetes.

Почему стоит обновиться

🔹Работая на актуальной версии, вы снижаете риски, связанные с уязвимостями и нестабильностью устаревших версий оркестратора.

🔹Упрощается переход на будущие обновления и новую функциональность экосистемы Kubernetes.

❗️Важно: на старте новая версия доступна кластерам, которые уже работают на новой версии оркестратора. Для кластеров на старой версии обновление выйдет позже.

Подробности — по ссылке.

🤔 Как защитить Kubernetes-кластер от сбоев и ошибок конфигурации?

Для production-кластеров, состояние которых важно быстро восстановить, в Managed Kubernetes доступен аддон Velero. Он настраивает резервное копирование workloads, namespace и Kubernetes-объектов, а копии хранит в VK Object Storage.

С какими задачами поможет Velero?

🔹Резервное копирование: сохраняйте состояние workloads, namespace и других Kubernetes-объектов.

🔹Быстрое восстановление: возвращайте кластер в рабочее состояние после сбоев, ошибок конфигурации, неудачных релизов или инцидентов с данными.

🔹Надежное хранение: бэкапы лежат в отдельном объектном хранилище VK Object Storage независимо от жизненного цикла кластера.

🪄 Как активировать?

Установите аддон velero во вкладке «Аддоны» кластера в панели управления VK Cloud, указав бакет и ключи доступа к VK Object Storage.

👉 Подробности — по ссылке.

Уже сегодня в 19:00 встречаемся на Cloud Sessions!

С нетерпением ждем начала и готовимся обсуждать кейсы вместе с инженерами из VK Cloud и Dodo Engineering.

Спикеры:
🔹 Владимир Вдовин, Principal Engineer VK Cloud — о steal time и планировщике ядра на eBPF
🔹 Юлия Санжаровская, инфраструктурный архитектор VK Cloud — о том, как масштабировать облако в условиях дефицита серверного железа
🔹 Павел Притчин, CTO Dodo Engineering — о том, как удалось ускорить разработку в 1,5 раза с помощью агентов

💻 Подключайтесь к онлайн-трансляции по ссылке.

VK Cloud выпустила VK Registry 26.2.0.

В новой версии появился модуль управления безопасностью артефактов (Security Manager). Он позволяет подключать экземпляры VK Registry
, задавать политики блокировки артефактов и на их основе ограничивать операции.

С помощью Security Manager можно автоматизировать проверки безопасности артефактов прямо на экземпляре VK Registry.

🌟Проверка проходит локально, что ускоряет процессы разработки и снижает нагрузку на сетевую инфраструктуру
🌟Для анализа используется база уязвимостей из шести источников — так можно надежнее выявлять угрозы в артефактах
🌟Результат проверки отображается в Security Manager
🌟Если версия не соответствует требованиям политики, система может автоматически заблокировать дальнейшие действия с ней.

Это снижает объем ручных проверок и помогает выстроить процессы безопасной разработки.

👉 Читайте подробности о VK Registry 26.2.0 в документации.

На демо LLM-инференс может работать быстро, а под реальной нагрузкой — получить растущий p99, очередь запросов и внезапный OOM.

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

В статье разбираем четыре механизма такой деградации:

🌟 фрагментация KV-cache
🌟 нехватка памяти на длинном контексте
🌟 блокировка очереди при батчинге
🌟 разрыв между p50 и p99.

👀 Главное — этот процесс можно заметить заранее. Средней задержки для этого мало. Нужны gpu_cache_usage, p99 задержки между токенами, глубина очереди, счетчик вытеснений и preemption.

Отдельно показываем, как подобрать параметры батчинга под свой трафик и почему оптимизации вроде PagedAttention не отменяют наблюдения за памятью и хвостовыми задержками.

В статье есть примеры расчетов для разных контекстов и скрипты для проверки KV-кэш, OOM, батчинга и хвостовой латентности на собственной инфраструктуре.

👉 Читайте на Хабре