Ingress в Kubernetes: как настроить вход трафика в кластер — инструкция для новичков

Что такое Ingress в Kubernetes

Ingress — это объект API группы networking.k8s.io/v1, который описывает правила доступа к сервисам внутри кластера снаружи. Объект появился в Kubernetes версии 1.1 как экспериментальная возможность, а стабильную форму networking.k8s.io/v1 получил в версии 1.19. По сути, Ingress — это набор правил маршрутизации по домену и пути, а не отдельный работающий процесс.

Правила Ingress сами по себе ничего не делают — их исполняет Ingress Controller: отдельный компонент вроде NGINX, Traefik или HAProxy, который читает объекты Ingress и настраивает реальный обратный проксирующий сервер. Без контроллера правила просто лежат в кластере как конфигурация без исполнителя. Именно контроллер принимает трафик на стандартных портах 80 (HTTP) и 443 (HTTPS) и решает, к какому Pod его направить.

Одним объектом Ingress можно описать от 1 до сотен правил маршрутизации по host и path одновременно. Например, вместо двух отдельных сервисов типа LoadBalancer для shop.example.ru и api.example.ru достаточно одного Ingress с двумя правилами и одного внешнего IP-адреса. Это экономит внешние адреса и упрощает управление TLS-сертификатами для всех доменов в одном месте.

Ключевые понятия для новичка:

• Ingress — правила маршрутизации (какой домен и путь куда вести)
• Ingress Controller — программа, которая эти правила выполняет
• Один контроллер обслуживает все объекты Ingress в кластере
• Домены и пути описываются в одном YAML-файле, а не в нескольких сервисах

Подробнее о том, как подготовить кластер перед установкой Ingress, читайте в статье про настройку кластера Kubernetes.

Как работает Ingress: путь запроса от клиента до Pod

Запрос от клиента идёт на стандартный порт 80 (HTTP) или 443 (HTTPS) — это точки входа, которые обрабатывает Ingress. Дальше трафик попадает на балансировщик типа LoadBalancer или на порт узла NodePort, а оттуда — на Pod с Ingress Controller. Именно контроллер читает объект Ingress и решает, куда направить запрос дальше.

Внутри Ingress Controller запрос сверяется с правилами по полям host и path. Если правило совпало, трафик уходит на нужный Service, а Service уже распределяет его между Pod с приложением. Одним объектом Ingress можно описать от 1 до сотен таких правил маршрутизации.

TLS-терминация — расшифровка HTTPS-трафика — происходит именно на уровне Ingress Controller, до того как запрос попадёт на Service и Pod. Дальше внутри кластера трафик обычно идёт уже как обычный HTTP. Сертификат для этого можно выпустить автоматически через cert-manager — он выдаёт сертификат Let’s Encrypt сроком на 90 дней и продлевает его без вашего участия.

Пример фрагмента манифеста показывает, как задаётся маршрут для конкретного домена и пути:

• поле host: shop.example.ru определяет, для какого домена действует правило;
• поле path: /api указывает, какие запросы отправлять на конкретный Service;
• аннотация nginx.ingress.kubernetes.io/rewrite-target переписывает путь перед тем, как передать запрос дальше — например, убирает префикс /api из URL;
• без такой аннотации приложение получит путь как есть, вместе с префиксом.

Если нужен готовый кластер, где Ingress Controller и TLS уже настроены, проще выбрать Kubernetes-хостинг с поддержкой Ingress и не собирать цепочку вручную.

Как установить и настроить Ingress Controller — пошагово

Ingress Controller не входит в стандартную поставку Kubernetes — его нужно установить отдельно. Самый быстрый способ развернуть NGINX Ingress Controller — через helm: весь процесс занимает 5–10 минут даже на новом кластере. Дальше настройка сводится к выпуску Ingress-ресурса и подключению TLS-сертификата.

Для теста хватает ноды на 2 vCPU и 4 ГБ RAM, для продакшена берите от 4 vCPU и 8 ГБ RAM — иначе Ingress Controller будет тормозить под нагрузкой. Если своего кластера ещё нет, сначала разберитесь с выбором мощности сервера через руководство по выбору VPS.

