Масштабирование, high availability, backup strategies, troubleshooting
Production-развёртывание Kong требует внимания к высокой доступности, масштабированию, мониторингу и процедурам восстановления.
Проблема: Kong должен быть доступен 24/7, даже при сбоях оборудования или развёртывании новых версий.
Решение: Кластеризация и правильная конфигурация Kubernetes.
Проблема: Одна реплика 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 реплики:
Проблема: Все поды Kong могут оказаться на одном узле кластера.
Решение: Pod anti-affinity для распределения по узлам.
spec:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchLabels:
app: kong
topologyKey: kubernetes.io/hostnameРезультат: Kubernetes старается разместить поды Kong на разных узлах.
Проблема: При обновлении кластера все поды 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: kongkubectl apply -f kong-pdb.yamlПроблема: Kubernetes должен знать, когда Kong готов к трафику и когда перезапустить под.
Решение: Readiness, Liveness и Startup 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:
Проблема: При перезапуске поды 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:
kong quit завершает работу gracefullyПроблема: Kong может потреблять слишком много ресурсов или быть убит OOM killer.
Решение: Правильные resource limits и requests.
spec:
containers:
- name: kong
resources:
requests:
cpu: 500m
memory: 512Mi
limits:
cpu: 2000m
memory: 2GiРекомендации для production:
Проблема: Нагрузка меняется в течение дня.
Решение: Автоматическое масштабирование по 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: Maxkubectl apply -f kong-hpa.yamlПроблема: Нужно восстановить конфигурацию Kong после сбоя.
Решение: Регулярные backup базы данных или версионирование конфигурации.
Проблема: Конфигурация 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Проблема: 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Преимущества:
# 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Проблема: Нужно вовремя обнаруживать проблемы.
Решение: Prometheus + Grafana + Alertmanager.
| Метрика | Описание | 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 |
# 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 }}"Проблема: 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Возможные причины:
Решение:
# Увеличение таймаутов
curl -X PATCH http://localhost:8001/services/users-api \
--data "read_timeout=60000" \
--data "write_timeout=60000"Проблема: Запросы обрабатываются медленно.
Диагностика:
# Проверка 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Возможные причины:
Решение:
# Увеличение ресурсов
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Проблема: Изменения в 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'Возможные причины:
Решение:
# Перезапуск 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# 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: monitoringenv:
- 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-tlsenv:
- name: KONG_NGINX_WORKER_PROCESSES
value: "auto" # По числу CPU ядер
- name: KONG_NGINX_WORKER_RLIMIT_NOFILE
value: "65535"
- name: KONG_NGINX_WORKER_CONNECTIONS
value: "65535"env:
- name: KONG_NGINX_RESOLVER
value: "kube-dns.kube-system.svc.cluster.local"
- name: KONG_NGINX_RESOLVER_VALID
value: "30s" # Кэширование DNS записейenv:
- name: KONG_PG_POOL_SIZE
value: "100"
- name: KONG_PG_MAX_CONCURRENT_QUERIES
value: "5"Вопросы ещё не добавлены
Вопросы для этой подтемы ещё не добавлены.