Контейнерное хранилище
Kubernetes Контейнерный интерфейс хранилища (CSI) — это стандартизированный фреймворк дополнений хранилища, запущенный Cloud Native Computing Foundation (CNCF). Он предполагает разъединение систем хранилища от Kubernetes, позволяя службам хранилища использоваться как дополнения без изменения ядра Kubernetes. Хранилище CCE построено на основе CSI и поддерживает широкий спектр типов хранилищ, включая блочное хранилище, файловое хранилище и объектное хранилище, чтобы удовлетворять потребности как бесстатных, так и статических приложений. CSI полностью совместим с нативной системой хранилища Kubernetes и поддерживает несколько форм хранилища, таких как emptyDir, hostPath, secret и ConfigMap.
Рисунок 1 Типы контейнерного хранилища
CCE позволяет рабочим pod‑ам использовать несколько типов хранилищ:
- Что касается реализации, хранилище поддерживает Container Storage Interface (CSI) и нативное хранилище Kubernetes.
Тип
Описание
CSI
Стандартизированный механизм плагинов (соответствует CCE Everest) разработан для разъединения систем хранилища от оркестрационных платформ, решая проблему тесной привязки традиционных in-tree плагинов хранилища к ядру Kubernetes. Его основная концепция включает определение единой спецификации gRPC-интерфейса, позволяющей поставщикам хранилищ разрабатывать пользовательские плагины вне дерева. Это обеспечивает независимую сборку, компиляцию и выпуск функциональности хранилища без встраивания кода плагина в репозиторий исходного кода Kubernetes. Достаточно лишь объявить требования к хранилищу через PVC и PV. Драйвер CSI обрабатывает остальное, обеспечивая динамическое предоставление и управление хранилищем.
Начиная с Kubernetes 1.13, CSI стал официально рекомендованной реализацией плагинов хранилища.
Нативное хранилище Kubernetes
Запускается в режиме in-tree, где код плагина хранилища встроен непосредственно в репозиторий ядра Kubernetes. Это означает, что плагины хранилища собираются, компилируются и выпускаются вместе с основными компонентами Kubernetes, такими как kubelet и kube-controller-manager. Плагины хранилища должны обновляться совместно с Kubernetes. Их нельзя разрабатывать, обновлять или расширять независимо от цикла выпуска Kubernetes. Это ограничивает гибкость поддержки сторонних систем хранилища.
- Что касается носителей хранилища, его можно классифицировать как облачное хранилище, локальное хранилище и объекты ресурсов Kubernetes.
Тип
Описание
Сценарий применения
Облачное хранилище
Хранилище предоставляется поставщиками облачных сервисов и позволяет сохранять данные хранилища в удалённых кластерах через сети. Это обеспечивает централизованное управление и эластичное масштабирование ресурсов хранилища. В кластере достаточно объявить требования к хранилищу через PVC и PV. Дополнение CSI автоматически обрабатывает доступ к облачному хранилищу, устраняя необходимость ручной настройки нижележащих ресурсов.
Данные требуют высокой доступности или должны быть общими, например, журналы и медиа‑ресурсы.
Выберите подходящий облачный StorageClass в зависимости от сценария применения. Подробнее см.Сравнение облачных хранилищ.
Локальное хранилище
Носитель хранилища — локальный диск с данными или память узла. Локальный PV — это настроенный StorageClass, предоставляемый CCE и монтируемый через PVC и PV с помощью CSI. Другие StorageClass являются нативными для Kubernetes.
Данные без HA требуют высокой производительности ввода‑вывода и низкой задержки.
Выберите соответствующий тип локального хранилища в зависимости от сценария применения. Подробнее см.Сравнение локального хранилища.
Объекты ресурсов Kubernetes
ConfigMap и secret — это ресурсы, создаваемые в кластерах. Они являются специальными типами хранилища и предоставляются tmpfs (файловой системой на основе ОЗУ) на API‑сервере Kubernetes.
ConfigMap используются для внедрения конфигурационных данных в pod‑ы.
Secret используются для передачи конфиденциальной информации, такой как пароли, pod‑ам.
Сравнение облачных хранилищ
Элемент | EVS | SFS | SFS Turbo | OBS |
|---|---|---|---|---|
Определение | Сервис блочного хранилища, работающий в пулах совместных ресурсов хранилища. Он предоставляет масштабируемые, высокопроизводительные и надёжные тома хранилища для облачных серверов. Диски EVS доступны в различных спецификациях и являются экономичными. | Масштабируемый до петабайт, SFS предоставляет полностью управляемое совместное файловое хранилище, обладающее высокой доступностью и стабильностью для обработки приложений, требующих больших объёмов данных и пропускной способности, в сфере HPC, обработки медиа, обмена файлами, управления контентом и веб‑сервисов. | Масштабируемый до 320 ТБ, SFS Turbo предоставляет полностью управляемое совместное файловое хранилище с высокой доступностью и стабильностью, поддерживая небольшие файлы и приложения, требующие низкой задержки и высокой IOPS. SFS Turbo можно использовать в веб‑сайтах с высоким трафиком, для хранения журналов, сжатия/распаковки, DevOps, корпоративных OA и контейнерных приложений. | Масштабируемое, безопасное, надёжное и экономичное хранилище для данных любого типа и объёма. Его можно использовать для корпоративного бэкапа/архивирования, видео по запросу (VoD), видеонаблюдения и множества других сценариев. |
Логика хранения данных | Хранит бинарные данные и не может напрямую хранить файлы. Для хранения файлов необходимо сначала отформатировать файловую систему. | Хранит файлы и сортирует, отображая данные в иерархии файлов и папок. | Хранит файлы и сортирует, отображая данные в иерархии файлов и папок. | Файлы, хранящиеся напрямую, автоматически генерируют системные метаданные, которые также могут быть настроены пользователем. |
Режим доступа | Доступно только после монтирования к ECS и инициализации. | Монтируется к ECS с использованием сетевых протоколов. Необходимо указать сетевой адрес или сопоставить его с локальным каталогом для доступа. | Поддерживает протокол Network File System (NFS) (только NFSv3). Вы можете бесшовно интегрировать существующие приложения и инструменты с SFS Turbo. | Доступно через Интернет или Direct Connect. Укажите адрес бакета и используйте протоколы передачи, такие как HTTP или HTTPS. |
Статические тома хранилища | Поддерживается. Подробнее см.Использование существующего диска EVS через статический PV. | Поддерживается. Подробнее см.Использование существующей файловой системы SFS через статический PV. | Поддерживается. Подробнее см.Использование существующей файловой системы SFS Turbo через статический PV. | Поддерживается. Подробнее см.Использование существующего бакета OBS через статический PV. |
Динамические тома хранилища | Поддерживается. Подробнее см.Использование диска EVS через динамический PV. | Поддерживается. Подробнее см.Использование файловой системы SFS через динамический PV. | Поддерживается для поддиректорий SFS Turbo. Подробнее см.(Рекомендуется) Создание поддиректории SFS Turbo с использованием динамического PV. | Поддерживается. Подробнее см.Использование бакета OBS через динамический PV. |
Особенности | Несшаренное хранилище. Каждый том может монтироваться только на один узел. | Общее хранилище с высокой производительностью и пропускной способностью | Общее хранилище с высокой производительностью и пропускной способностью | Общая файловая система в пользовательском режиме |
Сценарии применения | HPC, корпоративные приложения ядра кластера, корпоративные прикладные системы и dev/test Note ПРИМЕЧАНИЕ: | HPC, обработка медиа, управление контентом, веб‑сервисы, большие данные и аналитические приложения ПРИМЕЧАНИЕ: Приложения HPC здесь требуют высокой пропускной способности и совместного файлового хранилища, например, секвенирование генов и рендеринг изображений. | Веб‑сайты с высоким трафиком, хранение журналов, DevOps и корпоративный OA | Аналитика больших данных, хостинг статических веб‑сайтов, онлайн‑видео по запросу (VoD), секвенирование генов, интеллектуальное видеонаблюдение, резервное копирование и архивирование, а также корпоративные облачные коробки (веб‑дискы) |
Ёмкость | TB | SFS 1.0: PB | Общего назначения: TB | EB |
Задержка | 1–2 ms | SFS 1.0: 3–20 ms | Общего назначения: 1–5 мс | 10 ms |
Макс. IOPS | 2 200–256 000, в зависимости от флейворов | SFS 1.0: 2,000 | Общего назначения: до 100 000 | Десятки миллионов |
Пропускная способность | MB/s | SFS 1.0: GB/s | Общего назначения: до GB/s | TB/s |
Сравнение локального хранилища
Элемент | Локальный PV | Локальный эфемерный том | emptyDir | hostPath |
|---|---|---|---|---|
Определение | Локальные диски узла формируют пул хранилища (VolumeGroup) через LVM. LVM делит их на логические тома (LV) и монтирует их в pod‑ы. | Нативный emptyDir Kubernetes, где локальные диски узла формируют пул хранилища (VolumeGroup) через LVM. LVs создаются в качестве носителя хранилища для emptyDir и монтируются в pod‑ы. LVs обеспечивают лучшую производительность, чем типичный носитель emptyDir. | Нативный emptyDir Kubernetes. Его жизненный цикл совпадает с жизненным циклом pod. В качестве носителя хранилища можно указать память. При удалении pod пустой том emptyDir удаляется, и его данные теряются. | Используется для монтирования каталога файлов хоста, где находится pod, в указанный точку монтирования pod. |
Особенности | Низкая задержка, высокий I/O и PV без HA. Тома хранилища — это несшаренное хранилище, привязанное к узлам через метки. Поэтому тома могут монтироваться только к одному pod. | Эфемерный локальный том. Объём хранилища берётся из локальных LV. | Эфемерный локальный том. Объём хранилища берётся из локального корневого каталога kubelet или памяти. | Используется для монтирования файлов или каталогов файловой системы хоста. Каталоги хоста могут создаваться автоматически. Pod‑ы могут мигрировать (не привязаны к узлам). |
Монтирование тома хранилища | Статические тома хранилища не поддерживаются. Использование локального PV через динамический PV поддерживается. | Подробнее см.Local EV. | Подробнее см.Временный путь. | Подробнее см.hostPath. |
Сценарии применения | Требования приложений к высокому I/O и встроенным HA решениям, например, развёртывание MySQL в режиме HA. |
|
| Требуется файл узла, например, если используется Docker, можно использовать hostPath для монтирования /var/lib/docker путь узла. ПРИМЕЧАНИЕ: По возможности избегайте использования томов hostPath, поскольку они подвержены рискам безопасности. Если тома hostPath обязательны, они могут применяться только к файлам или каталогам и монтироваться в режиме только для чтения. |
Enterprise Project Support
Для использования этой функции добавленное расширение Everest должно быть обновлено до версии v1.2.33 или более новой.
- Автоматическое создание хранилища:
При создании PVC EVS или OBS с использованием StorageClass в CCE можно указать enterprise‑project для назначения созданных ресурсов хранилища (диски EVS и OBS). Этот enterprise project может быть либо стандартным, либо тем же, к которому принадлежит кластер.
Если enterprise project не указан, enterprise project, указанный в StorageClass, будет использоваться по умолчанию для создания ресурсов хранилища.
- Для пользовательского StorageClass можно указать enterprise project в StorageClass. Подробнее см.Создание StorageClass через консоль. Если enterprise project не указан в StorageClass, используется стандартный enterprise project.
- Для классов хранилища csi-disk и csi-obs, предоставляемых CCE, созданные ресурсы хранилища принадлежат стандартному enterprise project.
- Использование существующего хранилища:
При создании PVC с использованием PV убедитесь, что everest.io/enterprise-project-id указаны в PVC и PV одинаковы, так как при создании ресурса хранилища был указан enterprise project. В противном случае PVC и PV не смогут привязаться.
Полезные ссылки
- Перед использованием контейнерного хранилища ознакомьтесь с базовыми понятиями, такими как PV и PVC. Подробнее см.Основы хранилища.
- CCE использует Everest для взаимодействия с облачными сервисами хранилища. Подробнее об Everest см.CCE Container Storage (Everest).
- CCE поддерживает следующие типы томов хранилища: