Diagrama de arquitectura de service mesh: data plane, control plane y mTLS

Cuando un sistema tiene decenas de servicios, el mismo código de red aparece en todos ellos: reintentos, timeouts, TLS entre servicios, métricas por llamada, división del tráfico para los lanzamientos. Un service mesh saca ese código de los servicios y lo lleva a la ruta de red, donde un solo equipo puede configurarlo para todos.

Este artículo explica cómo se construye un mesh, qué hacen el control plane y el data plane, cómo funciona el mTLS automático y los costes que hacen de un mesh la elección equivocada para muchos equipos. El diagrama muestra el diseño clásico con sidecars.

Data plane y control plane

El data plane es un conjunto de proxies que se sitúan en la ruta de cada petición entre servicios. En el modelo sidecar, cada pod recibe su propio contenedor de proxy. La aplicación habla HTTP simple con su proxy local; el proxy se encarga de todo lo que va por la red: cifrado, reintentos, balanceo de carga, métricas. Istio usa Envoy como sidecar; Linkerd usa su propio proxy, creado para ese fin y escrito en Rust.

El control plane nunca toca el tráfico de peticiones. Vigila los servicios y endpoints del clúster, convierte tus políticas en configuración de proxy, envía esa configuración a cada proxy y emite los certificados con los que los proxies se identifican. En Istio es istiod; consulta la página de arquitectura de Istio. La referencia de arquitectura de Linkerd describe las piezas equivalentes.

mTLS automático e identidad de las cargas de trabajo

El TLS mutuo entre cada par de servicios es la función que convence a la mayoría de los equipos. Cada proxy recibe del control plane un certificado de corta duración que nombra la carga de trabajo, normalmente como un ID de SPIFFE derivado del namespace y la service account de Kubernetes, como spiffe://cluster.local/ns/shop/sa/orders. Cuando dos proxies se conectan, ambos presentan certificados, ambos los verifican y la conexión queda cifrada.

Dos consecuencias importan:

• La identidad sustituye a la ubicación en la red. Una política puede decir «payments solo acepta llamadas de la service account de orders», que es más fuerte que «desde esta subred».
• La rotación es automática. Los certificados duran unas horas y nadie abre un ticket para renovarlos.

Activa el modo estricto cuando todo esté dentro del mesh, para que las conexiones en texto plano se rechacen en lugar de aceptarse en silencio.

Una petición a través del mesh

Sigue una llamada de orders a payments:

1. La aplicación orders envía una petición HTTP simple al nombre del servicio payments. La redirección de tráfico la envía al sidecar local en lugar de a la red.
2. El sidecar de orders busca endpoints sanos de payments en la configuración que envió el control plane, elige uno con su algoritmo de balanceo y aplica el timeout de esa ruta.
3. Abre, o reutiliza, una conexión mTLS con el sidecar de payments, presentando el certificado de orders.
4. El sidecar de payments verifica el certificado, comprueba la política de autorización (¿puede orders llamar a payments?) y reenvía la petición a la aplicación payments por localhost.
5. Ambos sidecars registran la petición, su estado y su latencia. Si la llamada falla con un estado reintentable, el sidecar de orders puede reintentar dentro de su presupuesto.

Ninguna de las dos aplicaciones sabe que ha pasado nada de esto, y esa es la idea y también el riesgo: el comportamiento que no se ve en el código tiene que verse en otro sitio, por ejemplo en el diagrama.

Implantar un mesh

Adóptalo por pasos. Instala el control plane, añade los servicios namespace a namespace en modo permisivo para que el texto plano siga funcionando, vigila las métricas y luego pasa cada namespace a mTLS estricto. Añade las políticas de autorización al final, empezando por los servicios que guardan datos sensibles.

Políticas de tráfico

Como cada llamada pasa por un proxy, el mesh puede aplicar las mismas reglas en todas partes:

• Timeouts y reintentos, con presupuestos para que los reintentos no se multipliquen durante una caída.
• Circuit breaking y outlier detection: dejar de enviar tráfico a las instancias que fallan una y otra vez.
• División del tráfico por peso o por cabecera, que es como se implementan los despliegues canary en un mesh.
• Inyección de fallos para pruebas: añadir retardos o errores a un porcentaje de las llamadas.

Cuidado con los reintentos en dos sitios. Si la aplicación reintenta y el sidecar también, una llamada fallida se convierte en muchas. Elige un único responsable de los reintentos y déjalo por escrito.

