S3-хранилище для Kubernetes-сценариев: архитектура и варианты интеграции

Разберем задачи объектного хранилища для Kubernetes.

Хранение резервных копий и восстановление

Большинство backup-систем для Kubernetes используют S3-совместимый бэкэнд (Veeam, КиберБэкап, Commvault, Trilio и т.п.), так как объектное хранилище позволяет дешево хранить большие объемы бэкап-данных с надежной геораспределенной репликацией.

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

Кластеры ИИ и машинного обучения

Современные AI-кластеры в Kubernetes работают с наборами данных объемом от терабайтов до петабайт. Работа графического процессора GPU требует параллельного чтения большого количества объектов одновременно, а традиционные NAS-системы в таких сценариях начинают упираться в ограничения пропускной способности.

Распределенное объектное хранилище масштабируется горизонтально. При добавлении узла хранения растет совокупная пропускная способность, емкость параллельного чтения и объем хранения.

Именно поэтому большинство AI-платформ используют S3 как стандарт хранилища.

Kubernetes и долговременное хранение данных

Prometheus, Thanos и другие активно используют объектное хранилище для метрик, логов, хранения любых данных.

SSD-массивы для постоянной нагрузки становятся слишком дорогими. Объектное хранилище S3 же позволяет вынести долгосрочные данные на отдельном распределенном уровне хранения с более низкой стоимостью за ТБ.

SAN-системы хорошо работают для баз данных, блочного хранилища, предсказуемых операций на ввод-вывод. Но в Kubernetes возникают такие ограничения, как сложный мультикластерный доступ, высокая стоимость репликации и масштабирования, зависимость от поставщика, ограничения архитектуры контроллера. Также при росте числа контейнеров SAN начинает создавать узкое место на уровне структуры хранения данных и координации метаданных.

NAS остается удобным вариантом для файловая система, но при cloud-native нагрузках возникают проблемы в виде масштабирования индексного дескриптора, задержек метаданных, частых конфликтов из-за каталогов, ограничения параллельного ввода-вывода. При миллионах объектов производительность и показатели становятся хуже.

Объектное хранилище использует другую модель. Благодаря работе с метаданными и именами, распределенному хранению и горизонтальному масштабированию, S3 эффективнее работает с нагрузками Kubernetes.

S3 API – универсальный протокол взаимодействия с объектами по следующим причинам:

• независимость от конкретного вендора,
• масштабируемая архитектура,
• совместимость с инфраструктурой и cloud-native платформ,
• интеграция с Kubernetes-сценариями.

Сегодня S3-совместимое хранилище интегрируется практически со всеми ключевыми cloud-native инструментами, что позволяет компаниям снизить стоимость миграции и интеграции, а также масштабирования хранения данных.

При работе Kubernetes с объектным хранилищем вычислительный слой и слой хранения данных разделяются. Это одна из ключевых причин, почему S3-совместимая архитектура масштабируется лучше традиционных SAN/NAS решений в корпоративной среде.

В классической схеме Kubernetes-кластер выполняет:

• оркестровка контейнеров,
• планирование,
• автомасштабирование,
• управление сетевым взаимодействием.

А объектное хранилище S3 берет на себя:

• хранение данных,
• репликацию,
• отказоустойчивость,
• распределение объектов,
• управление метаданными.

Типовая архитектура объектного S3-хранилища состоит из нескольких независимых слоев и может подключаться к Kubernetes-приложениям через S3 API.

Слой API

S3 API endpoint принимает запросы:

• PUT,
• GET,
• DELETE,
• LIST,
• multipart upload.

Данный слой отвечает за авторизацию, маршрутизацию запросов, балансировку нагрузки, проверку политики доступа.

В корпоративной же инфраструктуре API обычно разворачивается через:

• контроллер входящего трафика,
• балансировщик нагрузки L4/L7,
• обратный прокси.

Слой метаданных

Слой метаданных хранит:

• информацию об объектах,
• конфигурацию сегмента,
• сопоставление размещения,
• состояние репликации,
• политики жизненного цикла.

Для объектного хранилища метаданные критически важный компонент. При миллиардах объектов именно метаданные становятся тем самым «узким местом».

В архитектуре метаданные должны обеспечивать:

• горизонтальное масштабирование,
• распределенное хранение,
• согласование,
• быстрое восстановление после отказов.

Узлы хранения

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

Таким образом, в случае выхода 2 из 3 ЦОД, данные все равно будут доступны в формате чтения.

