logo

Подготовка окружения к установке

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

Перед установкой подготовьте рабочее место администратора:

  • kubectl с доступом к целевому Kubernetes-кластеру;
  • helm версии 3.x;
  • доступ к Helm-репозиторию или локальным архивам чартов;
  • файл лицензии licence;
  • доступ к registry с образами Закрома.Хранение и Zakroma-ZDS.

Проверьте подключение:

1kubectl cluster-info
2kubectl get nodes
3helm version

Подготовка неймспейсов

Создайте отдельные неймспейсы для управляющего слоя Закрома.Хранение и слоя хранения ZDS:

1kubectl create namespace zakroma-storage
2kubectl create namespace zakroma-zds

Если образы скачиваются из приватного registry, создайте imagePullSecret в каждом неймспейсе:

1kubectl -n zakroma-storage create secret docker-registry regcred \
2  --docker-server=<registry> \
3  --docker-username=<username> \
4  --docker-password=<password>
5
6kubectl -n zakroma-zds create secret docker-registry regcred \
7  --docker-server=<registry> \
8  --docker-username=<username> \
9  --docker-password=<password>

Имя секрета укажите в values.yaml в параметре imagePullSecrets.

Подготовка лицензии и доверенных сертификатов

Создайте секрет с лицензией в неймспейсе zakroma-storage:

1kubectl -n zakroma-storage create secret generic licence \
2  --from-file=licence=./licence

Если внешние сервисы используют внутренний CA, подготовьте ConfigMap с цепочкой доверенных сертификатов и смонтируйте его в Pod через values.yaml:

1kubectl -n zakroma-storage create configmap ca-certificates \
2  --from-file=ca-certificates.crt=./ca-certificates.crt

Подготовка PostgreSQL

PostgreSQL должен быть доступен из неймспейса zakroma-storage.

Подробная инструкция по подготовке базы данных описана в статье Настройка PostgreSQL. Для расчёта max_connections используйте Расчёт максимального количества подключений к PostgreSQL.

Подготовьте:

  • базу данных для Закрома.Хранение;
  • пользователя с правами на создание и изменение схем;
  • схемы core, permission, notification, seclog, если их создание не делегируется приложению;
  • параметры подключения: host, port, database, user, password, sslmode.

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

Подготовка Keycloak или другого провайдера авторизации

Общие варианты авторизации и настройки Keycloak описаны в статье Настройка авторизации.

Если используется Keycloak:

  • создайте realm, например zakroma;
  • создайте client для Admin UI и Gateway;
  • задайте clientId, secret и redirect URI;
  • выберите стратегию синхронизации пользователей: roles или groups;
  • назначьте пользователям нужную роль или группу;
  • обеспечьте доступность Keycloak по HTTPS из Kubernetes-кластера.

Если используется file, ldap или oidc, подготовьте соответствующие параметры и внесите их в блок global.config.auth в values.yaml.

Подготовка Kafka

Kafka нужна для событий аудита, webhooks, notification, seclog и мультикластера. Если эти функции не используются, Kafka можно не включать в values.yaml.

Если Kafka используется, подготовьте:

  • список адресов подключения к брокерам Kafka, доступных из Kubernetes-кластера;
  • параметры SASL/TLS или mTLS, если они требуются;
  • trusted CA для TLS-подключений;
  • топики или разрешение на auto-creation топиков.

Подготовка хранилища для ZDS

Для ZDS подготовьте StorageClass, который поддерживает нужный режим доступа и размер PersistentVolume.

Проверьте:

1kubectl get storageclass
2kubectl -n zakroma-zds get pvc

Актуальный ZDS-чарт 3.1.1 поддерживает режимы EC и FC (Full Copy). Количество Pod, томов и частей данных или полных копий должно соответствовать выбранной конфигурации. Параметры описаны в Справочнике ZDS-чарта 3.1.1. Для базового примера EC 2+1 используются три Pod; режим FC не означает обязательную установку одного Pod или одного тома.

Подготовка Ingress, DNS и TLS

Подготовьте Ingress Controller и определите его IngressClass. В базовой инструкции Helm 6.1.1 он задаётся в отдельных манифестах Ingress; при использовании встроенных Ingress чарта — в соответствующих параметрах values.yaml.

Подготовьте DNS-записи для актуальной схемы доступа:

НазначениеDNS-имяПример
Admin UI и Management API<ADMIN_UI_FQDN>admin.example.internal
S3 API рабочих областей*.<BASE_DOMAIN>*.s3.example.internal

Обе записи направьте на внешний адрес Ingress Controller: A — на его IP-адрес либо CNAME — на DNS-имя балансировщика. Адрес должен быть доступен пользователям и S3-клиентам; ClusterIP сервиса для внешних DNS-записей не используется.

<BASE_DOMAIN> — значение global.config.base_domain без протокола и wildcard; в примере — s3.example.internal. S3-клиент обращается к https://<WORKSPACE>.<BASE_DOMAIN>, например https://test.s3.example.internal, а имя бакета передаёт в пути. Запись только для <BASE_DOMAIN> не заменяет wildcard-запись для рабочих областей.

Отдельное внешнее DNS-имя для сервиса gateway в этой схеме не требуется: Admin UI и Management API используют один адрес https://<ADMIN_UI_FQDN>, который также задаётся в переменной global.config.adminUi.basepath. В чартах 6.1.0 и 6.1.1 сервис zakroma-storage-admin-ui по умолчанию направляет запросы на внутренний management-порт сервиса Gateway (service.gatewayProxy.enabled: true). Сам компонент Gateway остаётся в составе Закрома.Хранение, но отдельный публичный hostname для него создавать не нужно.

TLS можно настроить через заранее выпущенный сертификат или через cert-manager. Сертификат должен покрывать публичные FQDN, через которые пользователи и S3-клиенты обращаются к системе.

Для базового сценария подготовьте сертификат Admin UI на <ADMIN_UI_FQDN> и S3-сертификат на *.<BASE_DOMAIN>. Wildcard в имени хоста Ingress и в TLS-сертификате покрывает один уровень имени: для этой схемы не используйте *.*.<BASE_DOMAIN>. Ограничения имён описаны в документации Kubernetes Ingress.

На рабочем месте администратора проверьте разрешение конкретных имён, заменив примеры своими значениями:

1dig +short admin.example.internal
2dig +short test.s3.example.internal

Ожидается адрес Ingress Controller либо CNAME-цепочка, ведущая к нему. Проверяйте имя рабочей области, а не буквальную строку со звёздочкой. Совпадение DNS не подтверждает работоспособность маршрутов и TLS: после установки выполните проверки Admin UI и S3 из базовой инструкции.

Preflight-проверка

Перед установкой проверьте, что базовые объекты и доступы готовы:

1kubectl get namespace zakroma-storage zakroma-zds
2kubectl -n zakroma-storage get secret licence
3kubectl get ingressclass
4kubectl get storageclass

После заполнения values.yaml выполните dry-run:

1helm template zakroma-storage <chart-ref> -n zakroma-storage -f values.yaml
2helm template zakroma-zds <chart-ref> -n zakroma-zds -f values.yaml

Если всё проходит без ошибок, переходите к установке соответствующих Helm-чартов.

Смотрите также
Настройка PostgreSQL
Расчёт максимального количества подключений к PostgreSQL
Настройка авторизации
Установка базового кластера
Описание и примеры values.yaml