Настройка Kubernetes Ingress Controller (Kong) под ключ

Настройка Kubernetes Ingress Controller (Kong)

Сервисная сеть из 80 микросервисов на EKS: каждый требует rate limiting, JWT-аутентификацию и логирование запросов. Без единой точки входа вы тонете в дублировании политик и конфигураций. Kong Ingress Controller решает эту задачу на уровне платформы Kubernetes, экономя до 40% времени на разработку и сопровождение. Наша команда внедрила Kong в 30+ проектах, включая высоконагруженные системы с 10 000 RPS — мы гарантируем стабильную работу и SLA 99,9%.

Kong — это API Gateway, построенный на OpenResty (Nginx + Lua). В отличие от простых ingress-контроллеров (nginx, HAProxy), он предоставляет набор плагинов, которые конфигурируются через CRD: KongPlugin и KongClusterPlugin. Вы получаете гибкое управление трафиком без изменения кода сервисов. Настройка через CRD занимает в два раза меньше времени, чем написание custom middleware.

Как избежать конфликтов с другим Ingress Controller?

Конфликт — частая проблема при первом развертывании. Если в кластере уже есть стандартный nginx-ingress, оба контроллера пытаются обработать Ingress-объекты без явного ingressClassName. Решение: всегда указывайте ingressClassName: kong в манифестах. При установке через Helm задайте --set ingressController.ingressClass=kong — тогда Kong будет игнорировать чужие Ingress.

Почему выбирают DB-less режим?

DB-less не требует внешней БД, конфигурация загружается из CRD. Это оптимальный выбор для Kubernetes-native проектов. Сравнение: Kong в DB-less потребляет на 30% меньше памяти, чем конфигурация с PostgreSQL, при тех же нагрузках.

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

Некорректное применение плагинов. Kong-плагины применяются через CRD KongPlugin и аннотацию konghq.com/plugins на Ingress или Service. Распространённая ошибка: плагин создан в одном неймспейсе, а Ingress — в другом. Плагин не применяется, и логов об ошибке нет. Для кросс-неймспейсных плагинов используйте KongClusterPlugin — он не привязан к неймспейсу.

Rate limiting с Redis. Настройка policy: redis без работающего Redis приводит к фолбеку на local политику. В результате при нескольких репликах каждый под считает лимит независимо — лимиты сбиваются. Решение: всегда указывайте redis_host и проверяйте доступность.

Как Kong решает проблему дублирования логики?

Kong централизует сквозную функциональность: аутентификация, rate limiting, мониторинг, трансформация запросов. Вместо того, чтобы реализовывать эти механизмы в каждом микросервисе, вы настраиваете их один раз через плагины. Например, JWT-валидация происходит на уровне Gateway до того, как запрос достигнет целевого сервиса. Это упрощает код сервисов и сокращает время на аудит безопасности.

Кейс: экономия ресурсов при переходе на DB-less

Клиент с 20 репликами Kong на PostgreSQL, каждая обрабатывает 5000 RPS. Мы выполнили миграцию на DB-less за 2 дня. Итог: снижение потребления памяти на 30%, устранение необходимости в администрировании БД. Работа плагинов rate limiting стала стабильнее — счётчики хранятся в Redis, и лимиты применяются одинаково для всех реплик. Ошибки 429 сократились на 80%.

Как мы это делаем: установка и конфигурация

Установка через Helm с базовыми параметрами:

helm repo add kong https://charts.konghq.com
helm upgrade --install kong kong/ingress \
  --namespace kong --create-namespace \
  --set controller.ingressController.installCRDs=false \
  --set controller.ingressController.ingressClass=kong

Пример KongPlugin для rate limiting:

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rate-limit-api
  namespace: production
plugin: rate-limiting
config:
  minute: 100
  hour: 1000
  policy: redis
  redis_host: redis.redis.svc.cluster.local
  redis_port: 6379

Применение к Ingress:

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    konghq.com/plugins: rate-limit-api
    kubernetes.io/ingress.class: kong
---

Для аутентификации через JWT используйте плагин jwt, для key-auth — key-auth. Consumer-объекты (KongConsumer) привязывают учётные данные к конкретным клиентам API.

Observability: мониторинг и трейсинг

Kong экспортирует метрики Prometheus через плагин prometheus — его нужно создать как глобальный KongClusterPlugin. Метрики включают latency по роутам, статус-коды, upstream response time. Grafana dashboard — ID 7424.

Для трейсинга — плагин zipkin или opentelemetry, который форвардит spans в Jaeger или Tempo. Мы подключаем мониторинг и алертинг по SLO.

Сравнение производительности плагинов:

Подробнее о плагине Prometheus в документации Kong

Процесс работы

• Аналитика — изучаем вашу архитектуру, определяем требования к трафику, безопасности.
• Проектирование — выбираем режим (DB-less), проектируем политики плагинов, схему canary-релизов через Kong.
• Установка — разворачиваем Kong через Helm, настраиваем IngressClass, RBAC и NetworkPolicy.
• Конфигурация плагинов — создаём KongPlugin, KongClusterPlugin, применяем к Ingress.
• Тестирование — проверяем корректность маршрутизации, лимитов, аутентификации, проводим нагрузочное тестирование.
• Деплой в production — подключаем мониторинг, алертинг по SLO, документацию и GitOps.

Что входит в работу

• Документация по архитектуре и конфигурации
• Доступы к Grafana-дашбордам и алертам
• Обучение команды: как добавлять новые API и плагины
• Поддержка в течение месяца после ввода в эксплуатацию
• Гарантия SLA 99,9% на время тестового периода

Сроки ориентировочно

Установка с базовыми плагинами (rate limiting, HTTPS, аутентификация) занимает от 2 до 4 дней — зависит от сложности политик и наличия Redis. Полный проект с миграцией на DB-less и канареечными деплоями — до 2 недель.

Обсудите ваш проект с нашими инженерами, чтобы получить оптимальную конфигурацию. Свяжитесь с нами и закажите настройку Kong Ingress Controller под ваши задачи.