Una malla de servicios resuelve tres problemas y te cuesta un operador

La forma habitual en que llega una malla de servicios es que alguien necesita reparto ponderado de tráfico para un canario, instala Istio un viernes y el lunes el equipo de plataforma es dueño de un plano de control, una autoridad de certificación, un inyector de sidecars y una clase nueva de incidente en la que un pod está sano pero no puede hablar con nada porque el proxy arrancó después que la aplicación.

Eso no es un argumento contra las mallas. Es un argumento a favor de saber cuál de los tres problemas estás comprando, porque una malla no es una funcionalidad que activas. Es una pieza de infraestructura con una guardia asociada.

Los tres problemas, y solo estos tres

Tráfico cifrado y autenticado entre servicios. Cada pod recibe un certificado de carga de trabajo de vida corta, los proxies negocian TLS mutuo y la identidad pasa a ser algo sobre lo que puedes escribir política: la cuenta de servicio de pagos puede llamar al servicio de contabilidad en este puerto y a nada más. Sin malla, o terminas TLS en cada aplicación, en cada lenguaje, con el manejo de certificados propio de cada equipo, o aceptas texto plano dentro del clúster y confías en la política de red para vallarlo. La versión con malla es la única que te da una identidad criptográfica en vez de una dirección IP, lo que importa en cuanto un auditor pregunta cómo aplicas la autorización entre servicios.

Control de tráfico con granularidad de petición. Reparto por pesos, encaminamiento por cabecera, reintentos con presupuesto, tiempos de espera, cortocircuitos e inyección de fallos. Los Services de Kubernetes te dan reparto por turnos sobre los destinos listos y nada más. Si quieres un cinco por ciento del tráfico en una versión nueva, o todo el tráfico de usuarios con una cabecera de prueba en una compilación de vista previa, esa lógica tiene que vivir en algún sitio. Una malla la pone en configuración en vez de en una librería que todos los servicios tienen que importar.

Telemetría uniforme. Cada salto produce las mismas cuatro señales de oro con los mismos nombres de etiqueta, tanto si el servicio está en Go, en Java o es un binario de un proveedor que no puedes instrumentar. Es el beneficio que los equipos infravaloran antes de tenerlo y al que se niegan a renunciar después, porque es lo que hace que el grafo de dependencias sea honesto.

Fíjate en lo que no está en la lista. Una malla no arregla una base de datos lenta, no sustituye a un controlador de entrada y no te regala trazas distribuidas: los proxies propagan las cabeceras de traza, pero la aplicación sigue teniendo que reenviarlas a través de sus propias llamadas internas o tus trazas salen como tramos sueltos y desconectados.

Elegir una

Istio en modo ambiente es donde el proyecto ha puesto su esfuerzo reciente, y cambia el cálculo. En lugar de un sidecar por pod, un componente por nodo se encarga del TLS mutuo y de la autorización de nivel cuatro, y solo despliegas un proxy intermedio en los namespaces que necesitan funciones de nivel siete. El cifrado y la identidad en toda la malla dejan de costar un contenedor por carga de trabajo. El modo sidecar sigue existiendo y sigue siendo el camino más completo en funcionalidades, pero si empiezas ahora, empieza en modo ambiente y añade proxies intermedios donde necesites encaminamiento.

Linkerd es la elección cuando quieres los tres problemas resueltos y nada más en la carta. Su proxy es pequeño, los valores por defecto son sensatos, el TLS mutuo está activo desde la instalación y la superficie operativa es genuinamente menor. El precio es un conjunto de funciones más estrecho y un modelo de licencia que conviene leer antes de comprometerse: las versiones estables se distribuyen con condiciones distintas del antiguo modelo completamente abierto, así que comprueba qué aplica a tu organización.

Cilium tiene sentido cuando ya es tu complemento de red. Obtienes política basada en identidad y buena parte de la observabilidad desde eBPF en el camino de datos, con Envoy insertado solo donde hace falta nivel siete. Un componente en vez de dos, y ningún segundo sistema de identidad. Si ya ejecutas Cilium para la red, evalúa sus funciones de malla antes de instalar nada más.

