Servizio Mesh e Criteri di traffico

1) Perché serve Service Mesh

• Protezione predefinita: mTLS, rilascio automatico/rotazione di certificati, identità dei servizi.
• Regole di traffico: routing L7, test canari/AV, degrado e stabilità.
• Osservabilità: metriche, fogli, tracce, segnali d'oro in ogni chiamata.
• Operazioni: criteri uniformi per tutte le lingue/frame.

Differenza dal gateway API: gateway - perimetro north-sud; mesh - east-west all'interno del cluster/organizzazione. Spesso lavorano insieme.

2) Architettura: piani e pattern

Data Plane: sidecar-proxy (Avvoy/Linkerd-proxy/haproxy), che intercetta il traffico sotto/VM.
Control Plane: distribuisce configurazioni (percorsi, criteri, certificati), memorizza lo stato e pubblica le unità di servizio.
Identity: solitamente SPIFFE ID e certificati X.509 automatici (SPIRE/CA incorporato).
Punti di ingresso/uscita: ingress/egress-gateway per controllare i flussi limite.
Modalità di implementazione: sidecar per ogni sotto; per-nodi/ambient-moda in nuove implementazioni.

3) Politica di sicurezza e zero-trust

1. mTLS by default: crittografia e autenticazione reciproca del servis↔servis.

• AuthN - Affidiamo solo le identità rilasciate da CA mesh'a (SPIFFE).
• AuthZ: regole dichiarative «chi può a chi e come» (RBAC/ABAC).

3. Isolamento e egress control:

• Domini/subnet consentiti uscita forzata tramite egress-gateway.
• Blocca gli esiti diretti dal suolo.

4. Rotazione dei segreti: certificati a breve durata, correzione automatica del proxy.

yaml apiVersion: security. istio. io/v1beta1 kind: PeerAuthentication metadata: { name: default, namespace: istio-system }
spec:
mtls: { mode: STRICT }

yaml apiVersion: security. istio. io/v1beta1 kind: AuthorizationPolicy metadata: { name: billing-allow, namespace: prod }
spec:
selector: { matchLabels: { app: billing } }
rules:
- from:
- source: { principals: ["spiffe://corp. local/ns/prod/sa/inventory"] }
to:
- operation: { ports: ["8080"], methods: ["POST"], paths: ["/proto. Billing/"] }

4) Criteri di traffico: sostenibilità e routing

4. 1 Timeout e retrai

Timeouts è obbligatorio per la chiamata (connect/read/overall).
Retries solo per le operazioni Idempotent backoff + jitter; limiti per-try timeout.

yaml apiVersion: networking. istio. io/v1beta1 kind: VirtualService metadata: { name: orders }
spec:
hosts: ["orders"]
http:
- route:
- destination: { host: orders, subset: v1, port: { number: 8080 } }
timeout: 5s retries:
attempts: 2 perTryTimeout: 2s retryOn: "5xx,connect-failure,reset"

4. 2 Circuit Breaker и outlier detection

CB limita le richieste/connessioni simultanee per proteggere gli upstream.
Outler: scarica istanze «cattive» su errori/latitanza.

yaml apiVersion: networking. istio. io/v1beta1 kind: DestinationRule metadata: { name: orders }
spec:
host: orders trafficPolicy:
connectionPool:
http: { http1MaxPendingRequests: 1024, maxRequestsPerConnection: 100 }
outlierDetection:
consecutive5xxErrors: 5 interval: 5s baseEjectionTime: 30s maxEjectionPercent: 50

4. 3 Canarie e condizioni

Weighted suddivide il traffico in peso v1/v2.
Header-based: bandiere/cookie/tenant per la nuova versione.
Sessione affinity: hash su chiave (ridimensionato con attenzione).

yaml http:
- match: [{ headers: { "x-experiment": { exact: "new" } } }]
route: [{ destination: { host: orders, subset: v2 } }]
- route:
- destination: { host: orders, subset: v1, weight: 90 }
- destination: { host: orders, subset: v2, weight: 10 }

4. 4 Fault Inquection e degrado

Iniezione di ritardi/errori per test di resistenza e SLO.

yaml fault:
delay: { fixedDelay: 300ms, percentage: { value: 10 } }
abort: { httpStatus: 503, percentage: { value: 1 } }

5) Limiti di rete: ingress/egress e servizi esterni

Ingress-gateway: unico punto di ingresso per i clienti esterni in mesh; integrazione con WAF/OIDC/ratelimits.
Egress-gateway: uscita centrale con elenco di host autorizzati, ispezione TLS, registrazione di telemetria.
ServiceEntry: dichiara SNI/host esterni come parte di mesh (criteri e mTLS-origination applicabili).

yaml apiVersion: networking. istio. io/v1beta1 kind: ServiceEntry metadata: { name: payments-external }
spec:
hosts: ["api. payments. com"]
ports: [{ number: 443, name: https, protocol: TLS }]
resolution: DNS location: MESH_EXTERNAL

6) Multi-cluster, multi-network e ibrido

Il dominio comune PKI/trust è un'unica identità SPIFFE tra cluster.
Endpoint discovery: palle di servizi tra le regioni; priorità locale e failover.
Isolamento di zona: politiche per le regioni, limiti e priorità.
VM in mesh connette legacy/Stateful sistemi al proxy e alle stesse regole.

