Service Mesh: Istio, Linkerd

Service Mesh: Istio, Linkerd

1) Ce este Service Mesh și când este necesar

Service Mesh este un strat de date de rețea/plan de control care oferă mTLS end-to-end, rutare, toleranță la erori și observabilitate între servicii fără rescriere de cod.

• Securitate implicită (zero-trust, identități de serviciu, politica de acces).
• Managementul traficului (Canary/Blue-Green, A/B, shadowing).
• Fiabilitate (retras, timeout, circuit de rupere).
• Observabilitate (valori, busteni, trasee).
• Standardizarea operațională (politici ca cod, GitOps).

• Multe microservicii cu cerință de multilingvitate și mTLS.
• Aveți nevoie de scenarii avansate de rutare/experimentare fără a schimba aplicația.
• Există cerințe de audit/politică la nivelul rețelei.

2) Istio vs Linkerd - o scurtă comparație

3) Modele de arhitectură și implementare

3. 1 plasă laterală (clasic)

Fiecare Pod primește un sidecar proxy.
Pro: maturitate, control complet L7.
Contra: CPU/RAM deasupra capului, complexitatea epuizării/depanării.

3. 2 Istio Ambient Mesh

ztunnel (L4) pe nod + waypoint proxies (L7), după cum este necesar.
Pro: costuri mai mici și complexitate, includerea treptată a L7.
Contra: Mai nou, nu toate cazurile L7 sunt disponibile fără punct de referință.

4) Identitate și mTLS (zero-trust)

4. 1 SPIFFE/SPIRE și certificate

Fiecărui antrenament i se atribuie un ID SPIFFE: "spiffe ://cluster. local/ns/NS/SA ".
Autentificare: TLS reciprocă între servicii.
Rotație cheie - automat (scurt 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 implicit

Activat după 'linkerd install' + 'linkerd injection'.
Clustere - propria ancoră de încredere, rotație automată.

5) Managementul traficului

5. 1 Istio: VirtualService (rute, canari)

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) Gateway-uri de intrare/ieșire și API

Istio Gateway (intrare/ieșire) - controlează traficul de intrare/ieșire, terminarea TLS, passthrough mTLS.
Linkerd funcționează cu controlere de intrare existente (NGINX/Contour/Traefik); ieșire - prin NetworkPolicy/egress-gateway-modele.
Politici de ieșire: lista albă a domeniilor, politica SNI, interdicția directă a internetului.

7) Autorizarea și politica

7. 1 Politica de autorizare Istio (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 Politica Linkerd (server + serverautorizare)

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) Observabilitate și telemetrie

8. 1 Măsurători

Istio Telemetry API → Prometheus: 'istio _ requests _ total', 'istio _ request _ duration _ milliseconds _ bucket', 'istio _ tcp _ received _ bytes _ total'.
Linkerd vis: 'request _ total', latency p50/p95/p99, 'success _ rate'.

8. 2 Trasee și jurnale

Push W3C Trace Context.
Istio/Envoy → OTLP в OpenTelemetry Collector; Linkerd - prin sidecar loggers/app SDK.

8. 3 Instanțe

Adăugați trace _ id la histogramele de durată pentru salt-to-trace.

9) Limitele ratei, WAF, filtre personalizate

Istio: EnvoyFilter/WASM pentru limitele tarifelor locale, serviciul de limită a ratei eksternale (Redis), precum și logica WAF (Lua/WASM).
Linkerd: suport nativ limitat; limita ratei - la nivel de intrare/gateway.

10) Multi-cluster

Istio: gateway est-vest, partajate PKI sau trust-bundle, servicii de descoperire prin intermediul ServiceEntry, Federația.
Linkerd: 'linkerd multicluster link', gateway per cluster, service-oglindă контроллер.

Utilizați-cazuri: active-regiuni, localizarea traficului, zero-trust federat.

11) Performanță și cost

Plasă laterală: CPU/RAM deasupra capului per Pod, latență crescută (de obicei + 1-3 ms per hop la starea de echilibru).
Ambient (Istio): mai puțin consum pentru L4, L7 este pornit punct.
Linkerd: proxy ușor este, în general, mai puțin deasupra capului, dar mai puțin capabilități extreme L7.
Practică: măsurați p95/CPU înainte/după, păstrați porțile SLO pentru degradare.

