lenec ru

← все посты

Дмитрий Орлов Подписаться

ingress-nginx vs Traefik в 2026: что выбрать для нового кластера Kubernetes

10K

Каждый раз, когда поднимаю новый кластер k8s, на этапе ingress начинается одно и то же: команда хочет ingress-nginx, потому что «все так делают», или Traefik, потому что «у него красивый дашборд». А я смотрю и думаю: оба нормальные, но они для разных кейсов. Расскажу, на что я смотрю в 2026, в чём реальные различия и где чьи грабли.

Сравнение — на актуальных версиях: ingress-nginx 1.11 и Traefik 3.2. Кластер k8s 1.30, реальный продакшен e-commerce с пиками до 30K RPS на ingress.

Что общего

Оба — Layer 7 reverse proxy, оба умеют terminate TLS, оба читают Ingress-объекты, оба деплоятся как DaemonSet или Deployment с LoadBalancer-сервисом перед ними.

Оба поддерживают cert-manager для Let's Encrypt, оба работают с ExternalDNS, оба отдают Prometheus-метрики. На базовом уровне — взаимозаменяемы.

Различия начинаются, когда нужно что-то сложнее «прокинь HTTP до сервиса».

ingress-nginx: проверенный конь

Что хорошо

За nginx стоит десятилетие продакшена. Знаешь, как он себя ведёт под нагрузкой, знаешь, какие конфиги он генерирует, знаешь nginx error log наизусть. Это огромный плюс, когда инцидент в три ночи.

Аннотации работают почти как полноценный nginx-конфиг. Хочешь rate-limit, кастомный proxy_read_timeout, своё server_name wildcard — всё через annotations:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api
  annotations:
    nginx.ingress.kubernetes.io/limit-rps: "100"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "60"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api
            port:
              number: 80

Производительность — отличная. На моих графиках ingress-nginx с 4 vCPU тянет 50K RPS статики и 15K RPS в проксированном API. Это в 1.5 раза больше, чем Traefik на той же железке (по моим замерам).

Lua-плагины. Если знаешь OpenResty, можешь писать свою логику прямо в ingress. Например, JWT-валидацию или подмену хедеров на основе query-параметра. С Traefik такого уровня кастомизации без отдельного middleware не получится.

Что плохо

Аннотации — это боль. Когда у тебя 50 ingress-объектов с разными аннотациями, найти, какая комбинация ломает релоад nginx, нелегко. Документация большая, но раскидана.

Релоад nginx — это полноценный nginx -s reload. Каждое изменение Ingress-объекта триггерит регенерацию nginx.conf и релоад. На активных кластерах с CD-пайплайнами nginx иногда релоадится по 10 раз в минуту, и это видно в latency-графиках. Лечится включением --enable-dynamic-configuration, но не на 100%.

В 2024 нашли цепочку CVE (CVE-2025-1097/1098/1974) с RCE через специально подобранные annotations. Лечится upgrade и WAF-правилами на уровне cloud LB, но осадок остался.

Traefik: молодой и амбициозный

Что хорошо

Конфигурация через CRD — это IngressRoute, Middleware, ServersTransport. Никаких аннотаций, всё типизировано в k8s API. Когда у тебя 30 микросервисов, читать YAML с типизированными полями приятнее, чем декодировать строки в annotations.

apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: api
spec:
  entryPoints:
    - websecure
  routes:
    - match: Host(`api.example.com`)
      kind: Rule
      services:
        - name: api
          port: 80
      middlewares:
        - name: rate-limit
  tls:
    secretName: api-tls
---
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: rate-limit
spec:
  rateLimit:
    average: 100
    burst: 50

Hot reload без рестарта. Traefik в Go, конфигурация перечитывается без сброса коннектов. Релоадить можно сколько угодно — клиенты не заметят.

Native gRPC, WebSocket, HTTP/3 — всё работает из коробки. ingress-nginx умеет, но иногда требует допиливания.

Дашборд. Да, он красивый, но он ещё и реально полезный — видно все routes, services, middlewares, TLS-сертификаты. Удобно для дебага.

Что плохо

