В апреле прошла вторая Deckhouse Conf и тогда мы ходили на площадку послушать, о чём сейчас говорят инженеры вокруг Kubernetes. А сейчас появились записи докладов, поэтому вместе с технической выжимкой увиденного можем поделиться и ссылками для DevOps-инженеров и платформенных разработчиков.

Если у вас нет времени смотреть все записи докладов целиком, держите главное.

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

Андрей Половов в своём докладе разобрал технические пределы классических CNI-плагинов. В Deckhouse отказались создавать Франкенштейна из готовых CNI- и SDN-решений, чтобы получить нативную для Kubernetes сетевую подсистему, в результате команда выкатила собственную программно-определяемую сеть.

В инструменте уже есть поддержка дополнительных сетей на классических VLAN, решён вопрос с адрес-менеджментом и dedicated NIC c поддержкой SR-IOV. В работе — дополнительные сети на XVLAN, DHCP для виртуалок, NetworkPolicy для дополнительных сетей, BGP и ALB-AAA.

Виртуалки как first-class citizens в Kubernetes

Тема с виртуалками в Kubernetes давно висит в воздухе. Компании идут в микросервисы и контейнеризацию, но в проде у многих до сих пор крутятся монолитные системы и легаси-приложения. Их реально проще держать в ВМ, чем быстро переписывать к следующему кварталу. На конференции этот вопрос разобрали в докладе Павла Тишкова через практику использования виртуализации внутри Kubernetes. Разговор шел именно про надежность и привычную управляемость виртуальных машин под управлением оркестратора.

Проблема соседства ВМ и контейнеров

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

Инженерам нужен способ держать все нагрузки в общем контуре и перестать плодить «зоопарк» из платформ, консолей и ручных регламентов. В докладе Павел разобрал практику запуска и управления виртуальными машинами наравне с контейнерамии внутри K8s.

Что меняется для инфраструктурной команды

Когда виртуалка становится штатным объектом внутри оркестратора, команда получает привычный operational flow. Ресурсы, политики, сеть и автоматизация начинают жить в одном контексте. Они больше не разъезжаются по разным панелям управления, где каждая вкладка требует отдельного ритуала. Вывод капитанский, но полезный: чем меньше ручной магии вокруг инфраструктуры, тем реже ночной дежурный вспоминает создателей этого стека.

Разработчики и DevOps получают возможность держать рядом сервис в контейнере и зависимый компонент в ВМ (которая тоже в контейнере). Изменения можно катать через знакомые процессы и постепенно разгребать наследство без миграции ради миграции. Deckhouse развивает виртуализацию без отрыва от Kubernetes и рассматривает виртуальные машины как часть общего рантайма для гибридных нагрузок.

Что стоит вынести из доклада

Виртуалки никуда не делись. Теперь их просто встраивают в современный платформенный слой, где уже прижились контейнеры, GitOps и декларативное управление. Такой подход спасает команды, желающие унифицировать эксплуатацию и убрать лишние переходы между разными контурами администрирования. Если у вас в инфраструктуре до сих пор живут монолиты, которые нельзя быстро распилить на микросервисы, эту тему точно можно посмотреть.

Самописный сontrol plane для SDS

Работа с Software-Defined Storage в Kubernetes часто оборачивается попытками подружить облачно-ориентированные технологии с инструментами старой школы. Александр Зимин разобрал типичный сценарий такого столкновения на примере LINSTOR. Разработчики Deckhouse изначально взяли этот инструмент на роль control plane, понимая его архитектурные ограничения. Они согласились на внешнюю базу данных и push-модель управления конфигурациями.

Со временем эти компромиссы дали о себе знать. Экспериментальный режим работы с etcd регулярно приводил к зависанию реплик при штатных обновлениях. Добавим к этому, что инженеры постоянно ловили баги во время изменения размеров томов и при эвакуации узлов.

Большой болью оказался и технологический стек. Подсистему хранения данных в Deckhouse пишет Go-команда, которой приходилось тратить спринты на дебаг и патчинг чужого Java-кода. Поддерживать и дальше такой воркфлоу было абсолютно невыгодно. Поэтому, набравшись опыта с LINSTOR, инженеры просто отказались от готового решения и написали собственный control plane под программно-определяемого хранилища.

Спикер показал понятный рубикон для платформенной разработки. Полезно видеть чужой опыт и понимать, когда пора перестать адаптировать готовый open-source продукт под свои задачи и сесть за написание кастомного решения.

Реальная цена защиты кластера

При переходе в Kubernetes инженеры закладывают мощности под бизнес-логику, но не всегда учитывают ресурсы для средств защиты кластеров. Никита Ладошкин из Positive Technologies показал «налоги» на информационную безопасность, которые стоит держать в уме, если вы хотите получить больше защищенности, чем в «ванильном» Kubernetes.

