Вокруг Kubernetes в VK

🔐 За считанные дни пароль от базы может оказаться сразу в нескольких местах: в Kubernetes Secret, CI/CD-переменной, локальном .env и на Confluence-странице. Пока окружений мало, за всем уследить еще можно, но в проде это сделать сложнее: значения нужно ротировать, доступы — разграничивать, а по каждому обращению к секрету желательно понимать, кто и когда его открывал. И чем больше копий секрета расходится по системам, тем выше шанс, что однажды он окажется «рассекреченным». Нативный Kubernetes Secret хранит данные в base64: это кодирование, а не шифрование. Если для etcd не включен encryption at rest, пароль от базы или токен внешнего API представлен на дисках control plane открытым текстом. Как эту проблему решает ESO External Secrets Operator помогает хранить исходные значения вне кластера — в централизованном хранилище. Значения живут в KMS, а ESO сам создает из них обычные Kubernetes Secret и обновляет их по расписанию. Для приложения схема не меняется: оно по-прежнему читает переменную окружения или подключенный volume. Чтобы все это настроить, нужно разобраться в нескольких сущностях ESO:

🔵 SecretStore — подключение к конкретному хранилищу секретов 🔵 ClusterSecretStore — то же подключение, но доступное из всех namespace 🔵 ExternalSecret — манифест, который говорит, какой секрет забрать и как назвать его в кластере 🔵 refreshInterval — как часто ESO проверяет хранилище на обновления.

