Shaping e instradamento del traffico

1) Perché tutto questo

• Stabilità: impediamo ai vicini rumorosi di chiudere i canali.
• Le priorità e le quote tra tenenti e classi.
• Efficienza: invia una richiesta dove viene elaborata più velocemente/meno costosa.
• Controllo modifiche: rilasci canarini/weighted senza rischi.
• Risparmio: ottimizzazione dei costi egress/egress e della cache CDN.

2) Concetti di base

2. 1 Traffic shaping vs policing

Shaping - Allinea il traffico tamponando e inviando pacchetti alla velocità di destinazione (anti-esplosione).
Policing - «punizione» del superamento (drop/marcatura) senza buffer. Più duro, ma più economico.

2. 2 Classi, code e discipline

Code con priorità (PRIO), WFQ/DRR (Equity Distribuzione), HTB (Quote gerarchiche), CoDel/RED (Lotta al Buffer), ECN (Segnale di sovraccarico senza drop).
Su L7 sono «code» come limiti RPS/connettori/byte e pool prioritari.

2. 3 Algoritmi di limitazione

Token Bucket (n token aggiunto con rate r; richiesta «spende» k token).
Leaky Bucket (uscita fissa; Bene per l'antialiasing).
Limiti globali/locali: locali - veloci, globali - equi (Redis/etcd/per-tenant).

3) QoS su L3/L4

3. 1 DSCP/ToS e classi di servizio

Contrassegnare i pacchetti per tipo di traffico ( , backend-RPC, operazioni di sfondo).
In datacenter: concordare il criterio DSCP con la rete/cloud.

3. 2 Linux tc: HTB + fq _ codel (sketch)

bash
Clearing tc qdisc del dev eth0 root 2 >/dev/null         true

Корневая HTB с 1Gbit tc qdisc add dev eth0 root handle 1: htb default 30 tc class add dev eth0 parent 1: classid 1:1 htb rate 1gbit

Класс latency-critical 200Mbit tc class add dev eth0 parent 1:1 classid 1:10 htb rate 200mbit ceil 1gbit prio 0 tc qdisc add dev eth0 parent 1:10 handle 10: fq_codel

Класс background 100Mbit tc class add dev eth0 parent 1:1 classid 1:30 htb rate 100mbit ceil 1gbit prio 2 tc qdisc add dev eth0 parent 1:30 handle 30: fq_codel

3. 3 ECN/RED/BBR

ECN riduce i drop sui picchi RED/CoDel limita il buffer.
BBR (al posto di Cubic) spesso riduce la latitanza p99, soprattutto sopra le code WAN/pesanti.

4) Routing L7 (HTTP/gRPC/WS)

4. 1 Criteri di routing

Percorsi/metodi ('/api/v1/', 'POST'), intestazioni (versione client, flag fich, heder canario), cookie (A/B, sticky), etichette JWT (tenant/role), geo/ASN, finestre temporali, carico (outler detection).
Protocollo: HTTP/2 (multiplexing), HTTP/3/QUIC (resistenza alla perdita dei pacchetti), gRPC (bi-di streams), WebSocket (connettori a lunga vita).

4. 2 Split/release canarie ponderate

Rout'v1: 95% ',' v2: 5% ', aumento automatico con metriche verdi.
Rifilaggi: errori/latitanza/invarianti aziendali.

Avvoy (sketch)

yaml route:
weighted_clusters:
clusters:
- name: svc-v1 weight: 95
- name: svc-v2 weight: 5

Istio

yaml apiVersion: networking. istio. io/v1beta1 kind: VirtualService spec:
hosts: ["svc"]
http:
- route:
- destination: { host: svc, subset: v1, weight: 95 }
- destination: { host: svc, subset: v2, weight: 5 }

4. 3 sessioni Sticky e consistent hasing

Sessione affinity cookie/IP/JWT.
Consistent hasing per i cluster cache, i servizi sharded, i gateway rate limit.

