¿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 se compone 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, agregando pods a medida que aumenta la demanda con el escalador automático de pods. Istio inyecta más contenedores en el pod para añadir seguridad, gestión y monitorización.

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 vídeo explica más sobre los conceptos básicos de Istio:

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

Introduzca la malla de servicio.

A medida que aumenta el número de servicios, el número de posibles formas de comunicación aumenta exponencialmente. 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 forma única de configurar esas rutas de comunicación mediante la creación de una política para la comunicación.

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

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

Como ya se ha mencionado, Istio se superpone a Kubernetes, añadiendo contenedores que son invisibles para el programador y el administrador. Se les llama contenedores sidecar, actúan como una persona en el medio, encauzando el tráfico y monitorizando las interacciones entre los componentes. Ambos trabajan en combinación de tres maneras: configuración, monitorización 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 ioctl.

Con Istio, puede monitorizar fácilmente la salud de sus aplicaciones ejecutadas con Kubernetes. La instrumentación de Istio puede gestionar y visualizar el estado de las aplicaciones, proporcionando más información que la simple monitorización de clústeres y nodos que ofrece Kubernetes.

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

Los principales beneficios de una malla de servicios incluyen capacidades para mejorar la depuración, la monitorización, 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 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 dependencia compleja puede tener 10 o 12 llamadas de servicio. Cuando uno de esas 12 falla, habrá una serie de fallos en cascada que darán como resultado algún tipo de error 500, error 400 o posiblemente ninguna respuesta.

Para depurar ese conjunto de llamadas, puede usar algo como un seguimiento de pila. En la interfaz, 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 en cascada para ayudar a depurar.

Lo que el ejemplo no muestra es lo que ocurre dentro 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 las llamadas a funciones en un diagrama muy parecido a éste.

Es posible que los equipos de DevOps y la administración de TI quieran 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 de control. Un panel de control proporciona una visualización de la suma, o el promedio, de esas métricas a lo largo del tiempo, quizás con la capacidad de profundizar hasta un nodo, servicio o pod específico. Kubernetes no proporciona estas funciones de forma nativa.

Por defecto, 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 trabajar entre sí. Así, por ejemplo, los servicios sólo pueden llamar a otros servicios que sean verdaderas dependencias. Otra política para mantener los servicios es un límite de velocidad, que impedirá que el exceso de tráfico atasque un servicio y evitará los ataques de denegación de servicio.

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 peticiones a cada pod en orden creciente y luego vuelve a empezar. Sin embargo, a veces una empresa implementa diferentes versiones del mismo servicio en producción.

El ejemplo más simple de esto podría ser una implementación 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 usuarios de producción a ella. Después de promocionar la nueva versión, la empresa puede conservar los servidores antiguos para agilizar el cambio en caso de fallo.

Con Istio, es tan simple como usar el etiquetado 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. Así, por ejemplo, los usuarios beta pueden dirigirse a un pod Canary con la última y mejor compilación, mientras que los usuarios normales 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 los errores y retrasos, puede forzar una pausa, lo que permite que un servicio se recupere, después de un número específico de solicitudes establecido por la política. Puede aplicar esta política en todo el clúster creando un pequeño archivo de texto e indicando a Istio que lo utilice 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 administración que se comunique con otros utiliza tráfico cifrado, lo que impide cualquier observación. El servicio de identidad, combinado con el cifrado, ayuda a garantizar que ningún usuario no autorizado pueda falsificar o "falsificar" una llamada de servicio. AAA proporciona a los profesionales de seguridad y operaciones las herramientas que necesitan para monitorizar, con menos sobrecarga.

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, reimplementando las mismas reglas de seguridad una y otra vez para cada servicio. Istio les permite trabajar al nivel adecuado, estableciendo políticas para el clúster a través de un único panel de control.