Vegere 2016 em li Buffer , û naha nêzîkê 60 nod (li ser AWS) û 1500 konteynir li ser koma meya k8s dixebitin ku ji hêla rêvebirinê ve têne rêve kirin. . Lêbelê, me bi ceribandin û xeletiyê ve çû servîsên mîkro, û tewra piştî çend salan xebata bi k8-an re jî em hîn jî bi pirsgirêkên nû re rû bi rû ne. Di vê postê de em ê li ser biaxivin sînorên processor: çima me difikirî ku ew pratîkek baş in û çima ew qas ne baş bûn.
Sînorkirinên processor û throttling
Mîna gelek bikarhênerên din ên Kubernetes, . Bêyî mîhengek weha, konteynerên di girêkekê de dikarin hemî hêza pêvajoyê hilgirin, ku di encamê de dibe sedema pêvajoyên girîng Kubernetes (mînakek kubelet) dê bersiva daxwazan rawestîne. Bi vî rengî, danîna sînorên CPU ji bo parastina girêkên xwe rêyek baş e.
Sînorên pêvajoyê konteynir li ser dema CPU ya herî zêde ya ku ew dikare ji bo heyamek taybetî bikar bîne destnîşan dike (pêşber 100ms e), û konteynir dê çu carî ji vê sînor derbas neke. Li Kubernetes ji bo rijandin konteynir û nehêle ku ew ji sînor derbas bibe, amûrek taybetî tê bikar anîn , lê ev sînorên CPU-ya çêkirî di encamê de zirarê didin performansê û dema bersivdana konteynerên we zêde dikin.
Çi dibe bila bibe eger em sînorên pêvajoyê destnîşan nekin?
Mixabin, em bi xwe jî neçar bûn ku bi vê pirsgirêkê re rû bi rû bimînin. Her nodek pêvajoyek ku berpirsiyarê birêvebirina konteyneran e kubelet, û wî dev ji bersivdana daxwazan berda. Node, dema ku ev yek bibe, wê bikeve nav dewletê NotReady, û konteynerên ji wê dê li cîhek din werin veguheztin û heman pirsgirêkan li ser girêkên nû biafirînin. Ne senaryoyek îdeal, bi kêmanî.
Nîşana pirsgirêka tinekirin û bersivdayînê
Metrîka sereke ji bo şopandina konteynerê ev e trottling, ew nîşan dide ka çend caran konteynera we hatiye rijandin. Me bi eleqedar ferq kir ku di hin konteyniran de tîrêjê çêdibe, bêyî ku barkirina pêvajoyê zehf e an na. Wekî mînakek, bila em li yek ji API-yên xwe yên sereke binêrin:
Wekî ku hûn li jêr dibînin, me sînor destnîşan kiriye 800m (0.8 an 80% bingehîn), û nirxên lûtkeyê herî baş digihîjin 200m (20% bingehîn). Wusa dixuye ku berî ku karûbarê xera bikin, me hîn jî pir hêza pêvajoyê heye, lêbelê ...
Dibe ku we ferq kiriye ku tewra gava ku barkirina pêvajoyê di binê sînorên diyarkirî de be - bi girîngî li jêr e - hîna jî qutbûn çêdibe.
Li hember vê yekê, me di demek kurt de çend çavkanî kifş kirin (, , ) Di derbarê daketina performans û dema bersivdayînê ya karûbaran de ji ber lêdanê.
Çima em di barkirina kêm a CPU-yê de xitimandinê dibînin? Guhertoya kurt ev e: "Di kernel Linux-ê de xeletiyek heye ku dibe sedem ku nepêwist qutkirina konteyneran bi sînorên pêvajoyê yên diyarkirî re çêbibe." Heke hûn bi xwezaya pirsgirêkê re eleqedar dibin, hûn dikarin pêşkêşiyê bixwînin ( и vebijark) ji hêla Dave Chiluk ve.
Rakirina sînorkirinên CPU (bi hişyariyek zehf)
Piştî nîqaşên dirêj, me biryar da ku em qedexeyên pêvajoyê ji hemî karûbarên ku rasterast an nerasterast bandor li fonksiyonên krîtîk ên ji bo bikarhênerên me dike rakin.
Ev biryar ne hêsan bû ji ber ku em pir qîmetê didin aramiya koma xwe. Di paşerojê de, me berê xwe bi bêîstiqrariya koma xwe ceribandiye, û dûv re karûbaran gelek çavkaniyan xerc kirin û xebata tevahiya girêka xwe hêdî kirin. Naha her tişt hinekî cûda bû: me têgihîştinek zelal a ku me ji komên xwe hêvî dikir, û her weha stratejiyek baş ji bo pêkanîna guhertinên plansazkirî hebû.
Nameya karsaziyê li ser pirsgirêkek lezgîn.
Gava ku qedexe têne rakirin meriv çawa girêkên xwe biparêze?
Veqetandina karûbarên "bêsînor":
Berê, me berê dît ku hin girêk ketine rewşek notReady, di serî de ji ber karûbarên ku gelek çavkaniyan dixwe.
Me biryar da ku em karûbarên weha di girêkên cihê ("navkirî") de bi cîh bikin da ku ew bi karûbarên "girêdayî" re mudaxele nekin. Wekî encamek, bi nîşankirina hin girêkan û lê zêdekirina pîvana toleransê li ser karûbarên "negirêdayî", me li ser komê kontrolek mezintir bi dest xist, û ji me re hêsantir bû ku pirsgirêkên bi girêkan re nas bikin. Ji bo ku hûn bi xwe pêvajoyên wekhev pêk bînin, hûn dikarin xwe nas bikin .
Tayînkirina pêvajoyek rast û daxwazek bîranînê:
Tirsa me ya herî mezin ev bû ku pêvajo dê gelek çavkaniyan bixwe û girêk dê bersivê bide daxwazan. Ji ber ku naha (bi saya Datadog) me karîbû bi zelalî çavdêriya hemî karûbarên li ser koma xwe bike, min çend mehên xebata wan ên ku me plan kir ku wekî "ne têkildar" binav bikin analîz kir. Min bi tenê karanîna CPU ya herî zêde bi marjînalek% 20 destnîşan kir û bi vî rengî cîh di girêkê de veqetand di doza ku k8s hewl dide ku karûbarên din ji girêkê re veqetîne.
Wekî ku hûn di grafîkê de dibînin, barkirina herî zêde ya li ser pêvajoyê gihîştiye 242m Corên CPU (0.242 core processor). Ji bo daxwazek pêvajoyek, bes e ku meriv hejmarek ji vê nirxê piçekî mezintir bigire. Ji kerema xwe ji bîr mekin ku ji ber ku karûbar bikarhêner-navendî ne, nirxên barkirina pez bi seyrûseferê re hevaheng in.
Bi karanîna bîranîn û pirsan re, û voila jî heman bikin - hûn hemî sazkirî ne! Ji bo ewlehiyek mezintir, hûn dikarin xweseriya podê ya horizontal lê zêde bikin. Ji ber vê yekê, her carê ku barkirina çavkaniyê zêde ye, pîvandina otomatîkî dê podên nû biafirîne, û kubernetes dê wan li girêkên bi cîhê belaş belav bike. Ger di komê bixwe de cîh nemîne, hûn dikarin ji xwe re hişyariyek saz bikin an pêvekirina girêkên nû bi navgîniya xweberkirina wan vesaz bikin.
Ji kêmasiyan, hêjayî gotinê ye ku me di "", yanî. hejmara konteynerên ku li ser yek nodê dixebitin. Di heman demê de dibe ku em di tîrêjiya seyrûsefera kêm de jî gelek "rehetî" hebin, û di heman demê de şansek heye ku hûn bigihîjin barek pêvajoyek bilind, lê divê girêkên otomatîkî bi ya paşîn re bibin alîkar.
Encam
Ez kêfxweş im ku van encamên hêja yên ceribandinên van çend hefteyên borî diweşînim; me jixwe di bersivê de di hemî karûbarên guhezbar de pêşveçûnên girîng dîtiye:
Me li ser rûpela xweya malê encamên çêtirîn bi dest xist (), li wir karûbar bileztir bû bîst û du caran!
Ma xeletiya kernel Linux rast e?
Erê, belavkirina guhertoya 4.19 û bilindtir.
Lêbelê, piştî xwendinê ji bo duyemîn îlona 2020 em hîn jî li ser hin projeyên Linux-ê yên ku bi xeletiyek wusa têne behs kirin. Ez bawer dikim ku hin belavkirinên Linux hîn jî vê xeletiyê hene û tenê li ser rastkirina wê dixebitin.
Ger guhertoya belavkirina we ji 4.19-ê kêmtir e, ez ê nûvekirina herî dawî pêşniyar bikim, lê di her rewşê de divê hûn biceribînin ku tixûbên pêvajoyê rakin û bibînin ka kêşandin berdewam dike. Li jêr hûn dikarin navnîşek qismî ya karûbarên rêveberiya Kubernetes û belavkirinên Linux bibînin:
- Debian: rastkirin di guhertoya herî dawî ya belavkirinê de yekbûyî, , û pir nû xuya dike (). Dibe ku hin guhertoyên berê jî werin sererast kirin.
- Ubuntu: di guhertoya herî dawî de yekbûyî rast bikin
- EKS hîna çareseriyek peyda kiriye . Ger guhertoya we ji vê kêmtir e, divê hûn AMI-ê nûve bikin.
- kops: у
kops 1.18+Wêneyê mêvandarê sereke dê Ubuntu 20.04 be. Ger guhertoya weya kops kevintir e, dibe ku hûn li benda rastkirinê bisekinin. Em bi xwe niha li bendê ne. - GKE (Google Cloud): Yekgirtî rast bikin , lêbelê pirsgirêkên bi tîrêjê hene .
Ger çareserkirinê pirsgirêka tansiyonê çareser bike çi bike?
Ez bawer nakim ku pirsgirêk bi tevahî çareser bibe. Gava ku em gihîştin guhertoya kernelê ya bi rastkirinê, ez ê komê biceribînim û postê nûve bikim. Ger kesek jixwe nûve kiriye, ez ê meraq bikim ku encamên we bixwînim.
encamê
- Ger hûn bi konteynerên Docker-ê yên di bin Linux-ê de bixebitin (ferq nake Kubernetes, Mesos, Swarm an yên din), dibe ku konteynerên we ji ber lêdanê performansê winda bikin;
- Bi guhertoya herî dawî ya belavkirina xwe nûve bikin bi hêvîya ku xeletî jixwe hatî rast kirin;
- Rakirina sînorên pêvajoyê dê pirsgirêkê çareser bike, lê ev teknîkek xeternak e ku divê bi hişyariyek zehf were bikar anîn (çêtir e ku hûn pêşî kernel nûve bikin û encaman bidin ber hev);
- Ger we sînorên CPU rakirin, bi baldarî karanîna CPU û bîranîna xwe bişopînin û pê ewle bin ku çavkaniyên CPU-ya we ji xerckirina we zêdetir in;
- Vebijarkek ewledar dê ev be ku podên otomatîkî biafirînin da ku di rewşek barkirina hardware ya zêde de podên nû biafirînin, da ku kubernetes wan bi girêkên belaş veqetîne.
Ez hêvî dikim ku ev post ji we re dibe alîkar ku hûn performansa pergalên konteyneran baştir bikin.
PS nivîskar bi xwendevan û şîrovekaran re (bi îngilîzî) re hevpeyivîn dike.
Source: www.habr.com