❓ Почему оператора недостаточно для 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

🧩 Три мастер-ноды и несколько реплик еще не делают Kubernetes-кластер отказоустойчивым. Сервис может пережить отказ одной ноды или потерять данные из томов.

В статье разбираем, как распределять реплики между зонами с topologySpreadConstraints, зачем нужен PodDisruptionBudget и почему снапшот etcd не заменяет бэкап данных приложений.

Отдельно показываем, что берет на себя Managed Kubernetes, а что остается зоной ответственности команды.

👉 Читайте в блоге →

📬 Мы в MAX

📣 27 августа в Москве проведем Cloud Sessions — технический митап про облака, платформы и инфраструктуру.

В программе — доклады с реальными инженерными кейсами, с которыми сталкиваются разработчики и архитекторы при развитии облачной инфраструктуры. Например, вы узнаете, как команда VK Cloud написала свой планировщик ядра на eBPF и победила steal time в облаке.

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

Кому будет полезно:

 🔹 Инженерам разработки облачных и сетевых сервисов, платформенным разработчикам

🔹 DevOps- и SRE-инженерам, SysOps, системным администраторам и архитекторам

🔹 Руководителям отделов разработки облачных, сетевых и инфраструктурных сервисов.

Когда и где

🗓️ 27 августа с 18:00 до 00:00
📍 Ленинградский проспект, 39, бизнес-центр Skylight, Б1

Митап бесплатный, но необходима регистрация.

☝️ Количество мест ограничено

📬 Мы в МАХ

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

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

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

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

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

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

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

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

📬 Мы в MAX

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

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

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

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

💬 Вопросы спикерам оставляйте в комментариях под этим постом. Будем собирать их по ходу встречи и передавать экспертам.

Если не успеем озвучить ваш вопрос во время митапа, спикеры ответят на него в чате после мероприятия 💙

📲 Мы в MAX

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

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

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

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

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

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

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

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

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

📬 Мы в MAX

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

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

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

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

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

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

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

📬 Мы в MAX

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

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

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

📬 Мы в MAX