Istio
Istio es una malla de servicios de código abierto que proporciona una plataforma integrada transparente para que los desarrolladores administren, aseguren y obs...
Istio es una plataforma de malla de servicios de código abierto que proporciona una forma transparente de asegurar, conectar y monitorizar servicios. Está diseñado para gestionar la complejidad de las arquitecturas de microservicios abstrayendo la capa de red. Istio se ejecuta típicamente como un conjunto de microservicios desplegados dentro de un clúster de Kubernetes. Su arquitectura consta de dos componentes principales: el Plano de Control y el Plano de Datos. El Plano de Control (por ejemplo, Pilot, Citadel, Galley) gestiona y configura los proxies en el Plano de Datos. El Plano de Datos consta de proxies Envoy desplegados como sidecars junto a cada instancia de servicio. Estos proxies Envoy interceptan todo el tráfico de red entre servicios, aplicando políticas y recopilando telemetría. Las características clave incluyen la gestión del tráfico (por ejemplo, enrutamiento, balanceo de carga, inyección de fallos), seguridad (por ejemplo, autenticación mTLS, políticas de autorización) y observabilidad (por ejemplo, métricas, logs, rastreo distribuido). Las contrapartidas implican la introducción de complejidad operativa y sobrecarga de recursos debido a los proxies sidecar, pero esto a menudo se compensa con los beneficios significativos en la gestión de sistemas distribuidos. Istio permite a los desarrolladores centrarse en la lógica de negocio en lugar de las preocupaciones de red, proporcionando capacidades avanzadas como despliegues canarios, pruebas A/B y patrones de resiliencia listos para usar.
graph LR
Center["Istio"]:::main
Rel_advanced_propulsion_systems["advanced-propulsion-systems"]:::related -.-> Center
click Rel_advanced_propulsion_systems "/terms/advanced-propulsion-systems"
Rel_microservices["microservices"]:::related -.-> Center
click Rel_microservices "/terms/microservices"
Rel_service_mesh["service-mesh"]:::related -.-> Center
click Rel_service_mesh "/terms/service-mesh"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧠 Prueba de conocimiento
🧒 Explícalo como si tuviera 5 años
Es como un controlador de tráfico súper inteligente para todas las diferentes aplicaciones que se ejecutan en tu sistema informático, asegurándose de que se comuniquen entre sí de forma segura, eficiente y sin perderse.
🤓 Expert Deep Dive
La arquitectura de Istio aprovecha los proxies Envoy como sidecars, inyectándolos en los pods de las aplicaciones para interceptar y gestionar todo el tráfico entrante y saliente. El Plano de Control, históricamente compuesto por Pilot (gestión de tráfico), Citadel (seguridad) y Galley (validación de configuración), ha evolucionado con componentes como istiod que consolidan muchas funciones. Pilot configura los proxies Envoy a través de la API xDS (Servicio de Descubrimiento), permitiendo el enrutamiento dinámico, el balanceo de carga y la inyección de fallos. Citadel proporciona una fuerte autenticación y autorización de servicio a servicio utilizando identidades SPIFFE/SPIRE y gestiona la rotación de certificados. Galley se encarga de la ingesta y validación de la configuración. Las contrapartidas incluyen la significativa sobrecarga de recursos (CPU/memoria) de ejecutar sidecars Envoy para cada instancia de servicio y la latencia adicional introducida por el salto de red extra. Las vulnerabilidades pueden surgir de configuraciones erróneas en las políticas de autorización, posibles explotaciones en el propio proxy Envoy o problemas dentro de los componentes del plano de control de Istio. Garantizar la aplicación coherente de políticas en un entorno dinámico de microservicios es un desafío clave.