12) Siguranță

mTLS peste tot, scurt TTL, rotație automată.
Policy as Code (OPA/Gatekeeper, Kyverno) for 'authorizationPolicy: ALLOW all' prohibitions.
Secretele - prin CSI/Vault, nu în manifeste.
Control ieşire: negare în mod implicit, liste de permise explicite.
Domenii de încredere separate pentru medii (prod/stage).

13) Integrarea cu versiuni și SLO gating

Canary/Blue-Green sunt implementate pe rute de plasă (a se vedea exemple).
Analiză metrică (Prometheus/SpanMetrics) în Argo Rollouts AnalysisTemplate - Autostop/Rollback la burn-rate/p95/5xx.
Adnotări ale versiunilor în Grafana: comparison 'version = stable' canary '.

14) Anti-modele

Includeți plasa „peste tot și imediat” → șocul infrastructurii.
Ignorați cardinalitatea măsurătorilor/jurnalelor din proxy → supraîncărcarea stocării TSDB/jurnal.
Lăsați mTLS în modul PERMISIV/opac pentru totdeauna.
Încercați să faceți o logică complexă WAF/business în interiorul EnvoyFilter în loc de gateway/aplicație.
Fără politică de ieșire - scurgeri de internet/by-pass de conformitate.
Proxy cu „: 15000” depanare deschis la exterior.

15) Lista de verificare a implementării (0-60 zile)

0-15 zile

Selectarea modelului: Sidecar vs Ambient (Istio )/Linkerd după profilul de încărcare.
Activați mTLS STRICT, politici de autorizare de bază pentru 1-2 servicii critice.
Trasee de bază (timeout/retries), tablouri de bord RED/SLO.

16-30 zile

Canary/TrafficSplit, detectarea/spargerea circuitelor pe piste fierbinți.
Integrarea OTEL: trasee + Exemple; alertă arde-rata.
Egress-gateway-uri și lista albă de domenii; nega-în-mod implicit.

31-60 zile

Legătura multi-cluster (dacă este necesar), încrederea federației.
Politica ca cod на autorizarePolitica/ServerAutorizare.
Joc-zi: simulare de incident și rută/politică rollback.

16) Valorile maturității

mTLS (STRICT/auto-rotire) acoperire ≥ 95% din servicii.
Ponderea traficului prin lansări canare/progresive ≥ de 80%.
Medie deasupra capului p95 <+ 5% din valoarea iniţială (după optimizare).
0 ieșire deschisă fără permisiune, servicii 100% cu AuthZ de bază.
RCA „de la program la pistă” ≤ 2 minute (p50).

17) Exemple de „politică ca cod”

Gatekeeper (interdicție PERMISIVĂ în prod)

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 (etichete necesare pentru 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) Sfaturi operaționale

Politici și rute de versiune (semver), promovare prin GitOps.
Observabilitate proxy: tablouri de bord individuale „proxy saturation” (CPU/heap, retries, 429/503).
Bugetul cardinalității: etichete „rută”, „cod”, „destinație” - numai șablon.
Limite de rețea/namespace cote (NetworkPolicy/LimitRange).
Documentație de comandă: runbook „cum să se rostogolească înapoi trasee mTLS/politică/chei”.

19) Concluzie

Istio și Linkerd fac același lucru - standardizează siguranța, fiabilitatea și vizibilitatea comunicațiilor încrucișate - dar fac acest lucru la adâncimi diferite și costul de proprietate.

Ai nevoie de capacități bogate L7 și politici flexibile - ia Istio (ia în considerare Ambient pentru a reduce deasupra capului).
Nevoie de simplitate și mici deasupra capului - ia Linkerd.

Indiferent ce plasă alegeți: Activați mTLS în mod implicit, gestionați rutarea ca cod, asociați valorile cu piesele, închideți ieșirea și adăugați SLO gating la versiuni. Apoi, stratul de rețea va înceta să fie o „cutie neagră” și va deveni un instrument previzibil pentru stabilitatea și viteza de schimbare.