Ragazza sulla scooter. Illustrazione freepik, logo di Nomad HashiCorp

Kubernetes è un gorilla di 300 kg per l'orchestrazione dei container. Funziona in alcuni dei più grandi sistemi di container al mondo, ma è costoso.

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

Cosa desideriamo

Il nostro team supporta una serie di servizi tipici per il monitoraggio e l'analisi delle prestazioni: endpoint API per le metriche scritte in Go, esportazione Prometheus, parser di log come Logstash e Gollum, oltre a database come InfluxDB o Elasticsearch. Ognuno di questi servizi funziona 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.
• Panorama dei servizi attivi.
• Collegamenti tra i servizi.
• Riavvio automatico se un servizio si arresta.
• Gestione dell'infrastruttura da parte di un piccolo team.

Inoltre, le seguenti caratteristiche saranno gradevoli ma non obbligatorie:

• Etichettatura delle macchine in base alle loro capacità (ad esempio, etichettare le macchine con dischi veloci per servizi pesanti di input/output).
• Possibilità di avviare i 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

Durante la creazione di un prototipo con Kubernetes, abbiamo notato che iniziavamo ad aggiungere strati di logica sempre più complessi, sui quali ci affidavamo incondizionatamente.

Ad esempio, Kubernetes supporta configurazioni di servizio integrate tramite ConfigMaps. Puoi facilmente confonderti, specialmente quando unisci più file di configurazione o aggiungi più servizi in un pod. Kubernetes (o helm In questo caso, consente di implementare dinamicamente configurazioni esterne per separare gli interessi. Tuttavia, ciò porta a un legame rigido e nascosto tra il tuo progetto e Kubernetes. Tuttavia, Helm e ConfigMaps sono opzioni aggiuntive, quindi non è necessario utilizzarli. Puoi semplicemente copiare la configurazione nell'immagine Docker. Tuttavia, è allettante seguire questo percorso e costruire astrazioni inutili, 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 - l'elenco continua e continua. Non tutti questi strumenti sono necessari all'inizio, ma non sai di cosa avrai bisogno, quindi è importante essere al corrente di tutto. Per questo motivo, la curva di apprendimento è abbastanza ripida.

Quando usare Kubernetes

Nella nostra azienda molte persone utilizzano Kubernetes e ne sono abbastanza soddisfatte. Queste istanze sono gestite da Google o Amazon, che hanno risorse sufficienti per il supporto.

Kubernetes viene fornito con funzionalità sorprendenti, che rendono più gestibile l'orchestrazione su larga scala dei contenitori:

• Gestione dettagliata dei diritti.
• Controller personalizzati aggiungono logica al cluster. Sono semplicemente programmi che comunicano con l'API di Kubernetes.
• Auto-scalabilità! Kubernetes è in grado di scalare i servizi su richiesta, utilizzando metriche di servizio e senza richiedere intervento manuale.

La questione è se hai davvero bisogno di tutte queste funzionalità. Non puoi semplicemente fare affidamento sulle astrazioni; dovrai capire cosa succede sotto il cofano.

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

Batterie non incluse

Nomad è il 20% dell'orchestrazione che fornisce l'80% di ciò che serve. Tutto ciò che fa è gestire i deployment. Nomad si occupa dei deployment, riavvia i contenitori in caso di errori... e questo è tutto.

Il senso di Nomad è proprio questo: almenoniente gestione dettagliata dei diritti o politiche di rete avanzate, così è progettato appositamente. Questi componenti sono forniti da terzi o non sono forniti affatto.

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

La cosa migliore di Nomad è che è facile sostituire. Il vendor lock-in è praticamente assente, poiché le sue funzionalità si integrano facilmente con qualsiasi altro sistema che gestisce i servizi. Funziona semplicemente come un normale binario su ogni macchina nel cluster, tutto qui!

L'ecosistema di Nomad è composto da componenti scarsamente accoppiati

La vera forza di Nomad risiede nel suo ecosistema. Si integra molto bene con altri prodotti completamente opzionali, come Consul (magazzino chiave-valore) o Vault (gestione dei segreti). All'interno del file di 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 si espande facilmente tramite altri servizi attraverso API. Ad esempio, supporta i tag per i job. Etichettiamo tutti i servizi con metriche con il tag trv-metrics. In questo modo, Prometheus trova facilmente questi servizi tramite Consul e controlla periodicamente l'endpoint /metrics per nuovi dati. Lo stesso può essere fatto, ad esempio, per i log, utilizzando Loki.

Ci sono molti altri esempi di espandibilità:

• Eseguire un job Jenkins tramite un hook, e Consul monitora il ridispiegamento del job di Nomad al variare della 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 un forte vincolo verso il vendor.

Un avviso onesto

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

Rispetto a Kubernetes, la comunità di Nomad non è così vasta. Kubernetes ha già circa 75.000 commit e 2000 contributori, mentre Nomad ne ha circa 14.000 e 300. Sarà difficile per Nomad mantenere il passo e non essere superato da Kubernetes, ma forse non è nemmeno necessario! Si tratta di un sistema più specializzato e una comunità più piccola significa anche che la tua pull request verrà probabilmente notata e accettata più facilmente rispetto a Kubernetes.

Riepilogo

Conclusione: non utilizzare Kubernetes solo perché lo fanno tutti. Valuta attentamente le tue esigenze e verifica quale strumento sia più vantaggioso.

Se hai intenzione di distribuire molteplici servizi omogenei su un'infrastruttura su larga scala, Kubernetes è un'ottima scelta. Tieni 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 e scalabile, perché non provare Nomad? Potresti rimanere sorpreso da quanto lontano ti porterà.

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

Fonte: habr.com