Что это такое
Kong Gateway — API-шлюз для микросервисов, обычного API-трафика и новых сценариев вокруг LLM/MCP. Его центральная роль — стоять между клиентами и сервисами.
Проект вырос из практической инфраструктурной задачи: когда сервисов становится много, маршрутизация, проверка доступа, лимиты, наблюдаемость и политики не должны жить в каждом сервисе отдельно.
Главная задача Kong — принимать запросы, проксировать их к нужным сервисам, применять плагины и давать единый слой управления трафиком.
Что внутри
Внутри проекта — Lua/OpenResty-экосистема, плагины, документация, Kubernetes Ingress Controller, режимы установки и материалы для собственного запуска.
Kong умеет маршрутизировать, балансировать, проверять здоровье сервисов, добавлять аутентификацию, ограничивать частоту запросов и расширяться через каталог плагинов.
Как используют
Обычный сценарий: команда ставит Kong перед набором сервисов, заводит routes и services, затем добавляет политики безопасности, логирования и лимитов.
В Kubernetes Kong часто используют как ingress-слой, чтобы управлять входящим трафиком к сервисам через декларативные правила.
Пример
Маршрут через API-шлюз
Пример показывает роль Kong: внешний путь связывается с внутренним сервисом, а политики можно добавлять поверх маршрута.
client -> Kong Gateway -> service: http://orders:8080
route: /api/orders
plugins: auth, rate-limit, loggingСильные стороны
Сильная сторона проекта — расширяемость. API-шлюз становится не просто прокси, а местом, где можно централизованно применять повторяющиеся правила.
Еще одно преимущество — зрелость в микросервисной среде: многие задачи вокруг трафика уже оформлены как готовые плагины и интеграции.
Ограничения
Ограничение в том, что API-шлюз становится критической точкой архитектуры. Ошибка в конфигурации, плагине или лимите может затронуть много сервисов сразу.
Также Kong не заменяет хороший контракт API. Он управляет входом и политиками, но качество схем, ошибок и версионирования остается задачей команд сервисов.
Кому подойдет
Kong подойдет организациям с несколькими сервисами, которым нужен единый контроль входящего трафика, безопасности и наблюдаемости.
Для маленького приложения с одним API он может быть избыточным, если те же задачи спокойно решаются внутри фреймворка.
В каталоге Kong важен как один из заметных открытых проектов на границе API-инфраструктуры и платформенной инженерии.
Практический старт — подключить один не критичный сервис, описать маршрут, добавить простой плагин и проверить, как команда будет хранить и ревьюить конфигурацию.
В практической архитектуре Kong часто появляется в тот момент, когда сервисов уже достаточно много, чтобы политики начали повторяться. Если аутентификация, лимиты и журналы настраиваются в одном месте, команды сервисов меньше копируют одинаковый код.
Для зрелого использования Kong важно относиться к конфигурации как к коду. Маршруты, сервисы и политики должны проходить ревью, храниться прозрачно и обновляться вместе с изменениями самих API.