Вход в кластер: 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:

kubectl get httproute,virtualservice -n ml-prod
Endpoints Service: kubectl get endpoints scorer
Pod ready? kubectl get pods -l app=scorer
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?