Kubernetes Container Storage Interface (CSI) — это стандартизированный фреймворк дополнений хранилища, запущенный Cloud Native Computing Foundation (CNCF). Он направлен на разъединение систем хранилища от Kubernetes, позволяя получать доступ к сервисам хранилища как к дополнениям без изменения основного кода Kubernetes. Хранилище CCE построено на основе CSI и поддерживает широкий спектр типов хранилища, включая блочное хранилище, файловое хранилище и объектное хранилище, чтобы удовлетворять потребности как приложений без состояния, так и приложений с состоянием. CSI полностью совместим с нативной системой хранилища Kubernetes и поддерживает несколько форм хранилища, таких как emptyDir, hostPath, secret и ConfigMap.
Рисунок 1 Типы контейнерного хранилища

CCE позволяет pod‑ам рабочей нагрузки использовать несколько типов хранилища:
Тип | Описание |
|---|---|
CSI | Стандартизированный механизм плагинов (соответствующий CCE Everest), разработанный для разъединения систем хранилища от оркестрационных платформ, решающий проблему тесной привязки традиционных in‑tree плагинов хранилища к основному коду Kubernetes. Его основная концепция заключается в определении единой спецификации интерфейса gRPC, позволяющей поставщикам хранилища разрабатывать пользовательские плагины хранилища в out‑of‑tree режиме. Это обеспечивает независимую сборку, компиляцию и выпуск функций хранилища без встраивания исходного кода плагина в репозиторий исходного кода Kubernetes. Достаточно объявить требования к хранилищу через PVC и PV. Драйвер CSI обрабатывает остальное, обеспечивая динамическое предоставление и управление хранилищем. Начиная с Kubernetes 1.13, CSI стал официально рекомендованной реализацией плагинов хранилища. |
Нативное хранилище Kubernetes | Работает в режиме in‑tree, когда код плагина хранилища встроен непосредственно в репозиторий основного кода Kubernetes. Это означает, что плагины хранилища собираются, компилируются и выпускаются вместе с основными компонентами Kubernetes, такими как kubelet и kube‑controller‑manager. Плагины хранилища должны обновляться одновременно с Kubernetes. Их нельзя разрабатывать, обновлять или расширять независимо от цикла выпуска Kubernetes. Это ограничивает гибкость поддержки сторонних систем хранилища. |
Тип | Описание | Сценарий применения |
|---|---|---|
Облачное хранилище | Хранилище предоставляется поставщиками облачных сервисов и позволяет сохранять данные в удалённых кластерах через сети. Это обеспечивает централизованное управление и эластичное масштабирование ресурсов хранилища. В кластере вам достаточно объявить требования к хранилищу через PVCs и PVs. Дополнение CSI автоматически обрабатывает доступ к облачному хранилищу, устраняя необходимость ручной настройки базовых ресурсов. | Данные требуют высокой доступности или должны быть общими, например, журналы и медиа‑ресурсы. Выберите подходящий облачный StorageClass в зависимости от сценария применения. Подробнее см. Cloud Storage Comparison. |
Локальное хранилище | Носителем хранилища является локальный диск с данными или память узла. Локальный PV — это настроенный StorageClass, предоставляемый CCE и монтируемый с помощью PVCs и PVs через CSI. Другие StorageClass являются нативными для Kubernetes. | Данные Non-HA требуют высокой производительности ввода‑вывода и низкой задержки. Выберите подходящий тип локального хранилища в зависимости от сценария применения. Подробнее см. Local Storage Comparison. |
Объекты ресурсов Kubernetes | ConfigMaps и secrets — это ресурсы, создаваемые в кластерах. Они представляют собой специальные типы хранилища и предоставляются tmpfs (файловой системой на основе ОЗУ) на сервере API Kubernetes. | ConfigMaps используются для внедрения конфигурационных данных в pods. Secrets используются для передачи конфиденциальной информации, такой как пароли, в pods. |
Элемент | EVS | SFS | SFS Turbo | OBS |
|---|---|---|---|---|
Определение | Сервис блочного хранилища, работающий в общих пулах ресурсов хранения. Он предоставляет масштабируемые, высокопроизводительные и надежные тома хранения для облачных серверов. Диски EVS доступны в различных спецификациях и являются экономичными. | Масштабируемый до петабайт, SFS предоставляет полностью управляемое совместное файловое хранилище, обладающее высокой доступностью и стабильностью, способное обрабатывать приложения с интенсивным использованием данных и пропускной способности в HPC, обработке медиа, совместном использовании файлов, управлении контентом и веб‑службах. | Масштабируемый до 320 ТБ, SFS Turbo предоставляет полностью управляемое совместное файловое хранилище с высокой доступностью и стабильностью, поддерживая небольшие файлы и приложения, требующие низкой задержки и высокой IOPS. Вы можете использовать SFS Turbo в веб‑сайтах с высоким трафиком, хранении журналов, сжатии/распаковке, DevOps, корпоративных OA и контейнеризованных приложениях. | Масштабируемое, безопасное, надежное и экономичное хранилище для данных любого типа и объёма. Его можно использовать в корпоративных бэкап/архивировании, видеопотоке по запросу (VoD), видеонаблюдении и многих других сценариях. |
Логика хранения данных | Хранит двоичные данные и не может напрямую сохранять файлы. Чтобы сохранять файлы, сначала отформатируйте файловую систему. | Хранит файлы и сортирует и отображает данные в иерархии файлов и папок. | Хранит файлы и сортирует и отображает данные в иерархии файлов и папок. | Хранит объекты. При прямом хранении файлов автоматически генерируются системные метаданные, которые также могут быть настроены пользователями. |
Access mode | Доступно только после монтирования к ECSs и инициализации. | Монтируется к ECSs с использованием сетевых протоколов. Необходимо указать сетевой адрес или сопоставить его с локальным каталогом для доступа. | Поддерживает протокол Network File System (NFS) (только NFSv3). Вы можете бесшовно интегрировать существующие приложения и инструменты с SFS Turbo. | Доступно через Internet или Direct Connect. Укажите адрес bucket и используйте протоколы передачи, такие как HTTP или HTTPS. |
Static storage volumes | Поддерживается. Подробнее см. Using an Existing EVS Disk Through a Static PV. | Поддерживается. Подробнее см. Using an Existing SFS File System Through a Static PV. | Поддерживается. Подробнее см. Using an Existing SFS Turbo File System Through a Static PV. | Поддерживается. Подробнее см. Using an Existing OBS Bucket Through a Static PV. |
Dynamic storage volumes | Поддерживается. Подробнее см. Using an EVS Disk Through a Dynamic PV. | Поддерживается. Подробнее см. Using an SFS File System Through a Dynamic PV. | Поддерживается для поддиректорий SFS Turbo. Подробнее см. (Recommended) Creating an SFS Turbo Subdirectory Using a Dynamic PV. | Поддерживается. Подробнее см. Using an OBS Bucket Through a Dynamic PV. |
Функции | Несинхронное хранилище. Каждый volume может быть подключен только к одному node. | Общее хранилище с высокой производительностью и пропускной способностью | Общее хранилище с высокой производительностью и пропускной способностью | Общая файловая система в пользовательском режиме |
Сценарии применения | HPC, корпоративные ядровые кластерные приложения, корпоративные прикладные системы и dev/test ПРИМЕЧАНИЕ: Приложения HPC здесь требуют высокоскоростного и высоко‑IOPS хранилища, например промышленного дизайна и энергетической разведки. | HPC, обработка медиа, управление контентом, веб‑сервисы, большие данные и аналитические приложения ПРИМЕЧАНИЕ: Приложения HPC здесь требуют высокой пропускной способности и общего файлового хранилища, например секвенирование генов и рендеринг изображений. | Веб‑сайты с высоким трафиком, хранение логов, DevOps и корпоративные OA | Аналитика больших данных, хостинг статических веб‑сайтов, онлайн‑видеопоток (VoD), секвенирование генов, интеллектуальное видеонаблюдение, бэкап и архивирование, а также корпоративные облачные коробки (веб‑диски) |
Ёмкость | TB | SFS 1.0: PB | General-purpose: TB | EB |
Задержка | 1–2 ms | SFS 1.0: 3–20 ms | General-purpose: 1–5 ms | 10 ms |
Max. IOPS | 2,200–256,000, в зависимости от флейворов | SFS 1.0: 2,000 | General-purpose: до 100,000 | Десятки миллионов |
Пропускная способность | MB/s | SFS 1.0: GB/s | Общее назначение: до GB/s | TB/s |
Элемент | Local PV | Local Ephemeral Volume | emptyDir | hostPath |
|---|---|---|---|---|
Определение | Локальные диски узла формируют пул хранилища (VolumeGroup) через LVM. LVM делит их на логические тома (LVs) и монтирует их в pods. | Встроенный в Kubernetes emptyDir, где локальные диски узла формируют пул хранилища (VolumeGroup) через LVM. LVs создаются в качестве носителя хранения emptyDir и монтируются в pods. LVs обеспечивают лучшую производительность, чем носитель хранения по умолчанию для emptyDir. | Встроенный в Kubernetes emptyDir. Его жизненный цикл совпадает с жизненным циклом pod. В качестве носителя хранения можно указать память. При удалении pod том emptyDir удаляется, и его данные теряются. | Используется для монтирования файлового каталога хоста, где находится pod, в указанную точку монтирования pod. |
Функции | Низкая задержка, высокая I/O и non-HA PV. Тома хранения являются несвязанным хранилищем и привязываются к узлам через метки. Поэтому тома хранения могут монтироваться только к одному pod. | Local ephemeral volume. Объём хранения берётся из локальных LVs. | Local ephemeral volume. Объём хранения берётся из локального корневого каталога kubelet или памяти. | Используется для монтирования файлов или каталогов файловой системы host. Каталоги host могут создаваться автоматически. Pods могут мигрировать (не привязаны к узлам). |
Монтирование тома хранения | Статические тома хранения не поддерживаются. Using a Local PV Through a Dynamic PV поддерживается. | Для получения подробной информации см. Local EV. | Для получения подробной информации см. Temporary Path. | Для получения подробной информации см. hostPath. |
Сценарии применения | Высокие требования к I/O и встроенные HA‑решения приложений, например, развертывание MySQL в режиме HA. |
|
| Требуется файл узла, например, если используется Docker, можно использовать hostPath для монтирования пути /var/lib/docker узла. NOTICE: Избегайте использования томов hostPath насколько это возможно, так как они подвержены рискам безопасности. Если тома hostPath необходимо использовать, они могут быть применены только к файлам или каталогам и монтироваться в режиме только для чтения. |
Чтобы использовать эту функцию, дополнение Everest должно быть обновлено до версии v1.2.33 или более новой.
При создании EVS или OBS PVC с использованием StorageClass в CCE вы можете указать enterprise project, чтобы назначить созданные ресурсы хранилища (диски EVS и OBS). Этот enterprise project может быть либо проектом по умолчанию, либо тем же, к которому относится кластер.
Если enterprise project не указан, enterprise project, указанный в StorageClass, будет использоваться по умолчанию для создания ресурсов хранилища.
При создании PVC с использованием PV убедитесь, что everest.io/enterprise-project-id, указанный в PVC и PV, одинаковый, поскольку при создании ресурса хранилища был указан проект предприятия. В противном случае PVC и PV не могут быть привязаны.