Shënim. përkth.: ky material është nga një projekt edukativ është përgjigjja e një pyetjeje popullore gjatë dizajnimit të infrastrukturës së bazuar në Kubernetes. Shpresojmë që përshkrimet mjaft të detajuara të të mirat dhe të këqijat e secilit opsion do t'ju ndihmojnë të bëni zgjedhjen më të mirë për projektin tuaj.
TL; DR: i njëjti grup ngarkesash pune mund të ekzekutohet në disa grupime të mëdha (çdo grup do të ketë një numër të madh ngarkesash pune) ose në shumë të vogla (me një numër të vogël ngarkesash në secilin grup).
Më poshtë është një tabelë që vlerëson të mirat dhe të këqijat e secilës qasje:
Kur përdorni Kubernetes si një platformë për ekzekutimin e aplikacioneve, shpesh lindin disa pyetje themelore në lidhje me ndërlikimet e konfigurimit të grupimeve:
- Sa grupe duhet të përdor?
- Sa të mëdha duhet t'i bëj ato?
- Çfarë duhet të përfshijë çdo grup?
Në këtë artikull, do të përpiqem t'u përgjigjem të gjitha këtyre pyetjeve duke analizuar të mirat dhe të këqijat e secilës qasje.
Deklarata e një pyetjeje
Si një zhvillues softuerësh, ju ka të ngjarë të zhvilloni dhe të përdorni shumë aplikacione në të njëjtën kohë.
Përveç kësaj, shumë raste të këtyre aplikacioneve ka të ngjarë të ekzekutohen në mjedise të ndryshme - për shembull, këto mund të jenë dev, provë и stimuloj.
Rezultati është një matricë e tërë e aplikacioneve dhe mjediseve:
Aplikacionet dhe Mjediset
Shembulli i mësipërm përfaqëson 3 aplikacione dhe 3 mjedise, duke rezultuar në një total prej 9 opsionesh të mundshme.
Çdo shembull aplikacioni është një njësi vendosjeje e pavarur me të cilën mund të punohet në mënyrë të pavarur nga të tjerët.
Vini re se shembull aplikimi mund të përbëhet nga shumë komponentët, të tilla si frontend, backend, databaza, etj. Në rastin e një aplikacioni për mikroshërbime, shembulli do të përfshijë të gjitha mikroshërbimet.
Si rezultat, përdoruesit e Kubernetes kanë disa pyetje:
- A duhet të vendosen të gjitha rastet e aplikacionit në një grup?
- A ia vlen të kesh një grup të veçantë për çdo shembull aplikacioni?
- Apo ndoshta duhet përdorur një kombinim i qasjeve të mësipërme?
Të gjitha këto opsione janë mjaft të zbatueshme, pasi Kubernetes është një sistem fleksibël që nuk kufizon aftësitë e përdoruesit.
Këtu janë disa nga mënyrat e mundshme:
- një grup i madh i përbashkët;
- shumë grupime të vogla shumë të specializuara;
- një grup për aplikim;
- një grup për çdo mjedis.
Siç tregohet më poshtë, dy qasjet e para janë në skajet e kundërta të shkallës së opsioneve:
Nga disa grupime të mëdha (majtas) në shumë të vogla (djathtas)
Në përgjithësi, një grup konsiderohet "më i madh" se një tjetër nëse ka një shumë më të madhe nyjesh dhe pods. Për shembull, një grup me 10 nyje dhe 100 pods është më i madh se një grup me 1 nyje dhe 10 pods.
Epo, le të fillojmë!
1. Një grup i madh i përbashkët
Opsioni i parë është të vendosni të gjitha ngarkesat e punës në një grup:
Një grup i madh
Brenda kësaj qasjeje, grupi përdoret si një universal platforma infrastrukturore - thjesht vendosni gjithçka që ju nevojitet në një grup ekzistues Kubernetes.
Kubernetes lejon që pjesët e grupit të ndahen logjikisht nga njëra-tjetra, në mënyrë që çdo shembull i aplikacionit të ketë hapësirën e vet të emrave.
Le të shohim të mirat dhe të këqijat e kësaj qasjeje.
+ Përdorimi efikas i burimeve
Me një grup të vetëm, ju nevojitet vetëm një kopje e të gjitha burimeve të nevojshme për të ekzekutuar dhe menaxhuar grupin Kubernetes.
Për shembull, kjo është e vërtetë për nyjet master. Në mënyrë tipike, çdo grup Kubernetes ka 3 nyje kryesore, kështu që për një grup të vetëm numri i tyre do të mbetet i tillë (për krahasim, 10 grupe do të kenë nevojë për 30 nyje kryesore).
Hollësia e mësipërme vlen edhe për shërbime të tjera që operojnë në të gjithë grupin, si balancuesit e ngarkesës, kontrolluesit e hyrjes, vërtetimi, regjistrimi dhe sistemet e monitorimit.
Në një grup të vetëm, të gjitha këto shërbime mund të përdoren menjëherë për të gjitha ngarkesat e punës (nuk ka nevojë të krijohen kopje të tyre, siç është rasti me grupe të shumta).
+ Lirë
Si pasojë e sa më sipër, më pak grupime janë zakonisht më të lira sepse nuk ka kosto të përgjithshme.
Kjo është veçanërisht e vërtetë për nyjet kryesore, të cilat mund të kushtojnë një shumë të konsiderueshme parash, pavarësisht se si janë pritur (në ambiente ose në cloud).
Disa shërbime të menaxhuara të Kubernetes, si p.sh ose , siguroni shtresën e kontrollit falas. Në këtë rast, çështja e kostos është më pak e mprehtë.
Ekzistojnë gjithashtu shërbime të menaxhuara që paguajnë një tarifë fikse për funksionimin e çdo grupi Kubernetes (për shembull, ).
+ Administrim efikas
Menaxhimi i një grupi është më i lehtë sesa menaxhimi i disa.
Administrata mund të përfshijë detyrat e mëposhtme:
- Përditësimi i versionit të Kubernetes;
- ngritja e një tubacioni CI/CD;
- instalimi i shtojcës CNI;
- vendosja e një sistemi të vërtetimit të përdoruesit;
- instalimi i një kontrolluesi të aksesit;
dhe shume te tjere…
Në rastin e një grupi, do t'ju duhet ta bëni të gjithë këtë vetëm një herë.
Për shumë grupe, operacionet do të duhet të përsëriten shumë herë, gjë që ka të ngjarë të kërkojë njëfarë automatizimi të proceseve dhe mjeteve për të siguruar qëndrueshmëri dhe qëndrueshmëri në proces.
Dhe tani disa fjalë për të këqijat.
− Pika e vetme e dështimit
Në rast refuzimi i vetmi grupi do të ndalojë së punuari menjëherë të gjithë ngarkesat e punës!
Ka shumë mënyra se si gjërat mund të shkojnë keq:
- përditësimi i Kubernetes çon në efekte anësore të papritura;
- Një komponent në të gjithë grupin (për shembull, një shtesë CNI) fillon të mos funksionojë siç pritej;
- një nga komponentët e grupit nuk është konfiguruar saktë;
- dështimi në infrastrukturën bazë.
Një incident i tillë mund të shkaktojë dëme serioze në të gjitha ngarkesat e punës të vendosura në një grup të përbashkët.
− Nuk ka izolim të ngurtë
Ekzekutimi në një grup të përbashkët do të thotë që aplikacionet ndajnë harduerin, aftësitë e rrjetit dhe sistemin operativ në nyjet e grupit.
Në një farë kuptimi, dy kontejnerë me dy aplikacione të ndryshme që funksionojnë në të njëjtën nyje janë si dy procese që ekzekutohen në të njëjtën makinë që ekzekutojnë të njëjtin kernel OS.
Kontejnerët Linux ofrojnë një formë izolimi, por nuk është aq i fortë sa ai i ofruar, të themi, nga makinat virtuale. Në thelb, një proces në një kontejner është i njëjti proces që ekzekutohet në sistemin operativ pritës.
Kjo mund të jetë një çështje sigurie: kjo marrëveshje teorikisht lejon që aplikacionet e palidhura të komunikojnë me njëri-tjetrin (qoftë qëllimisht ose aksidentalisht).
Për më tepër, të gjitha ngarkesat e punës në një grup Kubernetes ndajnë disa shërbime në të gjithë grupin, si p.sh. - kjo i lejon aplikacionet të gjejnë Shërbimet e aplikacioneve të tjera në grup.
Të gjitha pikat e mësipërme mund të kenë kuptime të ndryshme në varësi të kërkesave të sigurisë së aplikacionit.
Kubernetes ofron mjete të ndryshme për të parandaluar çështjet e sigurisë si p.sh и . Sidoqoftë, vendosja e tyre në mënyrë korrekte kërkon një përvojë; përveç kësaj, ata nuk janë në gjendje të mbyllin absolutisht të gjitha vrimat e sigurisë.
Është e rëndësishme të mbani mend gjithmonë se Kubernetes u krijua fillimisht për të ndarjen, jo për izolimi dhe siguria.
− Mungesa e shumë-qiramarrjes strikte
Duke pasur parasysh bollëkun e burimeve të përbashkëta në një grup Kubernetes, ka shumë mënyra që aplikacione të ndryshme mund të shkelin gishtat e njëri-tjetrit.
Për shembull, një aplikacion mund të monopolizojë një burim të përbashkët (të tillë si CPU ose memorie) dhe t'u mohojë aplikacioneve të tjera që funksionojnë në të njëjtën nyje aksesin në të.
Kubernetes ofron mekanizma të ndryshëm për të kontrolluar këtë sjellje, si p.sh (shih gjithashtu artikullin "" - përafërsisht. përkth.), и . Megjithatë, si në rastin e sigurisë, konfigurimi i tyre është mjaft i parëndësishëm dhe ata nuk janë në gjendje të parandalojnë absolutisht të gjitha efektet anësore të paparashikuara.
− Numri i madh i përdoruesve
Në rastin e një grupi të vetëm, ju duhet të hapni akses në të për shumë njerëz. Dhe sa më i madh numri i tyre, aq më i lartë është rreziku që ata të "thyejnë" diçka.
Brenda grupit mund të kontrolloni se kush mund të bëjë çfarë duke përdorur (shih artikullin "" - përafërsisht. përkth.). Megjithatë, nuk do t'i pengojë përdoruesit të "thyejnë" diçka brenda kufijve të zonës së tyre të përgjegjësisë.
− Grupimet nuk mund të rriten pafundësisht
Grupimi që përdoret për të gjitha ngarkesat e punës ka të ngjarë të jetë mjaft i madh (për sa i përket numrit të nyjeve dhe podeve).
Por këtu lind një problem tjetër: grupimet në Kubernetes nuk mund të rriten pafundësisht.
Ekziston një kufi teorik në madhësinë e grupimit. Në Kubernetes është afërsisht .
Sidoqoftë, në jetën reale, problemet mund të fillojnë shumë më herët - për shembull, vetëm me .
Fakti është se grupimet e mëdha vendosin një ngarkesë të lartë në shtresën e kontrollit Kubernetes. Me fjalë të tjera, mbajtja e grupit në funksion dhe funksionimi në mënyrë efikase kërkon akordim të kujdesshëm.
Kjo çështje është eksploruar në një artikull të lidhur në blogun origjinal të quajtur "'.
Por le të shqyrtojmë qasjen e kundërt: shumë grupime të vogla.
2. Shumë grupime të vogla të specializuara
Me këtë qasje, ju përdorni një grup të veçantë për çdo element që vendosni:
Shumë grupime të vogla
Për qëllimet e këtij neni, nën element i dislokueshëm i referohet një shembulli të një aplikacioni - për shembull, një version dev i një aplikacioni të veçantë.
Kjo strategji përdor Kubernetes si të specializuar koha e ekzekutimit për raste aplikimesh individuale.
Le të shohim të mirat dhe të këqijat e kësaj qasjeje.
+ "Rreze e shpërthimit" e kufizuar
Kur një grup dështon, pasojat negative kufizohen vetëm në ato ngarkesa pune që u vendosën në atë grup. Të gjitha ngarkesat e tjera të punës mbeten të paprekura.
+ Izolimi
Ngarkesat e punës të strehuara në grupe individuale nuk ndajnë burime të tilla si procesori, memoria, sistemi operativ, rrjeti ose shërbime të tjera.
Rezultati është një izolim i ngushtë midis aplikacioneve të palidhura, gjë që mund të jetë e dobishme për sigurinë e tyre.
+ Numër i vogël përdoruesish
Duke qenë se çdo grup përmban vetëm një grup të kufizuar ngarkesash pune, numri i përdoruesve me akses në të është zvogëluar.
Sa më pak njerëz të kenë akses në grup, aq më i ulët është rreziku që diçka të "thyehet".
Le të shohim të këqijat.
− Përdorimi joefikas i burimeve
Siç u përmend më herët, çdo grup Kubernetes kërkon një grup specifik të burimeve të menaxhimit: nyjet kryesore, komponentët e shtresës së kontrollit, zgjidhjet e monitorimit dhe regjistrimit.
Në rastin e një numri të madh grupimesh të vogla, një pjesë më e madhe e burimeve duhet t'i ndahet menaxhmentit.
− I shtrenjtë
Përdorimi joefikas i burimeve automatikisht sjell kosto të larta.
Për shembull, mbajtja e 30 nyjeve kryesore në vend të tre me të njëjtën fuqi llogaritëse do të ndikojë domosdoshmërisht në kosto.
− Vështirësi në administrim
Menaxhimi i shumë grupeve të Kubernetes është shumë më i vështirë sesa menaxhimi i vetëm një.
Për shembull, do t'ju duhet të konfiguroni vërtetimin dhe autorizimin për çdo grup. Versioni Kubernetes gjithashtu do të duhet të përditësohet disa herë.
Me shumë mundësi do t'ju duhet të përdorni automatizimin për t'i bërë të gjitha këto detyra më efikase.
Tani le të shohim skenarë më pak ekstremë.
3. Një grup për aplikim
Në këtë qasje, ju krijoni një grup të veçantë për të gjitha rastet e një aplikacioni të veçantë:
Grup për aplikim
Kjo rrugë mund të konsiderohet si një përgjithësim i parimit "grup i veçantë për ekip”, pasi zakonisht një ekip inxhinierësh po zhvillon një ose më shumë aplikacione.
Le të shohim të mirat dhe të këqijat e kësaj qasjeje.
+ Grupi mund të përshtatet me aplikacionin
Nëse një aplikacion ka nevoja të veçanta, ato mund të zbatohen në një grup pa ndikuar në grupe të tjera.
Nevoja të tilla mund të përfshijnë punëtorë GPU, disa shtojca CNI, një rrjetë shërbimi ose ndonjë shërbim tjetër.
Çdo grup mund të përshtatet me aplikacionin që ekzekutohet në të, në mënyrë që të përmbajë vetëm atë që nevojitet.
− Mjedise të ndryshme në një grup
Disavantazhi i kësaj qasjeje është se instancat e aplikimit nga mjedise të ndryshme bashkëjetojnë në të njëjtin grup.
Për shembull, versioni prod i aplikacionit funksionon në të njëjtin grup si versioni i dev. Kjo gjithashtu do të thotë që zhvilluesit operojnë në të njëjtin grup në të cilin operohet versioni i prodhimit të aplikacionit.
Nëse, për shkak të veprimeve të zhvilluesve ose defekteve në versionin dev, ndodh një dështim në grup, atëherë versioni prod mund të vuajë gjithashtu - një pengesë e madhe e kësaj qasjeje.
Dhe së fundi, skenari i fundit në listën tonë.
4. Një grup për çdo mjedis
Ky skenar përfshin ndarjen e një grupi të veçantë për çdo mjedis:
Një grup për çdo mjedis
Për shembull, mund të keni grupime dev, provë и stimuloj, në të cilin do të ekzekutoni të gjitha instancat e aplikacionit të dedikuara për një mjedis specifik.
Këtu janë të mirat dhe të këqijat e kësaj qasjeje.
+ Izolimi i mjedisit prod
Brenda kësaj qasjeje, të gjitha mjediset janë të izoluara nga njëri-tjetri. Megjithatë, në praktikë kjo është veçanërisht e rëndësishme në një mjedis nxitës.
Versionet e prodhimit të aplikacionit tani janë të pavarura nga ajo që po ndodh në grupe dhe mjedise të tjera.
Në këtë mënyrë, nëse papritmas lind një problem në grupin e devijimeve, versionet prod të aplikacioneve do të vazhdojnë të funksionojnë sikur asgjë të mos kishte ndodhur.
+ Grupi mund të përshtatet me mjedisin
Çdo grup mund të përshtatet me mjedisin e tij. Për shembull, ju mund të:
- instaloni mjete për zhvillim dhe korrigjimin e gabimeve në grupin e dev;
- instaloni kornizat dhe mjetet e testimit në grup provë;
- përdorni pajisje më të fuqishme dhe kanale rrjeti në grup stimuloj.
Kjo ju lejon të rrisni efikasitetin e zhvillimit dhe funksionimit të aplikacionit.
+ Kufizimi i aksesit në grupin e prodhimit
Nevoja për të punuar drejtpërdrejt me një grup prodhimi lind rrallë, kështu që mund të kufizoni ndjeshëm rrethin e njerëzve që kanë akses në të.
Mund të shkoni edhe më tej dhe t'u mohoni fare njerëzve aksesin në këtë grup dhe të kryeni të gjitha vendosjet duke përdorur një mjet të automatizuar CI/CD. Një qasje e tillë do të minimizojë rrezikun e gabimeve njerëzore pikërisht aty ku është më e rëndësishme.
Dhe tani disa fjalë për të këqijat.
− Nuk ka izolim ndërmjet aplikacioneve
Disavantazhi kryesor i qasjes është mungesa e izolimit të harduerit dhe burimeve ndërmjet aplikacioneve.
Aplikacionet e palidhura ndajnë burimet e grupimit: bërthamën e sistemit, procesorin, kujtesën dhe disa shërbime të tjera.
Siç u përmend, kjo mund të jetë potencialisht e rrezikshme.
− Pamundësia për të lokalizuar varësitë e aplikacioneve
Nëse një aplikacion ka kërkesa të veçanta, atëherë ato duhet të plotësohen në të gjitha grupimet.
Për shembull, nëse një aplikacion kërkon një GPU, atëherë çdo grup duhet të përmbajë të paktën një punonjës me një GPU (edhe nëse përdoret vetëm nga ai aplikacion).
Si rezultat, ne rrezikojmë kosto më të larta dhe përdorim joefikas të burimeve.
Përfundim
Nëse keni një grup specifik aplikacionesh, ato mund të vendosen në disa grupime të mëdha ose shumë të vogla.
Artikulli diskuton të mirat dhe të këqijat e qasjeve të ndryshme, duke filluar nga një grup global në disa të vogla dhe shumë të specializuara:
- një grup i madh i përgjithshëm;
- shumë grupime të vogla shumë të specializuara;
- një grup për aplikim;
- një grup për çdo mjedis.
Pra, cilën qasje duhet të merrni?
Si gjithmonë, përgjigjja varet nga rasti i përdorimit: duhet të peshoni të mirat dhe të këqijat e qasjeve të ndryshme dhe të zgjidhni opsionin më optimal.
Sidoqoftë, zgjedhja nuk kufizohet vetëm në shembujt e mësipërm - mund të përdorni çdo kombinim të tyre!
Për shembull, mund të organizoni disa grupime për secilin ekip: një grup zhvillimi (në të cilin do të ketë mjedise dev и provë) dhe grupim për prodhim (ku do të vendoset ambienti i prodhimit).
Bazuar në informacionin në këtë artikull, ju mund të optimizoni të mirat dhe të këqijat në përputhje me rrethanat për një skenar specifik. Paç fat!
PS
Lexoni edhe në blogun tonë:
- «"?
- «"?
- «"?
- «'.
Burimi: www.habr.com