3.6.3 · блок 3

Istio: control plane и data plane

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

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.

1. Deployment scorer-stable и scorer-canary — один Service scorer (selector общий или через DestinationRule subsets).

2. VirtualService: 10% трафика на canary.

3. Смотрим метрики latency/error rate canary в Grafana.

4. Увеличиваем 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».

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

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