Добрый день, меня зовут Владимир Павлунин, я архитектор технологической платформы в ИТ-команде «Северстали». В прошлой публикации про нашу платформу я лишь коротко написал, что в роли API Gateway у нас стоит Apache APISIX. В этой статье разбираю именно это решение: почему в архитектуре мы оставили APISIX, учитывая доступные альтернативы.

Это продолжение истории. Тут без общих фраз: только требования, проверка кандидатов, спорные места и финальный выбор под связку OIDC + Keycloak + OPA.

Если коротко:

  • это продолжение статьи про платформу, здесь весь фокус на API Gateway;

  • для проверки решения разобрали Apache APISIX, Kong, Tyk, KrakenD CE, Traefik, Higress и Gravitee;

  • ключевая проверка: рабочая связка OIDC + OPA в реальном прод-контуре;

  • по сумме критериев вперед вышел Apache APISIX;

  • самый болезненный миф: выбирать по RPS без единого стенда и общей методики. 

Срез по плагинам, лицензиям и метрикам сообщества актуален на 15 февраля 2026.

Фокус статьи

В первой статье я показал карту платформы целиком. Иначе было нельзя: нужно было объяснить, как все блоки стыкуются между собой. Здесь фокус только на одном решении: почему в архитектуре платформы API Gateway— это APISIX.

Ниже покажу, как мы проверяли границы OSS и платных функций, что получили по связке с OPA и насколько спокойно это живет в Kubernetes, когда сервисов много и время на эксперименты ограничено.

Это узкий и практический разбор одного архитектурного выбора.

Исходные условия

Команда компактная: platform/backend, DevOps и проверка безопасности по проектному запросу. Отдельного «департамента API Gateway» у нас нет.

Среда — Kubernetes-first. Сервисов много, маршрутов много, нагрузка стабильная, задержки чувствительны.

Сроки были рабочие. Мы не могли позволить себе длинный исследовательский цикл на несколько месяцев. Пришлось резать лишнее и выбирать то, что можно проверить руками в рамках PoC.

Что сравнивали

Кандидатов брали из CNCF Landscape. В шорт-лист вошли:

  • Apache APISIX

  • Kong

  • Tyk

  • KrakenD CE (Lura)

  • Traefik

  • Higress

  • Gravitee

Часть решений оставили на следующий раунд (Envoy Gateway, kgateway, Emissary-Ingress). Причина простая: дедлайн и ограниченный ресурс команды.

Критерии

Чтобы обсуждение не скатилось в «нравится/не нравится», сразу зафиксировали критерии:

  1. Лицензия и границы OSS / платной части.

  2. OIDC и OPA без экзотических обходов.

  3. Поведение под нагрузкой и задержка.

  4. Живость сообщества и качество документации.

  5. Эксплуатация в Kubernetes: ingress, наблюдаемость, rollout.

  6. Популярность в РФ как отдельный сигнал.

Сводная таблица

Решение

Лицензия

OPA/OIDC в OSS-контуре

Граница OSS vs коммерция

Производительность в статье

Сообщество (GitHub, 15.02.2026)

K8s/Ingress

Apache APISIX

Apache 2.0

OPA: да (opa), OIDC: да (openid-connect)

Ключевые функции доступны в OSS

Без чисел: сравнение качественное

~16.1k stars

Зрелая

Kong

OSS Apache 2.0 + Enterprise

OPA: Enterprise plugin, OIDC: Enterprise plugin

Сильная зависимость от Enterprise в этом сценарии

Без чисел: сравнение качественное

~42.5k stars

Зрелая

Tyk

Core MPL 2.0 + Enterprise

OIDC есть в OSS Gateway (deprecated с 5.7.0, рекомендуют JWT); OPA через Dashboard/enterprise-контур

Смешанная модель OSS + платные расширения

Без чисел: сравнение качественное

~10.5k stars

Зрелая

KrakenD CE (Lura)

Apache 2.0

JWT/OIDC из коробки; OPA через кастом/внешний путь

OSS, но по policy больше ручной работы

Без чисел: сравнение качественное

~6.7k stars

Есть

Traefik

OSS MIT + Hub/Enterprise

OPA/OIDC не как “из коробки в OSS core”, а через Hub/плагин-экосистему

Нужна детальная проверка границы Hub/Enterprise

Без чисел: сравнение качественное

~60.9k stars

Очень сильная

Higress

Apache 2.0

OPA/OIDC через официальные плагины в auth-каталоге (Wasm)

OSS, нужен отдельный продовый PoC

Без чисел: сравнение качественное

~7.5k stars

Сильная (Istio/Envoy база)

Gravitee

OSS + Enterprise

OIDC подтвержден; нативного OPA policy-плагина в APIM-каталоге не нашли

Смешанная модель, enterprise-часть весомая

Без чисел: сравнение качественное

Репозитории APIM/AM разнесены

Зрелая

Почему без RPS-таблицы? Потому что «чужие» цифры без единой лаборатории дают ложное чувство точности.

Как считали итог

