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

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

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

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

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

Пример:

idp:
  replicas: 2

reg:
  replicas: 2

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

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

Standby-режим для Console

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

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

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

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

  • основной под console работает в StatefulSet
  • standby создаётся как отдельный Deployment
  • пока основной pod здоров, standby остаётся NotReady
  • если основной pod недоступен, standby становится Ready и начинает принимать трафик сервиса

PodDisruptionBudget

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

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

pdb:
  enabled: true
  default:
    maxUnavailable: 1

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

  • для single-replica модулей PDB по умолчанию не создаётся
  • если явно включить PDB для одной реплики, можно заблокировать drain узла
  • правила minAvailable и maxUnavailable взаимоисключаемы

Работа с конфигурацией

Если используется config.readOnly=true

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

  • обновление исходных файлов
  • сборку нового образа
  • публикацию в registry
  • helm upgrade

Если используется config.readOnly=false

В рабочем процессе нужно контролировать:

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

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

Работа с логами

Для повседневной диагностики используйте стандартные 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

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

  • все изменения вносить через values-файл
  • хранить values-файлы по окружениям отдельно
  • перед обновлением выполнять helm template и helm lint

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

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

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

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