Интервью с SIG Storage: как развивается хранилище Kubernetes для AI-нагрузок

Kubernetes давно перестал быть просто оркестратором контейнеров — сегодня это платформа, на которой работают критически важные приложения, включая базы данных и AI-модели. За то, чтобы данные этих приложений были надёжно сохранены и доступны, отвечает SIG Storage — специальная группа внутри сообщества Kubernetes. В очередном выпуске серии SIG Spotlight мы поговорили с Xing Yang, соруководителем SIG Storage и инженером VMware by Broadcom, о том, как изменилось хранилище в Kubernetes за последние годы и что ждёт его в будущем.

SIG Storage: от первых CSI до AI-эпохи

SIG Storage существует с самого начала проекта Kubernetes, но её роль кардинально изменилась с появлением Container Storage Interface (CSI). До CSI каждый облачный провайдер должен был писать собственный интеграционный код для Kubernetes, что замедляло развитие экосистемы. CSI стандартизировал интерфейс между Kubernetes и системами хранения данных, позволив вендорам создавать единые драйверы. Как рассказывает Xing Yang, она пришла в SIG Storage как раз в период становления CSI — тогда многие процессы ещё только формировались.

Сегодня в SIG Storage работают два соруководителя (Xing Yang и Saad Ali из Google) и два технических лида (Michelle Au из Google и Jan Šafránek из Red Hat). Группа курирует несколько ключевых подпроектов: csi-provisioner, csi-attacher, csi-resizer и csi-snapshotter — все они выпускаются синхронно с каждым новым релизом Kubernetes.

Предыстория и контекст

Потребность в продвинутых функциях хранения данных в Kubernetes растёт экспоненциально. Если раньше большинство контейнерных приложений были stateless (веб-серверы, API-шлюзы), то сегодня всё чаще в Kubernetes разворачивают stateful-нагрузки: базы данных, очереди сообщений, а теперь и AI-модели. AI-нагрузки предъявляют особые требования к хранилищу: им нужны высокие скорости чтения/записи, низкая задержка и возможность создавать консистентные снимки состояния.

SIG Storage отвечает на эти вызовы новыми функциями. Одна из них — Volume Group Snapshot, которая появилась в Kubernetes 1.30. Она позволяет создавать crash-consistent снапшоты для группы томов, используемых одним приложением. Это особенно важно для баз данных, где данные распределены по нескольким томам.

Что такое Changed Block Tracking и зачем он нужен?

Changed Block Tracking (CBT) — ещё одна значимая функция, вышедшая из Data Protection Working Group, совместной инициативы SIG Storage и SIG Apps. CBT позволяет отслеживать, какие блоки данных изменились с момента последнего снапшота. Это кардинально ускоряет инкрементальное резервное копирование: вместо полного копирования всех данных система сохраняет только изменённые блоки. Для больших баз данных или AI-моделей, весящих сотни гигабайт, экономия времени и ресурсов колоссальна.

CBT работает на уровне драйвера CSI — вендоры систем хранения могут реализовать эту функцию в своих драйверах. Это не просто удобство, а необходимость для enterprise-сред, где RPO (Recovery Point Objective) измеряется минутами.

Технические подробности: как устроено управление томами в Kubernetes

Управление постоянными томами (Persistent Volumes, PV) и запросами на их использование (Persistent Volume Claims, PVC) — основа работы SIG Storage. Когда приложение запрашивает хранилище через PVC, Kubernetes автоматически связывает его с подходящим PV, используя механизмы динамического выделения. CSI-драйверы обеспечивают взаимодействие с реальными системами хранения: будь то облачные диски (AWS EBS, GCE PD), сетевые хранилища (NFS, iSCSI) или SDS-решения (Ceph, Portworx).

Каждый новый релиз Kubernetes включает обновление CSI-драйверов и sidecar-контейнеров, которые управляют операциями с томами. Например, csi-provisioner отвечает за создание новых томов, csi-attacher — за их подключение к узлам, csi-resizer — за изменение размера, а csi-snapshotter — за создание снапшотов. Синхронный релиз всех компонентов — сложная инженерная задача, которую SIG Storage решает из релиза в релиз.

Кого затронет и как

Новые функции SIG Storage в первую очередь важны для:

Разработчики stateful-приложений. Volume Group Snapshot и CBT позволяют реализовать надёжное резервное копирование без простоев. Теперь можно создавать консистентные снимки состояния для сложных приложений, состоящих из нескольких сервисов.

Администраторы Kubernetes. Упрощается управление резервным копированием на уровне кластера. Вместо скриптов, которые дёргают API облачных провайдеров, можно использовать стандартные Kubernetes API.

Вендоры систем хранения. CSI остаётся основным способом интеграции. Реализация поддержки новых функций, таких как CBT, даёт конкурентное преимущество.

В России и СНГ Kubernetes активно используется в крупных компаниях: от банков до телеком-операторов. Локальные вендоры, такие как «Аэродиск» или Yandex Cloud, уже поддерживают CSI. С внедрением Volume Group Snapshot и CBT российские пользователи получат ещё более надёжные инструменты для работы с данными.

Что будет дальше

AI-нагрузки становятся мейнстримом, и SIG Storage уже думает о том, как адаптировать Kubernetes для работы с GPU-кластерами и большими моделями. Среди обсуждаемых направлений — поддержка NVMe-oF (NVMe over Fabrics) для снижения задержек, улучшенная интеграция с параллельными файловыми системами (Lustre, GPFS) и автоматическое управление производительностью томов на основе нагрузки.

В ближайших релизах стоит ожидать дальнейшего развития Data Protection Working Group: возможно, появятся функции для репликации данных между кластерами и более гибкие политики снапшотов.

Итог

SIG Storage продолжает эволюционировать вместе с Kubernetes. От простого управления томами группа перешла к решению сложных задач защиты данных и производительности, которые становятся критически важными для AI и enterprise-нагрузок. Следить за работой SIG Storage стоит любому, кто использует Kubernetes в production, — новые функции появляются каждый релиз, и они напрямую влияют на надёжность и скорость работы приложений.