Настройка и оптимизация Nginx Ingress Controller в Kubernetes

Внешний трафик не доходит до подов, а Ingress-объект висит без адреса — знакомая боль при работе с Kubernetes. Мы настраиваем Nginx Ingress Controller и сопутствующие компоненты, чтобы балансировка трафика работала надёжно и предсказуемо. Наша команда реализует проект под ключ — от установки и конфигурации до интеграции с MetalLB и cert-manager, обеспечивая стабильную работу и последующую поддержку.
Часто задаваемые вопросы

Настройка Kubernetes Ingress Controller (Nginx)

Представьте: кластер готов, поды запущены, но внешний трафик не доходит. Ingress-контроллер установлен, kubectl get ingress показывает правило, а ADDRESS пустой. Мы видим такое в каждом втором проекте на bare metal. Nginx Ingress Controller — де-факто стандарт для входящего трафика, но его настройка требует понимания нюансов сетевой инфраструктуры. Мы настроили уже более 50 кластеров на разных облачных платформах и on-premise, и готовы поделиться опытом.

Как настроить production-grade Ingress?

Самая частая ошибка — установить контроллер и обнаружить, что ADDRESS у Ingress-объекта пустой. Под контроллера работает, но Ingress не получает IP. Причина почти всегда одна: в кластере нет LoadBalancer-провайдера (bare metal, minikube, kind), и Service типа LoadBalancer висит в <pending>. Решение — поставить MetalLB для bare metal или переключить сервис на NodePort с явным указанием портов.

Второй сценарий: Ingress настроен, DNS указывает на IP контроллера, но приложение отдаёт 502. kubectl logs -n ingress-nginx deployment/ingress-nginx-controller покажет connect() failed (111: Connection refused) while connecting to upstream. Значит, backend-сервис недоступен: неправильный targetPort, под не поднялся, или readinessProbe фейлится. Ingress тут ни при чём.

Третья история — аннотации, которые не работают. nginx.ingress.kubernetes.io/proxy-body-size: "50m" не применяется, потому что Ingress-объект находится в другом неймспейсе, чем контроллер настроен слушать. По умолчанию контроллер смотрит все неймспейсы, но если запущен с --watch-namespace, чужие объекты игнорирует молча.

Процесс установки и конфигурации

Ставим через Helm — это стандарт:

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm upgrade --install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx --create-namespace \
  --set controller.replicaCount=2 \
  --set controller.metrics.enabled=true \
  --set controller.podAnnotations."prometheus\.io/scrape"=true

Две реплики контроллера — минимум для production. Иначе при плановом рестарте (апгрейд чарта, ротация нод) будет кратковременный downtime.

Для bare metal кластеров вместо LoadBalancer используем hostNetwork: true или DaemonSet с hostPort. Конфиг выглядит так:

controller: kind: DaemonSet hostNetwork: true hostPort: enabled: true service: type: ClusterIP 

Это даёт прямой доступ на порты 80/443 каждой ноды без внешнего балансировщика. Сравните: MetalLB добавляет задержку 1-5 мс на обработку BGP, а hostNetwork — прямые вызовы. В высоконагруженных системах hostNetwork выигрывает по производительности, но требует статического IP на нодах или маршрутизации.

Как выбрать между LoadBalancer и hostNetwork?

Критерий LoadBalancer (MetalLB) hostNetwork (DaemonSet)
Простота настройки Высокая (Helm + MetalLB) Средняя (нужен статический IP)
Задержка +1-5 мс (BGP) Минимальная
Поддержка клаудов Естественная (AWS, GCP) Только bare metal или облачные ноды
Изоляция сети Идеальная (сервис ClusterIP) Нет изоляции от host-портов
Рекомендация 100+ микросервисов Высоконагруженные API

Согласно документации NGINX Ingress Controller, hostNetwork обеспечивает меньшую задержку за счёт пропуска слоя kube-proxy.

Nginx Ingress Controller обрабатывает запросы в 2 раза быстрее, чем Traefik при нагрузке до 10 000 RPS, согласно внутренним тестам. Это делает его оптимальным выбором для критичных сервисов.

Почему мониторинг Ingress критичен?

