27ê Nîsanê li konferansê , di çarçoveya beşa "DevOps" de, rapora "Autoscaling û rêveberiya çavkaniyê li Kubernetes" hate dayîn. Ew diaxive ka hûn çawa dikarin K8-ê bikar bînin da ku hebûna zêde ya serîlêdanên xwe bicîh bikin û performansa pez misoger bikin.
Li gorî kevneşopiyê, em kêfxweş in ku pêşkêş dikin (44 hûrdem, ji gotarê pir agahdartir) û kurteya bingehîn di forma nivîsê de. Ajotin!
Em mijara raporê peyv bi peyv analîz bikin û ji dawiyê dest pê bikin.
Kubernetes
Ka em bibêjin li ser mêvandarê me konteynerên Docker hene. Bo çi? Ji bo dabînkirina dubarebûn û veqetandinê, ku di encamê de rê dide sazkirina hêsan û baş, CI/CD. Gelek wesayîtên me yên bi konteynir hene.
Kubernetes di vê rewşê de çi peyda dike?
- Em dev ji ramana van makîneyan berdidin û bi "ewrê" re dest bi xebatê dikin komê konteynir an jî potan (komên konteyneran).
- Digel vê yekê, em li ser podên kesane jî nafikirin, lê bêtir îdare dikinоkomên mezintir. Yên wisa primitives-asta bilind rê bidin me ku em bibêjin ku şablonek ji bo xebitandina karek diyarkirî heye, û li vir ji bo xebitandina wê hejmareka pêwîst a nimûneyan heye. Ger em paşê şablonê biguhezînin, dê hemî mînak werin guhertin.
- Bi alîkariya alîkariya API-ya ragihandinê Li şûna ku em rêzek fermanên taybetî bicîh bînin, em "saziya cîhanê" (di YAML) de, ku ji hêla Kubernetes ve hatî afirandin, vedibêjin. Û dîsa: gava ku şirove biguhere, dê nîşana wê ya rastîn jî biguhere.
Rêveberiya Çavkaniyê
CPU
Ka em li ser serverê nginx, php-fpm û mysql bimeşînin. Van karûbaran bi rastî dê hîn bêtir pêvajoyên ku dimeşin hebin, ku her yek ji wan çavkaniyên hesabkirinê hewce dike:
(hejmarên li ser slaytê "parrot" in, hewcedariya razber a her pêvajoyê ji bo hêza hesabkirinê)
Ji bo ku meriv bi vê re hêsantir bixebite, mentiqî ye ku meriv pêvajoyan di koman de berhev bike (mînak, hemî pêvajoyên nginx di yek komê de "nginx"). Rêbazek hêsan û eşkere ji bo kirina vê yekê ev e ku hûn her komê di konteynirekê de bixin:
Ji bo berdewamkirinê, hûn hewce ne ku bîr bînin ku konteynir çi ye (li Linux). Xuyabûna wan bi saya sê taybetmendiyên sereke yên di kernelê de, ku pir dirêj berê hatine bicîh kirin, pêk hat: , и . Û pêşkeftina bêtir ji hêla teknolojiyên din ve hate hêsan kirin (tevî "şêlên" rehet ên mîna Docker):
Di çarçoveya raporê de tenê me eleqedar dike cgroups, ji ber ku komên kontrolê beşek fonksiyona konteyneran in (Docker, hwd.) ku rêveberiya çavkaniyê bicîh tîne. Pêvajoyên ku di nav koman de têne hev kirin, wekî ku me dixwest, komên kontrolê ne.
Ka em vegerin ser hewcedariyên CPU yên ji bo van pêvajoyan, û naha ji bo komên pêvajoyan:
(Ez dubare dikim ku hemî hejmar vegotinek razber a hewcedariya çavkaniyan in)
Di heman demê de, CPU bixwe xwedan çavkaniyek bêdawî ye (di nimûne de ev 1000 e), ku dibe ku her kes kêm nebe (hevdengiya hewcedariyên hemî koman 150+850+460=1460 e). Di vê rewşê de dê çi bibe?
Kernel dest bi belavkirina çavkaniyan dike û wê "dadperwerî" dike, heman mîqdara çavkaniyan dide her komê. Lê di rewşa yekem de, ji hewcedariyê zêdetir in (333>150), ji ber vê yekê zêde (333-150=183) di rezervan de dimîne, ku ew jî di navbera du konteynerên din de wekhev tê dabeş kirin:
Di encamê de: konteynera yekem têra xwe jêderk bû, ya duyemîn - têra wê tune bû, ya sêyemîn - têra wê tunebû. Ev encama çalakiyan e Di Linux-ê de plansazkerê "dilpak". - . Karê wê bi karanîna peywirê dikare were sererast kirin giran her yek ji konteynir. Mînakî, bi vî rengî:
Ka em li doza kêmbûna çavkaniyan di konteynera duyemîn de (php-fpm) binihêrin. Hemî çavkaniyên konteynerê di navbera pêvajoyan de wekhev têne belav kirin. Wekî encamek, pêvajoya masterê baş dixebite, lê hemî xebatkar hêdî dibin, ji nîvê tiştê ku ew hewce ne digirin:
Bi vî rengî plansazkerê CFS çawa dixebite. Em ê bêtir gazî giraniyên ku em ji konteyniran re destnîşan dikin daxwazên. Çima ev wisa ye - bêtir bibînin.
Ka em ji aliyê din ve li hemû rewşê binêrin. Wekî ku hûn dizanin, hemî rê berbi Romayê, û di mijara komputerê de, berbi CPU ve diçin. Yek CPU, gelek peywir - hûn hewceyê ronahiya trafîkê ne. Rêya herî hêsan a birêvebirina çavkaniyan "ronahiya trafîkê" ye: wan pêvajoyek demek gihîştina sabît dane CPU, paşê ya din, û hwd.
Ji vê nêzîkatiyê re kotayên dijwar tê gotin (sînorkirina dijwar). Werin em wê bi hêsanî wekî bîr bînin sînorên. Lêbelê, heke hûn sînoran li hemî konteyneran belav bikin, pirsgirêkek derdikeve: mysql li ser rê ajotibû û di deverekê de hewcedariya wê bi CPU bi dawî bû, lê hemî pêvajoyên din neçar in ku li bendê bimînin heya CPU. bêçalak.
Ka em vegerin ser kernel Linux û danûstendina wê bi CPU re - wêneya giştî wiha ye:
cgroup du mîhengan hene - bi bingehîn ev du "tewandin" hêsan in ku dihêle hûn destnîşan bikin:
- giraniya ji bo konteynerê (daxwazan) ye parvekirî;
- rêjeya tevahiya dema CPU ya ji bo xebata li ser peywirên konteynerê (sînor) ye par.
Meriv çawa CPU-yê dipîve?
Rêbazên cûda hene:
- çi parî, kes nizane - hûn hewce ne ku her carê danûstandinan bikin.
- Zem zelaltir, lê têkildar: 50% ji serverek bi 4 core û bi 20 core tiştên bi tevahî cûda ne.
- Hûn dikarin yên ku berê hatine gotin bikar bînin giran, ku Linux dizane, lê ew di heman demê de têkildar in.
- Vebijarka herî guncav pîvandina çavkaniyên hesabkirinê ye seconds. Ewan. di saniyeyên dema pêvajoyê de li gorî saniyeyên dema rast: 1 çirkeya dema pêvajoyê ji 1 çirkeya rastîn re hate dayîn - ev yek tevahiya CPU-yê ye.
Ji bo ku axaftin hê hêsantir be, wan rasterast dest bi pîvandinê kirin kernels, tê wateya ku ji hêla wan ve heman dema CPU-yê bi ya rastîn ve girêdayî ye. Ji ber ku Linux ji giranan fêm dike, lê ne ew qas dem / core CPU, mekanîzmayek hewce bû ku ji yek ji ya din were wergerandin.
Werin em mînakek hêsan bi serverek bi 3 core CPU-yê re bifikirin, ku tê de sê pod giranî têne dayîn (500, 1000 û 1500) ku bi hêsanî vediguhezin beşên têkildar ên korên ku ji wan re hatine veqetandin (0,5, 1 û 1,5).
Ger hûn serverek duyemîn hildin, ku li wir dê du qat zêdetir naverok (6) hebin, û heman pelan li wir bi cîh bikin, belavkirina navokan bi hêsanî bi 2-yê (1, 2 û 3, bi rêzê ve) zêdekirina bi hêsanî dikare were hesibandin. Lê demek girîng diqewime dema ku podek çaremîn li ser vê serverê xuya dibe, ku giraniya wê, ji bo rehetiyê, dê 3000 be. Ew beşek ji çavkaniyên CPU (nîvê naverokan) digire, û ji bo podên mayî ew ji nû ve têne hesibandin (nîv kirin):
Çavkaniyên Kubernetes û CPU
Li Kubernetes, çavkaniyên CPU bi gelemperî têne pîvandin milliadrax, yanî 0,001 core wek giraniya bingehîn têne girtin. (Heman tişt di termînolojiya Linux/cgroupan de parvekirina CPU-yê tê gotin, her çend, bi rastî, 1000 mîlîkor = 1024 parvekirinên CPU.) K8s piştrast dike ku ew ji çavkaniyên CPU-yê yên ji bo kombûna giraniya hemî podan bêtir pod li ser serverê cîh nagire.
Ev çawa dibe? Dema ku hûn serverek li komek Kubernetes zêde dikin, tê ragihandin ku çend navokên CPU-yê wê hene. Û dema ku podek nû diafirîne, plansazkerê Kubernetes dizane ku ev pod dê çend core hewce bike. Bi vî rengî, pod dê ji serverek ku têra xwe têr hene were veqetandin.
Ger dê çi bibe ne daxwaz hatîye diyar kirin (ango pod hejmareke diyarkirî ya core hewce nake)? Ka em fêr bibin ka Kubernetes bi gelemperî çavkaniyan çawa dihejmêre.
Ji bo podek hûn dikarin hem daxwazan (plansazkerê CFS) û hem jî sînoran diyar bikin (ronahiya trafîkê bi bîr tînin?):
- Ger ew wekhev têne destnîşan kirin, wê hingê pod çînek QoS tê destnîşankirin garantîkirin. Ev hejmara core ku her gav jê re peyda dibe garantî ye.
- Ger daxwaz ji sînor kêmtir e - çîna QoS teqandin. Ewan. Em li bendê ne ku pod, mînakî, her gav 1 bingehîn bikar bîne, lê ev nirx ji bo wê ne sînorek e: carinan pod dikare bêtir bikar bîne (gava ku server ji bo vê çavkaniyên belaş hene).
- Çînek QoS jî heye hewla çêtirîn - di nav wan de pir potan de ye ku daxwaz ji wan re nehatiye diyar kirin. Çavkaniyên dawî ji wan re têne dayîn.
bîra
Bi bîranînê re, rewş dişibihe, lê hinekî cûda ye - her tiştî, cewhera van çavkaniyan cûda ye. Bi gelemperî, analojiyek wiha ye:
Ka em bibînin ka daxwaz di bîranînê de çawa têne bicîh kirin. Bila pod li ser serverê bijîn, vexwarina bîranînê biguhezînin, heya ku yek ji wan ew qas mezin bibe ku ji bîrê xilas bibe. Di vê rewşê de, kujerê OOM xuya dike û pêvajoya herî mezin dikuje:
Ev her gav ne li gorî me ye, ji ber vê yekê gengaz e ku em birêkûpêk bikin ka kîjan pêvajoyê ji me re girîng in û neyên kuştin. Ji bo vê yekê, pîvanê bikar bînin oom_score_adj.
Ka em vegerin ser çînên QoS yên CPU-yê û bi nirxên oom_score_adj re ku pêşanînên mezaxtina bîranînê ji bo podan diyar dikin re analogiyek derxînin:
- Nirxa oom_score_adj ya herî nizm ji bo pod - -998 - tê vê wateyê ku podek weha divê herî dawî were kuştin, ev garantîkirin.
- Herî zêde - 1000 - e hewla çêtirîn, pêlên weha pêşî têne kuştin.
- Ji bo hejmartina nirxên mayî (teqandin) formulek heye, ku cewhera wê bi vê yekê ve girêdayî ye ku her çend çavkaniyan bêtir daxwaz kiriye, ew qas kêm dibe ku were kuştin.
"Tewist" ya duyemîn - limit_in_bytes - ji bo sînoran. Bi wê re, her tişt sadetir e: em bi tenê mîqdara herî zêde ya bîranînê vediqetînin, û li vir (bervajî CPU) pirsek tune ku meriv wê çawa bipîve (bîr).
Tevahî
Her pod li Kubernetes tê dayîn requests и limits - her du parameterên ji bo CPU û bîra:
- li ser bingeha daxwazan, plansazkerê Kubernetes dixebite, ku pod di nav serveran de belav dike;
- li ser bingeha hemî pîvanan, çîna QoS ya pod tê destnîşankirin;
- Giraniyên têkildar li ser bingeha daxwazên CPU têne hesibandin;
- plansazkerê CFS-ê li ser bingeha daxwazên CPU-yê hatî mîheng kirin;
- Kujerê OOM li ser bingeha daxwazên bîranînê tête mîheng kirin;
- "ronahiya trafîkê" li ser bingeha sînorên CPU-ê tête saz kirin;
- Li ser bingeha sînorên bîranînê, ji bo cgroup sînorek tête saz kirin.
Bi gelemperî, ev wêne bersiva hemî pirsan dide ka ka çawa beşa sereke ya rêveberiya çavkaniyê li Kubernetes pêk tê.
Autoscaling
K8s cluster-autoscaler
Ka em bifikirin ku tevahiya komê jixwe dagîrkirî ye û pêdivî ye ku podek nû were afirandin. Dema ku pod nekare xuya bibe, ew di statûyê de dimîne Nexelas. Ji bo ku ew xuya bibe, em dikarin serverek nû bi komê ve girêbidin an jî ... cluster-autoscaler saz bikin, ku dê ji me re bike: makîneyek virtual ji pêşkêşkarê ewr re ferman bike (daxwazek API bikar tîne) û wê bi komê ve girêbide. , piştî wê pod dê were zêdekirin.
Ev bixweberkirina koma Kubernetes e, ku pir baş dixebite (di ezmûna me de). Lêbelê, wekî cîhek din, li vir jî hin nuwaze hene ...
Heya ku me mezinahiya komê zêde kir, her tişt baş bû, lê dema ku kom bibe çi diqewime dest bi azadkirina xwe kir? Pirsgirêk ev e ku koçkirina pods (ji bo azadkirina mêvandaran) di warê çavkaniyan de ji hêla teknîkî ve pir dijwar û biha ye. Kubernetes nêzîkatiyek bi tevahî cûda bikar tîne.
Komek ji 3 pêşkêşkerên ku xwedan Deployment e bifikirin. Ew 6 pod hene: naha ji bo her serverek 2 hene. Ji ber hin sedeman me xwest ku yek ji serveran vekin. Ji bo vê yekê em ê fermanê bikar bînin kubectl drain, ku:
- dê şandina podên nû ji vê serverê re qedexe bike;
- dê podên heyî yên li ser serverê jê bibe.
Ji ber ku Kubernetes berpirsiyar e ji bo domandina hejmara pods (6), ew bi hêsanî dê ji nû ve biafirîne ew li ser girêkên din, lê ne li ser girêkek ku neçalak e, ji ber ku ew jixwe wekî neberdest ji bo mêvandariya polên nû tê nîşankirin. Ev ji bo Kubernetes mekanîka bingehîn e.
Lêbelê, li vir jî nuansek heye. Di rewşek wusa de, ji bo StatefulSet (li şûna Deployment), dê çalakî cûda bin. Naha me jixwe serîlêdanek dewletparêz heye - mînakî, sê podên bi MongoDB re, ku yek ji wan cûreyek pirsgirêk heye (dane xera bûye an xeletiyek din a ku rê nade ku pod rast dest pê bike). Û em dîsa biryar didin ku yek serverê neçalak bikin. Wê çi bibe?
MongoDB dikaribû bimire ji ber ku jê re quorumek hewce dike: ji bo komek ji sê saziyan, divê herî kêm du kar bikin. Lêbelê, ev pêk nayê - spas PodDisruptionBudget. Ev parametre hejmara herî hindik a pêdivî ya pêlên xebatê diyar dike. Dizanin ku yek ji podên MongoDB êdî naxebite, û dîtina ku PodDisruptionBudget ji bo MongoDB hatî danîn minAvailable: 2, Kubernetes dê nehêle ku hûn pod jêbirin.
Rêza jêrîn: ji bo ku tevger (û bi rastî, ji nû ve afirandin) dema ku kom tê berdan rast bixebite, pêdivî ye ku PodDisruptionBudget were mîheng kirin.
Pîvana Horizontal
Ka em rewşek din bifikirin. Serlêdanek wekî Deployment li Kubernetes tê xebitandin heye. Trafîka bikarhêner tê ser pêlên xwe (mînak, sê ji wan hene), û em di wan de nîşanek diyar dipîvin (dibêjin, barkirina CPU). Dema ku bar zêde dibe, em wê li ser bernameyek tomar dikin û ji bo belavkirina daxwazan hejmara podan zêde dikin.
Îro di Kubernetes de ev ne hewce ye ku bi destan were kirin: zêdebûn / kêmbûnek otomatîkî ya hejmara podan li gorî nirxên nîşaneyên barkirinê yên pîvandî têne mîheng kirin.
Pirsên sereke li vir in: tam çi bipîve и çawa şîrove bike nirxên wergirtî (ji bo girtina biryarek li ser guheztina hejmara potan). Hûn dikarin pir bipîvin:
Meriv çawa bi teknîkî vê yekê dike - berhevkirina metrîkan, hwd. - Min di raporê de bi berfirehî behsa wê kir . Û şîreta sereke ji bo hilbijartina pîvanên çêtirîn e ceribandinî!
Ð • n, Nûh * de (Têrbûn û Çewtiyên Bikaranînê), wateya ku li jêr e. Li ser çi bingehê wateya pîvandinê ye, mînakî, php-fpm? Li ser bingeha ku karker diqedin, ev e bikar anîn. Û eger karker bi dawî bibin û têkiliyên nû neyên pejirandin, ev jixwe ye saturation. Pêdivî ye ku ev her du pîvan werin pîvandin, û li gorî nirxan divê pîvandin were kirin.
Şûna encamê
Di raporê de berdewamiyek heye: di derbarê pîvana vertîkal de û meriv çawa çavkaniyên rast hilbijêrin. Ez ê di vîdyoyên pêşerojê de li ser vê biaxivim - bibin abone da ku hûn ji bîr nekin!
Vîdyo û slaytên
Vîdyo ji performansê (44 hûrdem):
Pêşkêşkirina raporê:
PS
Raporên din ên di derbarê Kubernetes de li ser bloga me:
- «» (Andrey Polovov; 8ê Avrêl, 2019 li Saint HighLoad ++);
- «» (Dmitry Stolyarov; 8 Mijdar 2018 li ser HighLoad ++);
- «» (Dmitry Stolyarov; 28 Gulan 2018 li RootConf);
- «» (Dmitry Stolyarov; 7 Mijdar 2017 li ser HighLoad ++);
- «» (Dmitry Stolyarov; 6 Hezîran, 2017 li RootConf).
Source: www.habr.com