Saltar al contenido

Nomad vs Kubernetes: 1 contendiente emergente desafiando al rey probado

Nomad es la alternativa de Hashicorp al patrón típico de usar una plataforma basada en Kubernetes como la única forma de orquestar tus cargas de trabajo de manera eficiente. Nomad es un proyecto iniciado en 2019, pero está ganando mucha más relevancia hoy en día después de 95 lanzamientos, y la versión actual de este artículo es 1.4.1, como puedes ver en su perfil de GitHub.

Nomad aborda los desafíos tradicionales de aislar el ciclo de vida de la aplicación para el ciclo de vida de operación de la infraestructura donde reside esa aplicación. Sin embargo, en lugar de ir completamente a una aplicación basada en contenedores, intenta proporcionar una solución de manera diferente.

¿Cuáles son las principales características de Nomad?

Basado en su propia definición, como puedes leer en su perfil de GitHub, ya destacan algunos de los puntos de diferencia con respecto al estándar de facto de la industria:

Nomad es un orquestador de cargas de trabajo fácil de usar, flexible y de alto rendimiento que puede desplegar una mezcla de aplicaciones de microservicios, por lotes, contenedorizadas y no contenedorizadas

Fácil de usar: Esta es la primera afirmación que incluyen en su definición porque el enfoque de Nomad es mucho más simple que alternativas como Kubernetes porque funciona con un enfoque de binario único donde tiene todas las capacidades necesarias ejecutándose como un agente de nodo basado en su propio «vocabulario» que puedes leer más en su documentación oficial.

Flexibilidad: Esta es la otra cosa crítica que proporcionan, un hipervisor, una capa intermedia entre la aplicación y la infraestructura subyacente. No se limita solo a aplicaciones de contenedores, sino que también admite este tipo de despliegue. También permite desplegarlo como parte de un enfoque tradicional de máquina virtual. Los casos de uso principales destacados son ejecutar aplicaciones estándar de Windows, lo cual es complicado cuando se habla de despliegues de Kubernetes; aunque los contenedores de Windows han sido una cosa durante mucho tiempo, su adopción no está al mismo nivel, como puedes ver en el mundo de los contenedores de Linux.

Integración con Hashicorp: Como parte del portafolio de Hashicorp, también incluye una integración perfecta con otros proyectos de Hashicorp como Hashicorp Vault, que hemos cubierto en varios artículos, o Hashicorp Consul, que ayuda a proporcionar capacidades adicionales en términos de seguridad, gestión de configuración y comunicación entre las diferentes cargas de trabajo.

Nomad vs Kubernetes: ¿Cómo funciona Nomad?

Como se comentó anteriormente, Nomad cubre todo con un enfoque de componente único. Un binario de Nomad es un agente que puede trabajar en modo servidor o modo cliente, dependiendo del rol de la máquina que lo ejecuta.

Así que Nomad se basa en un clúster de Nomad, un conjunto de máquinas que ejecutan un agente de Nomad en modo servidor. Esos servidores se dividen dependiendo del rol de líder o seguidores. El líder realiza la mayor parte de la gestión del clúster, y los seguidores pueden crear planes de programación y enviarlos al líder para su aprobación y ejecución. Esto se representa en la imagen a continuación de la página oficial de Hashicorp Nomad:

Nomad vs Kubernetes: 1 Contendiente Contra el Rey de la Orquestación
Arquitectura simple de Nomad de nomadproject.io

Una vez que tenemos el clúster listo, necesitamos crear nuestros trabajos, y un trabajo es una definición de la tarea que nos gustaría ejecutar en el clúster de Nomad que hemos configurado previamente. Una tarea es la unidad de trabajo más pequeña en Nomad. Aquí es donde la flexibilidad llega a Nomad porque el controlador de tareas ejecuta cada tarea, permitiendo que diferentes controladores ejecuten varias cargas de trabajo. Así es como siguiendo el mismo enfoque, tendremos un controlador de Docker para ejecutar nuestro despliegue de contenedores o un controlador de ejecución para ejecutarlo sobre una infraestructura virtual. Aún así, puedes crear tus controladores de tareas siguiendo un mecanismo de complementos que puedes leer más sobre aquí.

Los trabajos y las tareas se definen utilizando un enfoque basado en texto, pero no siguiendo el tipo habitual de archivos YAML o JSON, sino un formato diferente, como puedes ver en la imagen a continuación (haz clic aquí para descargar el archivo completo del repositorio de muestras de GitHub Nomad):

 ¿Es Nomad un reemplazo para Kubernetes?

Nomad vs Kubernetes: 1 Contendiente Contra el Rey de la Orquestación

Es una pregunta compleja de responder, e incluso Hashicorp ha documentado diferentes estrategias. Sin duda, puedes usar Nomad para ejecutar despliegues basados en contenedores en lugar de ejecutarlos en Kubernetes. Pero al mismo tiempo, también posicionan la solución junto a Kubernetes para ejecutar algunas cargas de trabajo en una solución y otras en la otra.

Al final, ambos intentan resolver y abordar los mismos desafíos en términos de escalabilidad, compartición y optimización de infraestructura, agilidad, flexibilidad y seguridad de los despliegues tradicionales.

