Что такое service mesh и зачем он нужен

Service mesh — это слой инфраструктуры для микросервисов, который берёт на себя межсервисную связь: безопасная коммуникация (mTLS), управление трафиком (routing, retries, timeouts, circuit breakers), наблюдаемость (metrics/traces/logs) и политики (authz, rate-limit). Mesh декомпозирует эти кросс-функциональные задачи из кода приложений в платформенный слой: для разработчиков — стандартные HTTP/gRPC вызовы, для операторов — централизованное управление поведением сети.

Основные компоненты и модели

• Data plane — sidecar-прокси (Envoy в Istio, lightweight proxy в Linkerd) запускается рядом с каждым контейнером и интерцептит входящий/исходящий трафик.

• Control plane — централизованный компонент, который управляет конфигурацией proxy, обеспечивает CA/сертификаты, принимает политики и распределяет конфиг во data plane.

• Sidecar injection — автоматическое (mutating webhook) или ручное добавление sidecar в Pod манифесты. Некоторые поставщики предлагают sidecarless/VM integration.

Ключевые возможности при проектировании

• mTLS и Identity: mesh выдаёт сервисной идентичности сертификаты и управляет ротацией; проектируйте сервис-identity на уровне ServiceAccount.

• Traffic management: маршрутирование по версиям (canary, A/B), weighted routing, header/path-based routing, mirroring. Используется для безопасных релизов.

• Resilience: retries, timeouts, circuit breakers, outlier detection — конфигурируемые политики для каждого маршрута.

• Observability: встроенные метрики (request rate, latency, success rate), distributed tracing (automated headers), access logs. Планируйте интеграцию с Prometheus/Grafana/Jaeger.

• Policy & Authorization: RBAC-like политика на уровне сервиса (who→what), JWT validation и rate-limiting через Envoy filters / policy engines.

• Multi-cluster / multi-network: mesh поддерживает несколько топологий: federation, east-west gateway, or mesh expansion; учитывайте маршруты, trust anchors и сетевые туннели.

Практические архитектурные решения

• Начать постепенно: включите mesh для non-critical namespaces; сначала — observability + mTLS (mutual TLS) в permissive режиме, затем enforce.

• Separation of concerns: держите control plane HA (multi-replica), RBAC для админов mesh; разграничьте политики платформы и политики приложений.

• Resource planning: sidecar добавляет CPU/RAM и сетевую задержку; выделяйте node-pools с учётом overhead; отключайте sidecar для лёгких/cron задач.

• Integration CI/CD: храните маршруты и virtualservices в Git (GitOps), затем применяйте автоматические promotion workflows (canary + analysis).

• Service identity mapping: используйте Kubernetes ServiceAccounts как источники идентичности; привяжите политики к SA/namespace.

Выбор Istio vs Linkerd — краткие заметки

• Istio: feature-rich (Envoy ecosystem), мощная телеметрия, extensibility (Envoy filters), гибкие политики, хороший multi-cluster набор, но более сложен и ресурсозатратен.

• Linkerd: lightweight, проще в установке и эксплуатации, меньше накладных расходов и latency, но функционально более ограничен (меньше extensibility).

Безопасность, управление и операционная зрелость

• mTLS rollout: start permissive → audit connections → enforce. Обеспечьте секреты и CA HA.

• Policy lifecycle: тестируйте правила в staging, используйте canary routes для политики (трафик тестируется на subset).

• Observability & SLOs: записывайте p50/p95/p99 и error budgets, настраивайте alerting на degradation после включения новых правил.

• Upgrades & compatibility: поддерживайте CI для control plane upgrades; тестируйте breaking changes в sidecar behavior.

Multi-cluster и hybrid сценарии

• Выбирайте модель: single control plane за несколько кластеров или per-cluster control plane с federation — trade-off между простотой и управляемостью. Для latency-sensitive active-active используйте local control planes + global traffic orchestration.

Best practices при внедрении

• Включайте mesh постепенно; начинайте с read-only функций (telemetry).

• Обязательные readiness/liveness, resource limits, и PDB для контроля при деплоях mesh.

• Документируйте политики доверия, runbooks и процедуру отката (как быстро переключить трафик в случае проблем).

• Автоматизируйте тесты (integration + chaos) для проверок сетевых политик, retries и timeouts.

Операционные ловушки и оптимизация

• Измеряйте overhead: latency, CPU/RAM на sidecar; применяйте tap/skip для высоко-чувствительных компонентов.

• Используйте telemetry sampling и recording rules чтобы не перегружать TSDB.

• Учитывайте сторонние зависимости (legacy services, DB): интегрируйте через egress gateways и адаптеры.

Внедрение service mesh — это платформа-уровневое изменение: при проектировании учитывайте не только функциональность (routing, security), но и операционную нагрузку, тестирование и интеграцию с процессами разработки и релизов.