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

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

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

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

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

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

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

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

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

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

Copy
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:

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

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

Copy
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.

Проверьте:

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

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

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

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

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

Обе записи направьте на внешний адрес 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.0.4 сервис 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.

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

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

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

Preflight-проверка

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

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

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

Copy
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-чартов.