Service Mesh: Istio, Linkerd

Service Mesh: Istio, Linkerd

1) Що таке Service Mesh і коли він потрібен

Service Mesh - це шар мережевої площини даних/управління, що забезпечує наскрізний mTLS, маршрутизацію, відмовостійкість і спостережуваність між сервісами без переписування коду.

• Безпека за замовчуванням (zero-trust, ідентичності сервісів, політика доступу).
• Управління трафіком (Canary/Blue-Green, A/B, shadowing).
• Надійність (ретраї, таймаути, circuit breaking).
• Спостережуваність (метрики, логи, трейси).
• Операційна стандартизація (політики як код, GitOps).

• Багато мікросервісів з полілінгвальністю і вимогою mTLS.
• Потрібні просунуті сценарії маршрутизації/експериментів без зміни програми.
• Є вимоги аудиту/політик на мережевому рівні.

2) Istio vs Linkerd - коротке порівняння

3) Архітектура та моделі розгортання

3. 1 Sidecar mesh (класика)

Кожен Pod отримує проксі-сайдкар.
Плюси: зрілість, повний L7-контроль.
Мінуси: накладні витрати CPU/RAM, ускладнення деплоїв/налагодження.

3. 2 Istio Ambient Mesh

ztunnel (L4) на вузлі + waypoint proxies (L7) за потребою.
Плюси: нижче вартість і складність, поступове включення L7.
Мінуси: новіше, не всі L7-кейси доступні без waypoint.

4) Ідентичність і mTLS (zero-trust)

4. 1 SPIFFE/SPIRE та сертифікати

Кожному ворклоаду присвоюється SPIFFE ID: `spiffe://cluster. local/ns/NS/sa/SA`.
Автентифікація: взаємний TLS між сервісами.
Ротація ключів - автоматично (короткий TTL).

4. 2 Istio (PeerAuthentication + DestinationRule)

yaml apiVersion: security. istio. io/v1 kind: PeerAuthentication metadata: { name: default, namespace: payments }
spec:
mtls: { mode: STRICT }
apiVersion: networking. istio. io/v1 kind: DestinationRule metadata: { name: payments-dr, namespace: payments }
spec:
host: payments. svc. cluster. local trafficPolicy:
tls: { mode: ISTIO_MUTUAL }

4. 3 Linkerd - mTLS за замовчуванням

Вмикається після'linkerd install'+'linkerd inject'.
Кластери - власний trust-anchor, ротація автоматична.

5) Трафік-менеджмент

5. 1 Istio: VirtualService (маршрути, канарок)

yaml apiVersion: networking. istio. io/v1 kind: VirtualService metadata: { name: payments }
spec:
hosts: ["payments"]
http:
- route:
- destination: { host: payments, subset: v1 } # stable weight: 90
- destination: { host: payments, subset: v2 } # canary weight: 10 retries: { attempts: 2, perTryTimeout: 300ms }
timeout: 2s

yaml apiVersion: networking. istio. io/v1 kind: DestinationRule metadata: { name: payments }
spec:
host: payments subsets:
- name: v1 labels: { version: v1 }
- name: v2 labels: { version: v2 }
trafficPolicy:
loadBalancer: { simple: LEAST_CONN }
outlierDetection:
consecutive5xx: 5 interval: 5s baseEjectionTime: 30s maxEjectionPercent: 50

5. 2 Linkerd: ServiceProfile + TrafficSplit

yaml apiVersion: linkerd. io/v1alpha2 kind: ServiceProfile metadata:
name: payments. default. svc. cluster. local spec:
routes:
- name: POST /withdraw condition:
method: POST pathRegex: "/withdraw"
isRetryable: true timeout: 2s apiVersion: split. smi-spec. io/v1alpha2 kind: TrafficSplit metadata: { name: payments }
spec:
service: payments backends:
- service: payments-v1 weight: 90
- service: payments-v2 weight: 10