1. Создайте отдельный namespace командой kubectl create namespace ingress-nginx — это изолирует ресурсы контроллера от остальных приложений.
2. Подключите репозиторий Helm: helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx, затем обновите его командой helm repo update.
3. Установите контроллер в нужный namespace: helm install ingress-nginx ingress-nginx/ingress-nginx --namespace ingress-nginx.
4. Проверьте адрес балансировщика: kubectl get svc -n ingress-nginx покажет столбец EXTERNAL-IP — это внешний адрес, через который пойдёт трафик на портах 80 (HTTP) и 443 (HTTPS).
5. Создайте A-запись домена, указав на полученный EXTERNAL-IP, и подождите обновления DNS.
6. Опишите правила маршрутизации в манифесте ingress.yaml, указав ingressClassName: nginx и нужные host и path — в одном объекте можно задать от 1 до сотен таких правил.
7. Примените манифест: kubectl apply -f ingress.yaml.
8. Установите cert-manager и создайте ClusterIssuer для Let’s Encrypt — сертификат TLS выпустится автоматически и будет действовать 90 дней с последующим обновлением.
9. Проверьте результат командой curl -I https://ваш-домен — код ответа 200 и валидный сертификат подтвердят, что Ingress работает.

Сколько стоит Ingress и сколько ресурсов он требует

Сам Ingress Controller — бесплатное программное обеспечение с открытым исходным кодом, лицензия не нужна ни для NGINX, ни для Traefik, ни для HAProxy. Платить приходится только за сервер, на котором контроллер работает, и за трафик. Для теста хватает 1 виртуального процессора (vCPU) и 2 гигабайт (ГБ) оперативной памяти, для продакшена с реальной нагрузкой нужно больше ресурсов и запас по CPU на пики.

Расход памяти растёт вместе с числом правил маршрутизации. Пока в кластере десяток правил по host и path, контроллер потребляет 50–100 мегабайт (МБ) RAM. Когда правил становится несколько сотен, конфигурация NGINX или Traefik разрастается, и потребление памяти может вырасти в 3–5 раз — это стоит учитывать при выборе тарифа сервера заранее, а не после падения пода из-за нехватки RAM.

Ниже — ориентировочное потребление ресурсов трёх популярных контроллеров при небольшой нагрузке (до 50 правил).

Стоимость VPS под ноду с контроллером зависит от масштаба задачи:

• Тестовый стенд: 1 vCPU и 2 ГБ RAM — от 290 ₽/мес, подходит для проверки правил и TLS-сертификатов перед запуском.
• Продакшен под средний трафик: 4 vCPU и 8 ГБ RAM — от 990 ₽/мес, с запасом для роста числа правил и всплесков запросов.
• При сотнях правил маршрутизации закладывайте на 1–2 ГБ RAM больше расчётного минимума, чтобы контроллер не упирался в лимит при перезагрузке конфигурации.

Если сомневаетесь, какой тариф VPS выбрать под конкретную нагрузку, посмотрите ответы на частые вопросы о VPS — там разобраны похожие сценарии по CPU и RAM.

Типичные ошибки при настройке Ingress

Ingress собирает вместе контроллер, DNS, TLS-сертификаты и правила маршрутизации, и ошибка в любом из них даёт похожие симптомы: сайт не открывается или показывает чужую страницу. Чаще всего встречаются ответ 404 default backend, пропущенный ingressClassName, необновлённый DNS, невыпущенный TLS-сертификат и неверный порт Service.

404 default backend

Так контроллер сообщает, что ни одно правило Ingress не подошло под запрошенный host или path. Проверьте домен на опечатки, наличие завершающего слэша в пути и то, что правило ссылается на существующий Service.

Контроллер игнорирует Ingress: не указан ingressClassName

Если в манифесте нет поля ingressClassName, а в кластере работает несколько контроллеров, Kubernetes не знает, какому из них передать правило: оно существует, но трафик по нему не идёт. Укажите ingressClassName: nginx в спецификации Ingress и проверьте вывод kubectl get ingress — колонка CLASS не должна быть пустой.

DNS не обновился

A-запись ещё не разошлась по резолверам, а TTL записи может достигать 24 часов. Исправлять здесь нечего — нужно подождать или заранее снизить TTL.

