Moza nun scooter. Ilustración freepik, Logotipo Nomad de HashiCorp

Kubernetes é o gorila de 300 libras da orquestración de contedores. Funciona nalgúns dos sistemas de contedores máis grandes do mundo, pero é caro.

Particularmente caro para equipos máis pequenos, que requirirán moito tempo de apoio e unha curva de aprendizaxe pronunciada. Isto é demasiado para o noso equipo de catro. Entón comezamos a buscar alternativas - e namorámonos Nómade.

Que queres

O noso equipo admite unha serie de servizos de análise e seguimento do rendemento comúns: puntos finais de API para métricas escritas en Go, exportacións de Prometheus, analizadores de rexistros como Logstash e Gollum, así como bases de datos como InfluxDB ou Elasticsearch. Cada un destes servizos execútase no seu propio contedor. Necesitamos un sistema sinxelo para manter todo funcionando.

Comezamos cunha lista de requisitos para a orquestración de contedores:

• Execución dun conxunto de servizos en moitas máquinas.
• Visión xeral dos servizos en execución.
• Vínculos entre servizos.
• Reinicio automático se o servizo cae.
• Mantemento da infraestrutura por un pequeno equipo.

Ademais, as seguintes cousas serán boas, pero non necesarias:

• Etiquetar máquinas en función das súas capacidades (por exemplo, etiquetar máquinas con discos rápidos para servizos de E/S pesados).
• Capacidade para executar servizos independentemente do orquestrador (por exemplo, durante o desenvolvemento).
• Un lugar común para compartir configuracións e segredos.
• Punto final para métricas e rexistros.

Por que Kubernetes non é o axeitado para nós

Mentres creabamos prototipos con Kubernetes, observamos que estabamos engadindo capas de lóxica cada vez máis complexas nas que confiamos moito.

Como exemplo, Kubernetes admite configuracións de servizos integradas mediante ConfigMaps. Pode confundirse rapidamente, especialmente cando se combinan varios ficheiros de configuración ou se engaden servizos adicionais a un pod. Kubernetes (ou leme neste caso) permítelle implementar dinámicamente configuracións externas para separar as preocupacións. Pero isto dá lugar a unha conexión estreita e oculta entre o teu proxecto e Kubernetes. Non obstante, Helm e ConfigMaps son opcións adicionais, polo que non tes que usalas. Pode simplemente copiar a configuración na imaxe de Docker. Non obstante, é tentador percorrer este camiño e construír abstraccións innecesarias das que podes arrepentirte despois.

Ademais, o ecosistema de Kubernetes está a evolucionar rapidamente. Leva moito tempo e enerxía estar ao día das mellores prácticas e das ferramentas máis recentes. Kubectl, minikube, kubeadm, helm, tiller, kops, oc - a lista segue e segue. Non todas estas ferramentas son necesarias cando estás comezando, pero non sabes o que necesitas, polo que debes estar atento a todo. Por iso, a curva de aprendizaxe é bastante pronunciada.

Cando usar Kubernetes

Na nosa empresa, moitas persoas usan Kubernetes e están bastante satisfeitas con el. Estas instancias son xestionadas por Google ou Amazon, que teñen os recursos para apoialas.

Kubernetes vén con características sorprendentes, que fan que a orquestración de contedores a escala sexa máis manexable:

• Detallado xestión de dereitos.
• Controladores personalizados engadir lóxica ao clúster. Estes son simplemente programas que falan coa API de Kubernetes.
• Autoescalado! Kubernetes pode escalar os servizos baixo demanda utilizando métricas de servizos e sen necesidade de intervención manual.

A pregunta é se realmente necesitas todas estas funcións. Non podes confiar só en abstraccións; terás que descubrir o que está a pasar debaixo do capó.

O noso equipo ofrece a maioría dos servizos de forma remota (debido á estreita conexión coa infraestrutura principal), polo que non queriamos crear o noso propio clúster de Kubernetes. Só queriamos ofrecer servizos.

Pilas non incluídas

Nomad é o 20% da orquestración que proporciona o 80% do que se necesita. O único que fai é xestionar as implantacións. Nomad encárgase dos despregamentos, reinicia os contedores en caso de erros... e xa está.

O obxectivo de Nomad é o que fai mínimo: sen xestión granular de dereitos ou políticas de rede estendidas, este está especialmente deseñado. Estes compoñentes son proporcionados externamente ou non se proporcionan en absoluto.

Creo que Nomad atopou o compromiso perfecto entre facilidade de uso e utilidade. É bo para servizos pequenos e independentes. Se necesitas máis control, terás que elevalos ti mesmo ou usar un enfoque diferente. Nómade é xusto orquestrador.

O mellor de Nomad é que é fácil заменить. Practicamente non hai conexión co vendedor, xa que as súas funcións se integran facilmente en calquera outro sistema que xestione servizos. Funciona como un binario normal en todas as máquinas do clúster, iso é todo!

Ecosistema nómada de compoñentes pouco acoplados

A verdadeira forza de Nomad é o seu ecosistema. Intégrase moi ben con outros produtos -completamente opcionais- como Cónsul (tenda de clave-valor) ou Bóveda (segredos de procesamento). Dentro do ficheiro Nomad hai seccións para extraer datos destes servizos:

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í lemos a clave service/geo-api/log-verbosity de Consul e mentres traballamos expoñémolo a unha variable de ambiente LOG_LEVEL. Tamén presentamos a clave secret/geo-api-key de Vault as API_KEY. Simple pero poderoso!

Debido á súa sinxeleza, Nomad é facilmente extensible con outros servizos a través da API. Por exemplo, as etiquetas para tarefas son compatibles. Etiquetamos todos os servizos con métricas trv-metrics. Deste xeito, Prometheus pode atopar facilmente estes servizos a través de Consul e comprobar periodicamente o punto final /metrics para novos datos. O mesmo pódese facer, por exemplo, para rexistros, usando Loki.

Hai moitos outros exemplos de extensibilidade:

• Executa un traballo de Jenkins mediante un gancho e Consul supervisa a redistribución do traballo Nomad cando cambia a configuración do servizo.
• Ceph engade un sistema de ficheiros distribuído a Nomad.
• Fabio para o equilibrio de carga.

Todo isto permite desenvolver organicamente infraestruturas sen ningunha conexión especial co vendedor.

Aviso xusto

Ningún sistema é perfecto. Non recomendo introducir inmediatamente as funcións máis novas na produción. Por suposto, hai erros e funcións que faltan, pero o mesmo aplícase a Kubernetes.

En comparación con Kubernetes, a comunidade Nomad non é tan grande. Kubernetes conta xa con preto de 75 commits e 000 colaboradores, mentres que Nomad conta cuns 2000 commits e 14 colaboradores. A Nomad terá dificultades para manterse ao día coa velocidade de Kubernetes, pero quizais non teña por que facelo. É un sistema máis especializado, e a comunidade máis pequena tamén significa que é máis probable que a túa solicitude de extracción se note e se acepte, en comparación con Kubernetes.

Resumo

Conclusión: non use Kubernetes só porque o fagan todos os demais. Avalía coidadosamente os teus requisitos e comprobe que ferramenta é máis beneficiosa.

Se planeas implantar unha tonelada de servizos homoxéneos nunha infraestrutura a gran escala, entón Kubernetes é unha boa opción. Só ten en conta a complexidade engadida e os custos operativos. Pódense evitar algúns custos usando un ambiente de Kubernetes xestionado como Google Kubernetes Engine ou Amazon EKS.

Se só buscas un orquestrador fiable que sexa fácil de manter e extensible, por que non probas Nomad? Podes sorprenderche ata onde che levará isto.

Se Kubernetes se compara cun coche, Nomad sería un scooter. Ás veces necesitas unha cousa e outras necesitas outra. Ambos teñen dereito a existir.

Fonte: www.habr.com