Дайджесты новостей
Изометрическая модель шлюза NooBaa в Kubernetes с единым протоколом S3 и автоматическим распределением объектов между локальными дисками и облаками.

NooBaa Operator: гибридное S3-хранилище и триггеры событий в Kubernetes

В современной микросервисной архитектуре приложениям постоянно требуется хранилище неструктурированных объектов: медиафайлов, пользовательских аватаров, логов, PDF-отчетов и бэкапов. Стандартом де-факто для работы с такими данными стал протокол Amazon S3 API.

Однако реальная инфраструктура компаний редко бывает однородной. Часть сервисов развернута в публичном облаке, часть — на собственных серверах bare-metal, а корпоративные политики требуют хранить чувствительные данные строго на локальных дисках. В результате приложения вынуждены тянуть за собой зоопарк вендорных SDK, разработчики мучаются с пробросом ключей доступа, а перенос сервиса из одного облака в другое превращается в мучительный рефакторинг.

Открытый проект NooBaa (широко известный в экосистеме Red Hat OpenShift как Multicloud Object Gateway) предлагает принципиально иной подход: предоставить кластеру Kubernetes единый независимый шлюз S3, абстрагирующий любые физические хранилища.

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

Архитектурная концепция: абстракция и тиринг

NooBaa Operator реализует паттерн Kubernetes Operator, полностью автоматизируя жизненный цикл объектного шлюза:

  • Единая точка входа: сервисы внутри кластера обращаются к единому внутреннему эндпоинту http://s3.noobaa.svc.cluster.local, используя стандартный протокол S3.
  • Гетерогенные бэкенды: физически данные могут сохраняться на локальные Persistent Volumes (PVC) серверов Ceph, в AWS S3, Google Cloud Storage, Azure Blob или любое стороннее S3-хранилище.
  • Интеллектуальный тиринг (Tiering): система умеет автоматически держать свежие «горячие» объекты на быстрых локальных SSD, а устаревшие архивные файлы прозрачно перемещать в дешевые облачные корзины.
  • Зеркалирование (Mirroring): запись одного объекта может параллельно дублироваться сразу в двух независимых облачных провайдеров для максимальной катастрофоустойчивости.
  • Серверлесс-триггеры: встроенный механизм нотификаций при появлении или удалении файлов в бакете позволяет запускать бессерверные функции обработки без внешних очередей сообщений.

Модель Custom Resource Definitions (CRD)

Вся магия NooBaa опирается на три понятных декларативных ресурса:

  1. BackingStore: описывает конкретное физическое место хранения (пул локальных дисков PVC или реквизиты внешнего бакета в AWS/GCP).
  2. BucketClass: определяет правила размещения (политику репликации, сжатия, шифрования и распределения по доступным BackingStore).
  3. ObjectBucketClaim (OBC): декларативная заявка разработчика на создание бакета (аналог привычного PVC для файлов).
# 1. Установка оператора NooBaa в кластер через CLI
noobaa install

# 2. Создание пула локальных дисков на базе системного StorageClass
noobaa backingstore create pv-pool local-pv-store --num-volumes 3 --pv-size-gb 50

# 3. Создание класса бакетов, привязанного к локальному пулу
noobaa bucketclass create fast-local-class --backingstores local-pv-store

Декларативное подключение к приложению

Разработчику микросервиса больше не нужно знать учетные данные облака или генерировать ключи вручную. Достаточно описать манифест ObjectBucketClaim:

# app-bucket-claim.yaml — декларативный запрос на выделение бакета
apiVersion: objectbucket.io/v1alpha1
kind: ObjectBucketClaim
metadata:
  name: user-media-bucket
  namespace: default
spec:
  bucketClassName: fast-local-class
  generateBucketName: media-storage

После применения манифеста оператор NooBaa автоматически создаст в пространстве имен default два связанных ресурса:

  • ConfigMap/user-media-bucket: содержит переменные BUCKET_NAME, BUCKET_HOST, BUCKET_PORT;
  • Secret/user-media-bucket: содержит сгенерированные учетные данные AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY.

Остается лишь подключить их к контейнеру приложения:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: media-service
spec:
  replicas: 2
  template:
    spec:
      containers:
        - name: app
          image: media-service:latest
          envFrom:
            - configMapRef:
                name: user-media-bucket
            - secretRef:
                name: user-media-bucket
Локальная разработка в minikube и kind

Для проверки манифестов на локальном ноутбуке инженера запусти установку с флагом noobaa install --mini. Оператор развернет компактный облегченный профиль компонентов, не перегружая память локальной машины.

Практический итог

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