Есть один очень характерный этап взросления инфраструктуры.

Сначала все выглядит прекрасно:

  • один backend,
  • один nginx,
  • один PostgreSQL,
  • один frontend,
  • и один человек, который “примерно помнит где лежат конфиги”.

Все просто. Все понятно. Все работает.

Потом начинается “рост бизнеса”. И внезапно появляются:

  • Kubernetes,
  • микросервисы,
  • мобильные приложения,
  • OAuth2,
  • SSO,
  • партнерские API,
  • внешние интеграции,
  • аудит безопасности,
  • observability,
  • DevOps-команда,
  • Platform Engineering,
  • и человек, который сказал:

“а давайте еще service mesh”.

И вот в этот момент в инфраструктуру приходит API Gateway.

Потому что без него через некоторое время:

  • auth размазан по сервисам,
  • CORS живет своей жизнью,
  • rate limiting отсутствует,
  • retry работает “на вере”,
  • а backend developer уже боится открывать ingress yaml.

Что такое API Gateway

API Gateway - это единая точка входа для API.

То есть:

  • frontend,
  • mobile apps,
  • внешние сервисы,
  • партнеры,
  • AI-агенты,
  • cron jobs,
  • “тот python-скрипт который никто не признает своим”

не ходят напрямую в сервисы. Они идут через gateway.

                 +-------------------+
                 |     API Gateway   |
                 +---------+---------+
                           |
       +-------------------+-------------------+
       |                   |                   |
       v                   v                   v
+-------------+   +---------------+   +---------------+
| auth-api    |   | users-api     |   | billing-api   |
+-------------+   +---------------+   +---------------+

Gateway становится:

  • reverse proxy,
  • security layer,
  • traffic manager,
  • policy engine,
  • точкой мониторинга,
  • централизованным ingress,
  • и иногда причиной фразы:

“а кто вообще менял этот plugin?”

Почему nginx перестает хватать

На старте nginx действительно решает почти все задачи:

  • reverse proxy,
  • SSL,
  • балансировка,
  • basic routing.

Но потом приходят:

  • JWT,
  • OAuth2,
  • OpenID Connect,
  • mTLS,
  • API keys,
  • tracing,
  • canary deploy,
  • rate limiting,
  • retries,
  • audit logging,
  • observability.

И внезапно оказывается - что копировать одну и ту же логику:

  • в каждый сервис,
  • в каждый framework middleware,
  • в каждый backend

- очень плохая идея.

Потому что через полгода:

  • один сервис валидирует JWT правильно,
  • второй “почти правильно”,
  • третий вообще не проверяет expiration.

А потом приходит отдел информационной безопасности.

И начинается новый сезон сериала:

Почему у нас refresh token живет 365 дней?

Что умеет API Gateway

Routing - маршрутизация запросов

Самая базовая функция. Gateway понимает - куда отправить запрос.

Например:

/api/users        -> users-service
/api/payments     -> payments-service
/api/admin        -> admin-service

Что это дает

Единый endpoint

Frontend знает только:

api.company.local

а не:

users-service.namespace.svc.cluster.local

Скрытие внутренней архитектуры

Клиент не знает:

  • сколько у вас сервисов,
  • как они называются,
  • где они живут.

Это:

  • безопаснее,
  • удобнее,
  • проще для поддержки.

Простая миграция backend

Вы можете:

  • перенести сервис,
  • переименовать его,
  • заменить стек,
  • переписать backend,

не ломая frontend.

Authentication и Authorization

Вот тут gateway начинает приносить огромную пользу. Потому что auth - это одна из самых быстро разрастающихся частей инфраструктуры.

Что обычно поддерживается

  • JWT
  • OAuth2
  • OpenID Connect
  • LDAP
  • SAML
  • API Keys
  • mTLS

Интеграции обычно делают с:

  • Keycloak,
  • HashiCorp Vault,
  • Active Directory,
  • FreeIPA.

Почему это важно

Без gateway каждый сервис:

  • отдельно валидирует JWT,
  • отдельно проверяет scopes,
  • отдельно ходит в LDAP,
  • отдельно работает с refresh token.

