Установка базового кластера

Назначение и ограничения

Базовый кластер в этой инструкции состоит из пяти компонентов Закрома.Хранение и отдельного кластера ZDS из трёх Pod. Для установки используются Helm и существующий Kubernetes-кластер.

Управляющий слой включает Admin UI, Gateway, Core, Composer и Worker. Каждый компонент работает в одной реплике. ZDS хранит данные объектов по схеме Erasure Coding 2+1.

В базовом сценарии используются локальные пользователи. Kafka, CDN, SecLog, Notification и автоматическое масштабирование не включаются. Варианты с внешними источниками пользователей описаны отдельно: LDAP и Keycloak.

Ограничения отказоустойчивости

В примере используется один внешний PostgreSQL, который остаётся единой точкой отказа. Для продуктивной инсталляции необходим отказоустойчивый кластер PostgreSQL, а ресурсы для узлов кластера рекомендуется рассчитать совместно с технической поддержкой.

EC 2+1 обеспечивает избыточность данных ZDS, но не компенсирует недоступность PostgreSQL, Ingress или единственной реплики компонента Закрома.Хранение. Эта конфигурация не является полностью отказоустойчивой установкой продукта.

Устанавливаемые компоненты

Имена неймспейсов, релизов и Secrets (regcred, licence и TLS Secrets) используются только в примере. При их изменении используйте те же имена в конфигурации и командах.

Схема установки

Ingress принимает HTTPS-запросы к Admin UI и S3 API и направляет их к сервисам в неймспейсе zakroma-storage. Core, Gateway и Worker используют внешний PostgreSQL. Composer обращается к ZDS в неймспейсе zakroma-zds. Каждый Pod ZDS использует собственные постоянные тома и взаимодействует с двумя другими Pod ZDS.

Установку выполняйте с рабочего места администратора с доступом к Kubernetes API. Перед началом проверьте командой kubectl config current-context, что выбран контекст целевого Kubernetes-кластера.

Минимальные требования

Общие требования приведены в Подготовке окружения к установке.

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

До начала установки:

1. Подготовьте PostgreSQL по инструкции Настройка PostgreSQL.
2. Рассчитайте требуемое количество подключений по инструкции Расчёт max_connections PostgreSQL.
3. Подготовьте записи DNS для <ADMIN_UI_FQDN> и *.<BASE_DOMAIN>, направленные на адрес Ingress. Например, Admin UI — admin.example.internal, базовый домен — s3.example.internal, рабочая область — test.s3.example.internal.
4. Выпустите сертификаты для Admin UI и *.<BASE_DOMAIN>. В примере S3-клиент обращается к <WORKSPACE>.<BASE_DOMAIN> и передаёт имя бакета в пути (Path-style). Wildcard-сертификат покрывает только один уровень DNS-имени; не используйте для Ingress wildcard с двойным уровнем вложенности *.*.<BASE_DOMAIN>.
5. Проверьте синхронизацию времени worker-узлов и рабочего места: расхождение времени влияет на работоспособность TLS и подпись S3-запросов. Если необходима детальная схема взаимодействия компонентов в кластере Kubernetes, обратитесь в техническую поддержку.

Admin UI и Management API используют общий адрес https://<ADMIN_UI_FQDN>; отдельное внешнее DNS-имя для сервиса Gateway не требуется. При штатном service.gatewayProxy.enabled: true сервис zakroma-storage-admin-ui направляет запросы на внутренний management-порт сервиса Gateway. Для S3 используются адреса рабочих областей https://<WORKSPACE>.<BASE_DOMAIN>. DNS-записи и их проверка приведены в Подготовке Ingress, DNS и TLS.

Установка

1. Получение чартов

Получите у поставщика архивы zakroma-storage-6.0.4.tgz и zds-3.1.0.tgz. Создайте отдельный рабочий каталог и разместите в нём архивы и подготовленные файлы:

