Märk. tõlge.: see this material from the educational project — the answer to a popular question when designing infrastructure based on Kubernetes. We hope that the sufficiently detailed descriptions of the pros and cons of each option will help you make the best choice for your project.
TL;DR: the same set of workloads can be run on several large clusters (with a large number of workloads per cluster) or on many smaller ones (with a small number of workloads in each cluster).
Below is a table evaluating the pros and cons of each approach:
When using Kubernetes as a platform for application operations, several fundamental questions about cluster configuration often arise:
- How many clusters to use?
- How large should they be?
- What should each cluster include?
In this article, I will try to answer all these questions by analyzing the pros and cons of each approach.
The question posed
As a software creator, you are likely developing and operating multiple applications simultaneously.
Lisaks sellele töötab kindlasti palju nende rakenduste koopiaid erinevates keskkondades — näiteks võivad need olla dev, test ja prod.
Tulemusena saame terviku rakenduste ja keskkondade maatriksi:
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 komponente, nagu frontend, backend, andmebaas jne. Mikroteenuste rakenduse korral sisaldab eksemplar kõiki mikroteenuseid.
Seetõttu tõstatavad Kubernetes'e kasutajad mitmeid küsimusi:
- Kas tuleks kõik rakenduse eksemplarid paigutada ühte klastrisse?
- Kas tuleks iga rakenduse eksemplari jaoks luua eraldi klaster?
- Või võib-olla tuleks kasutada kombinatsiooni eespool mainitud lähenemistest?
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õimalused:
- üks suur ühine klastri;
- mitu väikest kitsalt spetsialiseerunud klastrit;
- üks klaster iga rakenduse jaoks;
- üks klaster iga keskkonna jaoks.
Nagu allpool näidatud, on kaks esimest lähenemist skaalal vastassuunal:
Mõnest suurest klastrist (vasakul) kuni paljude väikesteni (paremal)
Üldiselt loetakse, et üks klaster on "suurem" kui teine, kui tal on rohkem sõlmi ja pod'e. Näiteks kluster, kus on 10 sõlme ja 100 pod'i, on suurem kui kluster, kus on 1 sõlm ja 10 pod'i.
Nojah, alustame!
1. Üks suur ühine klaster
Esimene variant on paigutada kõik töökoormused ühte klastrisse:
Üks suur klaster
Selle lähenemise raames kasutatakse klastrit universaalse infrastruktuuri platvormina — kõik, mis vajalik, on lihtsalt olemasolevas Kubernetes klastris paigutatud.
Kubernetes võimaldab klastris osi üksteisest loogiliselt eraldada, mistõttu iga rakenduse eksemplarile saab kasutada oma nimeala.
Vaatame selle lähenemise plusse ja miinuseid.
+ Tõhus resursside kasutamine
Ainult ühe klastriga on vajalik ainult üks koopia kõikidest ressurssidest, mis on vajalikud Kubernetesi klastri käivitamiseks ja haldamiseks.
Näiteks kehtib see master-sõlmede kohta. Ühe Kubernetesi klastri kohta on tavaliselt 3 master-sõlme, seega jääb nende arv ühele klastrile samaks (võrdluseks, 10 klastrile on vaja 30 master-sõlme).
Ülaltoodud nüanss kehtib ka teiste teenuste kohta, mis toimivad klastris laiemalt, nagu koormuse tasakaalustajad, Ingressi kontrollerid, autentimise, logimise ja jälgimise süsteemid.
Ühes klastri kõik neid teenuseid saab kasutada kohe kõigi töökoormuste jaoks (pole vaja luua nende koopiaid, nagu mitme klastriga).
+ Odavus
Seetõttu maksab väiksem arv klastreid tavaliselt vähem, kuna puuduvad kulutused üleliigsetele ressurssidele.
See kehtib eriti master-sõlmede kohta, millel võivad olla märkimisväärsed kulud, sõltumata majutamisviisist (kas kohapeal või pilves).
Mõned hallatud Kubernetes teenused, nagu või , pakuvad tasuta haldustaseme. Sellisel juhul on kuluküsimus vähem terav.
Samuti on olemas hallatud teenused, mis küsivad fikseeritud tasu iga Kubernetes'i klastrite töö eest (näiteks, ).
+ Tõhus haldus
Üht klastrit on lihtsam hallata kui mitut.
Haldus võib hõlmata järgmisi ülesandeid:
- Kubernetes'e versiooni värskendamine;
- CI/CD torujuhtme seadistamine;
- CNI pistiku installimine;
- Kasutaja autentimissüsteemi seadistamine;
- Luba kontrolleri installimine;
ja palju muud…
Ühe klastriga on vaja seda kõike teha ainult üks kord.
Mitme klastri puhul tuleb operatsioone korduvalt korrata, mis tõenäoliselt vajab protsesside ja tööriistade automatiseerimist, et tagada järjepidevus ja ühtsus.
Ja nüüd paar sõna puudustest.
− Üksik rikkepunkt
Üksiku klastri rikke korral lakka vahetult töötama kõik koormused!
On tohutult võimalusi, kus midagi võiks valesti minna:
- Kubernetes'e värskendamine toob ootamatud kõrvaltoimed;
- üldklastrikomponent (näiteks CNI pistikprogramm) käivitub ootamatult;
- üks grupi komponentidest on valesti seadistatud;
- aluseks oleva infrastruktuuri rike.
Üks selline juhtum võib tõsiselt kahjustada kõiki töökoormusi, mis on paigutatud üldklastrisse.
− Rangete isoleerimise puudumine
Töötamine üldklastris tähendab, et rakendused jagavad riistvara, võrguvõimalusi ja operatsioonisüsteemi klastrisõlmede vahel.
Mõnes mõttes on kaks konteinerit, kus töötab kaks erinevat rakendust samas sõlmes, sarnased kahele protsessile, mis töötavad ühel ja samal masinal sama operatsioonisüsteemi tuuma all.
Linuxi konteinerid pakuvad mingit vormi isoleerimisest, kuid see ei ole sugugi nii tugev, kui näiteks virtuaalmasinate korral. Põhimõtteliselt on konteineris olev protsess sama protsess, mis käivitatakse hostoperatsioonisüsteemis.
See võib olla turvalisuse seisukohalt probleem: selline korraldus võimaldab teoreetiliselt omavahel seotud rakendustel üksteisega suhelda (kas teadlikult või kogemata).
Lisaks kasutavad kõik Kubernetes klastri töökoormused ühiselt mõningaid klastriteenuseid, nagu — see võimaldab rakendustel leida teiste rakenduste teenuseid klastris.
Kõigil ülaltoodud punktidel võib olla erinev tähendus sõltuvalt rakenduste turvanõuetest.
Kubernetes pakub erinevaid tööriistu turvaprobleemide vältimiseks, nagu ja . Kuid nende õige seadistamine nõuab teatud kogemust, pealegi ei ole nad võimelised sulgema absoluutselt kõiki turvaauke.
Oluline on alati meeles pidada, et Kubernetes on algselt loodud koostööks, mitte isolatsiooni ja turvalisuse.
− Jõhkralt puudub multi-tenancy.
Arvestades Kubernetes klastri hulka ühiseid ressursse, on palju viise, kuidas erinevad rakendused võivad üksteisele “peale astuda”.
Näiteks võib rakendus monopoliseerida mõne ühise ressursi (nagu protsessor või mälu) ja jätta teised rakendused, mis töötavad samas sõlmes, sellest ilma.
Kubernetes tagab erinevad mehhanismid sellise käitumise kontrollimiseks, nagu vt ka artiklit «» — tõlk. märkus), ja . Siiski, nagu ka turvalisuse puhul, on nende seadistamine piisavalt keeruline ja need ei suuda vältida kõiki ettenägematuid kõrvalmõjusid.
− Suur hulk kasutajaid
Ühe klastriga peab juurdepääsu avama paljudele inimestele. Ja mida rohkem neid on, seda suurem on risk, et nad midagi "katkestavad".
Klastri sees saab hallata, kes ja mida teha saab, kasutades vt artiklit «» — tõlk. märkus). Siiski ei takista see kasutajaid "katkestamast" midagi oma vastutusala piires.
− Klastrid ei saa kasvama kuni lõpmatuseni
Klastrid, mida kasutatakse kõigi töökoormuste jaoks, on tõenäoliselt üsna suured (node'ide ja pod'ide arvult).
Kuid siin tekib teine probleem: Kuberneteses ei saa klastrid kasvada lõpmatuseni.
Klastri suuruse teoreetiline piir on olemas. Kuberneteses on see ligikaudu .
Kuid tegelikus elus võivad probleemid alata palju varem – näiteks juba 500 node'iga. .
Seda probleemi uuritakse vastavas artiklis algses päevas, pealkirjaga «
Architecting Kubernetes clusters — choosing a worker node size».
2. Palju väikeseid, spetsialiseeritud klastreid.
Selle lähenemise korral kasutate iga paigaldatava elemendi jaoks eraldi klastrit:
Palju väikeseid klustreid.
Käesoleva artikli eesmärkidel peame
paigaldatavaks elemendiks juurutatud element rakendusinstance mõistetakse - näiteks, arenduse versioon eraldiseisvast rakendusest.
Selles strateegias kasutatakse Kubernetes't kui spetsialiseeritud käituskeskkonda erakordsete rakenduste jaoks.
Vaatame selle lähenemise plusse ja miinuseid.
+ Piiratud "plahvatuse ring"
Klaster "purunemise" korral piirdub negatiivne mõju vaid nende töökoormustega, mis olid selles klastris juurutatud. Kõik teised töökoormused jäävad puutumatuks.
+ Isolatsioon
Eraldatud klastrites paigutatud töökoormustel ei ole ühiseid ressursse, nagu protsessor, mälu, opsüsteem, võrk või muud teenused.
Tulemuseks on range isolatsioon omavahel seotud rakenduste vahel, mis võib soodsalt mõjutada nende turvalisust.
+ Väike kasutajate arv
Kuna igas klastris on vaid piiratud arv töökoormusi, väheneb sellele juurdepääsu saavate kasutajate arv.
Mida vähem inimesi pääseb klastrile ligi, seda madalam on risk, et midagi "katki läheb".
Vaatame miinuseid.
− Ressursside ebaefektiivne kasutamine
Nagu varem mainitud, vajab iga Kubernetes'i klaster teatud haldusressursse: master-sõlmed, kontrollitasandi komponendid, jälgimis- ja logimislahendused.
Kui on palju väikse väikseid klastreid, tuleb rohkem ressursse eraldada halduseks.
− Kulukus
Ebatõhus ressursikasutus toob automaatselt kaasa kõrged kulud.
Näiteks 30 master-sõlme hoidmine kolme asemel sama arvutusvõimsuse juures mõjutab kindlasti kulusid.
− Halduse keerukus
Paljude Kubernetes'i klastrite haldamine on palju keerulisem kui ühega töötamine.
Näiteks tuleb iga klastrite jaoks seadistada autentimine ja autoriseerimine. Kubernetes'i versiooniuuendust tuleb samuti teha mitu korda.
Tõenäoliselt tuleb rakendada automatiseerimist, et suurendada nende ülesannete tõhusust.
Nüüd vaatame vähem äärmuslikke stsenaariume.
3. Üks klaster iga rakenduse jaoks
Selle lähenemise raames loote eraldi klastri kõigi konkreetse rakenduse eksemplaride jaoks:
Rakenduse klaster
Seda teed võib pidada põhimõtte «erinev klaster meeskonna jaoks» üldistamiseks, kuna tavaliselt tegeleb inseneride meeskond ühe või mitme rakenduse arendamisega.
Vaatame selle lähenemise plusse ja miinuseid.
+ Klastrit saab rakendusele kohandada
Kui rakendusel on erilised vajadused, saab neid klastri sees ellu viia, mõjutamata teisi klastreid.
Sellised vajadused võivad hõlmata GPU-dega worker’ite, teatud CNI pluginate, teenuse võrgu või mõne muu teenuse kasutamist.
Iga klaster saab kohandada töötavale rakendusele, et see sisaldaks ainult vajalikke elemente.
− Erinevad keskkonnad ühes klastris
Selle lähenemise miinuseks on see, et erinevate keskkondade rakenduse eksemplarid eksisteerivad ühes klastris.
Näiteks töötab rakenduse prod-version samas klastris nagu dev-version. See tähendab ka, et arendajad tegutsevad samas klastris, kus toodang on rakenduse versioon.
Kui arendajate tegevuse või dev-versiooni vead põhjustavad klastris rikke, võib potentsiaalselt kannatada ka prod-version — selle lähenemise suur puudus.
Ja lõpuks, viimane stsenaarium meie nimekirjas.
4. Üks klaster igas keskkonnas
See stsenaarium näeb ette igas keskkonnas eraldi klastri eraldamist:
Üks klaster iga keskkonna jaoks
Näiteks võivad teil olla klastrid, dev, test ja prod, kus käitate kõiki rakenduse eksemplare, mis on mõeldud kindlale keskkonnale.
Siin on selle lähenemise plussid ja miinused.
+ Produktiivsete keskkondade isoleerimine
Selle lähenemise raames on kõik keskkonnad teineteisest isoleeritud. Kuid praktikas on see eriti oluline tootmiskeskkonna jaoks.
Rakenduse tootmisversioonid ei sõltu enam muudest klastritest ja keskkondadest.
Nii et kui dev-klastris tekib äkki probleem, jätkavad tootmisversioonid töötamist nagu midagi ei juhtunud.
+ Klastrit saab kohandada keskkonna järgi
Iga klastrit saab kohandada oma keskkonna jaoks. Näiteks võib:
- paigaldada dev-klastrisse arendamise ja tõrkeotsingu tööriistad;
- paigaldada testimisraamistikke ja tööriistu klastrisse test;
- kasutada klastris võimsamat riistvara ja võrguühendusi. prod.
See aitab suurendada nii arenduse kui ka rakenduste haldamise tõhusust.
+ Juhtimise piiramine production-klastrisse
Otsene töötamine prod-klastriga on haruldane, seega on võimalik oluliselt piirata neid, kellel on sellele juurdepääs.
Saame minna veelgi kaugemale ja täiesti keelata inimeste juurdepääsu sellele klastrile, tehes kõik juurutamised automatiseeritud CI/CD tööriista abil. Selline lähenemine vähendab inimlike vigade riski just seal, kus see on kõige olulisem.
Ja nüüd paar sõna puudustest.
− Aparaadi ja ressursside isolatsiooni puudumine rakenduste vahel
Peamine puudus on see, et rakenduste vahel puudub riistvara ja ressursside isolatsioon.
Üksikud rakendused kasutavad koos klastrite ressursside süsteemi, protsessorit, mälu ja mõningaid teisi teenuseid.
Nagu juba mainitud, võib see osutuda potentsiaalselt ohtlikuks.
− Rakenduste sõltuvuste lokaliseerimise võimatus
Kui rakendusel on erilised nõudmised, tuleb neid täita kõigis klastrites.
Näiteks, kui rakendus vajab GPU-d, peab iga klaster sisaldama vähemalt ühte GPU-ga töötlusüksust (isegi kui seda kasutatakse ainult selle rakenduse poolt).
Tulemuseks on suuremad kulud ja ebaefektiivne ressursside kasutamine.
Kokkuvõte
Kuna on olemas teatud rakenduste komplekt, saab need paigutada paarisse suurtesse klastritesse või paljudesse väikestesse.
Artiklis käsitletakse erinevate lähenemisviiside plusse ja miinuseid, alates ühest globaalsest klastrist kuni paljude väikeste ja kitsaste:
- üks suur ühisklaster;
- mitu väikest kitsalt spetsialiseerunud klastrit;
- üks klaster iga rakenduse jaoks;
- üks klaster iga keskkonna jaoks.
Niisiis, millist lähenemist valida?
Nagu tavaliselt, sõltub vastus kasutusstsenaariumist: tuleb kaaluda erinevate lähenemisviiside plusse ja miinuseid ning valida kõige optimaalsem variant.
Kuid valik ei piirdu ainult eespool toodud näidetega – võib rakendada igasugust kombinatsiooni!
Näiteks võib korraldada igale meeskonnale paar klastrit: arenduse klaster (kus on keskkonnad dev ja test) ja klaster tootmisse (kus asub tootmiskeskkond).
Tuginedes sellele artiklile, saate vastavalt optimeerida iga variandi plussid ja miinused konkreetse stsenaariumi jaoks. Edu!
P.S.
Lugege ka meie blogist:
- «»;
- «»;
- «»;
- «».
Allikas: habr.com
