Service Mesh: Istio, Linkerd

Service Mesh: Istio, Linkerd

1) Cos'è Service Mesh e quando è necessario

Servizio Mesh è un livello del piano dati/gestione di rete che fornisce funzionalità di routing, routing, tolleranza di errore e osservabilità tra i servizi senza riscrivere il codice.

• Protezione predefinita (zero-trust, identità dei servizi, criteri di accesso).
• Gestione del traffico (Canary/Blue-Green, A/B, shadowing).
• Affidabilità (retrai, timeout, circuito breaking).
• Osservabilità (metriche, fogli, roulotte).
• Standardizzazione operativa (criteri come codice, GitOps).

• Un sacco di microservizi con polilinguinicità e richiesta di mTLS.
• Sono necessari scenari avanzati di routing/esperimenti senza modificare l'applicazione.
• Ci sono requisiti di controllo/regole a livello di rete.

2) Istio vs Linkerd - breve confronto

3) Architettura e modelli di implementazione

3. 1 Sidecar mesh (classico)

Ogni Pod riceve un proxy.
I vantaggi sono maturità, controllo totale L7.
Svantaggio: Costi generali CPU/RAM, complessità di debug/debug.

3. 2 Istio Ambient Mesh

ztunnel (L4) sul nodo + waypoint proxies (L7) per necessità.
Vantaggi: costi e complessità inferiori, inclusione graduale di L7.
Meno: più recente, non tutte le valigette L7 sono disponibili senza waypoint.

4) Identità e mTLS (zero-trust)

4. 1 SPIFFE/SPIRE e certificati

A ogni worcload viene assegnato un ID SPIFFE: 'spiffe ://cluster. local/ns/NS/sa/SA`.
Autenticazione: TLS reciproco tra i servizi.
Rotazione chiavi - Automatico (TTL breve).

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 predefinito

Attiva dopo «linkerd install» + «linkerd inject».
I cluster sono trust-anchor, rotazione automatica.

5) Gestione del traffico

5. 1 Istio: VirtualService (itinerari, canarini)

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 e API gateway

Istio Gateway (ingress/egress) - Controlla il traffico in entrata/uscita, TLS terminal, passthrough.
Linkerd funziona con i controller ingress esistenti (NGINX/Contour/Traefik); egress - Attraverso gli egress-gateway-pattern.
Regole egress: elenco di domini bianchi, SNI-policy, divieto di Internet diretto.

7) Autorizzazioni e criteri

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) Osservabilità e telemetria

8. 1 Metriche

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 Tracciati e fogli

Fare clic su W3C Trace Text.
Istio/Envoy → OTLP в OpenTelemetry Collector; Linkerd - tramite sidecar-logger/app-SDK.

8. 3 Varianti (Exemplars)

Aggiungi «trace _ id» agli istogrammi di durata per «jump-to-trace».

9) Rate limits, WAF, filtri di castoma

Istio: EnvoyFilter/WASM per rate limitits locali, eksternal-rate-limit service (Redis) e logica WAF (Lua/WASM).
Supporto nativo limitato rate limit - a ingress/gateway.

10) Multicasterizzazione

Istio: east-west gateway, comune PKI o trust-bundle, servizi di discovery via ServiceEntry, Federation.
Linkerd: `linkerd multicluster link`, gateway per cluster, service-mirror контроллер.

Use-case: asset-asset regioni, localizzazione del traffico, zero-trust federato.

11) Prestazioni e costi

Sidecar mesh: overhead CPU/RAM per ogni Pod, maggiore latitanza (solitamente + 1-3 ms per hop in steady-state).
Ambient (Istio) - Il consumo più basso per L4, L7 viene attivato in modo puntuale.
Linkerd: proxy leggero è generalmente meno overhead, ma meno funzionalità estreme L7.
Pratica: misurare p95/CPU prima/dopo, tenere SLO-gate per il degrado.

12) Sicurezza

mTLS ovunque, TTL breve, rotazione automatica.
Policy as Code (OPA/Gatekeeper, Kyverno) per i divieti «ALLOW all».
I segreti sono tramite CSI/Vault, non nei manifesti.
Egress Control: deny-by-default, fogli allow espliciti.
Singoli trust domains per ambienti (prod/stage).

13) Integrazione con release e SLO-gating

Canary/Blue-Green è implementato da percorsi mesh (vedere esempi).
Analisi delle metriche (Prometheus/SpanMetrics) in Argo Rollouts AnalysisTemplate - autostop/ritorno a burn-rate/p95/5xx.
Annotazioni di rilascio Grafana: confronto "variante = stabile" canary ".

14) Anti-pattern

Attivare il mesh dappertutto e subito lo shock dell'infrastruttura.
Ignora la cardinalità delle metriche/fogli dal proxy del sovraccarico TSDB/Logging.
Lascia il mTLS nella modalità PERMISSIVE/opache per l'eternità.
Cercare di rendere complessa la logica WAF/business all'interno del EnvoyFilter invece di gateway/applicazione.
Non c'è nessuna politica di fuga di notizie su Internet.
Proxy': 15000 'debug', aperto all'esterno.

15) Assegno foglio di implementazione (0-60 giorni)

0-15 giorni

Selezione del modello: Sidecar vs Ambient (Istio )/Linkerd per profilo di carico.
Abilita mTLS STRICT, criteri di autorizzazione di base per 1-2 servizi critici.
Percorsi di base (timeout/retries), dashboard RED/SLO.

16-30 giorni

Canary/TrafficSplit, outlier detection/circuito breaking sulle vie calde.
OTEL integrazione: trailer + Excempars; alert burn-rate.
Egress-gateways e elenchi bianchi di domini; deny-by-default.

31-60 giorni

Lente multicaster (se necessario), federation trust.
Policy as Code на AuthorizationPolicy/ServerAuthorization.
Game-day - Simulazione di un incidente e ripristino di percorsi/regole.

16) Metriche di maturità

La copertura del (STRICT/auto-rotate) si estende al 95% dei servizi.
La percentuale di traffico attraverso i canali è dell '80%.
Media overhead p95 <+ 5% dalla linea base (dopo l'ottimizzazione).
0 egress aperti senza autorizzazione, 100% servizi con AuthZ di base.
RCA «da grafico a pista» per 2 minuti (p50).

17) Esempi di criteri come codice

Gatekeeper (proibizione PERMISSIVE in vendita)

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 obbligatori per 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) Consigli operativi

Versionare politiche e percorsi (semver), promozioni attraverso il GitOps.
Osservabilità proxy: singoli dashboard «proxy saturation» (CPU/heap, retries, 429/503).
Le etichette «route», «code», «destination» sono solo modelli.
Limiti di rete/quote per il livello namespace (NetworkPolicy/LimitRange).
La documentazione del comando è runbook «come ritoccare percorsi/criteri/chiavi».

19) Conclusione

Istio e Linkerd hanno un unico obiettivo: standardizzare la sicurezza, l'affidabilità e la visibilità delle comunicazioni tra server, ma lo fanno con profondità e costi di proprietà diversi.

È necessaria una ricca capacità L7 e politiche flessibili - prendete Istio (considerate Ambient per ridurre le sovrapposizioni).
Serve semplicità e piccolo overhead - prendere Linkerd.

Qualunque sia la mesh che scegli: abilita il mTLS predefinito, controlla il routing come codice, collega le metriche alle roulotte, chiudi l'egress e aggiungi il gate SLO alle release. Il livello di rete non sarà più una scatola nera e diventerà uno strumento prevedibile per la stabilità e la velocità delle modifiche.