Acompaña el evento final de la Maratón Behind the Code 2020: 05/12 - Online ¡Inscríbete ahora!

Introducción a Istio

Agenda

  1. Introducción
  2. Pre-requisitos y siguientes pasos
  3. Antecedentes
  4. ¿Qué es una malla de servicios y qué es Istio?
  5. Arquitectura de Istio
  6. Escenarios y casos de uso de Istio
  7. Istio y las aplicaciones de 12 factores
  8. Conclusión
  9. Fuentes

1. Introducción y objetivo

  • El advenimiento y crecimiento de las aplicaciones basadas en arquitecturas de micro-servicios están resolviendo retos importantes que permiten a las empresas mantener un ritmo acelerado de innovación a través de la adopción de la transformación digital; no obstante esto atrae otros retos donde nuevas tecnologías, en su mayoría proyectos de código abierto, están aprovechando el conocimiento de la comunidad para innovar rápidamente y resolver estos nuevos retos. Istio es el resultado de la innovación de la comunidad, su uso está en expansión por los grandes beneficios que provee es imperante comprender cómo sacar provecho de esta tecnología al aplicarla.

  • Al terminar de leer este artículo, en aproximadamente 45 minutos, los interesados podrán comprender el concepto de una malla de servicios y cómo reducir los retos que surgen a partir del éxito de las arquitecturas basadas en micro-servicios, facilitando y robusteciendo la seguridad y la gestión de las comunicaciones, esto a través de casos de uso y ejemplos específicos.

2. Pre-requisitos y siguientes pasos

  • El presente artículo es conceptual, por lo que la audiencia que puede aprovechar el contenido es amplia, solo se requiere conocer los conceptos generales de micro-servicios, contenedores y Kubernetes; así como conceptos generales de redes TCP/HTTP y Seguridad SSL y TLS.

  • Al terminar este artículo, recomiendo como siguiente paso realizar tutoriales que permitan extender el conocimiento adquirido y ponerlo en práctica. Si bien al final del artículo dejo recomendaciones de lecturas y fuentes adicionales; aquí comparto un tutorial de Red Hat: https://developers.redhat.com/topics/service-mesh/(Link reside outside of ibm.com)

3. Antecedentes

  • En primer instancia, Istio nace como resultado de la popularidad que han ganado los micro-servicios a partir del concepto de contenedores (como lo es Dockers) y los orquestadores de contenedores (como lo es Kubernetes).

  • Durante la evolución de las arquitecturas de micro-servicios, se ha dado una madurez evolutiva resultado de su uso en expansión, el uso y apoyo por las principales fundaciones y fabricantes (como la CNCF:Cloud Native Computing Foundation, IBM, Google, etc…)

  • Esta madurez evolutiva ha traído interesados en resolver retos que recaían en la aplicación misma o bien en las capas de infraestructura que buscan gestionar los contenedores donde viven dichas aplicaciones

  • Esta madurez evolutiva ha traído interesados en resolver retos que recaían en la aplicación misma o bien en las capas de infraestructura que buscan gestionar los contenedores donde viven dichas aplicaciones

  • Entre otros, estos son los principales retos que se requieren resolver:

  • Las compañías, al adoptar las arquitecturas de micro-servicios, han tenido un crecimiento en sus implementaciones que conlleva una gran cantidad de micro-servicios (Una sola aplicación puede estar compuesta por cientos o miles de micro-servicios) que requieren comunicarse entre sí y que, como consecuencia, se enfrentan a nuevos retos que no eran tan relevantes en implementaciones pequeñas o en entornos de aplicativos monolíticos.

  • A diferencia de las aplicaciones monolíticas, las aplicaciones basadas en micro-servicios no son estáticas, mas bien son dinámicas ya que los mico-servicios pueden estar en cualquier lugar, esto debido a su elasticidad o bien resultado de los procesos de manejo de fallas y actualizaciones

  • Definición y gestión del tráfico entre los micro-servicios

  • Visibilidad y monitoreo del tráfico en una arquitectura de micro-servicios

  • Protección de las comunicaciones entre micro-servicios