Copy
1k8s-install-6.0.4/
2  charts/
3    zakroma-storage-6.0.4.tgz
4    zds-3.1.0.tgz
5  files/
6    licence
7    registry-config.json
8    admin.crt
9    admin.key
10    s3.crt
11    s3.key
12    ca.crt
13  storage/
14  zds/

Поместите конфигурацию доступа к registry в registry-config.json. Если сертификаты выпущены промежуточным CA, включите в admin.crt и s3.crt сертификат сервера и промежуточную цепочку. В ca.crt поместите доверенные CA для проверок.

Все дальнейшие команды выполняйте из каталога k8s-install-6.0.4. Проверьте версии и содержимое архивов, а также доступность PyYAML:

Copy
1umask 077
2mkdir -p storage zds
3helm show chart charts/zakroma-storage-6.0.4.tgz
4helm show chart charts/zds-3.1.0.tgz
5tar -tzf charts/zakroma-storage-6.0.4.tgz
6tar -tzf charts/zds-3.1.0.tgz
7python3 -c 'import yaml'

Ожидаемый результат: имена чартов — zakroma-storage и zds, версии — 6.0.4 и 3.1.0 соответственно. У ZDS appVersion должен быть 2.1.0. В архивах должны присутствовать Chart.yaml, values.yaml и шаблоны; у Закрома.Хранение — также подчинённые чарты. Проверка импорта PyYAML должна завершиться без ошибок.

Просмотрите исходные параметры чартов:

Copy
1helm show values charts/zakroma-storage-6.0.4.tgz
2helm show values charts/zds-3.1.0.tgz

Установка из локальных файлов

В этой инструкции Helm-чарты устанавливаются из локальных архивов. Доступ к внешнему Helm-репозиторию не требуется. Образы контейнеров загружаются отдельно: обеспечьте доступ к registry продукта или заранее подготовленному зеркалу.

2. Подготовка неймспейсов и секретов

Проверьте контекст и создайте неймспейсы, если они ещё не существуют:

Copy
1kubectl config current-context
2kubectl get nodes
3kubectl create namespace zakroma-storage --dry-run=client -o yaml | kubectl apply -f -
4kubectl create namespace zakroma-zds --dry-run=client -o yaml | kubectl apply -f -

Создайте registry Secret в каждом неймспейсе из подготовленного файла, не передавая пароль аргументом команды:

Copy
1kubectl -n zakroma-storage create secret generic regcred \
2  --type=kubernetes.io/dockerconfigjson \
3  --from-file=.dockerconfigjson=files/registry-config.json
4kubectl -n zakroma-zds create secret generic regcred \
5  --type=kubernetes.io/dockerconfigjson \
6  --from-file=.dockerconfigjson=files/registry-config.json

Поместите лицензию в files/licence. Проверьте, что файл существует и не пуст, затем создайте Secret с лицензией:

Copy
1test -s files/licence
2kubectl -n zakroma-storage create secret generic licence \
3  --from-file=licence=files/licence

Ожидаемый результат: Secret regcred создан в обоих неймспейсах, Secret licence — в неймспейсе zakroma-storage.

Если Secret уже существует, проверьте его назначение и актуальность. Не удаляйте и не перезаписывайте Secret другой установки. На шаге 12 выполняется повторный Helm upgrade без повторного создания Secrets.

3. Настройка TLS-секретов для Ingress

На рабочем месте проверьте исходные сертификаты:

Copy
1openssl x509 -in files/admin.crt -noout -subject -issuer -dates -ext subjectAltName
2openssl x509 -in files/s3.crt -noout -subject -issuer -dates -ext subjectAltName
3openssl verify -CAfile files/ca.crt -untrusted files/admin.crt files/admin.crt
4openssl verify -CAfile files/ca.crt -untrusted files/s3.crt files/s3.crt

Ожидаемый результат проверки цепочки — OK для обоих сертификатов. Проверьте сроки действия и наличие DNS-имён в расширении SAN.

