Production-паттерны и best practices — Kong

Production-паттерны и best practices для Kong

Production-развёртывание Kong требует внимания к высокой доступности, масштабированию, мониторингу и процедурам восстановления.

#1. Высокая доступность (High Availability)

Проблема: Kong должен быть доступен 24/7, даже при сбоях оборудования или развёртывании новых версий.

Решение: Кластеризация и правильная конфигурация Kubernetes.

#1.1. Минимальное количество реплик

Проблема: Одна реплика Kong — single point of failure.

Решение: Минимум 3 реплики для production.

# kong-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kong
  namespace: kong
spec:
  replicas: 3  # Минимум для production
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0  # Ни одна реплика не должна быть недоступна
  selector:
    matchLabels:
      app: kong
  template:
    spec:
      containers:
        - name: kong
          image: kong:3.5
          # ...

Почему 3 реплики:

При потере 1 узла остаётся 2 (кворум)
Возможность rolling update без простоя
Распределение нагрузки

#1.2. Pod Anti-Affinity

Проблема: Все поды Kong могут оказаться на одном узле кластера.

Решение: Pod anti-affinity для распределения по узлам.

spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          podAffinityTerm:
            labelSelector:
              matchLabels:
                app: kong
            topologyKey: kubernetes.io/hostname

Результат: Kubernetes старается разместить поды Kong на разных узлах.

#1.3. Pod Disruption Budget

Проблема: При обновлении кластера все поды Kong могут быть перезапущены одновременно.

Решение: Pod Disruption Budget (PDB).

# kong-pdb.yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: kong-pdb
  namespace: kong
spec:
  minAvailable: 2  # Минимум 2 пода должны быть доступны
  selector:
    matchLabels:
      app: kong

kubectl apply -f kong-pdb.yaml

#2. Health Checks и Probes

Проблема: Kubernetes должен знать, когда Kong готов к трафику и когда перезапустить под.

Решение: Readiness, Liveness и Startup probes.

#2.1. Конфигурация probes

spec:
  containers:
    - name: kong
      image: kong:3.5
      ports:
        - containerPort: 8000
          name: proxy
        - containerPort: 8001
          name: admin
      readinessProbe:
        httpGet:
          path: /status
          port: 8001
        initialDelaySeconds: 5
        periodSeconds: 10
        timeoutSeconds: 5
        successThreshold: 1
        failureThreshold: 3
      livenessProbe:
        httpGet:
          path: /status
          port: 8001
        initialDelaySeconds: 30
        periodSeconds: 10
        timeoutSeconds: 5
        successThreshold: 1
        failureThreshold: 3
      startupProbe:
        httpGet:
          path: /status
          port: 8001
        initialDelaySeconds: 5
        periodSeconds: 5
        failureThreshold: 30  # Даёт до 150 секунд на старт

Разница между probes:

Startup Probe — проверяет, что Kong запустился (отключает liveness/readiness пока не пройдёт)
Readiness Probe — проверяет готовность к трафику (не готов → убрать из Service)
Liveness Probe — проверяет, что Kong не «завис» (не прошёл → перезапустить под)

#2.2. Graceful Shutdown

Проблема: При перезапуске поды Kong могут оборвать активные соединения.

Решение: preStop hook и graceful termination.

spec:
  containers:
    - name: kong
      lifecycle:
        preStop:
          exec:
            command:
              - /bin/sh
              - -c
              - |
                # Ждём завершения активных запросов (до 30 сек)
                sleep 30
                # Graceful shutdown Kong
                kong quit
      terminationGracePeriodSeconds: 60

Процесс shutdown:

Pod помечается на удаление
Срабатывает preStop hook (30 сек sleep)
За это время Kubernetes удаляет pod из Service endpoints
Активные запросы завершаются
kong quit завершает работу gracefully

#3. Resource Limits и Requests

Проблема: Kong может потреблять слишком много ресурсов или быть убит OOM killer.

Решение: Правильные resource limits и requests.

spec:
  containers:
    - name: kong
      resources:
        requests:
          cpu: 500m
          memory: 512Mi
        limits:
          cpu: 2000m
          memory: 2Gi

Рекомендации для production:

requests: 500m CPU, 512Mi-1Gi RAM (гарантированные ресурсы)
limits: 2000m CPU, 2Gi RAM (максимум)
HPA target: 70-80% utilization

#3.1. Horizontal Pod Autoscaler

Проблема: Нагрузка меняется в течение дня.

Решение: Автоматическое масштабирование по CPU/memory.