4. ¿Qué es una Malla de servicios y qué es Istio?

  • Teniendo en cuenta los retos que son necesarios resolver en implementaciones de cierto tamaño, nacen los ”Service Mesh” o “Mallas de servicios” con el objetivo de resolver dichos retos; Istio es una Malla de servicios, entre otros que han surgido como Linkerd o Netflix OSS.

  • Ahora, para entender mejor qué es Istio, primero voy a compartir una definición y una analogía de Malla de servicios que me han hecho mucho sentido:

  • Definición: “Una malla de servicios es una capa de infraestructura dedicada para hacer que la comunicación entre servicios sea segura, rápida y confiable” What’s a service mesh? And why do I need one?

  • Analogía: Así como TCP provee una red para entrega de bytes entre puntos de red, la Malla de servicios provee una red para comunicación entre micro-servicios

  • Así, las Mallas de servicios prometen ser el mecanismo para gestionar las funciones de red necesarias para las arquitecturas basadas en micro-servicios

  • Entre las principales ventajas de usar Istio están las siguientes que es capaz de proveer prácticamente* sin cambios en el código de la aplicación:

  • Balanceo de cargas automático para el tráfico: HTTP, gRPC, WebSocket y TCP

  • Control granular del tráfico con reglas de ruteo, re-intentos, caídas, límites de rangos y cuotas
  • Métricas, “logs” y rastreo automático para el tráfico dentro de un clúster, incluyendo ingresos y egresos
  • Aseguramiento de la comunicación entre servicios en un clúster con una fuerte autenticación y autorización basada en identidades
  • https://istio.io/docs/tasks/telemetry/distributed-tracing/overview/#trace-context-propagation(Link reside outside of ibm.com)

  • Perspectiva de alto nivel:

  • ¿Qué es Istio?: Es una Malla de servicios que provee capacidades bastas, ricas y declarativas de descubrimiento y ruteo de servicios. https://developers.redhat.com/books/introducing-istio-service-mesh-microservices/(Link reside outside of ibm.com)

  • Istio provee soporte a los micro-servicios en un ambiente de Kubernetes por medio de la implementación de un proxy de tipo “sidecar”. Este proxy intercepta todas las comunicaciones entre los micro-servicios para gestionarlas
  • Este tipo de implementación el proxy-sidecar acompañará a la aplicación durante su vida de forma desacoplada pero agregando capacidades adicionales interceptando las comunicaciones de red
  • Así, en Kubernetes y dentro de un Pod, vivirá nuestra aplicación y el proxy-sidecar o “Envoy”. Aquí un ejemplo gráfico de alto nivel:

El cliente conectado a la nube, que conecta al Istio Sidecar y su Microservicio A, y a través de ese mismo Sidecar conecta al Sidecar del Microservicio B.

5. Arquitectura de Istio

Istio está conformado principalmente por 2 planos: El plano de Datos y el plano de Control:

  • Plano de datos: Está compuesto por los proxy-sidecars o “Envoys” desplegados dentro del Pod de nuestra aplicación para interceptar todas las comunicaciones entre los micro-servicios

  • Plano de control: Permite configurar y gestionar los proxies o Envoys para ruteo del tráfico y cumplimiento de otras políticas a tiempo de ejecución

Desde el plano de control, el mixer de telemetría situado entre el piloto y el citadel, se conecta a los pods de servicios A y B localizados entre el ingreso y la salida de la malla de servicios del plano de datos.

Características de los componentes de la arquitectura:

  • Envoy: Este es un proyecto separado y aprovechado por Istio. Componente encargado de proveer el servicio de descubrimiento dinámico de servicios, balanceo de carga, TLS, gRPC, interruptores automáticos, gestión de tiempos de espera, controles de estado y métricas entre otros

  • Pilot: Componente encargado del descubrimiento de los servicios, ruteo inteligente y tolerancia a fallos (reintentos, corta circuitos, tiempos de espera, entre otros)

  • Mixer: Componente encargado de aplicar las políticas, controles de acceso y uso. También obtención de métricas generadas por las llamadas a los Envoys. Libera a las aplicaciones de implementar capacidades como: Control de acceso, gestión de cuotas, informes de telemetría

  • Citadel: Componente encargado de la seguridad, permite la autenticación y encripción entre servicios a través de políticas basadas en identidad e implementa TLS

6. Escenarios y casos de uso de Istio

