Conceptos básicos

Este documento explica los conceptos principales y la arquitectura de Istio. Comprender estos conceptos básicos es importante para usar Istio de forma eficaz.

Tabla de contenido

1. Antecedentes e historia
2. ¿Por qué Istio?
3. Arquitectura de Istio
4. Modos de implementación: Sidecar vs Ambient
5. Recursos principales
6. Conceptos de gestión de tráfico
7. Conceptos de seguridad
8. Conceptos de observabilidad
9. Namespaces y Service Mesh
10. Próximos pasos

Antecedentes e historia

El nacimiento de Service Mesh

Desafíos de los microservicios

A principios de la década de 2010, las empresas comenzaron a dividir las aplicaciones monolíticas en microservicios.

Nuevos problemas:

Problema	Descripción	Impacto
Comunicación entre servicios	Aumento de las llamadas de red	Latencia, propagación de fallos
Observabilidad	Necesidad de trazado distribuido	Depuración difícil
Seguridad	Autenticación/cifrado entre servicios	Complejidad de implementación de mTLS
Control de tráfico	Implementaciones Canary, pruebas A/B	Modificaciones del código de la aplicación
Gestión de fallos	Circuit Breaker, Retry	Implementación por servicio

Solución inicial: bibliotecas

Problemas:

• Necesidad de desarrollar bibliotecas para cada lenguaje (Hystrix para Java, biblioteca independiente para Go...)
• Fuerte acoplamiento con el código de la aplicación
• Requiere volver a implementar todos los servicios para las actualizaciones
• Gestión de versiones compleja

Idea de Service Mesh: trasladar la lógica de red de la aplicación a una capa de infraestructura

El nacimiento de Envoy Proxy

El problema de Lyft

En 2015, Lyft enfrentaba los siguientes problemas:

• Operaba más de 200 microservicios
• Diversos lenguajes y frameworks (Python, Go, Java, etc.)
• Los proxies existentes (HAProxy, NGINX) eran insuficientes
  • Cambios dinámicos de configuración difíciles
  • Falta de observabilidad
  • Funciones avanzadas de enrutamiento limitadas

Matt Klein y Envoy

Matt Klein (ingeniero de Lyft) lanzó Envoy como código abierto en 2016.

Problemas que resolvió Envoy:

Características principales de Envoy:

1. Arquitectura fuera de proceso: proceso separado de la aplicación
2. APIs xDS: actualizaciones dinámicas de configuración
3. Proxy L7: compatibilidad con HTTP/2, gRPC y WebSocket
4. Observabilidad: métricas detalladas, trazado y registro
5. Rendimiento: escrito en C++, alto rendimiento

Adopción por CNCF

Cronología:

• Septiembre de 2016: Envoy se lanzó como código abierto
• Septiembre de 2017: aceptado como proyecto de CNCF (Incubating)
• Noviembre de 2018: promovido a proyecto CNCF Graduated

El nacimiento y la historia de Istio

Colaboración entre Google, IBM y Lyft

En mayo de 2017, Google, IBM y Lyft colaboraron para anunciar Istio.

Contribuciones de cada empresa:

Empresa	Contribución principal	Motivo
Google	Diseño del Control Plane	Experiencia con Borg y Kubernetes
IBM	Funciones empresariales	Requisitos de clientes empresariales
Lyft	Envoy Proxy	Proxy probado en producción

Historial de versiones de Istio

Hitos principales:

Versión 1.5 (marzo de 2020): punto de inflexión importante:

Arquitectura anterior (Istio 1.4 y versiones previas):

Separated into individual components:
- Mixer (policy/telemetry)
- Pilot (traffic management)
- Citadel (certificate management)
- Galley (configuration validation)

Arquitectura nueva (Istio 1.5+, versión actual 1.28):

Istiod (consolidated into single binary)
├── Pilot functionality (Service Discovery, Traffic Management)
├── Citadel functionality (Certificate Authority, Identity)
└── Galley functionality (Configuration Validation)

Mixer completely removed (functionality moved to Envoy)

