{"id":56259,"date":"2020-02-08T00:00:00","date_gmt":"2020-02-07T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih"},"modified":"2020-02-18T14:04:30","modified_gmt":"2020-02-18T11:04:30","slug":"rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","title":{"rendered":"Pracovn\u00e9 uzly Kubernetes: ve\u013ea mal\u00fdch alebo nieko\u013eko ve\u013ek\u00fdch?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Pracovn\u00e9
\nPri vytv\u00e1ran\u00ed klastra Kubernetes sa m\u00f4\u017eu objavi\u0165 ot\u00e1zky: ko\u013eko nastavi\u0165 pracovn\u00fdch uzlov a ak\u00e9ho typu? \u010co je lep\u0161ie pre on-premise klaster: k\u00fapi\u0165 nieko\u013eko v\u00fdkonn\u00fdch serverov, alebo vyu\u017ei\u0165 desiatku star\u0161\u00edch strojov vo va\u0161om d\u00e1tovom centre? A v cloude je lep\u0161ie vzia\u0165 osem jednojadrov\u00fdch alebo dva \u0161tvrojadrov\u00e9 in\u0161tancie? <\/p>\n

Odpovede na tieto ot\u00e1zky s\u00fa v \u010dl\u00e1nku Daniela Weibela, in\u017einiera-program\u00e1tora a lektora vzdel\u00e1vacieho projektu Learnk8s<\/a><\/noindex> v preklade t\u00edmu Kubernetes aaS od Mail.ru<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Kapacita klastrov<\/h2>\n

\nCelkovo sa klaster Kubernetes d\u00e1 pova\u017eova\u0165 za ve\u013ek\u00fd \u201esuperuzol\u201c. Jeho celkov\u00fd v\u00fdpo\u010dtov\u00fd v\u00fdkon je s\u00fa\u010dtom v\u00fdkonov v\u0161etk\u00fdch zlo\u017een\u00fdch uzlov. <\/p>\n

Existuje nieko\u013eko sp\u00f4sobov, ako dosiahnu\u0165 po\u017eadovan\u00fa cie\u013eov\u00fa kapacitu klastra. Napr\u00edklad potrebujeme klaster s celkovou kapacitou 8 CPU jadier a 32 GB RAM, preto\u017ee s\u00fabor aplik\u00e1ci\u00ed vy\u017eaduje tak\u00fdto po\u010det zdrojov. Potom je mo\u017en\u00e9 nain\u0161talova\u0165 dva uzly s 16 GB pam\u00e4te alebo \u0161tyri uzly s 8 GB pam\u00e4te, dva \u0161tvrojadrov\u00e9 procesory alebo \u0161tyri dvojjadrov\u00e9.<\/p>\n

Tu s\u00fa len dva mo\u017en\u00e9 sp\u00f4soby vytvorenia klastra:<\/p>\n

\"Pracovn\u00e9
\nObe mo\u017enosti d\u00e1vaj\u00fa klaster s rovnakou kapacitou, ale v spodnej konfigur\u00e1cii s\u00fa nain\u0161talovan\u00e9 \u0161tyri men\u0161ie uzly, zatia\u013e \u010do v hornej konfigur\u00e1cii s\u00fa dva ve\u013ek\u00e9. <\/p>\n

Ktor\u00e1 mo\u017enos\u0165 je lep\u0161ia?<\/h3>\n

\nAby sme na t\u00fato ot\u00e1zku odpovedali, pozrime sa na v\u00fdhody oboch mo\u017enost\u00ed. Dali sme ich do tabu\u013eky.<\/p>\n

Nieko\u013eko ve\u013ek\u00fdch uzlov<\/p>\n

Ve\u013ea mal\u00fdch uzlov<\/p>\n

Jednoduch\u0161ie spravovanie klastra (ak je on-premise)<\/p>\n

Plynul\u00e9 automatick\u00e9 \u0161k\u00e1lovanie<\/p>\n

Lep\u0161ie cenov\u00e9 mo\u017enosti (ak je on-premise) <\/p>\n

Cena sa m\u00e1lo l\u00ed\u0161i (v cloude) <\/p>\n

Je mo\u017en\u00e9 sp\u00fa\u0161\u0165a\u0165 n\u00e1ro\u010dn\u00e9 aplik\u00e1cie <\/p>\n

\u00dapln\u00e1 replik\u00e1cia<\/p>\n

Zdroje sa vyu\u017e\u00edvaj\u00fa efekt\u00edvnej\u0161ie (men\u0161\u00ed overhead na syst\u00e9mov\u00e9 d\u00e9mony)
\nVy\u0161\u0161ia odolnos\u0165 vo\u010di zlyhaniu klastra<\/p>\n

V\u0161imnite si, \u017ee hovor\u00edme len o pracovn\u00fdch uzloch. V\u00fdber po\u010dtu a ve\u013ekosti hlavn\u00fdch uzlov je \u00faplne in\u00e1 t\u00e9ma.<\/p>\n

Tak\u017ee sa podrobne pozrime na ka\u017ed\u00fd bod z tabu\u013eky.<\/p>\n

Prv\u00e1 mo\u017enos\u0165: nieko\u013eko ve\u013ek\u00fdch uzlov<\/h2>\n

\nNajextr\u00e9mnej\u0161ia mo\u017enos\u0165 \u2014 jeden pracovn\u00fd uzol na cel\u00fa kapacitu klastra. V uvedenom pr\u00edklade to bol jeden pracovn\u00fd uzol s 16 CPU jadrami a 16 GB RAM.<\/p>\n

V\u00fdhody <\/h3>\n

\nPlus \u010d. 1. Jednoduch\u0161ie spravovanie<\/b>
\nJe jednoduch\u0161ie spravova\u0165 nieko\u013eko strojov ako cel\u00fd park. R\u00fdchlej\u0161ie aplikova\u0165 aktualiz\u00e1cie a opravy, jednoduch\u0161ie synchronizova\u0165. Po\u010det v\u00fdpadkov v absol\u00fatnych \u010d\u00edslach je tie\u017e ni\u017e\u0161\u00ed.<\/p>\n

Upozor\u0148ujeme, \u017ee v\u0161etko vy\u0161\u0161ie uveden\u00e9 sa vz\u0165ahuje na vlastn\u00fd hardv\u00e9r, vlastn\u00e9 servery, nie na cloudov\u00e9 instance.<\/p><\/blockquote>\n

\nV cloude je situ\u00e1cia in\u00e1. O riadenie sa star\u00e1 poskytovate\u013e cloudov\u00fdch slu\u017eieb. T\u00fdm p\u00e1dom sa spr\u00e1va desiatich uzlov v cloude v\u00fdznamne nel\u00ed\u0161i od spr\u00e1vy jedn\u00e9ho uzla.<\/p>\n

Routovanie prev\u00e1dzky a rozde\u013eovanie za\u0165a\u017eenia medzi podmi v cloude sa vykon\u00e1va automaticky<\/a><\/noindex>: prich\u00e1dzaj\u00faca prev\u00e1dzka z internetu je smerovan\u00e1 na hlavn\u00fd vyva\u017eova\u010d za\u0165a\u017eenia, ktor\u00fd potom smeruje prev\u00e1dzku na port jedn\u00e9ho z uzlov (slu\u017eba NodePort vy\u017eaduje port v rozsahu 30000-32767 na ka\u017edom uzle klastera). Pravidl\u00e1 nastaven\u00e9 kube-proxy presmerov\u00e1vaj\u00fa prev\u00e1dzku z uzla na pod. Takto to vyzer\u00e1 pre desa\u0165 podov na dvoch uzloch:<\/p>\n

\"Pracovn\u00e9
\nPlus \u010d. 2. Ni\u017e\u0161ie n\u00e1klady na uzol<\/b>
\nV\u00fdkonn\u00fd stroj je drah\u0161\u00ed, ale rast ceny nie je nevyhnutne line\u00e1rny. In\u00fdmi slovami, jeden desa\u0165jadrov\u00fd server s 10 GB pam\u00e4te je zvy\u010dajne lacnej\u0161\u00ed ako desa\u0165 jednojadrov\u00fdch s rovnak\u00fdm mno\u017estvom pam\u00e4te.<\/p>\n

Ale v\u0161imnite si, \u017ee toto pravidlo zvy\u010dajne neplat\u00ed v cloudov\u00fdch slu\u017eb\u00e1ch. V s\u00fa\u010dasn\u00fdch cenov\u00fdch sch\u00e9mach v\u0161etk\u00fdch hlavn\u00fdch poskytovate\u013eov cloudov\u00fdch slu\u017eieb ceny rast\u00fa line\u00e1rne s rastom kapacity.<\/p><\/blockquote>\n

\nT\u00fdm p\u00e1dom v cloude sa zvy\u010dajne ned\u00e1 u\u0161etri\u0165 na v\u00fdkonnej\u0161\u00edch serveroch.<\/p>\n

Plus \u010d. 3. M\u00f4\u017eete sp\u00fa\u0161\u0165a\u0165 n\u00e1ro\u010dn\u00e9 aplik\u00e1cie<\/b>
\nNiektor\u00e9 aplik\u00e1cie potrebuj\u00fa v\u00fdkonn\u00e9 servery v klastri. Napr\u00edklad, ak syst\u00e9m strojov\u00e9ho u\u010denia vy\u017eaduje 8 GB pam\u00e4te, nem\u00f4\u017eete ho spusti\u0165 na uzloch s 1 GB, ale iba ak m\u00e1te aspo\u0148 jeden ve\u013ek\u00fd pracovn\u00fd uzol.<\/p>\n

Nev\u00fdhody <\/h3>\n

\nNev\u00fdhoda \u010d. 1. Ve\u013ea podov na uzol<\/b>
\nAk sa t\u00e1 ist\u00e1 \u00faloha vykon\u00e1va na men\u0161om po\u010dte uzlov, na ka\u017edom z nich bude prirodzene viac podov.<\/p>\n

To m\u00f4\u017ee by\u0165 probl\u00e9m.<\/p>\n

D\u00f4vodom je, \u017ee ka\u017ed\u00fd modul prin\u00e1\u0161a ur\u010dit\u00e9 re\u017eijn\u00e9 n\u00e1klady na prostredie kontajnerov (napr\u00edklad Docker), ako aj kubelet a cAdvisor.<\/p>\n

Napr\u00edklad, kubelet pravidelne kontroluje \u017eivos\u0165 v\u0161etk\u00fdch kontajnerov na uzle \u2014 \u010d\u00edm viac kontajnerov, t\u00fdm viac pr\u00e1ce m\u00e1 kubelet.<\/p>\n

CAdvisor zhroma\u017e\u010fuje \u0161tatistiky vyu\u017e\u00edvania zdrojov v\u0161etk\u00fdch kontajnerov na uzle a kubelet pravidelne t\u00fato inform\u00e1ciu vy\u017eaduje a poskytuje ju cez API. Op\u00e4\u0165, \u010d\u00edm viac kontajnerov, t\u00fdm viac pr\u00e1ce m\u00e1 cAdvisor aj kubelet.<\/p>\n

Ak po\u010det modulov vzrastie, m\u00f4\u017ee to spomali\u0165 syst\u00e9m a dokonca ohrozi\u0165 jeho spo\u013eahlivos\u0165.<\/p>\n

\"Pracovn\u00e9
\nV repozit\u00e1ri Kubernetes niektor\u00ed s\u0165a\u017eovali<\/a><\/noindex>, \u017ee uzly sa sk\u00e1\u010du medzi stavmi Ready\/NotReady, preto\u017ee pravideln\u00e9 kontroly kubeletu v\u0161etk\u00fdch kontajnerov na uzle zaberaj\u00fa prive\u013ea \u010dasu.
\nZ tohto d\u00f4vodu Kubernetes odpor\u00fa\u010da umiestni\u0165 najviac 110 podov na uzol<\/a><\/noindex>. V z\u00e1vislosti od v\u00fdkonu uzla m\u00f4\u017eete spusti\u0165 viac podov na uzol, ale \u0165a\u017eko predpoklada\u0165, \u010di vznikn\u00fa probl\u00e9my alebo v\u0161etko bude fungova\u0165 dobre. Je dobr\u00e9 to vopred otestova\u0165. <\/p>\n

Nev\u00fdhoda \u010d. 2. Obmedzenie replika\u010dn\u00e9ho v\u00fdkonu<\/b>
\nPr\u00edli\u0161 n\u00edzky po\u010det uzlov obmedzuje \u00fa\u010dinn\u00e9 stupne replika\u010dn\u00e9ho v\u00fdkonu aplik\u00e1ci\u00ed. Napr\u00edklad, ak m\u00e1te aplik\u00e1ciu s vysokou dostupnos\u0165ou s piatimi replikami, ale len dva uzly, \u00fa\u010dinn\u00e1 miera replika\u010dn\u00e9ho v\u00fdkonu aplik\u00e1cie sa zni\u017euje na dva.<\/p>\n

P\u00e4\u0165 replik sa d\u00e1 rozlo\u017ei\u0165 len na dva uzly, a ak jeden z nich prestane fungova\u0165, okam\u017eite vyrad\u00ed nieko\u013eko replik.<\/p>\n

Ak m\u00e1te p\u00e4\u0165 uzlov alebo viac, ka\u017ed\u00e1 replika sa vykon\u00e1va na samostatnom uzle a zlyhanie jedn\u00e9ho uzla odstr\u00e1ni maxim\u00e1lne jednu repliku.<\/p>\n

Preto po\u017eiadavky na vysok\u00fa dostupnos\u0165 m\u00f4\u017eu vy\u017eadova\u0165 ur\u010dit\u00fd minim\u00e1lny po\u010det uzlov v klusteri.<\/p>\n

Nev\u00fdhoda \u010d. 3. Zhor\u0161en\u00e9 n\u00e1sledky zlyhania<\/b>
\nPri men\u0161om po\u010dte uzlov nesie ka\u017ed\u00e9 zlyhanie v\u00e1\u017enej\u0161ie d\u00f4sledky. Napr\u00edklad, ak m\u00e1te len dva uzly a jeden z nich zlyh\u00e1, polovica va\u0161ich modulov zmizne.<\/p>\n

Samozrejme, Kubernetes presunie z\u00e1\u0165a\u017e z nefunk\u010dn\u00e9ho uzla na ostatn\u00e9. Ale ak ich je m\u00e1lo, m\u00f4\u017ee ch\u00fdba\u0165 vo\u013en\u00e1 kapacita. V d\u00f4sledku toho bud\u00fa niektor\u00e9 va\u0161e aplik\u00e1cie nedostupn\u00e9, k\u00fdm neobnov\u00edte nefunk\u010dn\u00fd uzol.<\/p>\n

Tak\u017ee \u010d\u00edm viac uzlov, t\u00fdm men\u0161\u00ed dopad hardv\u00e9rov\u00fdch zlyhan\u00ed.<\/p>\n

Nev\u00fdhoda \u010d. 4. Viac krokov automatick\u00e9ho \u0161k\u00e1lovania.<\/b>
\nV Kubernetes funguje syst\u00e9m automatick\u00e9ho \u0161k\u00e1lovania klastra pre cloudov\u00fa infra\u0161trukt\u00faru, ktor\u00fd umo\u017e\u0148uje automaticky prid\u00e1va\u0165 alebo odobera\u0165 uzly pod\u013ea aktu\u00e1lnych potrieb. S v\u00e4\u010d\u0161\u00edmi uzlami sa \u0161k\u00e1lovanie st\u00e1va v\u00fdraznej\u0161\u00edm a menej obratn\u00fdm. Napr\u00edklad, ak prid\u00e1te \u010fal\u0161\u00ed uzol na dvoch uzloch, kapacita klastra sa okam\u017eite zv\u00fd\u0161i o 50 %. A budete musie\u0165 za tieto zdroje zaplati\u0165, aj ke\u010f ich nepotrebujete.<\/p>\n

Tak\u017ee, ak pl\u00e1nujete pou\u017e\u00edva\u0165 automatick\u00e9 \u0161k\u00e1lovanie klastra, \u010d\u00edm men\u0161ie s\u00fa uzly, t\u00fdm flexibilnej\u0161ie a hospod\u00e1rnej\u0161ie \u0161k\u00e1lovanie dostanete.<\/p>\n

Teraz sa pozrime na v\u00fdhody a nev\u00fdhody ve\u013ek\u00e9ho mno\u017estva mal\u00fdch uzlov.<\/p>\n

Druh\u00e1 mo\u017enos\u0165: mno\u017estvo mal\u00fdch uzlov<\/h2>\n

\nV\u00fdhody tohto pr\u00edstupu v podstate vypl\u00fdvaj\u00fa z nev\u00fdhod opa\u010dnej mo\u017enosti s nieko\u013ek\u00fdmi ve\u013ek\u00fdmi uzlami.<\/p>\n

V\u00fdhody<\/h3>\n

\nPlus \u010d. 1. Men\u0161ie n\u00e1sledky v\u00fdpadku<\/b>
\n\u010c\u00edm viac uzlov, t\u00fdm menej podov na ka\u017edom uzle. Napr\u00edklad, ak m\u00e1te stovku modulov na desa\u0165 uzlov, na ka\u017edom uzle bude v priemere desa\u0165 modulov.<\/p>\n

Ak teda jeden z uzlov zlyh\u00e1, strat\u00edte len 10 % pracovnej z\u00e1\u0165a\u017ee. Existuje pravdepodobnos\u0165, \u017ee sa dotkne len mal\u00e9ho po\u010dtu replik, a aplik\u00e1cie v celku zostan\u00fa v prev\u00e1dzke.<\/p>\n

Okrem toho na zost\u00e1vaj\u00facich uzloch pravdepodobne zostan\u00fa vo\u013en\u00e9 zdroje pre za\u0165a\u017eenie nefunk\u010dn\u00e9ho uzla, tak\u017ee Kubernetes m\u00f4\u017ee vo\u013ene prepl\u00e1nova\u0165 pody a va\u0161e aplik\u00e1cie sa relat\u00edvne r\u00fdchlo vr\u00e1tia do funk\u010dn\u00e9ho stavu.<\/p>\n

Plus \u010d. 2. Dobr\u00e1 replik\u00e1cia<\/b>
\nAk je uzlov dostato\u010dne, pl\u00e1nova\u010d Kubernetes m\u00f4\u017ee priradi\u0165 v\u0161etk\u00fdm replik\u00e1m r\u00f4zne uzly. Tak\u017ee v pr\u00edpade zlyhania uzla bude ovplyvnen\u00e1 len jedna replika a aplik\u00e1cia zostane dostupn\u00e1.<\/p>\n

Nev\u00fdhody <\/h3>\n

\nMinus \u010d. 1. \u0164a\u017e\u0161ie riadenie<\/b>
\nS ve\u013ek\u00fdm po\u010dtom uzlov je \u0165a\u017e\u0161ie spravova\u0165. Napr\u00edklad ka\u017ed\u00fd uzol Kubernetes mus\u00ed komunikova\u0165 so v\u0161etk\u00fdmi ostatn\u00fdmi, to znamen\u00e1, \u017ee po\u010det spojen\u00ed rastie kvadraticky a v\u0161etky tieto spojenia treba sledova\u0165.<\/p>\n

Kontrol\u00e9r uzlov v mana\u017e\u00e9ri kontrol\u00e9rov Kubernetes pravidelne obch\u00e1dza v\u0161etky uzly v klastri na kontrolu funk\u010dnosti \u2014 \u010d\u00edm viac uzlov, t\u00fdm v\u00e4\u010d\u0161ia z\u00e1\u0165a\u017e na kontrol\u00e9r.<\/p>\n

Zv\u00e4\u010d\u0161uje sa aj z\u00e1\u0165a\u017e na datab\u00e1zach etcd \u2014 ka\u017ed\u00fd kubelet a kube-proxy vykon\u00e1va watcher<\/a><\/noindex> pre et cetera (cez API), na ktor\u00fd by mal etcd pren\u00e1\u0161a\u0165 aktualiz\u00e1cie objektu.<\/p>\n

Celkovo ka\u017ed\u00fd pracovn\u00fd uzol za\u0165a\u017euje syst\u00e9mov\u00e9 komponenty hlavn\u00fdch uzlov.<\/p>\n

\"Pracovn\u00e9
\nOfici\u00e1lne Kubernetes podporuje klastry s po\u010det uzlov a\u017e do 5000<\/a><\/noindex>. V praxi u\u017e 500 uzlov m\u00f4\u017ee sp\u00f4sobi\u0165 netrivi\u00e1lne probl\u00e9my<\/a><\/noindex>.<\/p>\n

Na spr\u00e1vu ve\u013ek\u00e9ho po\u010dtu pracovn\u00fdch uzlov je potrebn\u00e9 vybra\u0165 v\u00fdkonnnej\u0161ie hlavn\u00e9 uzly. Napr\u00edklad, kube-up automaticky in\u0161taluje<\/a><\/noindex> spr\u00e1vnu ve\u013ekos\u0165 VM pre hlavn\u00fd uzol v z\u00e1vislosti od po\u010dtu pracovn\u00fdch uzlov. To znamen\u00e1, \u017ee \u010d\u00edm viac pracovn\u00fdch uzlov, t\u00fdm v\u00fdkonnej\u0161ie musia by\u0165 hlavn\u00e9 uzly. <\/p>\n

Na rie\u0161enie t\u00fdchto \u0161pecifick\u00fdch probl\u00e9mov existuj\u00fa \u0161peci\u00e1lne v\u00fdvojov\u00e9 n\u00e1stroje, ako napr\u00edklad Virtual Kubelet<\/a><\/noindex>. Tento syst\u00e9m umo\u017e\u0148uje ob\u00eds\u0165 obmedzenia a vytv\u00e1ra\u0165 klastry s obrovsk\u00fdm po\u010dtom pracovn\u00fdch uzlov.<\/p>\n

Nev\u00fdhoda \u010d. 2. Vy\u0161\u0161ie re\u017eijn\u00e9 n\u00e1klady<\/b>
\nNa ka\u017edom pracovnom uzle Kubernetes sp\u00fa\u0161\u0165a s\u00fabor syst\u00e9mov\u00fdch d\u00e9monov \u2014 medzi nimi s\u00fa prostredie na vykon\u00e1vanie kontajnerov (napr\u00edklad Docker), kube-proxy a kubelet, vr\u00e1tane cAdvisor. V\u0161etky spolu spotrebov\u00e1vaj\u00fa ur\u010dit\u00e9 fixn\u00e9 mno\u017estvo zdrojov.<\/p>\n

Ak m\u00e1te ve\u013ea mal\u00fdch uzlov, podiel t\u00fdchto re\u017eijn\u00fdch n\u00e1kladov na ka\u017edom uzle je v\u00e4\u010d\u0161\u00ed. Napr\u00edklad si predstavte, \u017ee v\u0161etci syst\u00e9mov\u00ed d\u00e9moni jedn\u00e9ho uzla spolu pou\u017e\u00edvaj\u00fa 0,1 jadra CPU a 0,1 GB pam\u00e4te. Ak m\u00e1te jeden desajadern\u00fd uzol s 10 GB pam\u00e4te, d\u00e9moni spotrebuj\u00fa 1% kapacity klastra. Na druhej strane, na desiatich jednojadrov\u00fdch uzloch s 1 GB pam\u00e4te, d\u00e9moni zober\u00fa 10% kapacity klastra.<\/p>\n

T\u00fdm p\u00e1dom, \u010d\u00edm menej uzlov, t\u00fdm efekt\u00edvnej\u0161ie sa vyu\u017e\u00edva infra\u0161trukt\u00fara.<\/p>\n

Nev\u00fdhoda \u010d. 3. Neefekt\u00edvne vyu\u017eitie zdrojov<\/b>
\nNa mal\u00fdch uzloch m\u00f4\u017ee nasta\u0165 situ\u00e1cia, \u017ee zvy\u0161n\u00e9 fragmenty zdrojov s\u00fa pr\u00edli\u0161 mal\u00e9 na to, aby sa im pridelila nejak\u00e1 pracovn\u00e1 z\u00e1\u0165a\u017e, ale ost\u00e1vaj\u00fa nevyu\u017eit\u00e9.<\/p>\n

Napr\u00edklad, ka\u017ed\u00fd pod vy\u017eaduje 0,75 GB pam\u00e4te. Ak m\u00e1te desa\u0165 uzlov a na ka\u017edom po 1 GB pam\u00e4te, m\u00f4\u017eete spusti\u0165 desa\u0165 podov \u2014 na ka\u017edom uzle tak zostane 0,25 GB nevyu\u017eitej pam\u00e4te.<\/p>\n

To znamen\u00e1, \u017ee 25% pam\u00e4te cel\u00e9ho klastra sa m\u00ed\u0148a zbyto\u010dne.<\/p>\n

Na ve\u013ekom uzle s 10 GB pam\u00e4te m\u00f4\u017eete spusti\u0165 13 tak\u00fdch modulov \u2014 a ostane len jeden nevyu\u017eit\u00fd fragment 0,25 GB.<\/p>\n

V tomto pr\u00edpade sa m\u00ed\u0148a zbyto\u010dne len 2,5% pam\u00e4te.<\/p>\n

T\u00fdmto sp\u00f4sobom sa na ve\u013ek\u00fdch uzloch optim\u00e1lnej\u0161ie vyu\u017e\u00edvaj\u00fa zdroje.<\/p>\n

Nieko\u013eko ve\u013ek\u00fdch uzlov alebo mnoho mal\u00fdch?<\/h2>\n

\n\u010co je teda lep\u0161ie: nieko\u013eko ve\u013ek\u00fdch uzlov v klastri alebo ve\u013ea mal\u00fdch? Ako v\u017edy, jednozna\u010dn\u00e1 odpove\u010f neexistuje. Mnoho z\u00e1vis\u00ed od typu aplik\u00e1cie.<\/p>\n

Napr\u00edklad, ak aplik\u00e1cia vy\u017eaduje 10 GB pam\u00e4te, vo\u013eba vo v\u00e4\u010d\u0161\u00edch uzloch je jasn\u00e1. A ak aplik\u00e1cia vy\u017eaduje desa\u0165n\u00e1sobn\u00fa replik\u00e1ciu pre vysok\u00fa dostupnos\u0165, sotva by st\u00e1lo za to riskova\u0165 a umiestni\u0165 repliky len na dvoch uzloch \u2014 v klastri by malo by\u0165 minim\u00e1lne desa\u0165 uzlov.<\/p>\n

V medzi\u010dase sa rozhodujte na z\u00e1klade v\u00fdhod a nev\u00fdhod ka\u017ed\u00e9ho variantu. Mo\u017eno niektor\u00e9 argumenty s\u00fa pre va\u0161u situ\u00e1ciu aktu\u00e1lnej\u0161ie ako in\u00e9.<\/p>\n

A v\u00f4bec nie je nutn\u00e9, aby v\u0161etky uzly mali rovnak\u00fa ve\u013ekos\u0165. Ni\u010d v\u00e1m nebr\u00e1ni experimentova\u0165 najprv s uzlami jednej ve\u013ekosti a potom prida\u0165 uzly inej ve\u013ekosti, kombinuj\u00fac ich v klastri. Pracovn\u00e9 uzly klastra Kubernetes m\u00f4\u017eu by\u0165 \u00faplne heterog\u00e9nne. Tak\u017ee m\u00f4\u017eete vysk\u00fa\u0161a\u0165 v\u00fdhody oboch pr\u00edstupov.<\/p>\n

Neexistuje jedin\u00fd recept, ka\u017ed\u00e1 situ\u00e1cia m\u00e1 svoje nuansy a pravdu uk\u00e1\u017ee len produkcia.<\/p>\n

Preklad pripravila t\u00edm cloudovej platformy Mail.ru Cloud Solutions<\/a><\/noindex>.<\/i><\/p>\n

E\u0161te o Kubernetes: 25 u\u017eito\u010dn\u00fdch n\u00e1strojov na spr\u00e1vu a nasadzovanie klastrov<\/a><\/noindex>.<\/p>\n

Zdroj: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041f\u0440\u0438 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u0438 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 Kubernetes \u043c\u043e\u0433\u0443\u0442 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0442\u044c \u0432\u043e\u043f\u0440\u043e\u0441\u044b: \u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u0442\u044c \u0440\u0430\u0431\u043e\u0447\u0438\u0445 \u0443\u0437\u043b\u043e\u0432 \u0438 \u043a\u0430\u043a\u043e\u0433\u043e \u0442\u0438\u043f\u0430? \u0427\u0442\u043e \u043b\u0443\u0447\u0448\u0435 \u0434\u043b\u044f \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 on-premise: \u043a\u0443\u043f\u0438\u0442\u044c \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043c\u043e\u0449\u043d\u044b\u0445 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u0438\u043b\u0438 \u0437\u0430\u0434\u0435\u0439\u0441\u0442\u0432\u043e\u0432\u0430\u0442\u044c \u0434\u0435\u0441\u044f\u0442\u043e\u043a \u0441\u0442\u0430\u0440\u044b\u0445 \u043c\u0430\u0448\u0438\u043d \u0432 \u0432\u0430\u0448\u0435\u043c \u0434\u0430\u0442\u0430-\u0446\u0435\u043d\u0442\u0440\u0435? \u0410 \u0432 \u043e\u0431\u043b\u0430\u043a\u0435 \u043b\u0443\u0447\u0448\u0435 \u0432\u0437\u044f\u0442\u044c \u0432\u043e\u0441\u0435\u043c\u044c \u043e\u0434\u043d\u043e\u044f\u0434\u0435\u0440\u043d\u044b\u0445 \u0438\u043b\u0438 \u0434\u0432\u0430 \u0447\u0435\u0442\u044b\u0440\u0435\u0445\u044a\u044f\u0434\u0435\u0440\u043d\u044b\u0445 \u0438\u043d\u0441\u0442\u0430\u043d\u0441\u0430? \u041e\u0442\u0432\u0435\u0442\u044b \u043d\u0430 \u044d\u0442\u0438 \u0432\u043e\u043f\u0440\u043e\u0441\u044b \u2014 \u0432 \u0441\u0442\u0430\u0442\u044c\u0435 \u0414\u0430\u043d\u0438\u044d\u043b\u044f \u0412\u0430\u0439\u0431\u0435\u043b\u044f, \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u0430-\u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u0430 \u0438 \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u0432\u0430\u0442\u0435\u043b\u044f \u043e\u0431\u0443\u0447\u0430\u044e\u0449\u0435\u0433\u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-56259","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Pracovn\u00e9 uzly Kubernetes: mnoho mal\u00fdch alebo nieko\u013eko ve\u013ek\u00fdch? | ProHoster","description":"Pri vytv\u00e1ran\u00ed klastra.","canonical_url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sk_SK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0420\u0430\u0431\u043e\u0447\u0438\u0435 \u0443\u0437\u043b\u044b Kubernetes: \u043c\u043d\u043e\u0433\u043e \u043c\u0430\u043b\u0435\u043d\u044c\u043a\u0438\u0445 \u0438\u043b\u0438 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0431\u043e\u043b\u044c\u0448\u0438\u0445? | ProHoster","og:description":"\u041f\u0440\u0438 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u0438 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430.","og:url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-02-07T21:00:00+00:00","article:modified_time":"2020-02-18T11:04:30+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"56259","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:28:23","updated":"2022-10-03 08:08:38","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/56259","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/comments?post=56259"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/56259\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media?parent=56259"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/categories?post=56259"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/tags?post=56259"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}