En artículos anteriores hablamos de cómo service-mesh será el nuevo paradigma para la gestión de las funcionalidades estructurales de red en las nuevas arquitecturas de microservicios.

También hablamos de Istio, la solución de service-mesh creada en conjunto por Google, IBM y Lyft basada en la experiencia de Google ejecutando aplicaciones de gran tamaño durante años en producción.

Ahora que sabemos de la importancia de Istio, nos preguntamos ¿cómo es su arquitectura? ¿Cuáles son sus funcionalidades más importantes? ¿Cómo podemos llevar a cabo su configuración? Vamos a responder a estas y otras muchas preguntas más.

Arquitectura

Istio funciona utilizando el patrón sidecar que, como su nombre indica, es similar al concepto de un sidecar en una motocicleta.

En este patrón una parte de las funcionalidades/necesidades de la aplicación son trasladadas a un segundo componente desacoplándolas así de la aplicación original proporcionando aislamiento y encapsulación.

Esto nos permite proporcionar una funcionalidad adicional (llevar otro pasajero) desacoplada de la aplicación y que acompaña al elemento primario a lo largo de su ciclo de vida.

De forma similar, en el caso concreto del patrón sidecar-proxy, el sidecar, la pieza que acompañará a nuestra aplicación, será un proxy que intercepte todas las comunicaciones de red.

En el caso concreto de Kubernetes esto se traduce en que dentro del pod se ejecutarán, además del contenedor de nuestra aplicación, otro contenedor que será dicho proxy. Yendo al detalle, este es un proxy Envoy.

Las piezas que componen la arquitectura de Istio se pueden categorizar en dos grupos diferentes conocidos como planos:

La siguiente imagen muestra la arquitectura general de Istio con sus diferentes piezas. En ella podemos ver cómo un proxy Envoy acompaña a cada servicio svcA y svcB y que son los que realizan las comunicaciones entre los mismos además de recibir las llamadas entrantes al sistema (ingress) y realizan las salientes (egress).

Así mismo también se comunican con Mixer para la comunicación de métricas y la gestión de acceso. Mientras, Pilot nutre de información a los proxies Envoy sobre el registro y configuraciones, e Istio-Auth será el encargado de la generación de certificados para las llamadas con TLS.

A continuación vamos a ver las diferentes piezas que componen la arquitectura en mayor detalle.

Proxy Envoy

Es la pieza encargada de interceptar todo el tráfico de entrada y salida al contenedor de la aplicación.

Se comunica con el resto de piezas para llevar a cabo funcionalidades como son el balanceo, circuit breaking, gestión de timeouts… que más adelante analizamos en detalle.

Envoy es un proyecto separado de Istio como tal, podés encontrar su site aquí.

Mixer

Se encarga del control de acceso y de recibir las métricas generadas por las llamadas en los proxy Envoy.

Su finalidad es mover la integración con el control de acceso, gestión de cuota, logging y similares fuera del propio servicio (aplicación) como tal y convertirlas en simple configuración evitando así el acoplamiento entre el mismo y la infraestructura destinada a tal fin.

Para ello, Mixer actuará como intermediario de forma que el servicio interactuará con él, no estando acoplada a la infraestructura subyacente.

Además, el nivel de acoplamiento con Mixer será inferior al que se tendría con la infraestructura.

Para ello Mixer dispone de diferentes abstracciones en forma de adaptadores o plugins para interactuar con los diferentes sistemas (Prometheus, AWS, GCP...) ya sean de telemetría, control de acceso… proporcionando así un API unificada independiente de la herramienta utilizada por debajo.

Las funcionalidades principales proporcionadas por Mixer se podrían agrupar como:

Pilot

Es la pieza encargada de gestionar todo lo referente a registro de servicios, enrutado y resiliencia (circuit breaking, timeouts, reintentos...)

Es el punto central donde registraremos dichas configuraciones y que serán trasladadas en tiempo real a los diferentes proxies Envoy.

Además, proporciona abstracción sobre la infraestructura existente de forma que los proxies Envoy no necesitan saber si se están ejecutando sobre Kubernetes, CloudFoundry, Mesos…

Istio-Auth

Es la pieza encargada de securizar la comunicación entre servicios y usuario final con los servicios utilizando TLS.

De esta forma todo el tráfico de red en el service mesh estará identificado por quién ha invocado a quién, de manera que se podrán utilizar políticas de acceso en base a identidad en lugar de control de red.

Para ello se encarga de la generación, distribución, rotación y revocación de claves y certificados.

La siguiente imagen muestra la gestión de certificados para una comunicación entre dos servicios, uno desplegado en Kubernetes y el otro en máquinas virtuales/físicas (en el caso de este último es necesario el uso de un agente).

Las características principales de la arquitectura de seguridad son las siguientes:

Instalación

Istio dispone de una muy buena documentación en su sitio web e incluye un montón de ejemplos de las diversas funcionalidades y sus configuraciones necesarias.

Os recomiendo que le echéis un ojo y que hagáis alguno de ellos, son sencillos y demuestran muy bien toda la potencia de Istio.

De cara a la instalación, en mi caso, la plataforma con la que estoy más familiarizado es Openshift, la solución de Red Hat para orquestación de contenedores basado en Kubernetes, así que instalaré Istio en Openshift.

Aunque está basado en Kubernetes, las diferencias entre desplegar Istio en Openshift o en el propio Kubernetes son mínimas (básicamente la herramienta de línea de comandos de cada una: ‘oc’ para Openshift y ‘kubectl’ para Kubernetes; y poco más).

En este caso la solución que hemos escogido es utilizar un Openshift instalado en mi máquina local, para ello utilizaremos MiniShift, que nos permite levantar un cluster de un solo nodo sobre una máquina virtual.

Aquí podéis encontrar toda la documentación necesaria sobre el mismo y las instrucciones para arrancarlo. Está inspirado en minikube, la solución para ejecutar Kubernetes de forma local.

Para la instalación de Istio hemos utilizado la versión 0.4.0 y hemos seguido los pasos indicados en el siguiente artículo del blog de Openshift.

Las instrucciones de instalación también se pueden encontrar en la propia documentación de Istio, que puede instalarse sobre diversas plataformas, desde el propio Kubernetes pasando por entornos basados en Consul o Eureka, hasta en CloudFoundry o Mesos.

Istio incluye una aplicación de ejemplo que nos permite probar la funcionalidad del mismo, así como realizar los diversos ejemplos incluidos en su web. La arquitectura de la aplicación es la siguiente:

Si nos fijamos en la misma, podemos ver que se trata de varios microservicios, cada uno desarrollado en un lenguaje diferente y en el caso concreto de ‘reviews’ con tres versiones del mismo desplegadas. Si queréis conocer más en detalle la aplicación de ejemplo podéis encontrar información aquí.

El proceso de instalación, tanto de Minishift como de Istio y la aplicación de ejemplo, es realmente rápido, en menos de 15 minutos podemos tenerlo todo funcionando.

No voy a entrar en detalle, simplemente quiero remarcar los siguientes puntos relevantes:

oc apply -f 

Tell us what you think.

Los comentarios serán moderados. Serán visibles si aportan un argumento constructivo. Si no estás de acuerdo con algún punto, por favor, muestra tus opiniones de manera educada.

Enviar.
Goodly logo