Связаться с экспертомПопробовать бесплатно
Создавайте контент и получайте гранты!Готовы написать своё руководство? Участвуйте в контент-программе и получайте гранты на работу с облачными сервисами!
Подробнее о программе
Проект Яндекса
© 2026 ТОО «Облачные Сервисы Казахстан»

Object Storage

Статья создана
Улучшена
Обновлена 23 сентября 2026 г.
Открыть в Markdown

Object Storage — S3-совместимое объектное хранилище на базе Yandex Object Storage. Хранилище можно использовать для данных любого формата. Взаимодействовать с ним можно с помощью инструментов, поддерживающих S3 API.

Настройки компонента задаются ресурсом StorageConfig с именем main. Чтобы включить Object Storage и задать параметры хранилища при первой установке кластера, выполните инструкцию Настройка компонентов перед установкой.

В текущую поставку входит Object Storage версии 26.3.9.

Основные возможности

  • Хранение неструктурированных данных любого объема.
  • Совместимость с S3 API — работа с любыми инструментами и SDK, поддерживающими протокол S3.
  • Управление бакетами через Kubernetes CRD Bucket.
  • Гибкая настройка публичного доступа к объектам.
  • Поддержка CORS для веб-приложений.
  • Интеграция с Identity and Access Management для управления доступом.
  • Временные ключи доступа с ограниченным сроком действия и политикой доступа.
  • Версионирование, ограничение размера бакета и метки.
  • Управление доступом с помощью ACL и политик S3.
  • Автоматическое удаление объектов по правилам жизненного цикла и защита версий объектов от удаления с помощью Object Lock.

Конфигурация

Администратор кластера настраивает Object Storage с помощью ресурса StorageConfig с именем main. Ресурс действует на весь кластер. Чтобы изменить настройки, выполните команду:

kubectl edit storageconfig main

Пример конфигурации с включенным хранилищем и стандартными настройками ресурсов:

apiVersion: stackland.yandex.cloud/v1alpha1
kind: StorageConfig
metadata:
  name: main
spec:
  enabled: true
  settings:
    api:
      s3CacheMB: 256
    storage:
      diskType: SSD
      servers: 3
      size: 154Gi
    resources:
      auto:
        requests:
          cpu: "14"
          memory: 20Gi
        limits:
          cpu: "20"
          memory: 30Gi
      volumes:
        objectDatabase: 6Gi
        metadataDatabase: 3Gi
        backgroundTasksDatabase: 1Gi
        backupStorage: 11Gi

Где:

  • spec.enabled — включение компонента. По умолчанию false.
  • spec.settings.api.s3CacheMB — размер кеша S3 API в мегабайтах. По умолчанию 256.
  • spec.settings.storage.diskType — тип дисков: SSD или HDD.
  • spec.settings.storage.servers — количество серверов хранилища, каждый из которых размещается на отдельном worker-узле. Минимум — 3; количество серверов не должно превышать количество worker-узлов.
  • spec.settings.storage.size — размер тома данных на каждом сервере. В стандартной конфигурации для SSD задано 154Gi. Расчетная емкость servers × size / 3 не должна превышать 60 ТиБ.
  • spec.settings.storage.storageClass — класс хранилища, необязательное поле. Если его не задать, используется класс по умолчанию.
  • spec.settings.resources — настройки CPU, памяти и размеров служебных томов. Если блок не задан, используются значения по умолчанию из примера.

CPU и память

В spec.settings.resources.auto задаются параметры распределения CPU и памяти для Object Storage. Фактические суммарные requests и limits подов могут превышать эти значения из-за минимальных требований сервиса. Учитывайте это при планировании емкости кластера и подбирайте ресурсы под нагрузку.

Параметр

По умолчанию и минимум

Максимум

requests.cpu

"14"

"1024"

requests.memory

20Gi

4Ti

limits.cpu

"20"

"1024"

limits.memory

30Gi

4Ti

Если вы добавляете блок auto, укажите все четыре параметра. Для каждого ресурса значение requests не должно превышать limits.

CPU задается строкой в ядрах, например "20" или "20.5", либо в тысячных долях ядра: "20500m". Для памяти доступны единицы Mi, Gi и Ti.

Размеры служебных томов

В spec.settings.resources.volumes можно независимо задать размер каждого тома:

Параметр

Назначение

По умолчанию и минимум

objectDatabase

База данных со списками объектов и их метаданными

6Gi

metadataDatabase

База данных с метаданными бакетов

3Gi

backgroundTasksDatabase

База данных фоновых задач

1Gi

backupStorage

Хранилище резервных копий служебных баз данных

11Gi

Максимальный размер каждого тома — 4Ti. Доступны единицы Mi, Gi и Ti. Если параметр не задан, используется его значение по умолчанию.