Nginx

nginx upstream api {
hash $cookie_user_id consistent;
server 10. 0. 0. 1;
server 10. 0. 0. 2;
}

4. 4 Routing geo e latency-aware

a bordo (CDN/edge) per il RR/regione più vicina.
Latency-aware - Provini periodici health + misure RTT → il traffico verso il cluster «più veloce».

4. 5 Outlier detection / circuit breaking

Eliminazione di istanze «cattive»: max-ejection-percent, errori di base/latitanza.
Circuito breaker: limiti per connettori/RPS/in coda.

5) Traffic shaping a livello di gateway/mash-stack

5. 1 Rate limiting

Locale (per-pod) è una replica a basso costo, ma non equa.
Globale (Redis/etcd) - Giustizia per-tenant/API chiave.
Criteri: per-route, per-method, per-tenant, burst.

Avvoy RLS (sketch)

yaml typed_per_filter_config:
envoy. filters. http. ratelimit:
"@type": type. googleapis. com/envoy. extensions. filters. http. ratelimit. v3. RateLimit domain: "api"
rate_limit_service:
grpc_service: { envoy_grpc: { cluster_name: rate_limit_cluster } }

5. 2 Fairness e priorità

I pool prioritari sono « »> «sistema»> «sfondo».
DRR/WFQ equivalenti su L7: quote/peso per-client/tenante.

5. 3 Sovraccarico e protezione

Load-shed: guasto/degrado in caso di eccesso di budget.
Adattative concertency: l'altoparlante dei limiti da p50/p95/queue-len.
Server-side backpressure: 429/503 + Retry-After.

6) Livello eBPF e CNI

6. 1 Cilium/eBPF

Filtro/instradamento nel nucleo: meno contesto-pergamena, più sottili criteri L3-L7.
Maglev hasing per una distribuzione stabile.
Il programma eBPF per per per-pod QoS (TC/XDP hooks).

6. 2 Calico/NetworkPolicies

Criteri di accesso L3/L4, classi di priorità di base, integrazione con Kubernets QoS (Guaranteed/Burstable/BestEffort).

7) Edge/CDN e gateway API

CDN: chiavi cache (normalizzazione query/headers), stale-while-revalidate, protezione origin (rate limit/bot-filtri).
Gateway API: autenticazione, quote/piani tariffari (per-consumer), vincoli SLA, geo-routing, API.
WAF - Filtraggio sul bordo per non sprecare CPU del nucleo.

8) Pneumatici asincroni/stretch

Kafka/NATS/Pulsar: quote per produttori/consumatori, limite di dimensioni batch, backpressure tramite lag.
Routing eventi: chiavi di partizionamento (tenant/idempotency-key) che misurano le partizioni per uniformità.
Exactly-once «efficiente una volta»: produttori transazionali + sink idempotati.

9) Timeout, retrai, backoff

Timeout completi: client <proxy <servizio (non il contrario).
Retrai: numero limitato con backoff esponenziale jitterizzato, ma senza tempeste.
Idampotenza obbligatoria per i retrai; altrimenti - SAGA/compensi.
Hedged/parallel richiesti (attenzione): migliora il p99, aumenta il traffico totale.

10) Osservabilità e SLO

10. 1 Metriche

rate_limit_hits, requests_queued, shed_requests_total, latency_ms{p50,p95,p99}, error_ratio, retry_attempts, outlier_ejections, queue_time_ms.

10. 2 Tracing

Scorrere Correlation-ID; contrassegnare il tipo di motivo per cui "retry" shed "throttle" queue ".
Links per i retrai/hedges per capire l'impatto sui sottosistemi.

10. 3 Logi/report

Riepilogo di drop/shedding/limits, mappe termiche lungo le rotte.
Pannelli separati per il feirness (fairness index).

10. 4 esempi SLO