Motivos del cambio:

• Reducción de la complejidad (4 componentes → 1)
• Mejora del rendimiento (reducción de latencia del 50 % al eliminar Mixer)
• Operaciones simplificadas (gestión de un único proceso)
• Eficiencia de recursos (menor uso de memoria y CPU)

¿Por qué Istio?

Kubernetes proporciona orquestación de contenedores, pero tiene limitaciones para gestionar la comunicación compleja entre microservicios. Istio es una solución de service mesh para abordar estos problemas.

Desafíos de los microservicios

Valores principales que proporciona Istio

1. Gestión de tráfico

Problema: se desea realizar una transición segura del tráfico al implementar nuevas versiones.

Solución de Istio:

# Canary deployment without code changes
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90  # Existing version 90%
    - destination:
        host: reviews
        subset: v2
      weight: 10  # New version 10%

Beneficios:

• No se requiere modificar el código de la aplicación
• Ajuste de la división de tráfico en tiempo real
• Reversión automática posible
• Compatibilidad con pruebas A/B e implementaciones Blue/Green

2. Seguridad

Problema: se desea cifrar y autenticar la comunicación entre servicios.

Solución de Istio:

# Automatic mTLS enablement
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT  # Automatic encryption for all inter-service communication

Beneficios:

• Emisión y renovación automática de certificados
• Verificación automática de identidad de Service
• Control de permisos granular
• Implementación de red Zero Trust

3. Observabilidad

Problema: es difícil rastrear el flujo de solicitudes a través de decenas de microservicios.

Solución de Istio:

• Generación automática de métricas (Latency, Traffic, Errors, Saturation)
• Trazado distribuido
• Visualización de la topología de servicios

Beneficios:

• Identificación automática de cuellos de botella
• Identificación rápida de la causa raíz de errores
• Supervisión del estado de los servicios en tiempo real

4. Resiliencia

Problema: el fallo de un Service se propaga a todo el sistema.

Solución de Istio:

# Automatic Circuit Breaker configuration
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s

Beneficios:

• Aislamiento de fallos (Circuit Breaker)
• Retry y Timeout automáticos
• Eliminación automática de instancias no saludables
• Limitación de tráfico (Rate Limiting)

Cuándo usar Istio

✅ Cuándo Istio es adecuado:

1. Arquitectura de microservicios
   • 10 o más servicios
   • Dependencias complejas entre servicios
   • Implementaciones frecuentes
2. Se necesita gestión avanzada de tráfico
   • Implementaciones Canary, pruebas A/B
   • Control de enrutamiento granular
   • Traffic Mirroring
3. Requisitos de seguridad estrictos
   • Cifrado obligatorio entre servicios
   • Control de acceso granular
   • Cumplimiento normativo
4. Observabilidad y depuración
   • Seguimiento de problemas complejos entre servicios
   • Identificación de cuellos de botella de rendimiento
   • Supervisión de SLO/SLA

❌ Cuándo Istio puede ser excesivo:

1. Aplicaciones simples
   • Pocos servicios (menos de 5)
   • Requisitos simples
   • Kubernetes Ingress es suficiente
2. Restricciones de recursos
   • Cluster pequeño
   • No se puede asumir la sobrecarga de recursos
   • Carga del coste de memoria de Sidecar
3. Falta de capacidad operativa
   • Tiempo de aprendizaje insuficiente
   • No hay un equipo de plataforma dedicado
   • Se prefieren soluciones más simples

Comparación de alternativas

Kubernetes Ingress vs Istio

Característica	Kubernetes Ingress	Istio
Alcance	Externo → Cluster	Externo + entre servicios internos
Enrutamiento	Básico (Path, Host)	Avanzado (Header, Cookie, etc.)
mTLS	Configuración manual	Automático
Observabilidad	Limitada	Rica
Complejidad	Baja	Alta
Caso de uso	Aplicaciones simples	Microservicios

AWS VPC Lattice vs Istio

Para una comparación detallada, consulte el documento de integración con AWS.

