Istio es una capa de malla de servicios de código abierto configurable que conecta, supervisa y asegura los contenedores en un clúster de Kubernetes. Actualmente, Istio trabaja de forma nativa solamente con Kubernetes, pero su naturaleza de código abierto hace posible que cualquiera pueda escribir extensiones que le permitan a Istio ejecutarse en cualquier software de clúster. Hoy, nos centraremos en el uso de Istio con Kubernetes, su caso de uso más popular.

Kubernetes es una herramienta de orquestación de contenedores y una unidad central de Kubernetes es un nodo. Un nodo consta de uno o más contenedores, junto con sistemas de archivos u otros componentes. La arquitectura de microservicios podría tener una docena de nodos diferentes, cada uno de los cuales representa diferentes microservicios. Kubernetes gestiona la disponibilidad y el consumo de recursos de los nodos, añadiendo pods a la medida que aumenta la demanda con pod autoscaler. Istio inyecta contenedores adicionales en el pod para añadir seguridad, gestión y supervisión.

Debido a que es de código abierto, Istio puede ejecutarse en cualquier proveedor de nube pública que lo soporte y cualquier nube privada con administradores que así lo deseen.

El siguiente video explica más acerca de los conceptos básicos de Istio:

Cuando las organizaciones se trasladan a los microservicios, necesitan dar soporte a docenas o cientos de aplicaciones específicas. Gestionar esos puntos finales por separado significa admitir una gran cantidad de máquinas virtuales o VM, incluida la demanda. El software de clúster como Kubernetes puede crear pods y ampliarlos, pero Kubernetes no proporciona enrutamiento, reglas de tráfico o herramientas de supervisión o depuración sólidas.

Introduzca la malla de servicio.

A medida que aumenta el número de servicios, el número de formas potenciales de comunicar aumenta exponencialmente. Dos servicios solo tienen dos vías de comunicación. Tres servicios tienen seis, mientras que 10 servicios tienen 90. Una malla de servicio proporciona una única manera de configurar esas rutas  de comunicación creando una política para la comunicación.

Una malla de servicio instrumenta los servicios y dirige el tráfico de comunicaciones de acuerdo con una configuración predefinida. Esto significa que en lugar de configurar un contenedor en ejecución (o un código de escritura para hacerlo), un administrador puede proporcionar configuración a la malla de servicio y hacer que complete el trabajo. Anteriormente, esto siempre tenía que suceder con los servidores web y la comunicación de servicio a servicio.

La forma más común de hacerlo en un clúster es utilizar el patrón sidecar. Un sidecar es un nuevo contenedor, dentro del pod, que enruta y supervisa el tráfico de comunicaciones entre servicios y contenedores.

Como se mencionó anteriormente, Istio sobrepone capas en Kubernetes, agregando contenedores que son esencialmente invisibles para el programador y el administrador. Los llamados contenedores "sidecar" actúan como una "persona en medio", dirigiendo el tráfico y supervisando las interacciones entre los componentes. Los dos funcionan en combinación de tres formas: configuración, supervisión y gestión.

Configuración

El método principal para establecer la configuración con Kubernetes es el comando kubectl, comúnmente "kubectl -f", donde el archivo es un archivo YAML. Los usuarios de Istio pueden ejecutar nuevos y diferentes tipos de archivos YAML con kubectl o utilizar el nuevo comando opcional ioctl.

Supervisión

Con Istio, usted puede supervisar fácilmente el estado de sus aplicaciones que se ejecutan con Kubernetes. La instrumentación de Istio puede gestionar y visualizar el estado de las aplicaciones, proporcionando más insights que la supervisión general del clúster y los nodos que proporciona Kubernetes.

Gestión

Debido a que la interfaz para Istio es esencialmente la misma que Kubernetes, la gestión no requiere casi ningún trabajo adicional. De hecho, Istio permite al usuario crear políticas que impacten y gestionen todo el clúster de Kubernetes, reduciendo el tiempo para gestionar cada clúster mientras se elimina la necesidad de código de gestión personalizado.

Los principales beneficios de una malla de servicio incluyen funciones para mejorar la depuración, la supervisión, el enrutamiento, la seguridad y el aprovechamiento. Es decir, con Istio, se hará menos esfuerzo para gestionar un grupo más amplio de servicios.

Depuración mejorada

