Налаштування Kong Gateway для керування API-трафіком

Коли мікросервісів стає багато, управління API-трафіком без єдиного шлюзу перетворюється на хаос: rate limiting не синхронізований, аутентифікація розмазана по сервісах. Ми налаштовуємо Kong Gateway під ключ — консолідуємо весь трафік в єдиній точці входу з багатою плагінною екосистемою та повною спостережуваністю, забезпечуючи стабільну роботу та подальшу підтримку.
Часті запитання

Відмітимо: коли кількість мікросервісів перевищує десяток, управління 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

Крок 1: Аудит поточної інфраструктури

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

Крок 2: Вибір режиму конфігурації: DB-less або PostgreSQL

Характеристика DB-less PostgreSQL
Управління Declarative (YAML) Через Admin API
Зміни Pull request + deck sync Динамічні, без деплою
GitOps Ідеально Вимагає синхронізації
Відмовостійкість Залежить від etcd База даних
Швидкість apply < 1 сек (в 3 рази швидше, ніж PostgreSQL) 2-5 сек
Підходить для GitOps-пайплайни Часті зміни

DB-less краще підходить для GitOps, PostgreSQL — для динамічних змін.

Крок 3: Деплой за допомогою Helm

Приклад встановлення Kong Ingress Controller
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}"

Крок 4: Налаштування плагінів

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

Крок 5: 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 (валідація через JWKS URI), 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 днів за ціною від $1500. Міграція з існуючого рішення — до 2 тижнів за $5000. Вартість розраховується індивідуально після аудиту. В середньому наші клієнти економлять до 30% ресурсів за рахунок правильного налаштування rate limiting і кешування, а пропускна здатність збільшується на 50%.

Чому варто обрати нас

Ми — команда сертифікованих спеціалістів Kong з 5+ років досвіду та 50+ виконаних проєктів. Гарантуємо якість налаштування та технічну підтримку. Наш досвід підтверджується відгуками клієнтів та сертифікатами.

Як замовити налаштування Kong Gateway?

Зв'яжіться з нами для аудиту вашої інфраструктури — отримайте консультацію та попередню оцінку.

Наші компетенції:

Останні роботи

  • Розробка сайту компанії B2B ADVANCE
    Розробка сайту компанії B2B ADVANCE
    1542
  • Розробка веб-додатків для компанії FEEDME
    Розробка веб-додатків для компанії FEEDME
    1394
  • Розробка веб-сайту для компанії БЕЛФІНГРУП
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    1081
  • Розробка інтернет магазину для компанії FURNORO
    Розробка інтернет магазину для компанії FURNORO
    1369
  • Розробка логотипу компанії B2B Advance
    Розробка логотипу компанії B2B Advance
    816
  • Розробка веб-додатків для компанії Enviok
    Розробка веб-додатків для компанії Enviok
    1141