Lo que cuesta

Sé honesto con los números, y mídelos tú en vez de fiarte del blog de un banco de pruebas.

Latencia: un sidecar añade un salto a cada lado de una llamada. Pocos milisegundos en el percentil noventa y nueve con un Envoy bien ajustado, por debajo del milisegundo con el proxy de Linkerd, prácticamente eliminado en nivel cuatro con el modo ambiente o con eBPF. Para una petición que ya tarda doscientos milisegundos esto es ruido. Para una llamada interna en una cadena de doce, no.

Recursos: el modo sidecar significa un contenedor de proxy por pod, y en un clúster con mil pods eso es memoria real y margen real de petición de CPU, más un aumento proporcional de lo que el plano de control tiene que empujar. Las arquitecturas por nodo lo amortizan.

Operación: esta es la que muerde de verdad. Rotación de certificados, actualizaciones del plano de control que hay que secuenciar contra las del plano de datos, orden de arranque de los sidecars y el impuesto de depuración de un proxy extra en todos los caminos. Presupuesta un dueño con nombre, no una tarde suelta.

Las alternativas baratas que cubren dos de los tres

Antes de instalar nada, comprueba si ya tienes suficiente:

• Gateway API con una implementación que admita reparto de tráfico te da encaminamiento ponderado en el borde, que es lo que la mayoría de los canarios necesitan en realidad. Argo Rollouts y Flagger lo manejan directamente, sin malla.
• NetworkPolicy te da segmentación de nivel tres y cuatro. No es identidad, pero corta el problema de la red plana.
• Una librería de instrumentación compartida más el colector de OpenTelemetry te da telemetría uniforme si controlas todos los servicios y están en uno o dos lenguajes.
• Cifrado entre nodos desde tu complemento de red cubre el tráfico en el cable sin identidad por carga de trabajo, que puede ser exactamente lo que dice tu requisito de cumplimiento.

Si esas tres te cubren, has resuelto dos de los problemas por una fracción del coste operativo.

Lo que se olvida

• El proxy tiene que arrancar antes que la aplicación. Los contenedores sidecar nativos de las versiones modernas de Kubernetes arreglan el orden de arranque y de parada que antes rompía trabajos y contenedores de inicialización. Si vas en modo sidecar, úsalos.
• Los reintentos multiplican la carga. Un reintento a nivel de malla en cada salto de una cadena de cinco servicios convierte una petición del cliente en decenas durante una caída parcial. Pon presupuestos de reintento, no números de reintentos.
• El TLS mutuo en modo permisivo no es TLS mutuo. Casi todas las instalaciones empiezan en permisivo para que no se rompa nada, y después nadie vuelve a ponerlo en estricto. Sigue como métrica el porcentaje de namespaces en modo estricto.
• Multiclúster es otro proyecto. Una malla entre clústeres implica federación de dominios de confianza, descubrimiento de destinos y un radio de impacto mucho mayor. No lo trates como una opción de configuración.
• La salida suele ser el requisito real de auditoría. Controlar a qué hosts externos puede llegar una carga es una capacidad de malla por la que se instala una malla y que después nunca se configura.

Cuándo la respuesta es no

Menos de unos veinte servicios, un lenguaje, un clúster, ningún requisito normativo de cifrado dentro del clúster y ningún equipo que fuera a ser dueño de la malla: no instales ninguna. Vas a pagar el coste operativo completo por la fracción del beneficio que puedes usar, y el primer incidente lo causará aquello que instalaste para prevenir incidentes. Lo miramos explícitamente cuando dimensionamos una plataforma en un proyecto cloud, y la recomendación es con frecuencia esperar.

Qué hacer esta semana

Lista tus servicios y marca cada uno según si termina TLS internamente, si emite las mismas métricas de petición que sus vecinos y si necesita control ponderado de tráfico. Si la tercera columna está vacía y la segunda es mayoritariamente que sí, todavía no tienes un problema de malla. Guarda el fichero; es el argumento de negocio en cualquiera de los dos sentidos.