Уровень защиты данных

Для защиты данных в объектных хранилищах используются разные подходы: репликация и Erasure Coding. В PlatformCraft сейчас применяется полноценная репликация, а Erasure Coding развивается как более экономичная по емкости модель хранения для будущих сценариев.

При репликации объект хранится в нескольких полных копиях на разных узлах. Такой подход повышает отказоустойчивость, но требует больше дискового пространства. Erasure Coding позволяет хранить не полные копии, а фрагменты данных и проверочные части, за счет чего экономит емкость.

Сейчас PlatformCraft использует полноценную репликацию. Erasure Coding развивается как будущая возможность платформы и позволит экономить емкость за счет хранения фрагментов данных и проверочных частей вместо полных копий.

В Kubernetes объектное хранилище чаще всего используется через S3 API и SDK. Приложение работает напрямую через S3 API.

Поток данных при записи объекта

При записи данных в S3-хранилище приложение отправляет запрос на S3 endpoint. Если приложение работает в Kubernetes, взаимодействие происходит через S3 API или SDK; само хранилище при этом может быть развернуто отдельно от Kubernetes-кластера.

1. Приложение отправляет объект.

Контейнер или сервис выполняет PUT-запрос, многокомпонентную загрузку, потоковую загрузку. Далее запрос уходит на S3-endpoint.

2. API валидирует запрос.

Проверяются учетные данные, политика, правила жизненного цикла объектов, квота, изоляция арендатора. После этого система определяет стратегия размещения.

3. Подсистема метаданных создает объект.

Слой метаданных определяет, где будут размещены объекты, какие узлы участвуют в хранении, и какая политика репликации применяется.

4. Сегментирование объектов.

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

5. Кодирование и запись данных.

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

6. Фиксирование метаданных.

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

Kubernetes создает высокую динамику нагрузки из-за автомасштабирования, временных рабочих и пиковых нагрузок, распределенной обработки данных.

Для стабильного масштабирования S3-платформа должна поддерживать:

• распределенные метаданные,
• ребалансировку,
• Erasure Coding («стирающее кодирование»),
• изоляцию квот,
• георепликацию,
• контроль полосы пропускания,
• самовосстановление,
• многопользовательский режим.

Объектное хранилище лучше адаптировано под такую модель благодаря нескольким особенностям.

Отсутствие узкого места в общей файловой системе

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

Горизонтальное масштабирование

С добавлением новых узлов увеличится совокупная пропускная способность и количество параллельных операций ввода-вывода. В SAN/NAS масштабирование обычно ограничено архитектурой контроллера, структурой хранения.

Kubernetes создает огромное количество небольших объектов: логи, скриншоты, резервные копии, временные файлы, артефакты сборки, служебные данные. Чем больше таких объектов, тем выше нагрузка на систему индексации и поиск объектов внутри хранилища. В результате проблема возникает в обработке метаданных и служебных запросов.

В распределенном S3-хранилище между узлами постоянно передаются данные (репликация, восстановление после отказов, перераспределение объектов, синхронизация служебной информации). В случае перегрузки сети производительность начнет снижаться даже при наличии быстрых дисков и мощных серверов, поэтому объектное хранилище требует отдельной высокоскоростной сети с минимальными задержками между узлами.

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

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

Такая схема используется в большинстве крупных AI-платформ, инфраструктуры под резервное копирование или медиаконтент, поскольку позволяет независимо масштабировать:

• вычислительные ресурсы,
• узлы GPU,
• емкость хранилища,
• пропускная способность.

Объектное хранилище способен долгое время работать без явных ошибок. Система продолжает отвечать на запросы, но постепенно растет задержка, увеличивается время восстановления и падает пропускная способность под нагрузкой. Такие проблемы обычно обнаруживаются уже после сильного падения рабочей производительности.

Таким образом, развертывание S3-хранилище зависит от:

• объема данных,
• требований к задержке (latency),
• отказоустойчивости,
• топологии сети,
• типа рабочейнагрузки,
• требований к безопасности.

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

Развертывание через Docker Compose и ограниченные Kubernetes-сценарии

Для типовых «корпоративных» (on-premise) инсталляций PlatformCraft используется Docker Compose. Такой подход подходит для компактных кластеров с несколькими серверами, где нет необходимости в полноценной Kubernetes-оркестрации.
Kubernetes имеет смысл рассматривать в инфраструктурах с большим количеством узлов, где требуется автоматическое управление, масштабирование и восстановление сервисов. На текущем этапе Kubernetes-сценарий – один из возможных интеграционных контуров через S3 API, но не основной способ развертывания S3 от PlatformCraft.