Создайте TLS Secrets в неймспейсе, в котором находятся Ingress:

Copy
1kubectl -n zakroma-storage create secret tls admin-tls \
2  --cert=files/admin.crt --key=files/admin.key
3kubectl -n zakroma-storage create secret tls s3-tls \
4  --cert=files/s3.crt --key=files/s3.key

Если сертификаты уже выпущены через cert-manager, используйте готовые TLS Secrets при настройке Ingress. Установка cert-manager и добавление issuer-аннотаций для этого примера не требуются.

4. Настройка Закрома.Хранение

Используются Helm-чарт 6.0.4 и образы 2.9.4.

Создайте storage/values-storage.yaml — единый файл конфигурации релиза Закрома.Хранение. Укажите в нём все настройки, включая пароли и ключи. Этот же файл используется для проверки, установки и повторного Helm upgrade.

Добавляйте фрагменты этого шага в существующие блоки global и компонентов, не создавая повторяющихся YAML-ключей. Не заменяйте файл приведёнными ниже фрагментами целиком: сохраните остальные параметры без изменений и измените только перечисленные параметры. Неуказанные параметры наследуются из чарта.

4.1. Настройка подключения к PostgreSQL

В примере Core, Gateway и Worker подключаются к одной базе данных PostgreSQL. Во всех блоках могут использоваться одинаковые хост, порт, пользователь, пароль, имя базы и SSL-режим; значение search_path оставьте соответствующим компоненту.

Количество схем или БД для компонента worker (шардов БД) определяется совместно с технической поддержкой в соответствии с требованиями к RPS и планируемому количеству объектов.

В storage/values-storage.yaml задайте общие параметры для Core и Gateway и отдельный блок Worker:

Copy
1global:
2  config:
3    database:
4      host: "<POSTGRESQL_FQDN>"
5      port: 5432
6      name: "zakroma"
7      user: "<POSTGRESQL_USER>"
8      password: "<POSTGRESQL_PASSWORD>"
9      sslmode: "<POSTGRESQL_SSLMODE>"
10      connection_timeout: "10s"
11      target_session_attrs: "read-write"
12      core:
13        search_path: "core"
14        max_open_conns: 10
15        max_idle_conns: 5
16      gateway:
17        search_path: "permission"
18        max_open_conns: 10
19        max_idle_conns: 5
20    workers:
21      worker0:
22        database:
23          host: "<POSTGRESQL_FQDN>"
24          port: 5432
25          name: "zakroma"
26          user: "<POSTGRESQL_USER>"
27          password: "<POSTGRESQL_PASSWORD>"
28          sslmode: "<POSTGRESQL_SSLMODE>"
29          search_path: "worker0"
30          max_open_conns: 10
31          max_idle_conns: 5
32          connection_timeout: "10s"
33          target_session_attrs: "read-write"

Core и Gateway используют общие параметры global.config.database и настройки своей схемы. Для Worker укажите параметры подключения отдельно в global.config.workers.worker0.database.

Защита чувствительных данных

Файл storage/values-storage.yaml содержит пароли и ключи вместе с остальными настройками. Ограничьте права доступа к файлу до 600, исключите его из Git и незащищённых резервных копий. Эти же требования применяются к файлу конфигурации ZDS.

Не передавайте пароли через --set password=.... Не выводите сформированные манифесты с реальными секретами в терминал и не записывайте команды с секретами в журналы.

Файл values не зашифрован

Значения в values-файле хранятся открытым текстом. Helm сохраняет параметры релиза, а чарт может включать пароли и ключи в Secret и ConfigMap, в том числе в конфигурацию Gateway.

Ограничьте доступ к этим объектам средствами Kubernetes RBAC. Защитите резервные копии в соответствии с требованиями вашей организации.

Helm-чарт 6.0.4 также поддерживает подключение существующих Секретов. Этот способ настройки не является обязательным для базового сценария. Ключи и приоритеты параметров описаны в справочнике чарта.

