Kapag gumagawa ng Kubernetes cluster, maaaring lumabas ang mga tanong: ilang worker node ang iko-configure at anong uri? Ano ang mas mahusay para sa isang nasa nasasakupan na cluster: bumili ng ilang makapangyarihang server o gumamit ng isang dosenang lumang machine sa iyong data center? Mas mainam bang kumuha ng walong single-core o dalawang quad-core na instance sa cloud?
Ang mga sagot sa mga tanong na ito ay nasa artikulo. sa pagsasalin ng utos .
Kapasidad ng cluster
Sa pangkalahatan, ang isang Kubernetes cluster ay maaaring isipin bilang isang malaking "supernode". Ang kabuuang kapangyarihan nito sa pag-compute ay ang kabuuan ng mga kapangyarihan ng lahat ng mga node ng bumubuo nito.
Mayroong ilang mga paraan upang makamit ang iyong ninanais na target na kapasidad ng cluster. Halimbawa, kailangan namin ng isang cluster na may kabuuang kapasidad na 8 mga core ng processor at 32 GB ng RAM dahil ang isang hanay ng mga application ay nangangailangan ng napakaraming mapagkukunan. Pagkatapos ay maaari kang mag-install ng dalawang node na may 16 GB ng memorya o apat na node na may 8 GB ng memorya, dalawang quad-core na processor o apat na dual-core.
Narito ang dalawang posibleng paraan para gumawa ng cluster:
Ang parehong mga opsyon ay gumagawa ng isang cluster na may parehong kapasidad, ngunit ang ilalim na configuration ay may apat na mas maliit na node at ang tuktok na configuration ay may dalawang mas malaking node.
Aling pagpipilian ang mas mahusay?
Upang masagot ang tanong na ito, tingnan natin ang mga pakinabang ng parehong mga pagpipilian. Binubuod namin ang mga ito sa isang talahanayan.
Maraming malalaking node
Maraming maliliit na node
Mas madaling pamamahala ng cluster (kung nasa lugar ito)
Makinis na autoscaling
Mas mura (kung nasa lugar)
Medyo naiiba ang presyo (sa cloud)
Maaaring magpatakbo ng mga resource-intensive na application
Buong pagtitiklop
Ang mga mapagkukunan ay ginagamit nang mas mahusay (mas kaunting overhead sa mga daemon ng system
Mas mataas na cluster fault tolerance
Pakitandaan na ang pinag-uusapan lang natin ay tungkol sa mga worker node. Ang pagpili ng bilang at laki ng mga pangunahing node ay isang ganap na naiibang paksa.
Kaya, talakayin natin ang bawat punto mula sa talahanayan nang mas detalyado.
Unang pagpipilian: maraming malalaking node
Ang pinaka-matinding opsyon ay isang worker node para sa buong kapasidad ng cluster. Sa halimbawa sa itaas, ito ay magiging isang solong worker node na may 16 na CPU core at 16 GB ng RAM.
Pros
Plus No. 1. Mas madaling pamamahala
Mas madaling pamahalaan ang ilang mga makina kaysa sa isang buong fleet. Mas mabilis na maglunsad ng mga update at pag-aayos, at mas madaling i-synchronize. Ang bilang ng mga pagkabigo sa ganap na mga numero ay mas kaunti din.
Pakitandaan na ang lahat ng nasa itaas ay nalalapat sa iyong hardware, sa iyong mga server, at hindi sa cloud instance.
Iba ang sitwasyon sa ulap. Doon, pinangangasiwaan ng cloud service provider ang pamamahala. Kaya, ang pamamahala ng sampung node sa cloud ay hindi gaanong naiiba sa pamamahala ng isang node.
Pagruruta ng trapiko at pamamahagi ng pagkarga sa pagitan ng mga pod sa cloud : ang trapiko na nagmumula sa Internet ay ipinadala sa pangunahing load balancer, na nagpapasa ng trapiko sa port ng isa sa mga node (ang serbisyo ng NodePort ay nagtatakda ng port sa hanay na 30000-32767 sa bawat cluster node). Ang mga panuntunang itinakda ng kube-proxy ay nagre-redirect ng trapiko mula sa node patungo sa pod. Narito ang hitsura ng sampung pod sa dalawang node:
Pro #2: Mas kaunting gastos sa bawat node
Ang isang malakas na kotse ay mas mahal, ngunit ang pagtaas ng presyo ay hindi kinakailangang linear. Sa madaling salita, ang isang sampung-core server na may 10 GB ng memorya ay karaniwang mas mura kaysa sa sampung single-core server na may parehong dami ng memorya.
Ngunit tandaan na ang panuntunang ito ay hindi karaniwang gumagana sa mga serbisyo ng cloud. Sa kasalukuyang mga scheme ng pagpepresyo ng lahat ng pangunahing tagapagbigay ng ulap, ang mga presyo ay tumataas nang linear na may kapasidad.
Kaya, sa cloud ay karaniwang hindi ka makakatipid sa mas malakas na mga server.
Pro #3: Maaari kang magpatakbo ng mga resource-intensive na application
Ang ilang mga application ay nangangailangan ng makapangyarihang mga server sa isang kumpol. Halimbawa, kung ang isang machine learning system ay nangangailangan ng 8 GB ng memorya, hindi mo ito magagawang patakbuhin sa 1 GB na mga node, ngunit may kahit man lang isang malaking worker node.
Cons
Disadvantage No. 1. Maraming pod bawat node
Kung ang parehong gawain ay ginagawa sa mas kaunting mga node, ang bawat isa sa kanila ay natural na magkakaroon ng mas maraming pod.
Ito ay maaaring isang problema.
Ang dahilan ay ang bawat module ay nagpapakilala ng ilang overhead sa container runtime (hal. Docker), pati na rin ang kubelet at cAdvisor.
Halimbawa, regular na sinusuri ng kubelet ang lahat ng container sa isang node para sa survivabilityβmas maraming container, mas maraming trabaho ang kailangang gawin ng kubelet.
Kinokolekta ng CAdvisor ang mga istatistika ng paggamit ng mapagkukunan para sa lahat ng mga container sa isang node, at regular na tinatanong ng kubelet ang impormasyong ito at ibinibigay ito sa pamamagitan ng isang API. Muli, ang mas maraming container ay nangangahulugan ng mas maraming trabaho para sa parehong cAdvisor at kubelet.
Kung tataas ang bilang ng mga module, maaari nitong pabagalin ang system at masira pa ang pagiging maaasahan nito.
Sa repositoryo ng Kubernetes ilan na ang mga node ay tumatalon sa pagitan ng mga status na Ready/NotReady dahil masyadong mahaba ang mga regular na pagsusuri ng kubelet sa lahat ng container sa isang node.
Para sa kadahilanang ito Kubernetes . Depende sa pagganap ng node, maaari kang magpatakbo ng higit pang mga pod sa bawat node, ngunit mahirap hulaan kung magkakaroon ng mga problema o lahat ay gagana nang maayos. Ito ay nagkakahalaga ng pagsubok sa trabaho nang maaga.
Disadvantage No. 2. Limitasyon sa pagtitiklop
Masyadong kaunting mga node ang naglilimita sa epektibong lawak ng pagtitiklop ng aplikasyon. Halimbawa, kung mayroon kang mataas na kakayahang magamit na application na may limang replika ngunit dalawang node lamang, ang epektibong antas ng pagtitiklop ng application ay mababawasan sa dalawa.
Ang limang replika ay maaari lamang ipamahagi sa dalawang node, at kung mabibigo ang isa sa mga ito, aalisin nito ang maramihang mga replika nang sabay-sabay.
Kung mayroon kang limang node o higit pa, ang bawat replica ay tatakbo sa isang hiwalay na node, at ang pagkabigo ng isang node ay mag-aalis ng hindi hihigit sa isang replica.
Kaya, ang mga kinakailangan sa mataas na availability ay maaaring mangailangan ng partikular na minimum na bilang ng mga node sa cluster.
Disadvantage No. 3. Mas masahol na kahihinatnan ng pagkabigo
Sa isang maliit na bilang ng mga node, ang bawat pagkabigo ay may mas malubhang kahihinatnan. Halimbawa, kung mayroon ka lang dalawang node at nabigo ang isa sa mga ito, mawawala kaagad ang kalahati ng iyong mga module.
Siyempre, ililipat ng Kubernetes ang workload mula sa nabigong node patungo sa iba. Ngunit kung kakaunti ang mga ito, maaaring walang sapat na libreng kapasidad. Bilang resulta, ang ilan sa iyong mga application ay hindi magagamit hanggang sa ilabas mo ang nabigong node.
Kaya, mas maraming node, mas mababa ang epekto ng mga pagkabigo sa hardware.
Disadvantage #4: Higit pang mga hakbang sa autoscaling
Ang Kubernetes ay may cluster auto-scaling system para sa cloud infrastructure, na nagbibigay-daan sa iyong awtomatikong magdagdag o mag-alis ng mga node depende sa iyong kasalukuyang mga pangangailangan. Sa mas malalaking node, nagiging mas biglaan at clunky ang autoscaling. Halimbawa, sa dalawang node, ang pagdaragdag ng karagdagang node ay agad na magtataas ng kapasidad ng kumpol ng 50%. At kailangan mong magbayad para sa mga mapagkukunang iyon, kahit na hindi mo kailangan ang mga ito.
Kaya, kung plano mong gumamit ng awtomatikong cluster scaling, mas maliit ang mga node, mas flexible at cost-effective na scaling ang makukuha mo.
Ngayon tingnan natin ang mga pakinabang at disadvantages ng isang malaking bilang ng mga maliliit na node.
Pangalawang opsyon: maraming maliliit na node
Ang mga bentahe ng diskarteng ito ay mahalagang nagmumula sa mga disadvantages ng kabaligtaran na opsyon na may ilang malalaking node.
Pros
Pro #1: Mas kaunting epekto ng pagkabigo
Ang mas maraming node, mas kaunting mga pod sa bawat node. Halimbawa, kung mayroon kang isang daang module sa bawat sampung node, ang bawat node ay magkakaroon ng average na sampung module.
Sa ganitong paraan, kung nabigo ang isa sa mga node, mawawalan ka lang ng 10% ng workload. Malamang na maliit na bilang lamang ng mga replika ang maaapektuhan at ang pangkalahatang aplikasyon ay mananatiling gumagana.
Bukod pa rito, ang natitirang mga node ay malamang na magkakaroon ng sapat na libreng mapagkukunan upang mahawakan ang workload ng nabigong node, kaya maaaring malayang iiskedyul ng Kubernetes ang mga pod at ang iyong mga application ay babalik sa isang functional na estado nang medyo mabilis.
Pro #2: Magandang pagtitiklop
Kung may sapat na mga node, ang scheduler ng Kubernetes ay maaaring magtalaga ng iba't ibang mga node sa lahat ng mga replika. Sa ganitong paraan, kung nabigo ang isang node, isang replica lang ang maaapektuhan at mananatiling available ang application.
Cons
Disadvantage No. 1. Mahirap kontrolin
Ang malalaking bilang ng mga node ay mas mahirap pangasiwaan. Halimbawa, ang bawat node ng Kubernetes ay dapat makipag-ugnayan sa lahat ng iba pa, iyon ay, ang bilang ng mga koneksyon ay lumalaki nang quadratically, at lahat ng mga koneksyon na ito ay kailangang subaybayan.
Ang node controller sa Kubernetes Controller Manager ay regular na lumalakad sa lahat ng mga node sa cluster upang suriin ang kalusugan - mas maraming node, mas maraming load sa controller.
Lumalaki din ang load sa etcd database - bawat kubelet at kube-proxy ay tumatawag para sa etcd (sa pamamagitan ng API), kung saan dapat i-broadcast ng etcd ang mga update sa object.
Sa pangkalahatan, ang bawat node ng manggagawa ay nagpapataw ng karagdagang pagkarga sa mga bahagi ng system ng mga master node.
Opisyal na sinusuportahan ng Kubernetes ang mga cluster na may . Gayunpaman, sa pagsasanay mayroon nang 500 node .
Upang pamahalaan ang isang malaking bilang ng mga node ng manggagawa, dapat kang pumili ng mas makapangyarihang mga master node. Halimbawa, kube-up ang tamang laki ng VM para sa master node depende sa bilang ng mga node ng manggagawa. Iyon ay, mas maraming node ng manggagawa, mas produktibo dapat ang mga master node.
Upang malutas ang mga partikular na problemang ito mayroong mga espesyal na pag-unlad, tulad ng . Binibigyang-daan ka ng system na ito na i-bypass ang mga paghihigpit at bumuo ng mga kumpol na may malaking bilang ng mga node ng manggagawa.
Disadvantage #2: Higit pang mga gastos sa overhead.
Sa bawat node ng manggagawa, nagpapatakbo ang Kubernetes ng isang set ng mga daemon ng system - kabilang dito ang runtime ng container (gaya ng Docker), kube-proxy at kubelet, kabilang ang cAdvisor. Magkasama silang kumonsumo ng isang tiyak na halaga ng mga mapagkukunan.
Kung marami kang maliliit na node, mas malaki ang proporsyon ng overhead na ito sa bawat node. Halimbawa, isipin na ang lahat ng system daemon sa iisang node ay magkasamang gumagamit ng 0,1 CPU core at 0,1 GB ng memorya. Kung mayroon kang isang ten-core node na may 10 GB ng memorya, ang mga daemon ay kumokonsumo ng 1% ng kapasidad ng cluster. Sa kabilang banda, sa sampung single-core node na may 1 GB ng memorya, ang mga daemon ay kukuha ng 10% ng kapasidad ng kumpol.
Kaya, ang mas kaunting mga node, mas mahusay na ginagamit ang imprastraktura.
Disadvantage No. 3. Hindi mahusay na paggamit ng mga mapagkukunan
Sa maliliit na node, maaaring masyadong maliit ang natitirang mga resource chunks para magtalaga ng anumang workload, kaya nananatiling hindi ginagamit ang mga ito.
Halimbawa, ang bawat pod ay nangangailangan ng 0,75 GB ng memorya. Kung mayroon kang sampung node, bawat isa ay may 1GB ng memorya, maaari kang magpatakbo ng sampung pod, na iniiwan ang bawat node na may 0,25GB ng hindi nagamit na memorya.
Nangangahulugan ito na 25% ng memorya ng buong kumpol ay nasasayang.
Sa isang malaking node na may 10 GB ng memorya, maaari kang magpatakbo ng 13 sa mga module na ito - at magkakaroon lamang ng isang hindi nagamit na fragment na 0,25 GB.
Sa kasong ito, 2,5% lamang ng memorya ang nasasayang.
Kaya, ang mga mapagkukunan ay ginagamit nang mas mahusay sa mas malalaking node.
Ilang malalaking node o maraming maliliit?
Kaya, alin ang mas mahusay: ilang malalaking node sa isang kumpol o maraming maliliit? Gaya ng dati, walang malinaw na sagot. Malaki ang nakasalalay sa uri ng aplikasyon.
Halimbawa, kung ang isang application ay nangangailangan ng 10 GB ng memorya, ang mas malalaking node ay isang malinaw na pagpipilian. At kung ang aplikasyon ay nangangailangan ng sampung beses na pagtitiklop para sa mataas na kakayahang magamit, halos hindi sulit ang panganib na maglagay ng mga replika sa dalawang node lamang - dapat mayroong hindi bababa sa sampung node sa cluster.
Sa mga intermediate na sitwasyon, gumawa ng isang pagpipilian batay sa mga pakinabang at disadvantages ng bawat opsyon. Marahil ang ilang mga argumento ay mas nauugnay sa iyong sitwasyon kaysa sa iba.
At hindi kinakailangan na gawin ang lahat ng mga node sa parehong laki. Walang pumipigil sa iyo na mag-eksperimento muna sa mga node na may parehong laki, pagkatapos ay magdagdag ng mga node na may ibang laki sa mga ito, pagsasama-sama ang mga ito sa isang kumpol. Ang mga node ng manggagawa sa isang Kubernetes cluster ay maaaring maging ganap na magkakaibang. Kaya maaari mong subukang pagsamahin ang mga pakinabang ng parehong mga diskarte.
Walang iisang recipe, at ang bawat sitwasyon ay may sariling mga nuances, at ang produksyon lamang ang magpapakita ng katotohanan.
Pagsasalin na inihanda ng cloud platform team .
Higit pa tungkol sa Kubernetes: .
Pinagmulan: www.habr.com