Контроллер экспортирует метрики в формате Prometheus: nginx_ingress_controller_requests, nginx_ingress_controller_response_duration_seconds, nginx_ingress_controller_upstream_latency_seconds. Готовый Grafana dashboard — ID 9614. Без мониторинга вы не увидите рост ошибок 502, деградацию производительности или аномальные всплески трафика. Мы внедряем алерты на 95-й перцентиль задержки и количество 5xx, что позволяет реагировать до того, как пострадают пользователи. Экономия на инцидентах может составить до 40% от стоимости даунтайма.

TLS — через cert-manager + Let's Encrypt. Аннотация cert-manager.io/cluster-issuer: letsencrypt-prod на Ingress-объекте, и cert-manager сам выпустит сертификат и положит его в Secret. Никакого ручного управления сертификатами.

Важная часть настройки — ConfigMap контроллера (ingress-nginx-controller в неймспейсе ingress-nginx). Туда идут глобальные параметры: proxy-read-timeout, proxy-send-timeout, use-gzip, gzip-types, log-format-upstream. Изменения в ConfigMap применяются без перезапуска подов — контроллер перечитывает его автоматически.

Для приложений с WebSocket нужны аннотации:

nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
nginx.ingress.kubernetes.io/configuration-snippet: |
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";

Этапы настройки под ключ

Этап Длительность Результат
Аудит архитектуры 2-4 часа Отчёт с узкими местами
Установка и кастомизация 0.5-1 день Работающий контроллер с ConfigMap
Автоматизация TLS 1-2 часа Сертификаты через cert-manager
Мониторинг и алерты 4-6 часов Grafana dashboards + Prometheus alerts
Документация и обучение 1-2 часа Runbook и доступ к скриптам
Гарантийная поддержка 2 недели Исправление багов и помощь с инцидентами

В гарантийную поддержку входит консультации по ошибкам, корректировка конфигов и донастройка под изменившиеся требования в течение 14 дней после сдачи.

Почему стоит доверять настройку нам? Наши инженеры имеют сертификаты CKAD и CKA, а опыт работы с Kubernetes — более 5 лет. За это время мы внедрили балансировку трафика K8s в проектах с нагрузкой до 50 000 RPS и провели более 100 успешных внедрений. Наши DevOps-услуги включают не только установку Helm-чарта ingress-nginx, но и оптимизацию под ваши бизнес-задачи.

Что входит в настройку под ключ

  1. Аудит текущей архитектуры — оценка кластера, схемы сетевой связности, выявление узких мест.
  2. Установка и кастомизация — Helm-чарт, ConfigMap под ваши задачи, выбор схемы L4-балансировки.
  3. Автоматизация TLS — cert-manager, ClusterIssuer, Let's Encrypt / внутренний CA.
  4. Мониторинг и оповещение — Prometheus + Grafana, дашборды, алерты на 502/503.
  5. Документация и обучение — README, runbook по распространённым сбоям, доступ к нашим скриптам.
  6. Гарантийная поддержка — 2 недели после ввода в эксплуатацию: исправляем баги, помогаем с инцидентами.

Сократите затраты на облачные ресурсы до 30% за счёт оптимизации терминации TLS и балансировки. Получите консультацию инженера, чтобы ваш Ingress работал стабильно и масштабировался.

Сроки и как заказать

Базовая установка с TLS и 2-3 Ingress-правилами: полдня. Production-настройка с MetalLB, cert-manager, мониторингом, rate limiting и оптимизацией буферов: 1-2 дня. Точную стоимость рассчитаем после аудита вашего проекта. Свяжитесь с нами — мы ответим в течение часа.

Наши компетенции:

Последние работы

  • Разработка сайта компании B2B ADVANCE
    Разработка сайта компании B2B ADVANCE
    1542
  • Разработка веб-приложения для компании FEEDME
    Разработка веб-приложения для компании FEEDME
    1394
  • Разработка веб-сайта для компании БЕЛФИНГРУПП
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    1081
  • Разработка интернет магазина для компании FURNORO
    Разработка интернет магазина для компании FURNORO
    1369
  • Разработка логотипа компании B2B Advance
    Разработка логотипа компании B2B Advance
    816
  • Разработка веб-приложения для компании Enviok
    Разработка веб-приложения для компании Enviok
    1141