{"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\/pl\/blog\/administrirovanie\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","title":{"rendered":"W\u0119z\u0142y robocze Kubernetes: wiele ma\u0142ych czy kilka du\u017cych?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"W\u0119z\u0142y
\nPodczas tworzenia klastra Kubernetes pojawia si\u0119 wiele pyta\u0144: jak wiele w\u0119z\u0142\u00f3w roboczych skonfigurowa\u0107 i jakiego typu? Co lepiej dla klastra on-premise: zakupi\u0107 kilka wydajnych serwer\u00f3w czy wykorzysta\u0107 dziesi\u0119\u0107 starych maszyn w swoim centrum danych? A w chmurze lepiej wzi\u0105\u0107 osiem jednordzeniowych instancji czy dwie czterordzeniowe? <\/p>\n

Odpowiedzi na te pytania znajduj\u0105 si\u0119 w artykule Daniela Weibel, in\u017cyniera programisty i wyk\u0142adowcy projektu edukacyjnego Learnk8s<\/a><\/noindex> w t\u0142umaczeniu zespo\u0142u Kubernetes aaS od Mail.ru<\/a><\/noindex>.
\n<\/a><\/noindex><\/p>\n

Pojemno\u015b\u0107 klastra<\/h2>\n

\nOg\u00f3lnie rzecz bior\u0105c, klaster Kubernetes mo\u017cna uzna\u0107 za du\u017cy \u201esuperw\u0119ze\u0142\u201d. Jego ca\u0142kowita moc obliczeniowa to suma mocy wszystkich w\u0119z\u0142\u00f3w sk\u0142adowych. <\/p>\n

Istnieje kilka sposob\u00f3w, aby osi\u0105gn\u0105\u0107 po\u017c\u0105dan\u0105 docelow\u0105 pojemno\u015b\u0107 klastra. Na przyk\u0142ad potrzebujemy klastra z ca\u0142kowit\u0105 pojemno\u015bci\u0105 8 rdzeni procesora i 32 GB pami\u0119ci RAM, poniewa\u017c zestaw aplikacji wymaga takiej ilo\u015bci zasob\u00f3w. W\u00f3wczas mo\u017cna skonfigurowa\u0107 dwa w\u0119z\u0142y po 16 GB pami\u0119ci lub cztery w\u0119z\u0142y po 8 GB pami\u0119ci, dwa czterordzeniowe procesory lub cztery dwurdzeniowe.<\/p>\n

Oto tylko dwa mo\u017cliwe sposoby stworzenia klastra:<\/p>\n

\"W\u0119z\u0142y
\nObie opcje daj\u0105 klaster o tej samej pojemno\u015bci, ale w konfiguracji poni\u017cej zainstalowano cztery mniejsze w\u0119z\u0142y, a w konfiguracji powy\u017cej \u2014 dwa wi\u0119ksze. <\/p>\n

Kt\u00f3ra opcja jest lepsza?<\/h3>\n

\nAby odpowiedzie\u0107 na to pytanie, rozwa\u017cmy zalety obu opcji. Zebrali\u015bmy je w tabeli.<\/p>\n

Kilka du\u017cych w\u0119z\u0142\u00f3w<\/p>\n

Wiele ma\u0142ych w\u0119z\u0142\u00f3w<\/p>\n

\u0141atwiejsze zarz\u0105dzanie klastrem (je\u015bli jest on on-premise)<\/p>\n

P\u0142ynne automatyczne skalowanie<\/p>\n

Ta\u0144sze (je\u015bli on-premise) <\/p>\n

Cena niewiele si\u0119 r\u00f3\u017cni (w chmurze) <\/p>\n

Mo\u017cna uruchamia\u0107 zasobo\u017cerne aplikacje <\/p>\n

Pe\u0142na replikacja<\/p>\n

Zasoby s\u0105 wykorzystywane efektywniej (mniejsze obci\u0105\u017cenie na demony systemowe)
\nWy\u017csza odporno\u015b\u0107 klastra na awarie<\/p>\n

Zauwa\u017c, \u017ce m\u00f3wimy tylko o w\u0119z\u0142ach roboczych. Wyb\u00f3r liczby i rozmiaru w\u0119z\u0142\u00f3w g\u0142\u00f3wnych to zupe\u0142nie inny temat.<\/p>\n

Zatem om\u00f3wmy szczeg\u00f3\u0142owo ka\u017cdy punkt z tabeli.<\/p>\n

Pierwsza opcja: kilka du\u017cych w\u0119z\u0142\u00f3w<\/h2>\n

\nNajbardziej ekstremalna opcja \u2014 jeden w\u0119ze\u0142 roboczy na ca\u0142\u0105 pojemno\u015b\u0107 klastra. W powy\u017cszym przyk\u0142adzie by\u0142by to jeden w\u0119ze\u0142 roboczy z 16 rdzeniami CPU i 16 GB pami\u0119ci RAM.<\/p>\n

Zalety <\/h3>\n

\nZaleta nr 1. \u0141atwiejsze zarz\u0105dzanie<\/b>
\n\u0141atwiej jest zarz\u0105dza\u0107 wieloma maszynami ni\u017c ca\u0142ym parkiem. Szybciej wdra\u017ca\u0107 aktualizacje i poprawki, \u0142atwiej synchronizowa\u0107. Ilo\u015b\u0107 awarii w liczbach bezwzgl\u0119dnych r\u00f3wnie\u017c jest mniejsza.<\/p>\n

Zauwa\u017c, \u017ce wszystko, co powiedziano powy\u017cej, odnosi si\u0119 do w\u0142asnego sprz\u0119tu, w\u0142asnych serwer\u00f3w, a nie do instancji w chmurze.<\/p><\/blockquote>\n

\nW chmurze sytuacja jest inna. Zarz\u0105dzaniem zajmuje si\u0119 dostawca us\u0142ug chmurowych. W ten spos\u00f3b zarz\u0105dzanie dziesi\u0119cioma w\u0119z\u0142ami w chmurze niewiele r\u00f3\u017cni si\u0119 od zarz\u0105dzania jednym w\u0119z\u0142em.<\/p>\n

Routing ruchu i rozk\u0142adanie obci\u0105\u017cenia mi\u0119dzy podami w chmurze jest realizowane automatycznie<\/a><\/noindex>: przychodz\u0105cy z internetu ruch jest kierowany na g\u0142\u00f3wny load balancer, kt\u00f3ry kieruje ruch na port jednego z w\u0119z\u0142\u00f3w (us\u0142uga NodePort udost\u0119pnia port w zakresie 30000-32767 w ka\u017cdym w\u0119\u017ale klastra). Regu\u0142y ustalone przez kube-proxy przekierowuj\u0105 ruch z w\u0119z\u0142a do poda. Oto jak to wygl\u0105da dla dziesi\u0119ciu pod\u00f3w w dw\u00f3ch w\u0119z\u0142ach:<\/p>\n

\"W\u0119z\u0142y
\nZaleta nr 2. Mniejsze koszty na w\u0119ze\u0142<\/b>
\nMocna maszyna jest dro\u017csza, ale wzrost ceny nie musi by\u0107 liniowy. Innymi s\u0142owy, jeden dziesi\u0119ciordzeniowy serwer z 10 GB pami\u0119ci zazwyczaj kosztuje mniej ni\u017c dziesi\u0119\u0107 jedno rdzeniowych z t\u0105 sam\u0105 ilo\u015bci\u0105 pami\u0119ci.<\/p>\n

Ale pami\u0119taj, \u017ce ta zasada zwykle nie dzia\u0142a w chmurze. W obecnych schematach cenowych wszystkich g\u0142\u00f3wnych dostawc\u00f3w chmur ceny rosn\u0105 liniowo z zwi\u0119kszeniem pojemno\u015bci.<\/p><\/blockquote>\n

\nW zwi\u0105zku z tym w chmurze zazwyczaj nie da si\u0119 zaoszcz\u0119dzi\u0107 na bardziej wydajnych serwerach.<\/p>\n

Zaleta nr 3. Mo\u017cna uruchamia\u0107 zasobo\u017cerne aplikacje<\/b>
\nNiekt\u00f3re aplikacje wymagaj\u0105 mocnych serwer\u00f3w w klastrze. Na przyk\u0142ad, je\u015bli system uczenia maszynowego wymaga 8 GB pami\u0119ci, nie b\u0119dziesz m\u00f3g\u0142 uruchomi\u0107 go na w\u0119z\u0142ach po 1 GB, a jedynie przy obecno\u015bci co najmniej jednego du\u017cego w\u0119z\u0142a roboczego.<\/p>\n

Minusy <\/h3>\n

\n\u041c\u0438\u043d\u0443\u0441 \u2116 1. \u041c\u043d\u043e\u0433\u043e pod’\u043e\u0432 \u043d\u0430 \u0443\u0437\u0435\u043b<\/b>
\n\u0415\u0441\u043b\u0438 \u043e\u0434\u043d\u0430 \u0438 \u0442\u0430 \u0436\u0435 \u0437\u0430\u0434\u0430\u0447\u0430 \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u0435\u0442\u0441\u044f \u043d\u0430 \u043c\u0435\u043d\u044c\u0448\u0435\u043c \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u0435 \u0443\u0437\u043b\u043e\u0432, \u0442\u043e \u043d\u0430 \u043a\u0430\u0436\u0434\u043e\u043c \u0438\u0437 \u043d\u0438\u0445, \u0435\u0441\u0442\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e, \u0431\u0443\u0434\u0435\u0442 \u0431\u043e\u043b\u044c\u0448\u0435 pod’\u043e\u0432.<\/p>\n

Mo\u017ce to sta\u0107 si\u0119 problemem.<\/p>\n

Powodem jest to, \u017ce ka\u017cdy modu\u0142 wprowadza pewne narzuty na \u015brodowisko uruchomieniowe kontenera (na przyk\u0142ad Docker), a tak\u017ce kubelet i cAdvisor.<\/p>\n

Na przyk\u0142ad kubelet regularnie sondowa\u0142 wszystkie kontenery na w\u0119\u017ale pod k\u0105tem \u017cywotno\u015bci - im wi\u0119cej kontener\u00f3w, tym wi\u0119cej pracy dla kubelet.<\/p>\n

CAdvisor zbiera statystyki wykorzystania zasob\u00f3w wszystkich kontener\u00f3w na w\u0119\u017ale, a kubelet regularnie \u017c\u0105da tych informacji i udost\u0119pnia je przez API. Znowu, im wi\u0119cej kontener\u00f3w, tym wi\u0119cej pracy zar\u00f3wno dla cAdvisor, jak i kubelet.<\/p>\n

Je\u015bli liczba modu\u0142\u00f3w wzro\u015bnie, mo\u017ce to spowolni\u0107 system, a nawet podwa\u017cy\u0107 jego niezawodno\u015b\u0107.<\/p>\n

\"W\u0119z\u0142y
\nW repozytorium Kubernetes niekt\u00f3rzy skar\u017cyli si\u0119<\/a><\/noindex>, \u017ce w\u0119z\u0142y skacz\u0105 mi\u0119dzy statusami Ready\/NotReady, poniewa\u017c regularne kontrole kubelet wszystkich kontener\u00f3w na w\u0119\u017ale zajmuj\u0105 zbyt du\u017co czasu.
\nZ tego powodu Kubernetes \u0440\u0435\u043a\u043e\u043c\u0435\u043d\u0434\u0443\u0435\u0442 \u0440\u0430\u0437\u043c\u0435\u0449\u0430\u0442\u044c \u043d\u0435 \u0431\u043e\u043b\u0435\u0435 110 pod’\u043e\u0432 \u043d\u0430 \u0443\u0437\u0435\u043b<\/a><\/noindex>. W zale\u017cno\u015bci od wydajno\u015bci w\u0119z\u0142a mo\u017cesz uruchomi\u0107 wi\u0119cej pod\u00f3w na w\u0119ze\u0142, ale trudno przewidzie\u0107, czy pojawi\u0105 si\u0119 problemy, czy wszystko b\u0119dzie dzia\u0142a\u0107 dobrze. Warto przetestowa\u0107 dzia\u0142anie z wyprzedzeniem. <\/p>\n

Minus \u2116 2. Ograniczenie na replikacj\u0119<\/b>
\nZbyt ma\u0142a liczba w\u0119z\u0142\u00f3w ogranicza efektywny stopie\u0144 replikacji aplikacji. Na przyk\u0142ad, je\u015bli masz aplikacj\u0119 o wysokiej dost\u0119pno\u015bci z pi\u0119cioma replikami, ale tylko dwa w\u0119z\u0142y, to efektywny stopie\u0144 replikacji aplikacji zmniejsza si\u0119 do dw\u00f3ch.<\/p>\n

Pi\u0119\u0107 replik mo\u017cna roz\u0142o\u017cy\u0107 tylko na dwa w\u0119z\u0142y, a je\u015bli jeden z nich przestaje dzia\u0142a\u0107, natychmiast wy\u0142\u0105cza kilka replik.<\/p>\n

Je\u015bli masz pi\u0119\u0107 w\u0119z\u0142\u00f3w lub wi\u0119cej, ka\u017cda replika b\u0119dzie dzia\u0142a\u0107 na osobnym w\u0119\u017ale, a awaria jednego w\u0119z\u0142a usunie maksymalnie jedn\u0105 replik\u0119.<\/p>\n

W ten spos\u00f3b wymagania dotycz\u0105ce wysokiej dost\u0119pno\u015bci mog\u0105 wymaga\u0107 posiadania okre\u015blonej minimalnej liczby w\u0119z\u0142\u00f3w w klastrze.<\/p>\n

Minus \u2116 3. Gorsze konsekwencje awarii<\/b>
\nPrzy ma\u0142ej liczbie w\u0119z\u0142\u00f3w ka\u017cda awaria niesie powa\u017cniejsze konsekwencje. Na przyk\u0142ad, je\u015bli masz tylko dwa w\u0119z\u0142y, a jeden z nich przestaje dzia\u0142a\u0107, natychmiast znika po\u0142owa twoich modu\u0142\u00f3w.<\/p>\n

Oczywi\u015bcie Kubernetes przeniesie obci\u0105\u017cenie z uszkodzonego w\u0119z\u0142a na inne. Ale je\u015bli ich jest ma\u0142o, to mo\u017ce zabrakn\u0105\u0107 wolnej pojemno\u015bci. W rezultacie cz\u0119\u015b\u0107 twoich aplikacji stanie si\u0119 niedost\u0119pna, dop\u00f3ki nie uruchomisz uszkodzonego w\u0119z\u0142a.<\/p>\n

W ten spos\u00f3b im wi\u0119cej w\u0119z\u0142\u00f3w \u2014 tym mniejsze skutki awarii sprz\u0119towych.<\/p>\n

Minus \u2116 4. Wi\u0119ksze kroki automatycznego skalowania<\/b>
\nW Kubernetes dzia\u0142a system automatycznego skalowania klastra dla infrastruktury chmurowej, co pozwala na automatyczne dodawanie lub usuwanie w\u0119z\u0142\u00f3w w zale\u017cno\u015bci od bie\u017c\u0105cych potrzeb. W przypadku du\u017cych w\u0119z\u0142\u00f3w automatyczne skalowanie staje si\u0119 bardziej gwa\u0142towne i niepor\u0119czne. Na przyk\u0142ad, w przypadku dw\u00f3ch w\u0119z\u0142\u00f3w, dodanie dodatkowego w\u0119z\u0142a zwi\u0119kszy pojemno\u015b\u0107 klastra o 50%. I b\u0119dziesz musia\u0142 zap\u0142aci\u0107 za te zasoby, nawet je\u015bli nie s\u0105 Ci potrzebne.<\/p>\n

Dlatego je\u015bli planujesz korzysta\u0107 z automatycznego skalowania klastra, to im mniejsze w\u0119z\u0142y \u2014 tym bardziej elastyczne i oszcz\u0119dne skalowanie uzyskasz.<\/p>\n

Teraz przyjrzyjmy si\u0119 zaletom i wadom du\u017cej liczby ma\u0142ych w\u0119z\u0142\u00f3w.<\/p>\n

Druga opcja: wiele ma\u0142ych w\u0119z\u0142\u00f3w<\/h2>\n

\nZalety tego podej\u015bcia zasadniczo wynikaj\u0105 z wad przeciwnego wariantu z kilkoma du\u017cymi w\u0119z\u0142ami.<\/p>\n

Zalety<\/h3>\n

\nZaleta nr 1. Mniejsze skutki awarii<\/b>
\n\u0427\u0435\u043c \u0431\u043e\u043b\u044c\u0448\u0435 \u0443\u0437\u043b\u043e\u0432, \u0442\u0435\u043c \u043c\u0435\u043d\u044c\u0448\u0435 pod’\u043e\u0432 \u043d\u0430 \u043a\u0430\u0436\u0434\u043e\u043c \u0443\u0437\u043b\u0435. \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u0435\u0441\u043b\u0438 \u0443 \u0432\u0430\u0441 \u0441\u0442\u043e \u043c\u043e\u0434\u0443\u043b\u0435\u0439 \u043d\u0430 \u0434\u0435\u0441\u044f\u0442\u044c \u0443\u0437\u043b\u043e\u0432, \u0442\u043e \u043d\u0430 \u043a\u0430\u0436\u0434\u043e\u043c \u0443\u0437\u043b\u0435 \u0431\u0443\u0434\u0435\u0442 \u0432 \u0441\u0440\u0435\u0434\u043d\u0435\u043c \u043f\u043e \u0434\u0435\u0441\u044f\u0442\u044c \u043c\u043e\u0434\u0443\u043b\u0435\u0439.<\/p>\n

W zwi\u0105zku z tym, je\u015bli jeden z w\u0119z\u0142\u00f3w ulegnie awarii, tracisz tylko 10% obci\u0105\u017cenia roboczego. Istnieje prawdopodobie\u0144stwo, \u017ce dotkni\u0119te zostan\u0105 tylko nieliczne replikaty, a aplikacje w og\u00f3le pozostan\u0105 w dzia\u0142aniu.<\/p>\n

\u041a\u0440\u043e\u043c\u0435 \u0442\u043e\u0433\u043e, \u043d\u0430 \u043e\u0441\u0442\u0430\u0432\u0448\u0438\u0445\u0441\u044f \u0443\u0437\u043b\u0430\u0445, \u0441\u043a\u043e\u0440\u0435\u0435 \u0432\u0441\u0435\u0433\u043e, \u0445\u0432\u0430\u0442\u0438\u0442 \u0441\u0432\u043e\u0431\u043e\u0434\u043d\u044b\u0445 \u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432 \u0434\u043b\u044f \u0440\u0430\u0431\u043e\u0447\u0435\u0439 \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0438 \u043e\u0442\u043a\u0430\u0437\u0430\u0432\u0448\u0435\u0433\u043e \u0443\u0437\u043b\u0430, \u0442\u0430\u043a \u0447\u0442\u043e Kubernetes \u043c\u043e\u0436\u0435\u0442 \u0441\u0432\u043e\u0431\u043e\u0434\u043d\u043e \u043f\u0435\u0440\u0435\u043f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u0442\u044c pod’\u044b, \u0438 \u0432\u0430\u0448\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u043e\u0442\u043d\u043e\u0441\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0431\u044b\u0441\u0442\u0440\u043e \u0432\u0435\u0440\u043d\u0443\u0442\u0441\u044f \u0432 \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u043e\u0435 \u0441\u043e\u0441\u0442\u043e\u044f\u043d\u0438\u0435.<\/p>\n

Zaleta nr 2. Dobra replikacja<\/b>
\nJe\u015bli w\u0119z\u0142\u00f3w jest wystarczaj\u0105co du\u017co, to scheduler Kubernetes mo\u017ce przydzieli\u0107 wszystkim replikom r\u00f3\u017cne w\u0119z\u0142y. W ten spos\u00f3b, w przypadku awarii w\u0119z\u0142a, dotkni\u0119ta zostanie tylko jedna replikacja, a aplikacja pozostanie dost\u0119pna.<\/p>\n

Minusy <\/h3>\n

\nWada nr 1. Trudniejsze zarz\u0105dzanie<\/b>
\nZarz\u0105dzanie du\u017c\u0105 liczb\u0105 w\u0119z\u0142\u00f3w jest trudniejsze. Na przyk\u0142ad ka\u017cdy w\u0119ze\u0142 Kubernetes musi komunikowa\u0107 si\u0119 ze wszystkimi innymi, to znaczy liczba po\u0142\u0105cze\u0144 ro\u015bnie kwadratowo, i wszystkie te po\u0142\u0105czenia trzeba \u015bledzi\u0107.<\/p>\n

Kontroler w\u0119z\u0142\u00f3w w mened\u017cerze kontroler\u00f3w Kubernetes regularnie przeszukuje wszystkie w\u0119z\u0142y w klastrze w celu sprawdzenia ich stanu \u2014 im wi\u0119cej w\u0119z\u0142\u00f3w, tym wi\u0119ksze obci\u0105\u017cenie dla kontrolera.<\/p>\n

Obci\u0105\u017cenie wzrasta r\u00f3wnie\u017c na bazie danych etcd \u2014 ka\u017cdy kubelet i kube-proxy wywo\u0142uj\u0105 watcher<\/a><\/noindex> dla etcd (przez API), kt\u00f3remu etcd ma transmitowa\u0107 aktualizacje obiektu.<\/p>\n

Og\u00f3lnie ka\u017cdy w\u0119ze\u0142 roboczy nak\u0142ada dodatkowe obci\u0105\u017cenie na komponenty systemowe g\u0142\u00f3wnych w\u0119z\u0142\u00f3w.<\/p>\n

\"W\u0119z\u0142y
\nOficjalnie Kubernetes wspiera klastry z liczb\u0105 w\u0119z\u0142\u00f3w do 5000<\/a><\/noindex>. Jednak w praktyce ju\u017c 500 w\u0119z\u0142\u00f3w mo\u017ce powodowa\u0107 niewielkie problemy<\/a><\/noindex>.<\/p>\n

Aby zarz\u0105dza\u0107 du\u017c\u0105 liczb\u0105 w\u0119z\u0142\u00f3w roboczych, nale\u017cy wybiera\u0107 bardziej wydajne g\u0142\u00f3wne w\u0119z\u0142y. Na przyk\u0142ad kube-up automatycznie instaluje<\/a><\/noindex> odpowiedni rozmiar VM dla g\u0142\u00f3wnego w\u0119z\u0142a w zale\u017cno\u015bci od liczby w\u0119z\u0142\u00f3w roboczych. To znaczy, im wi\u0119cej w\u0119z\u0142\u00f3w roboczych, tym wydajniejsze powinny by\u0107 g\u0142\u00f3wne w\u0119z\u0142y. <\/p>\n

W celu rozwi\u0105zania tych specyficznych problem\u00f3w istniej\u0105 specjalne rozwi\u0105zania, takie jak Virtual Kubelet<\/a><\/noindex>. Ten system pozwala obej\u015b\u0107 ograniczenia i budowa\u0107 klastry z ogromn\u0105 liczb\u0105 w\u0119z\u0142\u00f3w roboczych.<\/p>\n

Minus nr 2. Wi\u0119ksze koszty og\u00f3lne<\/b>
\nNa ka\u017cdym w\u0119\u017ale roboczym Kubernetes uruchamia zestaw demon\u00f3w systemowych \u2014 nale\u017c\u0105 do nich \u015brodowisko uruchomieniowe kontener\u00f3w (np. Docker), kube-proxy i kubelet, w tym cAdvisor. W sumie zu\u017cywaj\u0105 okre\u015blon\u0105, sta\u0142\u0105 ilo\u015b\u0107 zasob\u00f3w.<\/p>\n

Je\u015bli masz wiele ma\u0142ych w\u0119z\u0142\u00f3w, udzia\u0142 tych koszt\u00f3w og\u00f3lnych na ka\u017cdym w\u0119\u017ale jest wi\u0119kszy. Na przyk\u0142ad wyobra\u017a sobie, \u017ce wszystkie demony systemowe jednego w\u0119z\u0142a razem zu\u017cywaj\u0105 0,1 rdzenia CPU i 0,1 GB pami\u0119ci. Je\u015bli masz jeden dziesi\u0119cio-rdzeniowy w\u0119ze\u0142 z 10 GB pami\u0119ci, demony zu\u017cywaj\u0105 1% pojemno\u015bci klastra. Z drugiej strony, na dziesi\u0119ciu jedno-rdzeniowych w\u0119z\u0142ach po 1 GB pami\u0119ci demony zabieraj\u0105 10% pojemno\u015bci klastra.<\/p>\n

Tak wi\u0119c, im mniej w\u0119z\u0142\u00f3w, tym efektywniej wykorzystywana jest infrastruktura.<\/p>\n

Minus nr 3. Nieefektywne wykorzystanie zasob\u00f3w<\/b>
\nNa ma\u0142ych w\u0119z\u0142ach mo\u017ce powsta\u0107 sytuacja, w kt\u00f3rej pozosta\u0142e fragmenty zasob\u00f3w s\u0105 zbyt ma\u0142e, aby przydzieli\u0107 im jakiekolwiek obci\u0105\u017cenie robocze, dlatego pozostaj\u0105 nieu\u017cywane.<\/p>\n

\u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u043a\u0430\u0436\u0434\u044b\u0439 pod \u0442\u0440\u0435\u0431\u0443\u0435\u0442 0,75 \u0413\u0411 \u043f\u0430\u043c\u044f\u0442\u0438. \u0415\u0441\u043b\u0438 \u0443 \u0432\u0430\u0441 \u0434\u0435\u0441\u044f\u0442\u044c \u0443\u0437\u043b\u043e\u0432, \u0438 \u043d\u0430 \u043a\u0430\u0436\u0434\u043e\u043c \u043f\u043e 1 \u0413\u0411 \u043f\u0430\u043c\u044f\u0442\u0438, \u043c\u043e\u0436\u043d\u043e \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0434\u0435\u0441\u044f\u0442\u044c pod’\u043e\u0432 \u2014 \u0432 \u0438\u0442\u043e\u0433\u0435 \u043d\u0430 \u043a\u0430\u0436\u0434\u043e\u043c \u0443\u0437\u043b\u0435 \u043e\u0441\u0442\u0430\u043d\u0435\u0442\u0441\u044f 0,25 \u0413\u0411 \u043d\u0435\u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c\u043e\u0439 \u043f\u0430\u043c\u044f\u0442\u0438.<\/p>\n

To oznacza, \u017ce 25% pami\u0119ci ca\u0142ego klastra jest marnowane.<\/p>\n

Na du\u017cym w\u0119\u017ale z 10 GB pami\u0119ci mo\u017cesz uruchomi\u0107 13 takich modu\u0142\u00f3w \u2014 i pozostanie tylko jeden niewykorzystany fragment 0,25 GB.<\/p>\n

W takim przypadku marnuje si\u0119 tylko 2,5% pami\u0119ci.<\/p>\n

W ten spos\u00f3b zasoby s\u0105 efektywniej wykorzystywane na du\u017cych w\u0119z\u0142ach.<\/p>\n

Kilka du\u017cych w\u0119z\u0142\u00f3w czy wiele ma\u0142ych?<\/h2>\n

\nCo wi\u0119c jest lepsze: kilka du\u017cych w\u0119z\u0142\u00f3w w klastrze czy wiele ma\u0142ych? Jak zawsze, nie ma jednoznacznej odpowiedzi. Wiele zale\u017cy od rodzaju aplikacji.<\/p>\n

Na przyk\u0142ad, je\u015bli aplikacja wymaga 10 GB pami\u0119ci, wyb\u00f3r du\u017cych w\u0119z\u0142\u00f3w jest oczywisty. Je\u015bli jednak aplikacja wymaga dziesi\u0119ciokrotnej replikacji dla wysokiej dost\u0119pno\u015bci, nie warto ryzykowa\u0107, umieszczaj\u0105c repliki na tylko dw\u00f3ch w\u0119z\u0142ach \u2014 w klastrze powinno by\u0107 co najmniej dziesi\u0119\u0107 w\u0119z\u0142\u00f3w.<\/p>\n

W sytuacjach po\u015brednich podejmij decyzj\u0119 na podstawie zalet i wad ka\u017cdego rozwi\u0105zania. By\u0107 mo\u017ce niekt\u00f3re argumenty s\u0105 bardziej aktualne w twojej sytuacji ni\u017c inne.<\/p>\n

Nie ma r\u00f3wnie\u017c konieczno\u015bci, aby wszystkie w\u0119z\u0142y mia\u0142y ten sam rozmiar. Nic nie stoi na przeszkodzie, aby eksperymentowa\u0107 najpierw z w\u0119z\u0142ami o tym samym rozmiarze, a potem doda\u0107 do nich w\u0119z\u0142y o innym rozmiarze, \u0142\u0105cz\u0105c je w klastrze. W\u0119z\u0142y robocze klastra Kubernetes mog\u0105 by\u0107 ca\u0142kowicie heterogeniczne. Mo\u017cna wi\u0119c spr\u00f3bowa\u0107 po\u0142\u0105czy\u0107 zalety obu podej\u015b\u0107.<\/p>\n

Nie ma jednego uniwersalnego przepisu, ka\u017cda sytuacja ma swoje niuanse, a tylko produkcja poka\u017ce prawd\u0119.<\/p>\n

T\u0142umaczenie przygotowane przez zesp\u00f3\u0142 platformy chmurowej Mail.ru Cloud Solutions<\/a><\/noindex>.<\/i><\/p>\n

Jeszcze o Kubernetes: 25 przydatnych narz\u0119dzi do zarz\u0105dzania i wdra\u017cania klastr\u00f3w<\/a><\/noindex>.<\/p>\n

\u0179r\u00f3d\u0142o: 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\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\udd47 W\u0119z\u0142y robocze Kubernetes: wiele ma\u0142ych czy kilka du\u017cych? | ProHoster","description":"Podczas tworzenia klastra.","canonical_url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/rabochie-uzly-kubernetes-mnogo-malenkih-ili-neskolko-bolshih","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pl_PL","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\/pl\/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\/pl\/wp-json\/wp\/v2\/posts\/56259","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/comments?post=56259"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/56259\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=56259"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=56259"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=56259"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}