Тома можно только увеличивать. После увеличения нельзя удалить параметр, если это вернет размер к меньшему значению по умолчанию. Увеличение этих томов не меняет емкость для пользовательских объектов, заданную в spec.settings.storage.size.

Проверить применение настроек

После сохранения изменений проверьте ресурс:

kubectl get storageconfig main -o yaml

Дождитесь status.phase: Ready. В status.conditions условие ResourcesValid со значением True означает, что настройки ресурсов допустимы, но само по себе не подтверждает завершение обновления. Поле status.observedGeneration должно совпадать с metadata.generation.

Если значение выходит за допустимые границы или уменьшает уже выделенный том, ресурс переходит в Error, а условие ResourcesValid получает значение False. Причина указана в status.message. Пока ошибка не исправлена, изменения конфигурации не применяются.

Ресурсная модель

Bucket

Бакет — контейнер для хранения объектов. Создавайте бакеты с помощью инструкции Создать бакет.

Полный пример манифеста с дополнительными настройками и пояснениями к полям приведен в разделе Дополнительные настройки через CLI.

Пример манифеста с публичным чтением объектов и правилом CORS:

apiVersion: storage.stackland.yandex.cloud/v1alpha1
kind: Bucket
metadata:
  name: my-bucket
  namespace: my-project
spec:
  anonymousAccessFlags:
    read: true
    list: false
  cors:
    - allowedOrigins:
        - "https://example.com"
      allowedMethods:
        - "GET"
        - "PUT"
      allowedHeaders:
        - "*"
      maxAgeSeconds: 3600

Где:

  • metadata.name — имя бакета длиной от 3 до 63 символов. Должно быть уникальным в рамках всего хранилища и не должно иметь вид IP-адреса. Используйте строчные буквы латинского алфавита, цифры и дефисы; начинайте и заканчивайте имя буквой или цифрой.
  • metadata.namespace — проект, в котором создается бакет.
  • spec.anonymousAccessFlags — настройки публичного доступа к бакету:
    • read — разрешает анонимным пользователям читать объекты в бакете.
    • list — разрешает анонимным пользователям получать список объектов в бакете.
    • configRead — разрешает анонимным пользователям читать конфигурацию бакета, например CORS и правила жизненного цикла.
  • spec.cors — правила CORS для кросс-доменных запросов:
    • id — идентификатор правила, необязательное поле.
    • allowedOrigins — непустой список разрешенных источников запросов, обязательное поле.
    • allowedMethods — непустой список разрешенных HTTP-методов: GET, HEAD, POST, PUT, DELETE. Обязательное поле. Для составной загрузки из браузера разрешите POST.
    • allowedHeaders — список разрешенных заголовков в preflight-запросах.
    • exposeHeaders — список заголовков, доступных браузеру в ответе.
    • maxAgeSeconds — время кеширования preflight-ответа в секундах.

Дополнительные настройки бакета

Через spec ресурса Bucket также доступны:

  • maxSize — максимальный объем данных в бакете. Можно указать число байтов или значение с единицей измерения, например 100Gi. Если поле не задано или равно 0, ограничение для бакета отсутствует; общая емкость хранилища остается ограниченной.
  • versioning — состояние версионирования: DISABLED, ENABLED или SUSPENDED. По умолчанию DISABLED. После включения можно приостановить создание версий с помощью SUSPENDED, но вернуться к DISABLED нельзя.
  • tags — метки в формате пар «ключ — значение».
  • acl.grants — список разрешений доступа к бакету. Каждое разрешение содержит:
    • permission — READ или FULL_CONTROL;
    • grantType — ACCOUNT для выдачи доступа сервисному аккаунту;
    • grantee — kind: ServiceAccount, name и namespace получателя разрешения.
  • policy — документ политики доступа S3 с правилами Statement. Политику можно описать YAML-объектом прямо в манифесте.
  • disabledStaticKeyAuth — запрет аутентификации по статическим ключам при значении true. По умолчанию false.
  • lifecycleRules — правила жизненного цикла объектов.
  • objectLock — настройки блокировки версий объектов.

Публичные разрешения ACL на бакет не поддерживаются. Для анонимного доступа используйте anonymousAccessFlags.

Разрешение READ на бакет также позволяет читать его ACL с помощью GetBucketAcl.

Настройки в манифесте описывают желаемую конфигурацию бакета. Изменяйте ее через ресурс Bucket: изменения тех же настроек через S3 API будут заменены значениями из манифеста. Удаление поля возвращает его к значению по умолчанию, а удаление tags, acl, cors, policy или lifecycleRules очищает соответствующую настройку. Ограничения на отключение версионирования и Object Lock сохраняются.

Жизненный цикл объектов

Каждое правило lifecycleRules содержит обязательное поле enabled и необязательный идентификатор id. Для выбора объектов используйте filter:

  • prefix — префикс ключей объектов;
  • tags — метки объектов;
  • objectSizeGreaterThan и objectSizeLessThan — границы размера объектов.

