Shaping und Verkehrsführung

1) Warum das alles ist

• Stabilität: Wir verhindern, dass „lärmende Nachbarn“ die Kanäle verstopfen.
• Fairness: Prioritäten und Quoten zwischen Tenanten/Klassen.
• Effizienz: Wir leiten die Anfrage dorthin, wo sie schneller/billiger bearbeitet wird.
• Change Control: Kanarien-/Weighted-Releases ohne Risiko.
• Einsparungen: Optimierung der egress/egress-Werte und der CDN-Cache-Trefferquote.

2) Grundbegriffe

2. 1 Traffic shaping vs policing

Shaping - Gleicht den Datenverkehr durch Puffern und Senden von Paketen mit der Zielgeschwindigkeit aus (Glättung von „Explosionen“).
Policing - „Bestrafung“ der Überschreitung (Drop/Markierung) ohne Pufferung. Härter, aber billiger.

2. 2 Klassen, Warteschlangen und Disziplinen

Priority Queues (PRIO), WFQ/DRR (gerechte Verteilung), HTB (hierarchische Quoten), CoDel/RED (Bufferbloat-Bekämpfung), ECN (Drop-freies Überlastsignal).
Bei L7 gibt es „Warteschlangen“ in Form von RPS/Konnektivitäts-/Byte-Limits und Prioritätspools.

2. 3 Begrenzungsalgorithmen

Token Bucket (n Token werden mit der Rate r hinzugefügt; Anfrage „verbringt“ k Token).
Leaky Bucket (fester Abfluss; gut zum Glätten).
Globale/lokale Grenzen: lokal - schnell, global - fair (Redis/etcd/per tenant).

3) QoS auf L3/L4

3. 1 DSCP/ToS und Serviceklassen

Beschriften Sie Pakete nach Art des Datenverkehrs (interaktiv, Backend-RPC, Hintergrundjobs).
In Rechenzentren - Richten Sie die DSCP-Richtlinie mit der Netzwerkfabrik/Cloud aus.

3. 2 Linux tc: HTB + fq_codel (Skizze)

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 reduziert Tropfen auf Peaks; RED/CoDel schränkt das Pufferbloat ein.
BBR (anstelle von Cubic) reduziert oft die p99-Latenz, insbesondere über WAN/schwere Warteschlangen.

4) L7-Routing (HTTP/gRPC/WS)

4. 1 Routing-Kriterien

Pfade/Methoden ('/api/v1/', 'POST'), Header (Client-Version, Ficha-Flags, Kanarienkopf), Cookies (A/B, Sticky), JWT-Stempel (Tenant/Rolle), Geo/ASN, Zeitfenster, Last (Ausreißererkennung).
Protokoll: HTTP/2 (Multiplexing), HTTP/3/QUIC (Widerstand gegen Paketverlust), gRPC (Bi-Di-Streams), WebSocket (langlebige Anschlüsse).

4. 2 Gewichtete Split/Kanarienfreigaben

Root 'v1: 95%', 'v2: 5%', automatische Erhöhung bei „grünen“ Metriken.
Cutoff: Fehler/Latenz/Geschäftsinvarianten.

Envoy (Skizze)

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 Sticky-Sessions und konsistentes Hashing

Sitzungsaffinität durch Cookie/IP/JWT-ID.
Konsistentes Hashing für Cache-Cluster, Shared Services, Gate-Rate-Limit.

Nginx

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

4. 4 Geo- und Latenzrouting

GeoIP/ASN am Rand (CDN/edge) → die nächstgelegene Region.
Latency-aware: Regelmäßige Gesundheitstests + RTT-Messungen → den Datenverkehr zum „schnellsten“ Cluster.

4. 5 Outlier detection / circuit breaking

Knockout der „schlechten“ Instances: max-ejection-percent, Grundfehler/Latenz.
Circuit Breaker: Grenzen für Anschlüsse/RPS/in Warteschlangen.

5) Traffic-Shaping auf Gateway/Mash-Stack-Ebene

5. 1 Rate limiting

Lokal (per-pod): billig, aber nicht fair zwischen-Repliken.
Global (Redis/etcd): Gerechtigkeit per-tenant/API-Schlüssel.
Richtlinien: per-route, per-method, per-tenant, burst.

RLS aktivieren (Skizze)

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 und Prioritäten

Prioritätspools: „interaktiv“> „System“> „Hintergrund“.
DRR/WFQ-Äquivalente für L7: Quoten/Gewichte pro Kunde/Tenant.

5. 3 Überlastung und Schutz

Load-shed: Ausfall/Degradierung bei Budgetüberschreitung.
Adaptive Concurrency: Grenzdynamik aus p50/p95/queue-len.
Server-side backpressure: 429/503 + Retry-After.

6) eBPF und CNI-Ebene

6. 1 Cilium/eBPF

Filtern/Routing im Kernel: weniger Kontext-Switches, subtile Richtlinien L3-L7.
Maglev-Hashing für eine stabile Verteilung.
eBPF-Programme für Per-Pod-QoS (TC/XDP-Hooks).

6. 2 Calico/NetworkPolicies

L3/L4-Zugriffsrichtlinien, grundlegende Prioritätsklassen, Integration mit Kubernetes QoS (Guaranteed/Burstable/BestEffort).

7) Edge/CDN und API-Gateways