6) Ingress/Egress і API-шлюзи

Istio Gateway (ingress/egress) - управляє вхідним/вихідним трафіком, TLS termination, mTLS passthrough.
Linkerd працює з існуючими ingress-контролерами (NGINX/Contour/Traefik); egress - через NetworkPolicy/egress-gateway-патерни.
Політики egress: білі списки доменів, SNI-policy, заборона прямого інтернету.

7) Авторизація та політика

7. 1 Istio AuthorizationPolicy (RBAC/ABAC)

yaml apiVersion: security. istio. io/v1 kind: AuthorizationPolicy metadata: { name: allow-withdraw, namespace: payments }
spec:
selector: { matchLabels: { app: payments } }
action: ALLOW rules:
- from:
- source:
principals: ["spiffe://cluster. local/ns/api/sa/gateway"]
to:
- operation:
methods: ["POST"]
paths: ["/withdraw"]
when:
- key: request. auth. claims[role]
values: ["cashout"]

7. 2 Linkerd policy (server + serverauthorization)

yaml apiVersion: policy. linkerd. io/v1beta3 kind: Server metadata: { name: payments-server, namespace: payments }
spec:
podSelector: { matchLabels: { app: payments } }
port: 8080 apiVersion: policy. linkerd. io/v1beta3 kind: ServerAuthorization metadata: { name: allow-gateway, namespace: payments }
spec:
server: { name: payments-server }
client:
meshTLS:
identities: [".ns. api. serviceaccount. identity. linkerd. cluster. local"]

8) Спостережуваність і телеметрія

8. 1 Метрики

Istio Telemetry API → Prometheus: `istio_requests_total`, `istio_request_duration_milliseconds_bucket`, `istio_tcp_received_bytes_total`.
Linkerd viz: `request_total`, latency p50/p95/p99, `success_rate`.

8. 2 Трейси і логи

Прокидайте W3C Trace Context.
Istio/Envoy → OTLP в OpenTelemetry Collector; Linkerd - через sidecar-логгери/апп-SDK.

8. 3 Екземпляри (Exemplars)

Додавайте'trace _ id'до гістограм тривалості для «jump-to-trace».

9) Rate limits, WAF, кастомні фільтри

Istio: EnvoyFilter/WASM для локальних rate limits, eksternal-rate-limit service (Redis), а також WAF-логіка (Lua/WASM).
Linkerd: обмежена нативна підтримка; rate limit - на ingress/шлюзовому рівні.

10) Багатокластерність

Istio: east-west gateway, загальна PKI або trust-bundle, сервіс-дискавері через ServiceEntry, Federation.
Linkerd: 'linkerd multicluster link', gateway per cluster, service-mirror контролер.

Use-cases: актив-актив регіони, локалізація трафіку, федерований zero-trust.

11) Продуктивність і вартість

Sidecar mesh: оверхед CPU/RAM на кожен Pod, збільшена латентність (зазвичай + 1-3 ms на hop в steady-state).
Ambient (Istio): менше споживання для L4, L7 включається точково.
Linkerd: легкий проксі, як правило, менше overhead, але менше екстремальних можливостей L7.
Практика: вимірюйте p95/CPU до/після, тримайте SLO-гейти на деградацію.

12) Безпека

mTLS скрізь, короткий TTL, автоматична ротація.
Policy as Code (OPA/Gatekeeper, Kyverno) для заборон'authorizationPolicy: ALLOW all`.
Секрети - через CSI/Vault, не в маніфестах.
Egress-контроль: deny-by-default, явні allow-листи.
Окремі trust domains для оточень (prod/stage).

13) Інтеграція з релізами та SLO-гейтингом

Canary/Blue-Green реалізуються маршрутами mesh (див. приклади).
Аналіз метрик (Prometheus/SpanMetrics) в Argo Rollouts AnalysisTemplate - автостоп/відкат при burn-rate/p95/5xx.
Анотації релізів в Grafana: порівняння'version = stable'canary'.

