Service Mesh и Multi-cluster

Зачем знать на Middle 3: Service mesh — это инфраструктурный слой между микросервисами. На уровне Middle 3 / Senior Go-разработчик не пишет mesh сам, но проектирует приложения, живущие в mesh’е: понимает, как mTLS меняет аутентификацию, как retries в sidecar взаимодействуют с retry-логикой клиента, как traffic shifting работает для canary, что такое L7 vs L4 политики, и в чём подвох sidecar overhead. Multi-cluster — это про disaster recovery, geo-distribution и compliance. Знание Istio/Linkerd/Cilium + Karmada/ArgoCD/Submariner — ожидаемый bagaj для senior Go-engineer’a, работающего в платформенной команде или в стартапе, доросшем до multi-region.

Содержание

Концепция: что такое service mesh, multi-cluster
Production-deep dive: Istio (классический + Ambient), Linkerd, Cilium, multi-cluster
Gotchas (10+)
Real cases: Spotify, Lyft, Discord
Вопросы (20+)
Practice
Источники

1. Концепция

1.1 Что такое Service Mesh

Service Mesh — это инфраструктурный слой, который обеспечивает service-to-service коммуникацию микросервисов: безопасность (mTLS), наблюдаемость (метрики/трейсы), управление трафиком (retries, circuit breaking, canary). Реализуется через sidecar pattern или per-node proxy.

Цель — вынести cross-cutting concerns из приложения в инфраструктуру, чтобы приложение оставалось «голым» бизнес-кодом.

   Без mesh:                              С mesh (sidecar):

   ┌────────────┐                         ┌──────────────────────┐
   │  Service A │ ──TCP/HTTP──→ B         │ Service A │ Envoy SC │
   │  + retry   │                         │           │  (proxy) │
   │  + TLS     │                         └──────────────────────┘
   │  + metrics │                                  │
   │  + auth    │                                  ▼
   └────────────┘                         ┌──────────────────────┐
                                          │ Envoy SC │ Service B │
                                          │  (proxy) │           │
                                          └──────────────────────┘

1.2 Архитектура: Control Plane vs Data Plane

   ┌───────────────────────────────────────────────────────┐
   │                    CONTROL PLANE                      │
   │   (Istio: istiod, Linkerd: control-plane)             │
   │   - Конфигурация маршрутизации                        │
   │   - Выпуск mTLS сертификатов                          │
   │   - Service discovery                                 │
   │   - Policy enforcement                                │
   └───────────────────────────────────────────────────────┘
                              │
                              │ xDS API (Envoy) / gRPC
                              ▼
   ┌───────────────────────────────────────────────────────┐
   │                     DATA PLANE                        │
   │   (Envoy / Linkerd-proxy / Pilot-agent)               │
   │   - Перехват трафика (iptables / eBPF)                │
   │   - L4/L7 маршрутизация                               │
   │   - mTLS termination                                  │
   │   - Метрики, трейсы                                   │
   └───────────────────────────────────────────────────────┘

1.3 Функции mesh’а