4.2. Настройка домена, TLS и локальной авторизации

Добавьте параметры в существующий storage/values-storage.yaml:

Copy
1global:
2  image:
3    tag: "2.9.4"
4    pullPolicy: IfNotPresent
5  imagePullSecrets:
Развернуть

В этом примере встроенные Ingress чарта отключены. Создайте два Ingress отдельными манифестами: это позволяет использовать подготовленный Ingress Controller без nginx/cert-manager-аннотаций из исходных values.

Эти Ingress не управляются Helm-релизом. Установка Ingress Controller в инструкцию не входит.

Создайте storage/ingress-admin.yaml:

Copy
1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: zakroma-storage-admin-ui
5  namespace: zakroma-storage
6spec:
7  ingressClassName: "<INGRESS_CLASS>"
8  tls:
9    - secretName: admin-tls
10      hosts:
11        - "<ADMIN_UI_FQDN>"
12  rules:
13    - host: "<ADMIN_UI_FQDN>"
14      http:
15        paths:
16          - path: /
17            pathType: Prefix
18            backend:
19              service:
20                name: zakroma-storage-admin-ui
21                port:
22                  number: 80

Создайте storage/ingress-s3.yaml:

Copy
1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: zakroma-storage-s3gateway
5  namespace: zakroma-storage
6spec:
7  ingressClassName: "<INGRESS_CLASS>"
8  tls:
9    - secretName: s3-tls
10      hosts:
11        - "*.<BASE_DOMAIN>"
12  rules:
13    - host: "*.<BASE_DOMAIN>"
14      http:
15        paths:
16          - path: /
17            pathType: Prefix
18            backend:
19              service:
20                name: zakroma-storage-gateway
21                port:
22                  name: s3api

При необходимости добавьте в metadata.annotations настройки выбранного Ingress Controller: ограничения размера тела запроса, тайм-ауты, потоковую передачу и обработку заголовков.

Сохранение параметров S3-запроса

Не включайте переписывание Host, URI, строки параметров запроса или нормализацию кодирования пути, нарушающую подпись AWS Signature V4. Проверьте работу выбранного Ingress Controller с помощью S3-теста на шаге 11.

Порты Service Gateway заданы полным списком: S3 80 → 8080, management 81 → 8180, metrics 82 → 8181. Это разделяет management и metrics, которые в исходных значениях подчарта используют одинаковый Service-порт 81.

В global.config.auth.file.list укажите локальных пользователей и их пароли. В zakroma-storage-gateway.config.jwt.keys укажите собственную ключевую пару JWT. Оба блока находятся в storage/values-storage.yaml; параметры PostgreSQL из подраздела 4.1 сохраните без изменений.

Группа clouduser здесь указана в качестве примера. Задайте полный список пользователей: он переопределяет список пользователей и групп из чарта.

Для локальной авторизации Gateway использует ключ подписи JWT. Создайте собственную пару ключей вместо демонстрационной пары innerkey из подчарта.

На рабочем месте администратора создайте ключи один раз для новой установки. При повторном Helm upgrade сохраните ту же пару:

Copy
1test ! -e files/storage-jwt.key && \
2  openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out files/storage-jwt.key
3openssl rsa -in files/storage-jwt.key -RSAPublicKey_out -out files/storage-jwt.pub
4chmod 600 files/storage-jwt.key storage/values-storage.yaml

Вставьте ключи в уже заполненный файл без вывода закрытого ключа в терминал. Команда ниже заменяет только <LOCAL_JWT_PUBLIC_KEY> и <LOCAL_JWT_PRIVATE_KEY>. Содержимое PEM записывается в строку с буквальными \n, как ожидает шаблон Gateway:

Copy
1python3 - <<'PY'
2from pathlib import Path
3import yaml
4path = Path('storage/values-storage.yaml')
5values = yaml.safe_load(path.read_text())
6key = values['zakroma-storage-gateway']['config']['jwt']['keys'][0]
7key['rsa_public_key'] = Path('files/storage-jwt.pub').read_text().strip().replace('\n', r'\n')
8key['rsa_secret_key'] = Path('files/storage-jwt.key').read_text().strip().replace('\n', r'\n')
9path.write_text(yaml.safe_dump(values, allow_unicode=True, sort_keys=False))
10path.chmod(0o600)
11PY

5. Настройка ZDS

В примере ZDS устанавливается в том же Kubernetes-кластере, что и Закрома.Хранение. Самостоятельная установка слоя хранения описана в Установке базового кластера ZDS.

Подключение существующего ZDS

Если ZDS уже установлен на внешних узлах, пропустите создание его неймспейса, Secrets, файла values и Helm-релиза, а также Kubernetes-проверки кластера ZDS. При регистрации хранилища укажите фактические адреса API и параметры TLS (если применимо).

В текущей инструкции используется Helm-чарт 3.1.0 и образ ZDS 2.1.0. Создайте zds/values-zds.yaml — файл конфигурации ZDS. Добавьте в него настройки из примеров ниже, включая ключи доступа. Используйте его при установке ZDS; для Закрома.Хранение используется storage/values-storage.yaml.

5.1. Настройка API, межузлового взаимодействия и EC

Copy
1replicaCount: 3
2accessKey: "<ZDS_ACCESS_KEY>"
3secretKey: "<ZDS_SECRET_KEY>"
4image:
5  tag: "2.1.0"
6  pullPolicy: IfNotPresent
7imagePullSecrets:
8  - name: regcred
9config:
10  protocolPrefix: "http://"
11  server:
12    host: "0.0.0.0"
13    port: 8080
14    tls:
15      enable: false
16  clusterServer:
17    host: "0.0.0.0"
18    port: 8081
19    tls:
20      enable: false
21persistence:
22  storageMode: EC
23  dataPart: 2
24  parityPart: 1
25affinity:
26  podAntiAffinity:
27    requiredDuringSchedulingIgnoredDuringExecution:
28      - labelSelector:
29          matchLabels:
30            app: zds
31            release: zakroma-zds
32        topologyKey: kubernetes.io/hostname

Метки app: zds и release: zakroma-zds соответствуют шаблону StatefulSet. При изменении имени релиза измените selector. Для обязательной конфигурации anti-affinity необходимы три подходящих worker-узла с учётом taints, ресурсов и топологии PVC; иначе часть Pod не будет запущена и останется в состоянии Pending.

Порты ZDS

В этом Helm-сценарии API ZDS использует порт 8080, а межузловое взаимодействие — 8081. При добавлении хранилища в Admin UI указывайте API-порт 8080. Кластерный порт не публикуйте через Ingress.

В accessKey и secretKey файла zds/values-zds.yaml укажите собственную пару ключей. Одна пара используется всеми тремя Pod этого ZDS-кластера. Не используйте демонстрационные значения из чарта. Ключи понадобятся при регистрации хранилища на шаге 11.

5.2. Настройка постоянных томов

Добавьте параметры в существующий блок persistence:

Copy
1persistence:
2  size: "<DATA_PVC_SIZE>"
3  storageClass: "<DATA_STORAGE_CLASS>"
4  storageClassZds: "HDD"
5  volumes:
6    - default
7  SystemVolumeSize: "<SYSTEM_PVC_SIZE>"
8  storageClassSystemVolume: "<SYSTEM_STORAGE_CLASS>"
9  accessMode: ReadWriteOnce
10systemVolumeMountPath: "/mnt/ps/system"

Сохранность постоянных томов

После ввода в эксплуатацию сохраняйте имена StatefulSet, неймспейсов и групп хранения.

6. Проверка конфигурации

Замените значения из примеров фактическими значениями своего окружения. Если используется LDAP или Keycloak, сначала измените блоки в storage/values-storage.yaml по соответствующей статье. Передайте подготовленный файл через -f, как в командах ниже.