TLS-сертификат не выпущен

cert-manager не может обратиться к ClusterIssuer из-за опечатки в его имени или неверного email для Let’s Encrypt. Проверьте имя ClusterIssuer и указанный email.

Ingress ссылается на несуществующий порт Service

Правило направляет трафик на порт, которого у Service нет. Проверьте соответствие port.number в правиле и портов Service.

Конфликт правил по одному host

Если несколько Ingress-объектов задают правила для одного host, контроллер применяет только одно из них. Чтобы этого избежать, не дублируйте один host в разных объектах Ingress.

В первую очередь проверьте колонку CLASS в kubectl get ingress и соответствие host, path и портов существующему Service. Затем переходите к DNS и сертификату.

Ingress или альтернативы: Gateway API, LoadBalancer Service, внешний прокси

Ingress работает только с HTTP и HTTPS на портах 80 и 443. Gateway API — это набор ресурсов Gateway, HTTPRoute, TCPRoute и UDPRoute. Он получил статус GA (General Availability, стабильная версия) в Kubernetes 1.29 и умеет маршрутизировать TCP, UDP и gRPC. Маршруты для TCP и UDP пока находятся в экспериментальном канале. Роли в Gateway API разделены: администратор управляет шлюзом, а разработчики описывают свои маршруты. Новый кластер версии 1.29 и выше лучше сразу строить на Gateway API, а рабочий Ingress переносить без спешки.

Service типа LoadBalancer получает отдельный внешний IP и отдельный облачный балансировщик. Для 1–2 сервисов это проще, чем ставить Ingress Controller. С ростом числа сервисов растёт и счёт: 10 сервисов — это 10 балансировщиков. Допустим, один стоит около 1 000 ₽ в месяц. Тогда за 10 вы заплатите около 10 000 ₽, а Ingress Controller обходится одним балансировщиком.

Внешний reverse-proxy (обратный прокси) ставят перед кластером ради CDN (Content Delivery Network, сеть доставки контента), кэша и защиты от DDoS. Это может быть Cloudflare или NGINX на отдельном сервере. Каждое новое звено удлиняет цепочку, и ошибка в любом из них ломает запрос. Чаще всего встречается ошибка 522 Connection timed out: прокси не дождался ответа от кластера. Подробный разбор причин — в статье как исправить ошибку 522.

Если появилась ошибка 522, проверьте цепочку по порядку:

• команда kubectl get svc -n ingress-nginx показывает EXTERNAL-IP, а не <pending>;
• A-запись DNS указывает на текущий IP балансировщика;
• порты 80 и 443 открыты для диапазонов IP прокси;
• при режиме SSL «Full (strict)» на Ingress установлен действующий сертификат, например от cert-manager.

Когда Ingress не подходит и чем его заменить

Ingress работает только с протоколами HTTP и HTTPS: он читает заголовок Host и путь запроса, чтобы направить трафик нужному сервису. Если вам нужен TCP- или UDP-трафик — например, игровой сервер на порту 25565 или база данных на порту 5432 — Ingress эту задачу не решит. Здесь подойдёт LoadBalancer Service, который пробрасывает произвольный порт напрямую на Pod, либо отдельный прокси уровня L4.

Ingress избыточен и для простого случая: один сервис без доменных правил и без нескольких путей. Развернуть объект Ingress с настройкой TLS через cert-manager и ждать 90 дней до продления сертификата ради единственного приложения — лишняя сложность. Проще открыть сервис как LoadBalancer напрямую или настроить внешний прокси перед кластером.

Для тестового кластера на 1 ноде Ingress Controller тоже не нужен. Минимальная нода с 2 vCPU и 4 ГБ RAM и так работает под нагрузкой разработки, а лишний Pod контроллера только съедает ресурсы. Проверить приложение локально проще через kubectl port-forward или через тип NodePort, который открывает сервис на порту ноды без установки контроллера.

Итого замена Ingress зависит от задачи:

• TCP/UDP-трафик — LoadBalancer Service или внешний прокси
• один сервис без маршрутизации по host и path — прямой LoadBalancer
• локальные тесты — kubectl port-forward
• кластер на 1 ноде — NodePort

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