Märge. tõlge: see materjal on pärit haridusprojektist on vastus populaarsele küsimusele Kubernetesel põhineva infrastruktuuri kujundamisel. Loodame, et iga valiku plusside ja miinuste üsna üksikasjalik kirjeldus aitab teil teha oma projekti jaoks parima valiku.
TL; DR: sama töökoormuste komplekti saab käitada mitmes suures klastris (igas klastris on palju töökoormusi) või paljudes väikestes (igas klastris väikese koormuste arvuga).
Allpool on tabel, mis hindab iga lähenemisviisi plusse ja miinuseid:
Kubernetese kasutamisel rakenduste käitamise platvormina tekib klastrite seadistamise keerukuse kohta sageli mitu põhiküsimust:
- Mitut klastrit peaksin kasutama?
- Kui suured ma need tegema peaksin?
- Mida peaks iga klaster sisaldama?
Selles artiklis püüan vastata kõigile neile küsimustele, analüüsides iga lähenemisviisi plusse ja miinuseid.
Küsimuse avaldus
Tarkvaraarendajana arendate ja kasutate tõenäoliselt palju rakendusi korraga.
Lisaks töötavad paljud nende rakenduste eksemplarid tõenäoliselt erinevates keskkondades – näiteks võivad need olla Dev, test и prod.
Tulemuseks on terve rakenduste ja keskkondade maatriks:
Rakendused ja keskkonnad
Ülaltoodud näide esindab 3 rakendust ja 3 keskkonda, mille tulemuseks on kokku 9 võimalikku valikut.
Iga rakenduse eksemplar on iseseisev juurutusüksus, millega saab töötada teistest sõltumatult.
Pange tähele, et rakenduse eksemplar võib koosneda paljudest komponendid, nagu kasutajaliides, taustaprogramm, andmebaas jne. Mikroteenuste rakenduse puhul sisaldab eksemplar kõiki mikroteenuseid.
Selle tulemusena on Kubernetese kasutajatel mitu küsimust:
- Kas kõik rakenduse eksemplarid tuleks paigutada ühte klastrisse?
- Kas tasub omada iga rakenduse eksemplari jaoks eraldi klastrit?
- Või võib-olla tuleks kasutada ülaltoodud lähenemisviiside kombinatsiooni?
Kõik need võimalused on üsna elujõulised, kuna Kubernetes on paindlik süsteem, mis ei piira kasutaja võimalusi.
Siin on mõned võimalikud viisid.
- üks suur ühine kobar;
- paljud väikesed väga spetsialiseerunud klastrid;
- üks klaster rakenduse kohta;
- üks klaster keskkonna kohta.
Nagu allpool näidatud, asuvad kaks esimest lähenemisviisi valikute skaala vastasotstes.
Mõnest suurest klastrist (vasakul) kuni paljude väikesteni (paremal)
Üldiselt peetakse üht klastrit teisest suuremaks, kui sellel on suurem sõlmede ja kaunade summa. Näiteks 10 sõlme ja 100 kaustaga klaster on suurem kui 1 sõlme ja 10 kaustaga klaster.
Noh, alustame!
1. Üks suur ühine kobar
Esimene võimalus on paigutada kõik töökoormused ühte klastrisse:
Üks suur klaster
Selle lähenemisviisi raames kasutatakse klastrit universaalsena infrastruktuuri platvorm — juurutate lihtsalt kõik, mida vajate, olemasolevas Kubernetese klastris.
Kubernetes võimaldab klastri osi üksteisest loogiliselt eraldada, nii et igal rakenduse eksemplaril võib olla oma nimeruum.
Vaatame selle lähenemisviisi plusse ja miinuseid.
+ Ressursside tõhus kasutamine
Ühe klastri puhul on teil vaja ainult ühte eksemplari kõigist Kubernetese klastri käitamiseks ja haldamiseks vajalikest ressurssidest.
Näiteks kehtib see põhisõlmede kohta. Tavaliselt on igal Kubernetese klastris 3 peasõlme, nii et ühe klastri puhul jääb nende arv selliseks (võrdluseks, 10 klastrit vajavad 30 peasõlme).
Ülaltoodud peensus kehtib ka muude teenuste kohta, mis töötavad kogu klastris, nagu koormuse tasakaalustajad, sissepääsukontrollerid, autentimis-, logimis- ja jälgimissüsteemid.
Ühes klastris saab kõiki neid teenuseid korraga kasutada kõigi töökoormuste jaoks (ei ole vaja luua neist koopiaid, nagu mitme klastri puhul).
+ Odav
Eeltoodu tulemusena on vähem klastreid tavaliselt odavamad, kuna puuduvad üldkulud.
See kehtib eriti põhisõlmede kohta, mis võivad kuluda märkimisväärse summa raha olenemata sellest, kuidas neid hostitakse (kohapealne või pilves).
Mõned hallatavad Kubernetese teenused, nt või , andke juhtkiht tasuta. Sel juhul on kuluprobleem vähem terav.
Samuti on hallatud teenuseid, mis võtavad iga Kubernetese klastri töötamise eest fikseeritud tasu (näiteks ).
+ Tõhus haldus
Ühe klastri haldamine on lihtsam kui mitme klastri haldamine.
Haldus võib hõlmata järgmisi ülesandeid:
- Kubernetese versiooni värskendus;
- CI/CD torujuhtme seadistamine;
- CNI pistikprogrammi installimine;
- kasutaja autentimissüsteemi seadistamine;
- juurdepääsukontrolleri paigaldamine;
ja paljud teised…
Ühe klastri puhul peate seda kõike tegema ainult üks kord.
Paljude klastrite puhul tuleb toiminguid korrata mitu korda, mis eeldab protsessi järjepidevuse ja järjepidevuse tagamiseks protsesside ja tööriistade mõningast automatiseerimist.
Ja nüüd paar sõna miinuste kohta.
− Üks tõrkepunkt
Keeldumise korral ainus klaster lakkab koheselt töötamast kõik töökoormused!
Asjad võivad valesti minna mitmel viisil:
- Kubernetese värskendamine toob kaasa ootamatuid kõrvalmõjusid;
- Kogu klastriülene komponent (nt CNI-plugin) ei tööta ootuspäraselt;
- üks klastri komponentidest pole õigesti konfigureeritud;
- rike aluseks olevas infrastruktuuris.
Üks selline juhtum võib tõsiselt kahjustada kõiki jagatud klastris hostitud töökoormusi.
− Puudub jäik isolatsioon
Jagatud klastris töötamine tähendab, et rakendused jagavad klastri sõlmede riistvara, võrguvõimalusi ja operatsioonisüsteemi.
Teatud mõttes on kaks konteinerit kahe erineva rakendusega, mis töötavad samas sõlmes, nagu kaks protsessi, mis töötavad samas masinas ja sama OS-i kerneliga.
Linuxi konteinerid pakuvad teatud tüüpi isolatsiooni, kuid see pole kaugeltki nii tugev kui näiteks virtuaalmasinate pakutav. Sisuliselt on konteineris olev protsess sama protsess, mis töötab hosti operatsioonisüsteemis.
See võib olla turvaprobleem: see paigutus võimaldab teoreetiliselt sõltumatutel rakendustel üksteisega suhelda (kas tahtlikult või kogemata).
Lisaks jagavad kõik Kubernetese klastri töökoormused mõningaid klastriüleseid teenuseid, näiteks - see võimaldab rakendustel leida klastris teiste rakenduste teenuseid.
Kõik ülaltoodud punktid võivad olenevalt rakenduse turvanõuetest omada erinevat tähendust.
Kubernetes pakub erinevaid tööriistu turvaprobleemide vältimiseks, nagu и . Nende õige seadistamine nõuab aga teatud kogemust, lisaks ei suuda need sulgeda absoluutselt kõiki turvaauke.
Oluline on alati meeles pidada, et Kubernetes oli algselt mõeldud jagamine, mitte isolatsioon ja ohutus.
− Range mitme üürilepingu puudumine
Arvestades Kubernetese klastri jagatud ressursside rohkust, on erinevatel rakendustel palju võimalusi üksteisele astuda.
Näiteks võib rakendus monopoliseerida jagatud ressursi (nt CPU või mälu) ja keelata teistele samas sõlmes töötavatele rakendustele sellele juurdepääsu.
Kubernetes pakub selle käitumise kontrollimiseks erinevaid mehhanisme, näiteks (vt ka artiklit ""- ca. tõlge.), и . Kuid nagu turvalisuse puhul, on nende konfiguratsioon üsna ebatriviaalne ja nad ei suuda ära hoida absoluutselt kõiki ettenägematuid kõrvalmõjusid.
− Suur kasutajate arv
Ühe klastri puhul peate avama juurdepääsu sellele paljudele inimestele. Ja mida suurem on nende arv, seda suurem on oht, et nad midagi lõhuvad.
Klastris saate juhtida, kes mida kasutades saab teha (vaata artiklit ""- ca. tõlge.). Kuid see ei takista kasutajatel midagi nende vastutusalas "murdmast".
− Klastrid ei saa lõputult kasvada
Kõigi töökoormuste jaoks kasutatav klaster on tõenäoliselt üsna suur (sõlmede ja kaustade arvu poolest).
Kuid siin kerkib esile veel üks probleem: Kubernetese klastrid ei saa lõputult kasvada.
Klastrite suurusel on teoreetiline piirang. Kuberneteses on see ligikaudu .
Kuid päriselus võivad probleemid alata palju varem – näiteks just sellega .
Fakt on see, et suured klastrid panevad Kubernetese juhtkihile suure koormuse. Teisisõnu nõuab klastri tõhusalt töökorras hoidmine hoolikat häälestamist.
Seda probleemi käsitletakse algse ajaveebi seotud artiklis "'.
Kuid kaalugem vastupidist lähenemist: palju väikeseid klastreid.
2. Paljud väikesed spetsialiseeritud klastrid
Selle lähenemisviisi korral kasutate iga juurutatud elemendi jaoks eraldi klastrit.
Paljud väikesed klastrid
Selle artikli tähenduses all juurutatav element viitab rakenduse eksemplarile – näiteks eraldi rakenduse arendajaversioonile.
See strateegia kasutab Kubernetesi spetsialiseerumisena käitusaeg üksikute rakendusjuhtumite jaoks.
Vaatame selle lähenemisviisi plusse ja miinuseid.
+ Piiratud lõhkeraadius
Kui klastris ebaõnnestub, on negatiivsed tagajärjed piiratud ainult nende töökoormustega, mis selles klastris juurutati. Kõik muud töökoormused jäävad puutumata.
+ Isolatsioon
Üksikutes klastrites hostitud töökoormused ei jaga ressursse, nagu protsessor, mälu, operatsioonisüsteem, võrk või muud teenused.
Tulemuseks on tihe isolatsioon sõltumatute rakenduste vahel, mis võib olla kasulik nende turvalisusele.
+ Väike kasutajate arv
Arvestades, et iga klaster sisaldab ainult piiratud hulga töökoormusi, väheneb sellele juurdepääsu omavate kasutajate arv.
Mida vähem inimesi pääseb klastrisse, seda väiksem on oht, et midagi puruneb.
Vaatame miinuseid.
− Ebaefektiivne ressursside kasutamine
Nagu varem mainitud, vajab iga Kubernetese klaster kindlat haldusressursside komplekti: põhisõlmed, juhtkihi komponendid, jälgimis- ja logilahendused.
Suure hulga väikeste klastrite puhul tuleb suunata suurem osa ressurssidest juhtimisele.
− Kallis
Ressursside ebaefektiivne kasutamine toob automaatselt kaasa suuri kulutusi.
Näiteks 30 põhisõlme säilitamine sama arvutusvõimsusega kolme asemel mõjutab tingimata kulusid.
− Haldusraskused
Mitme Kubernetese klastri haldamine on palju keerulisem kui ühe haldamine.
Näiteks peate iga klastri jaoks konfigureerima autentimise ja autoriseerimise. Ka Kubernetese versiooni tuleb mitu korda värskendada.
Tõenäoliselt peate kõigi nende ülesannete tõhusamaks muutmiseks kasutama automatiseerimist.
Vaatame nüüd vähem äärmuslikke stsenaariume.
3. Üks klaster rakenduse kohta
Selle lähenemisviisi puhul loote konkreetse rakenduse kõigi eksemplaride jaoks eraldi klastri.
Klaster rakenduse kohta
Seda teed võib käsitleda kui põhimõtte üldistuseraldi klaster meeskonna kohta”, kuna tavaliselt töötab inseneride meeskond üht või mitut rakendust.
Vaatame selle lähenemisviisi plusse ja miinuseid.
+ Klastrit saab kohandada vastavalt rakendusele
Kui rakendusel on erivajadused, saab neid rakendada klastris ilma teisi klastreid mõjutamata.
Sellised vajadused võivad hõlmata GPU töötajaid, teatud CNI pistikprogramme, teenindusvõrku või mõnda muud teenust.
Iga klastrit saab kohandada vastavalt selles töötavale rakendusele, nii et see sisaldab ainult vajalikku.
− Erinevad keskkonnad ühes klastris
Selle lähenemisviisi puuduseks on see, et erinevatest keskkondadest pärit rakenduse eksemplarid eksisteerivad samas klastris.
Näiteks rakenduse tootmisversioon töötab arendajaversiooniga samas klastris. See tähendab ka seda, et arendajad tegutsevad samas klastris, kus kasutatakse rakenduse tootmisversiooni.
Kui arendajate tegevuse või arendajaversiooni tõrgete tõttu ilmneb klastris rike, võib kannatada ka tooteversioon - selle lähenemisviisi tohutu puudus.
Ja lõpuks, meie nimekirja viimane stsenaarium.
4. Üks klaster keskkonna kohta
See stsenaarium hõlmab iga keskkonna jaoks eraldi klastri eraldamist.
Üks klaster keskkonna kohta
Näiteks võivad teil olla klastrid Dev, test и prod, milles käivitate kõik konkreetsele keskkonnale pühendatud rakenduse eksemplarid.
Siin on selle lähenemisviisi plussid ja miinused.
+ Tootmiskeskkonna isoleerimine
Selle lähenemisviisi raames on kõik keskkonnad üksteisest isoleeritud. Praktikas on see aga eriti oluline tootmiskeskkonnas.
Rakenduse tootmisversioonid on nüüd sõltumatud teistes klastrites ja keskkondades toimuvast.
Nii jätkavad rakenduste tootlusversioonid töötamist, kui arendajaklastris peaks ootamatult ilmnema probleem, nagu poleks midagi juhtunud.
+ Klastrit saab kohandada vastavalt keskkonnale
Iga klastrit saab kohandada vastavalt oma keskkonnale. Näiteks saate:
- installige arendusklastri tööriistad arendamiseks ja silumiseks;
- installige klastris testraamistikud ja tööriistad test;
- kasutada klastris võimsamat riistvara ja võrgukanaleid prod.
See võimaldab tõsta nii rakenduste arendamise kui ka töötamise efektiivsust.
+ Tootmisklastrile juurdepääsu piiramine
Vajadus töötada otse tooteklastriga tekib harva, nii et saate oluliselt piirata inimeste ringi, kellel on sellele juurdepääs.
Saate minna veelgi kaugemale ja keelata inimestel juurdepääsu sellele klastrile ning teostada kõik juurutused automaatse CI/CD tööriista abil. Selline lähenemine vähendab inimlike vigade riski täpselt seal, kus see on kõige olulisem.
Ja nüüd paar sõna miinuste kohta.
− Rakenduste vahel puudub isolatsioon
Selle lähenemisviisi peamiseks puuduseks on riistvara ja ressursside eraldatuse puudumine rakenduste vahel.
Mitteseotud rakendused jagavad klastri ressursse: süsteemi tuum, protsessor, mälu ja mõned muud teenused.
Nagu mainitud, võib see olla potentsiaalselt ohtlik.
− suutmatus lokaliseerida rakenduste sõltuvusi
Kui rakendusel on erinõuded, peavad need olema täidetud kõigis klastrites.
Näiteks kui rakendus nõuab GPU-d, peab iga klaster sisaldama vähemalt ühte GPU-ga töötajat (isegi kui seda kasutab ainult see rakendus).
Selle tulemusena riskime suuremate kuludega ja ressursside ebaefektiivse kasutamisega.
Järeldus
Kui teil on konkreetne rakenduste komplekt, saab need paigutada mitmesse suurde või paljudesse väikestesse klastritesse.
Artiklis käsitletakse erinevate lähenemisviiside plusse ja miinuseid, alates ühest globaalsest klastrist kuni mitme väikese ja väga spetsialiseerunud klastrini:
- üks suur üldklaster;
- paljud väikesed väga spetsialiseerunud klastrid;
- üks klaster rakenduse kohta;
- üks klaster keskkonna kohta.
Niisiis, millist lähenemist peaksite kasutama?
Nagu alati, sõltub vastus kasutusjuhtumist: peate kaaluma erinevate lähenemisviiside plusse ja miinuseid ning valima optimaalseima variandi.
Valik ei piirdu aga ainult ülaltoodud näidetega – võite kasutada nende mis tahes kombinatsiooni!
Näiteks saate iga meeskonna jaoks korraldada paar klastrit: arendusklastri (milles on keskkonnad Dev и test) ja klastri jaoks tootmine (kus hakkab paiknema tootmiskeskkond).
Selles artiklis esitatud teabe põhjal saate konkreetse stsenaariumi jaoks optimeerida plusse ja miinuseid. Edu!
PS
Loe ka meie blogist:
- «";
- «";
- «";
- «'.
Allikas: www.habr.com