Kumbuka. tafsiri.: nyenzo hii ni kutoka kwa mradi wa elimu ni jibu la swali maarufu wakati wa kubuni miundombinu inayotegemea Kubernetes. Tunatumahi kuwa maelezo ya kina ya faida na hasara za kila chaguo yatakusaidia kufanya chaguo bora kwa mradi wako.
TL; DR: seti sawa ya mizigo ya kazi inaweza kuendeshwa kwenye makundi kadhaa makubwa (kila nguzo itakuwa na idadi kubwa ya kazi) au kwa ndogo nyingi (pamoja na idadi ndogo ya kazi katika kila nguzo).
Ifuatayo ni jedwali linalotathmini faida na hasara za kila mbinu:
Unapotumia Kubernetes kama jukwaa la kuendesha programu, maswali kadhaa ya kimsingi mara nyingi huibuka juu ya ugumu wa kusanidi vikundi:
- Je, ni makundi ngapi ninapaswa kutumia?
- Je, ninapaswa kuwafanya wakubwa kiasi gani?
- Kila nguzo inapaswa kujumuisha nini?
Katika makala hii, nitajaribu kujibu maswali haya yote kwa kuchambua faida na hasara za kila mbinu.
Taarifa ya swali
Kama msanidi programu, unaweza kuendeleza na kuendesha programu nyingi kwa wakati mmoja.
Kwa kuongeza, matukio mengi ya maombi haya yanawezekana kukimbia katika mazingira tofauti - kwa mfano, haya yanaweza kuwa dev, mtihani ΠΈ Prod.
Matokeo yake ni mkusanyiko mzima wa matumizi na mazingira:
Maombi na Mazingira
Mfano hapo juu unawakilisha programu 3 na mazingira 3, na kusababisha jumla ya chaguzi 9 zinazowezekana.
Kila mfano wa programu ni kitengo cha utumaji kinachojitosheleza ambacho kinaweza kufanyiwa kazi bila ya wengine.
Tafadhali kumbuka kuwa mfano wa maombi inaweza kujumuisha nyingi vipengele, kama vile mandhari ya mbele, mandharinyuma, hifadhidata, n.k. Katika kesi ya maombi ya microservices, mfano utajumuisha huduma ndogo zote.
Kama matokeo, watumiaji wa Kubernetes wana maswali kadhaa:
- Matukio yote ya maombi yanapaswa kuwekwa kwenye nguzo moja?
- Inafaa kuwa na nguzo tofauti kwa kila mfano wa programu?
- Au labda mchanganyiko wa njia zilizo hapo juu zitumike?
Chaguzi hizi zote zinafaa kabisa, kwani Kubernetes ni mfumo unaobadilika ambao hauzuii uwezo wa mtumiaji.
Hapa kuna baadhi ya njia zinazowezekana:
- nguzo moja kubwa ya kawaida;
- vikundi vingi vidogo vilivyobobea sana;
- nguzo moja kwa kila programu;
- nguzo moja kwa kila mazingira.
Kama inavyoonyeshwa hapa chini, mbinu mbili za kwanza ziko kwenye ncha tofauti za kiwango cha chaguzi:
Kutoka kwa vikundi vichache vikubwa (kushoto) hadi vidogo vingi (kulia)
Kwa ujumla, nguzo moja inachukuliwa kuwa "kubwa" kuliko nyingine ikiwa ina jumla kubwa ya nodi na maganda. Kwa mfano, nguzo yenye nodi 10 na maganda 100 ni kubwa kuliko nguzo yenye nodi 1 na ganda 10.
Naam, tuanze!
1. Nguzo moja kubwa ya kawaida
Chaguo la kwanza ni kuweka mzigo wote wa kazi kwenye nguzo moja:
Kundi moja kubwa
Ndani ya mbinu hii, nguzo hutumiwa kama zima jukwaa la miundombinu - unatumia tu kila kitu unachohitaji katika nguzo iliyopo ya Kubernetes.
Kubernetes huruhusu sehemu za nguzo kutengwa kimantiki kutoka kwa nyingine, ili kila mfano wa programu uweze kuwa na nafasi yake ya majina.
Wacha tuangalie faida na hasara za njia hii.
+ Matumizi bora ya rasilimali
Ukiwa na kundi moja, unahitaji nakala moja pekee ya nyenzo zote zinazohitajika ili kuendesha na kudhibiti nguzo ya Kubernetes.
Kwa mfano, hii ni kweli kwa nodi kuu. Kwa kawaida, kila nguzo ya Kubernetes ina nodi 3 kuu, hivyo kwa nguzo moja idadi yao itabaki hivyo (kwa kulinganisha, nguzo 10 zitahitaji nodi 30 kuu).
Ujanja ulio hapo juu pia unatumika kwa huduma zingine zinazofanya kazi katika kundi zima, kama vile vidhibiti vya mizigo, vidhibiti vya Ingress, uthibitishaji, ukataji miti na mifumo ya ufuatiliaji.
Katika kikundi kimoja, huduma hizi zote zinaweza kutumika mara moja kwa mizigo yote ya kazi (hakuna haja ya kuunda nakala zao, kama ilivyo kwa makundi mengi).
+ Nafuu
Kama matokeo ya hapo juu, vikundi vichache kawaida huwa nafuu kwa sababu hakuna gharama za ziada.
Hii ni kweli hasa kwa nodi kuu, ambazo zinaweza kugharimu kiasi kikubwa cha pesa bila kujali jinsi wanavyokaribishwa (kwenye majengo au kwenye wingu).
Baadhi ya huduma zinazosimamia Kubernetes, kama vile au , toa safu ya udhibiti bila malipo. Katika kesi hii, suala la gharama ni chini ya papo hapo.
Pia kuna huduma zinazosimamiwa ambazo hutoza ada maalum kwa uendeshaji wa kila nguzo ya Kubernetes (kwa mfano, ).
+ Utawala bora
Kusimamia nguzo moja ni rahisi kuliko kusimamia kadhaa.
Utawala unaweza kujumuisha kazi zifuatazo:
- sasisho la toleo la Kubernetes;
- kuanzisha bomba la CI/CD;
- kufunga Plugin ya CNI;
- kuanzisha mfumo wa uthibitishaji wa mtumiaji;
- ufungaji wa mtawala wa upatikanaji;
na wengine wengiβ¦
Katika kesi ya nguzo moja, itabidi ufanye haya yote mara moja tu.
Kwa vikundi vingi, utendakazi utalazimika kurudiwa mara nyingi, ambayo itawezekana kuhitaji otomatiki fulani ya michakato na zana ili kuhakikisha uthabiti na uthabiti katika mchakato.
Na sasa maneno machache kuhusu hasara.
β Hatua moja ya kushindwa
Katika kesi ya kukataa wa pekee nguzo itaacha kufanya kazi mara moja wote kazi nyingi!
Kuna njia nyingi mambo yanaweza kwenda vibaya:
- uppdatering Kubernetes husababisha madhara yasiyotarajiwa;
- Sehemu ya nguzo pana (kwa mfano, programu-jalizi ya CNI) huanza kufanya kazi inavyotarajiwa;
- moja ya vipengele vya nguzo haijasanidiwa kwa usahihi;
- kushindwa kwa miundombinu ya msingi.
Tukio moja kama hilo linaweza kusababisha uharibifu mkubwa kwa mizigo yote ya kazi iliyopangishwa katika nguzo ya pamoja.
β Hakuna insulation ngumu
Kuendesha katika kundi la pamoja kunamaanisha kuwa programu zinashiriki maunzi, uwezo wa mtandao, na mfumo wa uendeshaji kwenye nodi za nguzo.
Kwa maana, vyombo viwili vilivyo na programu mbili tofauti zinazoendesha kwenye nodi moja ni kama michakato miwili inayoendesha kwenye mashine moja inayoendesha kernel sawa ya OS.
Vyombo vya Linux hutoa aina fulani ya kutengwa, lakini sio kali kama ile iliyotolewa na, tuseme, mashine pepe. Kwa asili, mchakato katika chombo ni mchakato sawa unaoendesha kwenye mfumo wa uendeshaji wa mwenyeji.
Hili linaweza kuwa suala la usalama: mpangilio huu kinadharia huruhusu programu zisizohusiana kuwasiliana (ama kwa makusudi au kwa bahati mbaya).
Zaidi ya hayo, mzigo wote wa kazi katika nguzo ya Kubernetes hushiriki huduma zingine za nguzo kama vile - hii inaruhusu programu kupata Huduma za programu zingine kwenye nguzo.
Pointi zote hapo juu zinaweza kuwa na maana tofauti kulingana na mahitaji ya usalama ya programu.
Kubernetes hutoa zana mbalimbali za kuzuia masuala ya usalama kama vile ΠΈ . Walakini, kuziweka kwa usahihi kunahitaji uzoefu fulani; kwa kuongezea, haziwezi kufunga mashimo yote ya usalama.
Ni muhimu kukumbuka kila wakati kuwa Kubernetes iliundwa kwa ajili ya kugawana, si kwa kutengwa na usalama.
β Ukosefu wa upangaji wa nyumba nyingi
Kwa kuzingatia wingi wa rasilimali zilizoshirikiwa katika kikundi cha Kubernetes, kuna njia nyingi ambazo programu tofauti zinaweza kukanyaga vidole vya kila mmoja.
Kwa mfano, programu inaweza kuhodhi rasilimali iliyoshirikiwa (kama vile CPU au kumbukumbu) na kukataa programu zingine zinazoendeshwa kwenye nodi sawa kuifikia.
Kubernetes hutoa njia mbalimbali za kudhibiti tabia hii, kama vile (tazama pia makala ""- takriban. tafsiri.), ΠΈ . Walakini, kama ilivyo kwa usalama, usanidi wao sio mdogo na hawawezi kuzuia athari zote zisizotarajiwa.
β Idadi kubwa ya watumiaji
Katika kesi ya nguzo moja, lazima ufungue ufikiaji wake kwa watu wengi. Na idadi yao kubwa, hatari zaidi ya kwamba "watavunja" kitu.
Ndani ya nguzo unaweza kudhibiti ni nani anayeweza kufanya nini kwa kutumia (tazama makala ""- takriban. tafsiri.). Walakini, haitazuia watumiaji kutoka "kuvunja" kitu ndani ya mipaka ya eneo lao la uwajibikaji.
β Nguzo haziwezi kukua kwa muda usiojulikana
Nguzo ambayo hutumiwa kwa mizigo yote ya kazi inaweza kuwa kubwa kabisa (kulingana na idadi ya nodi na maganda).
Lakini hapa shida nyingine inatokea: nguzo huko Kubernetes haziwezi kukua kwa muda usiojulikana.
Kuna kikomo cha kinadharia juu ya ukubwa wa nguzo. Katika Kubernetes ni takriban .
Walakini, katika maisha halisi, shida zinaweza kuanza mapema - kwa mfano, na .
Ukweli ni kwamba makundi makubwa huweka mzigo mkubwa kwenye safu ya udhibiti wa Kubernetes. Kwa maneno mengine, kuweka nguzo juu na kufanya kazi kwa ufanisi kunahitaji urekebishaji wa uangalifu.
Suala hili linachunguzwa katika makala inayohusiana kwenye blogu asili inayoitwa "'.
Lakini hebu fikiria mbinu kinyume: makundi mengi madogo.
2. Nguzo nyingi ndogo, maalum
Kwa mbinu hii, unatumia nguzo tofauti kwa kila kipengele unachopeleka:
Vikundi vingi vidogo
Kwa madhumuni ya kifungu hiki, chini ya kipengele kinachoweza kutumiwa inarejelea mfano wa programu - kwa mfano, toleo la dev la programu tofauti.
Mkakati huu hutumia Kubernetes kama mtaalamu wakati wa kukimbia kwa matukio ya maombi ya mtu binafsi.
Wacha tuangalie faida na hasara za njia hii.
+ "Radi ya mlipuko" mdogo
Kikundi kinaposhindwa, matokeo mabaya yanadhibitiwa tu na mzigo wa kazi ambao uliwekwa kwenye nguzo hiyo. Kazi zingine zote bado hazijaguswa.
+ Insulation
Mizigo ya kazi iliyopangishwa katika makundi mahususi haishiriki rasilimali kama vile kichakataji, kumbukumbu, mfumo wa uendeshaji, mtandao au huduma nyinginezo.
Matokeo yake ni kutengwa sana kati ya programu zisizohusiana, ambazo zinaweza kuwa na manufaa kwa usalama wao.
+ Idadi ndogo ya watumiaji
Ikizingatiwa kuwa kila kikundi kina seti chache tu ya mzigo wa kazi, idadi ya watumiaji wanaoweza kufikia hupunguzwa.
Watu wachache wanaweza kufikia nguzo, chini ya hatari ya kuwa kitu "kitavunja".
Hebu tuangalie hasara.
β Matumizi yasiyofaa ya rasilimali
Kama ilivyoelezwa hapo awali, kila nguzo ya Kubernetes inahitaji seti maalum ya rasilimali za usimamizi: nodi kuu, vipengele vya safu ya udhibiti, ufuatiliaji na ufumbuzi wa ukataji miti.
Katika kesi ya idadi kubwa ya vikundi vidogo, sehemu kubwa ya rasilimali lazima igawiwe kwa usimamizi.
β Ghali
Matumizi yasiyofaa ya rasilimali moja kwa moja yanajumuisha gharama kubwa.
Kwa mfano, kudumisha nodi kuu 30 badala ya tatu na nguvu sawa ya kompyuta itaathiri gharama.
β Ugumu katika utawala
Kusimamia nguzo nyingi za Kubernetes ni ngumu zaidi kuliko kudhibiti moja tu.
Kwa mfano, itabidi usanidi uthibitishaji na uidhinishaji kwa kila nguzo. Toleo la Kubernetes pia litalazimika kusasishwa mara kadhaa.
Huenda utahitaji kutumia otomatiki ili kufanya kazi hizi zote kuwa bora zaidi.
Sasa hebu tuangalie matukio ya chini sana.
3. Nguzo moja kwa kila programu
Kwa njia hii, unaunda nguzo tofauti kwa visa vyote vya programu fulani:
Nguzo kwa kila programu
Njia hii inaweza kuzingatiwa kama jumla ya kanuni "kundi tofauti kwa kila timuβ, kwani kwa kawaida timu ya wahandisi hutengeneza programu moja au zaidi.
Wacha tuangalie faida na hasara za njia hii.
+ Nguzo inaweza kubadilishwa kwa programu
Ikiwa programu ina mahitaji maalum, yanaweza kutekelezwa katika kikundi bila kuathiri makundi mengine.
Mahitaji kama haya yanaweza kujumuisha wafanyikazi wa GPU, programu-jalizi fulani za CNI, matundu ya huduma, au huduma nyinginezo.
Kila nguzo inaweza kulengwa kwa programu inayoendesha ndani yake ili iwe na kile kinachohitajika tu.
β Mazingira tofauti katika nguzo moja
Ubaya wa mbinu hii ni kwamba hali za matumizi kutoka kwa mazingira tofauti hukaa kwenye nguzo moja.
Kwa mfano, toleo la prod la programu huendeshwa katika kundi sawa na toleo la dev. Hii pia inamaanisha kuwa wasanidi programu hufanya kazi katika kundi moja ambalo toleo la uzalishaji la programu linaendeshwa.
Ikiwa, kwa sababu ya vitendo vya watengenezaji au hitilafu katika toleo la dev, kutofaulu kunatokea kwenye nguzo, basi toleo la prod linaweza kuteseka pia - shida kubwa ya njia hii.
Na mwishowe, hali ya mwisho kwenye orodha yetu.
4. Nguzo moja kwa kila mazingira
Hali hii inahusisha kutenga nguzo tofauti kwa kila mazingira:
Nguzo moja kwa kila mazingira
Kwa mfano, unaweza kuwa na makundi dev, mtihani ΠΈ Prod, ambayo utaendesha matukio yote ya programu iliyowekwa kwa mazingira maalum.
Hapa kuna faida na hasara za njia hii.
+ Kutengwa kwa mazingira ya prod
Ndani ya mbinu hii, mazingira yote yanatengwa kutoka kwa kila mmoja. Hata hivyo, katika mazoezi hii ni muhimu hasa katika mazingira ya prod.
Matoleo ya uzalishaji ya programu sasa hayategemei kile kinachotokea katika makundi na mazingira mengine.
Kwa njia hii, ikiwa shida itatokea ghafla kwenye nguzo ya usanidi, matoleo ya programu yataendelea kufanya kazi kana kwamba hakuna kilichotokea.
+ Nguzo inaweza kubadilishwa kwa mazingira
Kila nguzo inaweza kubadilishwa kwa mazingira yake. Kwa mfano, unaweza:
- sakinisha zana za ukuzaji na utatuzi katika nguzo ya dev;
- sakinisha mifumo ya majaribio na zana kwenye nguzo mtihani;
- tumia maunzi yenye nguvu zaidi na chaneli za mtandao kwenye nguzo Prod.
Hii inakuwezesha kuongeza ufanisi wa maendeleo ya maombi na uendeshaji.
+ Kuzuia ufikiaji wa kikundi cha uzalishaji
Haja ya kufanya kazi moja kwa moja na nguzo ya uzalishaji haitokei mara chache, kwa hivyo unaweza kupunguza kwa kiasi kikubwa mduara wa watu wanaoifikia.
Unaweza kwenda mbali zaidi na kuwanyima watu ufikiaji wa nguzo hii kabisa, na kutekeleza utumaji wote kwa kutumia zana ya kiotomatiki ya CI/CD. Mbinu kama hiyo itapunguza hatari ya makosa ya kibinadamu haswa mahali ambapo inafaa zaidi.
Na sasa maneno machache kuhusu hasara.
β Hakuna kutengwa kati ya programu
Hasara kuu ya mbinu ni ukosefu wa vifaa na kutengwa kwa rasilimali kati ya programu.
Programu zisizohusiana hushiriki rasilimali za nguzo: msingi wa mfumo, kichakataji, kumbukumbu, na huduma zingine.
Kama ilivyoelezwa, hii inaweza kuwa hatari.
β Kutoweza kubinafsisha vitegemezi vya programu
Ikiwa maombi yana mahitaji maalum, basi lazima yaridhike katika makundi yote.
Kwa mfano, ikiwa programu inahitaji GPU, basi kila kundi lazima liwe na angalau mfanyakazi mmoja aliye na GPU (hata kama inatumiwa na programu hiyo pekee).
Matokeo yake, tunahatarisha gharama kubwa na matumizi yasiyofaa ya rasilimali.
Hitimisho
Ikiwa una seti maalum ya programu, zinaweza kuwekwa katika makundi kadhaa makubwa au ndogo nyingi.
Nakala hiyo inajadili faida na hasara za njia anuwai, kuanzia nguzo moja ya kimataifa hadi kadhaa ndogo na maalum sana:
- nguzo moja kubwa ya jumla;
- vikundi vingi vidogo vilivyobobea sana;
- nguzo moja kwa kila programu;
- nguzo moja kwa kila mazingira.
Kwa hivyo unapaswa kuchukua njia gani?
Kama kawaida, jibu linategemea kesi ya utumiaji: unahitaji kupima faida na hasara za njia tofauti na uchague chaguo bora zaidi.
Hata hivyo, uchaguzi sio mdogo kwa mifano hapo juu - unaweza kutumia mchanganyiko wowote wao!
Kwa mfano, unaweza kupanga vikundi kadhaa kwa kila timu: kikundi cha maendeleo (ambacho kutakuwa na mazingira. dev ΠΈ mtihani) na nguzo kwa uzalishaji (ambapo mazingira ya uzalishaji yatakuwapo).
Kulingana na maelezo katika makala haya, unaweza kuboresha faida na hasara ipasavyo kwa hali maalum. Bahati njema!
PS
Soma pia kwenye blogi yetu:
- Β«";
- Β«";
- Β«";
- Β«'.
Chanzo: mapenzi.com