Повышение стабильности работы Ingress‑контроллера¶

Рекомендации в этой статье относятся к production‑окружениям. Настройки задаются в файле values.yaml и применяются командой helm upgrade (см. Настройка Ingress‑контроллера).

Несколько pod'ов Ingress‑контроллера¶

Запустите не менее двух pod'ов Ingress‑контроллера и разместите их на разных узлах кластера, чтобы отказ узла не прерывал обработку трафика:

controller:
  replicaCount: 2
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchLabels:
              app.kubernetes.io/name: wmx-ingress
              app.kubernetes.io/instance: <RELEASE_NAME>
          topologyKey: kubernetes.io/hostname

<RELEASE_NAME> — название установки Helm. Если узлов в кластере меньше, чем pod'ов, используйте preferredDuringSchedulingIgnoredDuringExecution: иначе лишние pod'ы не будут запущены.

Чтобы обслуживание узлов (например, обновление кластера) не останавливало все pod'ы одновременно, включите PodDisruptionBudget:

controller:
  podDisruptionBudget:
    enabled: true
    minAvailable: 1

Горизонтальное масштабирование¶

Для кластеров с переменной нагрузкой включите автоматическое масштабирование (HPA). Для работы HPA в кластере должен быть установлен metrics-server, а для pod'ов — заданы запросы ресурсов.

controller:
  autoscaling:
    enabled: true
    minReplicas: 2
    maxReplicas: 10
    targetCPUUtilizationPercentage: 50
    targetMemoryUtilizationPercentage: 70

Ресурсы¶

Модуль Вебмониторэкс загружает правила обнаружения атак в каждый рабочий процесс NGINX, поэтому Ingress‑контроллеру требуется больше памяти, чем NGINX без модуля. Ориентировочно контейнер wmx-ingress использует 200–400 МБ; при перезагрузке конфигурации потребление памяти кратковременно возрастает до двух раз (см. ниже).

controller:
  resources:
    requests:
      cpu: 500m
      memory: 512Mi
    limits:
      memory: 1Gi

Уточните значения по результатам мониторинга на реальной нагрузке.

Постаналитика¶

Запустите не менее двух pod'ов постаналитики на разных узлах, чтобы данные об атаках выгружались и при отказе одного из них:

controller:
  wmx:
    postanalytics:
      replicaCount: 2
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 100
              podAffinityTerm:
                labelSelector:
                  matchLabels:
                    app.kubernetes.io/name: wmx-ingress-wmx-postanalytics
                    app.kubernetes.io/instance: <RELEASE_NAME>
                topologyKey: kubernetes.io/hostname

Объем памяти постаналитики задается параметром controller.wmx.postanalytics.arena (ГБ). Он должен вмещать запросы за последние 5–15 минут; при нехватке памяти часть данных об атаках теряется (метрика wallarm_requests_lost).

Изменения сервисов и перезагрузки NGINX¶

По умолчанию Ingress‑контроллер направляет трафик напрямую на pod'ы сервиса и перезагружает конфигурацию NGINX при каждом изменении их набора: при масштабировании, обновлении или перезапуске приложения. Перезагрузка с модулем Вебмониторэкс занимает около секунды, на это время увеличиваются задержки ответов и потребление памяти.

Для сервисов, которые часто масштабируются (например, с HPA), включите передачу трафика через ClusterIP сервиса. Тогда изменения pod'ов не вызывают перезагрузок NGINX, а распределение запросов между pod'ами выполняет Kubernetes:

kubectl annotate ingress <INGRESS_NAME> nginx.org/use-cluster-ip=true

После перезагрузки старые рабочие процессы NGINX завершаются, когда закрываются их соединения. Долгоживущие соединения (WebSocket, gRPC‑потоки) могут удерживать старые процессы и их память. Ограничьте время завершения:

controller:
  config:
    entries:
      worker-shutdown-timeout: 240s

Аварийный режим¶

Параметр controller.wmx.fallback (по умолчанию on) позволяет NGINX продолжать пропускать трафик, если нода не смогла загрузить правила обнаружения атак или зарегистрироваться в Вычислительном кластере (например, при недоступности api.webmonitorx.ru). В этом случае трафик не анализируется. Не выключайте аварийный режим в production‑окружении, если доступность приложений важнее непрерывности защиты.

• Мониторинг Ingress‑контроллера
• Параметры Helm‑чарта F5 NGINX Ingress Controller