14) Анти-патерни

Увімкнути mesh «скрізь і відразу» → шок інфраструктури.
Ігнорувати кардинальність метрик/логів від проксі → перевантаження TSDB/логсховища.
Залишити mTLS в PERMISSIVE/opaque режимі навічно.
Намагатися зробити складний WAF/бізнес-логіки всередині EnvoyFilter замість gateway/програми.
Немає політики egress - витоку в інтернет/обхід комплаєнсу.
Проксі з':15000'debug відкриті назовні.

15) Чек-лист впровадження (0-60 днів)

0-15 днів

Вибір моделі: Sidecar vs Ambient (Istio )/Linkerd за профілем навантажень.
Включити mTLS STRICT, базові політики авторизації для 1-2 критичних сервісів.
Базові маршрути (timeout/retries), дашборди RED/SLO.

16-30 днів

Canary/TrafficSplit, outlier detection/circuit breaking на гарячих шляхах.
OTEL інтеграція: трейси + Exemplars; алерти burn-rate.
Egress-gateways і білі списки доменів; deny-by-default.

31-60 днів

Багатокластерний лінк (якщо потрібен), federation trust.
Policy as Code на AuthorizationPolicy/ServerAuthorization.
Game-day: симуляція інциденту і відкату маршрутів/політик.

16) Метрики зрілості

Покриття mTLS (STRICT/auto-rotate) ≥ 95% сервісів.
Частка трафіку через канарські/прогресивні релізи ≥ 80%.
Середній overhead p95 <+ 5% від базової лінії (після оптимізації).
0 відкритих egress без дозволу, 100% сервісів з базовими AuthZ.
RCA «з графіка в трасу» ≤ 2 хвилини (p50).

17) Приклади «політики як код»

Gatekeeper (заборона PERMISSIVE в проді)

yaml apiVersion: constraints. gatekeeper. sh/v1beta1 kind: K8sIstiomTLSStrict metadata: { name: deny-permissive-prod }
spec:
match:
kinds: [{ apiGroups: ["security. istio. io"], kinds: ["PeerAuthentication"] }]
namespaces: ["prod-"]
parameters:
allowedModes: ["STRICT"]

Kyverno (обов'язкові labels для VS/DR)

yaml apiVersion: kyverno. io/v1 kind: ClusterPolicy metadata: { name: require-mesh-labels }
spec:
rules:
- name: vs-dr-labels match:
any:
- resources:
kinds: ["VirtualService","DestinationRule"]
validate:
message: "owner and service labels required"
pattern:
metadata:
labels:
owner: "?"
service: "?"

18) Експлуатаційні ради

Версіонуйте політики і маршрути (semver), промоушен через GitOps.
Спостережуваність проксі: окремі дашборди «proxy saturation» (CPU/heap, retries, 429/503).
Бюджет кардинальності: мітки «route», «code», «destination» - тільки шаблонні.
Мережеві ліміти/квоти на рівень namespace (NetworkPolicy/LimitRange).
Документація команди: runbook «як відкотити маршрути/політику/ключі mTLS».

19) Висновок

Istio і Linkerd вирішують одну задачу - стандартизувати безпеку, надійність і видимість міжсервісних комунікацій - але роблять це з різною глибиною і вартістю володіння.

Потрібні багаті L7-можливості і гнучкі політики - беріть Istio (розгляньте Ambient для зниження накладних).
Потрібні простота і малий overhead - беріть Linkerd.

Який би mesh ви не вибрали: увімкніть mTLS за замовчуванням, керуйте маршрутизацією як кодом, зв'яжіть метрики з трейсами, закрийте egress, і додайте SLO-гейтинг в релізи. Тоді мережевий шар перестане бути «чорним ящиком» і стане передбачуваним інструментом стійкості і швидкості змін.