Kubernetes-klastrite projekteerimine: kui palju neid peaks olema?

Märkus tõlke kohta.: see materjal haridusprojektist learnk8s — vastus populaarsele küsimusele Kubernetesiga põhineva infrastruktuuri projekteerimisel. Loodame, et piisavalt põhjalikud iga variandi plusse ja miinuseid käsitlevad kirjeldused aitavad teil teha teie projekti jaoks optimaalse valiku.

TL;DR: sama töökoormuse kogumit saab käivitada mitmetes suurtes klastrites (iga kluster võtab enda alla suure hulga töökoormusi) või paljusid väikseid (iga klester sisaldab vähe töökoormust).

Allpool on tabel, milles hinnatakse iga lähenemise plusse ja miinuseid:

Kubernetes'e kasutamisel rakenduste haldamise platvormina tekivad sageli mõned põhiküsimused klastrite seadistamise nüansside kohta:

• Kui palju klastreid kasutada?
• Kui suured need peaksid olema?
• Mida peaks iga kluster sisaldama?

Selles artiklis proovin vastata kõikidele nendele küsimustele, analüüsides iga lähenemise plusse ja miinuseid.

Küsimuse püstitamine

Tarkvara looja, arvatavasti arendate ja hallate mitmeid rakendusi samal ajal.

Lisaks käivitatakse tõenäoliselt nende rakenduste mitmed eksemplarid erinevates keskkondades — näiteks võivad need olla dev, test ja prod.

Tulemusena tekib terve rakenduste ja keskkondade maatriks:

Rakendused ja keskkonnad

Ülaltoodud näites on esitatud 3 rakendust ja 3 keskkonda, mis kokku annab 9 võimalikku varianti.

Iga rakenduse eksemplar on iseseisev deployment-üksus, millega saab töötada sõltumatult teistest.

Pange tähele, et rakenduse eksemplar võib koosneda paljusid komponendid, nagu frontend, backend, andmebaas jne. Mikroteenuse rakenduse puhul sisaldab eksemplar kõiki mikroteenuseid.

Tulemuseks tekivad Kubernetes'e kasutajatel mitmed küsimused:

• Kas kõiki rakenduse eksemplare peaks olema ühes klastris?
• Kas peaks töötama eraldi kluster iga rakenduse eksemplari jaoks?
• Või võib-olla tuleks kasutada ülaltoodud lähenemiste kombinatsiooni?

Kõik need variandid on täiesti elujõulised, kuna Kubernetes on paindlik süsteem, mis ei piira kasutaja võimalusi.

Siin on mõned võimalikud teed:

• üks suur ühine klaster;
• palju väikeseid kitsalt spetsialiseeritud klastri;
• üks klaster iga rakenduse jaoks;
• üks klaster iga keskkonna jaoks.

Nagu allpool näidatud, on kaks esimest lähenemist skaala variantide vastupidistes otsades:

Mitmest suurest klastrist (vasakul) kuni paljude väikesteni (paremal)

Üldiselt peetakse üht klastrit "suuremaks" kui teist, kui sellel on rohkem sõlmedes ja pod'id. Näiteks on klaster, millel on 10 sõlme ja 100 pod'i, suurem klastrist, millel on 1 sõlm ja 10 pod'i.

Nojah, alustagem!

1. Üks suur ühine klaster

Esimene valik on paigutada kõik töökoormused ühte klastrisse:

Üks suur klaster

Selle lähenemise kohaselt kasutatakse klastrit universaalse infrastruktuuri platvormina — kõik vajalik on lihtsalt olemasolevas Kubernetes klastris.

Namespace'id Kubernetes võimaldab loogiliselt eraldada klastriosa üksteisest, nii et iga rakenduse eksemplari jaoks saab kasutada oma ruumi.

Vaadakem selle lähenemise plusse ja miinuseid.

+ Tõhus ressursside kasutamine

Ainus klaster nõuab vaid ühte koopiat kõigist ressurssidest, mis on vajalikud Kubernetes klastrite käitamiseks ja haldamiseks.

Näiteks kehtib see master-sõlmede kohta. Tavaliselt on igal Kubernetes klastril 3 master-sõlme, nii et ühes ainsas klastris jääb nende arv selleks (võrdluseks, 10 klastrisse vajatakse 30 master-sõlme).

Ülaltoodud nüanss kehtib ka teiste teenuste suhtes, mis toimivad kogu klastris, nagu koormuse tasakaalustajad, Ingress'i kontrollerid, autentimissüsteemid, logimise ja jälgimise süsteemid.

Ühes klastris saab kasutada kõiki neid teenuseid kõigi töökoormuste jaoks (ei ole vaja luua nende koopiaid, nagu mitme klastriga).

+ Odavus

