Ho creato Kube Eagle, un esportatore di Prometheus. Si è rivelata una cosa interessante che aiuta a comprendere meglio le risorse dei cluster di piccole e medie dimensioni. Alla fine, ho risparmiato centinaia di dollari perché ho selezionato i tipi di macchine giusti e configurato i limiti delle risorse applicative per i carichi di lavoro.
Ti parlerò dei vantaggi , ma prima spiegherò cosa ha causato tutto questo polverone e perché era necessario un monitoraggio di alta qualità.
Ho gestito diversi cluster da 4 a 50 nodi. Ogni cluster contiene fino a 200 microservizi e applicazioni. Per utilizzare al meglio l'hardware esistente, la maggior parte delle distribuzioni sono state configurate con risorse CPU e RAM espandibili. In questo modo, i pod possono prendere le risorse disponibili se necessario e allo stesso tempo non interferire con altre applicazioni su questo nodo. Beh, non è fantastico?
E sebbene il cluster consumasse relativamente poca CPU (8%) e RAM (40%), abbiamo costantemente avuto problemi con i pod che venivano anticipati quando tentavano di allocare più memoria di quella disponibile sul nodo. Allora avevamo una sola dashboard per il monitoraggio delle risorse Kubernetes. Come questo:
Dashboard Grafana solo con metriche cAdvisor
Con un pannello del genere non è un problema vedere nodi che consumano molta memoria e CPU. Il problema è capire quale sia il motivo. Per mantenere i pod in posizione, si potrebbero ovviamente impostare risorse garantite su tutti i pod (risorse richieste pari al limite). Ma questo non è l’uso più intelligente dell’hardware. Il cluster aveva diverse centinaia di gigabyte di memoria, mentre alcuni nodi erano affamati, mentre altri avevano 4-10 GB di riserva.
Risulta che lo scheduler Kubernetes ha distribuito i carichi di lavoro in modo non uniforme tra le risorse disponibili. Lo scheduler Kubernetes tiene conto di diverse configurazioni: regole di affinità, incompatibilità e tolleranze, selettori di nodo che possono limitare i nodi disponibili. Ma nel mio caso non c'era niente del genere e i pod sono stati pianificati in base alle risorse richieste su ciascun nodo.
Per il pod è stato selezionato il nodo che ha il maggior numero di risorse libere e che soddisfa le condizioni della richiesta. Abbiamo scoperto che le risorse richieste sui nodi non corrispondevano all'utilizzo effettivo, ed è qui che Kube Eagle e le sue capacità di monitoraggio delle risorse sono arrivate in soccorso.
Ho quasi tutti i cluster Kubernetes monitorati solo con и . Node Exporter fornisce statistiche sull'I/O e sull'utilizzo di disco, CPU e RAM, mentre Kube State Metrics mostra le metriche degli oggetti Kubernetes come richieste e limiti di risorse di CPU e memoria.
Dobbiamo combinare le metriche di utilizzo con le metriche delle richieste e dei limiti in Grafana, quindi otterremo tutte le informazioni sul problema. Sembra semplice, ma i due strumenti in realtà denominano le etichette in modo diverso e alcune metriche non hanno alcuna etichetta di metadati. Kube Eagle fa tutto da solo e il pannello si presenta così:
Siamo riusciti a risolvere molti problemi con le risorse e a risparmiare attrezzature:
- Alcuni sviluppatori non sapevano quante risorse fossero necessarie ai microservizi (o semplicemente non se ne preoccupavano). Non c'era modo di trovare richieste errate di risorse: per questo abbiamo bisogno di conoscere il consumo, le richieste e i limiti. Ora vedono le metriche Prometheus, monitorano l'utilizzo effettivo e adeguano richieste e limiti.
- Le applicazioni JVM occupano tutta la RAM che possono gestire. Il Garbage Collector rilascia memoria solo quando viene utilizzato più del 75%. E poiché la maggior parte dei servizi dispone di memoria espandibile, è sempre stata occupata dalla JVM. Pertanto, tutti questi servizi Java consumavano molta più RAM del previsto.
- Alcune applicazioni richiedevano troppa memoria e lo scheduler Kubernetes non cedeva questi nodi ad altre applicazioni, anche se in realtà erano più liberi di altri nodi. Uno sviluppatore ha accidentalmente aggiunto una cifra in più nella richiesta e ha preso una grossa porzione di RAM: 20 GB invece di 2. Nessuno se ne è accorto. L'applicazione aveva 3 repliche, quindi sono stati interessati fino a 3 nodi.
- Abbiamo introdotto limiti alle risorse, riprogrammato i pod con le richieste corrette e ottenuto un equilibrio ideale nell'utilizzo dell'hardware su tutti i nodi. Un paio di nodi avrebbero potuto essere chiusi del tutto. E poi abbiamo visto che avevamo le macchine sbagliate (orientate alla CPU, non alla memoria). Abbiamo cambiato il tipo ed eliminato molti altri nodi.
Risultati di
Con le risorse espandibili nel cluster, utilizzi l'hardware disponibile in modo più efficiente, ma lo scheduler Kubernetes pianifica i pod in base alle richieste di risorse e questo è complicato. Per prendere due piccioni con una fava: per evitare problemi e utilizzare al meglio le risorse, è necessario un buon monitoraggio. Ecco perché sarà utile (Esportatore Prometheus e dashboard Grafana).
Fonte: habr.com