Проверьте конфигурации обоих чартов:

Copy
1chmod 600 storage/values-storage.yaml zds/values-zds.yaml
2helm lint charts/zakroma-storage-6.0.4.tgz \
3  -f storage/values-storage.yaml
4helm lint charts/zds-3.1.0.tgz \
5  -f zds/values-zds.yaml

Сформируйте манифесты и сохраните их во временном каталоге с ограниченным доступом. Проверьте манифесты командой kubectl apply --dry-run=client. Не выводите содержимое файлов в терминал: они содержат реальные значения конфигурации и секреты. Если вывод необходим, ограничьте его или используйте инструменты хранения секретов.

Copy
1umask 077
2RENDER_DIR=$(mktemp -d)
3helm template zakroma-storage charts/zakroma-storage-6.0.4.tgz -n zakroma-storage \
4  -f storage/values-storage.yaml >"$RENDER_DIR/storage.yaml"
5helm template zakroma-zds charts/zds-3.1.0.tgz -n zakroma-zds \
6  -f zds/values-zds.yaml >"$RENDER_DIR/zds.yaml"
7kubectl apply --dry-run=client -f "$RENDER_DIR/storage.yaml"
8kubectl apply --dry-run=client -f "$RENDER_DIR/zds.yaml"
9kubectl apply --dry-run=client -f storage/ingress-admin.yaml -f storage/ingress-s3.yaml

Ожидаемый результат: helm lint и проверка манифестов завершаются без ошибок. В манифестах Helm должны присутствовать пять Deployments компонентов Закрома.Хранение, StatefulSet ZDS с тремя репликами, обязательная anti-affinity и два шаблона PVC. Два Ingress проверяются отдельно и отсутствуют в манифестах Helm.

После проверки удалите только созданные этой командой временные файлы и пустой каталог:

Copy
1rm -f -- "$RENDER_DIR/storage.yaml" "$RENDER_DIR/zds.yaml"
2rmdir -- "$RENDER_DIR"
3unset RENDER_DIR

7. Проверка лицензии и TLS-секретов

В рабочем каталоге проверьте имена и типы объектов:

Copy
1kubectl -n zakroma-storage get secret regcred licence admin-tls s3-tls
2kubectl -n zakroma-zds get secret regcred
3kubectl -n zakroma-storage get secret admin-tls -o jsonpath='{.data.tls\.crt}' \
4  | openssl base64 -d -A | openssl x509 -noout -subject -dates -ext subjectAltName
5kubectl -n zakroma-storage get secret s3-tls -o jsonpath='{.data.tls\.crt}' \
6  | openssl base64 -d -A | openssl x509 -noout -subject -dates -ext subjectAltName

Ожидаемые типы Secrets — kubernetes.io/dockerconfigjson для registry и kubernetes.io/tls для сертификатов. Сертификаты должны совпадать с проверенными на шаге 3.

Наличие Secret лицензии не заменяет проверку файла в Gateway после установки.

8. Проверки окружения перед установкой

Проверьте неймспейсы, классы Ingress и хранилища, а также доступные worker-узлы:

Copy
1kubectl get namespace zakroma-storage zakroma-zds
2kubectl get ingressclass
3kubectl get storageclass
4kubectl get nodes -L kubernetes.io/hostname

Убедитесь, что указанные IngressClass и StorageClass существуют, а для кластера ZDS доступны три разных worker-узла.

Проверьте наличие рабочих A-записей в DNS для Admin UI и рабочей области с рабочего места администратора. Переходите к установке после успешных проверок.

9. Установка Закрома.Хранение и ZDS

Установите сервисы Закрома.Хранение с подготовленным storage/values-storage.yaml. Команда одинакова для локальных пользователей, LDAP и Keycloak; настройки выбранного источника пользователей уже находятся в этом файле:

