Прокси и ingress-контроллеры: как настроить маршрутизацию в Kubernetes

Представьте ситуацию: ваш микросервис работает идеально, но пользователи не могут до него добраться. Трафик застревает где-то на границе кластера, либо уходит не туда, куда нужно. В мире Kubernetes система оркестрации контейнеров, которая автоматизирует развертывание, масштабирование и управление приложениями это классическая боль. Чтобы решить проблему доставки HTTP-запросов к нужным подам, мы используем два ключевых инструмента: прокси-серверы и ingress-контроллеры.

Частые заблуждения о роутинге в кластере

Многие новички путают понятия Service и Ingress. Если Service отвечает за внутреннюю связь между компонентами внутри сети Kubernetes, то Ingress управляет внешним доступом. Без правильного понимания этой разницы вы рискуете создать «дыру» в безопасности или просто потерять трафик. Прокси-сервер здесь выступает посредником, который принимает запросы от интернета и перенаправляет их внутрь кластера по заданным правилам.

Как устроена работа Ingress-контроллера

Ingress-контроллер - это не просто ресурс в YAML-файле. Это полноценное приложение (обычно набор подов), которое слушает события API-сервера Kubernetes. Когда вы создаете ресурс Ingress, контроллер читает его спецификацию и обновляет конфигурацию своего внутреннего прокси-ядра. Чаще всего этим ядром выступает высокопроизводительный прокси на базе C++ или Go.

Типичный процесс выглядит так:

1. Пользователь отправляет HTTP-запрос на публичный IP-адрес LoadBalancer.
2. Traffic попадает на NodePort или напрямую на узлы с запущенными подами Ingress-контроллера.
3. Контроллер анализирует хост и путь из заголовка запроса.
4. По правилам из ресурса Ingress определяется целевая Service.
5. Трафик пробрасывается через kube-proxy или iptables на конкретный Pod.

Сравнение популярных реализаций

На рынке есть несколько лидеров. Выбор зависит от ваших требований к производительности, экосистеме и сложности настройки. Вот основные игроки:

Практический пример конфигурации

Давайте посмотрим, как это выглядит в коде. Допустим, у нас есть два сервиса: frontend и api. Мы хотим, чтобы запросы на example.com шли во фронтенд, а на api.example.com - в бэкенд.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 80
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080

Обратите внимание на поле pathType. В современных версиях Kubernetes (1.25+) оно обязательно. Значение Prefix означает, что любой путь, начинающийся с указанного, будет направлен в этот сервис. Если бы мы использовали Exact, сработал бы только корневой путь.

Прокси vs Ingress: где проходит граница?

Вопрос часто звучит так: «Зачем нужен отдельный прокси, если есть Ingress?» Ответ кроется в уровнях абстракции. Ingress - это декларативный объект Kubernetes. Он говорит системе: «Вот правила маршрутизации». Но кто-то должен эти правила исполнять. Эту роль выполняет прокси-сервер (NGINX, Envoy, HAProxy). Ingress-контроллер объединяет две вещи: логику синхронизации с API-сервером Kubernetes и движок проксирования. Поэтому, говоря «настроить Ingress», мы фактически настраиваем поведение встроенного прокси-сервера через манифесты Kubernetes.

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

Даже опытные DevOps-инженеры иногда сталкиваются с проблемами. Вот топ-3 ловушки, которые стоит избегать:

• Конфликт правил. Если два Ingress-ресурса указывают один и тот же хост и пересекающиеся пути, приоритет отдается тому, который был создан раньше (или имеет меньший timestamp). Лучше явно разделять логику по именам сервисов.
• Забытый TLS-сертификат. Без правильной настройки tls секции браузеры будут показывать ошибку безопасности. Используйте Let's Encrypt через cert-manager для автоматического обновления.
• Неверный порт Service. Частая ошибка - указать порт Ingress, который не совпадает с портом, объявленным в объекте Service. Проверьте, что spec.service.port.number соответствует targetPort в вашем Deployment.

Когда нужен Service Mesh вместо простого Ingress?

Если вам нужна только маршрутизация по URL и балансировка нагрузки, Ingress более чем достаточно. Но если требования расширяются до межсервисной коммуникации, трассировки распределенных запросов или сложной политики управления трафиком (canary releases, A/B testing), обычный Ingress начинает буксовать. В таких случаях подключают Service Mesh, например Istio или Linkerd. Здесь Envoy становится sidecar-прокси для каждого пода, а глобальная маршрутизация управляется отдельным плоским слоем управления.

Производительность и масштабирование

При высокой нагрузке важно понимать, что узким местом может стать сам Ingress-контроллер. Поскольку он обычно работает в режиме DaemonSet или Deployment с несколькими репликами, убедитесь, что они равномерно распределяют нагрузку. Для NGINX Ingress рекомендуется использовать горизонтальное масштабирование (HPA) на основе CPU или кастомных метрик QPS. Envoy, благодаря своей архитектуре, часто показывает лучшую стабильность при пиковых нагрузках, но требует больше оперативной памяти.

Безопасность на уровне входа

Ingress - это первая линия обороны. Здесь стоит реализовать базовую защиту: ограничение размера тела запроса (proxy-body-size), таймауты чтения и записи, а также блокировку лишних HTTP-методов. Например, для REST API часто достаточно разрешить только GET, POST, PUT и DELETE. Все остальные методы можно вернуть со статусом 405 Not Allowed прямо на уровне прокси, не нагружая микросервисы.

Инструменты мониторинга

Без метрик настройка Ingress превращается в гадание. Большинство контроллеров экспортируют данные в формате Prometheus. Ключевые метрики, за которыми стоит следить:

• nginx_ingress_controller_requests - количество обработанных запросов по статусам.
• envoy_cluster_upstream_rq_time - время ответа от бэкенда (для Envoy).
• kube_pod_container_status_restarts_total - частота перезапусков подов контроллера.

FAQ