Not. werger.: Ev dîroka çavan a Omio - berhevkarek rêwîtiyê ya Ewropî - xwendevanan ji teoriya bingehîn digire heya tevliheviyên pratîkî yên balkêş ên veavakirina Kubernetes. Nasbûna bi dozên weha re dibe alîkar ku ne tenê asoyên we berfireh bikin, lê di heman demê de pêşî li pirsgirêkên ne-tiştan digire.
Ma tu carî serîlêdanek li cîhê we asê maye, dev ji bersivdana kontrolên tenduristiyê berde, û nikaribin fêm bikin çima? Yek ravekirinek gengaz bi sînorên kotaya çavkaniya CPU ve girêdayî ye. Ya ku em ê di vê gotarê de li ser biaxivin ev e.
TL; DR:
Em bi tundî pêşniyar dikin ku hûn sînorên CPU-yê li Kubernetes neçalak bikin (an jî kotayên CFS-ê li Kubelet neçalak bikin) heke hûn guhertoyek kernel Linux-ê bi xeletiyek kotaya CFS bikar tînin. Di bingehê de giran û xeletiyek ku rê li ber birîn û derengmayîna zêde vedike.
Li Omio tevahiya binesaziyê ji hêla Kubernetes ve tê rêve kirin. Hemî bargiraniyên me yên dewletparêz û bêdewlet bi taybetî li ser Kubernetes têne xebitandin (em Google Kubernetes Engine bikar tînin). Di şeş mehên dawîn de, me dest bi çavdêriya hêdîbûnên rasthatî kir. Serlêdan dicemidînin an bersivê didin kontrolên tenduristiyê, girêdana bi torê re winda dikin, hwd. Vê tevgerê ji bo demek dirêj me şaş kir, û di dawiyê de me biryar da ku pirsgirêkê ciddî bigirin.
Kurteya gotarê:
- Çend gotin li ser konteynir û Kubernetes;
- Daxwaz û sînorên CPU çawa têne bicîh kirin;
- Çawa sînorê CPU di hawîrdorên pir-core de dixebite;
- Meriv çawa şilkirina CPU-yê bişopîne;
- Çareseriya pirsgirêk û nuansan.
Çend gotin li ser konteynir û Kubernetes
Kubernetes di cîhana binesaziyê de bi bingehîn standarda nûjen e. Karê wê yê sereke orkestrasyona konteyneran e.
Konser
Di paşerojê de, me neçar ma ku hunerên mîna Java JAR / WAR, Python Eggs, an îcrakar biafirînin da ku li ser serveran bixebitin. Lêbelê, ji bo ku ew kar bikin, pêdivî bû ku xebatek zêde were kirin: sazkirina hawîrdora xebitandinê (Java / Python), pelên pêwîst li cîhên rast bicîh bikin, bihevhatina bi guhertoyek taybetî ya pergala xebitandinê re, hwd. Bi gotinek din, pêdivî bû ku baldariyek bi baldarî li ser rêveberiya mîhengê were dayîn (ku bi gelemperî di navbera pêşdebiran û rêveberên pergalê de çavkaniya nakokiyê bû).
Konteyniran her tişt guhert. Naha huner wêneyek konteynerek e. Ew dikare wekî celebek pelek darvekirî ya dirêjkirî were destnîşan kirin ku ne tenê bernameyê, lê di heman demê de jîngehek darvekirinê ya tam (Java/Python/...), û her weha pelên/pakêtên pêwîst, ji pêş-sazkirî û amade ne tê destnîşan kirin. rev. Konteyner bêyî gavên zêde dikarin li ser serverên cihêreng werin bicîh kirin û bimeşînin.
Wekî din, konteynir di hawîrdora xweya sandboxê de dixebitin. Ew xwedan adapterê torê ya virtual, pergala pelan a xwe ya bi gihîştina tixûbdar, hiyerarşiya pêvajoyên xwe, sînorên xwe yên li ser CPU û bîranînê, hwd. Ev hemî bi saya binepergalek taybetî ya kernel Linux - cîhên navan têne bicîh kirin.
Kubernetes
Wekî ku berê hate gotin, Kubernetes orkestratorek konteyneran e. Ew bi vî rengî dixebite: hûn jê re komek makîneyan didin, û dûv re dibêjin: "Hey, Kubernetes, em deh nimûneyên konteynera xwe bi 2 pêvajo û 3 GB bîra her yekê bidin destpêkirin û wan bimeşînin!" Kubernetes dê lênêrîna yên mayî bigire. Ew ê kapasîteya belaş bibîne, konteyneran bide destpêkirin û ger hewce bike wan ji nû ve bide destpêkirin, dema ku guhertoyan diguhezîne nûvekirinek derxîne, hwd. Di bingeh de, Kubernetes destûrê dide we ku hûn hêmana hardware ji holê rakin û cûrbecûr pergalên ji bo danîn û xebitandina sepanan guncan çêdike.
Kubernetes ji nêrîna laîk
Di Kubernetes de daxwaz û sînor çi ne
Baş e, me konteynir û Kubernetes vegirtiye. Em her weha dizanin ku pir konteynir dikarin li ser heman makîneyê rûnin.
Analojiyek dikare bi apartmanek komunal re were kişandin. Cihek fireh (makîne/yekîneyên) tê girtin û ji çend kirêdaran (konteyner) re tê kirêkirin. Kubernetes wekî realtor tevdigere. Pirs derdikeve holê, ka meriv çawa kirêdaran ji nakokiyên bi hev re biparêze? Ger yek ji wan, bêje, biryar bide ku nîvê rojê serşokê deyn bike?
Li vir daxwaz û sînor dikevin dewrê. CPU Tika tenê ji bo armancên plansaziyê hewce ne. Ev tiştek mîna "lîsteya xwestekan" ya konteynerê ye, û ji bo hilbijartina girêka herî maqûl tê bikar anîn. Di heman demê de CPU Sînorkirin dikare bi peymanek kirê re were berhev kirin - gava ku em yekîneyek ji bo konteynerê hilbijêrin, ya nikarin ji sînorên destnîşankirî derbas bibin. Û di vir de pirsgirêk derdikeve…
Di Kubernetes de daxwaz û sînor çawa têne bicîh kirin
Kubernetes ji bo bicihanîna sînorên CPU-yê mekanîzmayek rijandinê (derbazkirina çerxên demjimêrê) ku di kernelê de hatî çêkirin bikar tîne. Ger serîlêdanek ji sînor derbas bibe, rijandin tê çalak kirin (ango ew kêmtir çerxên CPU werdigire). Daxwaz û sînorên bîranînê bi rengek cûda têne organîze kirin, ji ber vê yekê ew hêsantir têne dîtin. Ji bo vê yekê, tenê statûya nûvekirina paşîn a podê kontrol bikin: gelo ew "OOMKilled" e. Teqandina CPU ne ew çend hêsan e, ji ber ku K8s tenê ji hêla karanîna metrîkan ve peyda dike, ne ji hêla cgroupan.
Daxwaza CPU
Daxwaza CPU çawa tête bicîh kirin
Ji bo sadebûnê, em li pêvajoyê binêrin ku wekî mînakek makîneyek bi CPU-ya 4-core bikar tîne.
K8s mekanîzmayek koma kontrolê (cgroups) bikar tîne da ku dabeşkirina çavkaniyan (bîr û pêvajoker) kontrol bike. Ji bo wê modelek hiyerarşîk heye: zarok sînorên koma dêûbav mîras digire. Agahiyên belavkirinê di pergala pelê ya virtual de têne hilanîn (/sys/fs/cgroup). Di mijara pêvajoyê de ev e /sys/fs/cgroup/cpu,cpuacct/*.
K8s pelê bikar tîne cpu.share ji bo veqetandina çavkaniyên processor. Di rewşa me de, cgroup root 4096 parên çavkaniyên CPU-yê digire - 100% ji hêza pêvajoya berdest (1 bingehîn = 1024; ev nirxek sabît e). Koma root çavkaniyan bi nîsbet li gorî parvekirina neviyên ku tê de hatine tomar kirin belav dike cpu.share, û ew, di heman demê de bi neviyên xwe re, hwd. Li ser girêkek tîpîk Kubernetes, koma c root sê zarok hene: system.slice, user.slice и kubepods. Du binkomên pêşîn ji bo belavkirina çavkaniyan di navbera barkirinên pergalê yên krîtîk û bernameyên bikarhêner ên derveyî K8 de têne bikar anîn. Ya dawî - kubepods - ji hêla Kubernetes ve hatî afirandin da ku çavkaniyan di navbera pods de belav bike.
Diagrama li jor nîşan dide ku jêrkomên yekem û duyemîn her yek wergirtine 1024 hîseyên, bi binkoma kuberpod veqetandin 4096 parve dike Ev çawa gengaz e: Beriya her tiştî, grûpa root tenê bigihîje 4096 hîseyên wê, û tevheviya hîseyên neviyên wê bi awayekî berbiçav ji vê hejmarê (6144)? Mesele ev e ku nirx wateya mentiqî dide, ji ber vê yekê nexşerêya Linux (CFS) wê bikar tîne da ku bi rêjeyî çavkaniyên CPU veqetîne. Di rewşa me de, du komên pêşîn distînin 680 hîseyên rastîn (16,6% ji 4096), û kubepod mayî distîne 2736 parve dike Di rewşek dakêşanê de, du komên yekem dê çavkaniyên veqetandî bikar neynin.
Xweşbextane, plansazkar mekanîzmayek heye ku ji windakirina çavkaniyên CPU-ya neyên bikar anîn dûr bixe. Ew kapasîteya "bêkar" vediguhezîne hewzek gerdûnî, ku jê ew li komên ku hewcedariya wan bi hêza pêvajoyek zêde heye tê belav kirin (veguheztin bi koman pêk tê da ku ji windahiyên dorpêçkirinê dûr nekevin). Rêbazek bi vî rengî ji bo hemî neviyên dûvdanan tê sepandin.
Ev mekanîzma dabeşkirina adil a hêza pêvajoyê peyda dike û piştrast dike ku kes pêvajo çavkaniyên ji yên din "dizîne".
Sînorê CPU
Tevî vê rastiyê ku mîhengên sînor û daxwazan di K8-an de mîna hev xuya dikin, pêkanîna wan bi tundî cûda ye: ev herî xapandin û beşa herî kêm belgekirî.
K8s tevdigere ji bo pêkanîna sînorên. Mîhengên wan di pelan de têne diyar kirin cfs_period_us и cfs_quota_us di pelrêça cgroup de (pel jî li wir e cpu.share).
Berevajî cpu.share, kota li ser bingeha dema dema, û ne li ser hêza pêvajoyê ya berdest. cfs_period_us dirêjahiya heyamê (serdemê) diyar dike - ew her gav 100000 μs (100 ms) ye. Vebijarkek heye ku meriv vê nirxê di K8s de biguhezîne, lê ew heya niha tenê di alpha de heye. Plansaz serdemê bikar tîne da ku kotayên bikar anîn ji nû ve bide destpêkirin. Dosya duyemîn cfs_quota_us, di her serdemê de dema berdest (kota) diyar dike. Bala xwe bidinê ku ew di mîkroçirkeyan de jî tête diyar kirin. Dibe ku kota ji dirêjahiya serdemê derbas bibe; bi gotineke din, dibe ku ji 100 ms mezintir be.
Ka em li du senaryoyên li ser makîneyên 16-binêrin (cûreya herî gelemperî ya komputera ku em li Omio heye):
Senaryo 1: 2 mijar û sînorek 200 ms. No throttling
Senaryo 2: 10 mijar û sînorê 200 ms. Têkçûn piştî 20 ms dest pê dike, gihîştina çavkaniyên pêvajoyê piştî 80 ms ya din ji nû ve dest pê dike.
Ka em bibêjin we sînorê CPU-yê destnîşan kir 2 kernels; Kubernetes dê vê nirxê wergerîne 200 ms. Ev tê vê wateyê ku konteynir dikare herî zêde 200 ms dema CPU-yê bêyî kêşan bikar bîne.
Û ev e ku kêfê dest pê dike. Wekî ku li jor behs kir, kotaya berdest 200 ms e. Heke hûn di paralel de dixebitin deh xêzên li ser makîneyek 12-core (li nîgarê ji bo senaryo 2 binêre), dema ku hemî podên din bêkar in, dê kota tenê di 20 ms de biqede (ji 10 * 20 ms = 200 ms), û hemî têlên vê podê dê biqedin. » (pîdala gazê) ji bo 80 ms. Ya ku berê behs kiribû , ji ber vê yekê xitimandinek zêde çêdibe û konteynir jî nikare kotaya heyî pêk bîne.
Meriv çawa di nav potan de şûştinê dinirxîne?
Tenê têkevin binavê û bicîh bikin cat /sys/fs/cgroup/cpu/cpu.stat.
-
nr_periods- hejmara giştî ya demên plansazker; -
nr_throttled- Hejmara serdemên rijandin di pêkhateyê denr_periods; -
throttled_time- dema rijandina berhevkirî di nanosecondê de.
Bi rastî çi diqewime?
Wekî encamek, em di hemî serîlêdanan de germbûna bilind digirin. Carinan ew tê de ye car û nîv ji hesaban bihêztir!
Ev dibe sedema xeletiyên cihêreng - têkçûnên kontrolkirina amadebûnê, cemidandina konteyneran, qutbûna pêwendiya torê, demên di nav bangên karûbarê de. Ev di dawiyê de dibe sedema zêdebûna derengbûnê û rêjeyên xeletiyên bilind.
Biryar û encamên
Li vir her tişt hêsan e. Me dev ji sînorên CPU-yê berda û dest bi nûvekirina kernel OS-ê ya di koman de heya guhertoya herî dawî, ya ku tê de xeletî hate rast kirin, kir. Hejmara xeletiyan (HTTP 5xx) di karûbarên me de tavilê pir kêm bû:
Çewtiyên HTTP 5xx
Çewtiyên HTTP 5xx ji bo karûbarek krîtîk
Dema bersivê p95
Derengiya daxwaza karûbarê krîtîk, sedî 95
Mesrefên xebitandinê
Hejmara demjimêrên nimûne
Theiqas digirt?
Wekî ku di destpêka gotarê de hate gotin:
Analojiyek dikare bi apartmanek komînal re were xêz kirin... Kubernetes wekî maldar tevdigere. Lê meriv çawa kirêdaran ji nakokiyên bi hevûdu re biparêze? Ger yek ji wan, bêje, biryar bide ku nîvê rojê serşokê deyn bike?
Li vir girtina. Yek konteynirek bêhiş dikare hemî çavkaniyên CPU yên heyî yên li ser makîneyek bixwe. Ger stûnek serîlêdana weya jîr heye (mînak, JVM, Go, Node VM bi rêkûpêk hatine mîheng kirin), wê hingê ev ne pirsgirêk e: hûn dikarin demek dirêj di şert û mercên weha de bixebitin. Lê heke serîlêdan kêm xweşbîn in an jî qet xweşbîn nebin (FROM java:latest), dibe ku rewş ji kontrolê derkeve. Li Omio me Dockerfilesên bingehîn ên otomatîkî hene ku bi mîhengên xwerû yên têr ji bo stûna zimanê sereke hene, ji ber vê yekê ev pirsgirêk tune bû.
Em pêşniyar dikin ku çavdêriya metrîkan bikin (bikaranîn, têrbûn û xeletî), derengiyên API û rêjeyên xeletiyê. Piştrast bikin ku encam hêviyên xwe li hev dikin.
references
Ev çîroka me ye. Materyalên jêrîn pir alîkariya fêmkirina çi diqewime kir:
- ;
- ;
- ;
- ;
- - li "cpu throttling" bigerin.
Raporên xeletiya Kubernetes:
- ;
- ;
- .
Ma we di pratîka xwe de bi pirsgirêkên bi heman rengî re rû bi rû maye an jî ezmûna we ya têkildar bi avêtina li hawîrdorên hilberîna konteyneran re heye? Di şîroveyan de çîroka xwe parve bikin!
PS ji wergêr
Li ser bloga me jî bixwînin:
- «»;
- «»;
- «".
Source: www.habr.com