Observabilidad (casi) gratis

Los proxies reportan el número de peticiones, las tasas de error y la latencia por origen y destino, sin cambiar las aplicaciones. También pueden iniciar y propagar spans de traza, pero la aplicación aún debe pasar las cabeceras de traza de las peticiones entrantes a las salientes; si no, las trazas se rompen en cada servicio.

Sidecars vs. modo ambient

Los sidecars tienen costes reales: un proxy en cada pod consume CPU y memoria, añade latencia a cada salto y complica el arranque de los pods y las actualizaciones. El modo ambient de Istio elimina el sidecar por pod. Un proxy por nodo llamado ztunnel se encarga del mTLS y de las políticas de capa 4, y unos proxies waypoint opcionales se encargan de las funciones de capa 7 solo para los servicios que las necesitan. A cambio, hay un modelo operativo distinto y menos años de historial en producción que con los sidecars.

El diagrama de arquitectura

Cómo leerlo:

• Izquierda: el ingress gateway recibe el tráfico externo y abre una conexión mTLS con el sidecar del pod de orders.
• Centro: dentro de cada pod, el sidecar reenvía a la aplicación por localhost. El sidecar de orders llama por mTLS a los sidecars de payments e inventory; las aplicaciones nunca manejan certificados.
• Abajo: el control plane envía configuración y certificados a los proxies (aristas discontinuas). No está en la ruta de las peticiones.
• Derecha: los sidecars reportan métricas y trazas (punteadas). El bloque Markdown muestra una política para payments: quién puede llamarlo, timeouts y reintentos, expulsión de instancias anómalas y mTLS estricto.

Cuándo no usar un mesh

• Un puñado de servicios, o un monolito con unos pocos satélites. Una biblioteca o un API gateway cubren las necesidades por una fracción del coste.
• Ningún equipo que se haga cargo. Un mesh es infraestructura que necesita actualizaciones, habilidades de depuración y experiencia en guardias.
• Cuando el objetivo principal es solo el cifrado. Muchas nubes y plugins CNI pueden cifrar el tráfico entre pods sin un mesh completo.

Qué poner en un diagrama de mesh

• Los dos planos, bien separados, con el control plane fuera de la ruta de las peticiones.
• Dónde empieza y termina TLS: de proxy a proxy, y HTTP simple en localhost.
• Las identidades, al menos de los servicios con políticas de acceso.
• Las políticas que cambian el comportamiento: timeouts, reintentos, circuit breaking.

El diagrama de arquitectura de Kubernetes muestra el clúster en el que corre el mesh, el diagrama de arquitectura zero trust explica por qué importan las políticas basadas en la identidad y el diagrama de arquitectura de microservicios trata los propios servicios.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Añade un Contenedor del pack Modelo C4 para el ingress gateway.
3. Para cada pod, añade un Marco del pack Básico con un Componente para el sidecar y un Contenedor para la aplicación dentro.
4. Añade un Contenedor para el control plane y Métricas del pack DevOps.
5. Dibuja aristas mTLS entre los sidecars, aristas discontinuas desde el control plane y aristas de telemetría punteadas, y añade un bloque Markdown del pack Básico con la política de un servicio.

El ejemplo usa 13 nodos de diagrama, dentro del plan Free.

Preguntas frecuentes

¿Qué diferencia hay entre un service mesh y un API gateway? Un API gateway gestiona el tráfico que entra en el sistema desde fuera. Un service mesh gestiona el tráfico entre los servicios de dentro. Muchos sistemas usan ambos.

¿Un service mesh añade latencia? Sí, cada salto por un proxy añade un poco, normalmente muy por debajo de unos pocos milisegundos por salto, además de CPU y memoria para los proxies. Mídelo con tu tráfico.

¿Tengo que cambiar el código de mi aplicación para usar un mesh? En general, no. La excepción es el tracing: las aplicaciones deben pasar las cabeceras de traza para que las trazas se conecten entre servicios.

¿Qué es el modo ambient? Un data plane de Istio sin sidecars: un proxy por nodo se encarga del mTLS y de la capa 4, y unos proxies waypoint opcionales se encargan de las funciones de capa 7 donde hagan falta.

¿Quién debe hacerse cargo del mesh? Un equipo de plataforma. Los equipos de servicios usan sus funciones mediante políticas, pero alguien tiene que actualizarlo, monitorizarlo y depurarlo.

Empieza gratis — un puesto, sin tarjeta de crédito.