Op. prev.: ta vsebina je iz izobraževalnega projekta — odgovor na priljubljeno vprašanje o zasnovi infrastrukture na podlagi Kubernetes. Upamo, da bodo dovolj podrobni opisi prednosti in slabosti vsake od možnosti pomagali pri optimalni izbiri za vaš projekt.
TL;DR: isti sklop delovnih obremenitev je mogoče zagnati na več velikih grozdu (vsak grozd bo imel veliko število delovnih obremenitev) ali na številnih manjših (z manjšim številom obremenitev v vsakem grozdu).
Spodaj je tabela, v kateri so ocenjene prednosti in slabosti vsakega pristopa:
Pri uporabi Kubernetes kot platforme za upravljanje aplikacij se pogosto pojavljajo nekatera temeljna vprašanja o nastavitev grozdov:
- Koliko grozdov uporabiti?
- Kako velike naj bodo?
- Kaj naj vsebuje vsak grozd?
V tem članku bom poskušal odgovoriti na vsa ta vprašanja, analizirajoč prednosti in slabosti vsakega pristopa.
Postavljanje vprašanja
Kot razvijalec programske opreme verjetno hkrati razvijate in upravljate številne aplikacije.
Poleg tega se številni primerki teh aplikacij zagotovo izvajajo v različnih okoljih — na primer, to so lahko dev, test in prod.
Rezultat je celotna matrika aplikacij in okolij:
Aplikacije in okolja
V zgornjem primeru je prikazanih 3 aplikacije in 3 okolja, kar na koncu daje 9 možnih kombinacij.
Vsak primer aplikacije predstavlja samostojno enoto za izvajanje, s katero lahko delate neodvisno od drugih.
je res polinom stopnje primer aplikacije lahko je sestavljen iz mnogih komponent, kot so frontend, backend, baza podatkov itd. V primeru mikroservisne aplikacije bo primer vključil vse mikroservise.
Zato se uporabnikom Kubernetes zastavlja več vprašanj:
- Ali naj bodo vsi primerki aplikacij v enem grozdu?
- Ali naj ima vsak primer aplikacije svoj grozd?
- Ali pa bi morda morali uporabiti kombinacijo zgoraj navedenih pristopov?
Vse te možnosti so povsem izvedljive, saj je Kubernetes fleksibilen sistem, ki uporabnikom omogoča široko paleto možnosti.
Tukaj je nekaj možnih poti:
- en velik skupen grozd;
- veliko majhnih specializiranih grozdov;
- en grozd za vsako aplikacijo;
- en grozd za vsako okolje.
Kot je prikazano spodaj, sta prva dva pristopa na nasprotnih koncih spektra možnosti:
Od nekaj velikih grozdov (levo) do mnogih majhnih (desno)
Na splošno velja, da je en grozd "večji" od drugega, če ima večjo skupno število vozlišč in podov. Na primer, grozd s 10 vozlišči in 100 podi je večji od grozda z 1 vozliščem in 10 podi.
No, začnimo!
1. En velik skupni grozd
Prva možnost je, da vse delovne obremenitve postavite v en grozd:
En velik grozd
V okviru tega pristopa se grozd uporablja kot univerzalna infrastrukturna platforma — vse, kar potrebujete, preprosto namestite v obstoječem grozdu Kubernetes.
Kubernetes omogoča logično ločevanje delov grozda drug od drugega, tako da lahko za vsako instanco aplikacije uporabite svoj imenski prostor.
Poglejmo prednosti in slabosti tega pristopa.
+ Učinkovita uporaba virov
V primeru enotnega grozda je potrebna le ena kopija vseh virov, potrebnih za zagon grozda Kubernetes in njegovo upravljanje.
Na primer, to velja za vodilna vozlišča. Običajno ima vsak grozd Kubernetes 3 vodilna vozlišča, zato bo število ostalo tako, tudi za en sam grozd (kot primer, 10 grozdov bo potrebovalo 30 vodilnih vozlišč).
Ta posebnost se nanaša tudi na druge storitve, ki delujejo na ravni celotnega grozda, kot so uravnoteževalniki obremenitve, kontrolerji Ingress, sistemi za avtentifikacijo, beleženje in nadzor.
V enotnem grozdu lahko te storitve uporabite takoj za vse delovne obremenitve (ni treba ustvarjati njihovih kopij, kot v primeru več grozdov).
+ Cenejša izbira
Zaradi zgornjega je manjše število grozdov običajno cenejše, saj ni stroškov za odvečne vire.
To še posebej velja za vodilna vozlišča, ki lahko stanejo precej, ne glede na način nastanitve (na lokaciji ali v oblaku).
Nekatere upravljane storitve Kubernetes, kot je ili , zagotavljajo brezplačno upravljavsko plast. V tem primeru vprašanje stroškov ni tako izrazito.
Obstajajo tudi upravljane storitve, ki zaračunavajo fiksno ceno za delovanje vsakega Kubernetes klasterja (na primer, ).
+ Učinkovito upravljanje
Upraviti en klaster je lažje kot več njih.
Upravljanje lahko vključuje naslednje naloge:
- posodobitev različice Kubernetes;
- nastavitev CI/CD pipelinov;
- namestitev CNI vtičnika;
- nastavitev sistema avtorizacije uporabnikov;
- namestitev kontrolerja dostopa;
in mnoge druge…
V primeru enega klasterja je potrebno to početiti le enkrat.
Pri več klasterjih bo treba naloge ponavljati večkrat, kar bo verjetno zahtevalo avtomatizacijo procesov in orodij za zagotavljanje sistematičnosti in doslednosti.
Sedaj pa nekaj besed o slabostih.
− Enotna točka okvare
V primeru okvare edinega klasterja prenehajo delovati takoj vse delovne obremenitve!
Obstaja veliko scenarijev, kjer lahko kaj gre narobe:
- posodobitev Kubernetes privede do nepredvidljivih stranskih učinkov;
- komponenta v skupnem klasterju (na primer, CNI vtičnik) ne deluje, kot je pričakovano;
- ena izmed komponent klasterja ni pravilno nastavljena;
- okvara v spodnji infrastrukturi.
En tak incident lahko povzroči resno škodo vsem delovnim obremenitvam, nameščenim v skupnem klasterju.
− Pomanjkanje stroge izolacije
Delo v skupnem klasterju pomeni, da aplikacije skupno uporabljajo strojno opremo, omrežne zmogljivosti in operacijski sistem na vozliščih klasterja.
V določenem smislu sta dva kontejnerja z dvema različnima aplikacijama, ki delujeta na istem vozlišču, podobna dvema procesoma, ki delujeta na istem računalniku pod nadzorom istega OS jedra.
Linux kontejnerji zagotavljajo neko obliko izolacije, vendar ta ni tako močna kot tista, ki jo zagotavljajo na primer virtualni stroji. V bistvu je proces v kontejnerju enak procesu, ki teče v gostiteljskem operacijskem sistemu.
To lahko postane težava s stališča varnosti: taka organizacija teoretično omogoča nepovezanim aplikacijam, da komunicirajo med seboj (nameroma ali nenameroma).
Poleg tega vse delovne obremenitve v Kubernetes klastru skupno uporabljajo nekatere skupne storitve, kot so — to omogoča aplikacijam, da najdejo storitve drugih aplikacij v klastru.
Vse zgoraj navedene točke imajo lahko različne pomene, odvisno od varnostnih zahtev aplikacij.
Kubernetes ponuja različna orodja za preprečevanje težav v informacijski varnosti, kot so in . Vendar pa je za pravilno nastavitev potrebna določena izkušnja, poleg tega pa ne morejo zapreti vseh varnostnih lukenj.
Pomembno je, da vedno pomnimo, da je Kubernetes prvotno zasnovan za skupno rabo, ne pa za izolacijo in varnost.
− Pomanjkanje stroge multi-tenancy
Ob upoštevanju obilice skupnih virov v Kubernetes klastru obstaja veliko načinov, kako si različne aplikacije lahko "stopijo na prste".
Na primer, aplikacija lahko monopolizira določen skupni vir (kot je procesor ali pomnilnik) in drugim aplikacijam, ki delujejo na istem vozlišču, onemogoči dostop do njega.
Kubernetes zagotavlja različne mehanizme za nadzor takšnega obnašanja, kot so (glejte tudi članek "“ — op. prev.), in . Vendar pa, kot v primeru varnosti, njihova nastavitev ni triviaalna in ne morejo preprečiti vseh nepredvidenih stranskih učinkov.
− Število uporabnikov
V primeru enega samega klastru je treba dostop do njega odpreti številnim ljudem. In bolj kot je njihovo število, večje je tveganje, da bodo kaj "pokvarili".
Znotraj klastru je mogoče nadzorovati, kdo in kaj lahko počne z uporabo (glejte članek "“ — op. prev.). Vendar pa to ne preprečuje, da bi uporabniki "pokvarili" kaj v okviru svojih odgovornosti.
− Klasterji ne morejo rasti neskončno
Kluster, ki se uporablja za vse delovne obremenitve, bo verjetno precej velik (glede na število vozlišč in podov).
Toda tu se pojavi drug problem: klasterji v Kubernetesu ne morejo rasti neskončno.
Obstaja teoretična omejitev velikosti klustra. V Kubernetesu ta znaša približno .
Vendar v resničnem svetu se težave lahko začnejo mnogo prej — na primer, pri .
Težava je v tem, da veliki klasterji obremenjujejo upravljalsko plast Kubernetes. Z drugimi besedami, za vzdrževanje klasterja v funkcionalnem stanju in učinkovito uporabo virov je potrebno skrbno nastavljanje.
Ta problem je obravnavan v ustreznem članku v originalnem blogu z naslovom „».
Toda poglejmo nasproten pristop: več manjših klasterjev.
2. Številni majhni, specializirani klasterji
Pri tem pristopu uporabite ločen klaster za vsak razporejen element:
Mnogokratni majhni klasterji
Za namen tega članka pod razporejenim elementom razumemo primer aplikacije — na primer, dev različico posamezne aplikacije.
V tej strategiji se Kubernetes uporablja kot specializirano izvajalno okolje za posamezne primere aplikacij.
Poglejmo prednosti in slabosti tega pristopa.
+ Omejen „radius eksplozije“
Ob „okvari“ klasterja so negativne posledice omejene le na tiste delovne obremenitve, ki so bile razporejene v tem klasterju. Vse druge obremenitve ostanejo nedotaknjene.
+ Izolacija
Delovne obremenitve, nameščene v individualnih klasterjih, nimajo skupnih virov, kot so procesor, pomnilnik, operacijski sistem, omrežje ali druge storitve.
Posledično dobimo strogo izolacijo med nepovezanimi aplikacijami, kar lahko pozitivno vpliva na njihovo varnost.
+ Majhno število uporabnikov
Glede na to, da v vsakem klasterju obstaja le omejen nabor delovnih obremenitev, se zmanjša število uporabnikov z dostopom do njega.
Manj ljudi, ki imajo dostop do klasterja, pomeni manjše tveganje, da se kaj „pokvari“.
Poglejmo pomanjkljivosti.
− Neučinkovita uporaba virov
Kot je bilo omenjeno prej, vsak klaster Kubernetes potrebuje določen nabor upravljalskih virov: master-vozlišča, komponente nadzorne plasti, rešitve za spremljanje in beleženje logov.
V primeru velikega števila majhnih klasterjev je treba dodeliti večji delež virov za upravljanje.
− Stroški
Neučinkovita uporaba virov samodejno vodi do visokih stroškov.
Na primer, vsebina 30 master vozlišč namesto treh pri enaki računski moči bo zagotovo vplivala na stroške.
− Težave z upravljanjem
Upravljanje z mnogimi Kubernetes klasterji je precej bolj zapleteno kot delo z enim samim.
Na primer, potrebno bo nastaviti avtentifikacijo in avtorizacijo za vsak klaster. Posodobitev različice Kubernetes bo prav tako treba izvesti večkrat.
Verjetno bo potrebno uporabiti avtomatizacijo, da bi povečali učinkovitost vseh teh nalog.
Zdaj pa poglejmo manj ekstremne scenarije.
3. En klaster za vsako aplikacijo
V okviru tega pristopa ustvarite ločen klaster za vse instance določenega programa:
Klaster za aplikacijo
Takšna pot se lahko obravnava kot posplošitev načela „ločen klaster za ekipo“, saj običajno ekipa inženirjev razvija eno ali več aplikacij.
Poglejmo prednosti in slabosti tega pristopa.
+ Klaster je mogoče prilagoditi aplikaciji
Če ima aplikacija posebne potrebe, jih je mogoče uresničiti v klastru, ne da bi vplivali na druge klastre.
Takšne potrebe lahko vključujejo delavce z GPU, določene CNI vtičnike, mrežo storitev ali kakšno drugo storitev.
Vsak klaster je mogoče prilagoditi aplikaciji, ki deluje v njem, tako da vsebuje le tisto, kar je potrebno.
− Različna okolja v enem klastru
Pomanjkljivost tega pristopa je, da instance aplikacij iz različnih okolij sobivajo v enem klastru.
Na primer, produkcijska različica aplikacije deluje v istem klastru kot različica za razvoj. To prav tako pomeni, da razvijalci delujejo v istem klastru, v katerem deluje produkcijska različica aplikacije.
Če pride do okvare v klastru zaradi dejanj razvijalcev ali napak v verziji za razvoj, lahko potencialno trpi tudi produkcijska različica — kar je ogromen minus tega pristopa.
In končno, zadnji scenarij na našem seznamu.
4. En klaster za vsako okolje
Ta scenarij predvideva dodelitev ločenega klastru za vsako okolje:
En klaster za okolje
Na primer, lahko imate klastre dev, test in prod, v katerih boste zagnali vse instance aplikacij, namenjene določenemu okolju.
Tukaj so prednosti in slabosti tega pristopa.
+ Izolacija produkcijskega okolja
V okviru tega pristopa so vsa okolja medsebojno izolirana. V praksi je to še posebej pomembno za produkcijsko okolje.
Produkcijske različice aplikacij zdaj niso odvisne od dogajanja v drugih grozdih in okoljih.
Tako, če v razvojnem grozdu pride do težave, produkcijske različice aplikacij nadaljujejo z delovanjem, kot da se nič ni zgodilo.
+ Grozd se lahko prilagodi okolju
Vsak grozd se lahko prilagodi svojemu okolju. Na primer, lahko:
- namestite orodja za razvoj in odpravljanje napak v razvojnem grozdu;
- namestite testne okvire in orodja v grozdu test;
- uporabite zmogljivejšo opremo in omrežne povezave v grozdu prod.
To povečuje učinkovitost tako pri razvoju kot pri delovanju aplikacij.
+ Omejitev dostopa do produkcijskega grozda
Potreba po neposrednem delu s produkcijskim grozdom se redko pojavi, zato lahko znatno omejite krog oseb, ki imajo dostop do njega.
Lahko greste še dlje in popolnoma odvzamete dostop ljudem do tega grozda, vse uvajanje pa izvajate z avtomatiziranim orodjem CI/CD. Tak pristop znatno zmanjša tveganje človeških napak ravno tam, kjer je to najbolj aktualno.
Sedaj pa nekaj besed o slabostih.
− Pomanjkanje izolacije med aplikacijami
Glavna slabost pristopa je pomanjkanje strojne in zmogljivostne izolacije med aplikacijami.
Nesrelatedne aplikacije skupaj uporabljajo vire grozda: jedro sistema, procesor, pomnilnik in nekatere druge storitve.
Kot je bilo že omenjeno, je to lahko potencialno nevarno.
− Nemogoče lokalizirati odvisnosti aplikacij
Če ima aplikacija posebne zahteve, jih je treba izpolniti v vseh grozdih.
Na primer, če aplikaciji potrebujete GPU, mora vsak grozd vsebovati vsaj enega delavca z GPU (tudi če ga uporablja samo ta aplikacija).
Zaradi tega tvegamo višje stroške in neučinkovito uporabo virov.
Zaključek
Ob prisotnosti določenega nabora aplikacij jih lahko postavimo v več velikih grozdih ali v številnih majhnih.
V članku so obravnavane prednosti in slabosti različnih pristopov, od enega globalnega grozda do več manjših in specializiranih:
- en velik skupni klaster;
- veliko majhnih specializiranih grozdov;
- en grozd za vsako aplikacijo;
- en grozd za vsako okolje.
Torej, katero pristop izbrati?
Kot ponavadi je odgovor odvisen od uporabe: potrebno je pretehtati prednosti in slabosti različnih pristopov ter izbrati najbolj optimalno rešitev.
Vendar pa izbira ni omejena le na zgoraj navedene primere — lahko uporabimo katerokoli kombinacijo!
Na primer, lahko organizirate par klasterjev za vsak tim: klaster za razvoj (v katerem bodo okolja dev in test) in klaster za production (kjer bo produkcijsko okolje).
Na podlagi informacij v tem članku boste lahko ustrezno optimizirali prednosti in slabosti za konkretno uporabo. Srečno!
P.S.
Preberite tudi na našem blogu:
- «»;
- «»;
- «»;
- «».
Izvor: habr.com