Что дает Managed Kubernetes VK Cloud В Managed Kubernetes VK Cloud ESO ставится как аддон прямо из панели управления. KMS вынесен отдельно от кластеров, доступ к нему настраивается через IAM, а все обращения к секретам попадают в аудит-лог. Права стоит сразу выдавать по least privilege: отдельный сервисный аккаунт и отдельный префикс на каждое окружение, например prod/*, staging/*, dev/*. В итоге в Git остаются только ссылки на секреты, значениями в KMS управляет SecOps, а кластер видит лишь то, к чему у него есть доступ. Что проверить при ошибке синхронизации Если после деплоя ExternalSecret вместо SecretSynced показывает SecretSyncedError — первым делом стоит проверить события. Типичные причины — неверный путь к секрету в KMS, права ServiceAccount или недоступный endpoint. Больше о нативном Secret в etcd, Sealed Secrets, self-managed Vault и ESO с KMS VK Cloud читайте в блоге VK Cloud. 📬 Мы в MAX

🗂 Приложение легко масштабировать, пока оно не начинает работать с файлами. Представьте: интернет-магазин увеличивает сервис загрузки фотографий с 2 до 10 POD’ов. Покупатель добавляет снимок через POD № 3, а POD № 7 его не видит — файл остался на локальном диске первой реплики. Стандартные способы хранения решают проблему только отчасти. EmptyDir теряет данные при перезапуске POD’а, блочный диск в режиме ReadWriteOnce доступен только с одной ноды, а для NFS или Ceph нужна отдельная инфраструктура. В новой статье разбираем, как организовать общее файловое пространство с помощью S3-CSI в VK Cloud Managed Kubernetes. 🔎 S3-CSI монтирует бакет Object Storage в контейнер как обычный каталог Все POD’ы, подключенные к одному PVC в режиме ReadWriteMany, работают с одними и теми же файлами. При масштабировании Node Plugin монтирует бакет на новой ноде, поэтому дополнительная реплика может сразу работать с уже загруженными данными. Менять код приложения и подключать S3 SDK не требуется. 🛠 Файлы при этом хранятся независимо от жизненного цикла кластера Rolling update, перезапуск POD’ов или перенос нагрузки на другие ноды не затрагивают содержимое бакета. Object Storage автоматически растет вместе с объемом данных, а оплата рассчитывается по фактически занятому месту. ➜ Как устроен S3-CSI, чем статическое провизионирование отличается от динамического и как подключить бакет через PV и PVC, читайте в блоге VK Cloud. 📬 Мы в MAX

🧩 Kubernetes становится понятнее, когда вы перестаете учить его по шпаргалке Первые команды запоминаются быстро: kubectl get pods, kubectl apply, kubectl logs. Но однажды Pod не стартует, Service не отвечает, а Deployment пересоздает Pod, и списка команд уже недостаточно. В новой статье разбираем маршрут для разработчика: от локального кластера на ноутбуке до Managed Kubernetes в облаке. 🔎 Сначала нужно понять, что происходит внутри кластера. Pod запускает контейнеры, Deployment следит за репликами и обновлениями, Service дает приложению стабильную точку доступа. Когда понятны связи между сущностями, отладка перестает быть перебором команд: вы знаете, где искать проблему и зачем переходить от get к describe и logs. 🛠 Следующий шаг — пройти путь от локальной среды до облака. Для первых экспериментов подойдет Minikube, для разработки, тестов и CI/CD — kind. Локальный кластер можно без риска ломать, пересоздавать и использовать для изучения механики Kubernetes. Когда проекту понадобятся отказоустойчивость, масштабирование и SLA, можно перейти в Managed Kubernetes. Рабочий процесс при этом сохранится: те же манифесты, тот же kubectl apply и привычные инструменты отладки. ➜ Полный текст статьи читайте в блоге VK Cloud. 📬 Мы в MAX

🧷 Запиннили зависимости? Проверьте, что workflow подтягивает дальше Даже SHA-пиннинг не закрывает все риски: workflow может подтянуть вредоносную зависимость во время выполнения. В CI/CD нужно контролировать доступы к сборке и код, который она подтягивает во время работы: GitHub Actions, контейнерные образы, Go-модули. Продолжаем рассказывать о защите CI/CD-конвейера. В прошлый раз говорили о том, кто может запускать сборки и какой CI-код разрешено исполнять. Сейчас речь пойдет про уровень зависимостей: какой код эти сборки подтягивают и как убедиться, что его не подделали. 🔎 Как Cilium контролирует зависимости в CI/CD: ⭐ фиксирует GitHub Actions по полному 40-символьному SHA-коммиту, чтобы изменение или подмена тега не привели к загрузке другого кода; ⭐ фиксирует контейнерные образы по @sha256-дайджесту, чтобы сборка использовала конкретное неизменяемое содержимое; ⭐ обновляет зависимости через Renovate: бот поднимает SHA и открывает отдельный PR; ⭐ ждет пять дней перед обновлением, чтобы скомпрометированную версию успели обнаружить и удалить до обновления; ⭐ вендорит Go-модули, проверяет согласованность go.mod, go.sum и vendor/ и отправляет изменения зависимостей на ревью; ⭐ проверяет workflow с помощью CodeQL и actionlint еще до ручного ревью. ⚠️ Но у пиннинга есть слепое пятно Запинненный по SHA action может ссылаться на транзитивные зависимости по тегам. Они разрешаются во время выполнения и остаются незаметными. В 2026 году GitHub планирует добавить секцию dependencies для фиксации всех зависимостей по SHA. Автоматически сливаются только обновления из разрешенного списка, остальные проходят ревью. Форкать все сторонние actions слишком затратно: форки нужно синхронизировать, иначе они сами становятся уязвимостью. Поэтому Cilium фиксирует зависимости, контролирует обновления и проверяет workflow статическим анализом. 🔹 Подробнее об этом читайте на Хабре — в новой статье о защите CI/CD 📬 Мы в MAX

🔐 Защитите учетные данные приложений с помощью аддона External Secret Operator Мы упростили управление секретами в Managed Kubernetes. Теперь для защиты паролей, ключей доступа и токенов в кластерах Kubernetes доступен аддон External Secret Operator. Он связывает контейнеры с централизованным облачным хранилищем секретов VK Cloud и избавляет от переноса конфиденциальных данных вручную. 💪 В чем преимущества: 🌟Секреты хранятся в изолированном специализированном хранилище. 🌟Приложения в кластере безопасно получают актуальные пароли для работы с внешними сервисами, базами данных или S3-хранилищами. 🌟Риск утечки данных из-за человеческого фактора сведен к минимуму — секреты передаются по защищенным внутренним каналам платформы. 👉 Подключите External Secret Operator в панели управления Managed Kubernetes при создании или настройке кластера. 📬 Мы в MAX

🏗 Когда вы в последний раз документировали архитектуру своего проекта? Обычно руки доходят до этого перед аудитом или после инцидента. VK Cloud дает повод сделать это заранее — и получить бонусы и ревью от практикующих архитекторов. Мы проводим конкурс «Архитектура мечты» для тех, кто проектирует или поддерживает облачную инфраструктуру: архитекторов, DevOps- и SRE-инженеров, техлидов и CTO. Опишите «идеальную» архитектуру своего облачного проекта и отправьте ее на оценку жюри — команды архитекторов VK Cloud. 💙 Все участники получат 5 000 ₽ бонусами от VK Cloud 💙 Лучший проект — 1 000 000 ₽ бонусами 🏆 Что будем оценивать: 30% — надежность 20% — безопасность 15% — комплаенс 15% — эффективность использования ресурсов VK Cloud 10% — экономическая обоснованность 10% — понятность и полноту описания 🧑‍💻 Как участвовать: ⭐ зарегистрируйтесь на платформе VK Cloud ⭐ подготовьте PDF-файл с описанием архитектуры ⭐ отправьте ID и файл через страницу конкурса Мы приглашаем к участию только юридические лица и ИП. Отправить заявку и получить бонус можно один раз. Прием заявок открыт до 1 октября 2026 года включительно. Итоги конкурса подведем 12 октября. ➡️ Подайте заявку на странице конкурса 🔗 Мы в MAX

🤖 Почему ИИ-сервисы все чаще запускают в Kubernetes? Потому что модель не работает в вакууме. API, хранилища с датасетами, пайплайны обучения, сервисы инференса, мониторинг и права доступа — управлять всем этим удобнее в одном контуре: с едиными правилами масштабирования. ⛓️ Kubernetes как раз дает такой слой управления. Он помогает распределять мощности между задачами, подключать S3-хранилища, изолировать GPU-ноды от непрофильной нагрузки и не держать ресурсы включенными без необходимости. ⭐️ Но остается вопрос: кто будет обслуживать сам кластер? В нашем обновленном Managed Kubernetes эту часть берет на себя облачная платформа: 🔹 Кластеры и аддоны разворачиваются за несколько кликов 🔹 При сбоях сервис автоматически восстанавливает ноды 🔹 Для критичных нагрузок доступны отказоустойчивые конфигурации с тремя или пятью мастер-нодами 🔹 Автомасштабирование, Spot-инстансы и раздельный биллинг помогают точнее управлять затратами. ➡️ Подробностями в нашем блоге делится Евгений Власов, руководитель команды solution sales VK Cloud.

Kubernetes гибкий, пока кластеров не становится слишком много 🤯

Сначала у команды появляется один отдельный кластер. Потом еще один — под новое окружение. Потом еще несколько — потому что у продукта свои требования.

👆 Так компания незаметно приходит к десяткам Kubernetes-кластеров, которые нужно обновлять, мониторить, защищать и оплачивать отдельно. Multitenancy помогает решить эту задачу: несколько команд используют общую инфраструктуру, но остаются изолированными друг от друга. 🔎 Чтобы общий кластер не превратился в источник рисков, нужно несколько уровней контроля: • RBAC — разграничивает доступы внутри namespace • NetworkPolicies — ограничивают сетевое взаимодействие между подами • ResourceQuotas и LimitRanges — задают лимиты потребления ресурсов • Pod Security Standards — ограничивают небезопасные настройки подов Перевели статью о том, какие модели Multitenancy используют в Kubernetes. А еще — как проектировать namespace, настраивать изоляцию, считать затраты по командам и не утонуть в операционном хаосе. ➜ Читайте статью на Хабре 🔗 Мы в MAX

⚡️ Почему GPU-нагрузки плохо масштабировать по CPU

Для vLLM, Triton, batch-инференса и обучения моделей стандартных метрик CPU и памяти часто недостаточно.

Основная нагрузка уходит в GPU, поэтому масштабирование лучше строить по сигналам ускорителя: • утилизация GPU • использование VRAM • температура • энергопотребление Для этого KEDA нужно передать метрики, которых у нее нет из коробки. В статье разобрали, как добавить их через внешний скейлер. 🔧 Как это работает: • на GPU-нодах запускается DaemonSet • он читает локальные метрики через NVML • передает их в KEDA по gRPC через ExternalScaler • KEDA управляет масштабированием нагрузки через HPA Для типовых сценариев есть готовые профили: vllm-inference, triton-inference, training и batch.

Например, vLLM deployment можно масштабировать по использованию памяти GPU и уводить в scale-to-zero при простое.

➜ Читайте на Хабре, как собрать внешний GPU-скейлер для KEDA и настроить автоскейлинг GPU-нагрузок в Kubernetes 🔗 Мы в MAX

Войдите в экспертный совет АОТ 🔝

АОТ — это Ассоциация облачно-ориентированных технологий, которую основали VK Cloud, Yandex Cloud и «Флант», чтобы популяризовать Cloud Native-технологии на российском рынке.

🚀 Сейчас АОТ собирает экспертный совет: это девять ведущих практиков в области облачно-ориентированных технологий и Kubernetes. Они будут определять технологическую повестку ассоциации, участвовать в запуске отраслевых инициатив, технической валидации подходов и практик. В экспертный совет приглашают профессионалов, желающих влиять на развитие технологий и обладающих практическим опытом в cloud-native и Kubernetes. Важно, чтобы у кандидатов был подтвержденный экспертный вклад в индустрию — статьи, выступления, open-source-проекты, а также готовность уделять 10-20 часов в месяц инициативам и задачам совета 📚 Подробнее про совет и требования к кандидатам — на сайте ассоциации: заходите, изучайте и подавайте заявки до 22 июля. Результаты отбора появятся в официальных каналах АОТ в августе 2026 года.

Ускорьте ИИ-нагрузки на 15% С Managed Kubernetes на физических серверах Managed Kubernetes автоматизирует развертывание и обслуживание приложений — вам не придется вручную следить за инфраструктурой и держать для этого отдельную команду. 👆 Раньше такие кластеры работали поверх виртуальных машин, теперь — прямо на «железе». Платите только за полезные вычисления и используйте всю мощность видеокарт. Новое поколение сервиса Managed Kubernetes рассчитано на экстремальные нагрузки: один кластер выдерживает до 55 000 микросервисов одновременно с гарантированной доступностью 99,95%. 🔧 Настройку, масштабирование и обновление можно запускать параллельно, что сокращает время вывода продуктов на рынок и снижает объем ручной работы. Такое решение отдает под расчеты 100% мощности графических процессоров и ускоряет работу с ИИ-нагрузками на 15%.

Запускать высоконагруженные и ИИ-приложения можно в четырех зонах доступности VK Cloud, полностью контролируя ресурсы и сохраняя привычное удобство облака. Инфраструктура отвечает требованиям 152-ФЗ, стандартам ISO и PCI DSS, а дата-центры аттестованы по 21 приказу ФСТЭК.

➜ Протестируйте Managed Kubernetes по ссылке 🔗 Мы в MAX

Если вы еще не видели сегодняшний доклад Саши — вы знаете, где его искать 👀

Мы входим в эпоху Cloud-Native AI 🤖 Что ее характеризует? • Managed k8s c GPU из коробки • автомасштабирование GPU-нод • MIG, vGPU, разделение по времени использования • S3 CSI для больших датасетов • ZeroOps для ML-платформ Как в соответствии с этим меняется инфраструктура для ИИ-нагрузок? Какое место занимает в ней Managed Kubernetes? Об этом Александр Прохоров, эксперт команды Developer Productivity VK Cloud, рассказал на VK Cloud Conf 2026. Смотрите запись трансляции на сайте конференции. 🔗 Мы в MAX

⏰ VK Cloud Conf стартует через 10 минут Делимся ссылками на трансляцию: • VK Видео • Сайт VK Cloud • CNews — на главной странице • Дзен — в теме «ИТ» Ждем вас на площадке и онлайн 💙

В Managed Kubernetes теперь доступен аддон S3-CSI — решение для проектов, которые работают с большим объемом пользовательских или системных файлов 🔗 Он позволяет подключить S3-хранилище напрямую к приложению в качестве диска. С какими задачами поможет S3-CSI: ➕Упростить масштабирование: вы сможете управлять количеством подов без риска потерять данные благодаря одновременной работе с общими файлами в S3. ➕Снизить затраты: хранить файлы, архивы и копии в S3 значительно дешевле, чем на стандартных дисках. ➕Защитить от нехватки места: безлимитное объектное хранилище избавляет от необходимости вручную расширять диски при росте объема данных. ➕Обеспечить постоянный доступ: файлы изолированы от жизненного цикла контейнеров и остаются на месте даже при перезапуске всех подов. ☑️ Как активировать: выберите S3-CSI в списке расширений при создании или настройке кластера в панели управления VK Cloud. Узнайте, как установить и настроить аддон ➜ 🔗 Мы в MAX

🧩 Pod не стартует? Проверьте env от Service Service в Kubernetes дает стабильный доступ к группе Pod. При этом данные о Service по умолчанию добавляются в Pod как переменные окружения. Эта деталь может неожиданно повлиять на запуск приложения.

Например, Service с именем server сгенерирует env SERVER_PORT. Если приложение ждет в этой переменной число, а получает строку вида tcp://<ClusterIP>:<port>, запуск может завершиться ошибкой.

Еще один сценарий — большое количество Service и портов в Namespace.

Набор env разрастается, контейнер упирается в лимит ядра и падает с ошибкой: argument list too long.

Поэтому при странных ошибках запуска стоит проверить Service в Namespace и env, которые попадают в Pod. 💙 Что помогает снизить риск: • отключать автоматические env от Service через enableServiceLinks : false • явно задавать критичные env в манифестах • ограничивать количество Service и портов • защищать Service kubernetes в namespace default от изменений В статье разобрали, как Service влияет на env в Pod, почему это может ломать приложения и какие настройки помогают защититься. ➜ Читайте статью на Хабре 🔗 Мы в MAX

Александр Прохоров, эксперт команды Developer Productivity VK Cloud, приглашает на VK Cloud Conf 2026 💙 17 июня в Москве обсудим, как Managed Kubernetes в VK Cloud превращается в высокопроизводительную платформу для ИИ-нагрузок. Рассмотрим автоматизацию администрирования, эластичность и масштабирование, работу с большими массивами данных. Регистрируйтесь на конференцию ➜ 🔗 Мы в MAX

🛡️ CI/CD может стать точкой входа в атаку

Если злоумышленник доберется до сборочного пайплайна, проблема может попасть дальше — в контейнерные образы, Helm-чарты и пользовательские кластеры.

👆 Для Cilium это особенно критично. Он работает в сетевом пути уровня ядра Linux и используется в Kubernetes-кластерах для сетевой связности, политик безопасности и наблюдаемости трафика. Про возможности Cilium в Managed Kubernetes VK Cloud рассказывали здесь ➜ В статье разбираем, как Cilium защищает цепочку поставки проекта: от запуска CI-workflow до проверки релизных артефактов. ⚙️ Что делает на практике: • ограничивает, кто может запускать CI-workflow • разделяет доверенный код и код из pull request • закрепляет GitHub Actions по SHA, а образы — по digest • изолирует production-учетные данные от CI-сборок • подписывает релизные образы и Helm-чарты через Sigstore Cosign Так каждый уровень снижает зону поражения, если один из участков пайплайна окажется скомпрометирован. ➜ Читайте на Хабре, как Cilium защищает CI/CD 🔗 Мы в MAX

Автоматизируйте релизы в Managed Kubernetes 🛠 Для команд с активной разработкой в Managed Kubernetes на платформе VK Cloud доступен аддон Argo CD. Он автоматизирует доставку кода из репозиториев в кластер, избавляя от рутины при развертывании приложений. Какие задачи решает Argo CD: ➕ Ускоряет выкатку обновлений. Как только код одобрен, изменения сразу применяются в кластере без участия инженеров. ➕ Защищает продакшн от сбоев. Если новое обновление вызвало сбой в приложении, вы мгновенно возвращаете кластер к стабильной версии через историю изменений в репозитории. ➕ Сверяет состояние кластера с эталоном в Git и сам исправляет случайные ручные правки. Как начать использовать:

Выберите Argo CD при создании или настройке кластера Managed Kubernetes в панели управления VK Cloud — он подключится автоматически.

➜ Читайте подробнее в документации 🔗 Мы в MAX