Зачем это нужно
Istio — service mesh для Kubernetes. На MDP Istio часто объединяет: входной трафик (Ingress Gateway), безопасность между сервисами (mTLS), observability (метрики, traces), продвинутый routing (canary, fault injection). ML-платформа — десятки сервисов (scorer, feature-store, MLflow, Seldon): mesh даёт единые политики без правок каждого Python-приложения.
Вы не обязаны быть mesh-админом, но должны понимать sidecar, VirtualService, DestinationRule — иначе не поймёте, почему запрос «завис» или почему canary не получает трафик.
Основные идеи
Control plane (istiod). Мозг: принимает конфигурацию (CRD), распределяет на data plane, выдаёт сертификаты для mTLS, service discovery.
Data plane (Envoy sidecar). К каждому Pod (при включённом injection) добавляется контейнер istio-proxy. Весь TCP/HTTP трафик приложения идёт через Envoy — «прозрачно» для вашего кода на порту 8080.
[ ваш FastAPI :8080 ] ←→ [ Envoy sidecar ] ←→ сеть кластера
Injection. Namespace с label istio-injection=enabled — новые Pod'ы получают sidecar автоматически. Без sidecar Pod не участвует в mesh-политиках (и может не ходить с mTLS на mesh-сервисы — зависит от STRICT mode).
Основные CRD (читать, не заучивать все).
| Ресурс | Назначение |
|---|---|
| Gateway | Точка входа (Ingress Gateway Pod), порты 80/443 |
| VirtualService | Правила routing: host, match, route, weight, timeout |
| DestinationRule | Политики к Service: subsets (v1/v2), circuit breaker, TLS mode |
| PeerAuthentication | mTLS: STRICT / PERMISSIVE |
| AuthorizationPolicy | Кто кому разрешён доступ (L4/L7) |
VirtualService (фрагмент canary):
apiVersion: networking.istio.io/v1 kind: VirtualService metadata: name: scorer spec: hosts: - scorer http: - route: - destination: host: scorer subset: stable weight: 90 - destination: host: scorer subset: canary weight: 10
DestinationRule определяет subsets по labels Pod'ов (version: stable / version: canary).
Observability. Envoy отдаёт метрики (request rate, latency, 5xx) — в MDP их забирает VictoriaMetrics/Prometheus. Sidecar сам по себе не создаёт и не прокидывает trace headers между вызовами приложения: приложение должно извлечь и передать trace context (например, W3C traceparent) в исходящий HTTP/gRPC запрос. Istio затем связывает сетевые spans с этим контекстом.
Istio vs «просто Gateway API». Gateway API решает north-south routing. Istio добавляет east-west, mTLS, fine-grained traffic policy. На практике они дополняют: HTTPRoute может быть реализован Istio-контроллером.
Как это выглядит на практике
Деплой inference с canary.
Deployment
scorer-stableиscorer-canary— один Servicescorer(selector общий или через DestinationRule subsets).VirtualService: 10% трафика на canary.
Смотрим метрики latency/error rate canary в Grafana.
Увеличиваем weight до 100%, удаляем stable.
Отладка из Pod с sidecar:
kubectl exec -it scorer-xxx -c istio-proxy -- curl localhost:15000/config_dump istioctl proxy-status # если istioctl доступен kubectl logs scorer-xxx -c istio-proxy
Типичные проблемы ML-сервисов.
Большие payload (batch inference) — default timeout VirtualService слишком мал → 504.
gRPC streaming (Triton) — нужны корректные destination port и protocol detection.
Init container без sidecar — редко; основной контейнер always через proxy.
Что не трогать студенту. Установка Istio, revision tags, global mTLS STRICT — зона platform team. Вы меняете VirtualService/HTTPRoute в своём namespace через GitOps.
Что сделать после занятия
Проверьте, есть ли sidecar у Pod вашего сервиса:
kubectl get pod -o jsonpath='{.spec.containers[*].name}'.Найдите VirtualService или HTTPRoute для scorer и выпишите host + backend port.
Объясните, зачем canary через mesh лучше, чем «вручную менять replicas и надеяться на random kube-proxy».