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

Требования и подготовка среды

Данный раздел поможет вам заранее подготовить всё, что потребуется для установки Blitz IDP в Kubernetes.

Минимальные технические требования

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

  • кластер Kubernetes версии 1.26 или выше
  • Helm 3
  • namespace для размещения релиза
  • PostgreSQL
  • доступ к Docker registry с образами Blitz

В большинстве сценариев также требуются:

  • StorageClass для PersistentVolumeClaim, если используется config.readOnly=false
  • ingress-контроллер, например nginx или traefik
  • корректная DNS-запись для публичного домена
  • TLS-сертификат для внешнего доступа
  • HashiCorp Vault и Vault Secrets Operator, если секреты будут поставляться через Vault

Подготовка

Namespace

Рекомендуется заранее создать отдельный namespace для релиза Blitz:

kubectl create namespace blitz

Если namespace уже существует, достаточно убедиться, что у команды внедрения есть права на создание стандартных ресурсов Helm.

PostgreSQL

Blitz IDP требует доступной базы PostgreSQL. Возможны два подхода:

  • использовать уже существующую корпоративную инсталляцию PostgreSQL
  • развернуть отдельную БД рядом с приложением

Пример установки PostgreSQL через Helm:

helm upgrade --install blitz-pg oci://registry-1.docker.io/bitnamicharts/postgresql \
  -n default \
  --set auth.username=blitz \
  --set auth.password=blitzpass \
  --set auth.database=blitz

Важно заранее определить:

  • адрес сервера PostgreSQL
  • имя базы
  • учётную запись приложения
  • сетевой доступ из namespace Blitz к БД

Доступ к реестру

Нужно проверить, что рабочие узлы кластера могут скачивать образы Blitz и, при необходимости, дополнительные образы, например bitnamilegacy/memcached или bitnami/jmx-exporter.

Если используется закрытый registry, заранее подготовьте:

  • зеркало или прокси-репозиторий
  • imagePullSecret
  • корпоративную политику тегов и digest

DNS и публичный домен

Параметр domain определяет базовый домен, который используется Ingress и генерируемыми URL.

Пример:

domain: "blitz.company.loc"

До установки нужно определить:

  • какое доменное имя будет использовать Blitz
  • какая DNS-запись указывает на ingress-контроллер
  • будет ли использоваться единый домен для всех модулей

TLS

Если вы планируете использовать встроенный Ingress и доступ к Blitz будет публиковаться по HTTPS, заранее подготовьте TLS-секрет:

kubectl -n blitz create secret tls blitz-idp-tls \
  --cert=path/to/tls.crt \
  --key=path/to/tls.key

После этого секрет можно указать в values.yaml:

ingress:
  tls:
    enabled: true
    secretName: "blitz-idp-tls"

StorageClass и PVC

Если планируется режим с динамической конфигурацией, необходимо заранее решить:

  • будет ли чарт создавать PersistentVolumeClaim сам
  • нужно ли использовать уже существующий PersistentVolumeClaim
  • какой StorageClass допустим в вашей платформе
  • какой нужен размер тома

Пример параметров:

config:
  shared:
    existingClaim: ""
    storageClass: "auto"
    storageSize: 1Gi

Vault и Vault Secrets Operator

Если планируется поставка секретов через Vault, необходимо заранее подготовить:

  • доступный адрес Vault
  • KV mount и путь до секрета
  • политику чтения
  • AppRole
  • secret_id, сохранённый в Secret Kubernetes
  • CRD Vault Secrets Operator

Без Vault чарт тоже может работать, но тогда секреты и часть конфигурации придётся передавать напрямую через values.yaml и Secret Kubernetes.

Рекомендованные организационные решения до старта

Перед установкой полезно зафиксировать несколько решений.

Выбор режима конфигурации

Нужно заранее выбрать один из двух режимов:

  • config.readOnly=true
  • config.readOnly=false

От этого зависит состав инфраструктуры, наличие PersistentVolumeClaim, логика обновлений и требования к исходному репозиторию конфигурации.

Состав модулей

Нужно определить, какие модули действительно требуются в конкретной инсталляции:

  • idp
  • console
  • reg
  • recovery
  • panel
  • ldapMfa

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

Политика секретов

Нужно решить, как команда будет управлять секретами:

  • через Vault и VSO
  • через Secret Kubernetes
  • через внутренний корпоративный процесс генерации и хранения

Для production-среды рекомендуется использовать Vault.

Сетевые ограничения

Если в кластере применяется модель zero-trust или обязательны сетевые ограничения, нужно сразу определить:

  • будет ли использоваться NetworkPolicy
  • нужен ли режим restricted
  • какие внешние зависимости должны быть доступны из подов Blitz

Краткий проверочный список

Перед переходом к следующему разделу проверьте:

  • namespace создан
  • PostgreSQL доступен
  • выбран домен
  • ingress-контроллер работает
  • TLS-сертификат подготовлен или признан не обязательным
  • понятен способ работы с секретами
  • решено, нужен ли PersistentVolumeClaim
  • определён набор модулей Blitz
Наверх