# kong-hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: kong-hpa
  namespace: kong
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: kong
  minReplicas: 3
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # 5 минут перед scale down
      policies:
        - type: Percent
          value: 10
          periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
        - type: Percent
          value: 100
          periodSeconds: 15
        - type: Pods
          value: 4
          periodSeconds: 15
      selectPolicy: Max

kubectl apply -f kong-hpa.yaml

#4. Backup и Disaster Recovery

Проблема: Нужно восстановить конфигурацию Kong после сбоя.

Решение: Регулярные backup базы данных или версионирование конфигурации.

#4.1. Backup PostgreSQL (для режима с БД)

Проблема: Конфигурация Kong хранится в PostgreSQL.

Решение: Регулярные снепшоты базы данных.

#!/bin/bash
# backup-kong-db.sh

BACKUP_DIR="/backups/kong"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="$BACKUP_DIR/kong_$TIMESTAMP.sql.gz"

# Создаём дамп
pg_dump -h postgres -U kong kong | gzip > $BACKUP_FILE

# Удаляем бэкапы старше 7 дней
find $BACKUP_DIR -name "kong_*.sql.gz" -mtime +7 -delete

echo "Backup completed: $BACKUP_FILE"

Cron job для автоматического backup:

# kong-backup-cronjob.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: kong-backup
  namespace: kong
spec:
  schedule: "0 2 * * *"  # Ежедневно в 2:00
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: backup
              image: postgres:15
              command:
                - /bin/sh
                - -c
                - |
                  pg_dump -h postgres -U kong kong | gzip > /backups/kong_$(date +%Y%m%d_%H%M%S).sql.gz
              env:
                - name: PGPASSWORD
                  valueFrom:
                    secretKeyRef:
                      name: kong-postgres-secret
                      key: password
              volumeMounts:
                - name: backup-volume
                  mountPath: /backups
          volumes:
            - name: backup-volume
              persistentVolumeClaim:
                claimName: backup-pvc
          restartPolicy: OnFailure

#4.2. DB-less режим и GitOps

Проблема: Backup базы данных сложен и требует downtime для restore.

Решение: DB-less режим с конфигурацией в git.

# kong-config.yaml
_format_version: "3.0"

services:
  - name: users-api
    url: http://users-service:8080
    routes:
      - name: users-route
        paths: [/api/users]
    plugins:
      - name: rate-limiting
        config:
          minute: 100

consumers:
  - username: mobile-app
    key-auth:
      - key: secret-key-123

Преимущества:

Конфигурация версионируется в git
Rollback через git revert
Audit trail изменений
Быстрое восстановление (применить YAML)

#4.3. Восстановление из backup

# Restore PostgreSQL backup
gunzip -c /backups/kong_20260317_020000.sql.gz | \
  psql -h postgres -U kong -d kong

# Перезапуск Kong для применения конфигурации
kubectl rollout restart deployment/kong -n kong

#5. Мониторинг и алертинг

Проблема: Нужно вовремя обнаруживать проблемы.

Решение: Prometheus + Grafana + Alertmanager.

#5.1. Ключевые метрики для мониторинга

Метрика	Описание	Alert threshold
`kong_requests_total`	RPS	Резкое падение
`kong_status{code="5xx"}`	Ошибки 5xx	> 1% от всех запросов
`kong_latency_request`	Latency запроса	P99 > 1000ms
`up{job="kong"}`	Статус подов	== 0 (down)
`kong_node_status`	Статус узлов Kong	!= healthy

#5.2. Alertmanager правила

