¿Sidecar o ambient?
Un service mesh de Istio está dividido lógicamente en un data plane y un control plane.
El data plane es el conjunto de proxies que median y controlan toda la comunicación de red entre microservicios. También recopilan y reportan telemetría sobre todo el tráfico de la mesh.
El control plane gestiona y configura los proxies en el data plane.
Istio soporta dos modos de data plane principales:
- modo sidecar, que despliega un proxy Envoy junto con cada Pod que inicias en tu cluster, o ejecutándose junto a servicios ejecutándose en VMs.
- modo ambient, que usa un proxy capa 4 por nodo, y opcionalmente un proxy Envoy por Namespace para características de capa 7.
Puedes elegir que ciertos namespaces o workloads se ejecuten en cada modo.
Modo sidecar
Istio ha sido construido sobre el patrón sidecar desde su primer release en 2017. El modo sidecar está bien entendido y ha sido ampliamente probado en situaciones reales, pero viene con un costo de recursos y sobrecarga operacional.
- Cada aplicación que despliegues tiene un proxy Envoy inyectado como un sidecar
- Todos los proxies pueden procesar tanto capa 4 como capa 7
Modo ambient
Lanzado en 2022, el modo ambient fue construido para abordar las deficiencias reportadas por los usuarios del modo sidecar. A partir de Istio 1.22, está listo para producción para casos de uso de cluster único.
- Todo el tráfico es procesado a través de un proxy de nodo solo de capa 4
- Las aplicaciones pueden optar por enrutarse a través de un proxy Envoy para obtener características de capa 7
Elegir entre sidecar y ambient
Los usuarios a menudo despliegan un mesh para habilitar una postura de seguridad zero-trust como primer paso y luego habilitan selectivamente capacidades L7 según sea necesario. la mesh ambient permite a esos usuarios evitar completamente el costo del procesamiento L7 cuando no es necesario.
| Sidecar | Ambient | |
|---|---|---|
| Gestión de tráfico | Conjunto completo de características de Istio | Conjunto completo de características de Istio (requiere usar waypoint) |
| Seguridad | Conjunto completo de características de Istio | Conjunto completo de características de Istio: cifrado y autorización L4 en modo ambient. Requiere waypoints para autorización L7. |
| Observabilidad | Conjunto completo de características de Istio | Conjunto completo de características de Istio: telemetría L4 en modo ambient; observabilidad L7 al usar waypoint |
| Extensibilidad | Conjunto completo de características de Istio | A través de plugins WebAssembly (requiere usar waypoint) La API EnvoyFilter no es compatible. |
| Agregar workloads a la mesh | Etiqueta un namespace y reinicia todos los pods para que se agreguen sidecars | Etiqueta un namespace - no se requiere reinicio de pods |
| Despliegue incremental | Binario: el sidecar está inyectado o no lo está | Gradual: L4 siempre está activado, L7 puede ser agregado mediante configuración |
| Gestión del ciclo de vida | Proxies gestionados por el desarrollador de la aplicación | Administrador de la plataforma |
| Utilización de recursos | Desperdicio; los recursos de CPU y memoria deben ser provisionados para el peor caso de uso de cada pod individual | Los proxies waypoint pueden ser escalados automáticamente como cualquier otro despliegue de Kubernetes. Un workload con muchas réplicas puede usar un waypoint, en lugar de que cada uno tenga su propio sidecar. |
| Costo promedio de recursos | Grande | Pequeño |
| Latencia promedio (p90/p99) | 0.63ms-0.88ms | Ambient: 0.16ms-0.20ms Waypoint: 0.40ms-0.50ms |
| Pasos de procesamiento L7 | 2 (sidecar de origen y destino) | 1 (waypoint de destino) |
| Configuración a escala | Requiere configuración del alcance de cada sidecar para reducir la configuración | Funciona sin configuración personalizada |
| Soporta protocolos "server-first" | Requiere configuración | Sí |
| Soporte para Kubernetes Jobs | Complicado por la larga vida del sidecar | Transparente |
| Modelo de seguridad | Más fuerte: cada workload tiene sus propias claves | Fuerte: cada agente de nodo tiene solo las claves para los workloads en ese nodo |
| Pod de aplicación comprometido da acceso a claves de la mesh | Sí | No |
| Soporte | Estable, incluyendo multi-cluster | Estable, solo single-cluster |
| Plataformas compatibles | Kubernetes (cualquier CNI) Máquinas virtuales | Kubernetes (cualquier CNI) |
capa 4 vs capa 7 features
El sobrecosto para procesar protocolos en capa 7 es significativamente mayor que el procesamiento de paquetes en capa 4. Para un servicio dado, si tus requisitos pueden ser satisfechos en L4, la mesh de servicio puede ser entregada a un costo sustancialmente menor.
Security
| L4 | L7 | |
|---|---|---|
| Encryption | Toda la comunicación entre pods está cifrada usando mTLS. | N/A—la identidad del servicio en Istio está basada en TLS. |
| Autenticación de servicio a servicio | SPIFFE, a través de certificados mTLS. Istio emite un certificado X.509 corto que codifica la identidad de la cuenta de servicio del pod. | N/A—la identidad del servicio en Istio está basada en TLS. |
| Autorización de servicio a servicio | Autorización basada en red, más políticas de identidad, por ejemplo:
| Política completa, por ejemplo:
|
| Autenticación de usuario final | N/A—no podemos aplicar configuraciones por usuario. | Autenticación local de JWTs, soporte para autenticación remota a través de flujos OAuth y OIDC. |
| Autorización de usuario final | N/A—ver arriba. | Las políticas de servicio a servicio pueden ser extendidas para requerir credenciales de usuario final con ámbitos específicos, emisores, principal, audiencias, etc. La implementación completa de acceso usuario a recurso puede ser realizada usando autorización externa, permitiendo políticas por solicitud con decisiones de un servicio externo, por ejemplo OPA. |
Observability
| L4 | L7 | |
|---|---|---|
| Logging | Información de red básica: 5-tupla de red, bytes enviados/recibidos, etc. Ver documentación de Envoy. | Logging de metadatos de solicitud completo, además de la información de red básica. |
| Tracing | No hoy; posiblemente en el futuro con HBONE. | Envoy participa en el seguimiento distribuido. Ver resumen de Istio sobre el seguimiento. |
| Metrics | Solo TCP (bytes enviados/recibidos, número de paquetes, etc.). | Métricas RED L7: tasa de solicitudes, tasa de errores, duración de la solicitud (latencia). |
Traffic management
| L4 | L7 | |
|---|---|---|
| Load balancing | Solo a nivel de conexión. Ver tarea de desplazamiento de tráfico TCP. | Por solicitud, habilitando, por ejemplo, implementaciones de canary, tráfico gRPC, etc. Ver tarea de desplazamiento de tráfico HTTP. |
| Circuit breaking | Solo TCP. | Configuraciones HTTP además de TCP. |
| Detección de outliers | En el establecimiento/fallo de la conexión. | En éxito/fallo de la solicitud. |
| Rate limiting | Rate limit en datos de conexión L4, en el establecimiento de la conexión, con opciones de rate limiting global y local. | Rate limit en metadatos de solicitud L7, por solicitud. |
| Timeouts | Solo establecimiento de conexión (la configuración de keep-alive de la conexión se configura a través de las configuraciones de circuit breaking). | Por solicitud. |
| Retries | Retry establecimiento de conexión | Retry fallo de solicitud. |
| Inyección de fallos | N/A—la inyección de fallos no puede ser configurada en conexiones TCP. | Fallas completas de aplicación y de conexión (timeouts, delays, códigos de respuesta específicos). |
| Traffic mirroring | N/A—solo HTTP | Mirroring porcentual de solicitudes a múltiples backends. |
Unsupported features
Las siguientes features están disponibles en modo sidecar, pero aún no implementadas en modo ambient:
- Interoperabilidad sidecar-waypoint
- Instalaciones multi-cluster
- Soporte multi-red
- Soporte de VM