Что чаще всего ломает развертывание в производственной среде

Большинство проблем в S3-инфраструктуре связано не с объемом хранения, а с неправильной архитектурой кластера и сети. Самые частые ошибки:

1. Неправильная сеть – в S3-хранилище между узлами постоянно передаются данные. При слабой сети или высокой задержке резко падает производительность всего кластера.
2. Перегрузка уровня метаданных – при росте числа объектов основная нагрузка переходит на систему метаданных (поиск объектов, LIST-запросы, версионирование, служебные операции). Именно метаданные чаще становится первым «проблемным местом» в крупных S3-кластерах.
3. Смешивание вычислительные ресурсы и хранилище – если приложения Kubernetes и объектное хранилище работают на одних серверах, начинается конкуренция за CPU, сеть и диски. В результате производительность кластера становится нестабильной.

Еще одна распространенная ошибка – резервирование только данных объекта без резервной подсистемы метаданных. Потеря кластера метаданных способна сделать объекты отключенными даже при полной сохранности данных на узлах хранения. Проектируйте отдельно резервное копирование метаданных и аварийное восстановление.

Сетевые требования к хранилищу данных

Сеть – ключевая составляющая S3-инфраструктуры.

Хранилище объектов постоянно генерирует:

• трафик репликации,
• синхронизацию метаданных,
• операции ребалансировки,
• перепроверку трафика,
• параллельное чтение/запись.

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

• от 10 Гб/с – минимально допустимая скорость передачи данных для небольшой нагрузки;
• от 25 Гб/с – базовый стандарт для S3 и Kubernetes;
• 40-100 Гб/с – для AI, аналитики, обработки медиафайлов и высокопроизводительной рабочей нагрузки;
• топология Spine-Leaf (магистраль-листья);
• коммутация с низкой задержкой.

По задержкам внутри сети обычно стремятся, чтобы:

• RTT составляла менее 1 мс между узлами хранилища;
• была стабильная низкая задержка сети без потери пакетов.

Как выглядит зрелая enterprise-архитектура

В зрелой корпоративной архитектуре Kubernetes и объектные хранилища развиваются как независимые распределенные системы. Kubernetes отвечает за оркестрацию и жизненный цикл вычислений. S3-хранилище берет на себя:

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

Резервное копирование стало одним из основных сценариев использования S3-совместимого хранилища в Kubernetes. Необходимо сохранять постоянные данные, метаданные, состояния, конфигурацию приложений, версии объектов и так далее.

Объектное хранилище – наиболее подходящая модель хранения для таких задач благодаря горизонтальному масштабированию и независимости от мощности инфраструктуры.

Большинство современных backup-систем для Kubernetes работают через S3 API, поэтому фактически S3 уже стал стандартом для бэкапирования. Именно S3-хранилище можно «расширить» на десятки и сотни терабайт ежемесячно без затруднений.

Еще одна причина популярности S3 в резервном копировании – это независимость backup-слоя от жизненного цикла Kubernetes.

За последние годы ransomware-атаки (программ-вымогателей) сделали бэкапы одной из главных целей злоумышленников. Если репозиторий с резервными копиями в одном экземпляре, то вредоносное ПО способно удалить данные, зашифровать их, повредить или даже уничтожить.

При репликации между несколькими площадками резервные копии сохраняются независимо от одного конкретного узла или ЦОД. Для защиты от удаления и шифрования дополнительно используют политики неизменяемости, версионирование и ограничение прав доступа. Даже если злоумышленники получат доступ к одному из узлов, данные останутся на других.

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

AI-инфраструктура стала одним из главных драйверов роста объектного хранения. Современные Kubernetes-кластеры для машинного обучения работают с объемами данных, которые плохо масштабируются на традиционных SAN или NAS системах.

Типичная AI-платформа хранит датасеты, артефакты, телеметрии и множество других данных, так что общий объем быстро достигает сотен терабайт, а то и петабайт.

Нагрузка при машинном обучении и AI принципиально отличается от классической корпоративной нагрузки. GPU-кластеры способны потреблять данные быстрее, чем большинство традиционные системы хранения успевают их отдавать. Если пропускной способности сети недостаточно, GPU начинают простаивать, что повышает стоимость вычислений.

