Настройка Kong Gateway для управления API-трафиком

Отметим: когда количество микросервисов превышает десяток, управление API-трафиком без централизованного шлюза превращается в хаос: rate limiting не синхронизирован, аутентификация размазана по сервисам, логирование фрагментировано. Мы настраиваем Kong Gateway для консолидации всего API-трафика: единая точка входа, богатая плагинная экосистема и полная наблюдаемость. Средняя экономия на инфраструктуре после оптимизации rate limiting составляет $2,000–$5,000 в месяц, а окупаемость внедрения — 3–6 месяцев.

Почему стоит выбрать Kong для управления API-трафиком?

Kong — один из самых зрелых open-source API gateway. Его экосистема включает более 200 плагинов на Kong Hub. Для Kubernetes доступен Ingress Controller, интегрирующийся напрямую с Gateway API. Главное преимущество — поддержка DB-less режима, идеального для GitOps: конфигурация хранится в YAML, изменения проходят через pull request и применяются утилитой decK.

Как мы настраиваем Kong Gateway в Kubernetes

Аудит текущей инфраструктуры

Оцениваем схему маршрутизации, нагрузку, требования к безопасности. На основе данных выбираем режим работы. Например, для e-commerce платформы с 50 микросервисами и пиковой нагрузкой 10 000 RPS выбираем DB-less для GitOps-подхода.

Выбор режима конфигурации: DB-less или PostgreSQL

DB-less лучше подходит для GitOps, PostgreSQL — для динамических изменений.

Деплой с помощью Helm

helm repo add kong https://charts.konghq.com
helm repo update
helm install kong kong/ingress \
  --namespace kong \
  --create-namespace \
  --set controller.ingressController.enabled=true \
  --set proxy.type=LoadBalancer \
  --set postgresql.enabled=true \
  --set postgresql.auth.password="${DB_PASSWORD}"

Настройка плагинов

Rate limiting с несколькими уровнями. Kong позволяет настроить rate limit на уровне сервиса, роута и consumer. Типичная конфигурация — жёсткий лимит на аноним и мягкий на авторизованного пользователя:

plugins:
  - name: rate-limiting
    config:
      minute: 100
      hour: 1000
      policy: redis
      redis_host: redis.kong.svc.cluster.local
      redis_port: 6379
      hide_client_headers: false
      fault_tolerant: true

policy: redis — единственный правильный выбор при нескольких репликах Kong. Без Redis счётчики не шарятся между подами и лимит умножается на количество реплик.

JWT-аутентификация через JWKS. Вместо хранения ключей в Kong настраиваем валидацию через JWKS URI (Keycloak, Auth0, AWS Cognito):

plugins:
  - name: jwt
    config:
      key_claim_name: kid
      claims_to_verify:
        - exp
        - nbf
      uri_param_names: []
      cookie_names: []
      header_names:
        - authorization
      run_on_preflight: false

Canary-релизы через weighted upstreams

Kong поддерживает weighted routing через два Service + два Route с разными весами в DB-less конфигурации:

upstreams:
  - name: orders-upstream
    targets:
      - target: orders-v1.default.svc.cluster.local:8080
        weight: 90
      - target: orders-v2.default.svc.cluster.local:8080
        weight: 10

Плавное переключение трафика: увеличиваем вес с 10% до 100% за 3-4 дня, отслеживая p99 latency и error rate. В одном из проектов p99 снизилась с 200ms до 50ms, error rate упал с 5% до 0.5%.

Кейс: настройка Kong для e-commerce с 50 микросервисами

Клиент — интернет-магазин с 50 микросервисами, пиковая нагрузка 10 000 RPS. Проблемы: rate limiting на каждом сервисе индивидуально (неэффективно), JWT-валидация в каждом сервисе (дублирование логики), отсутствие canary-релизов.

Решение. Установили Kong в DB-less режиме, настроили плагины: rate-limiting (500 RPS для анонимов, 5000 для авторизованных), jwt (валидация через https://auth.example.com/jwks), cors. Для canary-релизов настроили weighted upstreams. Результат: пропускная способность выросла на 50%, расходы на инфраструктуру снизились на 30% за счёт кэширования. Окупаемость — 4 месяца. Экономия составила около $15,000 в год.

Типовые ошибки при настройке Kong

Часто встречающиеся ошибки: использование policy: local при нескольких репликах (лимиты не синхронизируются), отсутствие health checks (потеря трафика), неправильная настройка upstream keepalive (деградация производительности), забытый плагин prometheus для мониторинга и отсутствие rate limiting для внешних запросов (уязвимость к DDoS).

Наблюдаемость: Prometheus, Grafana, OpenTelemetry

Плагин prometheus добавляет метрики на :8100/metrics. Ключевые метрики: kong_http_requests_total (labels: service, route, status_code) для SLO-дашбордов в Grafana, kong_latency_ms_bucket для p95/p99. Трассировка через плагин opentelemetry — каждый запрос получает trace-id, прокидываемый в бэкенд-сервисы, что позволяет видеть полный путь в Jaeger или Tempo.

Управление конфигурацией через decK

decK — официальный CLI для декларативного управления конфигурацией Kong:

# Дамп текущей конфигурации
deck dump --output-file kong-config.yaml
# Проверить diff перед применением
deck diff --state kong-config.yaml
# Применить изменения
deck sync --state kong-config.yaml

При интеграции в CI/CD: deck diff в pipeline показывает, что изменится до мержа PR. deck sync после мержа в main. Откат — git revert + повторный deck sync.

Что входит в работу по настройке Kong Gateway

• Аудит существующей инфраструктуры API
• Проектирование архитектуры плагинов
• Установка и конфигурация Kong в Kubernetes
• Настройка rate limiting, JWT-аутентификации, canary-релизов
• Интеграция с Prometheus и Grafana
• Настройка GitOps через decK
• Документация и обучение команды
• Техническая поддержка в течение месяца

Сроки и стоимость

Базовая установка — от 3 дней. Миграция с существующего решения — до 2 недель. Стоимость рассчитывается индивидуально после аудита. В среднем наши клиенты экономят до 30% ресурсов за счёт правильной настройки rate limiting и кэширования, а пропускная способность увеличивается на 50%.

Как заказать настройку Kong Gateway?

Свяжитесь с нами для аудита вашей инфраструктуры — получите консультацию и предварительную оценку. Закажите настройку Kong Gateway через форму на сайте.