И через некоторое время:

  • логика расходится,
  • появляются уязвимости,
  • backend-разработчики начинают ненавидеть auth.

Что делает gateway

Централизованная JWT validation

JWT проверяется один раз.

Backend получает уже валидированный запрос.

Проверка ролей и scopes

Например:

{
  "roles": ["admin"],
  "scope": "payments:write"
}

Gateway может:

  • пустить запрос,
  • отклонить,
  • перенаправить.

Token introspection

Особенно важно при OAuth2.

Gateway может:

  • проверить токен,
  • проверить expiration,
  • проверить issuer,
  • проверить audience.

Rate Limiting

Без него всегда находится:

  • crawler,
  • партнер,
  • junior frontend developer,
  • AI bot,

который случайно запускает:

while True:
    requests.get(api)

И backend начинает грустить.

Что делает rate limiting

Ограничение количества запросов

Например:

  • 100 запросов в минуту,
  • 1000 запросов в час.

Защита backend

Backend перестает умирать от:

  • случайных циклов,
  • retry storm,
  • brute force,
  • parser attacks.

Контроль партнеров

Очень важно для:

  • SaaS,
  • B2B API,
  • публичных API.

Fair usage

Один клиент не съедает все ресурсы.

Пример Kong Plugin

apiVersion: configuration.konghq.com/v1
kind: KongPlugin

metadata:
  name: rate-limit
plugin: rate-limiting
config:
  minute: 100
  hour: 1000
  policy: redis

TLS termination

HTTPS обычно завершается именно на gateway.

Что это дает

Централизованное управление сертификатами

Сертификаты лежат:

  • в одном месте,
  • обновляются централизованно,
  • проще ротируются.

Упрощение backend

Backend может работать:

  • внутри сети,
  • по HTTP,
  • без TLS overhead.

Интеграция с cert-manager

В Kubernetes это особенно удобно.

annotations:
  cert-manager.io/cluster-issuer: letsencrypt-prod

mTLS

Gateway может проверять клиентские сертификаты.

Это очень важно:

  • для B2B API,
  • fintech,
  • enterprise.

Caching

Очень недооцененная функция gateway.

Что такое caching

Gateway может:
не ходить каждый раз в backend,
а отдавать уже готовый ответ из кеша.

Пример

Вместо:

Client -> Gateway -> Backend -> Database

получаем:

Client -> Gateway Cache

Что это дает

Снижение нагрузки на backend

Особенно полезно для:

  • catalog API,
  • public data,
  • configuration endpoints.

Ускорение response time

Кешированный ответ может возвращаться:

  • за миллисекунды,
  • без похода в backend.

Защита database

Очень часто именно кеш спасает PostgreSQL от:

SELECT * FROM users

выполняемого 5000 раз в минуту.

Но есть нюансы

Cache invalidation

Самая страшная проблема computer science.

Потому что:

“почему пользователь видит старые данные?”

Нельзя кешировать все подряд

Особенно:

  • auth endpoints,
  • personal data,
  • highly dynamic responses.

Compression

Еще одна функция которую многие недооценивают.

Что делает compression

Gateway может:

  • gzip,
  • brotli,
  • deflate

сжимать ответы backend.

Что это дает

Меньше сетевого трафика

JSON:

{
  "users": [...]
}

может уменьшиться:

  • в 5-10 раз.

Быстрее mobile clients

Особенно важно:

  • в мобильных сетях,
  • при слабом интернете.

Меньше нагрузка на CDN и ingress

Минусы compression

Дополнительная CPU нагрузка

Сжатие требует CPU. Особенно Brotli на высоких уровнях.

Не все данные эффективно сжимаются

Например:

  • JPEG,
  • MP4,
  • ZIP

уже сжаты.

Retry Policies

Вот тут начинается distributed systems magic.

Что такое retry

Если backend:

  • временно недоступен,
  • ответил 502,
  • timeout,

gateway может:
автоматически повторить запрос.

Что это дает

Повышение отказоустойчивости

Очень часто backend “мигнул”:

  • pod перезапустился,
  • GC pause,
  • кратковременный network issue.