Объект должен удовлетворять всем заданным условиям фильтра. Без фильтра правило распространяется на весь бакет.

Доступные действия:

  • expiration — удаление текущих объектов. Задайте один параметр: days для срока в днях, date для даты в формате RFC 3339 или expiredObjectDeleteMarker: true для удаления маркера удаления, у которого не осталось версий объекта.
  • noncurrentExpiration.noncurrentDays — удаление предыдущих версий через указанное количество дней после того, как они перестали быть текущими.
  • noncurrentDeleteMarkers.noncurrentDays — удаление нетекущих маркеров удаления через указанное количество дней.
  • abortIncompleteMultipartUpload.daysAfterExpiration — удаление частей незавершенной составной загрузки через указанное количество дней после ее начала.

Блокировка версий объектов

Чтобы защитить версии объектов от удаления, задайте objectLock.enabled: true и versioning: ENABLED. После включения Object Lock отключить блокировку или приостановить версионирование нельзя.

В objectLock.defaultRetention можно указать срок блокировки новых версий по умолчанию:

  • mode — GOVERNANCE или COMPLIANCE;
  • days или years — срок в днях или годах. Укажите только одно из полей.

В режиме GOVERNANCE пользователь с соответствующим разрешением может обойти блокировку. В режиме COMPLIANCE удалить защищенную версию до истечения срока нельзя. Блокировка относится к версиям: запись новой версии объекта остается возможной.

Статус бакета

После создания бакета его статус отображается в поле status.phase:

  • Pending — бакет ожидает создания.
  • Creating — бакет создается.
  • Ready — бакет готов к использованию.
  • Updating — бакет обновляется.
  • Deleting — бакет удаляется.
  • CreationFailed — не удалось создать бакет.
  • UpdateFailed — не удалось применить настройки бакета.
  • DeletionFailed — не удалось удалить бакет.

Описание ошибки доступно в status.message, а номер обработанной версии манифеста — в status.observedGeneration. После изменения манифеста проверьте, что бакет вернулся в Ready и status.observedGeneration совпадает с metadata.generation.

Управление доступом

Доступ к Object Storage управляется через Identity and Access Management. Для работы с бакетами приложениям необходимы:

  1. Сервисный аккаунт — создайте ServiceAccount в проекте.
  2. Роль — назначьте сервисному аккаунту роль storage.editor или storage.viewer с помощью ресурса AccessBinding.
  3. Ключ доступа — используйте статический ключ или выпустите на его основе временный ключ через STS.

Подробнее о создании ключей доступа читайте в инструкции Создать ключ доступа.

Политика доступа бакета

Если задана spec.policy, запросы дополнительно проверяются по ее правилам. Укажите Allow для нужных операций: на этапе проверки политики запрос отклоняется, если он не соответствует ни одному разрешающему правилу или подпадает под Deny. Например, политика, содержащая только запрет s3:DeleteObject, не разрешает s3:GetObject, поэтому чтение также может завершиться ошибкой 403.

При обращении к объектам учитываются и их собственные ACL: они могут разрешить доступ после проверки политики бакета. Порядок проверки прав соответствует Yandex Object Storage и описан в обзоре способов управления доступом. Формат правил приведен в документации по политикам доступа.

Временные ключи доступа

Security Token Service (STS) позволяет выдать приложению временный доступ к бакету с отдельной политикой и сроком действия. STS включается автоматически вместе с Object Storage. Эндпоинт для выдачи ключей — https://sts.sys.<домен кластера>.

Временный ключ содержит AccessKeyId, SecretAccessKey и SessionToken. Для запросов к S3 нужны все три значения. Срок действия возвращается в поле Expiration; после его окончания приложению нужен новый ключ.

Порядок выдачи ключа и пример подключения приведены в разделе Создать временный ключ доступа.

Пример назначения роли

apiVersion: iam.stackland.yandex.cloud/v1alpha1
kind: AccessBinding
metadata:
  name: app-storage-access
  namespace: my-project
spec:
  roleID: storage.editor
  subject:
    kind: ServiceAccount
    name: my-app-sa
    namespace: my-project

Подключение к хранилищу

Для подключения к Object Storage используйте следующие параметры:

  • Endpoint: storage.sys.<домен кластера>.
  • Access Key ID: получите из секрета сервисного аккаунта.
  • Secret Access Key: получите из секрета сервисного аккаунта.
  • Session Token: передавайте дополнительно при использовании временного ключа.

Пример настройки AWS CLI:

aws configure set aws_access_key_id <access-key-id>
aws configure set aws_secret_access_key <secret-access-key>
aws configure set default.region ru-central1
aws --endpoint-url=https://storage.sys.<cluster-domain> s3 ls
Предыдущая
Monitoring
Следующая
Дисковая подсистема