mTLS (zero-trust) — авто-выпуск сертификатов на каждый Service Account. Весь трафик шифрован и аутентифицирован без участия приложения.
Traffic management — VirtualService / TrafficSplit / HTTPRoute, weighted routing, header-based routing.
Resilience — retries, timeouts, circuit breaking, outlier detection.
Observability — авто-метрики (request rate, error rate, latency), auto-tracing.
Authorization — L7 (GET /admin/* от пользователя X запрещён) и L4.
Rate limiting, fault injection (chaos).

1.4 Sidecar pattern vs per-node proxy

Sidecar (Istio классический, Linkerd 2.x): proxy injected в каждый Pod (контейнер sidecar). Изоляция, но overhead на CPU/memory.
Per-node (Cilium service mesh, Istio Ambient ztunnel, Linkerd 2.16+ partial): один proxy на ноду, обслуживает все pods. Меньше overhead, но изоляция weaker.
Sidecar-less L4 / L7 split (Istio Ambient): ztunnel (L4 mTLS) на ноду + waypoint proxy (L7) на namespace при необходимости.

2. Production-deep dive

2.1 Istio (классический)

Компоненты

   ┌──────────────────────────────────────────────────────┐
   │                       istiod                          │
   │   ┌──────────┐  ┌──────────┐  ┌──────────┐           │
   │   │  Pilot   │  │ Citadel  │  │  Galley  │           │
   │   │ (xDS)    │  │ (CA)     │  │ (config) │           │
   │   └──────────┘  └──────────┘  └──────────┘           │
   └──────────────────────────────────────────────────────┘
                              │
                              │ xDS gRPC stream
                              ▼
   Каждый Pod в namespace `istio-injection=enabled`:

       ┌──────────────────────────────────────┐
       │  pod                                  │
       │  ┌──────────────┐  ┌──────────────┐  │
       │  │ application  │  │ istio-proxy  │  │
       │  │  container   │  │   (Envoy)    │  │
       │  └──────────────┘  └──────────────┘  │
       │  (iptables redirects all traffic     │
       │   to local Envoy on port 15001/06)   │
       └──────────────────────────────────────┘

VirtualService и DestinationRule

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts: [reviews]
  http:
    - match:
        - headers:
            x-canary:
              exact: "true"
      route:
        - destination: { host: reviews, subset: v2 }
    - route:
        - destination: { host: reviews, subset: v1 }
          weight: 90
        - destination: { host: reviews, subset: v2 }
          weight: 10
---
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    connectionPool:
      tcp: { maxConnections: 100 }
      http:
        http2MaxRequests: 1000
        maxRequestsPerConnection: 10
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 30s
  subsets:
    - name: v1
      labels: { version: v1 }
    - name: v2
      labels: { version: v2 }

mTLS режимы

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: prod
spec:
  mtls:
    mode: STRICT     # требовать mTLS
    # PERMISSIVE — mTLS если возможно, иначе plain
    # DISABLE — отключить

STRICT глобально включает zero-trust — приложение без sidecar не сможет общаться с тем, у кого есть sidecar.

Gateway и Ingress

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: ingress
spec:
  selector: { istio: ingressgateway }
  servers:
    - port: { number: 443, name: https, protocol: HTTPS }
      tls:
        mode: SIMPLE
        credentialName: tls-secret
      hosts: ["api.example.com"]

Современный стандарт — Gateway API (Kubernetes SIG-Network), Istio его реализует.

2.2 Istio Ambient Mesh

В 2024 году Istio Ambient Mesh достиг GA. Главная идея — избавиться от sidecar’ов:

   ┌───────────────────────────────────────────────────┐
   │                  Node N                           │
   │  ┌──────────┐  ┌──────────┐  ┌──────────┐        │
   │  │ Pod A    │  │ Pod B    │  │ Pod C    │        │
   │  │ (no SC)  │  │ (no SC)  │  │ (no SC)  │        │
   │  └──────────┘  └──────────┘  └──────────┘        │
   │      │              │              │             │
   │      └──────────────┼──────────────┘             │
   │                     ▼                            │
   │  ┌────────────────────────────────────────────┐  │
   │  │   ztunnel (DaemonSet, L4 mTLS proxy)       │  │
   │  └────────────────────────────────────────────┘  │
   └───────────────────────────────────────────────────┘
                              │
                              │ HBONE (HTTP/2 mTLS tunnel)
                              ▼
   ┌───────────────────────────────────────────────────┐
   │     waypoint proxy (L7, опционально, per ns)      │
   │     - retry/timeout/policy/L7-метрики             │
   └───────────────────────────────────────────────────┘

ztunnel — Rust, лёгкий, на ноде. Делает только L4 mTLS.
waypoint — Envoy, на namespace, опционально. Делает L7-политики, retries, observability.

Преимущества: меньше CPU/memory, нет sidecar restart issue, можно постепенно мигрировать (приложения без sidecar получают L4 mTLS бесплатно).

Минусы: молодая технология, ecosystem ещё догоняет, L7-фичи требуют waypoint.

2.3 Linkerd

Linkerd — second-generation mesh, фокус на simplicity + reliability metrics.

Data plane — linkerd2-proxy (Rust, ultra-light).
Control plane — Go, набор контроллеров.
API — простой, без бесконечных knobs.
Strong focus на golden metrics (P50/P95/P99, success rate).
Service Profile — описание API: routes, timeouts, retry budgets.

apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: api.prod.svc.cluster.local
  namespace: prod
spec:
  routes:
    - name: GET /users/{id}
      condition: { method: GET, pathRegex: "/users/[^/]+" }
      isRetryable: true
      timeout: 1s
      responseClasses:
        - condition: { status: { min: 500, max: 599 } }
          isFailure: true
  retryBudget:
    retryRatio: 0.2
    minRetriesPerSecond: 10
    ttl: 10s

Linkerd в 2026 году — выбор тех, кто ценит «работает из коробки, без 100 страниц документации».

2.4 Cilium Service Mesh

Cilium — CNI на eBPF, который в 2022+ включает функции mesh:

L4 mTLS на уровне eBPF (без sidecar).
L7-функции через Envoy (один Envoy на ноду).
Network policies на CRD.
Hubble — UI для observability.

В 2026 году Cilium и Istio Ambient — главные кандидаты на «mesh будущего».

2.5 Consul Connect

Consul от HashiCorp — service discovery + mesh. Hybrid: работает в Kubernetes и в VM (на bare metal). Data plane — Envoy. Используется в enterprises с heterogeneous infrastructure (legacy + k8s).

2.6 Trade-offs

Аспект	Sidecar (Istio классический)	Ambient (Istio Ambient)	Per-node (Cilium / Linkerd-cni)
CPU overhead	~50–500m на pod	~50m на ноду (ztunnel)	Минимальный (eBPF)
Memory overhead	~50–200Mi на pod	~30Mi на ноду	Минимальный
Latency overhead	1-3ms (двойной hop)	0.5-1ms (один tunnel)	<0.5ms
Изоляция	High (per-pod)	Medium	Low (shared)
L7-функции	Все	Через waypoint (опц.)	Через Envoy на ноду
Сложность	Высокая	Средняя	Средняя
Зрелость	Production years	GA в 2024	Production (Cilium years)

2.7 Когда mesh нужен и не нужен

Нужен:

50+ микросервисов, сложные политики.
Zero-trust security (mTLS строго).
Multi-tenant с L7-авторизацией.
Canary / traffic splitting часто.

Не нужен:

Маленькая система (≤10 сервисов).
Built-in NetworkPolicy + хороший Ingress достаточно.
Команда без опыта эксплуатации Envoy.

2.8 Multi-cluster и Multi-region

Зачем

HA / DR — выживание при отказе одного региона.
Geo-distribution — низкая latency для пользователей.
Tenant isolation — отдельные кластеры на крупного клиента.
Regulatory — data residency (GDPR, ЦБ, банковские требования).

Паттерны

   Active-Passive (DR):
   ┌──────────────┐         ┌──────────────┐
   │ Region eu-w  │         │ Region us-e  │
   │ (active)     │ ──────→ │ (standby)    │
   │ takes 100%   │         │ replicate DB │
   └──────────────┘         └──────────────┘

   Active-Active:
   ┌──────────────┐         ┌──────────────┐
   │ Region eu-w  │ ←────→  │ Region us-e  │
   │ 50% traffic  │         │ 50% traffic  │
   └──────────────┘         └──────────────┘
              │                     │
              ▼                     ▼
         Geo-DNS / Anycast for routing

Инструменты

KubeFed v2 — устарел, использовать не рекомендуется в 2026.
Karmada (CNCF) — текущий лидер multi-cluster orchestration. Описываете PropagationPolicy, ресурс деплоится в кластеры по правилам.
ArgoCD ApplicationSet — GitOps multi-cluster, шаблон Application на N кластеров.
Submariner — multi-cluster networking (cross-cluster service discovery + IPSec туннели).
Liqo — capability sharing (мягкое объединение нескольких кластеров в один логический).
Cilium Cluster Mesh — соединение кластеров на eBPF без overlay.
Istio multi-cluster — mesh across clusters (primary/remote modes).

Service discovery across clusters

Service payment.prod существует в cluster-a и cluster-b. Сервис из cluster-a хочет к payment в cluster-b:

Istio multi-cluster — расширенный endpoint discovery: один control plane (или federated) знает endpoints всех кластеров. Envoy в cluster-a маршрутит трафик на cluster-b через east-west gateway.
Submariner — ServiceExport / ServiceImport, прокидывает endpoint в DNS.
MCS API (Multi-Cluster Services API) — стандарт Kubernetes SIG, реализуется Submariner-ом и другими.

Кросс-кластерное GitOps

ArgoCD с ApplicationSet:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: payments
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            env: prod
  template:
    metadata:
      name: '{{name}}-payments'
    spec:
      destination:
        server: '{{server}}'
        namespace: payments
      source:
        repoURL: https://github.com/example/payments
        targetRevision: main
        path: deploy/k8s

Один ApplicationSet → N Application’ов в N кластерах.

Data replication

БД: managed Postgres/MySQL multi-region (RDS, Cloud SQL, CrunchyData) или peer-to-peer (CockroachDB, YugaByte, TiDB).
Объектные хранилища: S3 cross-region replication.
Очереди: Kafka MirrorMaker, NATS leaf nodes.

Чек-лист multi-region

DNS strategy — Route53 Geo / Latency / Failover, или внешний GSLB.
TLS — wildcard или sertbot per cluster.
Identity — single source of truth (OIDC, IAM).
Logging — centralized (Loki / ELK / Datadog).
Metrics federation — Thanos / Cortex / Mimir.
Tracing — global span IDs (OTel сохраняет trace_id).
Cost/Quota — следить, чтобы dual-region не удвоил счёт впустую.

Метрики multi-region

Thanos / Mimir / Cortex federation:

   cluster A (Prometheus) ─┐
                           ├─► remote_write ─► Mimir / Thanos
   cluster B (Prometheus) ─┘                       │
                                                   ▼
                                            Single Grafana
                                            (запрос ко всем)

Prometheus.remote_write отправляет samples на длительное хранение, где они дедуплицируются по labels (включая cluster, region). Grafana запрашивает Mimir, видит все кластеры.

Latency бюджет cross-region

Реальные числа (2026):

Регион ↔ Регион	RTT (TCP)	TLS handshake
eu-west ↔ eu-cent	5-15 ms	30-60 ms
eu-west ↔ us-east	70-90 ms	250-350 ms
eu-west ↔ ap-south	130-180 ms	500-700 ms
us-east ↔ ap-east	180-220 ms	600-800 ms

Каждый дополнительный round-trip съедает 100+ ms. Поэтому архитектура multi-region должна быть regional-affinity (request обрабатывается там, где попал) с асинхронной репликацией данных между регионами.

2.9 Istio multi-cluster topologies

Istio в multi-cluster — три основных режима:

   1. Multi-Primary (каждый кластер сам себе istiod)
      Cluster A (istiod_A) ↔ Cluster B (istiod_B)
      East-west gateway соединяет mesh'и

   2. Primary-Remote (один istiod на все кластеры)
      Cluster A (istiod) ─────► Cluster B (только sidecars)
                       ─────► Cluster C (только sidecars)

   3. External control plane (istiod вынесен из любого кластера)
      [Managed Istio] ─────► Cluster A
                      ─────► Cluster B
                      ─────► Cluster C

Multi-primary — самый отказоустойчивый (если один istiod упал, остальные продолжают). Primary-remote — дешевле, но единая точка отказа.

East-west gateway

Между mesh’ами трафик идёт через специальный eastwestgateway Service (LoadBalancer внутренней сетки) на порту 15443. Внутри — HBONE (HTTP/2 over mTLS).

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  namespace: istio-system
spec:
  components:
    ingressGateways:
      - name: istio-eastwestgateway
        enabled: true
        label: { istio: eastwestgateway, app: istio-eastwestgateway, topology.istio.io/network: network1 }
        k8s:
          service:
            type: LoadBalancer
            ports:
              - port: 15021
                targetPort: 15021
                name: status-port
              - port: 15443
                targetPort: 15443
                name: tls

2.10 Observability и debugging mesh’а

Service mesh — мощный, но «магия» легко становится «чёрным ящиком». Ключевые tools:

istioctl

istioctl analyze -n production      # анализ конфигурации, типичные ошибки
istioctl proxy-status               # синхронизация sidecars с istiod (xDS)
istioctl proxy-config cluster pod   # текущий Envoy cluster config
istioctl proxy-config route pod     # routes
istioctl proxy-config endpoints pod # endpoints
istioctl proxy-config listeners pod # listeners
istioctl experimental describe pod  # человекочитаемый отчёт о Pod'е в mesh

Envoy admin

Envoy слушает на 15000 (внутри pod’а):

kubectl exec -it pod -c istio-proxy -- curl localhost:15000/config_dump
kubectl exec -it pod -c istio-proxy -- curl localhost:15000/clusters
kubectl exec -it pod -c istio-proxy -- curl localhost:15000/stats?filter=upstream_rq_5xx

Auto-tracing

Istio автоматически генерирует trace headers (B3 / W3C). Если приложение пропускает headers — trace ломается между сервисами. Приложение всё равно должно propagate trace headers (sidecar не может сам это сделать через app-internal call).

Telemetry API (Istio 1.13+)

apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata: { name: tracing-config, namespace: istio-system }
spec:
  tracing:
    - providers: [ { name: "otel" } ]
      randomSamplingPercentage: 10.0

Управляет sampling, custom-метриками, access logs — отдельно от VirtualService/DestinationRule.

2.11 mTLS — что под капотом

Когда PeerAuthentication.mode = STRICT, происходит следующее:

istiod создаёт CA (или использует cert-manager) и выпускает короткоживущие (24h) сертификаты для каждого Service Account.
Pilot-agent в каждом sidecar обращается к istiod через xDS, получает SDS (Secret Discovery Service) — сертификат на свой SA.
Envoy автоматически делает mTLS handshake при исходящих connections.
На принимающей стороне Envoy проверяет SAN сертификата (spiffe://cluster.local/ns/prod/sa/checkout).

   Pod A (SA: checkout) ──── mTLS ────► Pod B (SA: payment)
        │                                       │
        │ xDS                                   │ xDS
        ▼                                       ▼
                          istiod (CA)

SPIFFE / SPIRE

SPIFFE — open стандарт identity для workload’ов. Identity-строка вида spiffe://example.org/ns/prod/sa/checkout. SPIRE — reference implementation. Istio использует SPIFFE-формат под капотом.

В zero-trust security модели identity workload’а = его SA в k8s. RBAC + AuthorizationPolicy строятся на SA, а не на IP/network.

2.12 AuthorizationPolicy (L7-авторизация)

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata: { name: allow-frontend, namespace: payments }
spec:
  selector:
    matchLabels: { app: payment-api }
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/frontend/sa/checkout"]
      to:
        - operation:
            methods: ["POST"]
            paths: ["/api/v1/charge"]
      when:
        - key: request.headers[x-tenant]
          values: ["acme", "globex"]

Это L7 правило: «только Pod с SA frontend/checkout может делать POST /api/v1/charge если header x-tenant равен acme или globex». До mesh такие правила писались в коде приложения — теперь декларативно.

2.13 GitOps для multi-cluster

ArgoCD ApplicationSet — основной паттерн:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata: { name: payments-multi-cluster }
spec:
  generators:
    - matrix:
        generators:
          - list:
              elements:
                - { region: eu, cluster_url: https://eu-prod.k8s.example.com }
                - { region: us, cluster_url: https://us-prod.k8s.example.com }
                - { region: ap, cluster_url: https://ap-prod.k8s.example.com }
          - git:
              repoURL: https://github.com/example/manifests
              revision: main
              files:
                - path: "apps/*/manifest.yaml"
  template:
    metadata: { name: '{{path.basename}}-{{region}}' }
    spec:
      project: default
      source:
        repoURL: https://github.com/example/manifests
        targetRevision: main
        path: '{{path}}'
        helm:
          valueFiles: [ values.yaml, values-{{region}}.yaml ]
      destination:
        server: '{{cluster_url}}'
        namespace: '{{path.basename}}'
      syncPolicy:
        automated: { prune: true, selfHeal: true }
        retry: { limit: 5 }

Один YAML генерит N×M Application’ов: N приложений × M кластеров. Git — source of truth, ArgoCD доставляет.

3. Gotchas

Gotcha 1: ⚠️ Sidecar startup race

Контейнер приложения может запуститься до sidecar’a, и первые requests падают. Решения:

holdApplicationUntilProxyStarts: true в proxyMetadata.
В Istio 1.18+ sidecar — nativeSidecar (Kubernetes native sidecar containers, Stable 1.29+).
Init container с wait-for-istio.

Gotcha 2: ⚠️ Retry budget overload

Если у вас retries: 3 в VirtualService и клиент сам ретраит 3 раза, и сервис-B ретраит к сервису-C — общий retry-fan-out до 27x при ошибке. Cascading failure. Решение: согласовать retries между уровнями, использовать retry budgets (Linkerd), отключить app-level retries если mesh их делает.

Gotcha 3: ⚠️ mTLS PERMISSIVE → STRICT миграция

Если переключиться на STRICT, не убедившись, что все клиенты имеют sidecar — кластер ломается. Делайте поэтапно: PERMISSIVE → audit → STRICT по namespace.

Gotcha 4: ⚠️ Outlier detection и flaky health checks

consecutive5xxErrors: 5 слишком чувствителен на коротком trafficе — единичные 500-е могут выкинуть pod. Используйте consecutiveLocalOriginFailures и больший interval.

Gotcha 5: ⚠️ Headless services не дружат с mesh L7

Если service clusterIP: None, меш не может перехватить L7-сcheme — нужен STATELESS mode или ServiceEntry. Часто проявляется в Postgres, Redis, Kafka.

Gotcha 6: ⚠️ Proxy memory leak

Envoy в долгоживущих connections (HTTP/2 streaming) может накопить буфера. Регулярно мониторьте istio_proxy_memory_usage.

Gotcha 7: ⚠️ Ambient + L7 без waypoint — нет retry

Если вы пользуетесь только ztunnel (L4), VirtualService retries не работают. Нужно явно деплоить waypoint на namespace.

Gotcha 8: ⚠️ Multi-cluster split brain

В active-active, если сеть между регионами оборвалась — оба становятся «правым» и обрабатывают трафик. Без consensus (CockroachDB, leadership lock) данные расходятся. Решение: idempotent operations, vector clocks, CRDT.

Gotcha 9: ⚠️ Karmada propagation lag

PropagationPolicy применяет ресурсы на N кластеров — не атомарно. На один кластер уже задеплоилось, на второй — ещё нет. Если canary должен быть синхронным — учитывать.

Gotcha 10: ⚠️ Cross-cluster latency накапливается

mesh add overhead (1-3ms). Cross-region — 30-100ms. Стек вызовов A→B→C через регионы — суммарно секунды. Сервисы должны быть «региональными» (один request — один регион).

Gotcha 11: ⚠️ TLS internal != TLS external

mesh даёт mTLS внутри. Но Ingress / Gateway тоже терминирует TLS — нужны отдельные сертификаты (Let’s Encrypt) для внешнего входа. Не путать.

Gotcha 12: ⚠️ Cluster Mesh / east-west gateway требует RBAC между кластерами

Cilium ClusterMesh или Istio multi-cluster требуют kubeconfig от обоих кластеров. Утечка credentials → доступ к обоим. Хранить в Secret, ротировать.

4. Real cases

4.1 Spotify

Spotify Backstage + service mesh для управления тысячами микросервисов. Mesh даёт стандартизированную observability, retries, mTLS. URL: Spotify Engineering.

4.2 Lyft (родина Envoy)

Lyft разработал Envoy в 2016, открыл его, теперь Envoy — основа Istio. Lyft использует mesh для blue-green deployment, canary, A/B-testing.

4.3 Discord

Discord использует multi-region active-active для голосовых серверов, плюс Cassandra (geo-replication) и Rust-based services. Service mesh внутренний, основан на gRPC + custom load-balancing.

4.4 Cloudflare

Cloudflare использует свой mesh (Quicksilver для config, Magic Transit для networking). Многокластерность на уровне 200+ POPs (points of presence). Урок: иногда дешевле написать свой mesh, чем тюнить Istio.

4.5 Финтех с активным DR

Банк с двумя регионами (Москва + Новосибирск). Active-passive. RTO < 5 минут. Karmada + ArgoCD + Submariner. Postgres с logical replication через WireGuard tunnel. Раз в квартал — drill (game day).

5. Вопросы

Что такое service mesh и какие проблемы он решает?
Чем sidecar-pattern отличается от per-node proxy?
Что такое control plane и data plane в Istio?
Что такое xDS API?
Какие mTLS-режимы есть в Istio (STRICT, PERMISSIVE, DISABLE)?
Что такое VirtualService и DestinationRule?
Что такое outlier detection и как он работает?
Что такое Istio Ambient Mesh и чем отличается от классического Istio?
Что такое ztunnel и waypoint?
Чем Linkerd отличается от Istio?
Что такое Linkerd ServiceProfile?
Что такое Cilium Service Mesh?
Когда service mesh не нужен?
Зачем нужен Gateway API (sig-network)?
Что такое retry budget?
Что такое circuit breaking в mesh?
Какие multi-cluster паттерны существуют (active-active, active-passive)?
Что такое Karmada и чем оно отличается от KubeFed?
Что такое Submariner и MCS API?
Что такое ApplicationSet в ArgoCD?
Как сделать service discovery across clusters?
Какие риски multi-region active-active?
Что такое split-brain в multi-region?
Как мигрировать с sidecar Istio на Ambient?
Что такое HBONE protocol в Istio Ambient?

6. Practice

Istio bookinfo + canary. Поднимите Istio в kind/minikube, задеплойте bookinfo, сделайте canary 90/10 для reviews-v1/v2.
mTLS STRICT. Включите PeerAuthentication mode: STRICT, проверьте, что pod без sidecar не может достучаться.
Authorization policy. Сделайте AuthorizationPolicy, разрешающую GET /products/* только из ns frontend.
Ambient mesh. Установите Istio Ambient в kind, переведите namespace в ambient mode, задеплойте waypoint и проверьте L7-политики.
Linkerd. Установите Linkerd, сделайте ServiceProfile с retry budget и timeout.
Cilium service mesh. Поставьте Cilium в kind с --set-mesh.enabled=true, проверьте L7 policy через CiliumNetworkPolicy.
Karmada. Поставьте Karmada control plane, подключите 2 кластера, задеплойте Deployment через PropagationPolicy.
ArgoCD ApplicationSet. Сконфигурируйте ApplicationSet с cluster generator, разверните одно приложение в 3 кластера.
Submariner. Соедините 2 kind-кластера через Submariner, проверьте cross-cluster service discovery.
Game day. Имитируйте отказ региона (выключите один кластер), проверьте RTO/RPO.

7. Источники

Istio Architecture — официальная архитектура.
Istio Ambient Mesh — GA в 2024.
Linkerd Architecture.
Cilium Service Mesh.
Envoy Proxy docs.
Kubernetes Gateway API — современная замена Ingress.
Karmada docs.
ArgoCD ApplicationSet.
Submariner docs.
Multi-Cluster Services API (MCS).
Cloud Native Patterns (Davis) — книга Cornelia Davis.
“Istio in Action” (Christian E. Posta) — глубокая книга по Istio.
Lyft Envoy talk (KubeCon) — оригинальные доклады.