Entre otras capacidades, Istio permite integrar tolerancia a fallos a las aplicaciones sin realizar cambios al código de dichas aplicaciones, aquí los casos de uso mas relevantes:

  1. Descubrimiento de servicios desde el servidor
  2. Pruebas automatizadas
  3. Interruptores
  4. Mamparas
  5. Distribución de tráfico
  6. Diferenciación de tráfico
  7. Autenticación de servicios

1. Descubrimiento de servicios desde el servidor:

  • Se puede implementar balanceo de cargas sensible a la Zonas Disponibles (AZ) con conmutación automática por error (failover)

  • El cliente consulta al balanceador de cargas

  • El balanceador de cargas consulta el registro de servicios y rutea las solicitudes a las instancias
  • La lógica de distribución vive en el balanceador de cargas

Fuente: dzone.com

Flujo de solicitud hacia el balanceador de cargas, que conecta con el registro de servicios, y también con las instancias de servicio A, B y C.

2. Pruebas automatizadas:

  • Pruebas de fallas
  • Generación de problemas aleatorios con un propósito

  • Implementación de patrones de resiliencia

  • Registro de servicios: Listado dinámico de instancias de servicio

  • Interruptores: Bloqueo de las llamadas a servicios que no están funcionando
  • Mampara: Separación de “Pools” de conexiones para separar recursos
  • Comando: Ejecución de solicitudes de reintento, ”aceleración” y monitoreo

3. Interruptores en Istio:

El consumidor de un servicio es tan confiable como el servicio proveedor

  • Evitar invocar a una instancia de servicio no confiable:
  • El servicio debe arrojar un error
  • El servicio puede arrojar un tiempo excedido
  • También puede haber fallas de red

  • Interruptor: El consumidor de un servicio lo puede invocar de forma confiable

  • Puede invocar un servicio no confiable
  • Falla rápido cuando el servicio proveedor no está funcionando

Flujo entre consumidor  y microservicio interrumpido por problema de conexión, tiempo de espera excedido y regreso rápido por no llamar al micro-servicio.

3. Interruptores en Istio: Prueba de fallos:

  • Inyección sistematizada de fallos para identificar debilidades en las políticas de recuperación:
  • Códigos de error HTTP/gRPC
  • Inyección de retrasos

Flujos entre servicios A y B con tiempo límite de espera 200 ms con 2 intentos (400ms), y entre servicio B y C con límite de espera de 300 ms y 3 intentos, totalizando 900ms.

4. Mamparas:

Istio permite implementar mamparas; estas permiten reducir las posibilidades de propagación de fallos.

Sin mampara:

  • Un solo “pool” de conexión compartido con los sistemas externos

  • Si un sistema bloquea las conexiones, entonces todas las conexiones se bloquean y no hay forma de obtener conexiones a los demás sistemas

Con mampara:

  • Un “pool” de conexiones para cada sistema externo

  • Si un sistema bloquea las conexiones, entonces las otras conexiones a los demás sistemas continúan funcionando

Flujos entre servicios A y B con tiempo límite de espera 200 ms con 2 intentos (400ms), y entre servicio B y C con límite de espera de 300 ms y 3 intentos, totalizando 900ms.

5. Distribución de tráfico por cuotas:

Istio permite desacoplar el tráfico de la infraestructura usando reglas basadas en peso y establecidas en porcentajes y diferenciado el servicio destino a través de las etiquetas.

El Istio manager de Reglas API conectado al pod de servicio A,  y desde este 85 % se deriva a los pods 1,2 y 3 del servicio B, y 15 % apenas se deriva a otro pod 1 del servicio B.

5. Distribución de tráfico por contenido:

Istio permite direccionar el tráfico en base al contenido del mismo y diferenciando, por ejemplo, las etiquetas de los Pods.

Flujo de servicio A hacia pods 1,2 y 3 del servicio B. Desde otro servicio A, el flujo urgente Android va a tres pods y en paralelo el flujo urgente IPhone va al pod 4.

6. Autenticación de servicios:

Las características de seguridad de Istio proveen un fuerte manejo de identidades, políticas robustas, encripción TLS transparente y herramientas de AAA: Autenticación, Autorización y Auditoría

Arquitectura de alto nivel:

6.1 La seguridad en Istio considera múltiples componentes:

  • Citadel: Gestiona llaves y certificados
  • Sidecar y proxies perimetrales: Para asegurar la comunicación entre clientes y servidores
  • Pilot: Distribuye las políticas de autenticación y la información de nombres segura a los proxies
  • Mixer: Para gestionar la autorización y la auditoría

    Flujo de métricas de control uniendo el pilot, el proxy de servicio A, el citadel y el proxy del servicio B hasta llegar al mixer.

6.1 Dado que la seguridad es clave en cualquier implementación seria, a continuación profundizaremos en las siguientes características de seguridad en Istio:

  • Identidades
  • Comunicación segura
  • Gestión de claves

6.2 Identidades en Istio:

Istio utiliza las cuentas de servicio (sa) de Kubernetes para identificar a quien ejecuta un servicio. Al inicio de la comunicación entre servicios, las 2 partes deben intercambiar credenciales para una autenticación mutua.

  • Del lado del cliente, la identidad del servidor es validada contra un nombre seguro para confirmar que es un ejecutor autorizado del servicio

  • Del lado del servidor, el servidor debe determinar qué información puede ser accesada por el cliente basada en las políticas de autorización

Istio implementa Spiffe (spiffe.io – Secure Production Identity Framework for Everyone), que provee una identidad segura basada en un certificado personalizado X.509, para cualquier carga de trabajo en un ambiente moderno. Spiffe elimina la necesidad de autenticación a nivel aplicativo así como configuraciones de red complejas basadas en ACL (Access Control List) – Así Spiffe otorga identidades a los servicios en ambientes heterogéneos

De esta forma Istio logra gran flexibilidad y granularidad para representar a una persona, un servicio individual o un grupo de servicios. En Kubernetes la identidad de servicio de Istio es la cuenta de servicio (sa):

  • El identificador de una “sa” se representará de la siguiente forma:

“spiffe://<dominio>/ns/<espacio de nombres>/sa/<cuenta de servicio>, el espacio de nombres (ns) es el proyecto en el que se ejecutan los micro-servicios y su ”sa”

  • De esta forma, usando los ”sa” podemos identificar, por ejemplo: máquinas y/o usuarios

6.3 Comunicación segura:

Istio provee 2 tipos de autenticación:

Autenticación de transporte entre servicios: Como hemos visto, la comunicación en el Plano de Datos se da entre los “Envoys”, que pueden asegurarse sin cambios en el código considerando estas 3 capacidades:

  1. Los servicios (aplicativos) se comunican con su Envoy a través de conexiones locales TCP
  2. Los proxies se comunican utilizando mTLS (TLS mutuo)
  3. Durante el proceso inicial de comunicación se verifica que la “sa” identificada en el certificado del servidor tiene permisos para ejecutar el servicio

Autenticación de origen o de Usuario final permite verificar el cliente original que realiza la petición. Istio permite autenticación a nivel de petición con validación de Web Token JSON (JWT) y OpenID Connect

En ambos casos, Istio almacena las políticas de autenticación en el “Istio config store” a través del API de Kubernetes. Pilot las mantiene actualizadas para cada proxy junto con las llaves cuando corresponda. Istio provee un “modo permisivo” para validar cómo afecta un cambio de política en la seguridad antes hacerse efectivo.

Istio CA  conectado por dos flechas a dos cuentas de servicio A, y los pods de cada servicio, a su vez conectados entre sí, por una llave que indica TLS + nombre seguro.

7

Istio y las aplicaciones de 12 factores

¿Qué son las aplicaciones de 12 factores?

Los 12 factores sobre buenas prácticas para crear aplicaciones modernas y que permiten resolver retos relacionados con su dinamismo y escalabilidad, principalmente aplica a aplicaciones nativas de Nube

Lista de los 12 factores:

Un solo código base1. Código: Al publicar los servicios7. Asignación de puertos:
2. Dependencias: Explícitamente aisladas y declaradas 8. Concurrencia: Escalar usando procesos
3. Configuración: Almacenamiento de la configuración en el entorno 9. Desechabilidad: Disponer a través de un rápido arranque y apagado eficiente y gentil
4. Servicios externos: Tratar a los servicios externos como recursos conectables 10. Paridad entre ambientes: Mantener todos los ambientes lo mas similares posible
5. Construir, liberar, ejecutar: Separar claramente las fases de construcción y ejecución 11. Bitácoras: Tratar las bitácoras como corrientes de eventos
6. Procesos: Ejecutar las aplicaciones como procesos sin estado 12. Procesos administrativos: Ejecutar tareas administrativas y de gestión como un proceso único

