Хранилище

PersistentVolumeClaims

PersistentVolumeClaim ‒ ресурс РОСА Кубис, который используется для автоматического провижининга PV. В случае использования графического интерфейса Комплекса после создания PVC разрешено увеличение запрашиваемого объема хранилища (рисунок 339).

Рисунок 339 ‒ Запрашиваемый объем хранилища

На странице "PersistentVolumeClaims" можно создать, отредактировать, удалить или просмотреть ранее созданные PersistentVolumeClaim.

Создание PersistentVolumeClaim

Чтобы создать PersistentVolumeClaim, нужно нажать на кнопку + Добавить PersistentVolumeClaim.

Обязательными для заполнения в этом окне полями являются: имя PersistentVolumeClaim, режим доступа, запрашиваемый объем хранилища, название StorageClass:

  • AccessMode – выпадающий список со значениями:
  • ReadWriteOnce – PV может быть смонтирован на чтение и запись к одному поду;
  • ReadOnlyMany – PV может быть смонтирован на много подов в режиме только для чтения;
  • ReadWriteMany – PV может быть смонтирован к множеству подов в режиме чтения и записи;
  • Название StorageClass – выпадающий список имен, созданных в кластере StorageClass;
  • Запрашиваемый объем хранилища (Storage capacity). Чтобы задать объем хранилища, нужно:
  • выбрать единицу измерения стандартную для Kubernetes ‒ байт (B), кибибайт (Ki), мебибайт (Mi), гибибайт (Gi);
  • указать числовое значение запрашиваемого объема хранилища;
  • VolumeName ‒ выпадающий список PV, созданных в кластере. Используется для принудительной связи PVC с ранее созданным PV. Требует также связи на стороне PV.

При необходимости можно:

  • задать лейблы и аннотации PersistentVolumeClaim;
  • в блоке "Селектор PV" задать совпадающие лейблы и выражения для PV, чтобы определить перечень требуемых PV при привязке к ним PersistentVolumeClaim.

Просмотр PersistentVolumeClaim

Страница просмотра PVC состоит из четырех вкладок: "PVC", "PersistentVolumes", "Лейблы и аннотации" и "События".

Если администратор удаляет PVC, который используется в поде, PVC не удаляется немедленно. Удаление PVC откладывается до тех пор, пока PVC не будет использован в подах.

ConfigMaps

ConfigMap ‒ ресурс РОСА Кубис, который используется для хранения неконфиденциальных данных в виде пар "ключ-значение". Поды используют ConfigMaps как переменные среды, аргументы командной строки или как файлы конфигурации в value. Также ConfigMaps используется другими объектами, например, для настройки, без прямого доступа к поду.

ConfigMap не обеспечивает секретность или шифрование. Если данные являются конфиденциальными, следует использовать Secret или дополнительные (сторонние) инструменты для обеспечения конфиденциальности данных вместо ConfigMap.

На странице "ConfigMaps" можно создать, отредактировать, удалить или просмотреть ранее созданные ConfigMap (рисунок 340).

Рисунок 340 ‒ Страница "ConfigMaps"

Создание ConfigMap

Чтобы создать ConfigMap, нужно нажать на кнопку + Добавить ConfigMap.

В открывшемся окне возможно заполнить:

  • имя ConfigMap;
  • возможность редактирования;
  • текстовые ключи;
  • бинарные ключи.

Для заполнения текстового ключа требуется нажать кнопку +, в открывшемся модальном окне ввести ключ, значение и нажать кнопку Добавить (рисунок 341).

Рисунок 341 ‒ Добавление ключа

Для загрузки бинарного ключа следует нажать кнопку + (рисунок 342) и загрузить ключ в формате bin (рисунок 343).

Рисунок 342 ‒ Добавление бинарного ключа

Рисунок 343 ‒ Бинарный ключ добавлен

Примечание ‒ Если установить в поле "Возможность редактирования" значение "Нередактируемый", ConfigMap не будет доступен для изменения.

Чтобы удалить элемент, требуется нажать на Удалить в строке элемента.

После завершения создания ConfigMap необходимо нажать кнопку Сохранить.

Редактирование ConfigMap

После создания можно посмотреть и отредактировать ConfigMaps.

Необходимо перейти на вкладку "Манифест", чтобы изменить ConfigMaps с помощью YAML-манифеста. После внесения изменений в манифест требуется выполнить проверку. Результат проверки будет доступен в правой части экрана. Можно раскрыть блок результата проверки, чтобы увидеть полный манифест. Если валидация формата манифеста ConfigMaps не пройдена, недоступна проверка манифеста (рисунок 344).

Рисунок 344 ‒ Проверка манифеста

Далее следует сохранить изменения, внесенные в манифест. Несохраненные данные не будут применены.

Secrets

