Налаштування 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% менше пам'яті та працює в 1.5 рази швидше, ніж конфігурація з 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% (економія ~$5000/міс на інфраструктуру), усунення необхідності в адмініструванні БД. Робота плагінів 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

Процес роботи (покроково)

1. Аналітика — вивчаємо вашу архітектуру, визначаємо вимоги до трафіку та безпеки.
2. Проектування — обираємо режим (DB-less), проектуємо політики плагінів, схему canary-релізів через Kong.
3. Встановлення — розгортаємо Kong через Helm, налаштовуємо IngressClass, RBAC та NetworkPolicy.
4. Конфігурація плагінів — створюємо KongPlugin, KongClusterPlugin, застосовуємо до Ingress.
5. Тестування — перевіряємо коректність маршрутизації, лімітів, аутентифікації, проводимо навантажувальне тестування.
6. Деплой в production — підключаємо моніторинг, алертинг по SLO, документацію та GitOps.

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

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

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

Встановлення з базовими плагінами (rate limiting, HTTPS, аутентифікація) займає від 2 до 4 днів — залежить від складності політик та наявності Redis. Повний проект з міграцією на DB-less та канарковими деплоями — до 2 тижнів. Економія від впровадження може сягати $5000 на місяць.

Обговоріть ваш проект з нашими інженерами, щоб отримати оптимальну конфігурацію. Зв'яжіться з нами та замовте налаштування Kong Ingress Controller під ваші завдання.