Мониторинг и сетевая безопасность

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

Данный раздел описывает основные настройки чарта, связанные с метриками, логами, Ingress, TLS и NetworkPolicy.

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

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

Пример:

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 узла
• правила minAvailablestdout и maxUnavailablestderr. взаимоисключаемы
Это

соответствует

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

Kubernetes

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

подключить

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

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

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

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

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

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

Работа

Если снужна логами

более

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

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

helmpodLabels:
  listlog-collect: -n"true"
blitz

helm

Метрики statusPrometheus

blitz

Чарт -nподдерживает blitzдва helmосновных historyварианта blitzинтеграции:

-n

blitz
• ServiceMonitor
• PodMonitor

ServiceMonitor

Пример:

monitoring:
  serviceMonitor:
    enabled: true
    interval: 30s
    scrapeTimeout: 10s

PodMonitor

Пример:

monitoring:
  podMonitor:
    enabled: true
    interval: 30s
    scrapeTimeout: 10s

ПрактическийИспользуйте подход:тот вариант, который соответствует вашей модели интеграции с Prometheus Operator.

Аннотации для scrape

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

monitoring:
  scrapeAnnotations:
    enabled: true
    target: app
    scheme: http

Параметр target позволяет выбрать, к какой точке применять аннотации: к приложению или к JVM exporter.

JVM exporter

Чарт умеет подключать JMX exporter как javaagent для модулей:

• всеidp
изменения
• console
вносить
• reg
• recovery

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

jvmExporter:
  enabled: true
  exporterPort: 9405

При включении чарта:

• создаётся ConfigMap с конфигурацией exporter
• в поды добавляется initContainer, который копирует JAR агента
• в JAVA_TOOL_OPTIONS добавляется параметр -javaagent

Это удобно, если в организации уже принят сбор JVM-метрик через values-файлPrometheus.

Ingress

Ingress управляет внешней публикацией Blitz.

Базовый пример:

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

Если используется nginx, можно добавить аннотации контроллера:

ingress:
  className: "nginx"
  annotations:
    nginx.ingress.kubernetes.io/proxy-buffer-size: "16k"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "60"

TLS

Для production рекомендуется публиковать Blitz по HTTPS. Проверьте:

• существует ли TLS-секрет
• хранитьсовпадает values-файлыли поCN окружениямили отдельноSAN сертификата с доменом
• переддоступен обновлениемли выполнятькорректный сертификат через ingress-контроллер

Trusted proxies

Параметр helmhttp.forwardedTrustedProxies templateопределяет, каким прокси приложение доверяет при обработке forwarded-заголовков.

По умолчанию список может быть широким. В production лучше ограничить его CIDR-сетями ваших реальных ingress-прокси.

NetworkPolicy

Чарт может создавать NetworkPolicy для модулей Blitz.

Базовое включение:

networkPolicy:
  enabled: true
  mode: permissive

Режим permissive

Подходит для большинства стартовых внедрений. В этом режиме чарт:

• разрешает входящий трафик к опубликованным портам приложения
• не усложняет egress-политику без необходимости

Режим restricted

Подходит для более строгих платформ. В этом режиме нужно явно задавать разрешённые правила доступа:

networkPolicy:
  enabled: true
  mode: restricted
  egress:
    allowAll: false

Тогда команда внедрения должна заранее определить:

• какие источники могут обращаться к сервисам Blitz
• к каким внешним адресам Blitz должен ходить сам
• нужен ли доступ к PostgreSQL, Vault, DNS и helmдругим lintкорпоративным сервисам

Безопасные практикинастройки по умолчанию

Чарт уже включает ряд полезных параметров безопасности:

• readOnlyRootFilesystem=true
• runAsNonRoot=true
• seccompProfile.type=RuntimeDefault
• TLS-проверка исходящих HTTP-клиентов включена по умолчанию

Эти настройки не стоит отключать без отдельного обоснования.

Практический минимум для production среды

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

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

• состояние подов и количество рестартов
• срок действия TLS-сертификатов
• доступность PostgreSQL
• корректность публикации Ingress
• объёмограничить PersistentVolumeClaimforwardedTrustedProxies
• включить NetworkPolicy
• подключить централизованный сбор логов
• включить ServiceMonitor, еслиPodMonitor используетсяили динамическая конфигурацияscrape-аннотации
• синхронизациюоценить секретовнеобходимость изJVM Vaultexporter