Aku nggawe Kube Eagle - eksportir Prometheus. Pranyata dadi bab kelangan sing mbantu kanggo luwih ngerti sumber daya saka klompok cilik lan medium-ukuran. Pungkasane, aku ngirit atusan dolar amarga milih jinis mesin sing pas lan ngatur watesan sumber daya aplikasi kanggo beban kerja.
Aku bakal pitutur marang kowe bab keuntungan , nanging pisanan aku bakal nerangake apa sing nyebabake keributan lan ngapa perlu ngawasi kualitas dhuwur.
Aku ngatur sawetara klompok 4-50 simpul. Saben kluster ngemot nganti 200 layanan mikro lan aplikasi. Kanggo nggunakake hardware sing wis ana, umume panyebaran dikonfigurasi karo sumber daya RAM lan CPU sing bisa bledosan. Kanthi cara iki, polong bisa njupuk sumber daya sing kasedhiya yen perlu, lan ing wektu sing padha ora ngganggu aplikasi liyane ing simpul iki. Inggih, iku ora apik?
Lan sanajan kluster nganggo CPU sing relatif cilik (8%) lan RAM (40%), kita terus-terusan ngalami masalah karo polong sing diprediksi nalika nyoba nyedhiyakake memori luwih akeh tinimbang sing kasedhiya ing simpul. Nalika iku, kita mung duwe siji dasbor kanggo ngawasi sumber daya Kubernetes. Kaya iki:
Dashboard Grafana mung nganggo metrik cAdvisor
Kanthi panel kuwi, iku ora masalah kanggo ndeleng kelenjar sing mangan akeh memori lan CPU. Masalahe yaiku kanggo ngerteni apa sebabe. Kanggo njaga polong ing panggonan, mesthine bisa nyetel sumber daya sing dijamin ing kabeh polong (sumber daya sing dijaluk padha karo watesan). Nanging iki dudu panggunaan hardware sing paling cerdas. Kluster kasebut duwe sawetara atus gigabyte memori, nalika sawetara kelenjar kelaparan, dene liyane duwe cadangan 4-10 GB.
Pranyata manawa panjadwal Kubernetes nyebarake beban kerja sing ora rata ing sumber daya sing kasedhiya. Penjadwal Kubernetes njupuk konfigurasi sing beda-beda: aturan afinitas, taint lan toleransi, pamilih simpul sing bisa mbatesi simpul sing kasedhiya. Nanging ing kasusku, ora ana sing kaya ngono, lan polong direncanakake gumantung saka sumber daya sing dijaluk ing saben simpul.
Node sing nduweni sumber daya paling gratis lan sing nyukupi syarat panyuwunan dipilih kanggo pod. Kita nemokake manawa sumber daya sing dijaluk ing simpul kasebut ora cocog karo panggunaan nyata, lan ing kene Kube Eagle lan kemampuan ngawasi sumber daya teka kanggo ngluwari.
Aku meh kabeh kluster Kubernetes ngawasi mung karo ΠΈ . Node Exporter nyedhiyakake statistik babagan panggunaan I/O lan disk, CPU, lan RAM, dene Kube State Metrics nuduhake metrik obyek Kubernetes kayata panjalukan lan watesan sumber daya CPU lan memori.
Kita kudu nggabungake metrik panggunaan karo panjalukan lan watesan metrik ing Grafana, banjur kita bakal entuk kabeh informasi babagan masalah kasebut. Iki muni prasaja, nanging rong alat kasebut bener-bener menehi jeneng label kanthi beda, lan sawetara metrik ora duwe label metadata. Kube Eagle nindakake kabeh dhewe lan panel katon kaya iki:
Kita bisa ngatasi akeh masalah karo sumber daya lan nyimpen peralatan:
- Sawetara pangembang ora ngerti carane akeh sumber daya microservices needed (utawa mung ora keganggu). Ora ana cara kanggo nemokake panjalukan sing salah kanggo sumber daya - iki kita kudu ngerti konsumsi plus panjalukan lan watesan. Saiki dheweke ndeleng metrik Prometheus, ngawasi panggunaan nyata lan nyetel panjaluk lan watesan.
- Aplikasi JVM njupuk akeh RAM sing bisa ditangani. Penagih sampah mung ngeculake memori nalika luwih saka 75% digunakake. Lan amarga paling layanan duwe memori burstable, iku tansah dikuwasani dening JVM. Mulane, kabeh layanan Java iki mangan luwih akeh RAM saka samesthine.
- Sawetara aplikasi njaluk memori akeh banget, lan panjadwal Kubernetes ora menehi simpul kasebut menyang aplikasi liyane, sanajan nyatane luwih bebas tinimbang simpul liyane. Salah pangembang sengaja nambah digit ekstra ing panjalukan lan nyekel Piece gedhe saka RAM: 20 GB tinimbang 2. Ora ana kang weruh. Aplikasi kasebut duwe 3 replika, saengga 3 node kena pengaruh.
- Kita ngenalake watesan sumber daya, polong sing dijadwal maneh kanthi panjaluk sing bener, lan entuk keseimbangan panggunaan hardware sing cocog ing kabeh simpul. Saperangan simpul bisa ditutup kabeh. Banjur kita weruh yen kita duwe mesin sing salah (oriented CPU, ora orientasi memori). Kita ngganti jinis lan mbusak sawetara simpul liyane.
Hasil
Kanthi sumber daya burstable ing kluster, sampeyan nggunakake hardware kasedhiya luwih irit, nanging panjadwal Kubernetes jadwal pods adhedhasar panjalukan kanggo sumber daya, lan iki fraught. Kanggo mateni rong manuk kanthi siji watu: supaya ora ana masalah lan nggunakake sumber daya kanthi lengkap, sampeyan kudu ngawasi sing apik. Iki kok bakal migunani (Eksportir Prometheus lan dashboard Grafana).
Source: www.habr.com