Nagu eelnevalt mainitud, on väiksem arv klastreid tavaliselt odavam, kuna puuduvad kulud liigsetele ressurssidele.

See kehtib eriti master-sõlmede kohta, mis võivad maksma minna, olenemata paigutusviisist (on-premises või pilves).

Mõned hallatud Kubernetes teenused, nagu Google Kubernetes Engine (GKE) või Azure Kubernetes Service (AKS), pakuvad tasuta haldustasandi. Sel juhul on kulude küsimus vähem terav.

Samuti on olemas hallatud teenused, mis küsivad fikseeritud tasu iga Kubernetesi klastrite töö eest (näiteks, Amazon Elastic Kubernetes Service, EKS).

+ Tõhus haldamine

Ühe klasteri haldamine on lihtsam kui mitme.

Haldamine võib hõlmata järgmisi ülesandeid:

• Kubernetes'i versiooni uuendamine;
• CI/CD kanali seadistamine;
• CNI pistikprogrammi installimine;
• Kasutajate autentimissüsteemi seadistamine;
• Juhtimise kontrolleri installimine;

ja palju teisi…

Ühe klasteri korral tuleb sellega tegeleda ainult üks kord.

Mitmete klastrite puhul tuleb operatsioone korduvalt läbi viia, mis võib vajada mingit automatiseerimist ja tööriistu, et tagada protsessi süsteemsus ja ühtsus.

Nüüd on mõned sõnad miinustest.

− Üksik ebaõnnestumise punt

Kui ainus klaster ebaõnnestub, lõpetavad koheselt kõik töötavad koormused töö!

On palju olukordi, kus midagi võib valesti minna:

• Kubernetes'i uuendamine toob ootamatuid kõrvalmõjusid;
• üldklastri komponent (nt CNI pistikprogramm) hakkab toimima mitte ootuspäraselt;
• üks klastrikomponent on vale seadistusega;
• rikke alumises infrastruktuuris.

Üks selline juhtum võib põhjustada tõsist kahju kõigile töötavatele koormustele, mis asuvad üldklastri sees.

− Rangete isolatsiooni puudumine

Töötamine üldklastri sees tähendab, et rakendused jagavad sama riistvara, võrgu võimekuse ja operatsioonisüsteemi klastris asuvatel sõlmedel.

Teatud mõttes on kaks konteinerit, millel töötab kaks erinevat rakendust ühe ja sama sõlme peal, sarnased kahele protsessile, mis töötavad ühe masina alla ühe ja sama OS tuuma all.

Linuxi konteinerid pakuvad mingit vormi isolatsiooni, kuid see ei ole nii tugev nagu virtuaalmasinate pakutud. Sisuliselt on konteineris töötav protsess sama, mis töötasu host-operatsioonisüsteemi alla.

See võib olla probleemiks turvalisuse seisukohalt: selline ülesehitus võimaldab teoreetiliselt erinevatel rakendustel üksteisega suhelda (kas tahtlikult või juhuslikult).

Lisaks kasutavad kõik Kubernetes klusteris olevad töökohustused ühiselt mõningaid klusteri teenuseid, nagu DNS — see võimaldab rakendustel leida teiste rakenduste teenuseid klusteris.

Kõik eeltoodud punktid võivad omada erinevat tähendust sõltuvalt rakenduste turvanõuetest.

Kubernetes pakub erinevaid tööriistu turvaprobleemide vältimiseks, nagu PodSecurityPolicies ja NetworkPolicies. Kuid nende korrektseks seadistamiseks on vajalik teatav kogemus, lisaks ei suuda need suletud kõik turvavigu.

Oluline on alati meeles pidada, et Kubernetes loomulikult on loodud koostööks, mitte isoleerimiseks ja turvalisuseks.

− Puudub range multi-tenancy

Arvestades Kubernetes klustrite rohkust, on olemas palju viise, kuidas erinevad rakendused võivad üksteisele 'jalgu astuda'.

Näiteks võib rakendus monopoliseerida mingi ühise ressursi (nt CPU või mälu) ja jätta teised samal sõlmel töötavad rakendused sellelt pääsemata.

Kubernetes tagab erinevaid mehhanisme sellise käitumise kontrollimiseks, nagu ressursside päringud ja piirangud vt ka artiklit « CPU-limiidid ja agressiivne throttling Kubernetes'is » — tõlkija märkus), ResourceQuotas ja LimitRanges. Kuid nagu turvalisuse korral, on nende seadistamine üsna keeruline ja nad ei suuda vältida kõiki ettenägematuid kõrvalmõjusid.

− Suur hulk kasutajaid

Üksiku klustri puhul tuleb sellele anda juurdepääs paljudele inimestele. Mida rohkem inimesi, seda suurem on oht, et nad midagi "katkestavad".

Klastri sees saab kontrollida, kes ja mida teha saab rollipõhise ligipääsu haldusingi (RBAC) kaudu vt artiklit « Kasutajad ja RBAC autoriseerimine Kuberneteses » — tõlkija märkus). Siiski ei takista see kasutajaid "midagi katki tegema" oma vastutusalas.

− Klastrid ei saa lõpmatult kasvada

Klastri, mida kasutatakse kõikide töökohustuste jaoks, on tõenäoliselt väga suur (sõlmede ja pod'ide arvu poolest).

Kuid sellega tekib teine probleem: Kubernetes'e klastrid ei saa lõpmatult kasvada.

Klastri suurusele on teoreetiline piir. Kuberneteses on see umbes 5000 sõlme, 150 000 pod'i ja 300 000 konteinerit.

Kuid reaalses elus võivad probleemid alata palju varem - näiteks vaid 500 sõlmel.

Asi on selles, et suured klastrid koormavad Kubernetes'e juhtimistaset. Teisisõnu, et hoida klastrit töökorras ja ressursse tõhusalt kasutada, on vajalik hoolikas häälestamine.

Seda probleemi käsitletakse vastavas artiklis originaalblogis pealkirjaga „Kubernetes klastrite arhitektuur — töötlussõlme suuruse valimine».

Kuid vaatame vastupidist lähenemist: palju väikeseid klastreid.

2. Palju väikeseid, spetsialiseeritud klastreid

Selle lähenemise korral kasutate iga juurutatava elemendi jaoks eraldi klastrit:

Palju väikeseid klastreid

Selle artikli kontekstis mõistetakse juurutatavana rakenduse eksemplari - näiteks ühe rakenduse dev-versiooni.

Selles strateegias kasutatakse Kubernetes't kui spetsialiseeritud täitmisvõimet erinevate rakenduse eksemplaride jaoks.

Vaadakem selle lähenemise plusse ja miinuseid.

+ Piiratud „plahvatuse raadius“

Klastri „purunemise“ korral piirduvad negatiivsed tagajärjed vaid nende töökoormustega, mis olid juurutatud selles klastri. Kõik teised töökoormused jäävad puutumatuks.

+ Isolatsioon

Iseseisvates klastrites paigutatud töökoormustel puuduvad ühised ressursid, nagu protsessor, mälu, operatsioonisüsteem, võrk või muud teenused.

Tulemuseks on range isolatsioon omavahel seotud rakenduste vahel, mis võib positiivselt mõjutada nende turvalisust.

+ Väike kasutajate arv

Kuna igas klastris on vaid piiratud arv töökoormusi, väheneb sellele pääsupunktide arv.

Mida vähem inimesi pääseb klastrisse, seda madalam on risk, et midagi „katkeb”.

Vaatame puudusi.

− Tõhususe puudumine ressursside kasutuses

Nagu varem mainitud, vajab iga Kubernetes'e klaster teatud hulga juhtimisresources'e: master-sõlmed, juhtimistaseme komponendid, jälgimise ja logimise lahendused.

Paljude väikeste klastrite korral tuleb juhtimisele suunata suurem osa ressursse.

− Kulukus

Ebaefektiivne ressursside kasutamine toob automaatselt kaasa kõrged kulud.

Näiteks 30 master-sõlme sisu asemel kolme sama arvutustehnika puhul kajastub see kindlasti kuludes.

− Halduse keerukus

Kubeclustere haldamine on oluliselt keerulisem kui ühega töötamine.

Näiteks tuleb iga klastrile seadistada autentimine ja autoriseerimine. Kubernetesi versiooniuuendust tuleb samuti teha mitu korda.

Tõenäoliselt tuleb rakendada automatiseerimist, et saavutada nende ülesannete tõhusus.

Nüüd vaatame vähem äärmuslikke stsenaariume.

3. Üks klaster igale rakendusele

Selle lähenemise kohaselt loote iga konkreetse rakenduse kõikide instantside jaoks eraldi klastrite:

Klaster rakendusele

Seda teed võib pidada „eraldiseisva klastri igale meeskonnale”, kuna tavaliselt tegeleb inseneride meeskond ühe või mitme rakenduse arendamisega.

Vaadakem selle lähenemise plusse ja miinuseid.

+ Klaster saab rakendusele kohandada

Kui rakendusel on erilisi vajadusi, saab need klastris ellu viia, mõjutamata teisi klastreid.

Need vajadused võivad hõlmata GPU-d töötavaid töötajaid, teatud CNI pluginaid, teenuse sissihaardumist või mõnd muud teenust.

Iga klaster saab kohandada nii, et see sisaldab ainult seda, mis on vajalik töötavas rakenduses.

− Erinevad keskkonnad ühes klastris

Selle lähenemise puuduseks on see, et erinevate keskkondade rakenduste instantsid elavad ühes klastris koos.

Näiteks prod-versioon rakendusest töötab samas klastris kui dev-versioon. See tähendab ka seda, et arendajad töötavad samas klastris, kus toimib rakenduse tootmisversioon.

Kui arendajate tegevuse või dev-versiooni vead põhjustavad klastris tõrke, võivad potentsiaalselt kannatada ka prod-versioon — see on tohutu puudus sellise lähenemise puhul.

Ja lõpuks, meie nimekirjas viimane stsenaarium.

4. Üks klaster igale keskkonnale

See stsenaarium eeldab igale keskkonnale eraldi klastri eraldamist:

Üks klaster keskkonna jaoks

Näiteks võivad teil olla klastrid dev, test ja prod, kus käitate kõiki rakenduse instantside, mis on mõeldud teatud keskkonna jaoks.

Siin on sellise lähenemise plussid ja miinused.

+ Prod keskkonna isolatsioon

Selle lähenemise raames on kõik keskkonnad teineteisest isoleeritud. Praktiliselt on see eriti oluline prod-keskkonna jaoks.

Rakenduse tootmisversioon ei sõltu nüüd teiste klastrite ja keskkondade tegevusest.

Seega, kui dev-klastris tekib üllatuslik probleem, jätkavad tootmisversioonid tööd nagu poleks midagi juhtunud.

+ Klastri saab kohandada keskkonna järgi

Iga klastrit saab kohandada selle keskkonna järgi. Näiteks saab:

• paigaldada dev-klastrisse arendus- ja tõrkeotsingu tööriistad;
• paigaldada testimisraamistikke ja tööriistu klastrisse test;
• kasutada võimsamat riistvara ja võrguühendusi klastris prod.

See suurendab nii arenduse kui ka rakenduste kasutamise efektiivsust.

+ Juurdepääsu piiramine tootmis-klastrile

Vajadus töötada otse prod-klastriga tekib harva, seetõttu saab oluliselt piirata isikute ringi, kellel on sellele juurdepääs.

Saame minna veelgi kaugemale ja võtta inimestelt täielikult juurdepääs sellele klastrile, ning kõik juurutamised teha automatiseeritud CI/CD tööriista abil. Selline lähenemine vähendab oluliselt inimlike vigade riski seal, kus see on kõige kriitilisem.

Nüüd on mõned sõnad miinustest.

− Erinevuste puudumine rakenduste vahel

Peamine puudus on rakenduste vahelise riist- ja ressursi eraldatuse puudumine.

Sidumata rakendused kasutavad koos klastrite ressursse: süsteemi kerneli, protsessorit, mälu ja mõned muud teenused.

Nagu juba mainitud, võib see potentsiaalselt olla ohtlik.

− Rakenduste sõltuvuste lokaliseerimise võimatus

Kui rakendusel on erilised nõuded, tuleb neid rahuldada kõigis klastrites.

Näiteks, kui rakendus vajab GPU-d, peab igas klastris olema vähemalt üks töötleja GPU-ga (isegi kui seda kasutatakse ainult selle rakenduse poolt).

Tulemuseks on kõrgemad kulud ja ebaefektiivne ressursside kasutamine.

Kokkuvõte

Teatud rakenduste komplekti korral saab neid paigutada mitmesse suuresse klastrisse või paljusid pisikesi.

Artiklis käsitletakse erinevate lähenemisviiside plusse ja miinuseid, alates ühest globaalsest klastrist kuni mitme väikese ja kitsalt spetsialiseeritud klastrini:

• üks suur ühine klaster;
• palju väikeseid kitsalt spetsialiseeritud klastri;
• üks klaster iga rakenduse jaoks;
• üks klaster iga keskkonna jaoks.

Nii et, millist lähenemist valida?

Kuidas tavaliselt, sõltub vastus kasutusstsenaariumist: peate kaaluma erinevate lähenemisviiside plusse ja miinuseid ning valima optimaalse variandi.

Kuid valik ei piirdu ainult eelpooltoodud näidetega - võite kasutada mis tahes nende kombinatsiooni!

Näiteks, võite korraldada paar klastrit iga tiimi jaoks: klaster arendamiseks (kus on keskkonnad dev ja test) ja klaster production (kus asub tootmis keskkond).

Tuginedes sellele artiklile, suudate vastavalt optimeerida plussid ja miinused konkreetse stsenaariumi jaoks. Edu!

P.S.

Lugege ka meie blogist:

• «Visuaalne juhend Kubernetesi tõrkeotsinguks»;
• «Logid Kuberneteses (ja mitte ainult) täna: ootused ja reaalsus»;
• «Service Mesh: mida iga tarkvarainsener peab teadma kõige kuumemast tehnoloogiast»;
• «Kubernetes’i turvalisuse abecedaar: autentimine, autoriseerimine, audit».

Allikas: habr.com