Resumen rápido:

• VPC Lattice: administrado por AWS, simple, comunicación entre VPC/cuentas
• Istio: código abierto, funciones potentes, solo Kubernetes, control granular

Linkerd vs Istio

Propiedad	Istio	Linkerd
Complejidad	Alta	Baja
Funciones	Muy completas	Solo funciones principales
Recursos	Altos	Bajos
Curva de aprendizaje	Pronunciada	Suave
Comunidad	Grande	Pequeña

Guía de selección:

• Se necesitan funciones avanzadas y flexibilidad → Istio
• Se necesita una malla simple y ligera → Linkerd

Modos de implementación: Sidecar vs Ambient

Istio admite dos modos de implementación: Modo Sidecar y Modo Ambient.

Modo Sidecar (predeterminado)

Inyecta un proxy Envoy como contenedor sidecar en cada Pod de aplicación.

Ventajas:

• Maduro y estable
• Compatibilidad con todas las funciones de Istio
• Control granular por Pod

Desventajas:

• Sobrecarga de recursos (Envoy por Pod)
• Mayor tiempo de inicio (Init Container)
• Configuración de permisos compleja (iptables)

Modo Ambient (nuevo enfoque)

Gestiona el tráfico a nivel de nodo sin sidecars.

Ventajas:

• Bajo uso de recursos (1 por nodo)
• Inicio rápido de Pod
• Operaciones simples
• Posible aplicación gradual de funciones L7

Desventajas:

• Tecnología relativamente nueva (menos madura)
• Algunas funciones avanzadas son limitadas
• Control granular por Pod difícil

Tabla comparativa

Propiedad	Modo Sidecar	Modo Ambient
Uso de recursos	Alto (por Pod)	Bajo (por nodo)
Tiempo de inicio	Lento (Init Container)	Rápido
Complejidad operativa	Alta	Baja
Funciones L4	Compatibles	Compatibles
Funciones L7	Compatibilidad total	Opcionales (Waypoint)
Madurez	Alta	Media
Migración	-	Posible desde Sidecar existente
Uso recomendado	Se necesitan funciones L7 avanzadas	Prioridad de eficiencia de recursos

Guía de selección

Elija el modo Sidecar:

• Necesita utilizar todas las funciones de Istio
• Necesita control de políticas granular por Pod
• Necesita estabilidad probada en producción

Elija el modo Ambient:

• La eficiencia de recursos es importante
• Solo se necesitan funciones L4 simples
• Planea agregar gradualmente funciones L7

Para más detalles, consulte el documento Avanzado: modo Ambient.

Arquitectura de Istio

Istio consta de dos componentes principales: Control Plane y Data Plane.

Componente	Descripción
Control Plane (istiod)	Sistema de control central responsable del descubrimiento de servicios, la distribución de configuración y la gestión de certificados
Data Plane (Envoy Proxy)	Implementado como sidecar en cada Pod, gestiona el tráfico real (enrutamiento, mTLS, métricas)

Para conocer la estructura detallada de la arquitectura, los principios de funcionamiento interno y los mecanismos de interceptación de tráfico, consulte el documento de arquitectura.

Recursos principales

Istio utiliza Kubernetes Custom Resource Definitions (CRDs) para gestionar la configuración.

1. VirtualService

VirtualService define cómo se enrutan las solicitudes a los servicios.

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
  - reviews  # Target service
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2  # Route specific user to v2
  - route:
    - destination:
        host: reviews
        subset: v1  # Route to v1 by default

Características principales:

• Enrutamiento basado en Path (Path, Header, Query Parameter)
• División de tráfico (Canary, pruebas A/B)
• Retry, Timeout, Fault Injection
• URL Rewrite, manipulación de Header

2. DestinationRule

DestinationRule define subconjuntos (versiones) de Service y aplica políticas de tráfico.

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews-destination
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST  # Load balancing algorithm
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 50
        maxRequestsPerConnection: 2
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3

Características principales:

• Definición de versión (subset) de Service
• Algoritmo de balanceo de carga
• Configuración de Connection Pool
• Circuit Breaker (Outlier Detection)
• Configuración de TLS

3. Gateway

Gateway gestiona el tráfico externo que entra en la malla.

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  selector:
    istio: ingressgateway  # Select Ingress Gateway pod
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "bookinfo.example.com"
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: bookinfo-credential  # TLS certificate
    hosts:
    - "bookinfo.example.com"

Características principales:

• Definir el punto de entrada de tráfico externo
• Configuración de Host, puerto y protocolo
• Terminación de TLS
• Enrutamiento SNI

4. ServiceEntry

ServiceEntry permite usar servicios externos fuera de la malla como servicios internos.

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: external-api
spec:
  hosts:
  - api.external.com
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  location: MESH_EXTERNAL
  resolution: DNS

Características principales:

• Registro de servicios externos
• Control de tráfico para servicios externos
• Gestión de tráfico de Egress

5. PeerAuthentication

PeerAuthentication define las políticas de autenticación entre servicios.

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT  # STRICT, PERMISSIVE, DISABLE

6. AuthorizationPolicy

AuthorizationPolicy define los permisos de acceso a Service.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-ratings
  namespace: default
spec:
  selector:
    matchLabels:
      app: ratings
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/reviews"]
    to:
    - operation:
        methods: ["GET"]

Conceptos de gestión de tráfico

Flujo de enrutamiento de tráfico

División de tráfico (implementación Canary)

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews-canary
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90  # 90% of traffic
    - destination:
        host: reviews
        subset: v2
      weight: 10  # 10% of traffic (canary)

Circuit Breaker

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews-circuit-breaker
spec:
  host: reviews
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 10
        maxRequestsPerConnection: 2
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s
      maxEjectionPercent: 50

Conceptos de seguridad

mTLS (TLS mutuo)

Istio cifra automáticamente la comunicación entre servicios.

Modos de mTLS:

• STRICT: solo se permite mTLS
• PERMISSIVE: se permiten tanto mTLS como texto sin cifrar (para migración)
• DISABLE: mTLS deshabilitado

Autenticación y autorización

# JWT Authentication
apiVersion: security.istio.io/v1
kind: RequestAuthentication
metadata:
  name: jwt-auth
spec:
  jwtRules:
  - issuer: "https://accounts.google.com"
    jwksUri: "https://www.googleapis.com/oauth2/v3/certs"
---
# Authorization Policy
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
spec:
  action: DENY
  rules:
  - from:
    - source:
        notRequestPrincipals: ["*"]

Conceptos de observabilidad

Istio genera automáticamente métricas, registros y trazas.

Métricas generadas automáticamente

Métricas principales

Métrica	Descripción
istio_requests_total	Recuento total de solicitudes
istio_request_duration_milliseconds	Latencia de solicitudes
istio_request_bytes	Tamaño de solicitud
istio_response_bytes	Tamaño de respuesta
istio_tcp_connections_opened_total	Recuento de conexiones TCP

Trazado distribuido

# Enable tracing in Envoy
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    enableTracing: true
    defaultConfig:
      tracing:
        sampling: 100.0  # 100% sampling
        zipkin:
          address: jaeger-collector.istio-system:9411

Namespaces y Service Mesh

Aislamiento de Namespace

# Per-namespace mTLS policy
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT
---
# Per-namespace authorization policy
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: production
spec:
  action: DENY
  rules:
  - {}

Alcance de Service Mesh

# Include only specific namespaces in the mesh
kubectl label namespace default istio-injection=enabled
kubectl label namespace staging istio-injection=enabled

# Exclude specific namespace
kubectl label namespace kube-system istio-injection=disabled

Multi-tenancy

# Restrict mesh scope with Sidecar resource
apiVersion: networking.istio.io/v1
kind: Sidecar
metadata:
  name: default
  namespace: production
spec:
  egress:
  - hosts:
    - "production/*"  # Only production namespace accessible
    - "istio-system/*"

