Ragazza su uno scooter. Illustrazione freepik, logo di Nomad di HashiCorp

Kubernetes è un gorilla da 300 chilogrammi per l'orchestrazione dei container. Funziona in alcuni dei più grandi sistemi di container al mondo, ma ha un costo elevato.

Particolarmente costoso per piccoli team che dovranno dedicare molto tempo alla manutenzione e affrontare una curva di apprendimento ripida. Per il nostro team di quattro persone, è troppo alto il sovraccarico. Così abbiamo iniziato a cercare alternative e ci siamo innamorati di Nomad.

Cosa ci serve

Il nostro team supporta una serie di servizi tipici per il monitoraggio e l'analisi delle performance: endpoint API per metriche scritte in Go, esportazione Prometheus, parser di log come Logstash e Gollum, oltre a database come InfluxDB o Elasticsearch. Ognuno di questi servizi opera in un proprio container. Abbiamo bisogno di un sistema semplice per mantenere tutto in funzione.

Abbiamo iniziato con un elenco di requisiti per l'orchestrazione dei container:

• Esecuzione di un insieme di servizi su più macchine.
• Panoramica dei servizi in esecuzione.
• Collegamenti tra i servizi.
• Riavvio automatico in caso di crash del servizio.
• Manutenzione dell'infrastruttura da parte di un piccolo team.

Inoltre, le seguenti funzionalità sarebbero piacevoli, ma non essenziali:

• Marcatura delle macchine in base alle loro capacità (ad esempio, marcatura delle macchine con dischi veloci per servizi intensivi in input/output).
• Possibilità di eseguire servizi indipendentemente dall'orchestratore (ad esempio, durante lo sviluppo).
• Un luogo comune per la condivisione di configurazioni e segreti.
• Endpoint per metriche e log.

Perché Kubernetes non fa per noi

Quando abbiamo creato un prototipo con Kubernetes, abbiamo notato che aggiungevamo strati sempre più complessi di logica su cui ci siamo affidati incondizionatamente.

Ad esempio, Kubernetes supporta configurazioni di servizio incorporate tramite ConfigMaps. Puoi facilmente confonderti, specialmente quando unisci più file di configurazione o aggiungi ulteriori servizi a un pod. Kubernetes (o helm in questo caso) consente di introdurre dinamicamente configurazioni esterne per separare le preoccupazioni. Tuttavia, questo porta a un legame rigido e nascosto tra il tuo progetto e Kubernetes. Tuttavia, Helm e ConfigMaps sono opzioni aggiuntive, quindi non è necessario usarle. Puoi semplicemente copiare la configurazione nell'immagine Docker. Nonostante ciò, è allettante seguire questa strada e costruire astrattamenti non necessari, di cui potresti pentirti in seguito.

Inoltre, l'ecosistema Kubernetes si evolve rapidamente. Ci vuole molto tempo ed energia per rimanere aggiornati sulle migliori pratiche e sugli strumenti più recenti. Kubectl, minikube, kubeadm, helm, tiller, kops, oc - la lista continua e continua. Non è necessario avere tutti questi strumenti all'inizio, ma non sai cosa ti servirà, quindi devi essere informato su tutto. A causa di ciò, la curva di apprendimento è piuttosto ripida.

Quando usare Kubernetes

Nella nostra azienda, molti usano Kubernetes e sono soddisfatti. Questi istanze sono gestite da Google o Amazon, che hanno le risorse per supportarle.

Kubernetes viene fornito con funzionalità sorprendenti, che rendono la scalabilità dell'orchestrazione dei container più gestibile:

• Gestione dei diritti dettagliata..
• Controller personalizzati aggiungono logica al cluster. Sono semplicemente programmi che dialogano con l'API di Kubernetes.
• Autoscalamento! Kubernetes può scalare i servizi su richiesta, utilizzando metriche di servizio e senza necessità di intervento manuale.

La domanda è: hai davvero bisogno di tutte queste funzionalità? Non puoi solo fare affidamento sulle astrattazioni; dovrai scoprire cosa accade sotto il cofano..