CDN: Cache-Schlüssel (Normalisierung query/headers), stale-while-revalidate, origin protection (rate limit/bot filter).
API-Gateways: Authentifizierung, Kontingente/Tarifpläne (per-consumer), SLA-Beschränkungen, Geo-Routing, API-Version.
WAF: Filterung am Rand, um die CPU des Kernels nicht zu verschwenden.

8) Asynchroner Bus/Streaming

Kafka/NATS/Pulsar: Quoten für Produzenten/Consumer, Batch-Size-Limit, Backpressure via Lag.
Event-Routing: Partitionierungsschlüssel (tenant/idempotency-key), „flackernde“ Parties für Gleichmäßigkeit.
Exactly-once ≈ „einmal effektiv“: Transaktionsproduzenten + idempotente Syncs.

9) Timeouts, Retrays, Backoff

Timeouts durch: Client <Proxy <Service (nicht umgekehrt).
Retrays: begrenzte Anzahl mit jitterisiertem exponentiellem Backoff, aber keine Stürme.
Idempotenz ist bei Retrays obligatorisch; ansonsten - SAGA/Entschädigung.
Hedged/parallel requests (Vorsicht): verbessert p99, erhöht den Gesamtverkehr.

10) Beobachtbarkeit und SLO

10. 1 Metriken

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

10. 2 Traising

Durchqueren Sie die Correlation-ID; Markieren Sie die Spans mit der Art der Ursache: 'retry' shed 'throttle' queue'.
Links für Retrays/Hedges, um die Auswirkungen auf Subsysteme zu verstehen.

10. 3 Protokolle/Berichte

Zusammenfassung von Drops/Shedding/Limits, Heatmaps nach Routen.
Separate Panels für den Per-Tenant der Gerechtigkeit (Fairness-Index).

10. 4 SLO-Beispiele

"p99 ≤ 300 ms bei 95-Perzentil Last; shed ≤ 0. 1%; error_ratio ≤ 0. 5%».
„Mindestens 95% der Quote sind für eine interaktive Klasse bei Überlastung garantiert“.

11) Beispiele für Konfigurationen

11. 1 Nginx: rate limit + burst + Kanariensplit

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: pro Tenant der Quote (Reserve über 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 Kubernetes QoS von Hinta

Garantiert für kritische Pods (requests = limits).
PodPriority & Preemption: Kritische Pods verdrängen bei Knappheit den Hintergrund.
Topologie Spread Constraints: Verteilung auf Zonen für Nachhaltigkeit.

12) Anti-Muster

Das globale Limit pro Auge → falsche 429/Timeouts bei wichtigen Kunden.
Retrai ohne Jitter/Idempotenz → Sturm.
Verwirrung von Timeouts (Client> Server) → Einfrieren und „Doppelarbeit“.
Gemeinsame Caches/Warteschlangen für prod und Experimente → Datenverschmutzung.
„Immer sticky“ ohne gesunden Menschenverstand → ungleichmäßige Belastung/heiße Knoten.
Eine deaktivierte Outlier-Erkennung → einer „faulen“ Instance verdirbt die Metriken der Woche.

13) Checkliste Umsetzung

• Segmentieren Sie den Verkehr: Klassen/Tenanten/Routen.
• Legen Sie die Zielbudgets fest: RPS/Anschlüsse/Bytes und p95/p99.
• Aktivieren Sie rate limit (lokal + global), circuit breaker, outlier detection.
• Richten Sie Kanariensplit + Auto-Otcat für Metriken ein.
• Schreiben Sie Timeouts/Retrays mit exponentiellem Backoff + Jitter.
• Aktivieren Sie ECN/BBR (wo möglich) und fq_codel/HTB für egress.
• Separate Pools/Caches/Warteschlangen für „Schatten“ und Experimente.
• Dashboards: Metriken für Limits, Warteschlangen, Latenz, Fairness.
• SLO und Runbook: Shedding/Rollback/Include Kriterien.

14) FAQ

Q: Was zu wählen: shaping oder policing?
A: Für benutzerdefinierte Pfade - Formen (Glätten ohne Tropfen). Für die Serviceklassen „Hintergrund „/“ Masse “- Policing zum Schutz kritischer Threads.

F: Wie vermeide ich Retray-Stürme?
A: Jitterisierter Backoff, Versuchsbegrenzung, Idempotenz, serverseitige' Retry-After '-Hinweise, globale Quoten.

F: Sticky oder Hashing?
A: Sticky - wenn eine Sitzung/Cache benötigt wird, ist der Benutzer lokal; Hashing - wenn Sie die Gleichmäßigkeit und Stabilität von Sharding benötigen.

F: Was bedeutet HTTP/3/QUIC?
A: Ohne HOL-TCP-Sperren, bessere Verlustfestigkeit, schnellere Erholung - reduziert die p99/p999-Schwänze deutlich.

15) Ergebnisse

Effektives Shaping und L7-Routing ist ein kohärenter Satz von Richtlinien: Prioritäten und Quoten, faire Verteilung, sichere Grenzen und intelligentes Routing, unterstützt durch Beobachtbarkeit und SLO. Indem Sie die beschriebenen Praktiken befolgen (HTB/fq_codel/ECN auf den unteren Ebenen und Envoy/Istio/Nginx/eBPF auf den oberen Ebenen), erhalten Sie vorhersehbare Latenzschwänze, Überlastungsresistenz und kontrollierte, sichere Releases.