Wakati wa kuunda nguzo ya Kubernetes, maswali yanaweza kutokea: ni nodi ngapi za wafanyikazi za kusanidi na ni aina gani? Ni nini bora kwa nguzo ya msingi: nunua seva kadhaa zenye nguvu au utumie mashine kadhaa za zamani kwenye kituo chako cha data? Je, ni bora kuchukua matukio nane ya msingi mmoja au mbili za quad-core kwenye wingu?
Majibu ya maswali haya ni katika makala. katika tafsiri ya amri .
Uwezo wa nguzo
Kwa ujumla, nguzo ya Kubernetes inaweza kuzingatiwa kama "supernode" kubwa. Nguvu yake ya jumla ya kompyuta ni jumla ya nguvu za nodi zake zote za eneo.
Kuna njia kadhaa za kufikia lengo lako la uwezo wa nguzo unaotaka. Kwa mfano, tunahitaji kikundi chenye uwezo wa jumla wa core 8 za kichakataji na GB 32 za RAM kwa sababu seti ya programu inahitaji rasilimali nyingi. Kisha unaweza kufunga nodes mbili na 16 GB ya kumbukumbu au nodes nne na 8 GB ya kumbukumbu, processor mbili za quad-core au nne mbili-msingi.
Hapa kuna njia mbili tu zinazowezekana za kuunda nguzo:
Chaguzi zote mbili hutoa nguzo yenye uwezo sawa, lakini usanidi wa chini una nodi nne ndogo na usanidi wa juu una nodi mbili kubwa.
Chaguo gani ni bora?
Ili kujibu swali hili, hebu tuangalie faida za chaguzi zote mbili. Tumezijumlisha katika jedwali.
Nodi kadhaa kubwa
Node nyingi ndogo
Udhibiti rahisi zaidi wa nguzo (ikiwa uko kwenye uwanja)
Uwekaji kiotomatiki laini
Nafuu (ikiwa iko kwenye uwanja)
Bei ni tofauti kidogo (katika wingu)
Inaweza kuendesha programu zinazotumia rasilimali nyingi
Replication kamili
Rasilimali hutumiwa kwa ufanisi zaidi (chini ya uendeshaji kwenye daemoni za mfumo
Uvumilivu wa makosa ya nguzo ya juu
Tafadhali kumbuka kuwa tunazungumza tu juu ya nodi za wafanyikazi. Kuchagua idadi na ukubwa wa nodes kuu ni mada tofauti kabisa.
Kwa hiyo, hebu tujadili kila nukta kutoka kwa meza kwa undani zaidi.
Chaguo la kwanza: nodes kadhaa kubwa
Chaguo kali zaidi ni nodi moja ya wafanyikazi kwa uwezo wote wa nguzo. Katika mfano hapo juu, hii itakuwa nodi moja ya mfanyakazi na cores 16 za CPU na 16 GB ya RAM.
Faida
Pamoja Nambari 1. Udhibiti rahisi zaidi
Ni rahisi kudhibiti mashine chache kuliko kundi zima. Ni haraka kusambaza masasisho na marekebisho, na ni rahisi kusawazisha. Idadi ya kushindwa katika nambari kamili pia ni ndogo.
Tafadhali kumbuka kuwa yote yaliyo hapo juu yanatumika kwa maunzi yako, seva zako, na si kwa matukio ya wingu.
Hali ni tofauti katika wingu. Huko, usimamizi unashughulikiwa na mtoa huduma wa wingu. Kwa hivyo, kusimamia nodi kumi kwenye wingu sio tofauti sana na kudhibiti nodi moja.
Uelekezaji wa trafiki na usambazaji wa mzigo kati ya maganda kwenye wingu : trafiki inayotoka kwenye mtandao inatumwa kwa mizani kuu ya mzigo, ambayo hupeleka trafiki kwenye bandari ya nodi moja (huduma ya NodePort inaweka bandari katika safu 30000-32767 katika kila nodi ya nguzo). Sheria zilizowekwa na kube-proksi huelekeza tena trafiki kutoka kwa nodi hadi kwenye ganda. Hivi ndivyo inavyoonekana kwa maganda kumi kwenye nodi mbili:
Pro #2: Gharama ndogo kwa kila nodi
Gari yenye nguvu ni ghali zaidi, lakini ongezeko la bei sio lazima liwe mstari. Kwa maneno mengine, seva moja ya msingi kumi na kumbukumbu ya GB 10 kawaida ni ya bei nafuu kuliko seva kumi za msingi-moja zilizo na kumbukumbu sawa.
Lakini kumbuka kuwa sheria hii haifanyi kazi katika huduma za wingu. Katika mipango ya sasa ya bei ya watoa huduma wote wakuu wa mtandao, bei huongezeka kulingana na uwezo.
Kwa hivyo, katika wingu kawaida huwezi kuokoa kwenye seva zenye nguvu zaidi.
Pro #3: Unaweza kuendesha programu zinazotumia rasilimali nyingi
Baadhi ya programu zinahitaji seva zenye nguvu katika kundi. Kwa mfano, ikiwa mfumo wa kujifunza mashine unahitaji kumbukumbu ya GB 8, hutaweza kuiendesha kwenye nodi za GB 1, lakini kwa angalau nodi moja kubwa ya mfanyakazi.
Africa
Hasara Nambari 1. Maganda mengi kwa node
Ikiwa kazi hiyo hiyo inafanywa kwa nodes chache, basi kila mmoja wao atakuwa na maganda zaidi.
Hili linaweza kuwa tatizo.
Sababu ni kwamba kila moduli inatanguliza juu ya muda wa kuendeshwa kwa kontena (k.m. Docker), na vile vile kubelet na cAdvisor.
Kwa mfano, kubelet huchunguza mara kwa mara kontena zote kwenye nodi kwa ajili ya kuendelea kuishiβkadiri kontena zinavyoongezeka, ndivyo kubelet inavyopaswa kufanya kazi nyingi zaidi.
CAdvisor hukusanya takwimu za matumizi ya rasilimali kwa vyombo vyote kwenye nodi, na kubelet huuliza mara kwa mara maelezo haya na kuyatoa kupitia API. Tena, vyombo vingi vinamaanisha kazi zaidi kwa cAdvisor na kubelet.
Ikiwa idadi ya moduli huongezeka, inaweza kupunguza kasi ya mfumo na hata kudhoofisha uaminifu wake.
Katika hazina ya Kubernetes baadhi nodi hizo zinaruka kati ya hali za Tayari/Hazija Tayari kwa sababu ukaguzi wa mara kwa mara wa kubelet wa vyombo vyote kwenye nodi huchukua muda mrefu sana.
Kwa sababu hii Kubernetes . Kulingana na utendaji wa nodi, unaweza kukimbia pods zaidi kwa node, lakini ni vigumu kutabiri ikiwa kutakuwa na matatizo au kila kitu kitafanya kazi vizuri. Inastahili kupima kazi mapema.
Hasara No 2. Kizuizi juu ya replication
Vifundo vichache sana huzuia kiwango cha ufanisi cha urudufishaji wa programu. Kwa mfano, ikiwa una programu ya upatikanaji wa juu iliyo na nakala tano lakini nodi mbili pekee, basi kiwango bora cha urudufishaji wa programu hupunguzwa hadi mbili.
Nakala tano zinaweza tu kusambazwa kwenye nodi mbili, na ikiwa mojawapo itashindwa, itachukua nakala nyingi mara moja.
Ikiwa una nodi tano au zaidi, kila nakala itaendeshwa kwenye nodi tofauti, na kutofaulu kwa nodi moja kutaondoa nakala moja zaidi.
Kwa hivyo, mahitaji ya juu ya upatikanaji yanaweza kuhitaji idadi fulani ya chini ya nodi kwenye nguzo.
Hasara Nambari 3. Matokeo mabaya zaidi ya kushindwa
Kwa idadi ndogo ya nodes, kila kushindwa kuna madhara makubwa zaidi. Kwa mfano, ikiwa una nodi mbili tu na moja yao inashindwa, nusu ya moduli zako hupotea mara moja.
Bila shaka, Kubernetes itahamisha mzigo wa kazi kutoka kwa nodi iliyoshindwa hadi kwa wengine. Lakini ikiwa kuna wachache wao, basi kunaweza kuwa hakuna uwezo wa kutosha wa bure. Kwa hivyo, baadhi ya programu zako hazitapatikana hadi ulete nodi iliyoshindwa.
Hivyo, nodes zaidi, chini ya athari za kushindwa kwa vifaa.
Hasara # 4: Hatua zaidi za kuongeza otomatiki
Kubernetes ina mfumo wa nguzo wa kuongeza kiotomatiki kwa miundombinu ya wingu, ambayo hukuruhusu kuongeza au kuondoa nodi kiotomatiki kulingana na mahitaji yako ya sasa. Ukiwa na nodi kubwa, kuongeza kasi kiotomatiki kunakuwa kwa ghafla zaidi na kufifia. Kwa mfano, kwenye nodes mbili, kuongeza node ya ziada itaongeza mara moja uwezo wa nguzo kwa 50%. Na itabidi ulipie rasilimali hizo, hata kama huzihitaji.
Kwa hivyo, ikiwa unapanga kutumia upanuzi wa nguzo otomatiki, kadiri nodi zilivyo ndogo, ndivyo utakavyopata kuongeza rahisi zaidi na kwa gharama nafuu.
Sasa hebu tuangalie faida na hasara za idadi kubwa ya nodes ndogo.
Chaguo la pili: nodi nyingi ndogo
Faida za mbinu hii kimsingi zinatokana na hasara za chaguo kinyume na nodes kadhaa kubwa.
Faida
Pro #1: Athari chache za kutofaulu
Vifundo vingi ndivyo maganda machache kwenye kila nodi. Kwa mfano, ikiwa una moduli mia moja kwa nodi kumi, basi kila nodi itakuwa na wastani wa moduli kumi.
Kwa hiyo ikiwa moja ya nodes inashindwa, unapoteza tu 10% ya mzigo wa kazi. Uwezekano ni kwamba ni idadi ndogo tu ya nakala zitaathirika na programu kwa ujumla itasalia kufanya kazi.
Zaidi ya hayo, nodi zilizosalia zitakuwa na rasilimali za kutosha za kutosha kushughulikia mzigo wa nodi iliyoshindwa, kwa hivyo Kubernetes inaweza kupanga upya maganda kwa hiari na programu zako zitarejea katika hali ya utendakazi kwa haraka kiasi.
Pro #2: Urudufu mzuri
Ikiwa kuna nodi za kutosha, kipanga ratiba cha Kubernetes kinaweza kugawa nodi tofauti kwa nakala zote. Kwa njia hii, ikiwa nodi itashindwa, nakala moja tu itaathiriwa na programu itabaki inapatikana.
Africa
Hasara No 1. Vigumu kudhibiti
Idadi kubwa ya nodi ni ngumu zaidi kudhibiti. Kwa mfano, kila nodi ya Kubernetes lazima iwasiliane na wengine wote, yaani, idadi ya viunganisho inakua mara nne, na viunganisho hivi vyote vinahitaji kufuatiliwa.
Kidhibiti cha nodi katika Kidhibiti cha Kidhibiti cha Kubernetes hutembea mara kwa mara kupitia nodi zote kwenye nguzo ili kuangalia afya - nodi nyingi zaidi, ndivyo mzigo zaidi kwenye kidhibiti.
Mzigo kwenye hifadhidata ya etcd pia unakua - kila simu ya kubelet na kube-proxy kwa etcd (kupitia API), ambayo etcd inapaswa kutangaza sasisho za kitu.
Kwa ujumla, kila node ya mfanyakazi inatia mzigo wa ziada kwenye vipengele vya mfumo wa nodes za bwana.
Kubernetes inasaidia rasmi nguzo na . Walakini, katika mazoezi tayari kuna nodi 500 .
Ili kudhibiti idadi kubwa ya nodi za wafanyikazi, unapaswa kuchagua nodi za bwana zenye nguvu zaidi. Kwa mfano, kube-up saizi sahihi ya VM kwa nodi kuu kulingana na idadi ya nodi za wafanyikazi. Hiyo ni, nodes zaidi za wafanyakazi, nodi za bwana zinapaswa kuwa na tija zaidi.
Ili kutatua matatizo haya maalum kuna maendeleo maalum, kama vile . Mfumo huu hukuruhusu kupitisha vizuizi na kujenga vikundi na idadi kubwa ya nodi za wafanyikazi.
Hasara #2: Gharama zaidi za ziada.
Kwenye kila nodi ya mfanyakazi, Kubernetes huendesha seti ya daemoni za mfumo - hizi ni pamoja na muda wa matumizi ya kontena (kama vile Docker), kube-proksi na kubelet, ikijumuisha cAdvisor. Kwa pamoja hutumia kiasi fulani cha rasilimali.
Ikiwa una nodi nyingi ndogo, sehemu ya kichwa hiki kwenye kila nodi ni kubwa zaidi. Kwa mfano, fikiria kwamba daemoni zote za mfumo kwenye nodi moja pamoja hutumia cores 0,1 za CPU na 0,1 GB ya kumbukumbu. Ikiwa una nodi moja ya msingi kumi yenye kumbukumbu ya GB 10, basi damoni hutumia 1% ya uwezo wa nguzo. Kwa upande mwingine, kwenye nodi kumi za msingi-moja na GB 1 ya kumbukumbu, daemoni zitachukua 10% ya uwezo wa nguzo.
Kwa hivyo, nodes chache, miundombinu inatumiwa kwa ufanisi zaidi.
Hasara Nambari 3. Matumizi yasiyofaa ya rasilimali
Kwenye nodi ndogo, huenda vijisehemu vilivyobaki vya rasilimali ni vidogo sana vya kupeana mzigo wowote wa kazi, kwa hivyo vinabaki bila kutumika.
Kwa mfano, kila ganda linahitaji 0,75 GB ya kumbukumbu. Ikiwa una nodi kumi, kila moja ikiwa na 1GB ya kumbukumbu, unaweza kuendesha pods kumi, na kuacha kila nodi na 0,25GB ya kumbukumbu isiyotumiwa.
Hii inamaanisha kuwa 25% ya kumbukumbu nzima ya nguzo imepotea.
Kwenye node kubwa yenye kumbukumbu ya GB 10, unaweza kuendesha 13 ya moduli hizi - na kutakuwa na kipande kimoja tu ambacho hakijatumiwa cha 0,25 GB.
Katika kesi hii, 2,5% tu ya kumbukumbu hupotea.
Kwa hivyo, rasilimali hutumiwa kikamilifu kwenye nodi kubwa.
Nodi kadhaa kubwa au nyingi ndogo?
Kwa hivyo, ni bora zaidi: nodi chache kubwa kwenye nguzo au ndogo nyingi? Kama kawaida, hakuna jibu wazi. Inategemea sana aina ya maombi.
Kwa mfano, ikiwa programu inahitaji kumbukumbu ya GB 10, nodi kubwa ni chaguo dhahiri. Na ikiwa programu inahitaji urudufishaji mara kumi kwa upatikanaji wa juu, haifai hatari ya kuweka nakala kwenye nodi mbili tu - lazima kuwe na angalau nodi kumi kwenye nguzo.
Katika hali ya kati, fanya uchaguzi kulingana na faida na hasara za kila chaguo. Labda hoja zingine zinafaa zaidi kwa hali yako kuliko zingine.
Na sio lazima kabisa kufanya nodes zote za ukubwa sawa. Hakuna kinachokuzuia kujaribu kwanza na nodi za saizi sawa, kisha kuongeza nodi za saizi tofauti kwao, ukizichanganya kwenye nguzo. Nodi za wafanyikazi katika nguzo ya Kubernetes zinaweza kuwa tofauti kabisa. Kwa hivyo unaweza kujaribu kuchanganya faida za njia zote mbili.
Hakuna kichocheo kimoja, na kila hali ina nuances yake mwenyewe, na uzalishaji tu utaonyesha ukweli.
Tafsiri iliyotayarishwa na timu ya jukwaa la wingu .
Zaidi kuhusu Kubernetes: .
Chanzo: mapenzi.com