Digamos, por ejemplo, que un servicio tiene varias dependencias. El servicio pay_claim de una compañía de seguros llama al servicio deductible_amt, que llama al servicio is_member_covered, y así sucesivamente. Una cadena de dependencias compleja puede tener 10 o 12 llamadas de servicio. Cuando uno de esos 12 está fallando, habrá un conjunto en cascada de fallas que dan como resultado algún tipo de error 500, error 400, o posiblemente ninguna respuesta en absoluto.

Para depurar ese conjunto de llamadas, puede utilizar algo como un rastreo de lote. En el frontend, los desarrolladores del lado del cliente pueden ver qué elementos se extraen de los servidores web, en qué orden y examinarlos. Los programadores frontend pueden obtener un diagrama de cascada para ayudar en la depuración.

Lo que el ejemplo no muestra es lo que sucede al del centro de datos, cómo callback = parselLotamaAudiences llama a otros cuatro servicios web y cuáles responden más lentamente. Más tarde, veremos cómo Istio proporciona herramientas para rastrear llamadas de función en un diagrama muy parecido a este.

Seguimiento y observabilidad

Los equipos de DevOps y la administración de TI pueden desear supervisar el tráfico para ver la latencia, el tiempo en servicio, los errores como porcentaje del tráfico, etc. A menudo, requieren ver un panel de control. Un panel de control proporciona una visualización de la suma, del promedio o de esas métricas a lo largo del tiempo, tal vez con la capacidad de investigar en detalles un nodo, servicio o pod específico. Kubernetes no proporciona esta funcionalidad de forma nativa.

Política

De manera predeterminada, Kubernetes permite que cada pod envíe el tráfico a cualquier otro pod. Istio permite a los administradores crear una política para restringir qué servicios pueden funcionar entre sí. Así, por ejemplo, los servicios solo pueden llamar a otros servicios que son verdaderas dependencias. Otra política para mantener los servicios en alto es un límite de tasa, que impedirá que el exceso de tráfico obstruya un servicio y evitará ataques de denegación de servicio.

Enrutamiento y equilibrio de carga

De forma predeterminada, Kubernetes proporciona equilibrio de carga por turnos. Si hay seis pods que proporcionan un microservicio, Kubernetes proporcionará un equilibrador de carga, o "servicio", que envía solicitudes a cada pod en orden creciente, luego se iniciará de nuevo. Sin embargo, a veces una empresa implementará diferentes versiones del mismo servicio en producción.

El ejemplo más simple de esto puede ser una implementación azul/verde. En ese caso, el software puede crear una versión totalmente nueva de la aplicación en producción sin enviar usuarios de producción a la misma. Después de promocionar la nueva versión, la empresa puede mantener los servidores antiguos para hacer que la conmutación sea rápida en caso de fallo.

Con Istio, esto es tan sencillo como utilizar el etiquetado en un archivo de configuración. Los administradores también pueden utilizar etiquetas para indicar a qué tipo de servicio conectarse y crear reglas basadas en encabezados. Así, por ejemplo, los usuarios beta pueden dirigirse a un pod "canary" con la última y mejor compilación, mientras que los usuarios regulares van a la compilación de producción estable.

Interrupción

Si un servicio está sobrecargado o inactivo, las solicitudes adicionales fallarán mientras se continúa sobrecargando el sistema. Debido a que Istio está rastreando errores y retrasos, puede forzar una pausa, permitiendo que un servicio se recupere después de un número específico de solicitudes establecidas por la política. Puede hacer cumplir esta política en todo el clúster creando un pequeño archivo de texto e indicando a Istio que lo use como una nueva política.

Seguridad

Istio proporciona identidad, política y cifrado de forma predeterminada, junto con autenticación, autorización y auditoría (AAA). Cualquier pod bajo administración que se comunique con otros utilizará el tráfico cifrado, evitando cualquier observación. El servicio de identidad, combinado con el cifrado, asegura que ningún usuario no autorizado pueda falsificar o suplantar la identidad (spoof) de una llamada de servicio. AAA proporciona a los profesionales de seguridad y operaciones las herramientas que necesitan para supervisar, con menos costos generales.

Administración simplificada

Las aplicaciones tradicionales todavía necesitan las características de identificación, política y seguridad que ofrece Istio. Eso implica programadores y administradores trabajando en el nivel equivocado de abstracción, reimplementando las mismas reglas de seguridad una y otra vez para cada servicio. Istio les permite trabajar en el nivel correcto: establecer políticas para el clúster a través de un único panel de control.