Ilustración de evv en Shutterstock
Istio Ambient Mesh se presentó en septiembre de 2022, pero en su momento no le presté demasiada atención. Sin embargo, para quienes ya usan Istio como service mesh o piensan hacerlo, esta novedad busca resolver algunas de las limitaciones del modelo tradicional con sidecar, que repasaremos en las siguientes secciones de este blog.
Nota: Istio Ambient Mesh todavía está en alpha y no debería usarse en entornos de producción hasta que alcance General Availability (GA).
Antes de profundizar, conviene cubrir algunos conceptos básicos; sin ellos, el resto del artículo bien podría estar escrito en jeroglíficos.
¿Qué es un Service Mesh?
Muchas aplicaciones modernas se construyen sobre un esquema de microservicios distribuidos, donde cada microservicio cumple una función específica y suele comunicarse con los demás. A falta de mejor analogía, imagínalo como bloques modulares de Lego que se ensamblan para armar una estatua, en lugar de una estatua monolítica tallada en piedra.
Un service mesh es una capa que se suma sobre estas aplicaciones (o microservicios) y suma funciones como gestión de tráfico, observabilidad y seguridad sin necesidad de modificar las aplicaciones en sí.
Funciones de Istio Service Mesh
Istio es un service mesh de código abierto que se integra de forma transparente sobre aplicaciones distribuidas existentes. El modo de comunicación por defecto entre servicios dentro de un cluster es texto plano, lo cual no es ideal a nivel de seguridad. Istio service mesh protege ese tráfico cifrando las comunicaciones con mTLS (mutual TLS). También ofrece funciones adicionales, entre ellas:
- Balanceo de carga para HTTP, gRPC, WebSocket y TCP
- Control granular del tráfico
- Controles de acceso, rate limits y cuotas
- Service discovery
- Observabilidad total (métricas y datos de telemetría, logs y trazas de todo el tráfico dentro de un cluster)
Ahora que tenemos claro qué es un service mesh y los beneficios que aporta, comparemos el modelo tradicional con sidecar de Istio con el nuevo modelo Ambient Mesh.
Arquitectura de Istio sin Ambient Mesh
Istio tiene 2 componentes fundamentales: un Control Plane y un Data Plane.
El Data Plane representa las comunicaciones entre los servicios del mesh. El service mesh utiliza un proxy Envoy desplegado junto a cada servicio (como sidecar), y todo el tráfico entrante y saliente del mesh pasa por estos proxies Envoy.
El Control Plane recolecta datos de esos proxies, define y controla su configuración reconciliando el estado actual del entorno con el estado deseado.
fuente: https://istio.io/latest/docs/ops/deployment/architecture/
Inconvenientes de este modelo:
- Resiliencia: aplicar cambios como actualizar los proxies desde el control plane obliga a reiniciar cada contenedor sidecar, algo que puede resultar disruptivo.
- Alto consumo de recursos: los recursos para los sidecars deben reservarse pensando en el peor escenario de uso, lo cual es ineficiente y suele incomodar a quien gestiona la facturación.
- Tráfico que se rompe: especialmente al lidiar con aplicaciones que tienen implementaciones HTTP no conformes.
El sidecar realiza procesamiento de tráfico tanto en Layer 4 como en Layer 7. Un problema notable es que el procesamiento L7 demanda muchísimo cómputo y termina imponiéndose a los servicios incluso cuando solo necesitan seguridad de transporte simple. Además, la mayoría de los Common Vulnerabilities and Exposures (CVEs) críticos del proxy Envoy ocurren en la capa L7, así que se genera una superficie de ataque mayor cuando se carga con filtrado L7 a servicios que no lo requieren.
Arquitectura de Istio con Ambient Mesh
Istio Ambient Mesh introduce cambios radicales en la arquitectura del Data Plane. Este modelo separa las funcionalidades L4 y L7 que con los sidecars venían como un paquete de "todo o nada".
fuente: https://istio.io/v1.15/blog/2022/introducing-ambient-mesh/#slicing-the-layers
En lugar de sidecars, ahora contamos con una capa segura creada por ztunnels (zero-trust tunnels). Estos ztunnels actúan como agentes compartidos y se despliegan como un DaemonSet, es decir, hay un agente por nodo en el cluster de Kubernetes.
El ztunnel utiliza un programa eBPF compilado dentro del componente istio-cni para enrutar el tráfico. Esto aporta varios beneficios de rendimiento y flexibilidad frente al uso de iptables.
Cada ztunnel se encarga de proteger el tráfico L4 de los workloads dentro de su nodo.
Para las funciones L7, ambient mesh te permite desplegar waypoint proxies basados en Envoy que se aplican a nivel de namespace, de modo que los workloads dentro de ese namespace puedan aprovechar toda la gama de funciones de Istio.
fuente: https://istio.io/v1.15/blog/2022/introducing-ambient-mesh/#slicing-the-layers
Estos waypoint proxies escalan según la demanda real de los workloads del namespace en el que operan. Resulta mucho más eficiente y económico que reservar recursos para sidecars con base en el peor escenario de uso.
Esta arquitectura habilita por diseño un uso más ergonómico y rentable del service mesh de Istio: los proxies L7 solo se aplican donde se necesitan, aprovechan los recursos de manera más eficiente y escalan de forma más dinámica e independiente.
Además, mantiene la interoperabilidad con el modelo tradicional con sidecar, así que tienes flexibilidad para elegir.
Hay 2 inquietudes sobre este nuevo modelo de data plane que no abordaré directamente aquí:
- Rendimiento (por los saltos adicionales):
Istio afirma que, sin el filtrado L7 redundante en ambos sentidos del modelo con sidecar, la degradación de rendimiento esperada en el ambient mesh por el salto extra quedará más que compensada. También publicarán una entrada de blog dedicada al rendimiento, presumiblemente en colaboración con Solo.io y Google, con quienes han trabajado en este avance. 2. Seguridad (por el modelo de agente compartido):
A quienes les preocupen las implicaciones de seguridad de un Data Plane sin sidecars, les recomiendo revisar el blog Ambient Mesh Security Deep Dive.
Tengo muchas ganas de ver Ambient Mesh corriendo en un entorno de producción; promete generar un ahorro de costos y una eficiencia significativos a quienes lo aprovechen.
Sin embargo, al final del día, da la sensación de que el elefante en la habitación sigue muy presente y se le sigue ignorando: el proxy Envoy.
No creo que los sidecars desaparezcan pronto, pero quizás algún día tengamos un software de procesamiento L7 ligero, seguro y potente a la vez, que sea la panacea para los males de cualquier usuario de service mesh. Hasta entonces, agradezco cada paso en esa dirección, y tú también deberías hacerlo.