#Основные понятия

#Обзор

Этот документ знакомит администраторов Kubernetes, знакомых с концепциями постоянного хранения, с основными ресурсами и принципами Container Object Storage Interface (COSI). COSI предоставляет декларативный механизм управления объектным хранилищем (таким как AWS S3, MinIO и Ceph RGW), аналогичный существующим подходам управления постоянным хранилищем в Kubernetes.

Мы рассмотрим три основных ресурса в COSI — BucketClass, Bucket и BucketClaim — проводя аналогии с ресурсами хранения Kubernetes для прояснения их взаимосвязей и функционала.

#Основные ресурсы

COSI определяет три ключевых ресурса:

#1. BucketClass

Область видимости: на уровне кластера
Аналог в Kubernetes: аналог StorageClass

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

Основные функции:

• Определяет политику удаления бакета (например, удалять ли сам бакет при удалении BucketClaim)
• Указывает драйвер COSI (driverName)
• Задаёт параметры, специфичные для поставщика

Пример YAML:

apiVersion: objectstorage.k8s.io/v1alpha1
kind: BucketClass
metadata:
  name: ceph-cosi-driver-class
deletionPolicy: Delete
driverName: ceph.objectstorage.k8s.io
parameters:
  objectStoreUserSecretName: rook-ceph-object-user-object-store-user-for-cosi
  objectStoreUserSecretNamespace: rook-ceph

#2. Bucket

Область видимости: на уровне кластера
Аналог в Kubernetes: аналог PersistentVolume (PV)

Bucket представляет собой абстракцию реального бакета, существующего во внешней системе объектного хранения (например, AWS S3, MinIO, Ceph RGW) внутри Kubernetes.

Управление жизненным циклом:

• Динамическое создание: автоматически создаётся контроллером COSI при получении запроса BucketClaim.

#3. BucketClaim

Область видимости: в пределах namespace
Аналог в Kubernetes: аналог PersistentVolumeClaim (PVC)

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

Последовательность действий:

1. Пользователь создаёт BucketClaim, указывая BucketClass.
2. Контроллер COSI обнаруживает запрос и динамически создаёт бакет в бекенде объектного хранилища на основе определения BucketClass.
3. Создаётся соответствующий ресурс Bucket, который связывается с BucketClaim.
4. Генерируется Secret с учётными данными доступа к бакету, который автоматически монтируется в Pod’ы, запрашивающие бакет.

Пример YAML:

apiVersion: objectstorage.k8s.io/v1alpha1
kind: BucketClaim
metadata:
  name: my-app-bucket-claim
  namespace: my-app-ns
spec:
  bucketClassName: ceph-standard-replicated
  protocol:
    s3: {} # Defaults populated by the driver

#Взаимодействие ресурсов

Ниже описан процесс динамического создания ресурсов COSI на практике:

1. Администратор кластера создаёт и поддерживает BucketClass.
2. Пользователь namespace создаёт BucketClaim с ссылкой на BucketClass.
3. Контроллер COSI обнаруживает BucketClaim и динамически создаёт бакет на основе определения BucketClass.
4. Контроллер создаёт соответствующий ресурс Bucket в Kubernetes.
5. BucketClaim и Bucket связываются.
6. Создаётся Secret с учётными данными для использования в Pod’ах.
7. Pod’ы монтируют Secret и получают доступ к объектному хранилищу.

#Итог

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