Llevamos unos días hablando de Microservicios y recordando que teneis disponible el curso de Microservicios y Orquestación .

Además hoy vamos a hablar sobre tres de los “ orquestadores ” que se verán en el curso, siendo por otro lado los más demandados y utilizados hoy día en el mercado laboral. Docker Swarm, CoreOS Fleet y Kubernetes son tres rivales que compiten hoy día en entornos de clustering y contenedores cada vez más extendidos.

En cada uno encontraremos ventajas e inconvenientes, ahí es donde entra la libre competencia que se suponen unos a otros. Dependiendo de la infraestructura, de los recursos que se le vaya a dedicar, del administrador al cargo y su experiencia, entre otros factores, será más recomendado un sistema u otro, cumpliendo todos con una labor principal y común; facilitar el despliegue, gestión de instancias, mantenimiento y distribución de los recursos disponibles, agilizando así la labor del personal encargado de estas tareas pudiendo destinar ese tiempo ahorrado a continuar produciendo nuevos contenedores más ágiles, nuevas vías de comunicación, etc…

Pasemos pues a conocer a los tres contendientes:

Swarm

Swarm es la solución nativa de clustering en Docker , haciendo uso de la API de éste los contenedores pueden ser lanzados utilizando los comandos comunes de Docker mientras que Swarm se encarga de localizar un anfitrión apropiado para el despliegue del contenedor elegido.

Esto significa también que otras herramientas que utilicen la API de Docker podrán disponer de Swarm para gestionar sus contenedores, sin necesidad de conocer el funcionamiento de ninguna otra aplicación para este menester.

La arquitectura básica de Swarm es bastante simple puesto que cada host ejecuta un servicio Swarm y un gestor Swarm; quien se encargará de la orquestación y la programación de los contenedores en los hosts.

Además Swarm se puede ejecutar en modo alta disponibilidad donde etcd, Consul o Zookeeper son usados para gestionar la conmutación entre diferentes contenedores en caso de error, como por ejemplo si se detecta algún fallo realizar una copia de seguridad en un contenedor disponible a tal efecto.

Uno de entre los múltiples sistemas existentes para localizar, añadir o retirar hosts a un clúster se conoce como Descubrimiento en Swarm (Discover on Swarm), donde se establece que el listado de las direcciones de los equipos anfitriones permanezca almacenada en uno de los ejes centrales del entramado, conocido como Docker Hub.

Fleet

Fleet es la herramienta de administración de clústeres implementada en el sistema operativo CoreOS , autodescribiéndola sus desarrolladores como un motor de clusterización de bajo nivel, lo que podría significar que nos encontramos ante una capa de cimentación para soluciones de más alto nivel como Kubernetes.

Nada más lejos de la realidad. La característica más distintiva de Fleet es que se basa en la parte superior de SystemD, proporcionando la estabilidad y servicios de éste como si hacia una sola máquina se dirigiese, mientras que Fleet extendería estas características a todos los contenedores que se gestionasen. Fleet lee los ficheros de la unidad SystemD que luego son programados en una o varias máquinas dentro del clúster.

En el gestor Fleet, cada máquina funciona con un motor y agente independiente. Aunque los servicios de los clústeres estén activos, sólo uno de dichos motores estará activo en todo momento en el clúster, por lo que la cantidad de recursos que supondrá serán más que asequibles.

SystemD será quien lleve los archivos a gestionar a dicho motor activo y éste será el encargado de orquestar el trabajo a la máquina o contenedor correspondiente o con menos carga de trabajo. Por norma general sólo se implica a un contenedor para la gestión y reparto de trabajo, y es el gestor Fleet quien se encarga de iniciar la máquina y generar los informes de seguimiento o monitorización de la misma, quedando etcd para promover la comunicación entre las diferentes máquinas activas en el clúster y almacenar el estado tanto de las máquinas individualmente como del clúster al completo.

Una de las grandes ventajas de Fleet es su alta tolerancia a fallos, ya que en cuanto se detecta que una máquina ha caído, se reiniciará en un nuevo contenedor que replicará su último estado conocido y continuará el trabajo prácticamente en el punto en el que comenzó a fallar.

Además también estamos ante un sistema que admite inicio por conexión a socket, o lo que es lo mismo, cuando se detecta que un paquete llega a un puerto determinado es cuando se iniciará el servicio que tenemos en dicho puerto, por lo que este servicio no estará consumiendo recursos constantemente si no que únicamente lo hará cuando sea necesario y se le solicite.

Imagen 0 en Orquestación: Swarm vs Fleet vs Kubernetes

Kubernetes

Kubernetes es una herramienta de orquestación de contenedores desarrollada por Google basándose en sus experiencias y necesidades del uso de contenedores en producción durante los últimos años.

Puede no ser tan flexible como Swarm o Fleet, ya que nos requiere conocer algunos conceptos previos en torno a cómo organiza y conecta los contenedores.

Pods : Se trata de grupos de contenedores que se implementan y coordinan juntos. Forman la mínima unidad admitida por Kubernetes a diferencia de los contenedores individuales que predominan en los otros contendientes de este careo.

Estos Pods se compondrán de 1 a 5 contenedores que trabajarán en consonancia para ejecutar un servicio, pero además de los que nosotros como usuarios iniciemos, Kubernetes automáticamente iniciará contenedores extra que se encargarán de los servicios de registro y seguimiento de los contenedores que hemos iniciado.

Cabe destacar que los Pods son efímeros, por lo que tendremos que esperar a que se generen y desplieguen cada vez que los llamemos a escena.

Flat networking space : O red plana de trabajo es el sistema con el que se comunicarán los diferentes conjuntos de contenedores entre sí, que al ser plano como su propio nombre indica, facilita el que todos los Pods se puedan comunicar entre sí sin ningún tipo de problema favoreciendo así su administración desde el host.

Etiquetas : Encontraremos como etiquetas denominadores pares definidos como clave-valor que nos ayudaran a identificar ante qué objeto estamos y qué características tiene (por ejemplo, Version y nivel: dev-backend. Suelen identificar Pods (grupos de contenedores) facilitando así la agrupación de tareas o asignación de Pods para el balanceo de carga de trabajo.

Servicios : Son objetivos finales definidos que pueden ser llamados por su nombre, conectándose a los Pods mediante el uso o vinculación de etiquetas (por ejemplo, un servicio “caché” se conectará a todos los Pods identificados con la etiqueta “buffer” y la carga de este servicio aplicará un protocolo de diversificación del trabajo de tipo Round Robin (o distribución por rondas) entre todos los contenedores a su disposición.

Controladores de Réplicas : Pieza clave en Kubernetes, ya que se encargará de generar el número de Pods necesarios para que un servicio se lleve a cabo eficientemente, generando réplicas de una instancia de Pods en caso de que las solicitudes sobrepasen la carga máxima actual y eliminando Pods cuando estas peticiones al servicio disminuyan, aprovechando siempre los recursos disponibles del cluster en el servicio que más los requiera.

Y hasta aquí este cara a cara, pero no se ha acabado, podréis ampliar toda esta información en el curso de Microservicios y Orquestación de Openwebinars , y conseguir dominar una tecnología de futuro, como os decía en un post anterior, por algo gigantes como Netflix, Amazon o Ebay han sido de las primeras compañías en incluir esta metodología en sus sistemas en producción.