Chica en scooter. Ilustración , logotipo de Nomad de
Kubernetes es una gorila de 300 kilogramos para la orquestación de contenedores. Funciona en algunos de los sistemas de contenedores más grandes del mundo, pero tiene un alto costo.
Especialmente costoso para equipos pequeños, que tendrían que gastar mucho tiempo en soporte y una curva de aprendizaje pronunciada. Para nuestro equipo de cuatro personas, esto representa un exceso de costos. Por eso comenzamos a buscar alternativas y nos enamoramos de .
Lo que deseamos
Nuestro equipo soporta una serie de servicios típicos para monitoreo y análisis de rendimiento: puntos finales de API para métricas, escritos en Go, exportaciones de Prometheus, analizadores de logs como Logstash y , así como bases de datos, como InfluxDB o Elasticsearch. Cada uno de estos servicios funciona en su propio contenedor. Necesitamos un sistema sencillo para mantener todo esto en funcionamiento.
Comenzamos con una lista de requisitos para la orquestación de contenedores:
- Ejecutar un conjunto de servicios en múltiples máquinas.
- Una visión general de los servicios en ejecución.
- Conexiones entre servicios.
- Reinicio automático si un servicio falla.
- Mantenimiento de la infraestructura por un pequeño equipo.
Además, las siguientes cosas serían agradables, pero no esenciales:
- Etiquetado de máquinas según sus capacidades (por ejemplo, etiquetar máquinas con discos rápidos para servicios intensivos en E/S).
- La capacidad de ejecutar servicios independientemente del orquestador (por ejemplo, durante el desarrollo).
- Un lugar común para compartir configuraciones y secretos.
- Un punto final para métricas y logs.
Por qué Kubernetes no es adecuado para nosotros
Al crear un prototipo con Kubernetes, notamos que empezamos a añadir capas de lógica cada vez más complejas, en las que confiamos sin dudar.
Por ejemplo, Kubernetes admite configuraciones de servicios incorporadas a través de . Puedes confundirte rápidamente, especialmente al fusionar varios archivos de configuración o al agregar servicios adicionales en un pod. Kubernetes (o En este caso, permite implementar configuraciones externas de manera dinámica para dividir intereses. Pero esto lleva a una conexión oculta rígida entre tu proyecto y Kubernetes. Sin embargo, Helm y ConfigMaps son opciones adicionales, por lo que no es necesario utilizarlas. Puedes simplemente copiar la configuración en la imagen de Docker. No obstante, es tentador seguir este camino y construir abstracciones innecesarias de las que podrías arrepentirte después.
Además, el ecosistema de Kubernetes está evolucionando rápidamente. Se requiere mucho tiempo y energía para mantenerse al día con las mejores prácticas y las herramientas más recientes. Kubectl, minikube, kubeadm, helm, tiller, kops, oc: la lista continúa y continúa. Al principio no se necesitan todas estas herramientas, pero no sabes lo que necesitarás, por lo que es fundamental estar al tanto de todo. Esto provoca que la curva de aprendizaje sea bastante pronunciada.
Cuándo usar Kubernetes
En nuestra empresa, muchos utilizan Kubernetes y están bastante satisfechos con él. Estas instancias son gestionadas por Google o Amazon, que tienen suficientes recursos para su soporte.
Kubernetes viene con , que hacen que la orquestación a gran escala de contenedores sea más gestionable:
- Control detallado .
- agregan lógica al clúster. 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 se puede simplemente depender de abstracciones; .
Nuestro equipo ofrece la mayoría de los servicios de forma remota (debido a la estrecha relación con la infraestructura principal), por lo que no queríamos levantar nuestro propio clúster de Kubernetes. Solo queríamos ofrecer servicios.
Baterías no incluidas
Nomad es un 20% de la orquestación que proporciona el 80% de lo necesario. Todo lo que hace es gestionar despliegues. Nomad se encarga de los despliegues, reinicia contenedores en caso de errores... y eso es todo.
El sentido de Nomad es que hace un mínimo de: ningún control detallado de permisos o , así está diseñado intencionadamente. Estos componentes son proporcionados externamente o no se ofrecen en absoluto.
Creo que Nomad ha encontrado el compromiso perfecto entre facilidad de uso y utilidad. Es óptimo para servicios pequeños e independientes. Si se necesita más control, habrá que gestionarlos por cuenta propia o usar otro enfoque. Nomad es simplemente un orquestador.
Lo mejor de Nomad es que es fácil de reemplazar. La vinculación con el proveedor es prácticamente inexistente, ya que sus funciones se integran fácilmente en cualquier otro sistema que gestione servicios. Funciona simplemente como un binario estándar en cada máquina del clúster, ¡y eso es todo!
El ecosistema de Nomad está compuesto por componentes débilmente acoplados.
La verdadera fuerza de Nomad radica en su ecosistema. Se integra muy bien con otros productos completamente opcionales, como (almacenamiento clave-valor) o (gestión de secretos). Dentro del archivo de 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 la clave service/geo-api/log-verbosity de Consul y a lo largo del proceso la representamos como una variable de entorno LOG_LEVEL. También representamos la clave secret/geo-api-key de Vault como API_KEY.¡Sencillo pero poderoso!
Gracias a su simplicidad, Nomad se puede ampliar fácilmente con otros servicios a través de API. Por ejemplo, se admiten etiquetas para trabajos. Marcamos todos los servicios con métricas con la etiqueta trv-metrics. De esta manera, Prometheus puede encontrar estos servicios fácilmente a través de Consul y verificar periódicamente el punto final /metrics en busca de nuevos datos. Lo mismo se puede hacer, por ejemplo, para los registros, utilizando .
Existen muchos otros ejemplos de extensibilidad:
- Ejecutar un trabajo de Jenkins a través de un gancho, y Consul monitorea el redeployment del trabajo de Nomad al cambiar la configuración del servicio.
- Ceph añade a Nomad un sistema de archivos distribuido.
- para balanceo de carga.
Todo esto permite sin un compromiso particular con ningún proveedor.
Advertencia honesta
Ningún sistema es perfecto. No recomiendo implementar de inmediato las funciones más nuevas en producción. Por supuesto, hay errores y funciones que faltan, pero lo mismo ocurre con Kubernetes.
En comparación con Kubernetes, la comunidad de Nomad no es tan grande. Kubernetes ya cuenta con alrededor de 75,000 commits y 2,000 contribuidores, mientras que Nomad tiene aproximadamente 14,000 commits y 300 contribuidores. A Nomad le resultará difícil mantenerse al día y no rezagarse frente a Kubernetes, pero ¡quizás eso no sea necesario! Es un sistema más especializado, y una comunidad más pequeña también significa que su pull request tiene más probabilidades de ser notado y aceptado en comparación con Kubernetes.
Currículum
Conclusión: no use Kubernetes solo porque todos lo hacen. Evalúe cuidadosamente sus requisitos y compruebe qué herramienta es más beneficiosa.
Si planea desplegar una gran cantidad de servicios homogéneos en una infraestructura a gran escala, Kubernetes es una buena opción. Simplemente recuerde la complejidad adicional y los costos operativos. Algunos gastos se pueden evitar utilizando un entorno gestionado de Kubernetes, como o .
Si solo busca un orquestador confiable, fácil de mantener y escalable, ¿por qué no probar Nomad? Puede que se sorprenda de hasta dónde puede llevarle.
Si se compara Kubernetes con un coche, Nomad sería un scooter. A veces necesita uno y otras veces, el otro. Ambos tienen derecho a existir.
Fuente: habr.com