7) Osservazione, SLO e funzionamento

Метрики: `requests_total`, `request_duration_ms{p50,p95,p99}`, `5xx_rate`, `retry_attempts`, `cb_state`, `mTLS_authz_denied`.
Loghi di accesso: strutturali, con «traceparent», «user/tenant», «response _ flags».
Tracing: iniezione di intestazione automatica (W3C Trace Text), sampling, span a livello hop.
SLO: obiettivi di p99/errori di rotta (service→service).
Alert: picco di «5xx», «reset», «outler _ ejections», degrado di mTLS (handshake failures).

8) Prestazioni e costi

• Cereali: includere la politica dove necessario; non includere filtri pesanti ovunque.
• Pool - Separa i percorsi (critici/di sfondo) in percorsi e limiti diversi.
• Profilazione: p99 su percorsi «freddi», volume di telemetria (rate-limit logs/roulotte).
• Considerare le modalità ambient/sidecarless se supportate e adeguate ai requisiti.

9) Sicurezza e compliance

Accesso minimo richiesto: consente esplicitamente percorsi e metodi.
Criteri per Neimspace/Tenant - Limiti di rete/autorizzazioni.
Rotazione chiavi/SA pianificata e di emergenza certificati TTL brevi.
PII/segreti - occultamento in cassetti/roulotte; crittografia sul cavo/in pace.
Verifica: chi, quando e quali regole ha cambiato; Apruzzi a due fasi.

10) Integrazione con il livello K8s

Le politiche Mesh sono complementari, non sostitutive.
In ingress/egress-gateway puoi appendere il livello più basso.
NRA/Auto Scailing - Tenere conto dei retrai/SAN cambiano il carico.
I piani di rilascio sono pesi canari attraverso il VirtualService + progressione automatica dello SLO.

11) Assegno-foglio di implementazione

• I limiti di fiducia sono definiti ed è abilitato mTLS T.
• Le regole AuthZ sono abilitate: chi è verso chi, quali porte e quali metodi.
• Timeouts/retries e outlier detection sono stati configurati e sono stati definiti percorsi idipotenti.
• Le rotte canarie e il piano rollback sono prescritti; fault-inquection - solo in no-prod.
• Esposti dipendenze esterne attraverso egress-gateway e ServiceEntry.
• Le metriche, i fogli, le piste sono configurati; dashboard e alert per p99/5xx/CB.
• Sono previste quote/limiti per-tenant/namespace.
• Preparati runbooks: fuoriuscita certificato, rifiuto CA, degrado upstream, massa 503/RESET.
• Piano multi-cluster (PKI comune, priorità locali, script DR).
• Test giorni (game days) - Caduta del controllo plane, stop sidecar, interruzione della rete, upstream «velenoso».

12) Anti-pattern

Mesh «ovunque e subito» senza inventario di rotte e SLO è costoso.
I retrai sono predefiniti per tutti i metodi di ripresa effetti e valanga di traffico.
Il «temporaneo» disattivato rimane per sempre.
Egress senza gateway, fuga di dati/dipendenze non rilevate.
Una politica globale per tutti i servizi è finta sicurezza e falsi funzionamenti.
Zero osservabilità: attivato mesh, ma non raccogliamo metriche/roulotte - perdiamo il senso.

13) Ricette veloci

Linkerd: abilita mTLS e policy per server

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

Consul (L7 intent + splitter)

hcl
Kind = "service-router"
Name = "orders"
Routes = [{
Match { HTTP { PathPrefix = "/v1" } }
Destination { Service = "orders" }
}]
Kind = "service-splitter"
Name = "orders"
Splits = [
{ Weight = 90, ServiceSubset = "v1" },
{ Weight = 10, ServiceSubset = "v2" }
]

14) FAQ

Il mesh ha bisogno di una piccola squadra?
Se 3-5 servizi non ci sono più. Inizia con un buon ingress e librerie di stabilità. Collegare mesh quando si desidera mTLS predefinito, regole unificate e tracciabili senza modificare il codice.

Come si controlla il costo?
Misurare le sovrapposizioni (CPU/RAM/latency) sui percorsi critici, disattivare i filtri in eccesso, ridurre la quantità di cassetti/roulotte, utilizzare le modalità senza sidecar dove è sicuro.

È possibile interferire con i proxy personalizzati manualmente?
Si ', ma evitare il doppio routing/retro duplicato. Un unico posto è vero, il control plane.

Cosa c'è di più importante, sicurezza o prestazioni?
Il valore predefinito è protezione (mTLS, AuthZ). Le prestazioni vengono ottenute con connection pools, outlier detection, percorsi di destinazione.

15) Riepilogo

Servizio Mesh trasforma la rete tra i servizi in uno strato programmabile con regole comuni: crittografia e identità, instradamento e stabilità sottili, telemetria e quote. Iniziate con i percorsi critici, includete mTLS T e AuthZ, impostate timeout/retrai/SAN, controllate l'egress, misurate p99 e 5xx, eseguite il game days. Poi mesh diventerà un amplificatore di affidabilità e velocità di rilascio, non una fonte di sorpresa.