Ho creato Kube Eagle — un esportatore Prometheus. Si è rivelato uno strumento utile che aiuta a gestire meglio le risorse di piccoli e medi cluster. Grazie a questo, ho risparmiato diverse centinaia di dollari, poiché ho scelto i tipi di macchine giusti e impostato correttamente le limitazioni delle risorse delle applicazioni in base ai carichi di lavoro.
Vi parlerò dei vantaggi , ma prima spiegherò cosa ha causato la confusione e perché era necessaria una monitorizzazione di qualità.
Ho gestito diversi cluster con 4–50 nodi. In ogni cluster ci sono fino a 200 microservizi e applicazioni. Per utilizzare in modo più efficace l'hardware disponibile, la maggior parte dei deployment è stata configurata con memoria e risorse CPU burstable. In questo modo, i pod possono utilizzare le risorse disponibili quando necessario, senza disturbare le altre applicazioni su quel nodo. Non è fantastico?
E sebbene il cluster consumasse relativamente poca CPU (8%) e memoria (40%), ci trovavamo costantemente a fronteggiare problemi di espulsione dei pod quando cercavano di allocare più memoria di quella disponibile sul nodo. All'epoca avevamo solo un pannello per monitorare le risorse di Kubernetes. Ecco com'era:
Pannello Grafana solo con metriche cAdvisor
Con un pannello di nodi che consumano molta memoria e CPU, non è un problema vederli. Il problema è capire perché. Per mantenere i pod in posizione, è certamente possibile configurare risorse garantite su tutti i pod (le risorse richieste sono uguali al limite). Ma non è il modo migliore di utilizzare l'hardware. Nel cluster c'erano diverse centinaia di gigabyte di memoria, mentre alcuni nodi soffrivano di scarsità e altri avevano ancora 4-10 GB in riserva.
Quindi, il pianificatore Kubernetes distribuiva in modo disomogeneo i carichi di lavoro in base alle risorse disponibili. Il pianificatore Kubernetes tiene conto di diverse configurazioni: regole di affinità, taints e tolerations, selettori di nodi che possono limitare i nodi accessibili. Ma nel mio caso non c'era nulla di tutto ciò, e i pod venivano pianificati in base alle risorse richieste su ciascun nodo.
Per ciascun pod veniva selezionato un nodo con il maggior numero di risorse disponibili che soddisfaceva le condizioni della richiesta. Nonostante tutto, si è rilevato che le risorse richieste sui nodi non corrispondevano all'effettivo utilizzo, e qui è intervenuto Kube Eagle con le sue capacità di monitoraggio delle risorse.
Quasi tutti i cluster Kubernetes sono stati monitorati solo con e . Node Exporter fornisce statistiche su I/O e utilizzo di disco, CPU e memoria, mentre Kube State Metrics mostra le metriche degli oggetti Kubernetes, come richieste e limiti per CPU e memoria.
Dobbiamo combinare le metriche di utilizzo con le metriche di richieste e limiti in Grafana, e così avremo tutte le informazioni sul problema. Sembra semplice, ma in realtà in questi due strumenti le etichette sono denominate in modo diverso, e alcune metriche non hanno nemmeno etichette di metadati. Kube Eagle fa tutto da solo e il pannello appare così:
Siamo riusciti a risolvere molti problemi di risorse e risparmiare hardware:
- Alcuni sviluppatori non sapevano quanti risorse servissero ai microservizi (o semplicemente non si preoccupavano). Non avevamo modo di individuare richieste errate di risorse - per questo serviva sapere il consumo più le richieste e limiti. Ora possono vedere le metriche Prometheus, monitorare l'uso effettivo e adattare le richieste e i limiti.
- Le applicazioni JVM utilizzano tutta la memoria RAM disponibile. Il garbage collector rilascia la memoria solo se è occupato più del 75%. Dato che la maggior parte dei servizi ha una memoria burstable, JVM ha sempre occupato spazio. Pertanto, tutti questi servizi Java consumavano molta più memoria RAM di quanto previsto.
- Alcune applicazioni richiedevano troppa memoria, e il pianificatore Kubernetes non assegnava quelle nodi ad altre applicazioni, anche se in effetti erano più liberi di altri nodi. Uno sviluppatore ha accidentalmente aggiunto una cifra in più nella richiesta, occupando così un grande blocco di RAM: 20 GB invece di 2. Nessuno se n'era accorto. L'applicazione aveva 3 repliche, quindi 3 nodi hanno subito le conseguenze.
- Abbiamo imposto limiti alle risorse, riprogettato i pod con le giuste richieste e ottenuto un equilibrio ideale nell'uso dell'hardware su tutti i nodi. Alcuni nodi avrebbero potuto essere chiusi completamente. Poi abbiamo notato che avevamo macchine non corrette (ottimizzate per la CPU, e non per la memoria). Abbiamo cambiato tipo e rimosso altri nodi.
Risultati
Con risorse burstable nel cluster utilizzi più efficacemente l'hardware disponibile, ma il pianificatore Kubernetes pianifica i pod in base alle richieste di risorse, il che può creare problemi. Per ottenere il massimo da entrambe le situazioni — evitando problemi e utilizzando al meglio le risorse — è necessario un buon monitoraggio. A tal fine, è utile (l'esportatore Prometheus e il pannello di monitoraggio Grafana).
Fonte: habr.com
