¿Qué es Istio?

En este momento, Istio solo funciona de forma nativa con Kubernetes, pero su naturaleza de código abierto hace posible que cualquiera pueda escribir extensiones que permitan a Istio ejecutarse en cualquier software de clúster. Hoy nos centramos 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. Una arquitectura de microservicios puede tener una docena de nodos diferentes, cada uno de los cuales representa diferentes microservicios. Kubernetes administra la disponibilidad y el consumo de recursos de los nodos, y agrega pods a medida que aumenta la demanda con el escalador automático de pods. Istio inyecta más contenedores en el pod para agregar seguridad, gestión y monitoreo.

Al ser de código abierto, Istio puede ejecutarse en cualquier proveedor de nube pública que lo admita y en cualquier nube privada con administradores dispuestos a ello.

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

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

Introduzca la malla de servicios.

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

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

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

Como se mencionó anteriormente, Istio se superpone a Kubernetes, y agrega contenedores que son invisibles para el programador y el administrador. Llamados contenedores sidecar, actúan como una persona en el medio, que dirigen el tráfico y monitorean las interacciones entre los componentes. Los dos funcionan en combinación de tres maneras: configuración, monitoreo y gestión.

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

Con Istio, puedes monitorear fácilmente el estado de tus aplicaciones que se ejecutan con Kubernetes. La instrumentación de Istio puede gestionar y visualizar el estado de las aplicaciones, lo cual proporciona más insights que solo la supervisión general de clústeres y nodos que ofrece Kubernetes.

Dado que la interfaz de Istio es esencialmente la misma que la de Kubernetes, gestionarla prácticamente no requiere trabajo adicional. De hecho, Istio permite al usuario crear políticas que afectan y gestionan todo el clúster de Kubernetes, lo que reduce el tiempo de gestión de cada clúster y elimina la necesidad de un código de gestión personalizado.

Los principales beneficios de una malla de servicios incluyen capacidades para mejorar la depuración, el monitoreo, el enrutamiento, la seguridad y el uso. Es decir, con Istio, se necesita menos esfuerzo para gestionar un grupo más amplio de servicios.

Digamos, por ejemplo, que un servicio tiene múltiples 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 dependencia compleja podría tener 10 o 12 llamadas de servicio. Cuando una de esas 12 falla, habrá un conjunto de fallas en cascada que resultarán en algún tipo de error 500 o 400, o posiblemente ninguna respuesta.

Para depurar ese conjunto de llamadas, puede usar algo como un seguimiento de pila. En el frontend, los desarrolladores del lado del cliente pueden ver qué elementos se retiran de los servidores sitio web y 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 dentro del centro de datos: cómo callback=parselLotamaAudiences llama a otros cuatro servicios web y cuáles responden más lento. Más adelante, veremos cómo Istio proporciona herramientas para rastrear llamadas a funciones en un diagrama muy parecido a este.

Es posible que los equipos de DevOps y la administración de TI deseen observar el tráfico para ver la latencia, el tiempo de servicio, los errores como porcentaje del tráfico, etc. A menudo, quieren ver un panel. Un panel proporciona una visualización de la suma, o el promedio, o esas métricas a lo largo del tiempo, tal vez con la capacidad de profundizar en un nodo, servicio o pod específico. Kubernetes no proporciona estas funciones de forma nativa.

De forma predeterminada, Kubernetes permite que cada pod envíe tráfico a todos los demás pods. Istio permite a los administradores crear una política para restringir qué servicios pueden funcionar entre sí. Entonces, por ejemplo, los servicios solo pueden llamar a otros servicios que son verdaderas dependencias. Otra política para mantener los servicios en funcionamiento es un límite de velocidad, que evitará que el exceso de tráfico obstruya un servicio y evitará ataques de denegación del servicio.

Por defecto, Kubernetes proporciona un equilibrio de carga round-robin. Si hay seis pods que proporcionan un microservicio, Kubernetes proporcionará un equilibrador de carga, o servicio que envía peticiones a cada pod en orden creciente y luego vuelve a empezar. Sin embargo, a veces una compañía despliega diferentes versiones del mismo servicio en producción.

El ejemplo más sencillo podría ser un despliegue azul o verde. En ese caso, el software podría crear una versión completamente nueva de la aplicación en producción sin enviar a los usuarios de producción a ella. Tras promocionar la nueva versión, la compañía puede conservar los servidores antiguos para agilizar el cambio en caso de falla.

Con Istio, esto es tan simple como usar etiquetas en un archivo de configuración. Los administradores también pueden usar etiquetas para indicar a qué tipo de servicio conectarse y crear reglas basadas en encabezados. Entonces, por ejemplo, los usuarios beta pueden ir 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.

Si un servicio está sobrecargado o inactivo, más solicitudes fallan y continúan sobrecargando el sistema. Dado que Istio realiza un seguimiento de errores y retrasos, puede forzar una pausa, lo que permite que un servicio se recupere, luego de un número específico de solicitudes establecido por la política. Puede aplicar esta política en todo el clúster al crear un pequeño archivo de texto e indicar a Istio que lo use como una nueva política.

Istio proporciona identidad, políticas y cifrado de forma predeterminada, junto con autenticación, autorización y auditoría (AAA). Cualquier pod bajo gestión que se comunique con otros utiliza tráfico cifrado, lo que evita cualquier observación. El servicio de identidad, combinado con el cifrado, ayuda a garantizar 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 monitorear, con menos gastos generales.

Las aplicaciones tradicionales siguen necesitando las características de identidad, políticas y seguridad que ofrece Istio. Eso hace que los programadores y administradores trabajen en el nivel equivocado de abstracción, y vuelven a implementar las mismas reglas de seguridad una y otra vez para cada servicio. Istio les permite trabajar en el nivel adecuado, y establecen políticas para el clúster a través de un único panel de control.