Chica en una moto. Ilustración de freepik , logotipo de Nomad por HashiCorpKubernetes es un gorila de 300 kg para orquestación de contenedores. Funciona en algunos de los sistemas de contenedores más grandes del mundo, pero es costoso.
Especialmente costoso para equipos pequeños que tienen que dedicar mucho tiempo a la asistencia y una curva de aprendizaje empinada. Para nuestro equipo de cuatro, esto es demasiado sobrecarga. Así que comenzamos a buscar alternativas, y nos enamoramos de
Nomad .
Que quieres
Nuestro equipo admite una serie de servicios típicos para monitorear y analizar el rendimiento: puntos finales de API para métricas Go, exportación de Prometheus, analizadores de registros como Logstash y
Gollum , así como bases de datos como InfluxDB o Elasticsearch. Cada uno de estos servicios se ejecuta en su propio contenedor. Necesitamos un sistema simple para mantener todo esto operativo.
Comenzamos con una lista de requisitos para la organización de contenedores:
- Inicie un conjunto de servicios en muchas máquinas.
- Descripción general de los servicios en ejecución.
- Comunicación entre servicios.
- Reinicio automático si el servicio falla.
- Mantenimiento de infraestructura por un pequeño equipo.
Además, las siguientes cosas serán buenas, pero no adiciones obligatorias:
- Máquinas de marcado según sus capacidades (por ejemplo, máquinas de marcado con discos rápidos para servicios de E / S pesados).
- La capacidad de iniciar servicios independientemente de la orquesta (por ejemplo, durante el desarrollo).
- Un lugar común para compartir configuraciones y secretos.
- Punto final para métricas y registros.
Por qué Kubernetes no nos conviene
Al crear un prototipo con Kubernetes, notamos que comenzamos a agregar capas de lógica cada vez más complejas, en las que confiamos incondicionalmente.
Como ejemplo, Kubernetes admite configuraciones de servicio
integradas a través de
ConfigMaps . Puede confundirse rápidamente, especialmente cuando combina varios archivos de configuración o agrega servicios adicionales al pod. Kubernetes (o
timón en este caso) le permite implementar configuraciones dinámicamente externas para separar intereses. Pero esto lleva a una conexión encubierta entre su proyecto y Kubernetes. Sin embargo, Helm y ConfigMaps son opciones adicionales, por lo que no tiene que usarlas. Simplemente puede copiar la configuración a la imagen de Docker. Sin embargo, es tentador seguir esta ruta y construir abstracciones innecesarias, de las cuales puede arrepentirse más tarde.
Además, el ecosistema de Kubernetes está creciendo rápidamente. Se necesita mucho tiempo y energía para mantenerse al día con las mejores prácticas y las últimas herramientas. Kubectl, minikube, kubeadm, helm, tiller, kops, oc - la lista sigue y sigue. Al comienzo del trabajo, no todas estas herramientas son necesarias, pero usted no sabe lo que se necesita, por lo que debe estar al tanto de todo. Debido a esto, la curva de aprendizaje es bastante empinada.
Cuando usar Kubernetes
En nuestra empresa, muchos usan Kubernetes y están muy contentos con él. Estas instancias son administradas por Google o Amazon, que tienen suficientes recursos de soporte.
Kubernetes viene con
características sorprendentes que lo hacen más manejable y la orquestación de contenedores a gran escala:
La pregunta es si realmente necesita todas estas características. No puedes confiar solo en la abstracción;
tienes que averiguar lo que sucede debajo del capó .
Nuestro equipo proporciona la mayoría de los servicios de forma remota (debido a la estrecha conexión con la infraestructura principal), por lo que no queríamos crear nuestro propio clúster de Kubernetes. Solo queríamos brindar servicios.
Pilas no incluidas
Nomad es el 20% de la orquestación, lo que da el 80% de lo necesario. Todo lo que hace es administrar implementaciones. Nomad se encarga de las implementaciones, reinicia los contenedores en caso de errores ... y eso es todo.
El objetivo de Nomad es que hace un
mínimo : no se concibe una gestión de derechos detallada ni
políticas de red avanzadas . Estos componentes son proporcionados o no provistos en absoluto.
Creo que Nomad ha encontrado el compromiso perfecto entre facilidad de uso y utilidad. Es bueno para servicios pequeños e independientes. Si necesita más control, tendrá que criarlos usted mismo o utilizar un enfoque diferente. Nomad es
solo una orquesta.
Lo mejor de Nomad es que es fácil
de reemplazar . Prácticamente no hay enlace para el proveedor, ya que sus funciones se integran fácilmente en cualquier otro sistema que gestione los servicios. Funciona como un binario normal en cada máquina en un clúster, ¡eso es todo!
Ecosistema nómada de componentes sueltos
El verdadero poder de Nomad en su ecosistema. Se integra muy bien con otros productos, completamente opcionales, como
Consul (almacenamiento de valor clave) o
Vault (procesamiento de secretos). Dentro del archivo Nomad hay secciones para extraer datos de estos servicios:
template { data = <<EOH LOG_LEVEL="{{key "service/geo-api/log-verbosity"}}" API_KEY="{{with secret "secret/geo-api-key"}}{{.Data.value}}{{end}}" EOH destination = "secrets/file.env" env = true }
Aquí leemos el
service/geo-api/log-verbosity
clave
service/geo-api/log-verbosity
de Consul y en el proceso lo representamos con la variable de entorno
LOG_LEVEL
. También representamos la
secret/geo-api-key
de Vault como
API_KEY
. Simple pero poderoso!
Debido a su simplicidad, Nomad es fácilmente extensible a través de otros servicios a través de la API. Por ejemplo, se admiten etiquetas para tareas. Etiquetamos todos los servicios con métricas con la etiqueta
trv-metrics
. Por lo tanto, Prometheus encuentra fácilmente estos servicios a través de Consul y verifica periódicamente el punto final
/metrics
para obtener nuevos datos. Lo mismo se puede hacer, por ejemplo, para los registros que utilizan
Loki .
Hay muchos otros ejemplos de extensibilidad:
- Al ejecutar el trabajo de Jenkins con un gancho, el Cónsul realiza un seguimiento de la reinstalación del trabajo de Nomad cuando cambia la configuración del servicio.
- Ceph agrega un sistema de archivos distribuido a Nomad.
- fabio para balanceo de carga.
Todo esto le permite
desarrollar orgánicamente la infraestructura sin ningún vínculo particular con el proveedor.
Advertencia honesta
Ningún sistema es perfecto. No recomiendo introducir de inmediato las últimas funciones en producción. Por supuesto, hay errores y características faltantes, pero lo mismo ocurre con Kubernetes.
En comparación con Kubernetes, la comunidad nómada no es tan grande. Kubernetes ya tiene alrededor de 75,000 confirmaciones y 2,000 contribuyentes, mientras que Nomad tiene alrededor de 14,000 confirmaciones y 300 contribuyentes. Nomad tendrá dificultades para mantenerse al día con Kubernetes en velocidad, ¡pero tal vez esto no sea necesario! Este es un sistema más especializado y una comunidad más pequeña también significa que es más probable que su solicitud de extracción sea notada y aceptada que Kubernetes.
Resumen
Conclusión: No use Kubernetes solo porque todos lo hacen. Evalúe cuidadosamente sus requisitos y verifique qué herramienta es más rentable.
Si planea implementar una tonelada de servicios homogéneos en una infraestructura a gran escala, entonces Kubernetes es una buena opción. Solo recuerde la complejidad adicional y los costos de mantenimiento. Algunos de los costos se pueden evitar mediante el uso de un entorno administrado de Kubernetes como
Google Kubernetes Engine o
Amazon EKS .
Si solo está buscando un orquestador confiable, fácil de soportar y expandible, ¿por qué no prueba Nomad? Te preguntarás hasta dónde te llevará esto.
Si compara Kubernetes con un automóvil, Nomad será un scooter. A veces necesitas uno, y a veces otro. Ambos tienen derecho a existir.