Registro de cargas de trabajo de VM

Istio puede registrar no solo Pods de Kubernetes, sino también cargas de trabajo de Virtual Machine (VM) en la service mesh. Esto permite que las aplicaciones heredadas o los servicios fuera del cluster utilicen las funciones de gestión de tráfico, seguridad y observabilidad de Istio.

Por qué se necesitan cargas de trabajo de VM

Escenarios de uso:

• Migración gradual de aplicaciones heredadas
• Inclusión de servidores de bases de datos en la malla
• Integración de servicios fuera del cluster
• Configuración de entorno de nube híbrida

Arquitectura de registro de VM

Recurso WorkloadEntry

Las cargas de trabajo de VM se registran con el recurso WorkloadEntry.

apiVersion: networking.istio.io/v1
kind: WorkloadEntry
metadata:
  name: legacy-database
  namespace: default
spec:
  address: 192.168.1.100  # VM IP address
  labels:
    app: mysql
    version: v5.7
  serviceAccount: database-sa
  ports:
    mysql: 3306

Campos principales de WorkloadEntry:

• address: dirección IP de VM
• labels: coincide con el selector de Service
• serviceAccount: cuenta de Service para autenticación mTLS
• ports: definición de puertos expuestos

Integración con ServiceEntry

WorkloadEntry se usa con ServiceEntry para registrar servicios de VM en la malla.

# Define service with ServiceEntry
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: legacy-database
spec:
  hosts:
  - database.legacy.com
  ports:
  - number: 3306
    name: mysql
    protocol: TCP
  location: MESH_INTERNAL  # Register as internal mesh service
  resolution: STATIC
  workloadSelector:
    labels:
      app: mysql
---
# Register VM instance with WorkloadEntry
apiVersion: networking.istio.io/v1
kind: WorkloadEntry
metadata:
  name: mysql-vm-1
  namespace: default
spec:
  address: 192.168.1.100
  labels:
    app: mysql
    version: v5.7
  serviceAccount: mysql-sa

Comparación entre registro de VM y Multi-Cluster

Característica	Registro de carga de trabajo de VM	Multi-Cluster	Kubernetes Pod
Ubicación de la carga de trabajo	VM fuera del cluster	Cluster de Kubernetes diferente	Dentro del cluster
Instalación de Envoy	Instalación manual	Automática (sidecar)	Automática (sidecar)
Método de registro	WorkloadEntry	ServiceEntry + EndpointSlice	Service + Pod
mTLS	Compatible	Compatible	Compatible
Descubrimiento de servicios	Manual (IP especificada)	Automático	Automático
Escenario de uso	Aplicaciones heredadas, DB	Multinube, recuperación ante desastres	Aplicaciones cloud-native
Complejidad operativa	Alta	Media	Baja

Beneficios del registro de VM

1. Migración gradual

Beneficios:

• Integrar aplicaciones de VM existentes en la malla sin modificarlas
• Migrar a Kubernetes por etapas
• Mantener una seguridad y observabilidad coherentes durante la migración

2. Política de seguridad unificada

# mTLS policy applied to both VMs and pods
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT  # Enforce mTLS for both VMs and pods
---
# VM database access control
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: database-access
  namespace: default
spec:
  selector:
    matchLabels:
      app: mysql  # WorkloadEntry label
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/app-sa"]
    to:
    - operation:
        methods: ["*"]

3. Observabilidad coherente

Las cargas de trabajo de VM proporcionan las mismas métricas, registros y trazado distribuido que los Pods de Kubernetes.

# Unified metric query for VMs and pods
sum(rate(istio_requests_total{destination_workload="mysql-vm-1"}[5m]))

# Error rate from VM
sum(rate(istio_requests_total{destination_workload="mysql-vm-1",response_code="500"}[5m]))
/
sum(rate(istio_requests_total{destination_workload="mysql-vm-1"}[5m]))

Limitaciones del registro de VM