Kubernetes se centra en diferentes tipos de cargas de trabajo, pero todo sigue el mismo modo de despliegue (basado en contenedores) y adopta paradigmas recientes (basados en servicios, patrones de microservicios, liderados por API, etc.) con una arquitectura robusta que permite una excelente escalabilidad, rendimiento, flexibilidad y con niveles de adopción en la industria que se ha convertido en la única alternativa de facto actual para plataformas modernas de orquestación de cargas de trabajo.

Pero, al mismo tiempo, también requiere esfuerzo en la gestión y transformación de aplicaciones existentes a nuevos paradigmas.

Por otro lado, Nomad intenta abordarlo de manera diferente, minimizando el cambio de la aplicación existente para aprovechar los beneficios de la plataforma y reduciendo la sobrecarga de gestión y complejidad que una plataforma de Kubernetes habitual proporciona, dependiendo de la situación.

Nomad vs Kubernetes: 1 Emerging Contestant Defying The Proven King

Nomad is the Hashicorp alternative to the typical pattern of using a Kubernetes-based platform as the only way to orchestrate your workloads efficiently. Nomad is a project started in 2019, but it is getting much more relevant nowadays after 95 releases, and the current version of this article is 1.4.1, as you can see in their GitHub profile.

Nomad approaches the traditional challenges of isolating the application lifecycle for the infrastructure operation lifecycle where that application resides. Still, instead of going full to a container-based application, it tries to provide a solution differently.

What are the main Nomad Features?

Based on its own definition, as you can read on their GitHub profile, they already highlight some of the points of difference between the de-facto industry standard:

Nomad is an easy-to-use, flexible, and performant workload orchestrator that can deploy a mix of microservice, batch, containerized, and non-containerized applications

Easy-to-use: This is the first statement they include in their definition because the Nomad approach is much simpler than alternatives such as Kubernetes because it works on a single-binary approach where it has all the capabilities that are needed running as a node agent based on its own “vocabulary” that you can read more of it in their official documentation.

Flexibility: This is the other critical thing they provide a hypervisor, an intermediate layer between the application and the underlying infrastructure. It is not just limited to container applications but also supports this kind of deployment. It also allows the deploy it as part of a traditional virtual machine approach. The primary use cases highlighted are running standard windows applications, which is tricky when talking about Kubernetes deployments; even though Windows containers have been a thing for so long, their adoption is not at the same level, as you can see in the Linux container world.

Hashicorp Integration: As part of the Hashicorp portfolio, it also includes seamless integration with other Hashicorp projects such as Hashicorp Vault, which we have covered in several articles, or Hashicorp Consul, which helps to provide additional capabilities in terms of security, configuration management, and communication between the different workloads.

Nomad vs Kubernetes: How Nomad Works?

As commented above, Nomad covers everything with a single-component approach. A nomad binary is an agent that can work in server mode or client mode, depending on the role of the machine executing it.

So Nomad is based on a Nomad cluster, a set of machines running a nomad agent in server mode. Those servers are split depending on the role of the leader or followers. The leader performs most of the cluster management, and the followers can create scheduling plans and submit them to the leader for approval and execution. This is represented in the picture below from the Hashicorp Nomad official page:

Nomad vs Kubernetes: 1 Contestant Against the Orchestration King
Nomad simple architecture from nomadproject.io

Once we have the cluster ready, we need to create our jobs, and a job is a definition of the task we would like to execute on the Nomad cluster we have previously set up. A task is the smallest unit of work in Nomad. Here is where the flexibility comes to Nomad because the task driver executes each task, allowing different drivers to execute various workloads. This is how following the same approach, we will have a docker driver to run our container deployment or an exec driver to execute it on top of a virtual infrastructure. Still, you can create your task drivers following a plugin mechanism that you can read more about here.

Jobs and Task are defined using a text-based approach but not following the usual YAML or JSON kind of files but a different format, as you can see in the picture below (click here to download the whole file from the GitHub Nomad Samples repo):

 Is Nomad a Replace for Kubernetes?

Nomad vs Kubernetes: 1 Contestant Against the Orchestration King

It is a complex question to answer, and even Hashicorp they have documented different strategies. You can undoubtedly use Nomad to run container-based deployments instead of running them on Kubernetes. But at the same time, they also position the solution alongside Kubernetes to run some workloads on one solution and another on the other.

In the end, both try to solve and address the same challenges in terms of scalability, infrastructure sharing and optimization, agility, flexibility, and security from traditional deployments.

Kubernetes focus on different kind of workloads, but everything follows the same deployment mode (container-based) and adopts recent paradigms (service-based, microservice patterns, API-led, and so on) with a robust architecture that allows excellent scalability, performance, flexibility, and with adoption levels in the industry that has become the current de-facto only alternative for modern workload orchestration platforms.

But, at the same time, it also requires effort in management and transforming existing applications to new paradigms.

On the other hand, Nomad tries to address it differently, minimizing the change of the existing application to take advantage of the platform’s benefits and reducing the overhead of management and complexity that a usual Kubernetes platform provides, depending on the situation.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *