{"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\/cs\/blog\/administrirovanie\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","title":{"rendered":"Pracovn\u00ed uzly Kubernetes: mnoho mal\u00fdch nebo n\u011bkolik velk\u00fdch?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Pracovn\u00ed
\nP\u0159i vytv\u00e1\u0159en\u00ed Kubernetes clusteru se mohou vyskytovat ot\u00e1zky: kolik pracovn\u00edch uzl\u016f nastavit a jak\u00e9ho typu? Co je lep\u0161\u00ed pro on-premise cluster: koupit n\u011bkolik v\u00fdkonn\u00fdch server\u016f, nebo zapojit des\u00edtku star\u00fdch stroj\u016f ve va\u0161em datov\u00e9m centru? A v cloudu je lep\u0161\u00ed vz\u00edt osm jednoprocesorov\u00fdch nebo dva \u010dty\u0159j\u00e1drov\u00e9 instance? <\/p>\n

Odpov\u011bdi na tyto ot\u00e1zky naleznete v \u010dl\u00e1nku Dani\u00ebla Weibela, programov\u00e9ho in\u017een\u00fdra a u\u010ditele vzd\u011bl\u00e1vac\u00edho projektu Learnk8s<\/a><\/noindex> v p\u0159ekladu t\u00fdmu Kubernetes aaS od Mail.ru<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Kapacita clusteru<\/h2>\n

\nObecn\u011b se d\u00e1 Kubernetes cluster pova\u017eovat za velk\u00fd \"superuzel\". Jeho celkov\u00fd v\u00fdpo\u010detn\u00ed v\u00fdkon je sou\u010dtem v\u00fdkon\u016f v\u0161ech jednotliv\u00fdch uzl\u016f. <\/p>\n

Existuje n\u011bkolik zp\u016fsob\u016f, jak dos\u00e1hnout po\u017eadovan\u00e9 c\u00edlov\u00e9 kapacity clusteru. Nap\u0159\u00edklad, pot\u0159ebujeme cluster s celkovou kapacitou 8 procesorov\u00fdch jader a 32 GB RAM, proto\u017ee sada aplikac\u00ed vy\u017eaduje tolik zdroj\u016f. Potom je mo\u017en\u00e9 nastavit dva uzly s 16 GB pam\u011bti nebo \u010dty\u0159i uzly s 8 GB pam\u011bti, dva \u010dty\u0159j\u00e1drov\u00e9 procesory nebo \u010dty\u0159i dvouj\u00e1drov\u00e9.<\/p>\n

Toto jsou pouze dva mo\u017en\u00e9 zp\u016fsoby vytvo\u0159en\u00ed clusteru:<\/p>\n

\"Pracovn\u00ed
\nOb\u011b mo\u017enosti poskytuj\u00ed cluster se stejnou kapacitou, ale v doln\u00ed konfiguraci jsou \u010dty\u0159i men\u0161\u00ed uzly, zat\u00edmco v horn\u00ed konfiguraci jsou dva v\u011bt\u0161\u00ed. <\/p>\n

Kter\u00e1 varianta je lep\u0161\u00ed?<\/h3>\n

\nAbychom na tuto ot\u00e1zku odpov\u011bd\u011bli, pod\u00edvejme se na v\u00fdhody obou mo\u017enost\u00ed. Sepsali jsme je do tabulky.<\/p>\n

N\u011bkolik velk\u00fdch uzl\u016f<\/p>\n

Mnoho mal\u00fdch uzl\u016f<\/p>\n

Jednodu\u0161\u0161\u00ed spr\u00e1va clusteru (pokud je on-premise)<\/p>\n

Plynul\u00e9 automatick\u00e9 \u0161k\u00e1lov\u00e1n\u00ed<\/p>\n

Levn\u011bj\u0161\u00ed (pokud je on-premise) <\/p>\n

Cena je velmi podobn\u00e1 (v cloudu) <\/p>\n

Mo\u017enost spou\u0161t\u011bt n\u00e1ro\u010dn\u00e9 aplikace <\/p>\n

Plnohodnotn\u00e1 replikace<\/p>\n

Zdroje jsou efektivn\u011bji vyu\u017e\u00edv\u00e1ny (ni\u017e\u0161\u00ed re\u017eie na syst\u00e9mov\u00e9 d\u00e9mony)
\nVy\u0161\u0161\u00ed odolnost clusteru proti poruch\u00e1m<\/p>\n

V\u0161imn\u011bte si, \u017ee se bav\u00edme pouze o pracovn\u00edch uzlech. V\u00fdb\u011br po\u010dtu a velikosti hlavn\u00edch uzl\u016f je zcela jin\u00e9 t\u00e9ma.<\/p>\n

Poj\u010fme se pod\u00edvat podrobn\u011bji na ka\u017ed\u00fd bod z tabulky.<\/p>\n

Prvn\u00ed varianta: n\u011bkolik velk\u00fdch uzl\u016f<\/h2>\n

\nNejextr\u00e9mn\u011bj\u0161\u00ed varianta \u2014 jeden pracovn\u00ed uzel na celou kapacitu clusteru. V uveden\u00e9m p\u0159\u00edkladu by to byl jeden pracovn\u00ed uzel se 16 j\u00e1dry CPU a 16 GB RAM.<\/p>\n

V\u00fdhody <\/h3>\n

\nPlus \u010d\u00edslo 1. Snadn\u011bj\u0161\u00ed spr\u00e1va<\/b>
\nJe snaz\u0161\u00ed spravovat n\u011bkolik stroj\u016f ne\u017e cel\u00fd park. Aktualizace a opravy se aplikuj\u00ed rychleji a synchronizace je jednodu\u0161\u0161\u00ed. Absolutn\u00ed \u010d\u00edsla v\u00fdpadk\u016f jsou tak\u00e9 ni\u017e\u0161\u00ed.<\/p>\n

Vezm\u011bte pros\u00edm na v\u011bdom\u00ed, \u017ee v\u0161e v\u00fd\u0161e uveden\u00e9 se vztahuje na vlastn\u00ed hardware, vlastn\u00ed servery, a nikoli na cloudov\u00e9 instance.<\/p><\/blockquote>\n

\nVe cloudu je situace jin\u00e1. O spr\u00e1vu se star\u00e1 poskytovatel cloudov\u00fdch slu\u017eeb. T\u00edm p\u00e1dem spr\u00e1va deseti uzl\u016f v cloudu se od spr\u00e1vy jednoho uzlu p\u0159\u00edli\u0161 neli\u0161\u00ed.<\/p>\n

Sm\u011brov\u00e1n\u00ed provozu a rozd\u011blov\u00e1n\u00ed z\u00e1t\u011b\u017ee mezi pody v cloudu se prov\u00e1d\u00ed automaticky<\/a><\/noindex>: p\u0159\u00edchoz\u00ed provoz z internetu je sm\u011brov\u00e1n na hlavn\u00ed vyv\u00e1\u017ee\u010d z\u00e1t\u011b\u017ee, kter\u00fd sm\u011bruje provoz na port jednoho z uzl\u016f (slu\u017eba NodePort vystavuje port v rozmez\u00ed 30000-32767 na ka\u017ed\u00e9m uzlu clusteru). Pravidla stanoven\u00e1 kube-proxy p\u0159esm\u011brov\u00e1vaj\u00ed provoz z uzlu na pod. Takto to vypad\u00e1 pro deset pod\u016f na dvou uzlech:<\/p>\n

\"Pracovn\u00ed
\nPlus \u010d\u00edslo 2. Ni\u017e\u0161\u00ed n\u00e1klady na uzel<\/b>
\nV\u00fdkonn\u011bj\u0161\u00ed stroj je dra\u017e\u0161\u00ed, ale n\u00e1r\u016fst ceny nen\u00ed nutn\u011b line\u00e1rn\u00ed. Jin\u00fdmi slovy, jeden deseti j\u00e1drov\u00fd server s 10 GB pam\u011bti je obvykle levn\u011bj\u0161\u00ed ne\u017e deset jednoj\u00e1drov\u00fdch s t\u00edm stejn\u00fdm mno\u017estv\u00edm pam\u011bti.<\/p>\n

Ale vezm\u011bte pros\u00edm na v\u011bdom\u00ed, \u017ee toto pravidlo obvykle neplat\u00ed u cloudov\u00fdch slu\u017eeb. V aktu\u00e1ln\u00edch cenov\u00fdch modelech v\u0161ech hlavn\u00edch poskytovatel\u016f cloudov\u00fdch slu\u017eeb se ceny linearizuj\u00ed s rostouc\u00ed kapacitou.<\/p><\/blockquote>\n

\nT\u00edm p\u00e1dem ve cloudu obvykle nelze u\u0161et\u0159it na v\u00fdkonn\u011bj\u0161\u00edch serverech.<\/p>\n

Plus \u010d\u00edslo 3. M\u016f\u017eete spou\u0161t\u011bt n\u00e1ro\u010dn\u00e9 aplikace<\/b>
\nN\u011bkter\u00fdm aplikac\u00edm jsou zapot\u0159eb\u00ed v\u00fdkonn\u00e9 servery v clusteru. Nap\u0159\u00edklad, pokud syst\u00e9m strojov\u00e9ho u\u010den\u00ed vy\u017eaduje 8 GB pam\u011bti, nebudete jej moci spustit na uzlech s 1 GB, ale pouze p\u0159i existenci alespo\u0148 jednoho velk\u00e9ho pracovn\u00edho uzlu.<\/p>\n

Nev\u00fdhody <\/h3>\n

\nMinus \u010d. 1. Mnoho pod\u016f na uzel<\/b>
\nPokud je stejn\u00fd \u00fakol prov\u00e1d\u011bn na men\u0161\u00edm po\u010dtu uzl\u016f, pak na ka\u017ed\u00e9m z nich p\u0159irozen\u011b bude v\u00edce pod\u016f.<\/p>\n

To m\u016f\u017ee b\u00fdt probl\u00e9m.<\/p>\n

D\u016fvodem je, \u017ee ka\u017ed\u00fd modul p\u0159in\u00e1\u0161\u00ed ur\u010dit\u00e9 re\u017eijn\u00ed n\u00e1klady na prost\u0159ed\u00ed kontejneru (nap\u0159. Docker), stejn\u011b jako kubelet a cAdvisor.<\/p>\n

Nap\u0159\u00edklad kubelet pravideln\u011b kontroluje \u017eivotnost v\u0161ech kontejner\u016f na uzlu \u2014 \u010d\u00edm v\u00edce kontejner\u016f, t\u00edm v\u00edce pr\u00e1ce m\u00e1 kubelet.<\/p>\n

CAdvisor shroma\u017e\u010fuje statistiky o vyu\u017e\u00edv\u00e1n\u00ed zdroj\u016f v\u0161ech kontejner\u016f na uzlu a kubelet pravideln\u011b vy\u017eaduje tyto informace a poskytuje je prost\u0159ednictv\u00edm API. Znovu, \u010d\u00edm v\u00edce kontejner\u016f, t\u00edm v\u00edce pr\u00e1ce pro cAdvisor i kubelet.<\/p>\n

Pokud se po\u010det modul\u016f zv\u00fd\u0161\u00ed, m\u016f\u017ee to zpomalit syst\u00e9m a dokonce ohrozit jeho spolehlivost.<\/p>\n

\"Pracovn\u00ed
\nV repozit\u00e1\u0159i Kubernetes n\u011bkte\u0159\u00ed si st\u011b\u017eovali<\/a><\/noindex>, \u017ee uzly sk\u00e1\u010dou mezi stavy Ready\/NotReady, proto\u017ee pravideln\u00e9 kontroly kubeletu v\u0161ech kontejner\u016f na uzlu trvaj\u00ed p\u0159\u00edli\u0161 dlouho.
\nZ tohoto d\u016fvodu Kubernetes Doporu\u010duje se um\u00edstit maxim\u00e1ln\u011b 110 pod\u016f na uzel.<\/a><\/noindex>. V z\u00e1vislosti na v\u00fdkonu uzlu m\u016f\u017eete na uzlu provozovat v\u00edce pod\u016f, ale je t\u011b\u017ek\u00e9 p\u0159edpov\u011bd\u011bt, zda se objev\u00ed probl\u00e9my, nebo zda v\u0161e bude fungovat dob\u0159e. Je dobr\u00e9 to nejprve otestovat. <\/p>\n

Nev\u00fdhoda \u010d. 2. Omezen\u00ed replikace<\/b>
\nP\u0159\u00edli\u0161 mal\u00e9 mno\u017estv\u00ed uzl\u016f omezuje efektivn\u00ed m\u00edru replikace aplikac\u00ed. Nap\u0159\u00edklad, pokud m\u00e1te vysoce dostupnou aplikaci s p\u011bti replikami, ale pouze dva uzly, efektivn\u00ed m\u00edra replikace aplikace se sni\u017euje na dv\u011b.<\/p>\n

P\u011bt replik lze rozd\u011blit pouze na dva uzly, a pokud jeden z nich sel\u017ee, okam\u017eit\u011b vy\u0159ad\u00ed n\u011bkolik replik.<\/p>\n

Pokud m\u00e1te p\u011bt uzl\u016f nebo v\u00edce, ka\u017ed\u00e1 replikace bude b\u011b\u017eet na samostatn\u00e9m uzlu a selh\u00e1n\u00ed jednoho uzlu odstran\u00ed nejv\u00fd\u0161e jednu repliku.<\/p>\n

T\u00edmto zp\u016fsobem mohou po\u017eadavky na vysokou dostupnost vy\u017eadovat ur\u010dit\u00e9 minim\u00e1ln\u00ed mno\u017estv\u00ed uzl\u016f v klastru.<\/p>\n

Nev\u00fdhoda \u010d. 3. Hor\u0161\u00ed n\u00e1sledky selh\u00e1n\u00ed<\/b>
\nP\u0159i mal\u00e9m po\u010dtu uzl\u016f nese ka\u017ed\u00e9 selh\u00e1n\u00ed z\u00e1va\u017en\u011bj\u0161\u00ed d\u016fsledky. Nap\u0159\u00edklad, pokud m\u00e1te pouze dva uzly a jeden z nich sel\u017ee, okam\u017eit\u011b zmiz\u00ed polovina va\u0161ich modul\u016f.<\/p>\n

Samoz\u0159ejm\u011b, Kubernetes p\u0159esune pracovn\u00ed z\u00e1t\u011b\u017e ze selh\u00e1vaj\u00edc\u00edho uzlu na jin\u00e9. Ale pokud jich je m\u00e1lo, voln\u00e9 kapacity nemus\u00ed b\u00fdt dost. V d\u016fsledku toho bude \u010d\u00e1st va\u0161ich aplikac\u00ed nedostupn\u00e1, dokud nezvednete selh\u00e1vaj\u00edc\u00ed uzel.<\/p>\n

T\u00edmto zp\u016fsobem, \u010d\u00edm v\u00edce uzl\u016f, t\u00edm men\u0161\u00ed dopad hardwarov\u00fdch selh\u00e1n\u00ed.<\/p>\n

Nev\u00fdhoda \u010d. 4. V\u011bt\u0161\u00ed kroky automatick\u00e9ho \u0161k\u00e1lov\u00e1n\u00ed<\/b>
\nV Kubernetes funguje syst\u00e9m automatick\u00e9ho \u0161k\u00e1lov\u00e1n\u00ed cloudu, kter\u00fd umo\u017e\u0148uje automaticky p\u0159id\u00e1vat nebo odstra\u0148ovat uzly podle aktu\u00e1ln\u00edch pot\u0159eb. U v\u011bt\u0161\u00edch uzl\u016f se \u0161k\u00e1lov\u00e1n\u00ed st\u00e1v\u00e1 razantn\u011bj\u0161\u00edm a neohraban\u00fdm. Nap\u0159\u00edklad p\u0159id\u00e1n\u00ed dal\u0161\u00edho uzlu na dvou uzlech okam\u017eit\u011b zv\u00fd\u0161\u00ed kapacitu cloudu o 50 %. A za tyto zdroje budete muset zaplatit, i kdy\u017e je nepot\u0159ebujete.<\/p>\n

Pokud tedy pl\u00e1nujete vyu\u017e\u00edt automatick\u00e9 \u0161k\u00e1lov\u00e1n\u00ed cloudu, t\u00edm men\u0161\u00ed uzly budou, t\u00edm flexibiln\u011bj\u0161\u00ed a ekonomi\u010dt\u011bj\u0161\u00ed \u0161k\u00e1lov\u00e1n\u00ed z\u00edsk\u00e1te.<\/p>\n

Nyn\u00ed se pod\u00edvejme na v\u00fdhody a nev\u00fdhody velk\u00e9ho mno\u017estv\u00ed mal\u00fdch uzl\u016f.<\/p>\n

Druh\u00e1 mo\u017enost: mno\u017estv\u00ed mal\u00fdch uzl\u016f<\/h2>\n

\nV\u00fdhody tohoto p\u0159\u00edstupu v z\u00e1sad\u011b vypl\u00fdvaj\u00ed z nev\u00fdhod opa\u010dn\u00e9 varianty se n\u011bkolika velk\u00fdmi uzly.<\/p>\n

V\u00fdhody<\/h3>\n

\nPlus \u010d. 1. Men\u0161\u00ed dopad na selh\u00e1n\u00ed<\/b>
\n\u010c\u00edm v\u00edce uzl\u016f m\u00e1te, t\u00edm m\u00e9n\u011b pod\u016f na ka\u017ed\u00e9m uzlu. Nap\u0159\u00edklad, pokud m\u00e1te sto modul\u016f na deset uzl\u016f, pak na ka\u017ed\u00e9m uzlu bude v pr\u016fm\u011bru deset modul\u016f.<\/p>\n

Pokud tedy jeden z uzl\u016f sel\u017ee, ztr\u00e1c\u00edte pouze 10 % pracovn\u00ed z\u00e1t\u011b\u017ee. Existuje pravd\u011bpodobnost, \u017ee bude zasazena jen mal\u00e1 \u010d\u00e1st replik a aplikace z\u016fstanou funk\u010dn\u00ed.<\/p>\n

Krom\u011b toho na zb\u00fdvaj\u00edc\u00edch uzlech pravd\u011bpodobn\u011b z\u016fstanou dostate\u010dn\u00e9 prost\u0159edky pro pracovn\u00ed z\u00e1t\u011b\u017e porouchan\u00e9ho uzlu, tak\u017ee Kubernetes m\u016f\u017ee voln\u011b p\u0159epl\u00e1novat pody, a va\u0161e aplikace se relativn\u011b rychle vr\u00e1t\u00ed do funk\u010dn\u00edho stavu.<\/p>\n

Plus \u010d. 2. Dobr\u00e1 replikace<\/b>
\nPokud je uzl\u016f dostatek, m\u016f\u017ee pl\u00e1nova\u010d Kubernetes p\u0159i\u0159adit v\u0161em replik\u00e1m r\u016fzn\u00e9 uzly. Tak\u017ee v p\u0159\u00edpad\u011b selh\u00e1n\u00ed uzlu bude zasazena pouze jedna replikace, a aplikace z\u016fstane dostupn\u00e1.<\/p>\n

Nev\u00fdhody <\/h3>\n

\nMinus \u010d. 1. Obt\u00ed\u017en\u011bj\u0161\u00ed spr\u00e1va<\/b>
\nS v\u011bt\u0161\u00edm po\u010dtem uzl\u016f je obt\u00ed\u017en\u011bj\u0161\u00ed spr\u00e1va. Nap\u0159\u00edklad ka\u017ed\u00fd uzel Kubernetes mus\u00ed komunikovat se v\u0161emi ostatn\u00edmi, tedy po\u010det vztah\u016f roste kvadraticky a v\u0161echny tyto vztahy je t\u0159eba sledovat.<\/p>\n

Kontrol\u00e9r uzl\u016f v \u0159\u00eddic\u00edm spr\u00e1vci Kubernetes pravideln\u011b proch\u00e1z\u00ed v\u0161echny uzly v cloudu, aby zkontroloval jejich funk\u010dnost \u2014 \u010d\u00edm v\u00edce uzl\u016f, t\u00edm v\u011bt\u0161\u00ed z\u00e1t\u011b\u017e na kontrol\u00e9r.<\/p>\n

Zat\u00ed\u017een\u00ed roste tak\u00e9 na datab\u00e1zi etcd \u2014 ka\u017ed\u00fd kubelet a kube-proxy vol\u00e1 watcher<\/a><\/noindex> pro etcd (p\u0159es API), kter\u00fd mus\u00ed etcd p\u0159en\u00e1\u0161et aktualizace objektu.<\/p>\n

Celkov\u011b ka\u017ed\u00fd pracovn\u00ed uzel vytv\u00e1\u0159\u00ed dodate\u010dnou z\u00e1t\u011b\u017e pro syst\u00e9mov\u00e9 komponenty hlavn\u00edch uzl\u016f.<\/p>\n

\"Pracovn\u00ed
\nOfici\u00e1ln\u011b Kubernetes podporuje clustery s a\u017e 5000 uzly<\/a><\/noindex>. V praxi v\u0161ak ji\u017e 500 uzl\u016f mohou zp\u016fsobit nezanedbateln\u00e9 probl\u00e9my<\/a><\/noindex>.<\/p>\n

Pro spr\u00e1vu velk\u00e9ho po\u010dtu pracovn\u00edch uzl\u016f byste m\u011bli zvolit v\u00fdkonn\u011bj\u0161\u00ed hlavn\u00ed uzly. Nap\u0159\u00edklad kube-up automaticky nainstalov\u00e1v\u00e1<\/a><\/noindex> odpov\u00eddaj\u00edc\u00ed velikost VM pro hlavn\u00ed uzel v z\u00e1vislosti na po\u010dtu pracovn\u00edch uzl\u016f. To znamen\u00e1, \u017ee \u010d\u00edm v\u00edce pracovn\u00edch uzl\u016f, t\u00edm v\u00fdkonn\u011bj\u0161\u00ed by m\u011bly b\u00fdt hlavn\u00ed uzly. <\/p>\n

Pro \u0159e\u0161en\u00ed t\u011bchto specifick\u00fdch probl\u00e9m\u016f existuj\u00ed speci\u00e1ln\u00ed v\u00fdvojov\u00e9 projekty, jako je Virtual Kubelet<\/a><\/noindex>. Tento syst\u00e9m umo\u017e\u0148uje obej\u00edt omezen\u00ed a vytv\u00e1\u0159et clustery s obrovsk\u00fdm po\u010dtem pracovn\u00edch uzl\u016f.<\/p>\n

Nev\u00fdhoda \u010d. 2. V\u011bt\u0161\u00ed re\u017eijn\u00ed n\u00e1klady<\/b>
\nNa ka\u017ed\u00e9m pracovn\u00edm uzlu Kubernetes b\u011b\u017e\u00ed sada syst\u00e9mov\u00fdch d\u00e9mon\u016f \u2014 mezi n\u011b pat\u0159\u00ed runtime kontejneru (nap\u0159. Docker), kube-proxy a kubelet, v\u010detn\u011b cAdvisor. V\u0161echny dohromady spot\u0159ebov\u00e1vaj\u00ed ur\u010dit\u00e9 pevn\u00e9 mno\u017estv\u00ed zdroj\u016f.<\/p>\n

Pokud m\u00e1te mnoho mal\u00fdch uzl\u016f, pod\u00edl t\u011bchto re\u017eijn\u00edch n\u00e1klad\u016f na ka\u017ed\u00e9m uzlu je v\u011bt\u0161\u00ed. Nap\u0159\u00edklad si p\u0159edstavte, \u017ee v\u0161echny syst\u00e9mov\u00e9 d\u00e9mony jednoho uzlu spole\u010dn\u011b pou\u017e\u00edvaj\u00ed 0,1 j\u00e1dra CPU a 0,1 GB pam\u011bti. Pokud m\u00e1te jeden deseti j\u00e1drov\u00fd uzel s 10 GB pam\u011bti, pak d\u00e9moni spot\u0159ebov\u00e1vaj\u00ed 1% kapacity clusteru. Na druh\u00e9 stran\u011b na deseti jedno j\u00e1drov\u00fdch uzlech s 1 GB pam\u011bti si d\u00e9moni vezmou 10% kapacity clusteru.<\/p>\n

T\u00edm p\u00e1dem, \u010d\u00edm m\u00e9n\u011b uzl\u016f, t\u00edm efektivn\u011bji se vyu\u017e\u00edv\u00e1 infrastruktura.<\/p>\n

Nev\u00fdhoda \u010d. 3. Neefektivn\u00ed vyu\u017e\u00edv\u00e1n\u00ed zdroj\u016f<\/b>
\nNa mal\u00fdch uzlech m\u016f\u017ee nastat situace, \u017ee zb\u00fdvaj\u00edc\u00ed fragmenty zdroj\u016f jsou p\u0159\u00edli\u0161 mal\u00e9 na to, aby se jim mohla p\u0159i\u0159adit n\u011bjak\u00e1 pracovn\u00ed z\u00e1t\u011b\u017e, a proto z\u016fst\u00e1vaj\u00ed nevyu\u017eity.<\/p>\n

Nap\u0159\u00edklad ka\u017ed\u00fd pod vy\u017eaduje 0,75 GB pam\u011bti. Pokud m\u00e1te deset uzl\u016f a na ka\u017ed\u00e9m 1 GB pam\u011bti, m\u016f\u017eete spustit deset pod\u016f \u2014 nakonec na ka\u017ed\u00e9m uzlu z\u016fstane 0,25 GB nevyu\u017eit\u00e9 pam\u011bti.<\/p>\n

To znamen\u00e1, \u017ee 25% pam\u011bti cel\u00e9ho clusteru se pl\u00fdtv\u00e1.<\/p>\n

Na velk\u00e9m uzlu s 10 GB pam\u011bti m\u016f\u017eete spustit 13 takov\u00fdch modul\u016f \u2014 a zbude pouze jeden nevyu\u017eit\u00fd fragment 0,25 GB.<\/p>\n

V tomto p\u0159\u00edpad\u011b se pl\u00fdtv\u00e1 pouze 2,5% pam\u011bti.<\/p>\n

Tak\u017ee na velk\u00fdch uzlech jsou zdroje efektivn\u011bji vyu\u017e\u00edv\u00e1ny.<\/p>\n

N\u011bkolik velk\u00fdch uzl\u016f nebo mnoho mal\u00fdch?<\/h2>\n

\nCo je tedy lep\u0161\u00ed: n\u011bkolik velk\u00fdch uzl\u016f v clusteru nebo mnoho mal\u00fdch? Odpov\u011b\u010f nen\u00ed jednozna\u010dn\u00e1. Mnoho z\u00e1vis\u00ed na typu aplikace.<\/p>\n

Nap\u0159\u00edklad, pokud aplikace vy\u017eaduje 10 GB pam\u011bti, je jasnou volbou big nodes. A pokud aplikace vy\u017eaduje desetin\u00e1sobnou replikaci pro vysokou dostupnost, ur\u010dit\u011b nem\u00e1 smysl riskovat a um\u00eds\u0165ovat repliky jen na dvou uzlech \u2014 v clusteru by m\u011blo b\u00fdt minim\u00e1ln\u011b deset uzl\u016f.<\/p>\n

Ve st\u0159edn\u00edch situac\u00edch se rozhodn\u011bte na z\u00e1klad\u011b v\u00fdhod a nev\u00fdhod ka\u017ed\u00e9 varianty. Mo\u017en\u00e1 jsou n\u011bkter\u00e9 argumenty pro va\u0161i situaci relevantn\u011bj\u0161\u00ed ne\u017e jin\u00e9.<\/p>\n

A rozhodn\u011b nen\u00ed nezbytn\u00e9 m\u00edt v\u0161echny uzly stejn\u00e9 velikosti. Nic nebr\u00e1n\u00ed experimentovat nejprve s uzly jedn\u00e9 velikosti a pot\u00e9 k nim p\u0159idat uzly jin\u00e9 velikosti, kombinuj\u00edc\u00ed je v clusteru. Pracovn\u00ed uzly clusteru Kubernetes mohou b\u00fdt zcela heterogenn\u00ed. M\u016f\u017eete tedy vyzkou\u0161et v\u00fdhody obou p\u0159\u00edstup\u016f.<\/p>\n

Neexistuje \u017e\u00e1dn\u00fd univerz\u00e1ln\u00ed recept, ka\u017ed\u00e1 situace m\u00e1 sv\u00e9 nuance a pouze produk\u010dn\u00ed prost\u0159ed\u00ed uk\u00e1\u017ee pravdu.<\/p>\n

P\u0159eklad p\u0159ipravila t\u00fdm cloudov\u00e9 platformy Mail.ru Cloud Solutions<\/a><\/noindex>.<\/i><\/p>\n

Je\u0161t\u011b v\u00edce o Kubernetes: 25 u\u017eite\u010dn\u00fdch n\u00e1stroj\u016f pro spr\u00e1vu a nasazen\u00ed cluster\u016f<\/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\u00ed uzly Kubernetes: mnoho mal\u00fdch nebo n\u011bkolik velk\u00fdch? | ProHoster","description":"P\u0159i vytv\u00e1\u0159en\u00ed clusteru.","canonical_url":"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"cs_CZ","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\/cs\/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\/cs\/wp-json\/wp\/v2\/posts\/56259","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/comments?post=56259"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/posts\/56259\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/media?parent=56259"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/categories?post=56259"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/tags?post=56259"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}