3.6.1 · блок 3

Вход в кластер: Ingress, Gateway API, API Gateway, mesh

Зачем это нужно

Pod'ы в Kubernetes имеют внутренние IP — снаружи кластера до них не достучаться. Нужен входной слой: маршрутизация HTTP/gRPC, TLS, rate limit, аутентификация. В ML-платформе через этот слой ходят запросы к inference API, к MLflow UI, к Jupyter/Notebook gateway, к мониторингу.

Путаница начинается от четырёх похожих терминов. Этот урок — карта местности. Детали Gateway API и Istio — в следующих занятиях.

Основные идеи

Service (ClusterIP) — не «вход». my-scorer:8080 доступен только внутри кластера. Service — стабильный DNS + load balance между Pod'ами. Вход — отдельный компонент.

Ingress (классический Kubernetes). Ресурс Ingress + Ingress Controller (nginx, traefik, istio ingress gateway). Правила вида: scorer.ml.company.com → Service scorer:8080. Простой L7 routing, TLS через Secret или cert-manager.

Gateway API (эволюция Ingress). Отдельный набор CRD: Gateway, HTTPRoute, GRPCRoute. Роли разделены: infra-команда ставит Gateway, продуктовая команда создаёт HTTPRoute в своём namespace. Более выразительная модель (header match, weight split, TLS termination).

API Gateway (паттерн / продукт). Не только «прокси по hostname». Функции на edge: auth (JWT, API key), quota, request transformation, WAF, иногда billing. Реализации: Kong, Ambassador, Istio Gateway + policies, облачные ALB/API Gateway.

Service mesh (Istio и др.). Другой слой: sidecar (Envoy) рядом с каждым Pod. Управляет east-west трафиком (service-to-service): mTLS, retries, circuit breaker, observability. North-south (из интернета) mesh тоже может обслуживать через Ingress Gateway, но mesh ≠ только «вход снаружи».

Сравнение одной фразой.

| Термин | Основной вопрос |

|--------|-----------------|

| Ingress | Как HTTP снаружи попадёт в Service? |

| Gateway API | Как описать маршруты современным YAML с ролями? |

| API Gateway | Кто проверит JWT и лимитирует RPS на inference? |

| Mesh | Как безопасно и наблюдаемо ходить между 50 микросервисами? |

Для ML-инженера. Вы чаще потребитель: chart содержит HTTPRoute или VirtualService, hostname и TLS уже настроены платформой. Важно читать манифесты и понимать, где ломается цепочка: DNS → Gateway → Service → Pod.

MDP типично. Istio как mesh + Gateway API или Istio Gateway для north-south; cert-manager для TLS; VictoriaMetrics/Loki собирают метрики с Envoy.

Как это выглядит на практике

Запрос inference снаружи (упрощённо):


Клиент HTTPS
    → DNS scorer.ml.mdp.ru
    → Load Balancer (metal/cloud)
    → Istio Ingress Gateway (Pod)
    → VirtualService / HTTPRoute
    → Service scorer:8080
    → Pod scorer-7d8f... (sidecar Envoy)
    → контейнер FastAPI :8080

East-west: сервис feature-store вызывает scorer — трафик тоже через sidecar, mTLS между Pod'ами без правок в Python-коде.

Что смотреть при 502/503:

1. kubectl get httproute,virtualservice -n ml-prod

2. Endpoints Service: kubectl get endpoints scorer

3. Pod ready? kubectl get pods -l app=scorer

4. Gateway listener и сертификат: cert-manager Certificate Ready?

Anti-pattern. Публиковать inference через NodePort «для простоты» в prod — нет TLS, нет централизованной политики, сложный audit.

Что сделать после занятия

[ ] Нарисуйте цепочку от браузера до Pod для одного сервиса на MDP (или учебного кластера).
[ ] Объясните разницу north-south и east-west на примере: клиент → scorer → feature-store.
[ ] Найдите в документации платформы hostname и namespace своего inference — это HTTPRoute или Ingress?

Официальные материалы

Открыть интерактивную версию