Retry спасает клиента от ошибки.

Скрытие transient failures

Пользователь даже не замечает проблему.

Но есть огромная проблема

Retry storm

Если retry настроен неправильно:

  • gateway начинает долбить backend,
  • backend умирает еще сильнее,
  • вся система входит в feedback loop.

Классический сценарий

backend slow
-> requests timeout
-> retries
-> backend even slower
-> more retries
-> cluster dies

Distributed systems очень любят такие моменты.

Circuit Breaker

Еще одна важнейшая функция gateway.

Что делает circuit breaker

Если backend:

  • падает,
  • отвечает ошибками,
  • слишком медленный,

gateway временно прекращает слать туда трафик.

Что это дает

Защита backend

Backend получает время:

  • восстановиться,
  • перезапуститься,
  • перестать гореть.

Защита всей системы

Один падающий сервис:
не тянет за собой остальные.

Load Balancing

Gateway умеет распределять трафик между pod’ами.

Алгоритмы

Round Robin

Запросы идут по кругу.

Least Connections

Трафик идет туда:
где меньше активных соединений.

Weighted balancing

Можно:

  • больше трафика на мощные pod,
  • меньше на слабые.

Observability

Вот здесь gateway становится невероятно ценным. Потому что весь внешний трафик проходит через него.

Что можно видеть

Latency

Какие endpoint медленные.

Error rates

Где:

  • 500,
  • 502,
  • 504.

Tracing

Полный путь запроса:

  • gateway,
  • service,
  • database.

Интеграции

Обычно:

  • Prometheus
  • Grafana
  • Jaeger
  • Grafana Tempo
  • OpenTelemetry

Когда API Gateway нужен обязательно

Микросервисы

Без gateway frontend начинает знать внутреннюю структуру backend. Появляется хаос endpoint’ов. Auth дублируется. Headers различаются.

Публичное API

Интернет очень любит:

  • сканировать API,
  • ломать API,
  • перегружать API.

Без gateway:

  • нет нормального rate limiting,
  • нет централизованной защиты,
  • нет audit logging.

Мобильные приложения

Gateway помогает:

  • aggregation,
  • caching,
  • compression,
  • backward compatibility.

OAuth2 / SSO

Без gateway auth начинает расползаться по сервисам.

Kubernetes

Gateway становится:

  • ingress,
  • traffic manager,
  • TLS manager,
  • observability point.

Service Mesh

Mesh работает внутри.

Gateway - снаружи.

Несколько команд разработки

Gateway стандартизирует:

  • auth,
  • logging,
  • headers,
  • API conventions.

Партнерские интеграции

Нужны:

  • quotas,
  • API keys,
  • SLA,
  • analytics,
  • audit.

Установка Kong в Kubernetes

Kong Gateway Helm Chart

Добавляем Helm repo

helm repo add kong https://charts.konghq.com
helm repo update

Namespace

kubectl create namespace kong

values.yaml

deployment:
  kong:
    enabled: true
ingressController:
  enabled: true
env:
  database: "off"
proxy:
  type: LoadBalancer
admin:
  enabled: true
  type: ClusterIP
replicaCount: 2
resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "1"
    memory: "1Gi"

Установка

helm install kong kong/kong \
  --namespace kong \
  -f values.yaml

Проверяем

kubectl get pods -n kong

Итог

API Gateway - это не “просто reverse proxy”.

Это:

  • security layer,
  • traffic manager,
  • policy engine,
  • observability point,
  • centralized ingress,
  • API control plane.

Именно поэтому gateway:

  • может сильно упростить инфраструктуру,
  • а может превратить ее в distributed YAML nightmare.

Главное правило здесь очень простое:

Если ваш API Gateway содержит больше бизнес-логики чем backend - вы где-то очень сильно свернули не туда.

И да. Рано или поздно почти любая инфраструктурная команда приходит к философскому выводу:

Мы поставили API Gateway чтобы упростить систему. Теперь у нас отдельная команда поддерживает API Gateway.

Добро пожаловать в современную инфраструктуру.