S3-хранилище имеет наиболее подходящую архитектуру для таких сценариев благодаря горизонтальному масштабированию и способности обслуживать массивные параллельные нагрузки.

В крупных AI-кластерах объектное хранилище генерирует огромный трафик. Во время обучения модели данные постоянно перемещаются между узлами хранения, GPU, конвейерами предварительной обработки и уровнями кэширования. При недостаточной производительности сети возникают задержки и резкое снижение пропускной способности.

Для AI-платформ особенно важно независимое масштабирование, поэтому важно увеличивать:

• количество узлов GPU;
• кластер предварительной обработки;
• аналитические возможности.

В Kubernetes-кластере стоимость хранения складывается из нескольких компонентов:

• емкость,
• сеть,
• накладные расходы на репликацию,
• инфраструктура метаданных,
• энергопотребление,
• сопровождение,
• масштабирование,
• восстановительные операции,
• риск простоя.

Основное внимание при выборе S3-хранилища для Kubernetes обычно уделяется цене дисков или стоимости одного терабайта. В распределенной S3-архитектуре емкость и производительность растут одновременно с добавлением узлов хранения (в таких сценариях горизонтальное масштабирование значительно дешевле вертикального расширения SAN).

Отдельную роль играет стоимость репликации. Классические системы хранения часто используют полные копии данных между массивами, что увеличивает расход. В S3-хранилищах избыточность может снижаться за счет Erasure Coding, если этот механизм поддерживается платформой. В текущей реализации PlatformCraft отказоустойчивость обеспечивается полноценной репликацией, поэтому фактический расход емкости зависит от выбранного фактора репликации.

В Kubernetes объем рабочей нагрузки меняется динамически, и в S3-хранилище просто новый «node» подключается к кластеру, после чего система автоматически начинает перераспределение объектов и синхронизацию данных.

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

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

Резервное копирование и аварийное восстановление

Самый распространенный сценарий под объектное хранилище. Через S3 API хранилище интегрируется с решениями для бэкапирования, такими как Veeam, Acronis, КиберБэкап и подобные.

Мониторинг

Prometheus, Zabbix, Astra Monitoring и другие системы мониторинга генерируют огромный объем логов, метрик, данных телеметрии. Объектное хранилище используется для долгосрочного удержания, поскольку классические файловые системы плохо масштабируются при миллиардах небольших объектов.

AI и аналитика

Объектное хранилище хорошо подходит для параллельного доступа к большим объемам данных и горизонтального масштабирования AI-инфраструктуры, поэтому быстро становится стандартом для хранения машинных данных.

Видеоархивы и медиаплатформы

S3-совместимое хранилище также активно используется для видеоархивов, потоковой передачи, мультимедиа. Главные преимущества: масштабируемость, высокая пропускная способность и дешевое хранение.

1. Зачем Kubernetes-инфраструктуре S3-совместимое хранилище?
S3-хранилище используют как отдельный слой для резервных копий, логов, архивов, данных AI/ML, аналитики и медиаконтента. Оно помогает хранить большие объемы данных независимо от жизненного цикла Kubernetes-кластера.

2. Нужно ли разворачивать PlatformCraft внутри Kubernetes?
Нет. PlatformCraft может использоваться рядом с Kubernetes-кластером через S3 API, но Kubernetes не является обязательным способом развертывания платформы.

3. Как PlatformCraft обычно разворачивается в on-premise-инфраструктуре?
Для типовых on-premise-инсталляций используется Docker Compose. Такой подход подходит для компактных конфигураций с несколькими серверами, где не требуется полноценная Kubernetes-оркестрация.

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

5. Чем S3-хранилище лучше SAN/NAS для Kubernetes-сценариев?
S3-хранилище лучше масштабируется горизонтально, проще работает с большими объемами распределенных данных и не зависит от общей файловой системы, которая часто становится узким местом в SAN/NAS.

6. Как в PlatformCraft обеспечивается отказоустойчивость данных?
Сейчас PlatformCraft использует полноценную репликацию: данные хранятся в нескольких копиях на разных узлах или площадках. Erasure Coding развивается как будущая возможность для более экономного хранения.

7. Для каких задач S3-хранилище в Kubernetes используется чаще всего?
Чаще всего S3 применяют для резервного копирования и восстановления, долгосрочного хранения логов и метрик, AI/ML-датасетов, аналитики, видеоархивов и медиаплатформ.