1. Instalación manual de Envoy: debe instalar y configurar manualmente el proxy Envoy en la VM
2. Conectividad de red: se requiere conexión de red entre la VM y el cluster de Kubernetes
3. Gestión de certificados: los certificados de cuenta de Service deben implementarse en la VM
4. Carga operativa: se requieren gestión y actualizaciones de la versión de Envoy en la VM
5. Limitación de autoescalado: no hay autoescalado como Kubernetes HPA

Ejemplo de uso práctico

Escenario: integración de una base de datos heredada

# 1. Define database service with ServiceEntry
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: legacy-postgres
  namespace: production
spec:
  hosts:
  - postgres.production.svc.cluster.local
  addresses:
  - 240.240.1.10  # Virtual IP
  ports:
  - number: 5432
    name: postgresql
    protocol: TCP
  location: MESH_INTERNAL
  resolution: STATIC
  workloadSelector:
    labels:
      app: postgres
      tier: database
---
# 2. Register VM instance with WorkloadEntry
apiVersion: networking.istio.io/v1
kind: WorkloadEntry
metadata:
  name: postgres-vm-1
  namespace: production
spec:
  address: 10.0.1.100  # Actual VM IP
  labels:
    app: postgres
    tier: database
    version: v13
  serviceAccount: postgres-sa
  ports:
    postgresql: 5432
---
# 3. Access control policy
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: postgres-access-control
  namespace: production
spec:
  selector:
    matchLabels:
      app: postgres
  action: ALLOW
  rules:
  - from:
    - source:
        namespaces: ["production"]
        principals: ["cluster.local/ns/production/sa/api-service"]
    to:
    - operation:
        ports: ["5432"]

Resultado:

• Los Pods de Kubernetes acceden a la base de datos mediante postgres.production.svc.cluster.local
• Cifrado mTLS automático entre la VM y los Pods
• Política de control de acceso aplicada
• Métricas y trazado distribuido recopilados automáticamente

Resumen de la comparación de registro de cargas de trabajo

Gracias a las capacidades flexibles de registro de cargas de trabajo de Istio:

• Kubernetes Pod: aplicaciones cloud-native
• Multi-Cluster: multinube, distribución regional, recuperación ante desastres
• Virtual Machine: aplicaciones heredadas, bases de datos, entornos híbridos

Todas las cargas de trabajo reciben funciones coherentes de seguridad, gestión de tráfico y observabilidad.

Próximos pasos

Ahora comprende los conceptos básicos de Istio. Aprenda a usarlos en la práctica mediante los siguientes documentos:

Funciones principales

1. Gestión de tráfico
   • Uso de Gateway y VirtualService
   • Definición de DestinationRule y subset
   • ServiceEntry y WorkloadEntry (registro de VM)
   • Patrones de enrutamiento avanzados (Canary, pruebas A/B)
   • Traffic Mirroring y Shadowing
2. Seguridad
   • Configuración de mTLS y PeerAuthentication
   • Autenticación (RequestAuthentication, JWT)
   • Autorización (AuthorizationPolicy)
   • Gestión de políticas de seguridad
   • Integración de autenticación externa
3. Observabilidad
   • Recopilación de métricas (Prometheus)
   • Trazado distribuido (Jaeger, Zipkin)
   • Configuración de registros
   • Visualización de service mesh de Kiali
   • Dashboards de Grafana
4. Resiliencia
   • Patrón Circuit Breaker
   • Configuración de Retry y Timeout
   • Rate Limiting
   • Outlier Detection
   • Pruebas de Fault Injection

Temas avanzados

5. Temas avanzados
   • Modo Ambient (malla sin sidecar)
   • Configuración Multi-Cluster
   • Personalización de EnvoyFilter
   • DNS Proxy y Caching
   • Configuración detallada de cargas de trabajo de VM
   • Desarrollo de plugins WASM

Referencias

• Documentación oficial de Istio - Conceptos
• Documentación oficial de Istio - Gestión de tráfico
• Documentación oficial de Istio - Seguridad
• Documentación oficial de Istio - Observabilidad
• Documentación oficial de Envoy Proxy