Il nostro team fornisce la maggior parte dei servizi da remoto (a causa della stretta integrazione con l'infrastruttura principale), per cui non volevamo avviare un nostro cluster Kubernetes. Volevamo semplicemente fornire servizi.

Batterie non incluse

Nomad è il 20% dell'orchestrazione che fornisce l'80% di quanto necessario. Tutto ciò che fa è gestire le distribuzioni. Nomad si occupa delle distribuzioni, riavvia i container in caso di errori… e questo è tutto.

Il punto di Nomad è che fa un minimo di: niente gestione dettagliata dei diritti o politiche di rete avanzate, così è progettato. Questi componenti sono forniti da terze parti o non sono forniti affatto.

Penso che Nomad abbia trovato il compromesso ideale tra facilità d'uso e utilità. È buono per servizi piccoli e indipendenti. Se hai bisogno di più controllo, dovrai sollevarli da solo o utilizzare un altro approccio. Nomad è un solo orchestratore.

La cosa migliore di Nomad è che è facile sostituire. Il legame con il vendor è praticamente assente, poiché le sue funzioni si integrano facilmente in qualsiasi altro sistema di gestione dei servizi. Funziona semplicemente come un normale binario su ogni macchina nel cluster, tutto qui!

L'ecosistema di Nomad è composto da componenti debolmente connessi

La vera forza di Nomad sta nel suo ecosistema. Si integra molto bene con altri prodotti – completamente opzionali – come Consul (memoria chiave-valore) o Vault (gestione dei segreti). All'interno del file Nomad ci sono sezioni per estrarre dati da questi servizi:

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
}

Qui leggiamo la chiave service/geo-api/log-verbosity da Consul e durante l'esecuzione la presentiamo come variabile d'ambiente LOG_LEVEL. Presentiamo anche la chiave secret/geo-api-key da Vault come API_KEY. Semplice, ma potente!

Grazie alla sua semplicità, Nomad può essere facilmente esteso con altri servizi tramite API. Ad esempio, supporta i tag per i job. Etichettiamo tutti i servizi con metriche utilizzando il tag trv-metrics. In questo modo, Prometheus può facilmente trovare questi servizi attraverso Consul e controllare periodicamente l'endpoint /metrics per nuovi dati. Lo stesso si può fare, ad esempio, per i log, utilizzando Loki.

Ci sono molti altri esempi di estensibilità:

• Esecuzione di un job Jenkins con un hook, e Consul monitora il ri-deploy del job Nomad in caso di modifiche alla configurazione del servizio.
• Ceph aggiunge a Nomad un file system distribuito.
• fabio per il bilanciamento del carico.

Tutto ciò consente di sviluppare organicamente l'infrastruttura senza particolare legame con il vendor.

Avvertenza onesta

Nessun sistema è perfetto. Non consiglio di implementare immediatamente le funzioni più recenti in produzione. Certo, ci sono bug e funzioni mancanti, ma lo stesso vale per Kubernetes.

Rispetto a Kubernetes, la comunità di Nomad non è così grande. Kubernetes ha già circa 75.000 commit e 2.000 contributori, mentre Nomad ha circa 14.000 commit e 300 contributori. Sarà difficile per Nomad tenere il passo con la velocità di Kubernetes, ma forse non è necessario! È un sistema più specializzato, e una comunità più piccola significa anche che la tua pull request verrà notata e accettata più facilmente rispetto a Kubernetes.

Riepilogo

In sintesi: non usare Kubernetes solo perché lo fanno tutti. Valuta attentamente le tue esigenze e verifica quale strumento è più vantaggioso.

Se prevedi di distribuire un gran numero di servizi omogenei su un'infrastruttura su larga scala, Kubernetes è una buona scelta. Tieni solo presente la complessità aggiuntiva e i costi operativi. Alcuni costi possono essere evitati utilizzando un ambiente Kubernetes gestito, come Google Kubernetes Engine o Amazon EKS.

Se stai semplicemente cercando un orchestratore affidabile, facile da mantenere ed estendibile, perché non provare Nomad? Potresti rimanere sorpreso da quanto ti porterà lontano.

Se confronti Kubernetes con un'auto, Nomad sarà uno scooter. A volte hai bisogno di uno, a volte dell'altro. Entrambi hanno il loro posto.

Fonte: habr.com