Налаштування Nginx Ingress Controller (Nginx)
Уявіть: кластер готовий, поди запущені, але зовнішній трафік не доходить. Ingress-контролер встановлено, kubectl get ingress показує правило, а ADDRESS порожній. Ми бачимо таке в кожному другому проекті на bare metal. Nginx Ingress Controller — де-факто стандарт для вхідного трафіку, але його налаштування вимагає розуміння нюансів мережевої інфраструктури. Ми налаштували вже понад 50 кластерів на різних хмарних платформах та on-premise, і готові поділитися досвідом. З понад 5-річним досвідом та 100+ завершеними проектами, ми гарантуємо якість.
Як налаштувати 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 обробляє запити вдвічі швидше, ніж 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% вартості даунтайму — це до $500 на місяць для середнього проекту.
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, але й оптимізацію під ваші бізнес-завдання.
Що входить у налаштування під ключ
- Аудит поточної архітектури — оцінка кластера, схеми мережевої зв'язності, виявлення вузьких місць.
- Встановлення та кастомізація — Helm-чарт, ConfigMap під ваші завдання, вибір схеми L4-балансування.
- Автоматизація TLS — cert-manager, ClusterIssuer, Let's Encrypt / внутрішній CA.
- Моніторинг та оповіщення — Prometheus + Grafana, дашборди, алерти на 502/503.
- Документація та навчання — README, runbook по поширених збоях, доступ до наших скриптів.
- Гарантійна підтримка — 2 тижні після введення в експлуатацію: виправляємо баги, допомагаємо з інцидентами.
Скоротіть витрати на хмарні ресурси до 30% (у середньому $200–500 на місяць для типових проектів) за рахунок оптимізації термінації TLS та балансування. Отримайте консультацію інженера, щоб ваш Ingress працював стабільно та масштабувався.
Строки та як замовити
Базове встановлення з TLS та 2-3 Ingress-правилами: півдня (від 5000 грн). Production-налаштування з MetalLB, cert-manager, моніторингом, rate limiting та оптимізацією буферів: 1-2 дні (від 15000 грн). Точну вартість розрахуємо після аудиту вашого проекту. Зв'яжіться з нами — ми відповімо протягом години.