В ADR использовали весовую модель:

  • OIDC/OPA-практичность в нашем контуре: 35%;

  • границы OSS vs коммерция: 25%;

  • k8s-операционка: 20%;

  • экосистема и поддерживаемость: 10%;

  • производительность: 10%.

Популярность в РФ в итоговый балл не включали.

Баллы скоринга

Шкала: 1..5. Итог = сумма балл * вес.

Решение

OIDC/OPA 35%

OSS/коммерция 25%

Kubernetes-операции 20%

Экосистема 10%

Производительность 10%

Итоговый балл

Apache APISIX

5

5

4

4

4

4.70

Kong

3

2

4

5

4

3.25

Tyk

3

3

4

4

4

3.40

KrakenD CE (Lura)

3

5

3

3

3

3.50

Traefik

3

3

5

5

3

3.70

Higress

3

5

4

3

3

3.70

Gravitee

3

3

4

4

3

3.35

Отдельный фактор: стоимость перехода

Мы отдельно учитывали цену перехода с уже работающего APISIX: миграционные риски, правка ранбуков, обучение команды и вероятность просадки SLO.

Этот фактор не входил в формулу, но помогал разруливать близкие результаты.

Почему остались на APISIX

1) Понятные границы по лицензии

Для нас это не идеология. Это про предсказуемость бюджета и меньше сюрпризов на этапе роста.

2) OIDC + OPA собирается рабочей конфигурацией

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

3) Спокойная жизнь в эксплуатации

На длинной дистанции важен не красивый слайд, а то, как система ведёт себя в инциденте в 2 часа ночи.

Технические примеры

Ниже минимальные рабочие фрагменты.

Пример 1. APISIX: OIDC + OPA

{
   "uri": "/api/*",
   "upstream": {
     "type": "roundrobin",
     "nodes": {
       "orders.default.svc.cluster.local:8080": 1
     }
   },
   "plugins": {
     "openid-connect": {
       "client_id": "gateway-client",
       "client_secret": "${{OIDC_CLIENT_SECRET}}",
       "discovery": "https://keycloak.example.com/realms/platform/.well-known/openid-configuration",
       "bearer_only": true,
       "realm": "platform"
     },
     "opa": {
       "host": "http://opa.default.svc.cluster.local:8181",
       "policy": "httpapi/authz/allow",
       "with_route": true,
       "with_consumer": true
     }
   }
 }

Что важно:

  • openid-connect валидирует токен и передаёт контекст дальше;

  • opa принимает policy-решение;

  • секреты храним в менеджере секретов и Kubernetes Secrets, не в явном конфиге.

Пример 2. Rego policy

package httpapi.authz
 
 default allow = false
 
 allow {
   input.request.method == "GET"
   startswith(input.request.path, "/api/orders")
   input.jwt.claims.realm_access.roles[_] == "orders_reader"
 }
 
 allow {
   input.request.method == "POST"
   startswith(input.request.path, "/api/orders")
   input.jwt.claims.realm_access.roles[_] == "orders_writer"
 }

Плюс такого подхода: правила версионируются отдельно, проверка безопасности проходит проще, перенос между окружениями спокойнее.

Схема потока запроса

Логика простая: API Gateway подтверждает identity, OPA отвечает за policy.
Логика простая: API Gateway подтверждает identity, OPA отвечает за policy.

Чеклист миграции: rollout и canary

  1. Зафиксировать baseline: p95/p99, error rate, доля 401/403, таймауты.

  2. Поднять gateway в shadow-режиме, не трогая боевой маршрут.

  3. Включить OIDC, потом OPA, прогнать негативные кейсы.

  4. Запустить canary на 1-5% некритичного трафика.

  5. Сравнить canary с baseline по latency, 4xx/5xx, CPU/RAM.

  6. Повышать долю поэтапно: 10% -> 25% -> 50% -> 100%.

  7. Держать быстрый rollback через ingress/route-переключение.

  8. После 100% оставить усиленное наблюдение минимум на 1-2 недели.

Этот раздел не самый зрелищный, но именно он обычно экономит часы и нервы.

Где мы сами споткнулись:

  • сравнение по вакансиям шумное: много нерелевантных совпадений;

  • спор «у кого выше RPS» быстро съедает время без общей методики;

  • документация местами так склеивает OSS и платные функции, так что ошибиться очень легко.

Этот набор проблем встречается почти в каждом подобном сравнении.

Итог

Мы оставили Apache APISIX как базовый API-шлюз в нашем контуре.

Не потому что он «лучший в мире». Просто в наших ограничениях он дал самый понятный баланс: рабочий OIDC + OPA, прозрачная OSS-модель и спокойная эксплуатация в Kubernetes.

Если у вас похожий стек, стартуйте с проверки лицензий и операционных рисков. Красивые графики производительности лучше смотреть после этого.

Что можно сделать дальше:

  • прогнать единый нагрузочный тест всех кандидатов на одном стенде;

  • формализовать матрицу оценки с весами и критериями для следующих раундов;

  • для Higress и Gravitee провести отдельный PoC по тем же сценариям OIDC/OPA и тем же SLO.

Источники