Copy
1helm upgrade --install zakroma-storage charts/zakroma-storage-6.0.4.tgz -n zakroma-storage \
2  -f storage/values-storage.yaml --wait --timeout 10m
3for component in admin-ui gateway core composer worker0; do
4  kubectl -n zakroma-storage rollout status "deployment/zakroma-storage-$component" --timeout=600s || break
5done

Ожидаемый результат: обновление всех пяти Deployments завершено успешно. Тайм-аут 10m приведён как пример, обычно установка завершается значительно быстрее. Если установка завершилась ошибкой, определите причину по разделу диагностики перед повторным запуском.

Создайте маршруты Admin UI и S3 из подготовленных манифестов:

Copy
1kubectl apply -f storage/ingress-admin.yaml -f storage/ingress-s3.yaml

Затем установите ZDS:

Copy
1helm upgrade --install zakroma-zds charts/zds-3.1.0.tgz -n zakroma-zds \
2  -f zds/values-zds.yaml --wait --timeout 10m
3kubectl -n zakroma-zds rollout status statefulset/zds --timeout=600s
4kubectl -n zakroma-zds get pods -l app=zds,release=zakroma-zds -o wide
5kubectl -n zakroma-zds get pvc

Ожидаются три Pod на разных worker-узлах и шесть PVC в состоянии Bound: data-1-zds-0–data-1-zds-2 и system-volume-zds-0–system-volume-zds-2. --wait не заменяет проверку API ZDS на шаге 10.

Адреса подключения для регистрации хранилища в Admin UI:

Copy
1zds-0.zds-headless.zakroma-zds.svc.cluster.local:8080
2zds-1.zds-headless.zakroma-zds.svc.cluster.local:8080
3zds-2.zds-headless.zakroma-zds.svc.cluster.local:8080

Скопируйте все три адреса: они понадобятся при добавлении кластера ZDS в Admin UI. Если домен Kubernetes-кластера отличается от cluster.local, замените его во всех трёх адресах.

Короткие имена zds-N.zds-headless внутри конфигурации ZDS остаются локальными для его неймспейса. Дополнительная установка DNS или изменение чарта для этой схемы не требуются.

Проверка готовности

10. Проверка работоспособности сервисов и API

На рабочем месте администратора проверьте ресурсы кластера, файл лицензии в Gateway и доступность Admin UI:

Copy
1kubectl -n zakroma-storage get deployments,pods,services,ingress
2kubectl -n zakroma-zds get statefulset,pods,pvc
3kubectl -n zakroma-storage exec deployment/zakroma-storage-gateway -- \
4  test -s /opt/application/licence
5curl --fail --silent --show-error --cacert files/ca.crt \
6  -o /dev/null -w '%{http_code}\n' 'https://<ADMIN_UI_FQDN>/'

Ожидаемый результат: реплики компонентов готовы, проверка файла лицензии успешна, Admin UI возвращает HTTP 200 и открывает страницу входа.

Проверьте /readyz Gateway через локальное перенаправление порта. В одном терминале запустите:

Copy
1kubectl -n zakroma-storage port-forward deployment/zakroma-storage-gateway 18180:8180

В другом терминале:

Copy
1curl --fail --silent --show-error -o /dev/null -w '%{http_code}\n' http://127.0.0.1:18180/readyz

Ожидаемый результат — HTTP 200. Остановите kubectl port-forward через Ctrl+C.

Для Core, Composer и Worker чарт задаёт readinessProbe /readyz на порту 8180. Проверьте успешное завершение обновления этих компонентов и отсутствие ошибок проверок готовности в событиях. Для Admin UI проверьте доступность страницы: пустая readinessProbe в исходном чарте не проверяет всю цепочку авторизации.

Каждый Pod ZDS проверьте отдельно:

Copy
1for pod in zds-0 zds-1 zds-2; do
2  printf '%s: ' "$pod"
3  kubectl -n zakroma-zds exec "$pod" -- \
4    curl --fail --silent --show-error -o /dev/null -w '%{http_code}\n' \
5    http://127.0.0.1:8081/readyz || break
6done

