Service Mesh (Сетевая архитектура управления микросервисами)

Service Mesh — это инфраструктурный уровень управления сетевыми взаимодействиями между микросервисами. Он работает как прозрачный прокси-слой, обеспечивающий надёжную, безопасную и управляемую коммуникацию между сервисами в распределённых системах, особенно в среде Kubernetes.

В отличие от логики, встроенной в сами приложения, Service Mesh реализует критически важные функции — маршрутизацию, авторизацию, шифрование и телеметрию — полностью на уровне платформы, без необходимости менять исходный код.

Как работает Service Mesh

Ключевая идея — каждый под или сервис получает sidecar-прокси (например, Envoy), который перехватывает весь входящий и исходящий трафик. Сами приложения общаются с прокси, а уже прокси — с другими сервисами. Вся логика маршрутизации, политик и телеметрии управляется централизованно через control plane.

Архитектура состоит из:

• Data Plane — распределённые прокси (sidecars), обрабатывающие трафик;
• Control Plane — централизованный компонент, управляющий конфигурацией, безопасностью и политиками.

Возможности Service Mesh

• Обнаружение сервисов и маршрутизация (по версии, тегам, заголовкам);
• Шифрование трафика (mTLS) — автоматическое, end-to-end, по умолчанию;
• Управление доступом — через policies, RBAC, SNI и CIDR;
• Контроль над поведением сетевых вызовов — timeout, retry, circuit breaker, rate limiting;
• Наблюдаемость (observability) — трассировка (tracing), метрики, логи (интеграция с Prometheus, Grafana, Jaeger, Zipkin);
• A/B-тестирование и canary rollout — без необходимости менять код;
• Поддержка Zero Trust моделей — строгая идентификация и авторизация между сервисами.

Примеры решений

Где особенно нужен Service Mesh

• Kubernetes с большим количеством микросервисов;
• Мультиоблачные и мультикластерные среды;
• Финансовые и медицинские приложения с требованиями по трафику и безопасности;
• DevSecOps и Zero Trust архитектуры — строгая изоляция и шифрование без доверия к внутренней сети;
• CI/CD-пайплайны, где требуется независимое тестирование, деплой и управление фичами на сетевом уровне.

Почему это важно:

• Разгрузка команд разработки — нет необходимости реализовывать сетевую логику в приложениях;
• Централизованное управление политиками безопасности;
• Повышение надёжности и устойчивости микросервисов;
• Поддержка современного observability-стека без вмешательства в код.

Service Mesh — это ключевой слой для зрелых Kubernetes-платформ, где важно масштабирование, безопасность и управляемость коммуникаций. Это инструмент не про «модно», а про «обязательно», когда бизнес зависит от стабильной микросервисной архитектуры.

Вот практическое продолжение — архитектура Istio, пример настройки mTLS, CRD-манифест для трафик-сплита (canary) и сравнительная таблица Istio vs Linkerd. Всё строго, прикладно и применимо в реальных Kubernetes-кластерах.

Архитектура Istio (обобщённо)

                     ┌────────────────────────────┐
                     │        Istio Control Plane │
                     │  ┌────────┐  ┌───────────┐  │
                     │  │ Pilot  │  │ Citadel   │  │
                     │  └────────┘  └───────────┘  │
                     └────────┬────────┬──────────┘
                              │        │
 ┌──────────────┐    mTLS     ▼        ▼     mTLS   ┌──────────────┐
 │ Service A    │◄────────► Envoy ◄─► Envoy ◄──────►│ Service B    │
 └──────────────┘            Sidecar    Sidecar     └──────────────┘

• Envoy — sidecar-прокси, вставляемый в каждый под;
• Pilot — маршрутизация, правила, настройки;
• Citadel — управление сертификатами и безопасностью (mTLS);
• Galley / Telemetry / Mixer (в старых версиях) — телеметрия и политика.

Пример: включение mTLS между сервисами

1. Enable strict mTLS namespace-wide

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT

2. AuthorizationPolicy — кто с кем может говорить

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  selector:
    matchLabels:
      app: backend
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/production/sa/frontend"]

Это правило разрешает трафик к backend только от frontend.

Canary rollout через VirtualService (CRD Istio)

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: web-app
spec:
  hosts:
    - web.example.com
  http:
    - route:
        - destination:
            host: web-app
            subset: v1
          weight: 90
        - destination:
            host: web-app
            subset: v2
          weight: 10

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: web-app
spec:
  host: web-app
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

При этом поды web-app должны иметь метки version: v1 и version: v2.

Сравнение: Istio vs Linkerd