🔴 Advanced

Service Mesh — Sieťová vrstva pre mikroslužby

Service mesh je dedikovaná infraštruktúrna vrstva, ktorá riadi komunikáciu medzi mikroslužbami. Namiesto toho, aby každá služba implementovala vlastnú logiku pre retry, timeout, šifrovanie a load balancing, tieto zodpovednosti preberá mesh.

Prečo potrebujeme service mesh?

V monolitickej architektúre komunikácia prebieha vnútri jedného procesu. Pri mikroslužbách sa z jednoduchých volaní funkcií stávajú sieťové requesty — a s nimi prichádzajú problémy:

  • Latencia a výpadky — sieť je nespoľahlivá
  • Bezpečnosť — kto smie volať koho?
  • Observability — kde je bottleneck?
  • Traffic management — canary deploymenty, A/B testovanie

Service mesh rieši všetky tieto problémy transparentne, bez zmien v kóde aplikácie.

Architektúra service mesh

Service mesh sa skladá z dvoch hlavných komponentov:

Data Plane

Proxy (najčastejšie Envoy), ktorý zachytáva všetku sieťovú komunikáciu. V tradičnom modeli beží ako sidecar kontajner vedľa každej služby.

Control Plane

Centrálny riadiaci komponent, ktorý konfiguruje všetky proxy. Definuje pravidlá pre routing, bezpečnosť a observability.

┌─────────────────────────────────┐
│         Control Plane           │
│   (Istiod / Linkerd Control)    │
└──────────┬──────────────────────┘
           │ konfigurácia
    ┌──────┴──────┐
    ▼             ▼
┌────────┐   ┌────────┐
│ Sidecar│   │ Sidecar│
│ Proxy  │   │ Proxy  │
├────────┤   ├────────┤
│ App A  │◄─►│ App B  │
└────────┘   └────────┘

Istio — Najrozšírenejší service mesh

Istio je open-source service mesh vytvorený Google, IBM a Lyft. Je postavený na Envoy proxy a ponúka bohatú funkcionalitu.

Kľúčové funkcie Istio

  • Traffic management — VirtualService, DestinationRule pre canary, traffic splitting
  • mTLS — automatické šifrovanie medzi službami
  • Authorization policies — jemnozrnné riadenie prístupu
  • Observability — distributed tracing, metriky, logy

Príklad: Canary deployment s Istio

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
    - route:
        - destination:
            host: reviews
            subset: v1
          weight: 90
        - destination:
            host: reviews
            subset: v2
          weight: 10

Tento manifest presmeruje 90 % trafficu na v1 a 10 % na v2 — ideálne pre postupné nasadzovanie novej verzie.

Istio Authorization Policy

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-frontend
spec:
  selector:
    matchLabels:
      app: backend
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/default/sa/frontend"]
      to:
        - operation:
            methods: ["GET", "POST"]

Linkerd — Ľahká alternatíva

Linkerd je CNCF graduated projekt, známy svojou jednoduchosťou a nízkou réžiou. Na rozdiel od Istio používa vlastný ultraľahký proxy (linkerd2-proxy) napísaný v Ruste.

Výhody Linkerd

  • Jednoduchá inštalácia — linkerd install | kubectl apply -f -
  • Nízka réžia — proxy spotrebuje ~10 MB RAM
  • Automatické mTLS — zero-config šifrovanie
  • Metriky out-of-the-box — success rate, latency, RPS
# Inštalácia Linkerd
curl -sL run.linkerd.io/install | sh
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -

# Injektovanie proxy do deployment-u
kubectl get deploy -o yaml | linkerd inject - | kubectl apply -f -

# Overenie
linkerd check
linkerd viz dashboard

Sidecar vs Ambient Mesh

Tradičný model s sidecar proxy má nevýhody — každý pod dostane extra kontajner, čo zvyšuje spotrebu zdrojov a komplikuje debugging.

Ambient Mesh (Istio)

Istio ambient mesh je nový prístup, ktorý eliminuje sidecar kontajnery:

  • ztunnel — L4 proxy bežiaci ako DaemonSet na každom node (mTLS, základný traffic management)
  • waypoint proxy — voliteľný L7 proxy pre pokročilé funkcie (len pre služby, ktoré to potrebujú)
Tradičný sidecar:     Ambient mesh:
┌──────────────┐      ┌──────────────┐
│ Pod           │      │ Pod           │
│ ┌────┐┌────┐ │      │ ┌────┐       │
│ │App ││Proxy│ │      │ │App │       │
│ └────┘└────┘ │      │ └────┘       │
└──────────────┘      └──────┬───────┘
                             │
                      ┌──────▼───────┐
                      │   ztunnel    │
                      │  (per-node)  │
                      └──────────────┘

Výhody ambient mesh

  • Nižšia spotreba zdrojov — žiadne sidecar kontajnery
  • Jednoduchší upgrade — mesh sa aktualizuje nezávisle od aplikácií
  • Lepšia kompatibilita — funguje s aplikáciami, ktoré mali problémy so sidecar

mTLS — Mutual TLS

Mutual TLS je základ bezpečnosti v service mesh. Na rozdiel od bežného TLS (kde sa overuje len server), pri mTLS sa overujú obe strany komunikácie.

Service mesh automatizuje:

  1. Vydávanie certifikátov — každá služba dostane identitu (SPIFFE)
  2. Rotáciu certifikátov — automaticky, bez downtime
  3. Vynucovanie šifrovania — všetka komunikácia je šifrovaná

Traffic Management v praxi

Service mesh umožňuje sofistikované riadenie trafficu:

Funkcia Popis
Canary releases Postupné presmerovanie trafficu na novú verziu
Traffic mirroring Kopírovanie trafficu na testovaciu verziu
Circuit breaking Automatické odpojenie nefunkčnej služby
Retry + timeout Konfigurovateľné na úrovni mesh
Rate limiting Ochrana pred preťažením
Fault injection Testovanie odolnosti (chaos engineering)

Kedy (ne)použiť service mesh?

Použite service mesh keď:

  • Máte desiatky+ mikroslužieb s komplexnou komunikáciou
  • Potrebujete mTLS a zero-trust networking
  • Chcete distributed tracing bez zmien v kóde
  • Robíte canary/progressive deploymenty

Nepoužívajte keď:

  • Máte málo služieb (2-5) — overhead sa neoplatí
  • Bežíte na edge/IoT — príliš veľká réžia
  • Tím nemá skúsenosti s Kubernetes — pridáva komplexitu

Porovnanie Istio vs Linkerd

Aspekt Istio Linkerd
Proxy Envoy (C++) linkerd2-proxy (Rust)
Réžia Vyššia (~50 MB/proxy) Nižšia (~10 MB/proxy)
Funkcie Veľmi bohaté Esenciálne
Zložitosť Komplexný Jednoduchý
Multi-cluster Áno Áno
Ambient mode Áno Nie
CNCF Graduated Graduated

Best Practices

  1. Začnite s mTLS — najväčšia hodnota s najmenším úsilím
  2. Postupná adopcia — injektujte proxy namespace po namespace
  3. Monitorujte réžiu — sledujte CPU/RAM overhead proxy
  4. Používajte GitOps — mesh konfiguráciu verzujte v Gite
  5. Testujte v staging — mesh konfigurácia môže rozbiť komunikáciu

Service mesh je mocný nástroj pre organizácie s rozsiahlou mikroslužbovou architektúrou. Kľúč je vybrať si správny nástroj (Istio pre plnú kontrolu, Linkerd pre jednoduchosť) a adopovať ho postupne.