Istio es una capa de servicios en malla de código abierto configurable que conecta, supervisa y protege los contenedores en un clúster de Kubernetes. En este proyecto, Istio trabaja de forma nativa solamente con Kubernetes, pero su naturaleza de código abierto hace posible que cualquier usuario pueda escribir extensiones para habilitar la ejecución de Istio 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 un nodo es una unidad central de Kubernetes. Un nodo consta de uno o más contenedores, junto con sistemas de archivos u otros componentes. Una arquitectura de microservicios puede tener una docena de nodos diferentes, y cada uno de ellos representa diferentes microservicios. Kubernetes gestiona la disponibilidad y el consumo de recursos de los nodos, y añade pods a medida que aumenta la demanda con Pod Autoscaler. Istio inyecta contenedores adicionales en el pod para incrementar la seguridad, la gestión y la supervisión.

Al ser de código abierto, Istio puede ejecutarse en cualquier proveedor de cloud público que lo admita y cualquier cloud privado con administradores que así lo deseen.

El siguiente vídeo incluye una explicación más extensa sobre los aspectos básicos de Istio:

Cuando las organizaciones migran a los microservicios, necesitan dar soporte a decenas o cientos de aplicaciones específicas. Gestionar estos puntos finales por separado significa dar soporte a un gran número 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 direccionamiento, reglas de tráfico ni herramientas de supervisión o depuración potentes.

Empiece a utilizar la malla de servicio.

A medida que aumenta el número de servicios, el número de formas potenciales de comunicación 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 estas vías 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 escribir código para ello), un administrador puede proporcionar configuración a la malla de servicio y completarla. Estas tareas siempre eran necesarias 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 direcciona y observa el tráfico de comunicaciones entre servicios y contenedores.

Como se ha mencionado anteriormente, Istio se acopla en capas sobre Kubernetes, y añade contenedores que son básicamente invisibles para el programador y el administrador. Estos contenedores se denominan "sidecar" y actúan como si estuviesen en el medio dirigiendo el tráfico y supervisando las interacciones entre los componentes. Las dos herramientas se pueden combinar en tres aspectos: configuración, supervisión y gestión.

Configuración

El método principal para definir la configuración con Kubernetes es el mandato kubectl, que suele ser "kubectl -f", donde el archivo es un archivo YAML. Los usuarios de Istio pueden ejecutar nuevos o diferentes tipos de archivos YAML con kubectl o utilizar el nuevo mandato ioctl opcional.

Supervisión

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

Gestión

Como la interfaz para Istio es básicamente la misma que para Kubernetes, su gestión no requiere casi ningún trabajo adicional. De hecho, Istio permite al usuario crear políticas que incidan sobre todo el clúster de Kubernetes y lo gestionen, de modo que se reduce el tiempo de gestión de cada clúster y se elimina a su vez la necesidad de contar con código de gestión personalizado.

Las principales ventajas de una malla de servicio incluyen funciones para mejorar la depuración, la supervisión, el direccionamiento, la seguridad y la optimización. Es decir, Istio facilita la gestión de un grupo de servicios más amplio.

Depuración mejorada

Pongamos, por ejemplo, que un servicio tiene varias dependencias. El servicio pay_claim de una compañía de seguros llama al servicio deductible_amt, que a su vez llama al servicio is_member_covered, y así sucesivamente. Una cadena de dependencias compleja puede tener 10 o 12 llamadas de servicio. Cuando una de estas 12 falla, se produce un conjunto de fallos en cascada que generan algún tipo de error 500, error 400, o posiblemente ninguna respuesta en absoluto.

Para depurar este conjunto de llamadas, puede utilizar algo como un rastreo de pila. 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 de frontend pueden obtener un diagrama de cascada para ayudar en la depuración.

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

Supervisión y observabilidad

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

Política

De forma 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 sean dependencias reales. Otra política para mantener los servicios activos es un límite de velocidad, que impedirá que el exceso de tráfico obstruya un servicio y evitará ataques de denegación de servicio.

Direccionamiento y equilibrio de carga

De forma predeterminada, Kubernetes proporciona equilibrio de carga en rueda (round-robin). 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 y, a continuación, empezará de nuevo. Sin embargo, a veces una empresa desplegará diferentes versiones del mismo servicio en producción.

El ejemplo más simple en este caso puede ser un despliegue azul/verde. En este 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 acelerar la restauración en caso de fallo.

Con Istio, resulta 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 cabeceras. Así, por ejemplo, los usuarios beta pueden dirigirse a un pod "canary" con la última compilación, mientras que los usuarios habituales pueden optar por la compilación de producción estable.

Rotura de circuitos

Si un servicio está sobrecargado o se ha caído, las solicitudes adicionales fallarán mientras se continúa sobrecargando el sistema. Istio rastrea errores y retrasos, por lo que puede forzar una pausa para permitir que un servicio se recupere después de un número específico de solicitudes establecido por política. Puede aplicar esta política en todo el clúster mediante la creación de un archivo de texto pequeño e indicando a Istio que lo utilice 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, que evita cualquier observación. El servicio de identidad, combinado con el cifrado, garantiza que ningún usuario no autorizado pueda falsificar -o suplantar- una llamada de servicio. AAA proporciona a los profesionales de seguridad y operaciones las herramientas que necesitan para supervisar, con menos sobrecarga general.

Administración simplificada

Las aplicaciones tradicionales todavía necesitan las características de identificación, política y seguridad que ofrece Istio. En ellas, los programadores y administradores trabajan a un nivel de abstracción equivocado, reimplementando las mismas reglas de seguridad una y otra vez para cada servicio. Istio les permite trabajar a un nivel adecuado y definir una política para el clúster a través de un único panel de control.