Shaping y enrutamiento de tráfico

1) Por qué todo esto

• Estabilidad: no dejamos que los «vecinos ruidosos» obstruyan los canales.
• Equidad: prioridades y cuotas entre tenantes/clases.
• Eficiencia: enviamos la solicitud a donde se procesa más rápido/más barato.
• Control de cambios: lanzamientos canarios/weighted sin riesgo.
• Ahorros: optimización de los costos egress/egress y de la memoria caché CDN.

2) Conceptos básicos

2. 1 Traffic shaping vs policing

Shaping: alinea el tráfico almacenando búfer y enviando paquetes a la velocidad de destino (suavizando «explosiones»).
Policing - «caraet» de exceso (drop/etiquetado) sin buffering. Más duro, pero más barato.

2. 2 Clases, colas y disciplinas

Colas prioritarias (PRIO), WFQ/DRR (distribución equitativa), HTB (cuotas jerárquicas), CoDel/RED (lucha contra el búfer), ECN (señal de congestión sin drop).
En L7, «colas» como límites de RPS/connects/bytes y agrupaciones prioritarias.

2. 3 Algoritmos de límite

Token Bucket (n tokens añadidos con rate r; solicitud «gasta» k tokens).
Leaky Bucket (salida fija; bueno para suavizar).
Límites globales/locales: local - rápido, global - justo (Redis/etcd/per-tenant).

3) QoS en L3/L4

3. 1 DSCP/ToS y clases de servicio

Etiquete los paquetes por tipo de tráfico (interactivo, backend-RPC, trabajos de fondo).
En los centros de datos: armonice la política DSCP con la fábrica/nube de la red.

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

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 reduce los drops en los picos; RED/CoDel limita el búfer.
BBR (en lugar de Cubic) a menudo reduce la latencia p99, especialmente sobre las colas WAN/pesadas.

4) Enrutamiento L7 (HTTP/gRPC/WS)

4. 1 Criterios de routing

Rutas/métodos ('/api/v1/', 'POST'), encabezados (versión del cliente, banderas de fichas, header canario), cookies (A/B, sticky), etiquetas JWT (tenant/role), geo/ASN, ventanas temporales, carga (outlier detection).
Protocolo: HTTP/2 (multiplexación), HTTP/3/QUIC (resistencia a la pérdida de paquetes), gRPC (bi-di streams), WebSocket (conexiones de larga vida).

4. 2 Split ponderado/lanzamientos canarios

Enganche 'v1: 95%', 'v2: 5%', aumento automático con métricas 'verdes'.
Cortes: errores/latencia/invariantes comerciales.

Envoy (esbozo)

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 Sesiones de Sticky y Consistent hashing

Afinidad de sesión por cookie/IP/JWT-ID.
Consistent hashing para clústeres de caché, servicios cifrados, gateways rate limit.

Nginx

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

4. 4 Geo- y latency-aware routing

GeoIP/ASN en el borde (CDN/edge) → el RR/región más cercana.
Latency-aware: muestras periódicas de salud + mediciones de RTT → tráfico al clúster «más rápido».

4. 5 Outlier detection / circuit breaking

Eliminación de instancias «malas»: max-ejection-percent, errores básicos/latencia.
Circuit breaker: límites para conexiones/RPS/en colas.

5) Traffic shaping a nivel de pasarela/pila de memoria

5. 1 Rate limiting

Local (per-pod): barato pero no justo entre réplicas.
Global (Redis/etcd): equidad per-tenant/API-key.
Políticas: per-route, per-method, per-tenant, burst.

Envoy RLS (esbozo)

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 y prioridades

Grupos prioritarios: «Interactivo»> «Sistema»> «Fondo».
DRR/WFQ equivalentes en L7: cuotas/pesos por cliente/tenant.

5. 3 Sobrecarga y protección

Load-shed: falla/degradación cuando se exceden los presupuestos.
Concurrencia adaptativa: dinámica de límites de p50/p95/queue-len.
Server-side backpressure: 429/503 + Retry-After.

6) Nivel eBPF y CNI

6. 1 Cilium/eBPF

Filtrado/enrutamiento en el núcleo: menos contextos, directivas de L3-L7 delgadas.
Maglev hashing para una distribución estable.
Programas de eBPF para QoS per-pod (TC/XDP hooks).

6. 2 Calico/NetworkPolicies

Directivas de acceso de L3/L4, clases de prioridad básica, integración con Kubernetes QoS (Guaranteed/Burstable/BestEffort).

7) Puertas de enlace Edge/CDN y API