Ожидаемый результат — HTTP 200 для каждого из трёх Pod. Тело ответа может быть пустым. В ZDS 2.1.0 /readyz доступен на кластерном сервере.

11. Функциональная проверка S3

Откройте Admin UI по настроенному FQDN и войдите пользователем default_admin. Выполните:

1. Добавьте хранилище типа ZDSv2 с тремя адресами из шага 9 и ключами из zds/values-zds.yaml; TLS для подключения к ZDS в этом примере выключен.
2. Убедитесь, что зарегистрированное хранилище видит три узла. Параметры группы хранения описаны в Конфигурации ZDS.
3. Создайте рабочую область и бакет. В бакете добавьте группу хранения с политикой EC 2+1; вольюм создаётся автоматически. Назначьте пользователю разрешения и выпустите S3-ключ.
4. Подготовьте DNS рабочей области <WORKSPACE_FQDN> вида <WORKSPACE>.<BASE_DOMAIN>. Используйте отдельный тестовый объект.

Передайте секретный ключ интерактивно. Создайте временную конфигурацию AWS CLI, чтобы S3 использовал path-style адресацию, не меняя постоянные настройки рабочего места:

Copy
1export AWS_ACCESS_KEY_ID='<S3_ACCESS_KEY>'
2read -rsp 'AWS Secret Access Key: ' AWS_SECRET_ACCESS_KEY
3export AWS_SECRET_ACCESS_KEY
4echo
5export S3_ENDPOINT='https://<WORKSPACE_FQDN>'
6export S3_BUCKET='<TEST_BUCKET>'
7AWS_TLS_OPTION=''
8S3_CHECK_DIR=$(mktemp -d)
9export AWS_CONFIG_FILE="$S3_CHECK_DIR/aws-config"
10aws configure set default.s3.addressing_style path
11aws configure set default.region us-east-1
12export AWS_CA_BUNDLE="$PWD/files/ca.crt"

Самоподписанный сертификат

Если S3 API использует самоподписанный сертификат, перед проверкой добавьте переменную среды AWS_TLS_OPTION='--no-verify-ssl'. Параметр отключает для AWS CLI проверку сертификата сервера, поэтому используйте его только для функционального теста. Для сертификата от доверенного центра сертификации оставьте переменную пустой.

Для проверки TLS используйте доверенный CA через AWS_CA_BUNDLE. Выполняйте тест в отдельном Bash-сеансе, чтобы не затронуть ранее заданные переменные AWS.

Загрузите объект, проверьте его наличие, скачайте и сравните содержимое:

Copy
1object="k8s-base-cluster-$(date +%s).txt"
2printf 'Kubernetes S3 functional check\n' >"$S3_CHECK_DIR/source.txt"
3aws ${AWS_TLS_OPTION} --endpoint-url "$S3_ENDPOINT" s3 cp "$S3_CHECK_DIR/source.txt" "s3://${S3_BUCKET}/${object}"
4aws ${AWS_TLS_OPTION} --endpoint-url "$S3_ENDPOINT" s3 ls "s3://${S3_BUCKET}/${object}"
5aws ${AWS_TLS_OPTION} --endpoint-url "$S3_ENDPOINT" s3 cp "s3://${S3_BUCKET}/${object}" "$S3_CHECK_DIR/downloaded.txt"
6cmp "$S3_CHECK_DIR/source.txt" "$S3_CHECK_DIR/downloaded.txt"

Проверка успешна, если объект записан и скачан, а cmp не вывел различий. Сохраните объект до шага 12.

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

• повторите запись и чтение с ключом, содержащим пробел и +, например checks/test object+1.txt;
• повторите проверку с согласованным крупным тестовым файлом и multipart-загрузкой AWS CLI.

Удаляйте только объекты, созданные для проверки.