Service Mesh y política de tráfico

1) ¿Por qué necesita Service Mesh?

• Seguridad predeterminada: mTLS, emisión/rotación automática de certificados, identidad de servicios.
• Política de tráfico: enrutamiento L7, pruebas canarias/AV, degradación y sostenibilidad.
• Observabilidad: métricas, registros, rastros, señales de oro en cada llamada.
• Operaciones: políticas unificadas para todos los idiomas/marcos.

Diferencia de la puerta de enlace API: la puerta de enlace es un perímetro norte-sur; mesh - east-west dentro del clúster/organización. A menudo trabajan juntos.

2) Arquitectura: planos y patrones

Plano de datos: proxy sidecar (Envoy/Linkerd-proxy/haproxy) interceptando el tráfico de poda/VM.
Control Plane: distribuye configuraciones (rutas, políticas, certificados), almacena el estado, publica disquetes de servicio.
Identidad: normalmente, identificación SPIFFE y certificados X.509 automáticos (SPIRE/CA incorporado).
Puntos de entrada/salida: ingress/egress-gateway para controlar los flujos de frontera.
Modos de implementación: sidecar para cada debajo; las modas per-nodal/amb en nuevas implementaciones.

3) Política de seguridad y confianza cero

1. mTLS por default: cifrado y autenticación mutua de servis↔servis.

• AuthN: confiamos sólo en las identidades emitidas por CA mesh 'a (SPIFFE).
• AuthZ: reglas declarativas «quién puede a quién y cómo» (RBAC/ABAC).

3. Aislamiento y control egress:

• Dominios/subredes permitidos; salida forzada a través de egress-gateway.
• Bloquea los resultados directos de las podas.

4. Rotación de secretos: certificados de vida corta, reconfiguración automática 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) Política de tráfico: sostenibilidad y enrutamiento

4. 1 Tiempos de espera y retiros

Timeouts: necesariamente configurado para la llamada (connect/read/overall).
Retries: sólo para operaciones idempotentes; backoff + jitter; límites por-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 las solicitudes/conexiones simultáneas, protegiendo los upstreams.
Outlier: echa por tierra las instancias «malas» por error/latencia.

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 Canarios y condiciones

Weighted: separación del tráfico por pesos v1/v2.
Header-based: banderas/cookies/tenant → moverse a la nueva versión.
Session affinity: hash por clave (suavemente con zoom).

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 Inyección de faltas y degradación

Inyección de retrasos/errores para pruebas de resistencia y SLO.

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

5) Límites de red: ingress/egress y servicios externos

Ingress-gateway: el único punto de entrada para clientes externos en mesh; integración con WAF/OIDC/ratelimits.
Egress-gateway: salida central con lista de hosts permitidos, inspección TLS, grabación de telemetría.
ServiceEntry: declara SNI/host externos como parte de mesh (las políticas y la origen mTLS son aplicables).

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 híbrido

Dominio PKI/fideicomiso compartido: identidades SPIFFE uniformes entre clústeres.
Endpoint discovery: bolas de servicios entre regiones; prioridad local y failover.
Aislamiento zonal: Políticas, límites y prioridades de la región.
VM en mesh: conexión de sistemas legacy/Stateful a proxy y las mismas políticas.

7) Observabilidad, SLO y operación

Метрики: `requests_total`, `request_duration_ms{p50,p95,p99}`, `5xx_rate`, `retry_attempts`, `cb_state`, `mTLS_authz_denied`.
Registros de acceso: estructurales, con 'traceparent', 'user/tenant', 'response _ flags'.
Treking: Auto-inyección de encabezados (W3C Trace Context), sampling, durmiendo en el nivel hop.
SLO: objetivos por p99/errores en ruta (service→service).
Alertas: estallido de '5xx', crecimiento de 'reset', 'outlier _ ejections', degradación de mTLS (fallas de mano).

8) Rendimiento y costo

