Ragazza su uno scooter. Illustrazione , Logo Nomade da
Kubernetes è il gorilla da 300 libbre dell'orchestrazione dei container. Funziona in alcuni dei sistemi di container più grandi del mondo, ma è costoso.
Particolarmente costoso per i team più piccoli, che richiederanno molto tempo di supporto e una ripida curva di apprendimento. Questo è un sovraccarico eccessivo per la nostra squadra di quattro persone. Così abbiamo iniziato a cercare alternative e ce ne siamo innamorati .
Cosa vuoi
Il nostro team supporta una serie di servizi comuni di monitoraggio e analisi delle prestazioni: endpoint API per metriche scritte in Go, esportazioni Prometheus, parser di log come Logstash e , nonché database come InfluxDB o Elasticsearch. Ciascuno di questi servizi viene eseguito nel proprio contenitore. Abbiamo bisogno di un sistema semplice per far funzionare tutto.
Abbiamo iniziato con un elenco di requisiti per l'orchestrazione dei contenitori:
- Esecuzione di una serie di servizi su molte macchine.
- Panoramica dei servizi in esecuzione.
- Collegamenti tra servizi.
- Riavvio automatico in caso di interruzione del servizio.
- Manutenzione dell'infrastruttura da parte di un piccolo team.
Inoltre, le seguenti cose saranno aggiunte carine, ma non necessarie:
- Etichettatura delle macchine in base alle loro capacità (ad esempio, etichettatura delle macchine con dischi veloci per servizi I/O pesanti).
- Capacità di eseguire servizi indipendentemente dall'orchestratore (ad esempio, durante lo sviluppo).
- Un luogo comune per condividere configurazioni e segreti.
- Endpoint per parametri e log.
Perché Kubernetes non è adatto a noi
Durante la prototipazione con Kubernetes, abbiamo notato che stavamo aggiungendo livelli di logica sempre più complessi su cui facevamo molto affidamento.
Ad esempio, Kubernetes supporta le configurazioni di servizi integrate tramite . Puoi confonderti rapidamente, soprattutto quando unisci più file di configurazione o aggiungi servizi aggiuntivi a un pod. Kubernetes (o in questo caso) consente di implementare dinamicamente configurazioni esterne per separare le preoccupazioni. Ma ciò si traduce in un accoppiamento stretto e nascosto tra il tuo progetto e Kubernetes. Tuttavia, Helm e ConfigMap sono opzioni aggiuntive, quindi non è necessario utilizzarle. Puoi semplicemente copiare la configurazione nell'immagine Docker. Tuttavia, si è tentati di seguire questa strada e costruire astrazioni inutili di cui potresti pentirti in seguito.
Inoltre, l’ecosistema Kubernetes si sta evolvendo rapidamente. Ci vuole molto tempo ed energia per rimanere aggiornati con le migliori pratiche e gli strumenti più recenti. Kubectl, minikube, kubeadm, helm, tiller, kops, oc - l'elenco potrebbe continuare all'infinito. Non tutti questi strumenti sono necessari quando inizi, ma non sai di cosa avrai bisogno, quindi devi essere consapevole di tutto. Per questo motivo, la curva di apprendimento è piuttosto ripida.
Quando utilizzare Kubernetes
Nella nostra azienda, molte persone utilizzano Kubernetes e ne sono abbastanza soddisfatte. Queste istanze sono gestite da Google o Amazon, che hanno le risorse per supportarle.
Kubernetes viene fornito con , che rendono più gestibile l'orchestrazione dei contenitori su larga scala:
- Dettagliato .
- aggiungere logica al cluster. Questi sono semplicemente programmi che comunicano con l'API Kubernetes.
- ! Kubernetes può scalare i servizi on demand utilizzando le metriche del servizio e senza richiedere l'intervento manuale.
La domanda è se hai davvero bisogno di tutte queste funzionalità. Non puoi fare affidamento solo sulle astrazioni; .
Il nostro team fornisce la maggior parte dei servizi in remoto (grazie alla stretta connessione con l'infrastruttura principale), quindi non volevamo creare il nostro cluster Kubernetes. Volevamo solo fornire servizi.
Batterie non incluse
Nomad rappresenta il 20% dell'orchestrazione che fornisce l'80% di ciò che serve. Tutto ciò che fa è gestire le distribuzioni. Nomad si occupa delle distribuzioni, riavvia i contenitori in caso di errori... e questo è tutto.
Il punto centrale di Nomad è ciò che fa minimo: nessuna gestione granulare dei diritti o , questo è appositamente progettato. Questi componenti vengono forniti esternamente o non vengono forniti affatto.
Penso che Nomad abbia trovato il perfetto compromesso tra facilità d'uso e utilità. Va bene per i servizi piccoli e indipendenti. Se hai bisogno di maggiore controllo, dovrai allevarli tu stesso o utilizzare un approccio diverso. Nomade lo è solo orchestratore.
La cosa migliore di Nomad è che è facile sostituire. Non c'è praticamente alcun collegamento con il venditore, poiché le sue funzioni sono facilmente integrabili in qualsiasi altro sistema che gestisce i servizi. Funziona semplicemente come un normale binario su ogni macchina nel cluster, tutto qui!
Ecosistema nomade di componenti liberamente accoppiati
La vera forza di Nomad è il suo ecosistema. Si integra molto bene con altri prodotti, completamente opzionali, come (negozio di valori-chiave) o (segreti del trattamento). All'interno del file Nomad sono presenti delle sezioni per l'estrazione dei 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 mentre lavoriamo lo esponiamo a una 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 è facilmente estensibile con altri servizi tramite API. Ad esempio, sono supportati i tag per le attività. Contrassegniamo tutti i servizi con metriche trv-metrics. In questo modo Prometheus può trovare facilmente questi servizi tramite Consul e controllare periodicamente l'endpoint /metrics per nuovi dati. Lo stesso può essere fatto, ad esempio, per i log, utilizzando .
Esistono molti altri esempi di estensibilità:
- Esegui un lavoro Jenkins utilizzando un hook e Consul monitora la ridistribuzione del lavoro Nomad quando cambia la configurazione del servizio.
- Ceph aggiunge un file system distribuito a Nomad.
- per il bilanciamento del carico.
Tutto ciò lo consente senza alcun legame speciale con il venditore.
Giusto avvertimento
Nessun sistema è perfetto. Non consiglio di introdurre immediatamente le funzionalità più recenti in produzione. Naturalmente ci sono bug e funzionalità mancanti, ma lo stesso vale per Kubernetes.
Rispetto a Kubernetes, la comunità Nomad non è così grande. Kubernetes ha già circa 75 commit e 000 contributori, mentre Nomad ha circa 2000 commit e 14 contributori. Nomad avrà difficoltà a tenere il passo con la velocità di Kubernetes, ma forse non è necessario! È un sistema più specializzato e la comunità più piccola significa anche che la tua richiesta pull ha maggiori probabilità di essere notata e accettata, rispetto a Kubernetes.
Riassunto
In conclusione: non utilizzare Kubernetes solo perché lo fanno tutti gli altri. Valuta attentamente le tue esigenze e verifica quale strumento è più vantaggioso.
Se prevedi di distribuire moltissimi servizi omogenei su un'infrastruttura su larga scala, Kubernetes è una buona opzione. Basta essere consapevoli della complessità aggiuntiva e dei costi operativi. Alcuni costi possono essere evitati utilizzando un ambiente Kubernetes gestito come o .
Se stai semplicemente cercando un orchestratore affidabile, facile da mantenere ed estensibile, perché non provare Nomad? Potresti essere sorpreso di quanto lontano ti porterà.
Se Kubernetes fosse paragonato a un’auto, Nomad sarebbe uno scooter. A volte hai bisogno di una cosa e a volte ne hai bisogno di un'altra. Entrambi hanno il diritto di esistere.
Fonte: habr.com