Bilješka. prev.: ovaj materijal je iz obrazovnog projekta odgovor je na popularno pitanje pri projektiranju infrastrukture temeljene na Kubernetesu. Nadamo se da će vam prilično detaljni opisi prednosti i nedostataka svake opcije pomoći da napravite najbolji izbor za svoj projekt.
TL; DR: isti skup radnih opterećenja može se izvoditi na nekoliko velikih klastera (svaki klaster će imati veliki broj radnih opterećenja) ili na mnogo malih (s malim brojem radnih opterećenja u svakom klasteru).
U nastavku je tablica koja procjenjuje prednosti i nedostatke svakog pristupa:
Kada koristite Kubernetes kao platformu za pokretanje aplikacija, često se postavlja nekoliko temeljnih pitanja o zamršenosti postavljanja klastera:
- Koliko klastera trebam koristiti?
- Koliko velike trebam napraviti?
- Što svaki klaster treba sadržavati?
U ovom ću članku pokušati odgovoriti na sva ova pitanja analizirajući prednosti i nedostatke svakog pristupa.
Izjava pitanja
Kao programer softvera, vjerojatno razvijate i upravljate mnogim aplikacijama u isto vrijeme.
Osim toga, mnoge instance ovih aplikacija vjerojatno će se izvoditi u različitim okruženjima - na primjer, ove mogu biti dev, test и štap.
Rezultat je čitava matrica aplikacija i okruženja:
Prijave i okruženja
Gornji primjer predstavlja 3 aplikacije i 3 okruženja, što rezultira s ukupno 9 mogućih opcija.
Svaka instanca aplikacije je samostalna jedinica za implementaciju s kojom se može raditi neovisno o drugima.
Imajte na umu da instanca aplikacije može se sastojati od mnogih Komponente, kao što su frontend, backend, baza podataka itd. U slučaju aplikacije mikroservisa, instanca će uključivati sve mikroservise.
Zbog toga korisnici Kubernetesa imaju nekoliko pitanja:
- Trebaju li sve instance aplikacije biti smještene u jedan klaster?
- Isplati li se imati zaseban klaster za svaku instancu aplikacije?
- Ili bi se možda trebala koristiti kombinacija gore navedenih pristupa?
Sve ove opcije su prilično održive, budući da je Kubernetes fleksibilan sustav koji ne ograničava mogućnosti korisnika.
Evo nekih od mogućih načina:
- jedan veliki zajednički klaster;
- mnogo malih visoko specijaliziranih klastera;
- jedan klaster po aplikaciji;
- jedan klaster po okruženju.
Kao što je prikazano u nastavku, prva dva pristupa su na suprotnim krajevima ljestvice opcija:
Od nekoliko velikih grozdova (lijevo) do mnogo malih (desno)
Općenito, jedan se klaster smatra "većim" od drugog ako ima veći zbroj čvorova i grupa. Na primjer, klaster s 10 čvorova i 100 podova veći je od klastera s 1 čvorom i 10 podova.
Pa, počnimo!
1. Jedan veliki zajednički klaster
Prva opcija je smjestiti sva radna opterećenja u jedan klaster:
Jedan veliki grozd
Unutar ovog pristupa klaster se koristi kao univerzalan infrastrukturna platforma — jednostavno postavite sve što vam treba u postojeći Kubernetes klaster.
Kubernetes dopušta da dijelovi klastera budu logički odvojeni jedni od drugih, tako da svaka instanca aplikacije može imati svoj vlastiti imenski prostor.
Pogledajmo prednosti i mane ovog pristupa.
+ Učinkovito korištenje resursa
S jednim klasterom potrebna vam je samo jedna kopija svih resursa potrebnih za pokretanje i upravljanje Kubernetes klasterom.
Na primjer, ovo vrijedi za glavne čvorove. Tipično, svaki Kubernetes klaster ima 3 glavna čvora, tako da će za jedan klaster njihov broj ostati takav (za usporedbu, 10 klastera trebat će 30 glavnih čvorova).
Gornja suptilnost također se odnosi na druge usluge koje rade u cijelom klasteru, kao što su balanseri opterećenja, ulazni kontroleri, sustavi provjere autentičnosti, zapisivanja i nadzora.
U jednom klasteru sve te usluge mogu se koristiti odjednom za sva radna opterećenja (nema potrebe za stvaranjem njihovih kopija, kao što je slučaj s više klastera).
+ Jeftino
Kao posljedica gore navedenog, manji broj klastera obično je jeftiniji jer nema režijskih troškova.
Ovo posebno vrijedi za glavne čvorove, koji mogu koštati značajnu količinu novca bez obzira na to kako su hostirani (lokalno ili u oblaku).
Neki upravljani Kubernetes servisi, kao npr ili , pružiti kontrolni sloj besplatno. U ovom slučaju, pitanje troškova je manje akutno.
Postoje i upravljane usluge koje naplaćuju fiksnu naknadu za rad svakog Kubernetes klastera (npr. ).
+ Učinkovita administracija
Upravljanje jednim klasterom lakše je nego upravljanje nekoliko njih.
Administracija može uključivati sljedeće zadatke:
- Ažuriranje Kubernetes verzije;
- postavljanje CI/CD cjevovoda;
- instaliranje CNI dodatka;
- postavljanje sustava za autentifikaciju korisnika;
- ugradnja kontrolera pristupa;
i mnogi drugi…
U slučaju jednog klastera, sve ovo ćete morati učiniti samo jednom.
Za mnoge klastere, operacije će se morati ponavljati mnogo puta, što će vjerojatno zahtijevati određenu automatizaciju procesa i alata kako bi se osigurala dosljednost i dosljednost u procesu.
A sada nekoliko riječi o nedostacima.
− Jedna točka kvara
U slučaju odbijanja jedini klaster će odmah prestati raditi sve radna opterećenja!
Mnogo je načina na koje stvari mogu poći po zlu:
- ažuriranje Kubernetesa dovodi do neočekivanih nuspojava;
- Komponenta na razini klastera (na primjer, CNI dodatak) počinje ne raditi kako se očekuje;
- jedna od komponenti klastera nije ispravno konfigurirana;
- kvar u temeljnoj infrastrukturi.
Jedan takav incident može uzrokovati ozbiljnu štetu svim radnim opterećenjima koja se nalaze u zajedničkom klasteru.
− Bez krute izolacije
Rad u zajedničkom klasteru znači da aplikacije dijele hardver, mrežne mogućnosti i operativni sustav na čvorovima klastera.
U određenom smislu, dva spremnika s dvije različite aplikacije koje se izvode na istom čvoru su poput dva procesa koji se izvode na istom stroju koji pokreće istu jezgru OS-a.
Linux spremnici pružaju neki oblik izolacije, ali ona nije ni približno jaka kao ona koju pružaju, recimo, virtualni strojevi. U biti, proces u spremniku je isti proces koji se izvodi na glavnom operativnom sustavu.
To može biti sigurnosni problem: ovaj raspored teoretski omogućuje nepovezanim aplikacijama da međusobno komuniciraju (bilo namjerno ili slučajno).
Osim toga, sva radna opterećenja u Kubernetes klasteru dijele neke usluge na razini klastera kao što su - ovo omogućuje aplikacijama da pronađu usluge drugih aplikacija u klasteru.
Sve gore navedene točke mogu imati različita značenja ovisno o sigurnosnim zahtjevima aplikacije.
Kubernetes nudi razne alate za sprječavanje sigurnosnih problema kao što su и . Međutim, njihovo ispravno postavljanje zahtijeva određeno iskustvo, osim toga, ne mogu zatvoriti apsolutno sve sigurnosne rupe.
Važno je uvijek imati na umu da je Kubernetes izvorno dizajniran za dijeljenje, nije za izolacija i sigurnost.
− Nedostatak stroge odredbe o višestanarstvu
S obzirom na obilje zajedničkih resursa u Kubernetes klasteru, postoji mnogo načina na koje različite aplikacije mogu stati jedna drugoj na prste.
Na primjer, aplikacija može monopolizirati dijeljeni resurs (kao što je CPU ili memorija) i uskratiti drugim aplikacijama koje rade na istom čvoru pristup njemu.
Kubernetes pruža različite mehanizme za kontrolu ovog ponašanja, kao što su (vidi i članak “" - cca. prev.), и . Međutim, kao iu slučaju sigurnosti, njihova konfiguracija je prilično netrivijalna i ne mogu spriječiti apsolutno sve nepredviđene nuspojave.
− Veliki broj korisnika
U slučaju jednog klastera, morate otvoriti pristup njemu mnogim ljudima. A što je njihov broj veći, to je veći rizik da će nešto "slomiti".
Unutar klastera možete kontrolirati tko može učiniti što pomoću (vidi članak "" - cca. prev.). Međutim, to neće spriječiti korisnike da "slome" nešto unutar svojeg područja odgovornosti.
− Grozdovi ne mogu rasti beskonačno
Klaster koji se koristi za sva radna opterećenja vjerojatno će biti prilično velik (u smislu broja čvorova i podova).
Ali tu se javlja još jedan problem: klasteri u Kubernetesu ne mogu rasti beskonačno.
Postoji teoretsko ograničenje veličine klastera. U Kubernetesu je otprilike .
Međutim, u stvarnom životu problemi mogu početi mnogo ranije - na primjer, samo s .
Činjenica je da veliki klasteri opterećuju Kubernetes kontrolni sloj. Drugim riječima, održavanje klastera u ispravnom i učinkovitom radu zahtijeva pažljivo podešavanje.
Ovo je pitanje istraženo u povezanom članku na izvornom blogu pod nazivom "".
Ali razmotrimo suprotan pristup: mnogo malih klastera.
2. Mnogo malih, specijaliziranih klastera
Ovim pristupom koristite zaseban klaster za svaki element koji implementirate:
Mnogo malih grozdova
Za potrebe ovog članka, pod razmjestivi element odnosi se na instancu aplikacije - na primjer, razvojnu verziju zasebne aplikacije.
Ova strategija koristi Kubernetes kao specijalizirani vrijeme izvođenja za pojedinačne primjere primjene.
Pogledajmo prednosti i mane ovog pristupa.
+ Ograničeni "radijus eksplozije"
Kada klaster zakaže, negativne posljedice ograničene su samo na ona radna opterećenja koja su bila raspoređena u tom klasteru. Sva ostala radna opterećenja ostaju netaknuta.
+ Izolacija
Radna opterećenja smještena u pojedinačnim klasterima ne dijele resurse kao što su procesor, memorija, operativni sustav, mreža ili druge usluge.
Rezultat je čvrsta izolacija između nepovezanih aplikacija, što može biti korisno za njihovu sigurnost.
+ Mali broj korisnika
S obzirom na to da svaki klaster sadrži samo ograničen skup radnih opterećenja, broj korisnika s pristupom njemu je smanjen.
Što manje ljudi ima pristup klasteru, manji je rizik da će se nešto "pokvariti".
Pogledajmo nedostatke.
− Neučinkovito korištenje resursa
Kao što je ranije spomenuto, svaki Kubernetes klaster zahtijeva određeni skup resursa za upravljanje: glavne čvorove, komponente kontrolnog sloja, rješenja za nadzor i bilježenje.
U slučaju velikog broja malih klastera, veći udio resursa mora biti alociran na upravljanje.
− Skupo
Neučinkovito korištenje resursa automatski povlači za sobom visoke troškove.
Na primjer, održavanje 30 glavnih čvorova umjesto tri s istom računalnom snagom nužno će utjecati na troškove.
− Poteškoće u administraciji
Upravljanje više Kubernetes klastera puno je teže nego upravljanje samo jednim.
Na primjer, morat ćete konfigurirati autentifikaciju i autorizaciju za svaki klaster. Kubernetes verzija također će morati biti ažurirana nekoliko puta.
Vjerojatno ćete morati upotrijebiti automatizaciju kako biste učinili sve ove zadatke učinkovitijima.
Sada pogledajmo manje ekstremne scenarije.
3. Jedan klaster po aplikaciji
U ovom pristupu stvarate zaseban klaster za sve instance određene aplikacije:
Klaster po aplikaciji
Ovaj put se može smatrati generalizacijom principa "odvojeni klaster po timu“, jer obično tim inženjera razvija jednu ili više aplikacija.
Pogledajmo prednosti i mane ovog pristupa.
+ Klaster se može prilagoditi primjeni
Ako aplikacija ima posebne potrebe, one se mogu implementirati u klaster bez utjecaja na druge klastere.
Takve potrebe mogu uključivati GPU radnike, određene CNI dodatke, servisnu mrežu ili neku drugu uslugu.
Svaki se klaster može prilagoditi aplikaciji koja se u njemu izvodi tako da sadrži samo ono što je potrebno.
− Različita okruženja u jednom klasteru
Nedostatak ovog pristupa je da instance aplikacije iz različitih okruženja koegzistiraju u istom klasteru.
Na primjer, proizvodna verzija aplikacije radi u istom klasteru kao razvojna verzija. To također znači da programeri rade u istom klasteru u kojem radi proizvodna verzija aplikacije.
Ako se, zbog radnji programera ili grešaka u dev verziji, dogodi kvar u klasteru, tada bi prod verzija također potencijalno mogla stradati - veliki nedostatak ovog pristupa.
I na kraju, posljednji scenarij na našem popisu.
4. Jedan klaster po okruženju
Ovaj scenarij uključuje dodjelu zasebnog klastera za svako okruženje:
Jedan klaster po okruženju
Na primjer, možete imati klastere dev, test и štap, u kojem ćete pokretati sve instance aplikacije namijenjene određenom okruženju.
Evo prednosti i mana ovog pristupa.
+ Izolacija proizvodnog okruženja
Unutar ovog pristupa sva su okruženja međusobno izolirana. Međutim, u praksi je to posebno važno u proizvodnom okruženju.
Proizvodne verzije aplikacije sada su neovisne o tome što se događa u drugim klasterima i okruženjima.
Na ovaj način, ako se iznenada pojavi problem u dev klasteru, prod verzije aplikacija nastavit će raditi kao da se ništa nije dogodilo.
+ Grozd se može prilagoditi okolini
Svaki se klaster može prilagoditi svojoj okolini. Na primjer, možete:
- instalirajte alate za razvoj i otklanjanje pogrešaka u razvojnom klasteru;
- instalirati testne okvire i alate u klaster test;
- koristiti snažniji hardver i mrežne kanale u klasteru štap.
To vam omogućuje povećanje učinkovitosti razvoja i rada aplikacije.
+ Ograničavanje pristupa proizvodnom klasteru
Rijetko se javlja potreba za izravnim radom s proizvodnim klasterom, tako da možete značajno ograničiti krug ljudi koji mu imaju pristup.
Možete ići čak i dalje i potpuno uskratiti ljudima pristup ovom klasteru i izvršiti sve implementacije pomoću automatiziranog CI/CD alata. Takav će pristup minimizirati rizik od ljudskih pogrešaka točno tamo gdje je to najrelevantnije.
A sada nekoliko riječi o nedostacima.
− Nema izolacije između aplikacija
Glavni nedostatak pristupa je nedostatak hardverske i resursne izolacije između aplikacija.
Nepovezane aplikacije dijele resurse klastera: jezgru sustava, procesor, memoriju i neke druge usluge.
Kao što je spomenuto, ovo može biti potencijalno opasno.
− Nemogućnost lokalizacije ovisnosti aplikacije
Ako aplikacija ima posebne zahtjeve, oni moraju biti zadovoljeni u svim klasterima.
Na primjer, ako aplikacija zahtijeva GPU, tada svaki klaster mora sadržavati najmanje jednog radnika s GPU-om (čak i ako ga koristi samo ta aplikacija).
Kao rezultat toga, riskiramo veće troškove i neučinkovito korištenje resursa.
Zaključak
Ako imate određeni skup aplikacija, one se mogu smjestiti u nekoliko velikih klastera ili mnogo malih.
U članku se raspravlja o prednostima i nedostacima različitih pristupa, od jednog globalnog klastera do nekoliko malih i visoko specijaliziranih:
- jedan veliki opći klaster;
- mnogo malih visoko specijaliziranih klastera;
- jedan klaster po aplikaciji;
- jedan klaster po okruženju.
Dakle, koji biste pristup trebali odabrati?
Kao i uvijek, odgovor ovisi o slučaju upotrebe: trebate odvagnuti prednosti i nedostatke različitih pristupa i odabrati najoptimalniji izbor.
Međutim, izbor nije ograničen na gore navedene primjere - možete koristiti bilo koju njihovu kombinaciju!
Na primjer, možete organizirati nekoliko klastera za svaki tim: razvojni klaster (u kojem će biti okruženja dev и test) i klaster za proizvodnja (gdje će biti smješten proizvodni okoliš).
Na temelju informacija u ovom članku, možete optimizirati prednosti i nedostatke u skladu s određenim scenarijem. Sretno!
PS
Pročitajte i na našem blogu:
- «»;
- «»;
- «»;
- «".
Izvor: www.habr.com