Вокруг Kubernetes в VK

📣 27 августа в Москве проведем Cloud Sessions — технический митап про облака, платформы и инфраструктуру. В программе — доклады с реальными инженерными кейсами, с которыми сталкиваются разработчики и архитекторы при развитии облачной инфраструктуры. Например, вы узнаете, как команда VK Cloud написала свой планировщик ядра на eBPF и победила steal time в облаке. После докладов вас ждет афтепати с пиццей и нетворкингом: в кулуарах можно обсудить то, что не уместилось на слайдах, и задать вопросы спикерам напрямую. Кому будет полезно:  🔹 Инженерам разработки облачных и сетевых сервисов, платформенным разработчикам 🔹 DevOps- и SRE-инженерам, SysOps, системным администраторам и архитекторам 🔹 Руководителям отделов разработки облачных, сетевых и инфраструктурных сервисов. Когда и где 🗓️ 27 августа с 18:00 до 00:00 📍 Ленинградский проспект, 39, бизнес-центр Skylight, Б1 Митап бесплатный, но необходима регистрация. ☝️ Количество мест ограничено 📬 Мы в МАХ

🧩 Три мастер-ноды и несколько реплик еще не делают Kubernetes-кластер отказоустойчивым. Сервис может пережить отказ одной ноды или потерять данные из томов. В статье разбираем, как распределять реплики между зонами с topologySpreadConstraints, зачем нужен PodDisruptionBudget и почему снапшот etcd не заменяет бэкап данных приложений. Отдельно показываем, что берет на себя Managed Kubernetes, а что остается зоной ответственности команды. 👉 Читайте в блоге → 📬 Мы в MAX

❓ Почему оператора недостаточно для on-prem DBaaS Инструменты Kubernetes умеют создавать базы данных, настраивать репликацию, масштабирование и переключение на резервную реплику. Но для DBaaS этого мало: разным командам нужны единые правила обновлений, восстановления из бэкапов и соблюдения политик. Когда каждая команда самостоятельно выстраивает эти процессы, решения начинают дублироваться: у команд появляются свои API, правила обновлений, восстановления и эксплуатации. 🤝 Что должно быть между командой и инфраструктурой Чтобы не собирать отдельное DBaaS-решение для каждой команды, нужен слой абстракции между запросом разработчика и конкретным способом создания базы. Он отделит запрос на базу от способа ее создания. Разработчик описывает нужный сервис через привычные ресурсы Kubernetes. Платформенная команда выбирает, какой бэкенд выполнит этот запрос: оператор, собственная автоматизация или управляемый облачный сервис. При этом бэкенд можно менять, не заставляя разработчиков осваивать новый способ работы. ✅ Что добавляет Klutch.iо Open source-проект Klutch.iо адаптирует модель service broker для Kubernetes. Разработчики создают запросы в локальных кластерах, а платформенная команда централизованно выбирает способ их выполнения и нужный бэкенд. В статье разбираем, почему модель Open Service Broker не закрепилась в Kubernetes и как Klutch.iо пытается приблизить экосистему к общему стандарту DBaaS. Читайте 👉 на Хабре 📬 Мы в MAX

Когда Kubeflow не хватит для диагностики 🧠 Когда notebook зависает или задача обучения завершается с ошибкой, оператору важно увидеть, что происходит с ресурсами Kubernetes. Интерфейс Kubeflow не всегда показывает эти детали, поэтому приходится переходить к kubectl и отдельно проверять Pod. Упростить диагностику помогает плагин Headlamp Kubeflow. Он показывает ресурсы Kubeflow и связанные данные Kubernetes в одном интерфейсе: причины ошибок, лимиты, состояния Pod и связи между объектами. Например, в Headlamp можно проверить Pod notebook-сервера, посмотреть лучший Trial в Katib или сравнить версии пайплайна через YAML-дифф. Плагин сам определяет установленные компоненты Kubeflow и добавляет только нужные разделы. ➜ Как установить плагин и разбирать AI/ML-нагрузки без переключения между дашбордами и kubectl, читайте в блоге VK Cloud. 📬 Мы в MAX Часто ли вам приходится переключаться на kubectl при работе с Kubeflow? ❤️ — почти каждый раз 🔥 — иногда, для деталей 👌 — стараюсь обходиться без него

🧩 POD пересоздался, IP поменялся, а сервис все равно должен отвечать по тому же имени. Сетевую модель Kubernetes определяют три правила: у каждого POD’а свой IP, POD’ы общаются без NAT, а адресное пространство кластера плоское. Эту модель реализует CNI, а поверх нее работают сервисы, DNS и сетевые политики. В новой статье разбираем сетевую модель снизу вверх: от IP-адресов POD’ов и ClusterIP до CoreDNS, LoadBalancer и сетевых политик. 🔎 Отдельно рассматриваем частую ошибку с NetworkPolicy: после включения default-deny POD перестает резолвить DNS-имена, потому что в исходящем трафике не разрешили обращения к DNS по порту 53. Еще из текста узнаете: 🔵чем отличаются ClusterIP, NodePort, LoadBalancer и ExternalName 🔵за что отвечает CNI 🔵как работает сеть в Managed Kubernetes VK Cloud. ➜ Читайте статью в блоге VK Cloud. 📬 Мы в MAX

🔐 За считанные дни пароль от базы может оказаться сразу в нескольких местах: в 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. 🔗 Мы в MAX

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

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