Chica en scooter. Ilustración , logotipo de Nomad de
Kubernetes es el gorila de 300 libras de la orquestación de contenedores. Funciona en algunos de los sistemas de contenedores más grandes del mundo, pero es caro.
Particularmente costoso para equipos más pequeños, que requerirán mucho tiempo de soporte y una curva de aprendizaje pronunciada. Esto es demasiado para nuestro equipo de cuatro. Así que empezamos a buscar alternativas y nos enamoramos de ellas. .
Qué deseas
Nuestro equipo admite una serie de servicios comunes de análisis y supervisión del rendimiento: puntos finales API para métricas escritas en Go, exportaciones de Prometheus, analizadores de registros como Logstash y , 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 que todo siga funcionando.
Comenzamos con una lista de requisitos para la orquestación de contenedores:
- Ejecutar un conjunto de servicios en muchas máquinas.
- Descripción general de los servicios en ejecución.
- Enlaces entre servicios.
- Reinicio automático si el servicio se cae.
- Mantenimiento de infraestructura por un pequeño equipo.
Además, las siguientes cosas serán adiciones agradables, pero no obligatorias:
- Etiquetar máquinas según sus capacidades (por ejemplo, etiquetar máquinas con discos rápidos para servicios de E/S pesados).
- Capacidad para ejecutar servicios independientemente del orquestador (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 es adecuado para nosotros
Mientras creamos prototipos con Kubernetes, notamos que estábamos agregando capas de lógica cada vez más complejas en las que confiábamos en gran medida.
Por ejemplo, Kubernetes admite configuraciones de servicios integradas a través de . Puede confundirse rápidamente, especialmente al fusionar varios archivos de configuración o agregar servicios adicionales a un pod. Kubernetes (o en este caso) le permite implementar dinámicamente configuraciones externas para separar preocupaciones. Pero esto da como resultado un acoplamiento estrecho y oculto entre su proyecto y Kubernetes. Sin embargo, Helm y ConfigMaps son opciones adicionales, por lo que no es necesario utilizarlas. Simplemente puede copiar la configuración en la imagen de Docker. Sin embargo, es tentador seguir este camino y construir abstracciones innecesarias de las que quizás te arrepientas más adelante.
Además, el ecosistema de Kubernetes está evolucionando rápidamente. Se necesita mucho tiempo y energía para mantenerse actualizado con las mejores prácticas y las últimas herramientas. Kubectl, minikube, kubeadm, helm, timón, kops, oc: la lista sigue y sigue. No todas estas herramientas son necesarias cuando estás empezando, pero no sabes cuáles necesitarás, por lo que debes estar al tanto de todo. Debido a esto, la curva de aprendizaje es bastante pronunciada.
Cuándo usar Kubernetes
En nuestra empresa, mucha gente utiliza Kubernetes y está muy contenta con él. Estas instancias son administradas por Google o Amazon, quienes cuentan con los recursos para respaldarlas.
Kubernetes viene con , que hacen que la orquestación de contenedores a escala sea más manejable:
- Detallado .
- agregar lógica al clúster. Estos son simplemente programas que se comunican con la API de Kubernetes.
- ! Kubernetes puede escalar servicios bajo demanda utilizando métricas de servicio y sin requerir intervención manual.
La pregunta es si realmente necesitas todas estas funciones. No puedes confiar simplemente en abstracciones; .
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.
Baterías no incluidas
Nomad es el 20% de la orquestación que proporciona el 80% de lo que se necesita. Todo lo que hace es gestionar las implementaciones. Nomad se encarga de los despliegues, reinicia los contenedores en caso de errores... y listo.
El objetivo de Nomad es lo que hace. mínimo: sin gestión granular de derechos o , esto está especialmente diseñado. Estos componentes se proporcionan externamente o no se proporcionan en absoluto.
Creo que Nomad ha encontrado el equilibrio perfecto entre facilidad de uso y utilidad. Es bueno para servicios pequeños e independientes. Si necesita más control, tendrá que aumentarlos usted mismo o utilizar un enfoque diferente. Nómada es sólo orquestador.
Lo mejor de Nomad es que es fácil заменить. Prácticamente no existe conexión con el proveedor, ya que sus funciones se integran fácilmente en cualquier otro sistema que gestione servicios. Simplemente se ejecuta como un binario normal en cada máquina del clúster, ¡eso es todo!
Ecosistema nómada de componentes débilmente acoplados
La verdadera fortaleza de Nomad es su ecosistema. Se integra muy bien con otros productos (completamente opcionales) como (almacenamiento clave-valor) o (secretos de procesamiento). Dentro de la ficha de Nomad existen apartados para la extracción de 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 la clave service/geo-api/log-verbosity desde Consul y mientras trabajamos lo exponemos a una variable de entorno LOG_LEVEL. También te presentamos la clave secret/geo-api-key de la bóveda como API_KEY. ¡Simple pero poderoso!
Debido a su simplicidad, Nomad es fácilmente extensible con otros servicios vía API. Por ejemplo, se admiten etiquetas para tareas. Etiquetamos todos los servicios con métricas. trv-metrics. De esta manera, Prometheus puede encontrar fácilmente estos servicios a través de Consul y verificar periódicamente el punto final. /metrics para nuevos datos. Lo mismo se puede hacer, por ejemplo, para los registros, usando .
Hay muchos otros ejemplos de extensibilidad:
- Ejecute un trabajo de Jenkins usando un enlace y Consul monitoreará la reimplementación del trabajo de Nomad cuando cambie la configuración del servicio.
- Ceph agrega un sistema de archivos distribuido a Nomad.
- para equilibrio de carga.
Todo esto permite sin ninguna conexión especial con el proveedor.
Advertencia justa
Ningún sistema es perfecto. No recomiendo introducir inmediatamente las funciones más nuevas en producción. Por supuesto, hay errores y faltan funciones, pero lo mismo se aplica a Kubernetes.
En comparación con Kubernetes, la comunidad Nomad no es tan grande. Kubernetes ya tiene alrededor de 75 confirmaciones y 000 contribuyentes, mientras que Nomad tiene alrededor de 2000 confirmaciones y 14 contribuyentes. A Nomad le resultará difícil mantener el ritmo de Kubernetes, ¡pero tal vez no sea necesario! Es un sistema más especializado y la comunidad más pequeña también significa que es más probable que su solicitud de extracción sea notada y aceptada, en comparación con Kubernetes.
Resumen
En pocas palabras: no use Kubernetes solo porque todos los demás lo hacen. Evalúe sus requisitos cuidadosamente y compruebe qué herramienta es más beneficiosa.
Si planea implementar una gran cantidad de servicios homogéneos en una infraestructura a gran escala, Kubernetes es una buena opción. Sólo tenga en cuenta la complejidad y los costos operativos adicionales. Algunos costos se pueden evitar utilizando un entorno de Kubernetes administrado, como o .
Si sólo busca un orquestador confiable que sea fácil de mantener y extensible, ¿por qué no prueba Nomad? Te sorprenderá lo lejos que te llevará esto.
Si se compara Kubernetes con un automóvil, Nomad sería un scooter. A veces necesitas una cosa y otras veces necesitas otra. Ambos tienen derecho a existir.
Fuente: habr.com