A continuación exploraremos cómo Istio es una buena práctica en las aplicaciones de 12 factores. En este documento no exploraremos a fondo los 12 factores, ya que se requiere un artículo completo para este fin, pero sí revisaremos en dónde Istio ayuda a lograr de manera mas efectiva dichos factores y facilita por lo tanto la construcción y gestión de aplicaciones nativas de Nube

Para explorar a detalle los 12 factores recomiendo las siguientes ligas:

https://sg.com.mx/revista/52/aplicaciones-12-factores(Link reside outside of ibm.com)

https://blog.scottlogic.com/2017/07/17/successful-microservices-with-12factor-app.html(Link reside outside of ibm.com)

Factores y su relación con Istio:

1. Código, 10. Paridad entre ambientes: Como hemos visto, Istio ayuda a aplicar diferentes políticas de red y seguridad para diferentes entornos, esto sin necesidad de “tocar” la aplicación, por lo que ayuda a mantener un solo código mientras podemos lograr comportamiento diferenciado dependiendo las características del ambiente donde se despliega la aplicación.

1. Dependencias: Dichas políticas nos permiten establecer reglas de operación del ambiente basado en micro-servicios de forma aislada y completamente declarativa.

1. Configuración: Istio ayuda a gestionar la configuración de las reglas de comunicación entre los servicios, si bien lo hace centralizando en punto donde se realiza esta gestión, la configuración es distribuida a los “Envoys” en su propio entorno

1. Servicios externos: Istio permite vincular los servicios de red y de seguridad como un recurso externo, esto se comprueba ya que no se requiere modificar la aplicación para incluir dichos servicios al entorno

1. Construir, liberar, ejecutar: Este factor recomienda la separación del proceso de convertir el código en un ejecutable (construir), luego combinar el ejecutable con la configuración para un entorno específico listo para su ejecución (Aquí Istio puede proveer la configuración para las políticas de red y seguridad que aplicarán) y finalmente arrancar la aplicación en donde fue desplegada (Donde las políticas serán enviadas a los Envoys para ser aplicadas a tiempo de ejecución).

1. Asignación de puertos: Este factor permite que un servicio sea visible a otros servicios a través de la asignación de puertos; y justamente en este punto es donde Istio nos ayuda en la vinculación de puertos para establecer reglas de “quien habla con quien”

1. Concurrencia: Dado que la concurrencia requiere escalabilidad, Kubernetes ofrece gran valor; sin embargo, como hemos visto previamente, la tarea de trabajar con estos ambientes se incrementa conforme las aplicaciones y los entornos se hacen mas grandes y complejos. Justamente Istio ayuda a gestionar ambientes que al escalar de forma dinámica se hacen mas complejos.

1. Bitácoras: Istio, a través del componente “Mixer” permite la generación de bitácoras relacionadas con el flujo de tráfico en la Malla de servicios en un conjunto de formatos configurables, permitiendo control completo de cómo, qué, cuándo y dónde se generarán bitácoras, permitiendo una auditoría detallada de las transacciones de red. Istio permite crear bitácoras para ser explotados por herramientas como Fluentd o ELK

1. Procesos administrativos: Istio permite la ejecución de tareas administrativas relacionadas, como hemos visto, con la configuración de reglas de red y seguridad entre otras. Dichas tareas son ejecutadas a través de archivos de configuración que mantienen la estructura que se maneja en los archivos de configuración de Kubernetes. Estas tareas se manejan de forma independiente a la aplicación, pero afectando su comportamiento.

8. Conclusión

Istio es una herramienta muy poderosa para gestionar entornos de aplicativos basados en Kubernetes (entre otros) complejos y grandes, haciendo mas sencillas las tareas de gestión de tráfico y seguridad entre los micro-servicios, y si bien, Istio no provoca que una aplicación (o más) se apegue a los 12 factores como buenas prácticas para desarrollo de aplicaciones de nube nativas, si tiene ventajas que ayudan a un apego mas sencillo en varios rubros.

9. Fuentes

Cloud Garage Application Architect Bootcamp materials: