Что такое service mesh и когда он реально нужен? Какие проблемы он решает и какие создаёт?

Пример: canary routing в Istio

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-service-vs
spec:
  hosts:
    - my-service
  http:
    - match:
        - headers:
            x-canary:
              exact: "true"
      route:
        - destination:
            host: my-service
            subset: v2
    - route:
        - destination:
            host: my-service
            subset: v1
          weight: 90
        - destination:
            host: my-service
            subset: v2
          weight: 10

Service mesh: суть и назначение

Service mesh — инфраструктурный слой, который берёт на себя всё, что связано с сетевым взаимодействием между сервисами: безопасность, наблюдаемость и управление трафиком. Реализуется двумя основными паттернами:

• Sidecar proxy (Istio + Envoy, Linkerd + linkerd-proxy) — рядом с каждым подом запускается proxy-контейнер, который перехватывает весь входящий/исходящий трафик.
• eBPF-based (Cilium Service Mesh) — proxy встроен в ядро через eBPF, без sidecar-контейнеров.

Какие проблемы решает

• mTLS между сервисами. Автоматическое шифрование и аутентификация east-west трафика без изменения кода приложения. Istio выдаёт SPIFFE-сертификаты через cert-manager.
• Observability. Автоматический сбор метрик (RED: Rate, Errors, Duration), distributed tracing (Zipkin/Jaeger), service graph — без instrumentации кода.
• Traffic management. Canary deployments, A/B тесты, circuit breaker, retries, timeouts, fault injection — через CRD (VirtualService, DestinationRule в Istio).
• Authorization Policy. Zero-trust: DENY всего по умолчанию, явные ALLOW на уровне HTTP-методов и путей.

Пример: mTLS + AuthorizationPolicy

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-frontend-to-api
  namespace: production
spec:
  selector:
    matchLabels:
      app: api
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/production/sa/frontend-sa"]
      to:
        - operation:
            methods: ["GET", "POST"]
            paths: ["/api/*"]

Когда service mesh реально нужен

• 10+ микросервисов с требованием mTLS (compliance: PCI DSS, SOC 2).
• Сложная маршрутизация: canary для нескольких сервисов одновременно.
• Команды независимо деплоят сервисы — нужна единая политика безопасности без координации.
• Требования к SLA с детальным tracing и service-level метриками.

Какие проблемы создаёт

• Сложность операций: Istio имеет 15+ CRD и собственный control plane (istiod).
• Latency: sidecar добавляет 0.5–5ms на каждый запрос.
• Ресурсы: каждый Envoy sidecar — ~50 MB RAM.
• Debugging становится сложнее: трафик идёт через proxy, что скрывает реальные IP.

Подводные камни

• Istio ломает UDP. Envoy proxy перехватывает только TCP. DNS-трафик и другие UDP-протоколы идут мимо mesh.
• Init-контейнеры запускаются до sidecar. Если init-контейнер делает HTTP-запрос, он может упасть, пока Envoy не готов. Решение: holdApplicationUntilProxyStarts: true в IstioOperator.
• Конфликт с CNI. Некоторые CNI-плагины (Calico с eBPF) конфликтуют с iptables-манипуляциями Istio.
• Certificate rotation при большом кластере. При тысячах подов SPIFFE cert rotation создаёт пики нагрузки на istiod.
• Версионирование Istio. Мажорные обновления (1.17 → 1.18) нередко требуют rolling upgrade всего кластера с simple/revision переключением.
• Linkerd не поддерживает gRPC bidirectional streaming корректно в некоторых версиях — проверяйте перед выбором mesh.
• eBPF mesh требует ядро Linux 5.10+. Не все managed-кластеры гарантируют это, особенно с долго живущими node pools.

• Называть mesh заменой Kubernetes Service
• Не говорить про overhead
• Включать retries без идемпотентности

• Понимает data plane/control plane
• Называет реальные use cases
• Оценивает complexity