AI-нагрузка пришла в прод: Serverless или Kubernetes?
Когда команда приносит очередную AI-фичу, инфраструктуре быстро приходится отвечать на вполне приземлённые вопросы: где её запускать, как масштабировать, что делать с GPU, состоянием и холодным стартом — и во сколько всё это обойдётся после выхода в прод.
Serverless выглядит удобным способом снять часть операционной нагрузки. Kubernetes даёт больше контроля, но вместе с ним добавляет сложность эксплуатации. Универсального выбора здесь нет: решение зависит от характера нагрузки, требований к задержкам, бюджета и того, насколько инфраструктурная команда готова управлять платформой самостоятельно.
21 июля в 20:00 на бесплатном уроке разберём, как сравнивать Serverless и Kubernetes для AI-ворклоадов и какие ограничения учитывать до того, как архитектурное решение превратится в дорогую миграцию. Отдельно посмотрим на холодный старт, работу с состоянием, поддержку GPU, масштабирование и гибридные сценарии.
Другие бесплатные уроки от экспертов по инфраструктуре, Linux, K8s, сетям, безопасности и наблюдаемости собрали в дайджесте.
Астрономический научный центр модернизировал оркестрацию космического мониторинга с помощью ITFB Group
Астрономический научный центр (АНЦ) завершил масштабную модернизацию своей управляющей платформы. Интегратором выступила компания ITFB Group, которая помогла центру перейти на более надёжную и масштабируемую инфраструктуру, автоматизировать процессы разработки и обновления, а также гарантировать безотказную доставку критически важных данных о космических объектах.
Платформа АНЦ обеспечивает оркестрацию множества процессов, связанных с обработкой данных наблюдений. По мере роста нагрузки существующая архитектура перестала в полной мере отвечать требованиям к отказоустойчивости и масштабированию. При большом количестве параллельных процессов возникали задержки, обновление системы выполнялось вручную, а отдельные события в исключительных случаях могли не доходить до конечных потребителей. Кроме того, используемая инфраструктура не обеспечивала автоматического восстановления сервисов при сбоях.
Специалисты ITFB Group провели аудит существующей платформы, выявили архитектурные ограничения и разработали новую целевую модель. В ходе проекта была внедрена современная инфраструктура на базе Kubernetes, которая автоматически восстанавливает сервисы после сбоев и позволяет гибко масштабировать систему по мере роста нагрузки. Для передачи данных между компонентами была внедрена промышленная система обмена сообщениями, обеспечивающая гарантированную доставку событий. Также команда автоматизировала процесс развертывания новых версий платформы: теперь изменения проходят путь от разработки до промышленной эксплуатации за считанные минуты без ручных операций.
Михаил Атрахимович, директор направления разработки ITFB Group, отметил: «В проекте для АО "АНЦ" мы использовали накопленный опыт создания высоконадежных платформ оркестрации бизнес-процессов. Основная сложность заключалась в том, что модернизацию необходимо было проводить без остановки уже работающей системы. В результате заказчик получил отказоустойчивую и масштабируемую платформу, готовую к дальнейшему развитию и увеличению объемов обработки данных».
Николай Савин, технический директор АО «АНЦ», добавил: «Сотрудничество с ITFB Group стало для нас важным этапом в развитии нашей системы оркестрации. Мы получили не только исправление текущих недочётов, но и чёткую дорожную карту, а также полный пакет эксплуатационной документации. Благодаря этому проекту мы уверены в надёжности и масштабируемости нашей платформы и готовы к дальнейшему расширению функционала».
В результате проекта АНЦ получил отказоустойчивую инфраструктуру enterprise-уровня, гарантированную доставку событий, автоматизированный релизный цикл и полный комплект эксплуатационной документации (мониторинг, алертинг, процедуры backup с RTO, регламенты при инцидентах).
Как на собственных серверах настроить систему сбора и хранения данных с датчиков и снизить нагрузку на команду эксплуатации
Собрать данные с датчиков — это полбеды. Главная боль — заставить Kafka, PostgreSQL и ClickHouse стабильно работать в приватном облаке без выгорания команды на Day-2-операциях и ручном масштабировании stateful-сервисов.
На вебинаре покажем, как на Deckhouse Kubernetes Platform (DKP) и managed-сервисах упаковать IoT-сценарии и аналитический контур в единую платформу, чтобы снизить стоимость эксплуатации и уйти от DIY-подхода к data-инфраструктуре.
Разберём схему event-driven-платформы и разделение операционного и аналитического контуров.
Покажем live-demo: ingest событий с датчиков, потоковая обработка и вывод в дашборды.
Проверим, как паттерны из умного дома масштабируются до промышленного IoT на DKP.
Разберём жизненный цикл data-сервисов (backup, scaling, observability) и то, сколько времени занимает их обслуживание.
Бонусы: промокод на все курсы Deckhouse Академии.
Будет полезно DevOps и SRE-инженерам, инфраструктурным и платформенным командам, enterprise-архитекторам и всем, кто строит IoT- и data-платформы в private cloud или on-prem.
Спикер — Дмитрий Гайворонский, менеджер по развитию направления Deckhouse Data Orchestration.
Релиз ≠ деплой: почему прод падает именно после обновлений
Большинство крупных инцидентов происходят сразу после релиза. Не во время нагрузочного теста, не в случайный вторник — а именно тогда, когда команда только что что-то выкатила и выдохнула. Почему так, если всё прошло тестирование?
В новом выпуске «В SREду на кухне»вместе с Артёмом Гетманским, техруком юнитов в Авито, и Андреем Мухиным, TechLead из MWS, разобрались: что вообще считается релизом, чем он отличается от деплоя — и как не превратить каждое обновление в рулетку.
Что на повестке
Оказывается, релиз может сломать прод даже без единой строчки нового кода — и это не баг, а особенность современных систем. Разбираем, как Feature Flags, Canary, Blue-Green и Rolling-стратегии помогают снизить риск, когда hotfix тоже считается релизом и что с этим делать, и как error budget влияет на то, насколько смело команда вообще решается катить изменения.
Отдельно досталось вопросу, должны ли SRE участвовать в продуктовых релизах — и у участников выпуска на этот счёт нашлись весьма конкретные мнения.
Подключайтесь к вебинару — покажем, как автоматизировать управление сложной инфраструктурой
Когда часть сервисов находится в облаке, а остальное — в изолированных контурах, доставка серверного ПО и контроль лицензий превращаются в настоящий квест для команды DevOps.
На вебинаре расскажем, как собрать весь зоопарк решений в единую систему с помощью MWS B2B Store. Разберем деплой инсталляций, когда разные ноды находятся на разных инфраструктурных провайдерах, доставку и обновления в закрытых контурах, версионирование и распространение внутренних и внешних решений.
В прямом эфире в режиме демо покажем:
Деплой сервисов (VMware + K8S) для разных сред, имплементацию Terraform as a service.
Автоматическое развертывание в изолированные контуры: от стандарта упаковки до «раскатки» в гибридную инфраструктуру.
Как управлять лицензиями на серверное ПО и контролировать, кто, где и сколько использовал.
Работу с инстансами из разных инфраструктур в едином окне: мониторинг, аудит и управление жизненным циклом.
Будет полезно CTO, DevOps, директорам по инфраструктуре и тимлидам инфраструктурных команд.
📅 Когда: 30 июня в 11:00 мск.
📍 Где: онлайн. Зарегистрируйтесь, подключайтесь и задавайте вопросы нашим экспертам в чате трансляции.
Подборка материалов, которые помогут снизить стоимость, стабилизировать прод и перестать гадать с ресурсами
Среди читателей Хабра много ML‑инженеров, дата‑сайентистов и дата‑инженеров — и мы, как команда провайдера облачных и ИИ-сервисов, догадываемся, где у вас чаще всего болит. Ниже подборка материалов, которые помогут в решении задач: чуть ускорить, чуть удешевить, чуть упростить жизнь в проде.
👨💻 ML/DS‑инженеры и бэкенд
Боль №1
Суть: вы крутите LLM в проде, токены стоят денег, контекст забивается громоздким JSON, а латентность растет. Что делать: прочитать статью — как практическое руководство по переходу с JSON на компактный TOON‑формат для структурированных ответов. Почему: в ряде кейсов можно сэкономить до ~40% токенов, но есть нюансы. Формат лучше работает при небольшой вложенности (3–4 уровня) и однородных массивах. Для плоских данных чаще выгоднее CSV. Плюс потребуется свой парсер/SDK — это усложняет дебаг и интеграцию.
Боль№2
Суть: нужно обогатить поисковую выдачу или интерфейс LLM‑функциональностью, но непонятно, как выдержать нагрузку и не превратить кластер в черную дыру для бюджета. Что делать: взять на вооружение материал от Avito Tech — эдакий «рентген» продакшен‑архитектуры с LLM/мультимоделями под серьезной нагрузкой. Почему: хороший слепок боевой системы с vLLM и LoRA, организацией GPU‑кластера, схемой запросов и мониторинга качества. Учитывая масштабы, команду и бюджеты Avito, «копировать-вставить» вряд ли получится, но по крайней мере есть опорная схема, как декомпозировать сервисы, и на какие метрики смотреть при проектировании.
👨💻 Data Science, MLOps, DevOps
Боль №3
Суть: модели живут в «ручных» скриптах, развертывание нестабильно, автоскейлинг либо отсутствует, либо работает хаотично. Не всегда получается договориться с коллегами о процессе вывода из ноутбуков в прод, который бы всех устроил. Что делать: читать нашу статью, где разбирается жизненный цикл ML‑модели в Kubernetes. Почему: показана связка контейнеризации, CI/CD и деплоя с учетом ML‑нагрузок. Это не универсальный рецепт (пример завязан на инфраструктуру Cloud.ru), но помогает синхронизировать ожидания между DS и MLOps, чтобы было от чего оттолкнуться.
👨💻 ML‑инженеры и исследователи
Боль №4
Суть: эксперименты падают из-за CUDA out-of-memory, приходится наугад крутить размер батча, длину контекста и конфигурацию кластера. Каждый запуск — лотерея и потерянные GPU‑часы. Что делать: читать перевод зарубежной статьи с разбором оценки потребления памяти на примере GRPO. Почему: объясняет, из чего складывается потребление памяти и как прикинуть конфигурацию до запуска. Это не калькулятор «до байта», поскольку значения зависят от стека, наличия обучения со смешанной точностью или распределенного обучения, — но как ориентир экономит время и нервы.
Суть: никаких «красивых» датасетов: данные разнородные — таблицы, тексты, временные ряды, сигналы. Поддерживать зоопарк моделей дорого, а терять качество нельзя. Что делать: читать свежие работы про TabPFN — первуюи вторую. Почему: обе работы показывают, что вокруг TabPFN можно выстроить единое табличное ядро. С одной стороны — подключать текст через адаптеры, не теряя информацию на грубом PCA. С другой — переводить в таблицу разнородные временные ряды и решать на одном ядре разнородные задачи. Может быть удобно, когда данных немного и не хочется поддерживать много отдельных моделей. При этом придется аккуратно проектировать фичи и контекст, а адаптеры обучать под свой домен, но это все равно дешевле и проще, чем полное переобучение.
Пишите в комментариях, где еще болит. В следующий заход попробуем принести что-то точечно под ваши задачи.
GitOps без романтики: эксплуатация, советы, решения
Есть подходы, которые в докладах на конференциях звучат как откровение. Git — единственный источник правды, всё декларативно, прод руками не трогаем, система сама себя лечит. А потом наступает понедельник, и выясняется, что кто-то всё-таки поправил что-то руками, конфиг задрейфовал, а rollback работает ровно до того момента, пока не нужен по-настоящему.
В новом выпуске «В SREду на кухне» поговорили о GitOps без хайпа — с Михаилом Кожемским, Lead DevOps в Банк 131, и Павлом Селивановым, руководителем продуктового направления DevTools в Яндекс Клауд.
Что на повестке
Разбираем, чем push-модель отличается от pull и почему выбор между ними — это не вкусовщина, как Argo CD и Flux ведут себя в реальной жизни, а не в туториалах, и почему иллюзия «Git = реальность» — одна из самых дорогостоящих в инфраструктуре. Отдельно — про конфигурационный drift, Terraform и Crossplane, и что GitOps до сих пор так и не научился решать.
Если вы уже внедрили GitOps и думаете «что-то пошло не так» — или только собираетесь и хотите знать, что именно пойдёт не так — этот выпуск для вас.
Опубликовали митигацию CVE-2026-31431 для Deckhouse Kubernetes Platform
Уязвимость затрагивает модуль ядра Linux algif_aead (интерфейс AF_ALG). До выхода обновлений ядра в дистрибутивах предлагаем временное решение на уровне платформы.
В репозитории:
• NodeGroupConfiguration, который блокирует загрузку модуля и выгружает его, если он загружен;
• FalcoAuditRules для детекта попыток эксплуатации (доступно в DKP EE и CSE).
Применяется через kubectl apply, подробности и инструкции в README.
Selectel начисляет до 30 000 бонусов на облачные сервисы
Привет, Хабр! Если вы ИП или юрлицо и ранее не использовали облачные базы данных или Managed Kubernetes в Selectel — можете получите до 30 000 бонусных рублей на тест этих продуктов.
Чтобы получить грант, нужно создать тикет от юридического лица или ИП с описанием нужной конфигурации — и мы начислим до 30 000 бонусов на облачные базы данных и Managed Kubernetes в Selectel.
Вебинар: от Pod Security Standards к полноценной модели безопасности подов в Deckhouse Kubernetes Platform
Pod Security Standards ограничивают privileged-контейнеры, hostPath и capabilities. Однако реальные риски безопасности шире. Неконтролируемые registry, отсутствие лимитов на ресурсы, образы без фиксированных тегов, контейнеры без health-проверок — всё это расширяет поверхность атаки.
28 апреля в 12:00 на вебинаре Deckhouse Академии разберём, как выстроить полноценную модель безопасности пода средствами Deckhouse Kubernetes Platform:
как SecurityPolicy и OperationPolicy в DKP закрывают то, что PSS оставляют открытым;
как Gatekeeper превращает декларативные политики в версионируемый код, который можно проверить в CI/CD;
почему платформенный механизм проще и надёжнее подхода «договариваться о безопасности с каждой командой».
Проект просуществовал более восьми лет, набрал 20 тысяч звёзд на GitHub и стал стандартом для HTTP-маршрутизации в Kubernetes. Теперь поддержка и разработка полностью прекращена: новых релизов, багфиксов и патчей безопасности не будет.
Причина архива: ресурс Ingress изначально был слишком ограничен. Весь расширенный функционал реализовали через vendor-специфичные аннотации, нормального RBAC не было, протоколы: только HTTP/HTTPS. Gateway API решает все эти проблемы на уровне спецификации.
Мейнтейнеры рекомендуют переходить на реализации Gateway API:
"If you are not already using ingress-nginx, you should not be deploying it as it is not being developed. Instead you should identify a Gateway API implementation and use it."
Разворачиваем приватную LLM в кластере Kubernetes в прямом эфире
Начинаем через 30 минут, в 12:00 мск. Эксперты вместе с вами пройдут весь путь от подготовки кластера до готового интерфейса: настроят мониторинг, распределенные модели, интеграции и даже автоматизацию инфраструктуры.
Kubernetes, Swarm, Nomad — как выбрать оркестратор и не пожалеть
Когда контейнеров становится больше десятка, ручное управление превращается в отдельную работу: уследить, что запущено, что упало, где не хватает ресурсов — уже не получается.
Оркестратор берет это на себя. Но выбор между Kubernetes, Docker Swarm, Nomad, Mesos и OpenShift — не очевидный. У каждого своя ниша, и «взять Kubernetes, потому что все берут» — одна из самых частых ошибок при внедрении.
Разобрали, как работают оркестраторы изнутри, чем они отличаются на практике и по каким критериям выбирать под конкретный проект. Плюс чек-лист запуска и типичные грабли — от избыточной сложности на старте до игнорирования безопасности.
Основы работы с Helm: как упростить деплой в Kubernetes
Helm — это менеджер пакетов для Kubernetes. По сути, он делает для кластеров то же, что apt для Linux или npm для JavaScript: позволяет устанавливать приложения как готовые пакеты, а не собирать всё вручную из десятков YAML-файлов.
В основе Helm — чарт: набор шаблонов с описанием ресурсов Kubernetes. При установке создается релиз с собственной историей версий — можно обновлять приложения, отслеживать изменения и при необходимости быстро откатываться. А еще Helm объединяет десятки ресурсов в один пакет и позволяет переиспользовать конфигурации для разных окружений через values.yaml.
В блоге разобрали установку Helm, основные команды, работу с репозиториями и релизами, проверку чартов перед деплоем, управление зависимостями и откаты. Читайте на сайте Рег.облака.
Что такое Portainer и зачем он нужен для управления Docker
Ранее мы уже разбирали базовые команды Docker и повседневную работу с контейнерами. Следующий логичный шаг — упростить управление окружениями и сделать его наглядным.
Сегодня поговорим о Portainer — графическом интерфейсе для управления Docker, Kubernetes и Podman. В новой статье показали, какие задачи он решает, в каких сценариях действительно полезен и чем отличается от работы через командную строку. Отдельно разобрали ключевые возможности: управление контейнерами и образами, просмотр логов и статистики, работу с сетями и томами, запуск приложений через docker-compose и готовые шаблоны.
Пошаговая инструкция по установке Portainer через Docker-контейнер и подсказки, с каких разделов удобнее начать работу — в базе знаний Рег.облака.
Если тебе надо быстро потыкать что-то из Linux / контейнеров / сетей / namespaces / cgroups, но при этом не хочется поднимать VM, ставить Docker, ковырять окружение, то iximiuz labs playgrounds - это прям топ штука.
Это набор готовых интерактивных лаб, где ты заходишь в браузере и просто:
запускаешь контейнеры
смотришь namespace’ы
играешься с сетью
Причём самое классное, что там не “прочитай статью”, а прям сценарий + терминал + что делать. То есть зашёл → запустил → увидел результат → понял, как оно работает.
---
Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩
Kubernetes Zero to Hero — базовый видеокурс от «Фланта»
Если вы хотите изучить основы работы с Kubernetes, мы сняли подходящий для этого видеокурс. Из него вы получите практические знания, которых будет достаточно для решения большинства типовых задач.
В курсе 10 коротких — до 10 минут — видео. Они рассчитаны на начинающих разработчиков с опытом в продуктовой разработке, учебных или личных проектах, где возникает потребность в Kubernetes. С нами вы:
поднимете локальный кластер и разберётесь в ключевых сущностях Kubernetes;
научитесь развёртывать приложения, пройдя путь от коммита кода в Git-репозиторий до его выката в кластер;
поймёте, как устроены сетевое взаимодействие внутри кластера и доступ к приложениям извне;
познакомитесь с werf и Helm, шаблонизацией чартов и практиками реальных проектов.
Два первых ролика уже доступны. Во вводном будут план курса и желательный для старта бэкграунд, а второй поможет поднять локальный кластер Kubernetes с помощью Minikube и получить готовое окружение для экспериментов. Смотрите на удобной вам площадке:
PostgreSQL на 4 ТБ, Patroni на две столицы и 16 000 фур в реалтайме: как мы «перевозили» CARGO.RUN
Привет, Хабр! Представьте ситуацию: один логист управляет 80 машинами одновременно. Маршруты, топливо, простои — все в реальном времени. Остановись сервер — бизнес сразу теряет деньги, а на перевозчиков сваливается хаос.
Именно таков мир, в котором работает команда CARGO.RUN — SaaS-платформа, которая автоматизирует грузоперевозки для топ-игроков рынка. Мы подготовили кейс о том, как помогли CARGO.RUN мигрировать к нам в Selectel. Внутри — настоящий технический детектив и архитектурный дзен.
Базы данных — почему для PostgreSQL с расширениями PostGIS и Timescale (а это 4 ТБ «горячих» данных!) выбрали именно выделенные серверы, а не облако.
Отказоустойчивость — как развернули кластер Patroni, физически разнесенный между дата-центрами в Москве и Санкт-Петербурге, чтобы пережить падение целого региона.
Оркестрация — переход от Docker Swarm к Managed Kubernetes для микросервисов, когда в штате всего три DevOps-инженера.
IaC — как Terraform и GitOps помогли навести порядок и сделать инфраструктуру прозрачной.
Результат миграции — рост производительности логистов в 2,5 раза и сокращение порожнего пробега фур на 53%.
