Dema ku komek Kubernetes diafirîne, dibe ku pirs derkevin holê: çend girêkên karker werin mîheng kirin û çi celeb? Ji bo komikek serhêl çi çêtir e: çend serverên hêzdar bikirin an di navenda daneya xwe de bi dehan makîneyên kevn bikar bînin? Ma çêtir e ku meriv heşt nimûneyên yek-core an du çar-core di ewr de bavêje?
Bersivên van pirsan di gotarê de ne. di wergera fermanê de .
Kapasîteya Cluster
Bi gelemperî, komek Kubernetes dikare wekî "supernode"ek mezin were hesibandin. Tevahiya hêza wê ya hesabker kombûna hêzên hemî girêkên wê yên pêkhatî ye.
Gelek rê hene ku hûn bigihîjin armanca kapasîteya koma xweya xwestinê. Mînakî, ji me re komek bi kapasîteya tevahî 8 core pêvajoyê û 32 GB RAM hewce ye ji ber ku komek serîlêdan gelek çavkaniyan hewce dike. Dûv re hûn dikarin du girêkên bi bîranîna 16 GB an çar girêkên bi bîranîna 8 GB, du pêvajoyên çar-core an çar yên du-core saz bikin.
Li vir tenê du awayên mimkun hene ku meriv komek çêbike:
Her du vebijark komek bi heman kapasîteyê hildiberînin, lê veavakirina jêrîn çar girêkên piçûktir û veavakirina jorîn du girêkên mezin hene.
Kîjan vebijark çêtir e?
Ji bo bersiva vê pirsê, em li avantajên her du vebijarkan binêrin. Me ew di tabloyekê de bi kurtî berhev kirine.
Çend girêkên mezin
Gelek girêkên piçûk
Rêvebiriya komê hêsantir (heke ew li ser bingehê be)
Xweseriya nermî
Erzantir (eger li ser cîhê ye)
Biha hindik cûda ye (di ewr de)
Dikare serîlêdanên çavkanî-dijwar bimeşîne
Replication Full
Çavkaniyên bi bandortir têne bikar anîn (kêm zêde li ser şeytanên pergalê
Tolerasyona xeletiya komê ya bilind
Ji kerema xwe not bikin ku em tenê li ser girêkên karkeran dipeyivin. Hilbijartina hejmar û mezinahiya girêkên sereke mijarek bi tevahî cûda ye.
Ji ber vê yekê, werin em her xalek ji tabloyê bi hûrgulî nîqaş bikin.
Vebijarka yekem: çend girêkên mezin
Vebijarka herî zêde ji bo tevahiya kapasîteya komê yek girêk karker e. Di mînaka li jor de, ev ê girêkek karkerek yekane bi 16 core CPU û 16 GB RAM be.
Плюсы
Plus No.. 1. Rêveberiya hêsantir
Birêvebirina çend makîneyan ji fîloya tevahî hêsantir e. Zûtir e ku nûvekirin û rastkirin were derxistin, û senkronîzekirin hêsantir e. Hejmara têkçûnan di hejmarên teqez de jî kêmtir e.
Ji kerema xwe not bikin ku hemî jorîn li ser hardware, serverên we, û ne ji bo bûyerên ewr re derbas dibe.
Di ewr de rewş cuda ye. Li wir, rêveberî ji hêla pêşkêşvanê karûbarê cloudê ve tê rêve kirin. Bi vî rengî, birêvebirina deh girêkên di ewr de ji birêvebirina yek girêk pir cûda nabe.
Rêvekirina trafîkê û belavkirina barkirinê di navbera podên di ewr de : seyrûsefera ku ji Înternetê tê ji balansa barkirinê ya sereke re tê şandin, ku seyrûseferê ber bi bendera yek ji girêkan ve dişîne (karûbarê NodePort di her girêka komê de portê di navbera 30000-32767 de destnîşan dike). Qaîdeyên ku ji hêla kube-proxy ve hatî destnîşan kirin seyrûsefera ji nodê berbi podê verast dike. Va ye ku ew ji bo deh podên li ser du girêkan çawa xuya dike:
Pro #2: Mesrefa kêmtir ji bo nod
Otomobîlek hêzdar bihatir e, lê zêdebûna bihayê ne hewce ne rêzik e. Bi gotinek din, serverek deh-core bi bîranîna 10 GB bi gelemperî ji deh serverên yek-core yên bi heman mîqdara bîranînê erzantir e.
Lê bîr bînin ku ev qaîdeyek bi gelemperî di karûbarên cloudê de naxebite. Di nexşeyên nirxê heyî yên hemî pêşkêşkerên sereke yên ewr de, biha bi kapasîteyê re bi rêkûpêk zêde dibin.
Bi vî rengî, di ewr de hûn bi gelemperî nekarin li ser serverên bihêztir hilînin.
Pro #3: Hûn dikarin serîlêdanên çavkaniyê-dijwar bimeşînin
Hin serîlêdan di komekê de serverek hêzdar hewce dike. Mînakî, heke pergala fêrbûna makîneyê 8 GB bîranîn hewce bike, hûn ê nikaribin wê li ser girêkên 1 GB bimeşînin, lê tenê bi kêmanî yek girêkek mezin a karker.
Минусы
Dezavantaj No.. 1. Gelek pods per node
Ger heman peywir li ser hindiktir girêkan were kirin, wê hingê her yek ji wan bi xwezayî dê xwedan pêvek zêdetir be.
Ev dikare bibe pirsgirêk.
Sedem ev e ku her modul hin serekî bi dema xebitandina konteynerê (mînak Docker), û her weha kubelet û cAdvisor vedigire.
Mînakî, kubelet bi rêkûpêk hemî konteynerên li ser girêkekê ji bo saxbûnê dikole - ku bêtir konteynir, ew qas bêtir kar divê kubelet bike.
CAdvisor statîstîkên karanîna çavkaniyê ji bo hemî konteynerên li ser girêkekê berhev dike, û kubelet bi rêkûpêk li vê agahiyê dipirse û bi navgîniya API-yê peyda dike. Dîsa, bêtir konteyneran hem ji bo cAdvisor û hem jî ji bo kubelet bêtir kar tê wateya.
Ger hejmara modulan zêde bibe, ew dikare pergalê hêdî bike û tewra pêbaweriya wê jî xera bike.
Di depoya Kubernetes de hin ku girêk dikevin navbera statûyên Amade/NeReady ji ber ku kontrolên birêkûpêk ên kubelet ên hemî konteynerên li ser girêkek pir dirêj digire.
Ji ber vê yekê Kubernetes . Bi performansa girêkê ve girêdayî, hûn dikarin ji her girêkek bêtir pods bimeşînin, lê dijwar e ku meriv pêşbîn bike ka dê pirsgirêk hebin an dê her tişt baş bixebite. Hêjayî ceribandina xebatê ye di pêş de.
Kêmasiya Hejmar 2. Sînorkirina li ser dubarekirinê
Pir hindik girêk rêjeya bi bandor a dubarekirina serîlêdanê sînordar dike. Mînakî, heke we serîlêdanek berdestbûna zêde ya bi pênc kopiyan lê bi tenê du girêk heye, wê hingê asta bandorker a dubarekirina serîlêdanê daket duduyan.
Pênc replica tenê dikarin li ser du girêkan bêne belav kirin, û heke yek ji wan têk biçe, ew ê di yekcarê de gelek kopiyan hilîne.
Ger pênc girêkên we an jî zêdetir hebin, her kopiyek dê li ser girêkek cûda bixebite, û têkçûna yek girêk dê herî zêde kopiyek jê rake.
Ji ber vê yekê, hewcedariyên hebûna bilind dibe ku di komê de hejmarek hindiktirîn girêk hewce bike.
Kêmasiya Hejmar 3. Encamên xirabtir ên têkçûnê
Bi hejmareke piçûk a girêkan, her têkçûn encamên cidîtir hene. Mînakî, heke tenê du girêkên we hebin û yek ji wan têk biçe, nîvê modulên we tavilê winda dibin.
Bê guman, Kubernetes dê bargiraniya xebatê ji girêka têkçûyî koçî yên din bike. Lê heke hindik ji wan hebin, wê hingê dibe ku kapasîteya belaş têr nebe. Wekî encamek, hin serîlêdanên we dê ne berdest bin heya ku hûn girêka têkçûyî dernexin.
Ji ber vê yekê, bêtir girêk, bandora têkçûna hardware kêmtir dibe.
Kêmasî # 4: Zêdetir gavên xweserî
Kubernetes ji bo binesaziya ewr xwedan pergalek xweberhevkirina komê ye, ku dihêle hûn bixweber li gorî hewcedariyên xweyên heyî girêkan lê zêde bikin an jê derxînin. Bi girêkên mezintir re, otoscaling ji nişka ve û qelstir dibe. Mînakî, li ser du nokan, lê zêdekirina girêkek din dê tavilê kapasîteya komê 50% zêde bike. Û hûn ê ji bo wan çavkaniyan bidin, tevî ku hûn ne hewce ne.
Bi vî rengî, heke hûn plan dikin ku pîvana komê ya otomatîkî bikar bînin, her ku girêk piçûktir bibin, hûn ê pîvanek maqûltir û bihatir bistînin.
Naha em li awantaj û dezawantajên hejmareke mezin ji girêkên piçûk binêrin.
Vebijarka duyemîn: gelek girêkên piçûk
Awantajên vê nêzîkatiyê bi bingehîn ji dezawantajên vebijarka berevajî bi gelek girêkên mezin re derdikevin.
Плюсы
Pro #1: Kêmtir bandora têkçûnê
Çiqas girêk zêdetir bin, li ser her girêkek kêmtir girêk. Mînakî, heke di her deh girêkan de sed modulên we hebin, wê hingê her girêk dê bi navînî deh modulan hebe.
Bi vî rengî, heke yek ji girêkan têk biçe, hûn tenê 10% ji barê xebatê winda dikin. Derfetên wê hene ku tenê hejmarek piçûk ji kopiyan bandor bibin û serîlêdana giştî dê karbidest bimîne.
Wekî din, girêkên mayî dê belkî xwedan çavkaniyên belaş ên têra xwe bin da ku karûbarê girêka têkçûyî bi rê ve bibin, ji ber vê yekê Kubernetes dikare bi serbestî pezê ji nû ve saz bike û serîlêdanên we dê bi rengek zû vegere rewşek fonksiyonel.
Pro #2: Repplication baş
Ger girêk têr hebin, plansazkerê Kubernetes dikare girêkên cihêreng ji hemî kopiyan re destnîşan bike. Bi vî rengî, heke girêk têk biçe, dê tenê yek kopiyek bandor bibe û serîlêdan dê berdest bimîne.
Минусы
Kêmasiya No.. 1. Zehmet e ku kontrol bikin
Rêvebirina hejmarên mezin ên girêk dijwartir e. Mînakî, divê her girêk Kubernetes bi hemî yên din re têkilî daynin, ango, hejmara pêwendiyan bi çarçoveyek mezin dibe, û pêdivî ye ku ev hemî girêdan werin şopandin.
Kontrolkerê girêkê di Gerînendeyê Kontrolkerê Kubernetes de bi rêkûpêk di nav hemî girêkên komê de dimeşe da ku tenduristiyê kontrol bike - çiqas bêtir girêk, ew qas barkirina li ser kontrolker zêde dibe.
Barkirina li ser databasa etcd jî zêde dibe - her kubelet û kube-proxy bang dike ji bo etcd (bi rêya API-ê), ya ku etcd divê nûvekirinên tiştan biweşîne.
Bi gelemperî, her girêk karker barek zêde li ser pêkhateyên pergalê yên girêkên sereke ferz dike.
Kubernetes bi fermî koman piştgirî dike . Lêbelê, di pratîkê de jixwe 500 nod hene .
Ji bo birêvebirina hejmareke mezin ji girêkên karker, divê hûn girêkên sereke yên bihêztir hilbijêrin. Mînakî, kube-up mezinahiya VM-ya rast ji bo girêka masterê li gorî hejmara girêkên karker ve girêdayî ye. Ango girêkên karker çiqasî zêde bin, divê girêkên master jî ewqas berhemdar bin.
Ji bo çareserkirina van pirsgirêkên taybetî pêşveçûnên taybetî hene, wekî . Ev pergal destûrê dide we ku hûn qedexeyan derbas bikin û bi hejmareke mezin ji girêkên karkeran re koman ava bikin.
Kêmasiya # 2: Zêdetir lêçûnên zêde.
Li ser her girêk karker, Kubernetes komek şeytanên pergalê dimeşîne - di nav wan de dema xebitandina konteyneran (wek Docker), kube-proxy û kubelet, di nav de cAdvisor jî hene. Bi hev re ew hejmarek diyarkirî ya çavkaniyan dixwin.
Ger gelek girêkên we yên piçûk hebin, rêjeya vê sermayê li ser her nodê mezintir e. Mînakî, bifikirin ku hemî şeytanên pergalê li ser yek girêk bi hev re 0,1 core CPU û 0,1 GB bîra bikar tînin. Ger we yek nodek deh-core bi 10 GB bîranîn heye, wê hingê şeytan 1% ji kapasîteya komê vedixwe. Ji hêla din ve, li ser deh girêkên yek-core bi bîranîna 1 GB, dê dê 10% ji kapasîteya komê bigirin.
Bi vî rengî, girêk hindiktir, binesaziyek bi bandortir tê bikar anîn.
Kêmasiya Hejmar 3. Bikaranîna bêserûber a çavkaniyan
Li ser girêkên piçûk, dibe ku perçeyên çavkaniyê yên mayî pir piçûk bin ku meriv barê xebatê jê re were veqetandin, ji ber vê yekê ew bêkar dimînin.
Mînakî, her podek 0,75 GB bîranîn hewce dike. Ger deh girêkên we hebin, her yek bi 1 GB bîranîn heye, hûn dikarin deh girêkan bimeşînin, her girêkek bi 0,25 GB bîranîna nekarandî bihêle.
Ev tê wê wateyê ku 25% ji bîra tevahî komê winda dibe.
Li ser girêkek mezin a bi bîranîna 10 GB, hûn dikarin 13 ji van modulan bimeşînin - û dê tenê yek perçeyek 0,25 GB nekarandî hebe.
Di vê rewşê de, tenê 2,5% ji bîranînê winda dibe.
Bi vî rengî, çavkanî li ser girêkên mezin bi rengek çêtirîn têne bikar anîn.
Çend girêkên mezin an gelek yên piçûk?
Ji ber vê yekê, kîjan çêtir e: çend girêkên mezin di komekê de an gelek piçûk? Wek her dem, bersivek zelal tune. Pir bi celebê serîlêdanê ve girêdayî ye.
Mînakî, heke serîlêdanek 10 GB bîranîn hewce dike, girêkên mezin bijarek eşkere ne. Û heke serîlêdan ji bo hebûna zêde dubarekirina deh carî hewce dike, ne hêja ye ku meriv kopiyan li ser du girêkan tenê bi cîh bike - divê di komê de herî kêm deh girêk hebin.
Di rewşên navîn de, li gorî avantaj û dezawantajên her vebijarkê bijartinek bikin. Dibe ku hin arguman ji yên din bi rewşa we re têkildar in.
Û qet ne hewce ye ku meriv hemî girêkan heman mezinahiyê bike. Tiştek nahêle ku hûn pêşî bi girêkên heman mezinahiyê ceribandinê bikin, dûv re girêkên bi mezinahiyek cûda li wan zêde bikin, wan di komekê de berhev bikin. Girêkên karker ên di komek Kubernetes de dikarin bi tevahî heterojen bin. Ji ber vê yekê hûn dikarin hewl bidin ku avantajên her du rêbazan bi hev re bikin.
Reçeteyek yekane tune, û her rewş hûrgelên xwe hene, û tenê hilber dê rastiyê nîşan bide.
Werger ji aliyê ekîba platforma ewr ve hatiye amadekirin .
Zêdetir li ser Kubernetes: .
Source: www.habr.com