Istio añade gestión de tráfico, seguridad y observabilidad a un conjunto de microservicios sin tocar su código. Eso solo es posible por cómo se reparten el trabajo sus dos mitades: un plano de datos que realmente gestiona el tráfico y un plano de control que le dice al plano de datos qué hacer. Esta guía cubre ambos y el modelo de sidecar que los conecta con tus cargas de trabajo.

El sidecar: un proxy que viaja junto a tu contenedor

En el modo predeterminado de Istio, a cada Pod de carga de trabajo se le inyecta un segundo contenedor junto al de tu aplicación: un proxy Envoy, configurado para interceptar todo el tráfico entrante y saliente de ese Pod. Tu aplicación sigue enlazándose a su puerto y haciendo llamadas salientes exactamente como si nada fuera diferente; el sidecar se sitúa de forma transparente en la ruta, que es todo el objetivo. La aplicación nunca necesita saber que el proxy está ahí.

Lo que esto aporta: TLS, reintentos, timeouts, balanceo de carga y autorización salen del código de la aplicación y pasan a ser configuración aplicada al proxy. Un equipo de desarrollo escribe lógica de negocio; la malla gestiona las preocupaciones de red de manera uniforme en todos los servicios, en lugar de que cada equipo reimplemente (u olvide implementar) su propia versión de las mismas.

El plano de datos: Envoy, haciendo el trabajo real

El plano de datos es el conjunto de todos esos proxies sidecar, que transportan realmente cada petición entre servicios. Aquí es donde se cifra el tráfico, donde se reintenta una petición tras un timeout, donde una versión de un servicio podría recibir el 10% del tráfico en un despliegue canary. El plano de datos no decide la política por sí mismo; aplica la configuración que el plano de control le ha enviado.

El plano de control: istiod

istiod es el plano de control de Istio, que se ejecuta como su propio conjunto de Pods en el namespace istio-system. Hace tres trabajos distintos:

• Distribución de configuración. Expresas tu intención en los propios recursos de Kubernetes de Istio, como “reparte el tráfico 90/10 entre estas dos versiones”. istiod lo traduce al formato de configuración nativo de Envoy y lo envía a cada sidecar relevante, de modo que nunca escribes a mano configuración de Envoy directamente (la serie “Learn” sobre Envoy de esta biblioteca cubre cómo es realmente esa configuración subyacente, para quien tenga curiosidad por lo que genera istiod).
• Autoridad de certificación. istiod emite y rota los certificados que usa cada sidecar para el TLS mutuo, de modo que el tráfico entre servicios se cifra y cada lado puede verificar la identidad del otro, sin que ningún código de aplicación gestione certificados por sí mismo.
• Descubrimiento de servicios y políticas. istiod rastrea qué servicios existen y dónde, y distribuye la política de autenticación y autorización a los proxies que necesitan aplicarla.

Inyección de sidecars: cómo obtiene realmente un Pod su proxy

Instalar Istio por sí solo no cambia nada de tus cargas de trabajo en ejecución. La inyección de sidecars es un paso aparte y explícito: etiqueta un namespace (istio-injection=enabled) y cualquier Pod creado en ese namespace después obtiene automáticamente un sidecar Envoy añadido a su especificación en el momento de la creación. Los Pods existentes no se modifican retroactivamente; necesitan recrearse (eliminarlos y volver a aplicarlos, o renovarlos mediante un Deployment) después de que la etiqueta esté en su sitio antes de recoger el sidecar.

Este diseño de adhesión voluntaria por namespace es deliberado. Incluir automáticamente en la malla todos los namespaces de un clúster, incluidos los namespaces del sistema que nunca estuvieron pensados para ejecutar un sidecar, añadiría sobrecarga de recursos y complejidad que nadie pidió. Etiquetar te da control sobre exactamente qué cargas de trabajo están en la malla.

Un Pod con su sidecar muestra dos contenedores donde uno equivalente sin malla muestra uno:

kubectl get pods
# NAME                READY   STATUS
# reviews-v1-abc123   2/2     Running   ← sidecar presente
# ratings-v1-def456   1/1     Running   ← sin sidecar (namespace sin etiquetar)

Para una carga de trabajo que necesita un sidecar sin etiquetar todo su namespace, la inyección manual (istioctl kube-inject) añade el sidecar a un solo manifiesto antes de aplicarlo, lo que se cubre en la siguiente guía junto con el resto de la instalación.

Una nota sobre el modo ambient

Todo lo anterior describe la arquitectura original de Istio basada en sidecars, que es lo que cubre el resto de esta serie. Istio también ofrece una alternativa sin sidecars, el modo ambient, que divide el plano de datos en un componente por nodo (ztunnel) y un proxy waypoint por namespace en lugar de inyectar un proxy en cada Pod, con el objetivo de reducir la sobrecarga de recursos de ejecutar un Envoy por carga de trabajo. Es una diferencia arquitectónica lo bastante sustancial como para quedar fuera del alcance de esta serie; lo que aprendas aquí sobre gestión de tráfico y conceptos de seguridad sigue aplicándose conceptualmente bajo el modo ambient, pero la mecánica de cómo se intercepta el tráfico difiere. Consulta la propia documentación de Istio si el modo ambient es específicamente lo que estás evaluando.