"p99 ≤ 300 ms a 95 percento di carico; shed ≤ 0. 1%; error_ratio ≤ 0. 5%».
Almeno il 95% della quota è garantito alla classe interattiva durante il sovraccarico.

11) Esempi di configurazione

11. 1 Nginx: rate limit + burst + split canareo

nginx map $http_x_canary $canary { default 0; 1 1; }

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

upstream api_v1 { server 10. 0. 0. 1; }
upstream api_v2 { server 10. 0. 0. 2; }

server {
location /api/ {
limit_req zone=perip burst=20 nodelay;
if ($canary) { proxy_pass http://api_v2; break; }
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_pass http://api_v1;
}
}

11. 2 Envoy: circuit breaker + outlier detection

yaml circuit_breakers:
thresholds:
- priority: DEFAULT max_connections: 1000 max_pending_requests: 500 max_requests: 2000 outlier_detection:
consecutive_5xx: 5 interval: 10s max_ejection_percent: 50 base_ejection_time: 30s

11. 3 Istio: per-tenente quota (riserva tramite label)

yaml apiVersion: security. istio. io/v1 kind: AuthorizationPolicy spec:
selector: { matchLabels: { app: api } }
rules:
- when:
- key: request. headers[x-tenant]
values: ["gold"]
Next - RateLimitPolicy in the limit provider with a large quota pool for "gold."

11. 4 Kubernets hints

Guaranteed per sottoprodotti critici (sollests = limits).
PodPriority & Preemption - I sottostanti critici supereranno quelli di sfondo in caso di deficit.
Topology Spread Constrains: distribuzione delle aree per la stabilità.

12) Anti-pattern

Il limite globale è di 429/timeout falsi su clienti importanti.
Retrai senza jitter/idampotenza della tempesta.
Confusione dei timeout (Client> Server) e doppi lavori.
Cache/code comuni per prod e esperimenti per l'inquinamento dei dati.
«Sempre sticky», senza buon senso, è un carico ineguagliabile/nodi caldi.
Un outlier detection disattivato con un'istanza «marcio» rovina le metriche della settimana.

13) Assegno-foglio di implementazione

• Segmentare il traffico: classi/tenenti/percorsi.
• Impostare i budget di destinazione: RPS/connettori/byte e p95/p99.
• Includere rate limit (locale + globale), circuito breaker, outlier detection.
• Regolare lo split canario + ripristinare automaticamente le metriche.
• Inserire timeout/retrai con backoff esponenziale + jitter.
• Attivare ECN/BBR (se possibile) e fq _ codel/HTB per egress.
• Singoli pool/cache/coda per «ombre» e esperimenti.
• Dashboard: metriche di limiti, code, latitanza, fairness.
• SLO e runbook: criteri di shedding/reimpostazione/inclusione.

14) FAQ

Q: Cosa scegliere, shaping o policing?
A: Per i percorsi personalizzati, shaping (antialiasing senza drop). Per le classi di servizio sfondo/bulk, policing per la protezione dei flussi critici.

Come evitare le tempeste retrae?
A: backoff jitterizzato, limite di tentativi, idampotenza, suggerimenti server «Retry-After», quote globali.

Q: Sticky o hasing?
A: Sticky - Quando si desidera una sessione/cache è locale; hashing - quando serve uniformità e stabilità dello sharding.

Q: Cosa dà HTTP/3/QUIC?
A: Senza blocchi HOL TCP, migliore resistenza alle perdite, recupero più rapido - riduce notevolmente le code p99/p999.

15) Riepilogo

Shaping efficiente e routing L7 sono un insieme coerente di regole: priorità e quote, equa distribuzione, limiti di sicurezza e routing intelligente, supportati da osservabilità e SLO. Seguendo le prassi descritte (HTB/fq _ codel/ECN ai livelli inferiori e superiore), otterrai code di latitanza prevedibili, resistenza al sovraccarico e rilasci controllati e sicuri.