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

Эксплуатация

Описание

После Helm-чарта

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

Масштабирование модулей

Helm-чартКоличество реплик настраивается на уровне отдельных модулей.

Пример:

idp:
  replicas: 2

reg:
  replicas: 2

Для production среды разумно поддерживать blitz-idp устанавливаеткак минимум в кластердвух наборрепликах. приложенийЭто согласуется и вспомогательныхс ресурсов,настройками необходимыхPodDisruptionBudget по умолчанию.

После изменения values.yaml применяйте обновление через Helm, а не ручное масштабирование через kubectl scale, если важно сохранить конфигурацию как источник правды.

Standby-режим для работы Blitz Identity Provider.

В зависимости от конфигурации и включённых модулей чарт может создавать:

  • Deployment и StatefulSet для модулей Blitz
  • Service для внутреннего и внешнего доступа
  • Ingress для публикации HTTP-маршрутов
  • Secret и ConfigMap для статической конфигурации
  • PersistentVolumeClaim для общей динамической конфигурации
  • Job начальной загрузки конфигурации
  • PodDisruptionBudget
  • NetworkPolicy
  • ServiceMonitor и PodMonitor
  • ресурсы Vault Secrets Operator, если включена интеграция с Vault

Версия чарта требует Kubernetes не ниже 1.26.

Основные модули Blitz

Console

Чарт поддерживает следующиеотдельный модули:standby режим для модуля console. Включите его для обеспечения аварийного доступа к консоли при падении основного пода.

Пример включения:

console:
  standby:
    enabled: true
    activationProbe:
      periodSeconds: 5
      timeoutSeconds: 2
      failureThreshold: 1

Логика работы:

  • idp — основной модульпод аутентификации и выдачи identity-сервисов
  • console —работает административнаяв консоль BlitzStatefulSet
  • standby создаётся как отдельный regDeployment — модуль регистрации
  • пока основной pod здоров, standby остаётся recoveryNotReady — модуль восстановления доступа
  • если основной pod недоступен, standby становится panelReady —и дополнительныйначинает пользовательскийпринимать веб-модуль
    • трафик
  • ldapMfa — сервис LDAP MFAсервиса

PodDisruptionBudget

ПоPodDisruptionBudget защищает Blitz IDP от добровольных прерываний.

Типовой пример:

pdb:
  enabled: true
  default:
    maxUnavailable: 1

Практические замечания:

  • для single-replica модулей PDB по умолчанию вне чартесоздаётся
    • включены
  • если явно включить PDB для одной реплики, можно заблокировать idpdrain, узла
  • правила console, reg, recovery. Модули panelminAvailable и ldapMfamaxUnavailable включаютсявзаимоисключаемы
    • отдельно
через

Работа конфигурациюс чарта.

конфигурацией

Схема конфигурации

В чарте

Если используется двухуровневаяconfig.readOnly=true

модель

Конфигурация конфигурации:живёт внутри образов. Любое контролируемое изменение должно проходить через:

  • статическаяобновление конфигурацияисходных файлов
  • динамическаясборку конфигурациянового образа

Статическая конфигурация

Статическая конфигурация рендерится Helm и попадает

  • публикацию в Secret, ConfigMap или, при использовании Vault, в VaultStaticSecret.

    Типовые статические файлы:

    • boot.confregistry
    • overlay.conf
      • helm
    • play.conf
    • logback.xml
    • blitz-keystore.bks
    • console.confupgrade

    Для модулей Blitz эти файлы по умолчанию монтируются в каталог:

    /usr/share/identityblitz/blitz-config

    Динамическая конфигурация

    Динамическая конфигурация

    Если используется в сценариях, где конфиги поставляются не только внутри образа, но и из внешнего источника.

    По умолчанию она размещается по пути:

    /usr/share/identityblitz/idp-config

    Если выбран режим config.readOnly=false, чарт использует общий PersistentVolumeClaim и публикует туда конфигурацию через специальный Job.

    Два режима поставки конфигурации

    Режим image-only

    РежимВ config.readOnly=trueрабочем подходит для случаев, когда конфигурация встроена в Docker-образ и её непроцессе нужно инициализировать из Git или локального каталога.

    Особенности режима:контролировать:

    • нетсостояние общего PersistentVolumeClaim
    • неактуальность запускаетсяисходного init-conf JobGit-репозитория
    • эксплуатациянеобходимость прощеповторной ипубликации безопаснееконфигурации
    • измененияфлаг конфигурации вносятся через пересборку образовreseedOnUpgrade

    Не стоит пересоздавать том или вручную менять содержимое каталога без чёткого регламента. Это усложняет диагностику и может привести к расхождению между Git и фактическим состоянием среды.

    РежимРабота Git/Localс -> PVCлогами

    РежимДля config.readOnly=falseповседневной нужен,диагностики когдаиспользуйте конфигурациюстандартные требуетсяKubernetes публиковать в общий каталог во время установки.команды:

    kubectl logs deploy/<deployment-name> -n blitz --tail=200
kubectl logs statefulset/<statefulset-name> -n blitz --tail=200

    ОсобенностиПри режима:необходимости можно включить режим JSON-логирования:

    logger:
  type: "json"
  rootLevel: "INFO"

    Это упрощает интеграцию с ELK, OpenSearch, Loki и другими системами централизованного сбора логов.

    Работа с релизами Helm

    Для сопровождения используйте команды:

    helm list -n blitz
helm status blitz -n blitz
helm history blitz -n blitz

    Практический подход:

    • используетсявсе общийизменения PersistentVolumeClaimвносить через values-файл
    • источникхранить динамическойvalues-файлы конфигурациипо задаётсяокружениям через config.source.typeотдельно
    • создаётсяперед обновлением выполнять init-confhelm template Job
    • рабочие поды могут ожидают готовности конфигурации через initContainer

    Kubernetes-ресурсы

    Ingress

    Ingress публикует HTTP-эндпоинты Blitz наружу. Чарт поддерживает настройку класса ingress-контроллера, аннотаций и TLS-секрета.

    helm

    PersistentVolumeClaim

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

    Vault и VSO

    Если используется vault.enabled=true, чарт может забирать секреты из HashiCorp Vault через Vault Secrets Operator. В этом случае вместо прямого создания некоторых Secret в кластере используются ресурсы:

    • VaultConnection
    • VaultAuth
    • VaultStaticSecretlint

    PodDisruptionBudgetБезопасные практики для production среды

    • не передавать секреты через --set
    • не менять конфигурацию вручную в живых подах
    • не полагаться на незафиксированные ручные патчи в namespace
    • держать NetworkPolicy и PodDisruptionBudget защищаетвключёнными модулитам, отгде добровольныхэто прерываний,допускает напримермодель приэксплуатации
    • проверять kubectl drainreadiness или плановом обслуживании узлов.

      NetworkPolicy

      NetworkPolicy ограничивает сетевой доступ к подам Blitz. В чарте есть как более мягкий режим, так и строгийлоги режимпосле скаждого явнымиобновления

      • правилами.

    Регулярные проверки

    • состояние подов и количество рестартов
    • срок действия TLS-сертификатов
    • доступность PostgreSQL
    • корректность публикации Ingress
    • объём PersistentVolumeClaim, если используется динамическая конфигурация
    • синхронизацию секретов из Vault
    • Наверх