Microservicios con kubernetes

Introducción

La manera en la se desplegaban las aplicaciones antiguamente era mediante la intalación en un servidor usando el administrador de paquetes del sistema operativo y usualmente se recurría a máquinas virtuales para escalar la aplicación. La desventaja de realizarlo de esta manera, es que los ejecutables, la configuración, las librerías y el ciclo de vida de todos estos componentes se entretejían unos a otros, además de que las máquinas virtuales consumen muchos recursos. Para solucionar estas deventajas se creó el concepto de contenedor.

Un contenerdor es una virtualización a nivel del sistema operativo que permite empaquetar un software con todas sus dependecias. Estos contenedores están aislados entre ellos y con el servidor anfitrión: tienen sus propios sistemas de archivos, no ven los procesos de los demás y el uso de recursos puede ser limitado. Son más fáciles de construir que una máquina virtual, y porque no están acoplados a la infraestructura y sistema de archivos del anfitrión, pueden llevarse entre nubes y distribuciones de sistema operativo.

Con esta nueva tecnología se emepezaron a desarrollar aplicaciones orientadas a microservicios, es decir, que la arquitectura del software en desarrollo se constituye de comunicaciones entre servidores que por lo general ofrecen un tipo de servicio.

Pero a medida que crece la aplicación también aumentan los servicios que lo componen, volviendo así más complejo controlar, monitorear y administrar todos los contenedores que componen la aplicación, en algunos casos es hasta imposible realizarlo. Es por eso que se desarrolló otra tecnología conocida como orquestador de contenedores, el cual se encarga de administrar y monitorear los contenedores tratando siempre de llevarlos a un estado deseado.

Existen varios orquetadores de contenedores, pero para efectos de este blog se analizará el orquestador de kubernetes.

¿Qué es kubernetes?

Kubernetes es una plataforma portable y extensible de código abierto para administrar cargas de trabajo y servicios. Facilita la automatización y la configuración declarativa. Tiene un ecosistema grande y en rápido crecimiento. El soporte, las herramientas y los servicios para Kubernetes están ampliamente disponibles.

Kubernetes ofrece un entorno de administración centrado en contenedores. Orquesta la infraestructura de cómputo, redes y almacenamiento para que las cargas de trabajo de los usuarios no tengan que hacerlo.

Puedes pensar en Kubernetes como:

• Una plataforma de contenedores.
• Una plataforma de microservicios.
• Una plataforma portable de nube.

Kubernetes ofrece a una aplicación las siguientes características:

• Alta disponibilidad.
• Escalabilidad.
• Recuperación ante fallas.

Componentes de kubernetes

Ahora se analizaran los componentes u objetos de kubernetes, que son de uso más común en el desarrollo de una aplicación. Para efectos de este blog analizaremos los componentes bajo el contexto de una aplicación simple.

La aplicación está constituida por un cliente y un servidor; esta consiste en ofrecer al usuario un servicio para guardar tareas (Todo-App). De esta manera un usuario se registra, inicia sesión, crea tareas, las edita o bien las elimina.

La siguiente figura muestra el diagrama de arquitectura de la aplicación con los componentes de kubernetes involucrados.

