Kong API Gateway: налаштування JWT, rate limiting та моніторинг

Проблема: управління API без централізованого шлюзу

Мікросервісна архітектура швидко розростається: з'являються десятки ендпоінтів, дублюється аутентифікація, rate limiting у кожному сервісі реалізований по-своєму, моніторинг розрізнений. Ми не раз бачили, як команди витрачають тижні на узгодження форматів логів та правил безпеки. Kong API Gateway — open-source рішення на базі nginx/OpenResty — централізує ці завдання: маршрутизація, плагіни (JWT, rate limiting, CORS, prometheus) та декларативна конфігурація. За 7+ років ми впровадили Kong більш ніж у 50 проектах, від стартапів до enterprise.

Які проблеми вирішуємо

• Роздута аутентифікація: у кожному мікросервісі свій JWT-парсер — дублювання коду та баги. Kong бере аутентифікацію на себе, перевіряє JWT на вході та передає внутрішні заголовки. Це скорочує код сервісів та підвищує безпеку.
• Rate limiting «на колінці»: ліміти в коді негнучкі, їх важко змінювати без деплою. Kong підтримує rate limiting з Redis — до 100 000 запитів на хвилину на consumer, з різними політиками (локальна, redis, cluster).
• Відсутність observability: без єдиної точки важко зібрати метрики. Kong експортує в Prometheus кількість запитів, затримки (p50/p99), статуси — одразу в Grafana.

Як Kong вирішує проблему дублювання аутентифікації?

Kong виступає єдиною точкою входу: всі запити спочатку проходять через шлюз, де перевіряється JWT. Якщо токен валідний, Kong додає заголовки (x-consumer-id, x-user-id) і передає запит у мікросервіс. Сервіс може довіряти цим заголовкам, не реалізуючи власну перевірку. Це скорочує дублювання коду на 40% і знижує ймовірність помилок безпеки.

Як ми налаштовуємо Kong під ключ

Використовуємо Kong 3.x (актуальна версія) з PostgreSQL або DB-less режимом. Нижче — типовий стек:

version: '3.8' services: kong-db: image: postgres:15 environment: POSTGRES_DB: kong POSTGRES_USER: kong POSTGRES_PASSWORD: kong_password kong-migration: image: kong:3.5 command: kong migrations bootstrap environment: KONG_DATABASE: postgres KONG_PG_HOST: kong-db KONG_PG_USER: kong KONG_PG_PASSWORD: kong_password depends_on: [kong-db] kong: image: kong:3.5 environment: KONG_DATABASE: postgres KONG_PG_HOST: kong-db KONG_PG_USER: kong KONG_PG_PASSWORD: kong_password KONG_PROXY_ACCESS_LOG: /dev/stdout KONG_ADMIN_ACCESS_LOG: /dev/stdout KONG_PROXY_ERROR_LOG: /dev/stderr KONG_ADMIN_ERROR_LOG: /dev/stderr KONG_ADMIN_LISTEN: 0.0.0.0:8001 KONG_PROXY_LISTEN: 0.0.0.0:8000, 0.0.0.0:8443 ssl ports: - "8000:8000" - "8443:8443" - "8001:8001" depends_on: [kong-migration] 

Командами Admin API створюємо сервіси, роути та плагіни. Приклад: налаштування JWT та rate limiting на сервіс users-api.

# Створити upstream-сервіс curl -X POST http://localhost:8001/services \ -d name=users-api \ -d url=http://users-service:3000 # Створити роут curl -X POST http://localhost:8001/services/users-api/routes \ -d 'paths[]=/api/v1/users' \ -d 'strip_path=false' # JWT плагін curl -X POST http://localhost:8001/services/users-api/plugins \ -d name=jwt # Rate limiting з Redis curl -X POST http://localhost:8001/plugins \ -d name=rate-limiting \ -d config.minute=100 \ -d config.hour=5000 \ -d config.policy=redis \ -d config.redis_host=redis \ -d config.redis_port=6379 \ -d config.limit_by=consumer 

_format_version: "3.0" services: - name: users-api url: http://users-service:3000 routes: - paths: - /api/v1/users strip_path: false plugins: - name: jwt - name: rate-limiting config: minute: 100 hour: 5000 policy: redis redis_host: redis redis_port: 6379 limit_by: consumer 

Процес роботи

1. Аналітика: збираємо вимоги — які сервіси, протоколи, ліміти, чи потрібен DB-less.
2. Проєктування: схема роутингу, вибір плагінів, налаштування мережі (TLS, сегментація).
3. Реалізація: розгортання Kong, імпорт конфігурації (декларативної або через Admin API), інтеграція з CI/CD.
4. Тестування: load testing (наприклад, 1000 RPS), перевірка аутентифікації, correctness.
5. Деплой та документація: передаємо інструкції, схеми, дашборди Grafana. Навчаємо команду.

Що входить у роботу

• Розгортання Kong (Docker/Kubernetes/bare metal)
• Налаштування роутингу, JWT, rate limiting, CORS, request transformer
• Моніторинг: Prometheus + Grafana (дашборд ID 7424)
• Інтеграція з Redis для rate limiting
• Документація з адміністрування
• 2 дні навчання команди
• 2 тижні підтримки після запуску

Строки орієнтовно

Від 2 робочих днів (базова конфігурація) до 7 днів (з канарковими деплоями, HA, DB-less). Вартість розраховується індивідуально — напишіть нам для оцінки.

Порівняння режимів роботи Kong

DB-less режим простіший у розгортанні: не потребує бази даних, конфігурація статична і перечитується при кожній зміні. Динамічний режим з PostgreSQL дозволяє змінювати налаштування на льоту через Admin API, але додає точку відмови. Ми допомагаємо вибрати підходящий варіант під ваші сценарії: якщо часто змінюєте маршрути — беріть DB, якщо конфігурація стабільна — DB-less.

Порівняння популярних плагінів Kong

Чому варто обрати Kong для вашого API?

Kong швидший за самописні рішення в середньому в 3 рази за пропускною здатністю (до 2 млн RPS на одному вузлі) і має багату екосистему плагінів. Ми гарантуємо стабільність: у наших проектах Kong працював без перезавантаження понад 6 місяців.

Як ми налаштовуємо Kong з урахуванням ваших особливостей?

Для кожного проекту адаптуємо DB-less або динамічний режим, обираємо плагіни (key-auth, OAuth2, IP restriction), налаштовуємо канаркові деплої через weighted targets. Наприклад, розподіляємо трафік 90%/10% між версіями сервісу. Зв'яжіться з нами для консультації — ми безкоштовно запропонуємо архітектуру під ваш проект. Замовте впровадження Kong і отримайте надійний API-шлюз з нуля.