Ginawa ko ang Kube Eagle - isang Prometheus exporter. Ito ay naging isang cool na bagay na tumutulong upang mas maunawaan ang mga mapagkukunan ng maliliit at katamtamang laki ng mga kumpol. Sa huli, nakatipid ako ng daan-daang dolyar dahil pinili ko ang mga tamang uri ng makina at na-configure ang mga limitasyon ng mapagkukunan ng application para sa mga workload.
Sasabihin ko sa iyo ang tungkol sa mga benepisyo , ngunit ipapaliwanag ko muna kung ano ang sanhi ng kaguluhan at kung bakit kailangan ang mataas na kalidad na pagsubaybay.
Namamahala ako ng ilang kumpol ng 4β50 node. Ang bawat cluster ay naglalaman ng hanggang 200 microservice at application. Upang mas mahusay na magamit ang kasalukuyang hardware, karamihan sa mga deployment ay na-configure gamit ang burstable na RAM at mga mapagkukunan ng CPU. Sa ganitong paraan, ang mga pod ay maaaring kumuha ng mga magagamit na mapagkukunan kung kinakailangan, at sa parehong oras ay hindi makagambala sa iba pang mga application sa node na ito. Well, hindi ba ito mahusay?
At kahit na ang cluster ay gumagamit ng medyo maliit na CPU (8%) at RAM (40%), palagi kaming nagkakaroon ng mga problema sa mga pod na na-preempted kapag sinubukan nilang maglaan ng mas maraming memory kaysa sa magagamit sa node. Noon ay mayroon lamang kaming isang dashboard para sa pagsubaybay sa mga mapagkukunan ng Kubernetes. Ganito:
Grafana dashboard na may mga sukatan ng cAdvisor lang
Sa ganitong panel, hindi problema na makita ang mga node na kumakain ng maraming memorya at CPU. Ang problema ay upang malaman kung ano ang dahilan. Para mapanatili ang mga pod sa lugar, siyempre, maaaring mag-set up ang isa ng mga garantisadong mapagkukunan sa lahat ng pod (hiniling na mapagkukunan na katumbas ng limitasyon). Ngunit hindi ito ang pinakamatalinong paggamit ng hardware. Ang cluster ay may ilang daang gigabytes ng memory, habang ang ilang mga node ay nagugutom, habang ang iba ay may 4β10 GB na natitira sa reserba.
Lumalabas na ang scheduler ng Kubernetes ay namahagi ng mga workload nang hindi pantay sa mga magagamit na mapagkukunan. Isinasaalang-alang ng scheduler ng Kubernetes ang iba't ibang configuration: affinity, taints at tolerations rules, node selector na maaaring limitahan ang mga available na node. Ngunit sa aking kaso ay walang ganoon, at ang mga pod ay binalak depende sa hiniling na mapagkukunan sa bawat node.
Ang node na may pinakamaraming libreng mapagkukunan at nakakatugon sa mga kondisyon ng kahilingan ay pinili para sa pod. Nalaman namin na ang mga hiniling na mapagkukunan sa mga node ay hindi tumugma sa aktwal na paggamit, at dito sumagip ang Kube Eagle at ang mga kakayahan nito sa pagsubaybay sa mapagkukunan.
Halos lahat ng Kubernetes clusters ay sinusubaybayan ko lang ΠΈ . Nagbibigay ang Node Exporter ng mga istatistika sa paggamit ng I/O at disk, CPU, at RAM, habang ipinapakita ng Kube State Metrics ang mga sukatan ng object ng Kubernetes gaya ng mga kahilingan at mga limitasyon ng CPU at memory resource.
Kailangan naming pagsamahin ang mga sukatan ng paggamit sa mga sukatan ng mga kahilingan at limitasyon sa Grafana, at pagkatapos ay makukuha namin ang lahat ng impormasyon tungkol sa problema. Ito ay mukhang simple, ngunit ang dalawang tool ay aktwal na pinangalanan ang mga label sa ibang paraan, at ang ilang mga sukatan ay walang anumang mga label ng metadata. Ginagawa ng Kube Eagle ang lahat at ganito ang hitsura ng panel:
Nagawa naming malutas ang maraming problema sa mga mapagkukunan at makatipid ng kagamitan:
- Ang ilang mga developer ay hindi alam kung gaano karaming mga mapagkukunan ang kailangan ng mga microservice (o hindi lang nag-abala). Walang paraan para makahanap kami ng mga maling kahilingan para sa mga mapagkukunan - para dito kailangan naming malaman ang pagkonsumo kasama ang mga kahilingan at limitasyon. Ngayon ay nakikita na nila ang mga sukatan ng Prometheus, sinusubaybayan ang aktwal na paggamit at inaayos ang mga kahilingan at limitasyon.
- Ang mga JVM application ay kumukuha ng mas maraming RAM hangga't kaya nila. Ang tagakolekta ng basura ay naglalabas lamang ng memorya kapag higit sa 75% ang ginamit. At dahil karamihan sa mga serbisyo ay may burstable na memorya, palagi itong inookupahan ng JVM. Samakatuwid, ang lahat ng mga serbisyong ito ng Java ay kumakain ng mas maraming RAM kaysa sa inaasahan.
- Ang ilang mga application ay humiling ng masyadong maraming memory, at ang Kubernetes scheduler ay hindi nagbigay ng mga node na ito sa iba pang mga application, kahit na sa katunayan sila ay mas libre kaysa sa iba pang mga node. Isang developer ang aksidenteng nagdagdag ng dagdag na digit sa kahilingan at nakakuha ng malaking piraso ng RAM: 20 GB sa halip na 2. Walang nakapansin. Ang application ay mayroong 3 replika, kaya hanggang 3 node ang naapektuhan.
- Ipinakilala namin ang mga limitasyon sa mapagkukunan, nag-reschedule ng mga pod na may tamang mga kahilingan, at nakakuha ng perpektong balanse ng paggamit ng hardware sa lahat ng node. Ang isang pares ng mga node ay maaaring sarado nang buo. At pagkatapos ay nakita namin na mayroon kaming mga maling makina (CPU oriented, hindi memory oriented). Binago namin ang uri at nagtanggal ng ilan pang mga node.
Mga resulta ng
Sa mga burstable na mapagkukunan sa cluster, mas mahusay mong ginagamit ang available na hardware, ngunit ang scheduler ng Kubernetes ay nag-iskedyul ng mga pod batay sa mga kahilingan para sa mga mapagkukunan, at ito ay puno. Upang patayin ang dalawang ibon gamit ang isang bato: upang maiwasan ang mga problema at gamitin nang husto ang mga mapagkukunan, kailangan mo ng mahusay na pagsubaybay. Ito ang dahilan kung bakit ito ay magiging kapaki-pakinabang (Prometheus exporter at Grafana dashboard).
Pinagmulan: www.habr.com