• Pod: Son una abstracción de los contenedores, pueden tener uno o varios contenedores dentro de ellos.
• Deployment: Este componente se encarga del despligue de los pods, es decir, los crea con las características asignadas. Es un tipo de replicación para pods Stateless, o que no requieren ser consistentes con los datos.
• Service: Es un componente que expone el acceso a un pod. Normalmente una aplicación no interactúa directamente con un pod, debido a que estos pueden ser destruidos en cualquier momento. Por otro lado un servicio es estable y se mantiene ante fallos.
• Ingress: Es un enrutador de servicios, funciona como un API-Gateway para aplicaciones.
• Persistent Volume: Es un componente que permite guardar la información, para posteriormente recuperarla. Debido a que los pods son mortales, cuando desaparecen y vuelven a ser desplegados, la información anterior ya no está. Por lo que este componenete permite recuperar la información evitando pérdidas de información.
• Persistent Volume Claim: Es el componente que permite encontrar las características adecuadas de almacenamiento y seleccionarlo. Dado que pueden haber muchos Persistent Volume definidos en un nodo, este componente permite encontrar el adecuado para aplicación.
• Stateful Set: Este componente es similar al Deployment, pero para pods que son Stateful o requieren ser consistentes con los datos, como lo son las base de datos. Por lo tanto, cuando se realiza el despliegue de pods, se asegura que la información sea recuperable.
• Config Map: Contiene la información de la URL de la base de datos, de esta manera un servicio sabe a cual base de datos debe consultar.
• Secret: Contiene la información de autenticación de una base de datos, como el nombre de usuario y la contraseña, ambos datos deben ser encriptados en Base64 para mantener segura la información.
• Namespace: Todos estos componentes anteriormente descritos son archivos configurables de extensión .yml, dichos archivos se pueden agrupar dentro de otro archivo llamado namespace. Esto permite organizar mejor los componentes que constituyen la aplicación.

Acontiuación se describe el flujo de la aplicación presentada en la figura anterior.

• Se introduce la información desde el browser.
• La consulta se realiza desde el Pod del cliente.
• La información pasa por el Service del cliente en dirección al servidor.
• El servidor contiene un Ingress por donde pasa toda consulta.
• El Ingress determina cual servicio es consultado y lo direcciona hacia él.
• El Service del servidor direcciona el Pod del servidor.
• El servidor opera la consulta según el endpoint y requiere la base de datos.
• El Pod del servidor direcciona al ConfigMap.
• El ConfigMap obtiene la URL y solicita los credenciales al Secret.
• El Secret brinda los credenciales al ConfigMap y este direcciona al Pod de la base de datos.
• La base de datos reclama los datos al PersistenVolumeClaim.
• El PersistenVolumeClaim busca el PersistenVolume adecuado y obtiene/guarda los datos.
• La base de datos obtiene los datos y los envía al Pod del servidor.
• El Pod del servidor envía la información al Service del servidor y este lo envía al Ingress.
• El Ingress envía la información al Service del cliente.
• El Service del cliente direcciona al Pod del cliente.
• El Pod del cliente procesa la información y la muestra al usuario por medio del browser.

Si un Pod es destruido, por medio de los Deployment o StatefulSet son restituidos. Para el caso de Pods que requieren ser stateful, con ayuda de los PersistentVolumeClaim y PersistentVolumen recuperan la información.

Arquitectura de Kubernetes

En esta sección se analizará la arquitectura de kubernetes para conocer cómo es que funciona esta tecnología. La siguiente figura muestra el diragrama de dicha arquitectura.

• Nodo (Kubernetes minions): Es donde se instancian los Pods para que se ejecuten. Un nodo puede tener uno o muchos Pods según su capacidad definida.
• Kubelet: Es la interfaz de comunicación entre el motor de contenedores (por ejemplo Docker) y el motor del nodo, es decir, es quien hace posible que los contenedores se ejecuten dentro del nodo.
• Kube-proxy: Permite abstraer un servicio en Kubernetes manteniendo las reglas de red en el anfitrión y haciendo reenvío de conexiones.
• Master (Kubernetes master): Es el nodo maestro, es quien se encarga de controlar y monitorear el estado de los nodos y su contenido. Está constituido por 5 grandes componentes.
• Kube-apiserver: Es el componente que expone el uso de kubernetes al cliente, es decir, es un frontend que recibe las peticiones.
• Etcd: Almacén de datos persistente, consistente y distribuido de clave-valor utilizado para almacenar toda la información del clúster de Kubernetes.
• Kube-scheduler: Componente del plano de control que está pendiente de los Pods que no tienen ningún nodo asignado y selecciona uno donde ejecutarlo. Para decidir en qué nodo se ejecutará el pod, se tienen en cuenta diversos factores: requisitos de recursos, restricciones de hardware/software/políticas, afinidad y anti-afinidad, localización de datos dependientes, entre otros.
• Kube-controller-manager: Componente del plano de control que ejecuta los controladores de Kubernetes. Estos controladores incluyen: Controlador de nodos: es el responsable de detectar y responder cuándo un nodo deja de funcionar. Controlador de replicación: es el responsable de mantener el número correcto de pods para cada controlador de replicación del sistema. Controlador de endpoints: construye el objeto Endpoints, es decir, hace una unión entre los Services y los Pods. Controladores de tokens y cuentas de servicio: crean cuentas y tokens de acceso a la API por defecto para los nuevos Namespaces.
• Cloud-controller-manager: Ejecuta controladores que interactúan con proveedores de la nube.