• Granulosidad: incluir la política donde sea necesario; no incluir filtros pesados en todas partes.
• Pools: divide las rutas (críticas/de fondo) en diferentes rutas y límites.
• Perfilando: p99 en rutas «frías», volumen de telemetría (rate-limit logs/tracks).
• Considerar los modos amb/sidecarless si se admiten y se ajustan a los requisitos.

9) Seguridad y cumplimiento

Acceso mínimo necesario: permitir explícitamente direcciones y métodos.
Políticas de no espaces/tenantes: límites de red/autorización.
Rotación de llaves/SA: planificada y de emergencia; certificados TTL cortos.
PII/secretos: enmascaramiento en logs/tries; cifrado en el cable/en reposo.
Auditoría: quién, cuándo y qué política ha cambiado; apruvas de dos pasos.

10) Integración con el nivel K8s

Las políticas de Mesh complementan, en lugar de reemplazar, a NetworkPolicy.
En ingress/egress-gateway, puede colgar PodSecurity/PSA en un nivel inferior.
NRA/Auto Scaling: considere retraídas/SV - cambian la carga.
Planes de lanzamiento: peso canario a través de VirtualService + promoción automática de SLO.

11) Lista de verificación de implementación

• Se han definido límites de confianza y STRICT mTLS está habilitado.
• Políticas AuthZ incluidas: quién a quién, en qué puertos/métodos.
• Se han configurado timeouts/retries y outlier detection, se han definido rutas idempotentes.
• Se especifican las rutas canarias y el plan rollback; fault-injection - sólo en el no-prod.
• Se han emitido dependencias externas a través de egress-gateway y ServiceEntry.
• Métricas, registros, rutas configuradas; dashboards y alertas en el p99/5xx/CB.
• Se prevén cuotas/límites per-tenant/namespace.
• Runbooks preparados: fuga de certificados, falla de CA, degradación de apstream, 503/RESET masivas.
• Plan multi-cluster (PKI general, prioridades locales, scripts DR).
• Días de prueba (días de juego): caída del plano de control, parada sidecar, rotura de la red, «venenoso» apstream.

12) Anti-patrones

Mesh «en todas partes y a la vez» sin inventario de rutas y SLO → costosa complejidad.
Retrés predeterminados para todos los métodos → toma de efectos y avalancha de tráfico.
El mTLS desactivado «temporalmente» → permanece para siempre.
Egress sin puerta de enlace → filtración de datos/dependencias no contabilizadas.
Una política global para todos los servicios → la seguridad falsa y los falsos positivos.
Observabilidad cero: activado mesh, pero no recogemos métricas/tracks - perdemos sentido.

13) Recetas rápidas

Linkerd: activar mTLS y la política por servidor

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

¿Necesito un equipo pequeño?
Si 3-5 servicios - más a menudo no. Comience con una buena ingresa y bibliotecas de sostenibilidad. Conecte mesh cuando se necesite mTLS por defecto, directivas únicas y rastreo sin cambiar el código.

¿Cómo puedo controlar el costo?
Mida las facturas (CPU/RAM/latency) en las rutas críticas, desactive los filtros superfluos, reduzca el volumen de registros/tracks, use modos sin sidecar donde sea seguro.

¿Es posible interferir con los proxies de mesh y manualmente configurados?
Sí, pero evite el doble enrutamiento/retrés duplicados. Un solo lugar es verdadero - control plane.

¿Qué es más importante: seguridad o rendimiento?
Por defecto, seguridad (mTLS, AuthZ). El rendimiento se logra afinando los pools de conexión, la detección de outlier, las rutas de destino.

15) Resultados

Service Mesh transforma la red entre servicios en una capa programable con políticas únicas: cifrado e identidades, enrutamiento fino y sostenibilidad, telemetría y cuotas. Comience con rutas críticas, active STRICT mTLS y AuthZ explícitos, defina temporizadores/retraídas/SV, controle el egreso, mida p99 y 5xx, realice días de juego. Entonces mesh se convertirá en un amplificador de fiabilidad y velocidad de lanzamiento, no en una fuente de sorpresas.