Testing de Service Mesh

¿Qué Es un Service Mesh? #

Un service mesh es una capa de infraestructura que gestiona la comunicación entre microservicios. En lugar de que cada servicio implemente su propia lógica de retry, circuit breakers y encriptación, estas preocupaciones son manejadas por un proxy (sidecar) que se ejecuta junto a cada servicio.

Las implementaciones más comunes de service mesh son:

Cómo Funciona #

┌──────────────────┐     ┌──────────────────┐
│  Servicio A       │     │  Servicio B       │
│  ┌──────────────┐│     │┌──────────────┐  │
│  │  App Code    ││     ││  App Code    │  │
│  └──────┬───────┘│     │└──────▲───────┘  │
│         │        │     │       │          │
│  ┌──────▼───────┐│     │┌──────┴───────┐  │
│  │  Sidecar     │├────▶││  Sidecar     │  │
│  │  Proxy       ││     ││  Proxy       │  │
│  └──────────────┘│     │└──────────────┘  │
└──────────────────┘     └──────────────────┘

Todo el tráfico entre servicios fluye a través de los sidecar proxies. El control plane del mesh configura estos proxies con reglas de routing, políticas de seguridad y configuraciones de observabilidad.

Qué Probar en un Service Mesh #

1. Traffic Routing #

Los service meshes permiten routing sofisticado de tráfico: canary deployments, A/B testing, routing basado en headers y traffic splitting.

Test de canary deployment:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: product-service
spec:
  hosts:
    - product-service
  http:
    - route:
        - destination:
            host: product-service
            subset: v1
          weight: 90
        - destination:
            host: product-service
            subset: v2
          weight: 10

Cómo verificar: Envía 1,000 solicitudes y verifica que aproximadamente 900 van a v1 y 100 a v2.

2. Load Balancing #

Verifica que el mesh distribuya tráfico entre instancias del servicio usando el algoritmo configurado (round-robin, least connections, random).

Enfoque de testing:

1. Despliega 3 réplicas de un servicio.
2. Envía 100 solicitudes.
3. Revisa los access logs o métricas para verificar que cada réplica recibió tráfico similar.

3. Circuit Breakers #

Los circuit breakers previenen fallas en cascada deteniendo solicitudes a un servicio no saludable.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: product-service
spec:
  host: product-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 10
        http2MaxRequests: 100
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 60s
      maxEjectionPercent: 50

Enfoque de testing:

1. Haz que una instancia del servicio retorne errores 500.
2. Envía tráfico y verifica que el mesh eyecta la instancia fallida después de 5 errores 5xx consecutivos.
3. Verifica que el tráfico se redirige a instancias saludables.
4. Repara la instancia y verifica que re-entra al pool.

4. Fault Injection #

El mesh puede inyectar fallas sin cambiar el código de la aplicación — invaluable para resilience testing.

Inyectar un delay de 5 segundos:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: product-service
spec:
  hosts:
    - product-service
  http:
    - fault:
        delay:
          percentage:
            value: 100
          fixedDelay: 5s
      route:
        - destination:
            host: product-service

Inyectar errores HTTP 503:

http:
  - fault:
      abort:
        percentage:
          value: 50
        httpStatus: 503
    route:
      - destination:
          host: product-service

5. Verificación de mTLS #

Verifica que mutual TLS esté aplicado entre servicios.

Enfoque:

1. Verifica la configuración del mesh para confirmar que mTLS está en modo STRICT.
2. Intenta llamar un servicio directamente (bypaseando el sidecar proxy) — debería ser rechazado.
3. Usa istioctl o dashboards del mesh para verificar que todo el tráfico está encriptado.

6. Observabilidad #

Los service meshes proveen métricas, traces distribuidos y access logs automáticamente.

Verificar:

• Métricas de Prometheus se recolectan para cada llamada servicio-a-servicio.
• Traces distribuidos (Jaeger/Zipkin) muestran la ruta completa de la solicitud.
• Access logs capturan detalles de request/response.

Ejercicio: Escenarios de Testing de Service Mesh #

Configura un ambiente de service mesh y prueba sus funcionalidades clave.

Configuración #

Si tienes un cluster Kubernetes con Istio instalado, usa tus propios servicios. De lo contrario, usa la aplicación de ejemplo Bookinfo de Istio:

# Desplegar ejemplo Bookinfo
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/bookinfo/platform/kube/bookinfo.yaml

# Crear gateway
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/bookinfo/networking/bookinfo-gateway.yaml

# Verificar deployment
kubectl get pods

Tarea 1: Traffic Splitting #

Configura un canary deployment para el servicio reviews:

1. Aplica un VirtualService que enrute 80% del tráfico a reviews-v1 y 20% a reviews-v3.
2. Envía 50 solicitudes y registra qué versión atendió cada solicitud.
3. Verifica que el split de tráfico sea aproximadamente 80/20.

for i in $(seq 1 50); do
  curl -s http://$GATEWAY_URL/productpage | grep -o 'reviews-v[0-9]' >> results.txt
done
sort results.txt | uniq -c

Tarea 2: Fault Injection #

Inyecta un delay de 7 segundos en el servicio ratings:

1. Aplica un VirtualService con fault injection.
2. Accede a la productpage y observa el comportamiento.
3. ¿La página carga? ¿Muestra un error? ¿Cuánto tarda?
4. Documenta cómo los servicios upstream manejan el delay.

Tarea 3: Circuit Breaker #

Configura un circuit breaker para el servicio ratings:

1. Aplica un DestinationRule con outlier detection (3 errores 5xx consecutivos, eyección de 30 segundos).
2. Haz que el servicio ratings retorne errores.
3. Envía tráfico y observa cuándo el circuit breaker se activa.
4. Restaura el servicio y verifica que re-entra al pool.

Tarea 4: Auditoría de mTLS #

Verifica la encriptación entre servicios:

1. Revisa la política PeerAuthentication — ¿mTLS es STRICT o PERMISSIVE?
2. Usa Kiali o istioctl para verificar que todas las conexiones usan mTLS.
3. Si es PERMISSIVE, intenta enviar una solicitud no encriptada y documenta si tiene éxito.

Entregables #

1. Un reporte de testing documentando los resultados de cada tarea.
2. Screenshots o output de comandos mostrando distribución de tráfico, comportamiento ante fallas, activación del circuit breaker y estado de mTLS.
3. Una lista de problemas de configuración encontrados y recomendaciones.