Service Mesh: Istio vs Linkerd в production

Компания «МикроПлат» — платёжная система, 60 микросервисов в Kubernetes. Проблемы:

• Безопасность: трафик между сервисами — plain HTTP. Компрометация одного pod = перехват всего трафика
• Observability: нет distributed tracing между сервисами, impossible to debug «500 Internal Server Error»
• Reliability: нет retry, circuit breaker, timeout на уровне сети. Каждый сервис реализует свою логику
• Traffic management: canary деплой — руками через deployment replicas

Service Mesh — инфраструктурный слой, который добавляет mTLS, observability и traffic management без изменения кода приложений. Sidecar-прокси (Envoy/linkerd2-proxy) перехватывает весь трафик pod-а.

# Установка Linkerd
curl -fsL https://run.linkerd.io/install | sh
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -

# Проверка
linkerd check
# ✔ control plane is healthy
# ✔ data plane is healthy

# Включение mesh для namespace
kubectl annotate namespace production linkerd.io/inject=enabled
# Перезапуск pods для инжекции sidecar
kubectl rollout restart deployment -n production

# Проверка mesh
linkerd stat deployment -n production
# NAME              MESHED  SUCCESS   RPS  LATENCY_P50  LATENCY_P99
# orders-service    3/3     99.8%    150   2ms          15ms
# payments-service  3/3     100%      80   5ms          25ms

Linkerd Dashboard — мгновенная observability без настройки:

# Запуск dashboard
linkerd viz install | kubectl apply -f -
linkerd viz dashboard

# Service-to-service трафик, success rate, latency — всё видно
# + top (live traffic), tap (отдельные запросы), routes

# Установка Istio
curl -L https://istio.io/downloadIstio | sh -
istioctl install --set profile=default

# Включение injection
kubectl label namespace production istio-injection=enabled
kubectl rollout restart deployment -n production

# Traffic splitting: 90% → v1, 10% → v2 (canary)
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: orders-service
spec:
  hosts:
  - orders-service
  http:
  - route:
    - destination:
        host: orders-service
        subset: v1
      weight: 90
    - destination:
        host: orders-service
        subset: v2
      weight: 10
    retries:
      attempts: 3
      retryOn: "5xx,connect-failure"
    timeout: 10s

# Circuit breaker
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: orders-service
spec:
  host: orders-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        h2UpgradePolicy: DEFAULT
        http1MaxPendingRequests: 100
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 60s
      maxEjectionPercent: 50

Ambient Mode — революция в service mesh: mTLS и L4 policy без sidecar-контейнеров. L7 обработка — через waypoint proxy (один на namespace).

# Установка Istio в ambient mode
istioctl install --set profile=ambient

# Включение ambient для namespace (без рестарта pods!)
kubectl label namespace production istio.io/dataplane-mode=ambient

# mTLS работает мгновенно — без sidecar, без restart
# Overhead: ~0 (ztunnel — DaemonSet, не per-pod)

# Для L7 policy (traffic splitting, retry, etc.):
# Создать waypoint proxy
istioctl waypoint apply -n production --name orders-waypoint
kubectl label service orders-service istio.io/use-waypoint=orders-waypoint

Преимущества ambient vs sidecar:

• Нет per-pod overhead: sidecar = +20-50 МБ на pod. При 200 pod-ах = 4-10 ГБ RAM. Ambient = 0
• Нет рестарта pod: включение mesh мгновенное, без downtime
• Проще отладка: нет sidecar = tcpdump видит реальный трафик

Выбор: Linkerd для 80% задач (mTLS, observability, basic retry) + Istio Ambient для namespace-ов с canary deploy.

Linkerd — если нужен лёгкий mesh (mTLS + observability) с минимальным overhead. Istio — если нужен продвинутый traffic management, canary, fault injection, или ambient mode без sidecar.