Gibuhat nako ang Kube Eagle - usa ka eksporter sa Prometheus. Kini nahimo nga usa ka cool nga butang nga makatabang aron mas masabtan ang mga kahinguhaan sa gagmay ug medium nga kadako nga mga pungpong. Sa katapusan, nakadaginot ko og gatusan ka mga dolyar tungod kay gipili nako ang husto nga mga tipo sa makina ug gi-configure ang mga limitasyon sa kapanguhaan sa aplikasyon alang sa mga workloads.
Isulti ko kanimo ang bahin sa mga benepisyo , apan una nakong ipasabot kon unsay hinungdan sa kaguliyang ug nganong gikinahanglan ang taas nga kalidad nga pagmonitor.
Nakadumala ko og daghang pungpong sa 4β50 ka node. Ang matag cluster adunay hangtod sa 200 ka microservice ug aplikasyon. Aron mas maayo nga magamit ang kasamtangan nga hardware, kadaghanan sa mga deployment gi-configure nga adunay burstable nga RAM ug mga kapanguhaan sa CPU. Niining paagiha, ang mga pod mahimong makakuha sa magamit nga mga kapanguhaan kung gikinahanglan, ug sa samang higayon dili makabalda sa ubang mga aplikasyon niini nga node. Aw, dili ba kini maayo?
Ug bisan kung ang cluster mikonsumo medyo gamay nga CPU (8%) ug RAM (40%), kanunay kami adunay mga problema sa mga pod nga gi-preempted sa diha nga sila misulay sa paggahin og dugang nga memorya kay sa anaa sa node. Kaniadto aduna ra kami usa ka dashboard alang sa pag-monitor sa mga kapanguhaan sa Kubernetes. Ingon ani:
Grafana dashboard nga adunay cAdvisor metrics lang
Sa ingon nga panel, dili problema ang pagtan-aw sa mga node nga mokaon og daghang memorya ug CPU. Ang problema mao ang pagpangita kung unsa ang hinungdan. Aron mapabilin ang mga pod sa lugar, ang usa mahimo nga magbutang ug garantiya nga mga kapanguhaan sa tanan nga mga pod (gihangyo nga mga kapanguhaan nga katumbas sa limitasyon). Apan dili kini ang labing maalamon nga paggamit sa hardware. Ang cluster adunay pipila ka gatus ka gigabytes nga memorya, samtang ang pipila ka mga node gigutom, samtang ang uban adunay 4-10 GB nga nahabilin sa reserba.
Kini nahimo nga ang Kubernetes scheduler nag-apod-apod sa mga workload nga dili parehas sa mga magamit nga kapanguhaan. Giisip sa Kubernetes scheduler ang lain-laing mga configuration: affinity, taints and tolerations rules, node selectors nga mahimong limitahan ang available nodes. Apan sa akong kaso wala'y ingon niana, ug ang mga pod giplano depende sa gihangyo nga mga kapanguhaan sa matag node.
Ang node nga adunay labing libre nga mga kapanguhaan ug nga makatagbaw sa mga kondisyon sa hangyo gipili alang sa pod. Among nakit-an nga ang gipangayo nga mga kapanguhaan sa mga node wala motakdo sa aktuwal nga paggamit, ug dinhi ang Kube Eagle ug ang mga kapabilidad sa pagmonitor sa kahinguhaan niini nakaluwas.
Naa koy halos tanang Kubernetes clusters nga gimonitor lang ΠΈ . Ang Node Exporter naghatag og estadistika sa paggamit sa I/O ug disk, CPU, ug RAM, samtang ang Kube State Metrics nagpakita sa Kubernetes object metrics sama sa mga request ug CPU ug memory resource limits.
Kinahanglan namon nga isagol ang mga sukatan sa paggamit sa mga hangyo ug mga sukatan sa limitasyon sa Grafana, ug dayon makuha namon ang tanan nga kasayuran bahin sa problema. Kini paminawon nga yano, apan ang duha ka mga himan sa tinuud nagngalan sa mga label nga lahi, ug ang pipila nga mga sukatan walaβy bisan unsang mga label sa metadata. Gihimo sa Kube Eagle ang tanan ug ang panel ingon niini:
Nasulbad namon ang daghang mga problema sa mga kahinguhaan ug makatipig sa mga kagamitan:
- Ang ubang mga developers wala mahibalo kon sa unsang paagi sa daghan nga mga kapanguhaan microservices gikinahanglan (o sa yano wala magsamok). Walaβy paagi nga makit-an namon ang dili husto nga mga hangyo alang sa mga kapanguhaan - alang niini kinahanglan namon mahibal-an ang pagkonsumo ug mga hangyo ug limitasyon. Karon ilang nakita ang Prometheus metrics, monitor sa aktuwal nga paggamit ug adjust hangyo ug limitasyon.
- Ang mga aplikasyon sa JVM nagkuha ug daghang RAM kutob sa ilang mahimo. Ang garbage collector mopagawas lang og memory kung kapin sa 75% ang gigamit. Ug tungod kay kadaghanan sa mga serbisyo adunay burstable nga panumduman, kini kanunay nga giokupahan sa JVM. Busa, kining tanan nga mga serbisyo sa Java nagkaon ug mas daghang RAM kay sa gipaabot.
- Ang ubang mga aplikasyon nangayo ug daghan kaayong memorya, ug ang Kubernetes scheduler wala maghatag niini nga mga node ngadto sa ubang mga aplikasyon, bisan tuod sa pagkatinuod kini mas gawasnon kay sa ubang mga node. Ang usa ka developer aksidenteng midugang og dugang nga digit sa hangyo ug mikuha og dako nga piraso sa RAM: 20 GB imbes 2. Walay nakamatikod. Ang aplikasyon adunay 3 nga mga replika, busa hangtod sa 3 nga mga node ang naapektuhan.
- Gipaila namo ang mga limitasyon sa kahinguhaan, gi-reschedule usab ang mga pod nga adunay hustong mga hangyo, ug nakakuha og maayong balanse sa paggamit sa hardware sa tanang node. Ang usa ka magtiayon nga mga node mahimo nga sirado sa tanan. Ug unya among nakita nga kami adunay sayup nga mga makina (CPU oriented, dili memory oriented). Gibag-o namon ang tipo ug gitangtang ang daghang mga node.
Mga resulta
Uban sa mga burstable nga mga kapanguhaan sa cluster, imong gigamit ang magamit nga hardware nga mas episyente, apan ang Kubernetes scheduler nag-iskedyul og mga pod base sa mga hangyo alang sa mga kapanguhaan, ug kini puno. Sa pagpatay sa duha ka langgam sa usa ka bato: aron malikayan ang mga problema ug sa paggamit sa mga kahinguhaan sa hingpit, kinahanglan nimo ang maayong pagmonitor. Mao kini ang hinungdan nga kini mapuslanon (Prometheus exporter ug Grafana dashboard).
Source: www.habr.com