Какие ingress контроллеры использовали в Kubernetes
Что проверяют
Это вопрос об опыте, а не о списке из документации: интервьюер хочет услышать, что вы сами ставили, как настраивали и на что наступали. Следом почти всегда спрашивают, чем Ingress отличается от Service типа LoadBalancer и знаете ли вы про Gateway API.
Как отвечать
Начните с разделения: ресурс Ingress это только правила маршрутизации, без контроллера он ничего не делает. Контроллер выбирается полем ingressClassName, аннотация kubernetes.io/ingress.class устарела.
Дальше опыт по конкретным контроллерам:
- ingress-nginx: самый распространённый, настраивается аннотациями вроде
nginx.ingress.kubernetes.io/proxy-body-size. Сообщество объявило о прекращении его поддержки: с весны 2026 года новых релизов и исправлений безопасности нет, кластеры с ним мигрируют; - NGINX Ingress Controller от F5: отдельный проект с другими аннотациями, их часто путают;
- Traefik: удобен автообнаружением и своим CRD
IngressRoute, идёт из коробки в k3s; - HAProxy Ingress, Contour, Envoy Gateway: когда нужна производительность или Envoy под капотом;
- облачные: AWS Load Balancer Controller, GKE Ingress и аналоги у других провайдеров.
Покажите эксплуатацию: установка через Helm, TLS через cert-manager с бесплатными сертификатами по ACME, метрики контроллера в Prometheus, реальный IP клиента через externalTrafficPolicy: Local или PROXY protocol, таймауты для WebSocket и gRPC. Хорошо закончить Gateway API: Gateway и HTTPRoute разделяют зоны ответственности платформы и команд и не завязаны на аннотации одного вендора.
Если работали только с одним контроллером, так и скажите и добавьте, что знаете про альтернативы.
Где спотыкаются
Путают ресурс Ingress и контроллер или считают, что Ingress сам создаёт балансировщик.
Не отличают ingress-nginx от контроллера F5 и переносят аннотации одного в другой.
Перечисляют всё подряд без деталей. Одна история про ошибку 413 из-за лимита тела запроса или про потерянный IP клиента убеждает больше, чем пять названий.