System Design
Service Mesh
Цели урока
- Понять проблемы, которые решает Service Mesh
- Изучить sidecar pattern и архитектуру data/control plane
- Освоить traffic management: canary, circuit breaker, retries
- Понять mTLS и zero-trust security в mesh
- Сравнить Istio и Linkerd, знать когда что выбрать
Предварительные знания
- Основы Kubernetes (pods, services, deployments)
- Понимание микросервисной архитектуры
- API Gateway и паттерны коммуникации
Зачем нужен Service Mesh
**Service Mesh** - инфраструктурный слой, который управляет коммуникацией между микросервисами. Networking, security, observability - без изменения кода приложений.
Service Mesh решает вопрос: "Как сделать retry, timeout, mTLS, tracing для 500 сервисов, не добавляя код в каждый?"
Какую проблему НЕ решает Service Mesh?
Sidecar Pattern и архитектура
**Sidecar Pattern** - контейнер рядом с основным приложением в одном pod. Весь трафик проходит через sidecar.
**Sidecar Injection** - Kubernetes автоматически добавляет proxy при деплое через admission webhook.
Namespace-level injection: `kubectl label namespace default istio-injection=enabled`. Все pods в namespace получат sidecar.
Как sidecar proxy перехватывает трафик приложения?
Traffic Management
Service Mesh позволяет управлять трафиком декларативно: canary deployments, A/B testing, circuit breaker - без кода.
Canary deployment: 90% трафика на v1, 10% на v2. v2 показывает 50% error rate. Что должен сделать mesh?
mTLS (Mutual TLS)
**mTLS** - двусторонняя TLS аутентификация. И клиент, и сервер проверяют сертификаты друг друга. Zero-trust security.
**SPIFFE**: Secure Production Identity Framework. Стандарт для workload identity. Istio и Linkerd поддерживают SPIFFE ID.
Istio mTLS mode: STRICT. Сервис без sidecar пытается вызвать сервис с sidecar. Что произойдёт?
Observability в Service Mesh
Service Mesh предоставляет **observability из коробки**: distributed tracing, metrics, access logs - без изменения кода.
**Overhead**: Access logs + tracing добавляют latency (~1-5ms). Для performance-critical paths можно отключить выборочно.
Для distributed tracing в Istio что должно делать приложение?
Istio vs Linkerd: когда что выбрать
Два основных Service Mesh для Kubernetes: **Istio** (feature-rich) и **Linkerd** (simple, fast).
| Критерий | Istio | Linkerd |
|---|---|---|
| Proxy | Envoy (C++) | linkerd2-proxy (Rust) |
| Latency overhead | ~3-5ms | ~1ms |
| Memory per sidecar | ~50MB | ~10MB |
| Setup complexity | Сложный | 5 минут |
| Features | Всё из коробки | Базовые |
| Community | Большое (Google, IBM) | Меньше (Buoyant) |
| Multi-cluster | Да | Да (simpler) |
| Non-K8s support | Да (VMs) | Только Kubernetes |
**Когда НЕ нужен Service Mesh вообще:**
**Правило**: начните без mesh. Когда боль от ручного управления retry/mTLS/tracing станет нетерпимой - добавьте mesh.
Стартап, 15 микросервисов, команда 3 DevOps, нужен mTLS и observability. Что выбрать?
Ключевые принципы Service Mesh
- **Service Mesh** = networking, security, observability без изменения кода
- **Sidecar pattern**: Envoy/Linkerd proxy рядом с каждым сервисом
- **Data Plane** (proxies) + **Control Plane** (config management)
- **mTLS**: автоматическое шифрование и certificate rotation
- **Traffic management**: canary, circuit breaker, retries - декларативно
- **Istio** для enterprise, **Linkerd** для простоты. Или без mesh для <10 сервисов
Связанные темы
Service Mesh - часть cloud-native stack
- Микросервисы — Mesh для service-to-service communication
- API Gateway — Gateway для north-south, Mesh для east-west traffic
- URL Shortener Design — Применение изученных концепций в реальном дизайне