Ho creato Kube Eagle — un esportatore di Prometheus. Si è rivelato uno strumento eccezionale che aiuta a comprendere meglio le risorse di piccoli e medi cluster. Alla fine ho risparmiato diverse centinaia di dollari, perché ho selezionato i giusti tipi di macchine e configurato i limiti delle risorse delle applicazioni in base ai carichi di lavoro.
Parlerò dei vantaggi , ma prima spiegherò da dove è nata la confusione e perché era necessario un monitoraggio 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ù efficiente 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 altre applicazioni su quel nodo. Non è fantastico?
E anche se il cluster consumava relativamente poca CPU (8%) e memoria (40%), avevamo costantemente problemi di espulsione dei pod quando cercavano di allocare più memoria di quella disponibile sul nodo. All'epoca avevamo solo un pannello per il monitoraggio delle risorse di Kubernetes. Ecco di che tipo:
Pannello Grafana solo con metriche cAdvisor
Con tale pannello, è facile individuare i nodi che consumano molta memoria e CPU. Il problema è capire qual è la causa. Per mantenere i pod in posizione, avremmo potuto configurare risorse garantite su tutti i pod (le risorse richieste equivalgono al limite). Ma non è il modo più intelligente di utilizzare l'hardware. Nel cluster c'erano diverse centinaia di gigabyte di memoria, mentre alcuni nodi erano a corto di risorse e altri avevano disponibili 4–10 GB.
Quindi, il pianificatore Kubernetes distribuiva i carichi di lavoro sulle risorse disponibili in modo non uniforme. Il pianificatore Kubernetes tiene conto di diverse configurazioni: regole di affinità, taint e toleration, selettori di nodi che possono limitare i nodi disponibili. Ma nel mio caso non c'era nulla del genere, e i pod venivano pianificati in base alle risorse richieste su ogni nodo.
Per ogni pod, veniva scelto un nodo che avesse più risorse disponibili e che soddisfacesse i criteri della richiesta. Così abbiamo scoperto che le risorse richieste sui nodi non corrispondevano all'utilizzo effettivo, ed è qui che Kube Eagle è intervenuto con le sue capacità di monitoraggio delle risorse.
Quasi tutti i miei cluster Kubernetes erano monitorati solo con e . Node Exporter fornisce statistiche su input/output e utilizzo di disco, CPU e memoria RAM, mentre Kube State Metrics mostra le metriche degli oggetti Kubernetes, come richieste e limiti sulle risorse di CPU e memoria.
Dobbiamo combinare le metriche di utilizzo con le metriche di richieste e limiti in Grafana, e poi avremo tutte le informazioni sul problema. Sembra semplice, ma in realtà in questi due strumenti le etichette vengono chiamate in modo diverso, e alcune metriche non hanno affatto etichette di metadati. Kube Eagle fa tutto da solo e il pannello appare così:
Siamo riusciti a risolvere molti problemi di risorse e a risparmiare attrezzature:
- Alcuni sviluppatori non sapevano quante risorse servissero ai microservizi (o semplicemente non se ne preoccupavano). Non avevamo modo di trovare richieste errate sulle risorse — per questo bisogna conoscere i consumi oltre a richieste e limiti. Ora vedono le metriche di Prometheus, monitorano l'utilizzo effettivo e regolano richieste e limiti.
- Le applicazioni JVM occupano tutta la memoria RAM di cui hanno bisogno. Il garbage collector libera la memoria solo se viene utilizzato più del 75%. E poiché la maggior parte dei servizi utilizza memoria burstable, era sempre occupata dalla JVM. Di conseguenza, tutti questi servizi Java consumavano molta più memoria RAM di quanto previsto.
- Alcune applicazioni richiedevano troppa memoria, e il planner Kubernetes non assegnava queste nodi ad altre applicazioni, anche se in realtà erano più libere di altre nodi. Uno sviluppatore ha accidentalmente aggiunto una cifra in più nella richiesta, occupando un grosso pezzo di memoria RAM: 20 GB invece di 2. Nessuno se n'è accorto. L'applicazione aveva 3 repliche, quindi 3 nodi sono stati colpiti.
- Abbiamo imposto limiti sulle risorse, riprogettato i pod con richieste corrette e ottenuto un perfetto bilanciamento nell'utilizzo dell'hardware su tutti i nodi. Alcuni nodi potevano essere addirittura spenti. Poi abbiamo notato che avevamo macchine errate (orientate sulla CPU, non sulla memoria). Abbiamo cambiato tipo e rimosso altri nodi.
Conclusioni
Con risorse burstable nel cluster si utilizza in modo più efficiente l'hardware disponibile, ma il planner Kubernetes pianifica i pod in base alle richieste di risorse, il che è rischioso. Per uccidere due piccioni con una fava: evitare problemi e utilizzare le risorse al massimo, è necessario un buon monitoraggio. È proprio per questo che servirà. (esportatore Prometheus e pannello di monitoraggio Grafana).
Fonte: habr.com
