Архитектура Kong, основные компоненты, use cases и сравнение с альтернативами
Kong Gateway — это облачно-нативный API-шлюз с открытым исходным кодом, который решает проблему централизации кросс-сервисных задач в микросервисной архитектуре.
Проблема: В микросервисной архитектуре каждый сервис должен реализовывать:
Это приводит к:
Решение: API Gateway выносит эти задачи на уровень шлюза. Микросервисы фокусируются на бизнес-логике, а Kong обрабатывает кросс-сервисные задачи централизованно.
┌─────────────┐
│ Клиент │
└──────┬──────┘
│
▼
┌─────────────────────────────┐
│ Kong Gateway │
│ ┌───────────────────────┐ │
│ │ Authentication │ │
│ │ Rate Limiting │ │
│ │ Logging & Metrics │ │
│ │ Routing │ │
│ └───────────────────────┘ │
└──────────┬──────────────────┘
│
┌──────┴──────┬────────────┐
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│ Users │ │ Orders │ │ Payments│
│ Service│ │ Service│ │ Service │
└────────┘ └────────┘ └────────┘
Kong состоит из двух основных компонентов:
Проблема: Нужен высокопроизводительный компонент для обработки входящего трафика.
Решение: Data Plane — это компонент, который непосредственно принимает HTTP-запросы и проксирует их на upstream-сервисы. Основан на nginx, что обеспечивает высокую производительность.
Проблема: Нужно централизованное управление конфигурацией всех узлов Data Plane.
Решение: Control Plane хранит конфигурацию и управляет ею через Admin API.
┌──────────────────┐
│ Control Plane │
│ ┌────────────┐ │
│ │ Admin API │ │
│ │ PostgreSQL │ │
│ └────────────┘ │
└────────┬─────────┘
│
│ распространяет конфигурацию
│
┌────┴────┐
▼ ▼
┌────────┐ ┌────────┐
│ Data │ │ Data │
│ Plane │ │ Plane │
└────────┘ └────────┘
Проблема: Нужна абстракция для бэкенд-сервисов, чтобы не хардкодить URL в конфигурации маршрутизации.
Решение: Service — это представление upstream-сервиса в Kong.
# Создаём Service для бэкенда пользователей
curl -X POST http://localhost:8001/services \
--data "name=users-api" \
--data "url=http://users-service:8080"Service содержит:
name — уникальное имя сервисаurl — URL бэкенда (протокол, хост, порт, опционально path)connect_timeout, write_timeout, read_timeout — таймаутыretries — количество попыток подключенияПроблема: Нужно маршрутизировать запросы на разные сервисы в зависимости от пути, хоста, методов.
Решение: Route — правило маршрутизации, которое связывает входящие запросы с Service.
# Создаём Route для пользователей
curl -X POST http://localhost:8001/services/users-api/routes \
--data "name=users-route" \
--data "paths[]=/api/users" \
--data "methods[]=GET" \
--data "methods[]=POST"Route поддерживает различные условиясоответствия:
paths —соответствия path запроса (/api/users)hosts —соответствия хоста (api.example.com)methods — HTTP-методы (GET, POST, etc.)headers — заголовки запросаsnis — SNI для TLSПроблема: Нужно идентифицировать пользователей/приложений для аутентификации, авторизации и rate limiting.
Решение: Consumer — представление пользователя или приложения в Kong.
# Создаём потребителя
curl -X POST http://localhost:8001/consumers \
--data "username=mobile-app"Consumer может иметь:
Проблема: Нужен механизм для применения политик (аутентификация, логирование, rate limiting) к запросам.
Решение: Plugin — расширяемый компонент, который выполняется на разных этапах обработки запроса.
# Применяем rate limiting к Route
curl -X POST http://localhost:8001/routes/users-route/plugins \
--data "name=rate-limiting" \
--data "config.minute=100" \
--data "config.policy=redis"Kong предоставляет встроенные плагины:
Проблема: Нужно понимать, когда и какие плагины выполняются при обработке запроса.
Решение: Kong выполняет плагины на определённых этапах жизненного цикла:
1. DNS Resolution
↓
2. Rewrite (преобразование запроса)
↓
3. Access (аутентификация, авторизация, rate limiting)
↓
4. Proxy (отправка на upstream)
↓
5. Response (получение ответа от upstream)
↓
6. Body Filter (трансформация тела ответа)
↓
7. Header Filter (трансформация заголовков ответа)
↓
8. Log (логирование, отправка метрик)
Пример выполнения плагинов:
key-auth проверяет API-ключ, rate-limiting проверяет лимитusers-service:8080response-transformer добавляет заголовкиprometheus экспортирует метрики, http-log отправляет логиПроблема: Нужна персистентная конфигурация с возможностью динамического обновления.
Решение: Control Plane использует PostgreSQL для хранения конфигурации.
# docker-compose.yml
services:
kong:
image: kong:3.5
environment:
KONG_DATABASE: postgres
KONG_PG_HOST: postgres
KONG_PG_USER: kong
KONG_PG_PASSWORD: kong
ports:
- "8000:8000"
- "8443:8443"
- "8001:8001"
- "8444:8444"Преимущества:
Проблема: Нужна простая развёртываемость без зависимости от базы данных, конфигурация как код.
Решение: Конфигурация загружается из YAML-файла при старте.
# Запуск в DB-less режиме
kong start --conf-file /path/to/kong.yml# kong.yml
_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
policy: redisПреимущества:
Проблема: Нужно централизованное управление множеством узлов Data Plane с возможностью горизонтального масштабирования.
Решение: Разделение Control Plane и Data Plane на разные узлы.
┌─────────────────────┐
│ Control Plane │
│ (отдельный узел) │
│ - Admin API │
│ - PostgreSQL │
└──────────┬──────────┘
│
│ защищённое соединение (TLS)
│
┌──────┴──────┬────────────┐
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│ DP 1 │ │ DP 2 │ │ DP 3 │
│ (EU) │ │ (US) │ │ (AS) │
└────────┘ └────────┘ └────────┘
Преимущества:
Проблема: Нужно понимать разницу между API Gateway и Service Mesh.
Решение: Kong Gateway и Kong Mesh решают разные задачи:
| Характеристика | Kong Gateway | Kong Mesh |
|---|---|---|
| Тип трафика | Север-Юг (клиент → сервис) | Восток-Запад (сервис → сервис) |
| Развёртывание | Центральный шлюз | Sidecar в каждом pod |
| Безопасность | TLS termination | mTLS между сервисами |
| Маршрутизация | По path/host к сервисам | Traffic splitting между версиями |
| Основа | nginx | Envoy proxy |
Север-Юг трафик:
Клиент → [Kong Gateway] → Сервис
Восток-Запад трафик:
Сервис A → [Sidecar Proxy] → [Sidecar Proxy] → Сервис B
| Решение | Преимущества | Недостатки |
|---|---|---|
| Kong | Зрелый продукт, богатая экосистема плагинов, хорошая документация | Lua для кастомных плагинов, производительность ниже чем у Envoy |
| Envoy Proxy | Высокая производительность, встроенный support для gRPC, HTTP/2 | Сложнее в настройке, меньше готовых плагинов |
| NGINX | Высокая производительность, стабильность | Меньше функций для API management, платная версия для продвинутых функций |
| Traefik | Простота, автоматическое обнаружение сервисов | Меньше плагинов, менее зрелый для enterprise |
| AWS API Gateway | Полностью управляемый, интеграция с AWS | Vendor lock-in, дороже на больших объёмах |
Проблема: 10 микросервисов, каждый реализует JWT-аутентификацию по-своему.
Решение: Kong с плагином jwt-auth проверяет токены централизованно.
curl -X POST http://localhost:8001/plugins \
--data "name=jwt"Проблема: Бесплатные пользователи — 100 запросов/час, премиум — 10000 запросов/час.
Решение: Kong с разными Consumers и плагинами rate-limiting.
# Бесплатный тариф
curl -X POST http://localhost:8001/consumers/free-user/plugins \
--data "name=rate-limiting" \
--data "config.hour=100"
# Премиум тариф
curl -X POST http://localhost:8001/consumers/premium-user/plugins \
--data "name=rate-limiting" \
--data "config.hour=10000"Проблема: Нужно развернуть новую версию сервиса с 10% трафика.
Решение: Kong с weighted upstream (в Kong Mesh) или несколько Routes с разными приоритетами.
Проблема: Нужно видеть latency, RPS, ошибки по всем сервисам в одном месте.
Решение: Kong с плагином prometheus экспортирует метрики для Grafana.
curl -X POST http://localhost:8001/plugins \
--data "name=prometheus"Далее: Установка и настройка