Secret ‒ ресурс РОСА Кубис, который содержит небольшое количество конфиденциальных данных, таких как пароль, токен или ключ. Использование Secret снижает риск раскрытия данных во время рабочего процесса при создании, просмотре и редактировании подов.

Секреты Комплекса по умолчанию хранятся в незашифрованном виде в базовом хранилище данных сервера API (etcd). Для безопасного использования Secrets выполняется шифрование при хранении секретов, настройка правил RBAC с доступом к секретам с минимальными привилегиями, ограничение доступа к определенным контейнерам, использование внешних поставщиков секретных хранилищ.

На странице "Secrets" можно создать, отредактировать, удалить или просмотреть ранее созданные секреты (рисунок 345).

Рисунок 345 ‒ Страница "Secrets"

Создание Secret

Чтобы создать Secret, нужно нажать на кнопку + Добавить Secret.

В открывшемся окне возможно заполнить:

  • имя Secret;
  • возможность редактирования. Если установить в поле "Возможность редактирования" значение "Нередактируемый", секрет не будет доступен для изменения;
  • тип Secret. Если выбран тип kubernetes.io/service-account-token, необходимо выбрать "ServiceAccountName", и дополнительно доступно добавление "Аннотации";
  • добавить лейблы;
  • ключи.

Для заполнения текстового ключа следует нажать + в открывшемся модальном окне:

  • Если был выбран тип секрета Opaque или kubernetes.io/service-account-token, то ввести ключ, значение и нажать кнопку Добавить (рисунок 346).

Рисунок 346 ‒ Добавление ключа

  • Если был выбран тип секрета kubernetes.io/dockercfg или kubernetes.io/dockerconfigjson, загрузить файл Docker config в формате JSON (рисунок 347) и нажать кнопку Добавить (рисунок 348).

Рисунок 347 ‒ Загрузка файла ключа

Рисунок 348 ‒ Добавление файла ключа

Пример Docker config:

{
"auths": {
"your.private.registry.example.com": {
"username": "janedoe",
"password": "xxxxxxxxxxx",
"email": "jdoe@example.com",
"auth": "c3R...zE2"
}
}
}

где auth ‒ пара "username:password", закодированная в base64.

  • Если выбран тип секрета kubernetes.io/tls, загрузить файл с сертификатом клиента и файл с ключом клиента (рисунок 349), нажать кнопку Добавить (рисунок 350).

Рисунок 349 ‒ Загрузка файлов

Рисунок 350 ‒ Добавление файлов

  • Если выбран тип секрета kubernetes.io/ssh-auth, загрузить файл ключа пользователя для подключения по SSH (рисунок 351) и нажать кнопку Добавить (рисунок 352).

Рисунок 351 ‒ Загрузка файла ключа

Рисунок 352 ‒ Добавление файла ключа

  • Если выбран тип секрета kubernetes.io/basic-auth, указать имя и пароль в ключе, нажать кнопку Добавить (рисунок 353).

Рисунок 353 ‒ Добавление ключа

  • Если выбран тип bootstrap.kubernetes.io/token, к заполнению доступны (рисунок 354):
    • auth-extra-groups ‒ список имен групп, которые должны быть аутентифицированы дополнительно к группе system:bootstrappers;
    • expiration ‒ окончание периода действия токена;
    • token-id ‒ идентификатор токена;
    • token-secret ‒ секрет токена;
    • usage-bootstrap-authentication ‒ флаг использования токена для аутентификации;
    • usage-bootstrap-signing ‒ флаг использования токена для подписания.

Рисунок 354 ‒ Добавление ключа

После завершения создания секрета необхоимо нажать кнопку Сохранить.

Просмотр и редактирование Secret

На странице просмотра доступны вкладки:

  • Secret;
  • Лейблы и аннотации;
  • Манифест.

Если при создании Secret в поле "Возможность редактирования" было установлен "Нередактируемый", секрет доступен только для просмотра.

Если при создании было выбрано "Редактируемый" или "Не задано", к редактированию доступны:

  • возможность редактирования;
  • тип Secret;
  • дополнительные поля в зависимости от типа, созданного Secret;
  • добавление лейблов и аннотаций;
  • ключи.

Чтобы изменить Secret с помощью YAML-манифеста, нужно перейти на вкладку "Манифест". Манифест не будет доступен к редактированию, если его тип ‒ "Нередактируемый". После внесения изменений в манифест требуется выполнить проверку. Результат проверки будет доступен в правой части экрана. Можно раскрыть блок результата проверки, чтобы увидеть полный манифест (рисунок 355). Если валидация формата манифеста Secret не пройдена, недоступна проверка манифеста.

Рисунок 355 ‒ Проверка манифеста

Далее следует сохранить изменения, внесенные в манифест. Несохраненные данные не будут применены.