Реалізація Service Mesh (Istio/Linkerd) для мікросервісів
Service Mesh — інфраструктурний шар для управління міжсервісним трафіком у Kubernetes. Замість того щоб кожен мікросервіс самостійно реалізовував retry, timeout, mTLS та трейсинг, ці функції виносяться в sidecar-прокси, прозорий для коду сервісу.
Що дає Service Mesh
Traffic Management:
- Canary deployment (5% трафіку → нова версія)
- A/B тестування по заголовках
- Circuit breaker на рівні інфраструктури
- Retry та timeout без змін коду
Observability:
- Автоматичний трейсинг всіх запросів між сервісами
- Метрики: latency, error rate, throughput для кожної пари сервісів
- Граф залежностей сервісів (Service Graph)
Security:
- mTLS між усіма сервісами без змін коду
- Ротація сертифікатів
- Authorization Policies
Istio vs Linkerd
| Критерій | Istio | Linkerd |
|---|---|---|
| Прокси | Envoy (тяжкий, потужний) | Linkerd2-proxy (легкий, Rust) |
| RAM на sidecar | 300–500 МБ | 10–30 МБ |
| Складність | Висока | Помірна |
| Можливості | Повний набір | Основні функції |
| Крива навчання | Крута | Більш пологая |
Linkerd — для команд, яким потрібні mTLS, observability та базове управління трафіком без вивчення сотень Istio CRD.
Установка Linkerd
# Установка CLI
curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/install | sh
# Перевірка кластера
linkerd check --pre
# Установка control plane
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -
# Перевірка
linkerd check
Ін'єкція sidecar (аннотація namespace):
apiVersion: v1
kind: Namespace
metadata:
name: production
annotations:
linkerd.io/inject: enabled
Після цього всі поди у namespace автоматично отримують linkerd-proxy контейнер.
Управління трафіком Istio
Canary Deployment — поступовий виккат нової версії:
Використовувати VirtualService та DestinationRule для розподілу трафіку, маршрутизації по заголовках та поступового зсуву трафіку.
Circuit Breaker через DestinationRule:
Налаштувати пороги послідовних помилок, час видалення та пули з'єднань.
mTLS
У Istio, включити mTLS на рівні namespace або глобально:
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: production
spec:
mtls:
mode: STRICT # тільки mTLS, plaintext заборонено
Authorization Policy — хто може вивикатись кого:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: order-service-policy
namespace: production
spec:
selector:
matchLabels:
app: order-service
rules:
- from:
- source:
principals: ["cluster.local/ns/production/sa/api-gateway"]
to:
- operation:
methods: ["GET", "POST"]
Observability через Kiali
Kiali — UI для Istio, показує Service Graph:
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/addons/kiali.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/addons/jaeger.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/addons/prometheus.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/addons/grafana.yaml
istioctl dashboard kiali
Тимчасовість реалізації
- Установка Linkerd + базова observability — 3–5 днів
- Установка Istio + canary routing + mTLS — 1–2 тижні
- Authorization policies + повна observability stack — ще 1 тиждень