Traefik 1.x → 2.x → 3.x — каждый раз ломающие изменения в API. Если у тебя кластер живёт несколько лет, миграция между мажорными версиями — болезненная процедура. У ingress-nginx такого почти нет.

Производительность ниже. На моих тестах под одинаковой нагрузкой Traefik 3.2 с 4 vCPU тянул примерно 30K RPS, после чего CPU 100% и latency растёт. Это не плохо, но если ты на пределе — учитывай.

Меньше готовых аннотаций для тонкой настройки. Например, кастомный header-rewrite или conditional rate-limit в Traefik требует middleware-кода, в nginx — одна аннотация.

Сноска: нагрузочное я гонял k6 на синтетике, в реальном проде картина может быть другая. В стейджинге — да.

Сравнительная таблица в виде списка

Performance

  • ingress-nginx — топ. 50K+ RPS на средней железке.
  • Traefik — нормально, до 30K RPS примерно.

Конфигурация

  • ingress-nginx — Ingress + аннотации. Гибко, но грязновато.
  • Traefik — IngressRoute CRD + Middleware. Чисто, типизированно.

TLS / Let's Encrypt

  • ingress-nginx — через cert-manager, стандарт.
  • Traefik — встроенный ACME-клиент, можно cert-manager. Встроенный проще, но не работает корректно с несколькими репликами без shared storage.

Стабильность API

  • ingress-nginx — Ingress API стабильный, аннотации меняются редко.
  • Traefik — мажорные версии ломают конфиги.

Observability

  • ingress-nginx — Prometheus метрики, access log в JSON.
  • Traefik — то же плюс встроенный дашборд.

Что я выбираю

Реальные критерии:

Беру ingress-nginx, если:

  • На входе ожидается 20K+ RPS, и performance важнее красоты.
  • Команда уже знает nginx, и хочется минимальной кривой обучения.
  • Нужны Lua-скрипты или сложные header-манипуляции.
  • Кластер в облаке с поддержкой WAF на уровне LB — riski CVE снижены.

Беру Traefik, если:

  • Микросервисная архитектура, где каждая команда деплоит свой Ingress, и хочется типизированных CRD.
  • Активный CD с частыми релоадами — Traefik их переживает спокойнее.
  • HTTP/3, gRPC, WebSocket из коробки.
  • Стартап, нет жёстких требований к performance, есть требование «всё красиво в дашборде».

Что я бы не делал ни в одном случае

  • Не ставил бы оба одновременно в один кластер. Это путь к админскому хаосу.
  • Не использовал бы ingress-controller от облачного провайдера (AWS ALB Ingress Controller, GKE-native). У них меньше функций, и lock-in. Исключение — если ты строишь чисто managed-историю и не планируешь переезжать.

Гейтвей API: куда всё движется

На горизонте — Gateway API. Это новый стандарт, который должен заменить Ingress, и оба контроллера его поддерживают. В 2026 он всё ещё в бете для большинства фич, но GA-часть уже стабильна. Если строишь новый кластер — стоит присматриваться к Gateway API сразу, особенно для TCPRoute/UDPRoute, которые в Ingress никогда нормально не поддерживались.

Я в новых проектах ставлю ingress-nginx с Gateway API enabled, и для базовых HTTP-роутов использую HTTPRoute вместо Ingress. Через пару лет, думаю, аннотации уйдут в прошлое везде.

Что запомнить

ingress-nginx — для high-traffic и команд, знающих nginx. Traefik — для микросервисов с CRD-first подходом и активного CD. Оба нормальны, выбор больше про команду, чем про технологию. И не забывай: между ингрессом и приложением живёт ещё много слоёв (envoy/istio, service mesh, rate-limiter), и иногда их роль логичнее переложить туда, а ingress оставить тонким.

Куда копать: документация ingress-nginx и Traefik, и заметки про Gateway API на kubernetes.io. Если есть возможность поднять оба в стейджинге и прогнать k6 — ничто не заменит свои цифры.

Комментарии 0

  • Будьте первым, кто оставит комментарий.

Войдите, чтобы оставить комментарий.