Если компания дозрела до мониторинга runtime-рисков, ей приходится достраивать технологии, процессы и роли. Плата за всё это — высокие компетенции нанимаемых инженеров, дополнительные вычислительные ресурсы и время на разбор ошибок. Но есть и хорошие новости. Несмотря на то, что защита контейнерных сред неизбежно забирает своё из общего пула ресурсов, можно оформить «налоговый вычет». Например, за счет выбора правильных инструментов, фокуса на ценных активах и харденинга.

Защита самой платформы

Разумеется, информационная безопасность в контексте Kubernetes не ограничивается одним контролем уже запущенных нагрузок. Сама платформа для их развёртывания тоже должна быть защищена от разных векторов атак. В Deckhouse используют подходSecure by Design. Разработчики внедрили контроль целостности — обязательную цифровую подпись всех контейнерных образов платформы и её системных компонентов. Такой механизм исключает подмену на этапе доставки, иезаметная подмена кода полностью исключается.

Контроль всех ИБ-компонентов кластера в Dechouse Kubernetes Platform вынесли в специализированный интерфейс для централизованного контроля. А компаниям, которые подпадают под требования регуляторов пригодится сертифицированная ФСТЭК России редакция платформы.

Архитектура в пайплайнах вместо ревью

Когда код пушат десятки команд, техлиды физически не могут отсматривать каждый коммит. Архитектурное ревью быстро превращается в бутылочное горлышко, где релизы висят в ожидании согласования. Антон Исанин из «АльфаСтрахования» показал, как выпилить этот ручной труд с помощью Deckhouse Development Platform.

Ребята зашили стандарты разработки прямо в CI/CD. Теперь пайплайн сам разворачивает валидную среду и бьет по рукам, если сервис не проходит по инфраструктурным требованиям. Разработчики просто получают готовую песочницу и сразу пишут бизнес-логику. Сеньорам при этом больше не нужно тратить время на проверку базового бойлерплейта и объяснение правил при онбординге новых людей.

Что выкатил сам Deckhouse: веб-интерфейс, мониторинг, управление GPU и

В главном докладе Александр Титов и Давид Мэгтон показали ключевые апдейты Deckhouse Kubernetes Platform, а детали реализации и новости других продуктов команда раскрыла на профильных питчах.

Платформа для запуска софта должна быть простой в эксплуатации, несмотря её на сложность «под капотом». Для этого инженеры Deckhouse существенно прокачали графический интерфейс: теперь в нём доступны 100% возможностей CLI и API платформы, а ещё появилась удобная мультитенантность. Графический инсталлятор же теперь умеет ставить DKP в 9 видов инфраструктур.

С наблюдаемостью знакомая история: при росте количества метрик сборщики телеметрии начинают неадекватно потреблять оперативную память. Команда Deckhouse выкатила для решения этой задачи свою систему мониторинга Prom++. Она оптимизирует хранение данных и экономит RAM на серверах. API полностью совместим с Prometheus, поэтому переписывать привычные дашборды и алерты не придется.

Как уже было понятно из доклада про виртуализацию, DKP умеет запускать виртуальные машины наравне с контейнерами. За год с прошлой конференции здесь добавилось много новых фич, например, живая миграция и клонирование ВМ, гибкое управление USB и продвинутый мониторинг.

Под ML-задачи завезли нативное управление видеокартами. Платформа теперь умеет динамически нарезать одну физическую GPU на изолированные ресурсы для разных задач.

Представили и линейку управляемых сервисов. Сейчас в платформе уже доступны семь сервисов, которые закрывают основные сценарии работы с данными: PostgreSQL, Kafka, Cassandra, Valkey, Memcached, Hive Metastore и Trino.

Что еще стоит посмотреть в записи

Из остального расписания советуем глянуть кейс Владимира Анисимова и Антона Белоусова про партизанский кластер DKP CE. Материал пригодится инженерам, которым нужно собрать proof of concept для закрытого контура. Спикеры показали процесс развертывания платформы на обычном пользовательском железе практически без доступа в интернет. Этот опыт пригодится, если нужно обкатать гипотезу до выделения бюджетов на энтерпрайз-лицензии и серверные стойки.

Владимир Гурьянов прошелся по визуализации метрик. Доклад подойдет тем, кто устал смотреть на перегруженные данными дашборды, которые грузятся по несколько минут. Спикер разобрал частые ошибки создания дашбордов и объяснил логику выбора информации для графиков и их легенд. Увидите, почему привычка собирать на одном экране вообще все доступные параметры сервиса только мешает дежурным.

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