# alerting-rules.yaml
groups:
  - name: kong
    rules:
      - alert: KongHighErrorRate
        expr: |
          sum(rate(kong_status{code=~"5.."}[5m])) 
          / 
          sum(rate(kong_requests_total[5m])) > 0.01
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "High error rate in Kong"
          description: "Error rate is {{ $value | humanizePercentage }}"

      - alert: KongHighLatency
        expr: |
          histogram_quantile(0.99, 
            sum(rate(kong_latency_request_bucket[5m])) by (le)
          ) > 1000
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "High latency in Kong"
          description: "P99 latency is {{ $value }}ms"

      - alert: KongPodDown
        expr: up{job="kong"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Kong pod is down"
          description: "Pod {{ $labels.pod }} is not responding"

      - alert: KongNotEnoughReplicas
        expr: kube_deployment_status_replicas_available{deployment="kong"} < 3
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Kong has less than 3 replicas"
          description: "Current replicas: {{ $value }}"

#6. Troubleshooting

#6.1. 502 Bad Gateway

Проблема: Kong возвращает 502 ошибки.

Диагностика:

# Проверка логов Kong
kubectl logs -n kong -l app=kong --tail=100

# Проверка доступности upstream
kubectl get endpoints users-service

# Проверка health checks
curl http://localhost:8001/upstreams/users-upstream/health

# Проверка таймаутов
curl http://localhost:8001/services/users-api

Возможные причины:

Upstream сервис недоступен
Неправильные таймауты (слишком короткие)
Health checks отключили target

Решение:

# Увеличение таймаутов
curl -X PATCH http://localhost:8001/services/users-api \
  --data "read_timeout=60000" \
  --data "write_timeout=60000"

#6.2. Высокая latency

Проблема: Запросы обрабатываются медленно.

Диагностика:

# Проверка latency по перцентилям
curl http://localhost:8001/metrics | grep kong_latency

# Проверка загрузки CPU/Memory
kubectl top pods -n kong

# Проверка network latency
kubectl exec -it kong-xxxxx -n kong -- ping users-service

Возможные причины:

Перегрузка Kong (недостаточно ресурсов)
Медленный upstream
Сетевые проблемы

Решение:

# Увеличение ресурсов
kubectl patch deployment kong -n kong --type='json' -p='[
  {"op": "replace", "path": "/spec/template/spec/containers/0/resources/limits/cpu", "value": "4000m"},
  {"op": "replace", "path": "/spec/template/spec/containers/0/resources/limits/memory", "value": "4Gi"}
]'

# Горизонтальное масштабирование
kubectl scale deployment kong -n kong --replicas=5

#6.3. Конфигурация не применяется

Проблема: Изменения в KongPlugin/Ingress не отражаются.

Диагностика:

# Проверка статуса синхронизации
kubectl get ingress -o wide

# Логи Kong Ingress Controller
kubectl logs -n kong -l app=kong-ingress-controller

# Проверка событий
kubectl get events -n kong --sort-by='.lastTimestamp'

Возможные причины:

Kong Ingress Controller не работает
Ошибки валидации конфигурации
Network policy блокирует доступ к Admin API

Решение:

# Перезапуск Ingress Controller
kubectl rollout restart deployment/kong-ingress-controller -n kong

# Проверка доступа к Admin API
kubectl port-forward -n kong svc/kong-admin 8001:80
curl http://localhost:8001

#7. Security Best Practices

#7.1. Ограничение доступа к Admin API

# NetworkPolicy для Admin API
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: kong-admin-policy
  namespace: kong
spec:
  podSelector:
    matchLabels:
      app: kong
  policyTypes:
    - Ingress
  ingress:
    - ports:
        - port: 8001
          protocol: TCP
      from:
        - podSelector:
            matchLabels:
              app: kong-ingress-controller
        - namespaceSelector:
            matchLabels:
              name: monitoring

#7.2. TLS для Admin API

env:
  - name: KONG_ADMIN_LISTEN
    value: "0.0.0.0:8001 ssl, 0.0.0.0:8444 ssl http2"
  - name: KONG_ADMIN_GUI_LISTEN
    value: "0.0.0.0:8002 ssl, 0.0.0.0:8445 ssl http2"
volumeMounts:
  - name: admin-tls
    mountPath: /etc/kong/ssl
    readOnly: true
volumes:
  - name: admin-tls
    secret:
      secretName: kong-admin-tls

#8. Performance Tuning

#8.1. Оптимизация nginx worker

env:
  - name: KONG_NGINX_WORKER_PROCESSES
    value: "auto"  # По числу CPU ядер
  - name: KONG_NGINX_WORKER_RLIMIT_NOFILE
    value: "65535"
  - name: KONG_NGINX_WORKER_CONNECTIONS
    value: "65535"

#8.2. Кэширование DNS

env:
  - name: KONG_NGINX_RESOLVER
    value: "kube-dns.kube-system.svc.cluster.local"
  - name: KONG_NGINX_RESOLVER_VALID
    value: "30s"  # Кэширование DNS записей

#8.3. Оптимизация базы данных

env:
  - name: KONG_PG_POOL_SIZE
    value: "100"
  - name: KONG_PG_MAX_CONCURRENT_QUERIES
    value: "5"

Метрика

Описание

Alert threshold

kong_requests_total

RPS

Резкое падение

kong_status{code="5xx"}

Ошибки 5xx

> 1% от всех запросов

kong_latency_request

Latency запроса

P99 > 1000ms

up{job="kong"}

Статус подов

== 0 (down)

kong_node_status

Статус узлов Kong

!= healthy