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

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

Инструкция устанавливает только слой хранения данных: ZDSv2 версии 2.1.0 чартом zds версии 3.1.0. Создаются три Pod с EC 2+1 на разных worker-узлах, по одному data PVC и system PVC на Pod. Закрома.Хранение и PostgreSQL этой инструкцией не устанавливаются.

Управляющий слой может работать в том же или другом Kubernetes-кластере, на физических серверах либо виртуальных машинах. ZDS регистрируется в нём после установки. Требования к смешанным схемам приведены в Архитектуре решения.

Постоянное состояние

Имена ZDS-узлов, порядок групп хранения и пути постоянного состояния должны сохраняться при эксплуатации. Не удаляйте PVC и не меняйте их идентичность при повторном upgrade. EC 2+1 не защищает от одновременного отказа общей системы хранения всех PVC.

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

Чарт использует имена zds и zds-headless, а не имя релиза для StatefulSet и Service. Для этого примера используйте один ZDS-релиз в отдельном неймспейсе.

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

Подготовьте не менее трёх подходящих Kubernetes worker-узлов, StorageClass с ReadWriteOnce, ёмкость для трёх data PVC и трёх system PVC, доступ к registry образов и рабочее место с Helm и kubectl. Поддерживаемую версию Kubernetes, ресурсы контейнеров и размеры томов согласуйте с технической поддержкой.

Обеспечьте синхронизацию времени, DNS и взаимодействие Pod ZDS по 8080 и 8081. Компоненты Закрома.Хранение должны иметь доступ к адресам API ZDS на 8080.

Установка

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

Получите архив zds-3.1.0.tgz и разместите его в charts/ рабочего каталога. Registry config с доступом к образам сохраните в files/registry-config.json. Выполняйте команды из этого каталога:

Copy
1umask 077
2mkdir -p zds
3kubectl config current-context
4helm show chart charts/zds-3.1.0.tgz
5tar -tzf charts/zds-3.1.0.tgz

Ожидаются name: zds, version: 3.1.0, appVersion: 2.1.0. Локальный архив исключает необходимость Helm-репозитория, но не загрузку контейнерного образа из registry.

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

Copy
1kubectl create namespace zakroma-zds --dry-run=client -o yaml | kubectl apply -f -
2kubectl -n zakroma-zds create secret generic regcred \
3  --type=kubernetes.io/dockerconfigjson \
4  --from-file=.dockerconfigjson=files/registry-config.json
5kubectl -n zakroma-zds get secret regcred

Если Secret уже существует, проверьте его назначение и актуальность; не удаляйте и не перезаписывайте чужой объект. Для ZDS не требуется Secret с лицензией Gateway.

3. Настройка API, размещения и постоянных томов

Создайте zds/values-zds.yaml — файл конфигурации ZDS. Добавьте в него настройки из примеров ниже, включая ключи доступа. Если блок persistence уже есть, дополните его. Используйте файл для проверки, установки и повторного Helm upgrade. Параметры, не указанные в файле, берутся из чарта.

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

Для обязательной anti-affinity нужны три доступных worker-узла с учётом taints, ресурсов и топологии томов. Метки selector соответствуют StatefulSet этого релиза. Порты: API 8080, межузловой сервер 8081. Внутренний TLS в примере выключен; его включение требует отдельной подготовки Secrets и согласованной настройки клиентов.

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"

В accessKey и secretKey файла zds/values-zds.yaml укажите собственную общую пару ключей для трёх Pod ZDS. Эти ключи понадобятся при регистрации хранилища в Закрома.Хранение.

Защита ключей доступа

Не используйте демонстрационные значения из чарта. Файл values не зашифрован; ключи могут сохраняться в Helm release и конфигурационном ConfigMap. Ограничьте доступ к файлу и объектам Kubernetes, не сохраняйте секреты в Git и не выводите рендер в журналы.

4. Проверка конфигурации и окружения

Copy
1chmod 600 zds/values-zds.yaml
2kubectl get nodes -L kubernetes.io/hostname
3kubectl get storageclass
4helm lint charts/zds-3.1.0.tgz -f zds/values-zds.yaml
5RENDER_DIR=$(mktemp -d)
6helm template zakroma-zds charts/zds-3.1.0.tgz -n zakroma-zds \
7  -f zds/values-zds.yaml >"$RENDER_DIR/zds.yaml"
8kubectl apply --dry-run=client -f "$RENDER_DIR/zds.yaml"
9rm -f -- "$RENDER_DIR/zds.yaml"
10rmdir -- "$RENDER_DIR"
11unset RENDER_DIR

Ожидаются успешный lint и разбор манифестов: три реплики, anti-affinity, два шаблона PVC, три адреса узлов в конфигурации.

5. Установка 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 data-1-zds-0–data-1-zds-2, system-volume-zds-0–system-volume-zds-2 в состоянии Bound. При WaitForFirstConsumer выдача томов может ожидать планирования Pod. Helm --wait не заменяет проверки API.

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

6. Проверка API и подключения управляющего слоя

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

Для всех трёх Pod ожидается HTTP 200; тело ответа может быть пустым. В ZDS 2.1.0 /readyz проверяет готовность реестра и локального узла. Штатный чарт 3.1.0 задаёт livenessProbe /healthz, но не readinessProbe, поэтому одного Running или READY 1/1 недостаточно.

Для Закрома.Хранение в том же Kubernetes-кластере зарегистрируйте ZDSv2-хранилище с полным списком адресов:

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

После подключения выполните запись и чтение объекта через Закрома.Хранение. Пример настройки рабочей области, политики, бакета и AWS CLI приведён в Функциональной проверке S3. Без подключённого управляющего слоя можно подтвердить только готовность ZDS, но не работу всей цепочки S3.

Итоговая проверка установки