Básicamente se puede decir que un nodo envía y recibe datos del maestro al mismo tiempo que ejecuta la configuración dada por el usuario para crear los pods y sus comunicaciones. Por medio de la inteface de kubelet es posible ejecutar los contenedores dentro del nodo. Por otro lado el maestro se encarga de controlar y monitorear los estados de los nodos y sus componentes al mismo tiempo que sirve de interface de comunicación con el proveedor en la nube.

A un conjunto de nodos se le llama cluster.

Proveedores en la nube

Para comparar cual proveedor en la nube es más conveniente para una aplicación por desarrollar, hay que considerar algunos factores como:

• Versiones.
• Tiempo en crear nodos o clusters.
• Recursos como CPUs y RAM.
• Tiempo en desplegar una aplicación.
• Costo.

Las siguientes imagenes fueron tomadas de aquí. La intensión es utilizarlas como fuente de información para esta entrada, en donde se compararan los 3 principales proveedores en la nube, a saber, Google Cloud, Amazon Web Server, Microsoft Azure.

La siguiente imagen muestra la información en cuanto a versiones de kubernetes soportadas por los proveedores.

La comparación en tiempo para crear tres nodos es la siguiente.

En cuanto al tiempo que toman en levantar una aplicación (en este caso Prometheus) se obtiene el siguiente resultado.

Finalmente se dá la comparación en cuanto a recursos y los costos. La imagen fue tomada de aquí.

Ahora existen comparaciones más técnicas entre los proveedores en la nube que pueden ser tomadas en cuenta a la hora de decidir cual provedor usar, las sigueintes imagenes fuero tomadas de este estudio.

Conclusiones

En esta entrada se analizó como es que funciona kubenetes por medio de su arquitectura, en donde básicamente se evidencia la existencia de un nodo maestro que controlo y monitorea los nodos esclavos por medio de 5 componenetes principales, uno de ellos encargado de servir de interface con el proveedor en la nube.

Además se analizó como se contituye una aplicación usando componentes de kubernetes como Deployment y StatefulSet que describen como una aplicación debe correr y los Services que describen como una aplicación debe ser expuesta y otros como PersistenVolumes para alamacenar información y no perderla cuando un Pod falla y es reemplazado por otro o Ingress que funciona como un API Gateway que enruta todo el tráfico a los servicios requeridos.

Por último se brindó una comparación entre los 3 proveedores princiapales de kubernetes en la nube, examinando los principales factores como recursos y costos, tiempos de construcción o creación de nodos y levantamiento de aplicaciones, versiones y más comparaciones a nivel técnico como mantenimiento, redes, seguridad y limites del servicio.

Finalmente sobre lo proveedores en la nube se puede decir que el más integro o desarrollado es Google Cloud Plataform, esto según la información de las tablas. AWS es el menos administrado por defecto, sin embargo se puede mejorar por medio de Addons, lo que implica más costo. Además AKS y EKS requieren mejoras en la automatización del servicio.