Как провести трафик к ингресу внутри кластера

Отличный, фундаментальный вопрос, который затрагивает ключевые аспекты сетевой модели Kubernetes и сервис-меши (если он используется). Как Senior DevOps Engineer с большим опытом, я разбиваю эту задачу на несколько сценариев, так как единого ответа нет — всё зависит от архитектуры, требований и инструментов.

Внутри кластера Kubernetes трафик к Ingress-контроллеру (это важно: Ingress — это набор правил, а Ingress Controller — его реализация, например, Nginx, Traefik, HAProxy) направляется через Сервис Kubernetes. Основной механизм — это Kubernetes Service типа ClusterIP (по умолчанию) или NodePort.

Базовый сценарий: Kubernetes Service (ClusterIP/NodePort)

Это стандартный и наиболее распространённый подход.

1. Развёртывание Ingress Controller: Вы разворачиваете поды с самим контроллером (например, ingress-nginx).
2. Создание Сервиса: Для этих подов создаётся Service. Чаще всего это Service типа ClusterIP. Этот сервис получает стабильный DNS-имя внутри кластера (например, nginx-ingress-controller.ingress-nginx.svc.cluster.local) и виртуальный IP-адрес (ClusterIP).
3. Маршрутизация внутреннего трафика: Любое приложение (под) внутри кластера, которому нужно обратиться к внешнему API через ингресс, просто выполняет HTTP-запрос на этот DNS-имя или ClusterIP сервиса. kube-proxy на каждой ноде обеспечивает маршрутизацию этого запроса к одному из подов Ingress Controller.

Пример манифеста сервиса для Nginx Ingress:

apiVersion: v1
kind: Service
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
spec:
  type: ClusterIP # <-- Ключевой момент
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  - port: 443
    targetPort: 443
    protocol: TCP
    name: https
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/component: controller

Как этим пользоваться внутри пода:

# Простой curl из любого пода в кластере
curl http://nginx-ingress-controller.ingress-nginx.svc.cluster.local
# Или используя пространство имён по умолчанию в том же namespace
curl http://nginx-ingress-controller

Продвинутые сценарии и оптимизации

В production-средах базового сценария часто недостаточно.

1. Использование Service Mesh (Istio, Linkerd)

Это самый мощный и комплексный подход. Service Mesh внедряет sidecar-прокси (например, Envoy) в каждый под, беря на себя всю сетевую коммуникацию.

• Трафик к ингрессу становится просто ещё одним внутренним вызовом сервиса.
• Преимущества: Сквозное шифрование (mTLS), детальная наблюдательность (трейсы, метрики), сложное управление трафиком (canary, mirroring, retries, timeout) для запросов к ингрессу и через него.
• В Istio вы настраиваете Gateway (аналог Ingress Controller) и VirtualService (аналог Ingress). Обращение к Gateway изнутри кластера будет происходить через его сервис, но весь трафик будет управляться и наблюдаться mesh'ем.

2. Internal Ingress / Шлюз для внутреннего трафика

Часто вводится разделение на внешний (public) и внутренний (private) ингресс-контроллеры.

• External Ingress: Обслуживает трафик из интернета, находится в публичной сети, часто с ограниченным набором правил (белый список IP и т.д.).
• Internal Ingress: Развёрнут внутри кластера, имеет сервис типа ClusterIP, доступен только изнутри. На него выносят правила для внутренних API, инструментов мониторинга (Prometheus, Grafana), административных интерфейсов. Это повышает безопасность.

3. Использование Headless Service для прямой маршрутизации

Если критически важна минимальная задержка и нужно избежать лишнего хопа через kube-proxy (режим iptables или ipvs), можно использовать Headless Service (.spec.clusterIP: None). В этом случае DNS-запрос вернёт все IP-адреса подов ингресс-контроллера, и клиентское приложение или его sidecar-прокси смогут балансировать трафик напрямую на поды, используя, например, round-robin DNS.

apiVersion: v1
kind: Service
metadata:
  name: nginx-ingress-headless
spec:
  clusterIP: None # <-- Headless Service
  selector:
    app: nginx-ingress
  ports:
  - port: 80

Критические аспекты, которые я всегда учитываю:

• Вопрос "Зачем?": Прежде всего, нужно понять, зачем приложению внутри кластера обращаться к другому приложению через Ingress, а не напрямую через сервис? Частые причины:

    *   Единая точка аутентификации/авторизации (OAuth-прокси на ингрессе).
    *   Глобальные правила ограничения скорости (rate limiting).
    *   Централизованное логирование и мониторинг входящего трафика.
    *   Приложение является BFF (Backend For Frontend) и должно обращаться к внешним API.

• Производительность: Каждый дополнительный хоп (особенно через пользовательский балансировщик) добавляет задержку. В высоконагруженных системах может потребоваться оптимизация, вплоть до рассмотрения Service Mesh или Headless Service с умным клиентским балансировщиком.
• Безопасность: Трафик внутри кластера по умолчанию не шифруется. Если это требование, обязательно использовать Service Mesh с mTLS или, как минимум, TLS между приложением и ингресс-контроллером (хотя сертификаты управляются сложнее).
• Отказоустойчивость: Сервис Ingress Controller должен быть развёрнут с достаточным количеством реплик и anti-affinity правилами, чтобы поды были распределены по разным нодам.

Мой стандартный выбор для большинства проектов: Начинаю с простого Service типа ClusterIP. По мере роста требований к безопасности и управлению трафиком внедряю Service Mesh (Istio), который естественным образом решает вопросы внутренней маршрутизации к шлюзам, безопасности и наблюдаемости. Разделение на internal/external ingress внедряю практически всегда в production-средах для изоляции критического административного трафика.