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 моделей — строгая идентификация и авторизация между сервисами.

---

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

Решение	Прокси (Sidecar)	Control Plane	Особенности
Istio	Envoy	Istiod	Полнофункциональный, гибкий, но тяжёлый
Linkerd	Rust-based proxy	Linkerd control plane	Лёгкий, быстрый, без Envoy
Consul Connect	Envoy / native	Consul	Гибрид service discovery + mesh
Kuma	Envoy	Kuma CP	Ставка на multi-mesh и CRD-управление
Open Service Mesh (OSM)	Envoy	OSM controller	Лёгкий, SMI-совместимый, поддерживается Microsoft

---

Где особенно нужен 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"]

Это правило разрешает трафик к

только от .

---

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

При этом поды

должны иметь метки и .

---

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

Характеристика	Istio	Linkerd
Прокси	Envoy (C++)	Rust-based (lightweight)
Установка	Сложнее, больше CRD	Быстро и просто ( Копироватьlinkerd install )
mTLS	Да (по умолчанию в новых версиях)	Да (всегда по умолчанию)
Traffic splitting	Да (через VirtualService)	Да (через SMI или ServiceProfile)
Observability	Prometheus, Jaeger, Kiali	Prometheus, Grafana, Tap
Производительность	Выше нагрузка, больше latency	Минимальный overhead
Расширяемость	Высокая (плагины, WASM, WAF)	Ограничена, но простая
Production-ready	Да (широко используется)	Да (особенно для лёгких сред)

---