CDN: claves de caché (normalización de query/headers), stale-while-revalidate, protección de origen (filtros de límite de velocidad/bot).
Pasarelas API: autenticación, contingentes/planes arancelarios (per-consumer), restricciones SLA, geo-routing, versión API.
WAF: filtrar en el borde para no desperdiciar la CPU del núcleo.

8) Neumáticos asíncronos/streaming

Kafka/NATS/Pulsar: cuotas para productores/consumers, límite de tamaño de batch, backpressure a través de lag.
Enrutamiento de eventos: llaves de lote (tenant/idempotency-key), lotes «parpadeantes» para uniformidad.
Exactly-once ≈ «efectivamente una vez»: productores transaccionales + xinki idempotente.

9) Taimouts, retrayas, backoff

Los tiempos de espera son de extremo a extremo: cliente <proxy <servicio (no al revés).
Retrai: número limitado con retroceso exponencial jitterizado, pero sin tormentas.
La idempotencia es obligatoria en los retratos; de lo contrario - SAGA/compensación.
Solicitudes Hedged/parallel (cuidado): mejora p99, aumenta el tráfico total.

10) Observabilidad y SLO

10. 1 Métricas

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

10. 2 Treasing

Busque la Correlación-ID; note los durmientes con el tipo de causa: 'retry' shed 'throttle' queue '.
Links para retraídos/hedges para entender el impacto en los subsistemas.

10. 3 Registros/Informes

Resumen de drops/shedding/límites, mapas térmicos a lo largo de las rutas.
Paneles separados para el per-tenant de la justicia (índice fairness).

10. 4 Ejemplos de SLO

"p99 ≤ 300 ms a 95-percentil de carga; shed ≤ 0. 1%; error_ratio ≤ 0. 5%».
«Al menos el 95% de la cuota está garantizada a la clase interactiva en caso de sobrecarga».

11) Ejemplos de configuraciones

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

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: pluma-tenant de la cuota (reserva a través de la etiqueta)

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 hints

Guaranteed para pods críticos (requests = limits).
PodPriority & Preemption: las podas críticas desplazarán a las de fondo cuando escaseen.
Topology Spread Constraints: distribución por zonas para la sostenibilidad.

12) Anti-patrones

El límite global «por ojo» → falsos 429/timeouts en clientes importantes.
Retraídas sin jitter/idempotencia → tormenta.
Confusión de tiempos de espera (cliente> servidor) → colgar y «doble trabajo».
Cachés/colas comunes para prod y experimentos → contaminación de datos.
«Siempre sticky» sin sentido común → carga desigual/nodos calientes.
La detección de outlier desactivada → las instancias «podridas» estropean las métricas de la semana.

13) Lista de verificación de implementación

• Segmenta el tráfico: clases/tenantes/rutas.
• Establecer presupuestos de destino: RPS/connects/bytes y p95/p99.
• Habilite el límite de velocidad (local + global), circuito breaker, detección de salida.
• Configure el split canario + autocorrección por métricas.
• Impregnar los temporizadores/retraídos con backoff + jitter exponencial.
• Habilite ECN/BBR (siempre que sea posible) y fq_codel/HTB para egresos.
• Grupos/cachés/colas individuales para «sombras» y experimentos.
• Dashboards: métricas de límites, colas, latencia, fairness.
• SLO y runbook: criterios para la introducción/reversión/inclusión.

14) FAQ

P: ¿Qué elegir: shaping o policing?
R: Para rutas personalizadas - shaping (suavizado sin drops). Para las clases de servicio, «fondo «/» bulk »- policing para proteger los flujos críticos.

P: ¿Cómo evitar las tormentas retray?
R: backoff jitterizado, límite de intento, idempotencia, pistas de servidor 'Retry-After', cuotas globales.

P: ¿Sticky o hashing?
A: Sticky - Cuando se necesita una sesión/caché es local para el usuario; hashing - cuando se necesita uniformidad y estabilidad de charding.

P: ¿Qué da el HTTP/3/QUIC?
R: Sin bloqueos HOL TCP, mejor resistencia a las pérdidas, recuperación más rápida - reduce notablemente las colas p99/p999.

15) Resultados

La forma eficiente y el enrutamiento L7 son un conjunto coherente de políticas: prioridades y cuotas, distribución equitativa, límites seguros y enrutamiento inteligente respaldado por la observabilidad y el SLO. Siguiendo las prácticas descritas (HTB/fq_codel/ECN en los niveles inferiores y Envoy/Istio/Nginx/eBPF en los niveles superiores), obtendrá previsibles colas de latencia, resistencia a la sobrecarga y lanzamientos controlados y seguros.