Service Mesh

Когда микросервисов становится много, появляются вопросы: как управлять трафиком между ними? Как обеспечить mTLS? Как делать канареечные релизы? Service mesh решает эти задачи на уровне инфраструктуры, а не кода.

Зачем нужен Service Mesh

В монолите межсервисное взаимодействие — это вызов функции. В микросервисах — это сетевой запрос с рядом инфраструктурных задач:

• Retries и timeouts — каждый сервис должен их реализовать
• Circuit breaker — защита от каскадных сбоев
• mTLS — шифрование трафика между сервисами
• Трассировка — понять, где тормозит запрос
• Канареечные релизы — направить 5% трафика на новую версию

Можно реализовать всё это в коде каждого сервиса. Но тогда:

• Дублирование логики во всех сервисах
• Разные языки = разные реализации
• Изменение политики требует редеплоя всех сервисов

Архитектура: Control Plane vs Data Plane

                    +------------------+
                    |   Control Plane  |
                    |     (Istiod)     |
                    |                  |
                    | - Service        |
                    |   discovery      |
                    | - Config mgmt    |
                    | - Certificate    |
                    |   authority      |
                    +--------+---------+
                             |
            xDS API (push configs)
                             |
         +-------------------+-------------------+
         |                   |                   |
         v                   v                   v
+--------+-------+  +--------+-------+  +--------+-------+
|   Data Plane   |  |   Data Plane   |  |   Data Plane   |
|                |  |                |  |                |
| +---+ +------+ |  | +---+ +------+ |  | +---+ +------+ |
| |App| |Envoy | |  | |App| |Envoy | |  | |App| |Envoy | |
| |   |<->Proxy| |  | |   |<->Proxy| |  | |   |<->Proxy| |
| +---+ +------+ |  | +---+ +------+ |  | +---+ +------+ |
|     Pod A      |  |     Pod B      |  |     Pod C      |
+----------------+  +----------------+  +----------------+

Ключевой момент: Istio сам не гоняет трафик. Он управляет конфигурацией Envoy-прокси через xDS API.

Envoy: sidecar и gateway

Ingress Gateway

Стоит на границе кластера. Это входная точка для внешнего трафика:

• TLS termination
• Rate limiting
• Глобальный роутинг по доменам и путям
• Аутентификация внешних запросов

Sidecar Envoy

Запускается рядом с каждым подом (через Istio injection). Перехватывает весь ingress/egress трафик конкретного сервиса:

• mTLS между сервисами (mutual TLS — обе стороны проверяют сертификаты друг друга, в отличие от обычного TLS, где только клиент проверяет сервер)
• Retries и circuit breaker
• Канареечные правила
• Сбор метрик и трейсов
• Политики доступа (pod-to-pod)

Egress Gateway

Контролирует исходящий трафик из кластера во внешние сервисы. Позволяет:

• Ограничить, куда сервисы могут ходить
• Логировать внешние вызовы
• Применять единые политики для внешнего трафика

Istio: управление mesh

Istio — control plane, который программирует Envoy-прокси:

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v1
EOF

Этот конфиг направляет пользователя "jason" на v2, остальных — на v1. Без изменения кода сервисов.

Что делает Istiod

• Service discovery: синхронизируется с Kubernetes API
• Configuration: пушит правила маршрутизации в sidecar'ы
• Certificates: выдаёт и ротирует сертификаты для mTLS

Управление трафиком

Канареечные релизы

http:
- route:
  - destination:
      host: my-service
      subset: v1
    weight: 95
  - destination:
      host: my-service
      subset: v2
    weight: 5

Circuit Breaker

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: my-service
spec:
  host: my-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        h2UpgradePolicy: UPGRADE
        http1MaxPendingRequests: 100
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 30s

Retries и Timeouts

http:
- route:
  - destination:
      host: my-service
  retries:
    attempts: 3
    perTryTimeout: 2s
    retryOn: 5xx,reset,connect-failure
  timeout: 10s

Когда внедрять

Service mesh нужен, если:

• Много микросервисов (10+) на разных языках
• Требуется mTLS между всеми сервисами
• Нужны канареечные релизы без изменения кода
• Требуется единая observability (метрики, трейсы)
• Есть compliance требования к шифрованию трафика

Service mesh избыточен, если:

• Монолит или несколько сервисов
• Команда не готова к операционной сложности
• Нет ресурсов на поддержку (sidecar добавляет latency и потребление памяти)

Альтернативы