Balik sa 2016 kami sa Buffer , ug karon mga 60 ka node (sa AWS) ug 1500 ka mga sudlanan ang nagtrabaho sa among k8s cluster nga gidumala sa . Bisan pa, mibalhin kami sa mga microservice pinaagi sa pagsulay ug sayup, ug bisan pagkahuman sa daghang tuig nga pagtrabaho kauban ang mga k8 nag-atubang gihapon kami sa mga bag-ong problema. Niini nga post atong hisgutan mga limitasyon sa processor: nganong naghunahuna kami nga maayo sila nga praktis ug nganong nahimo silang dili kaayo maayo.
Mga limitasyon sa processor ug throttling
Sama sa daghang ubang tiggamit sa Kubernetes, . Kung wala ang ingon nga setting, ang mga sulud sa usa ka node mahimong makakuha sa tanan nga gahum sa processor, nga sa baylo hinungdan sa hinungdanon nga mga proseso sa Kubernetes (pananglitan kubelet) mohunong sa pagtubag sa mga hangyo. Sa ingon, ang pagtakda sa mga limitasyon sa CPU usa ka maayong paagi aron mapanalipdan ang imong mga node.
Ang mga limitasyon sa processor nagtakda sa usa ka sudlanan sa pinakataas nga oras sa CPU nga magamit niini alang sa usa ka piho nga panahon (ang default mao ang 100ms), ug ang sudlanan dili gayud molapas niini nga limitasyon. Sa Kubernetes para throttling sudlanan ug pugngan kini nga molapas sa limitasyon, gigamit ang usa ka espesyal nga himan , apan kining mga artipisyal nga limitasyon sa CPU makadaut sa performance ug makadugang sa oras sa pagtubag sa imong mga sudlanan.
Unsa man ang mahitabo kung dili kami magtakda og mga limitasyon sa processor?
Ikasubo, kami mismo ang nag-atubang niini nga problema. Ang matag node adunay proseso nga responsable sa pagdumala sa mga sudlanan kubelet, ug mihunong siya sa pagtubag sa mga hangyo. Ang node, kung kini mahitabo, moadto sa estado NotReady, ug ang mga sudlanan gikan niini i-redirect sa laing dapit ug maghimo sa samang mga problema sa bag-ong mga node. Dili usa ka sulundon nga senaryo, aron isulti ang labing gamay.
Pagpadayag sa problema sa throttling ug tubag
Ang yawe nga sukatan alang sa pagsubay sa sulud mao ang trottling, kini nagpakita kung pila ka beses ang imong sudlanan na-throttle. Namatikdan namon nga interesado ang presensya sa throttling sa pipila nga mga sudlanan, bisan kung ang pagkarga sa processor grabe o dili. Isip usa ka pananglitan, atong tan-awon ang usa sa atong nag-unang mga API:
Sama sa imong makita sa ubos, among gibutang ang limitasyon sa 800m (0.8 o 80% nga kinauyokan), ug mga peak nga kantidad sa labing kaayo nga pagkab-ot 200m (20% nga kinauyokan). Ingon og sa wala pa i-throttling ang serbisyo aduna pa kitay daghang gahum sa processor, bisan pa...
Mahimo nimong namatikdan nga bisan kung ang load sa processor ubos sa gitakda nga mga limitasyon - labi ka ubos - ang throttling mahitabo gihapon.
Nag-atubang niini, sa wala madugay nadiskobrehan namo ang daghang mga kapanguhaan (, , ) mahitungod sa pagkunhod sa performance ug oras sa pagtubag sa mga serbisyo tungod sa throttling.
Ngano nga nakita namon ang pag-throttling sa ubos nga load sa CPU? Ang mubo nga bersyon mao ang: "adunay usa ka bug sa Linux kernel nga hinungdan sa wala kinahanglana nga throttling sa mga sudlanan nga adunay piho nga mga limitasyon sa processor." Kung interesado ka sa kinaiya sa problema, mahimo nimong basahon ang presentasyon ( ΠΈ mga kapilian) ni Dave Chiluk.
Pagtangtang sa mga pagdili sa CPU (uban ang hilabihang pag-amping)
Pagkahuman sa taas nga mga diskusyon, nakahukom kami nga tangtangon ang mga pagdili sa processor gikan sa tanan nga mga serbisyo nga direkta o dili direkta nga nakaapekto sa kritikal nga pagpaandar alang sa among mga tiggamit.
Dili sayon ββang desisyon tungod kay gipabilhan kaayo namo ang kalig-on sa among cluster. Kaniadto, nag-eksperimento na kami sa pagkawalay kalig-on sa among cluster, ug unya ang mga serbisyo nag-usik sa daghang mga kapanguhaan ug gipahinay ang trabaho sa ilang tibuuk nga node. Karon ang tanan medyo lahi: kami adunay usa ka tin-aw nga pagsabut sa kung unsa ang among gipaabut gikan sa among mga pundok, ingon man usa ka maayong estratehiya alang sa pagpatuman sa giplano nga mga pagbag-o.
Mga sulat sa negosyo sa usa ka dinalian nga isyu.
Giunsa pagpanalipod ang imong mga node kung gitangtang ang mga pagdili?
Pag-inusara sa "walay pugong" nga mga serbisyo:
Kaniadto, nakita na nato ang pipila ka mga node nga nahimong estado notReady, nag-una tungod sa mga serbisyo nga nagkonsumo sa daghang mga kapanguhaan.
Nakahukom kami nga ibutang ang ingon nga mga serbisyo sa bulag nga ("gimarkahan") nga mga node aron dili kini makabalda sa mga serbisyo nga "may kalabutan". Ingon nga resulta, pinaagi sa pagmarka sa pipila ka mga node ug pagdugang sa tolerance parameter sa "walay kalabutan" nga mga serbisyo, nakab-ot namo ang mas dako nga kontrol sa cluster, ug nahimong mas sayon ββalang kanamo ang pag-ila sa mga problema sa mga node. Aron mahimo ang parehas nga mga proseso sa imong kaugalingon, mahimo nimong pamilyar ang imong kaugalingon .
Pag-assign sa husto nga processor ug hangyo sa memorya:
Ang among labing dako nga kahadlok mao nga ang proseso mogamit sa daghang mga kapanguhaan ug ang node mohunong sa pagtubag sa mga hangyo. Sukad karon (salamat sa Datadog) klaro namong mamonitor ang tanang serbisyo sa among cluster, akong gi-analisa ang pipila ka bulan nga operasyon niadtong among giplanohan nga itudlo nga "walay kalabutan". Gibutang ra nako ang labing kadaghan nga paggamit sa CPU nga adunay margin nga 20%, ug sa ingon gigahin ang wanang sa node kung ang k8s mosulay sa pag-assign sa ubang mga serbisyo sa node.
Sama sa imong makita sa graph, ang maximum load sa processor nakaabot na 242m CPU cores (0.242 processor cores). Alang sa usa ka hangyo sa processor, igo na ang pagkuha sa usa ka numero nga mas dako kaysa niini nga kantidad. Palihug timan-i nga tungod kay ang mga serbisyo kay user-centric, ang peak load values ββcoincide sa traffic.
Buhata ang parehas sa paggamit sa memorya ug mga pangutana, ug voila - na-set up ka na! Para sa mas dako nga seguridad, mahimo nimong idugang ang horizontal pod autoscaling. Busa, sa matag higayon nga taas ang resource load, ang autoscaling maghimo ug bag-ong mga pod, ug ang mga kubernete mag-apod-apod niini ngadto sa mga node nga adunay libre nga luna. Kung wala nay lugar nga nahabilin sa cluster mismo, mahimo nimong ibutang ang imong kaugalingon nga alerto o i-configure ang pagdugang sa mga bag-ong node pinaagi sa ilang autoscaling.
Sa mga minus, angay nga hinumdoman nga nawala kami sa "", i.e. gidaghanon sa mga sudlanan nga nagdagan sa usa ka node. Mahimo usab nga kita adunay daghang mga "relaxation" sa ubos nga densidad sa trapiko, ug adunay higayon usab nga makaabot ka sa taas nga load sa processor, apan ang mga autoscaling node kinahanglan nga makatabang sa ulahi.
Π Π΅Π·ΡΠ»ΡΡΠ°ΡΡ
Nalipay ko nga imantala kining maayo kaayong mga resulta gikan sa mga eksperimento sa milabay nga pipila ka semana; nakakita na mig mahinungdanong mga kalamboan agig tubag sa tanang giusab nga serbisyo:
Nakab-ot namo ang pinakamaayong resulta sa among home page (), didto mikusog ang serbisyo baynte duha ka beses!
Naayo ba ang Linux kernel bug?
Oo, distribusyon nga bersyon 4.19 ug mas taas pa.
Apan, sa pagbasa alang sa ikaduha sa Septyembre 2020 nakit-an gihapon namon ang mga paghisgot sa pipila ka mga proyekto sa Linux nga adunay parehas nga bug. Nagtuo ako nga ang pipila ka mga pag-apod-apod sa Linux adunay kini nga bug ug nagtrabaho lang sa pag-ayo niini.
Kung ang imong bersyon sa pag-apod-apod mas ubos kaysa 4.19, akong irekomendar ang pag-update sa pinakabag-o, apan sa bisan unsang kaso kinahanglan nimong sulayan nga tangtangon ang mga pagdili sa processor ug tan-awa kung magpadayon ba ang throttling. Sa ubos makita nimo ang partial nga listahan sa mga serbisyo sa pagdumala sa Kubernetes ug mga distribusyon sa Linux:
- Debian: ayo nga gisagol sa pinakabag-o nga bersyon sa pag-apod-apod, , ug presko kaayo tan-awon (). Ang ubang mga naunang bersyon mahimo usab nga ayohon.
- Ubuntu: ayo nga gisagol sa pinakabag-o nga bersyon
- Ang EKS aduna pa'y pag-ayo . Kung ang imong bersyon mas ubos kaysa niini, kinahanglan nimo nga i-update ang AMI.
- kops: Ρ
kops 1.18+Ang nag-unang imahe sa host mao ang Ubuntu 20.04. Kung ang imong bersyon sa kops mas karaan, mahimo ka maghulat alang sa pag-ayo. Kami mismo naghulat karon. - GKE (Google Cloud): Pag-ayo sa integrated , bisan pa adunay mga problema sa throttling .
Unsa ang buhaton kung giayo sa pag-ayo ang problema sa throttling?
Dili ko sigurado nga ang problema hingpit nga nasulbad. Kung makaabut kami sa bersyon sa kernel nga adunay ayo, sulayan nako ang cluster ug i-update ang post. Kung adunay naka-update na, interesado ako nga basahon ang imong mga resulta.
konklusyon
- Kung nagtrabaho ka sa mga sudlanan sa Docker sa ilawom sa Linux (bisan unsa ang Kubernetes, Mesos, Swarm o uban pa), ang imong mga sudlanan mahimong mawad-an sa pasundayag tungod sa throttling;
- Sulayi ang pag-update sa pinakabag-o nga bersyon sa imong pag-apod-apod sa paglaum nga ang bug naayo na;
- Ang pagtangtang sa mga limitasyon sa processor makasulbad sa problema, apan kini usa ka delikado nga teknik nga kinahanglan gamiton sa hilabihan nga pag-amping (mas maayo nga una nga i-update ang kernel ug itandi ang mga resulta);
- Kung imong gitangtang ang mga limitasyon sa CPU, pag-monitor pag-ayo sa imong CPU ug paggamit sa memorya ug siguroa nga ang imong mga kapanguhaan sa CPU labaw sa imong konsumo;
- Ang usa ka luwas nga kapilian mao ang pag-autoscale sa mga pod aron makahimo og bag-ong mga pod kung adunay taas nga karga sa hardware, aron ang mga kubernetes mag-assign kanila sa libre nga mga node.
Nanghinaut ko nga kini nga post makatabang kanimo sa pagpalambo sa performance sa imong mga container system.
PS ang tagsulat nahiuyon sa mga magbabasa ug komentarista (sa English).
Source: www.habr.com