Контейнерное хранилище
Kubernetes Container Storage Interface (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, позволяющей поставщикам хранилищ разрабатывать пользовательские плагины хранения в out-of-tree режиме. Это обеспечивает независимую сборку, компиляцию и выпуск функций хранения без встраивания исходного кода плагина в репозиторий исходного кода Kubernetes. Достаточно объявить требования к хранилищу через PVCs и PVs. Драйвер CSI обрабатывает остальное, обеспечивая динамическое предоставление и управление хранилищем.
Начиная с Kubernetes 1.13, CSI стал официально рекомендуемой реализацией плагинов хранения.
Нативное хранилище Kubernetes
Работает в in-tree режиме, при котором код плагина хранения внедряется непосредственно в репозиторий основного кода Kubernetes. Это означает, что плагины хранения собираются, компилируются и выпускаются вместе с основными компонентами Kubernetes, такими как kubelet и kube-controller-manager. Плагины хранения должны обновляться одновременно с Kubernetes. Их нельзя разрабатывать, обновлять или расширять независимо от цикла выпуска Kubernetes. Это ограничивает гибкость поддержки сторонних систем хранения.
- С точки зрения носителей хранения, хранилище можно классифицировать как облачное хранилище, локальное хранилище и объекты ресурсов Kubernetes.
Тип
Описание
Сценарий использования
Облачное хранилище
Хранилище предоставляется поставщиками облачных сервисов и позволяет сохранять данные в удалённых кластерах через сети. Это обеспечивает централизованное управление и эластичное масштабирование ресурсов хранилища. В кластере вам достаточно объявить требования к хранилищу через PVCs и PVs. Дополнение CSI автоматически обрабатывает доступ к облачному хранилищу, исключая необходимость ручной настройки базовых ресурсов.
Данные требуют высокой доступности или должны быть общими, например, журналы и медиа‑ресурсы.
Выберите подходящий облачный StorageClass в зависимости от сценария применения. Подробнее см. Cloud Storage Comparison.
Локальное хранилище
Носителем хранилища является локальный Диск с данными или память узла. Локальный PV — это настраиваемый StorageClass, предоставляемый CCE и монтируемый с помощью PVCs и PVs через CSI. Другие StorageClass являются нативными для Kubernetes.
Данные без высокой доступности требуют высокой I/O и низкой задержки.
Выберите подходящий тип локального хранилища в зависимости от сценария применения. Подробнее см. Local Storage Comparison.
Объекты ресурсов Kubernetes
ConfigMaps и secrets — это ресурсы, создаваемые в кластерах. Они представляют собой специальные типы хранилища и предоставляются tmpfs (файловая система на основе ОЗУ) на сервере API Kubernetes.
ConfigMaps используются для внедрения конфигурационных данных в pods.
Secrets используются для передачи конфиденциальной информации, такой как пароли, в pods.
Cloud Storage Comparison
Элемент | EVS | SFS Turbo | OBS |
|---|---|---|---|
Определение | Блочный сервис хранения, работающий в общих пулах ресурсов хранения. Он предлагает масштабируемые, высокопроизводительные и надежные тома хранения для облачных серверов. Диски EVS доступны в различных спецификациях и являются экономичными. | Расширяемый до 320 ТБ, SFS Turbo предоставляет полностью управляемое совместное файловое хранилище, обладающее высокой доступностью и стабильностью, для поддержки небольших файлов и приложений, требующих низкой задержки и высокого IOPS. Вы можете использовать SFS Turbo в веб‑сайтах с высоким трафиком, хранении журналов, сжатии/распаковке, DevOps, enterprise OA и контейнеризованных приложениях. | Масштабируемое, безопасное, надежное и экономичное хранилище для данных любого типа и объёма. Вы можете использовать его в корпоративном резервном копировании/архивировании, видеопотоке по запросу (VoD), видеонаблюдении и многих других сценариях. |
Логика хранения данных | Хранит двоичные данные и не может напрямую хранить файлы. Чтобы хранить файлы, сначала отформатируйте файловую систему. | Хранит файлы, сортирует и отображает данные в иерархии файлов и папок. | Хранит объекты. При прямом хранении файлов автоматически генерируются системные метаданные, которые также могут быть настроены пользователями. |
Режим доступа | Доступно только после монтирования к ECSs и инициализации. | Поддерживает протокол Network File System (NFS) (только NFSv3). Вы можете бесшовно интегрировать существующие приложения и инструменты с SFS Turbo. | Доступно через Internet или Direct Connect. Укажите адрес bucket и используйте протоколы передачи, такие как HTTP или HTTPS. |
Статические тома хранения | Поддерживается. Подробнее см. Using an Existing EVS Disk Through a Static PV. | Поддерживается. Подробнее см. Using an Existing SFS Turbo File System Through a Static PV. | Поддерживается. Подробнее см. Using an Existing OBS Bucket Through a Static PV. |
Динамические тома хранения | Поддерживается. Подробнее см. Using an EVS Disk Through a Dynamic PV. | Поддерживается для подкаталогов SFS Turbo. Подробнее см. (Recommended) Creating an SFS Turbo Subdirectory Using a Dynamic PV. | Поддерживается. Подробнее см. Using an OBS Bucket Through a Dynamic PV. |
Функции | Неделимое хранилище. Каждый том может быть смонтирован только на один узел. | Общее хранилище с высокой производительностью и пропускной способностью | Общая файловая система пользовательского режима |
Сценарии использования | HPC, enterprise core cluster applications, enterprise application systems и dev/test ПРИМЕЧАНИЕ: HPC‑приложения требуют высокоскоростного и высоко‑IOPS хранилища, например, для промышленного дизайна и разведки энергии. | Веб‑сайты с высоким трафиком, хранение логов, DevOps и корпоративный OA | Аналитика больших данных, хостинг статических веб‑сайтов, онлайн‑видео по запросу (VoD), геномное секвенирование, интеллектуальное видеонаблюдение, бэкап и архивирование, а также enterprise cloud boxes (web disks) |
Ёмкость | TB | General-purpose: TB | EB |
Задержка | 1–2 ms | General-purpose: 1–5 ms | 10 ms |
Макс. IOPS | 2,200–256,000, depending on flavors | General-purpose: до 100,000 | Десятки миллионов |
Пропускная способность | MB/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, в указанный mount point pod. |
Функции | Низкая задержка, высокий I/O и non-HA PV. Тома хранения являются несвязанным (non-shared) хранилищем и привязываются к узлам через метки. Поэтому тома хранения могут монтироваться только к одному pod. | Локальный эфемерный том. Объём хранения берётся из локальных LVs. | Локальный эфемерный том. Объём хранения берётся из локального корневого каталога kubelet или памяти. | Используется для монтирования файлов или каталогов файловой системы хоста. Каталоги хоста могут создаваться автоматически. Pods могут мигрировать (не привязаны к узлам). |
Монтирование тома хранения | Статические тома хранения не поддерживаются. Using a Local PV via Dynamic Provisioning поддерживается. | Для получения подробной информации см. Local EV. | Для получения подробной информации см. Temporary Path. | Для получения подробной информации см. hostPath. |
Сценарии использования | Высокие требования к I/O и встроенные HA‑решения приложений, например, развертывание MySQL в режиме HA. |
|
| Требуется файл узла, например, если используется Docker, можно использовать hostPath для монтирования пути /var/lib/docker узла. NOTICE: По возможности избегайте использования томов hostPath, так как они подвержены рискам безопасности. Если тома hostPath необходимо использовать, они могут быть применены только к файлам или каталогам и монтироваться в режиме только для чтения. |
Enterprise Project Support
Для использования этой функции необходимо обновить дополнение Everest до версии v1.2.33 или более новой.
- Автоматическое создание хранилища:
При создании EVS или OBS PVC через StorageClass CCE позволяет указать enterprise project. Предоставленные ресурсы хранилища (диски EVS и бакеты OBS) автоматически назначаются указанному проекту. Доступные варианты enterprise project включают default enterprise project, enterprise project, к которому относится кластер, и enterprise project, указанный в StorageClass.
Если enterprise project не указан, enterprise project, указанный в StorageClass, будет использоваться по умолчанию для создания ресурсов хранилища.
- For a custom StorageClass, you can specify an enterprise project in StorageClass. For details, see Advanced StorageClass Settings. If no enterprise project is specified in StorageClass, the default enterprise project is used.
- Для ресурсов хранения, созданных с использованием StorageClass csi-disk или csi-obs, предоставляемого CCE, ресурсы назначаются enterprise project default.
- Использовать существующее хранилище:
При создании PVC с использованием PV убедитесь, что значение everest.io/enterprise-project-id, указанное в PVC и PV, одинаково, поскольку при создании ресурса хранения был указан enterprise project. В противном случае PVC и PV не могут быть привязаны.
Полезные ссылки
- Прежде чем использовать контейнерное хранилище, ознакомьтесь с базовыми понятиями, такими как PVs и PVCs. Подробности см. в Storage Basics.
- CCE использует Everest для взаимодействия с облачными сервисами хранения. Подробности о Everest см. в CCE Container Storage (Everest).
- CCE поддерживает следующие типы томов хранения: