Jegyzet. ford.: ez az anyag egy oktatási projektből származik a válasz egy népszerű kérdésre a Kubernetes-alapú infrastruktúra tervezésekor. Reméljük, hogy az egyes lehetőségek előnyeiről és hátrányairól szóló meglehetősen részletes leírások segítenek a legjobb választás kiválasztásában projektje számára.
TL, DR: ugyanaz a munkaterhelés-készlet több nagy fürtön is futtatható (minden fürtnek nagy számú terhelése lesz), vagy sok kicsin (kevés terhelés esetén minden fürtben).
Az alábbiakban egy táblázat található, amely értékeli az egyes megközelítések előnyeit és hátrányait:
Amikor a Kubernetes alkalmazásokat futtató platformként használjuk, gyakran számos alapvető kérdés merül fel a fürtök beállításának bonyolultságával kapcsolatban:
- Hány klasztert használjak?
- Mekkora legyen őket?
- Mit kell tartalmaznia az egyes klasztereknek?
Ebben a cikkben megpróbálok választ adni ezekre a kérdésekre az egyes megközelítések előnyeinek és hátrányainak elemzésével.
Egy kérdés megnyilatkozása
Szoftverfejlesztőként valószínűleg sok alkalmazást fejleszt és működtet egyszerre.
Ezen túlmenően ezeknek az alkalmazásoknak számos példánya valószínűleg különböző környezetekben fut – például ezek lehetnek dev, teszt и döf.
Az eredmény az alkalmazások és környezetek egész mátrixa:
Alkalmazások és környezetek
A fenti példa 3 alkalmazást és 3 környezetet ábrázol, ami összesen 9 lehetséges opciót eredményez.
Minden alkalmazáspéldány egy önálló telepítési egység, amellyel másoktól függetlenül lehet dolgozni.
Kérjük, vegye figyelembe, hogy a alkalmazáspéldány sokból állhat alkatrészek, például frontend, backend, adatbázis stb. Mikroszolgáltatási alkalmazás esetén a példány az összes mikroszolgáltatást tartalmazza.
Ennek eredményeként a Kubernetes-felhasználóknak számos kérdése van:
- Az összes alkalmazáspéldányt egy fürtbe kell helyezni?
- Érdemes minden alkalmazáspéldányhoz külön fürtöt készíteni?
- Vagy esetleg a fenti megközelítések kombinációját kellene alkalmazni?
Mindezek a lehetőségek meglehetősen életképesek, mivel a Kubernetes egy rugalmas rendszer, amely nem korlátozza a felhasználó képességeit.
Íme néhány lehetséges mód:
- egy nagy közös klaszter;
- sok kis, magasan specializálódott klaszter;
- alkalmazásonként egy fürt;
- környezetenként egy klaszter.
Amint az alább látható, az első két megközelítés a lehetőségek skála ellentétes végén található:
Néhány nagy csoporttól (balra) a sok kicsiig (jobbra)
Általánosságban elmondható, hogy egy klasztert „nagyobbnak” tekintenek a másiknál, ha több csomópontot és podokat tartalmaz. Például egy 10 csomópontból és 100 podból álló fürt nagyobb, mint egy 1 csomópontból és 10 podból álló fürt.
Nos, kezdjük!
1. Egy nagy közös klaszter
Az első lehetőség az, hogy az összes munkaterhelést egy fürtbe helyezzük:
Egy nagy klaszter
Ezen a megközelítésen belül a klasztert univerzálisként használják infrastrukturális platform – egyszerűen telepíthet mindent, amire szüksége van egy meglévő Kubernetes-fürtben.
A Kubernetes lehetővé teszi a fürt egyes részei logikai elválasztását egymástól, így minden alkalmazáspéldánynak saját névtere lehet.
Nézzük meg ennek a megközelítésnek az előnyeit és hátrányait.
+ Erőforrások hatékony felhasználása
Egyetlen fürt esetén csak egy példányra van szüksége a Kubernetes-fürt futtatásához és kezeléséhez szükséges összes erőforrásból.
Például ez igaz a fő csomópontokra. Általában minden Kubernetes-fürtnek 3 fő csomópontja van, így egyetlen fürt esetében a számuk így is marad (összehasonlításképpen 10 fürthöz 30 fő csomópontra van szükség).
A fenti finomság a teljes fürtben működő egyéb szolgáltatásokra is vonatkozik, mint például a terheléselosztókra, az Ingress vezérlőkre, a hitelesítési, naplózási és megfigyelési rendszerekre.
Egyetlen fürtben ezek a szolgáltatások egyszerre használhatók az összes munkaterheléshez (nincs szükség másolatok létrehozására, mint ahogyan ez több fürt esetében történik).
+ Olcsó
A fentiek következtében a kevesebb klaszter általában olcsóbb, mivel nincs rezsiköltség.
Ez különösen igaz a főcsomópontokra, amelyek jelentős összegbe kerülhetnek, függetlenül attól, hogy hogyan tárolják őket (helyszíni vagy felhőben).
Néhány felügyelt Kubernetes szolgáltatás, mint pl vagy , ingyenesen biztosítsa a vezérlőréteget. Ebben az esetben a költségkérdés kevésbé akut.
Vannak olyan felügyelt szolgáltatások is, amelyek fix díjat számítanak fel az egyes Kubernetes-fürtök működéséért (pl. ).
+ Hatékony adminisztráció
Egy fürt kezelése könnyebb, mint több.
Az adminisztráció a következő feladatokat foglalhatja magában:
- Kubernetes verziófrissítés;
- CI/CD csővezeték felállítása;
- a CNI bővítmény telepítése;
- felhasználói hitelesítési rendszer beállítása;
- beléptető vezérlő telepítése;
és sokan mások…
Egy klaszter esetén mindezt csak egyszer kell megtennie.
Sok klaszter esetében a műveleteket sokszor meg kell ismételni, ami valószínűleg a folyamatok és eszközök bizonyos automatizálását teszi szükségessé a folyamat következetességének és konzisztenciájának biztosítása érdekében.
És most néhány szó a hátrányokról.
− Egyetlen hibapont
Elutasítás esetén az egyetlen a fürt azonnal leáll minden munkaterhelések!
A dolgok sokféleképpen elromolhatnak:
- a Kubernetes frissítése váratlan mellékhatásokhoz vezet;
- Egy fürtszintű összetevő (például egy CNI-bővítmény) nem a várt módon kezd működni;
- a fürt egyik összetevője nincs megfelelően konfigurálva;
- a mögöttes infrastruktúra meghibásodása.
Egy ilyen esemény komoly károkat okozhat egy megosztott fürtben tárolt összes munkaterhelésben.
− Nincs merev szigetelés
A megosztott fürtben való futtatás azt jelenti, hogy az alkalmazások megosztják a hardvert, a hálózati képességeket és az operációs rendszert a fürt csomópontjain.
Bizonyos értelemben két tároló, amelyekben két különböző alkalmazás fut ugyanazon a csomóponton, olyan, mint két folyamat, amely ugyanazon a gépen fut, ugyanazt az operációs rendszer kernelt futtatva.
A linuxos konténerek biztosítanak bizonyos fajta elszigetelést, de közel sem olyan erős, mint amit mondjuk a virtuális gépek biztosítanak. Lényegében a tárolóban lévő folyamat ugyanaz a folyamat, amely a gazdagép operációs rendszeren fut.
Ez biztonsági probléma lehet: ez az elrendezés elméletileg lehetővé teszi, hogy a független alkalmazások kommunikáljanak egymással (akár szándékosan, akár véletlenül).
Ezenkívül a Kubernetes-fürtben lévő összes munkaterhelés megosztja a fürtszintű szolgáltatásokat, például - Ez lehetővé teszi az alkalmazások számára, hogy megtalálják a fürtben lévő más alkalmazások szolgáltatásait.
A fenti pontok mindegyike eltérő jelentéssel bírhat az alkalmazás biztonsági követelményeitől függően.
A Kubernetes különféle eszközöket kínál a biztonsági problémák megelőzésére, mint pl и . A helyes beállításuk azonban némi tapasztalatot igényel, ráadásul nem képesek teljesen minden biztonsági rést bezárni.
Fontos, hogy mindig emlékezzen arra, hogy a Kubernetes eredetileg erre készült megosztás, nem azért elszigeteltség és biztonság.
− Szigorú többbérlet hiánya
Tekintettel a Kubernetes-fürt megosztott erőforrásainak bőségére, a különböző alkalmazások számos módon ráléphetnek egymás lábára.
Például egy alkalmazás monopolizálhat egy megosztott erőforrást (például CPU-t vagy memóriát), és megtagadhatja az ugyanazon a csomóponton futó egyéb alkalmazások számára a hozzáférést.
A Kubernetes különféle mechanizmusokat biztosít ennek a viselkedésnek a szabályozására, mint pl (lásd még a cikket ""- kb. fordítás.), и . Azonban a biztonsághoz hasonlóan konfigurációjuk sem triviális, és nem képesek minden előre nem látható mellékhatást megakadályozni.
− Nagy számú felhasználó
Egyetlen fürt esetén sok ember számára meg kell nyitnia a hozzáférést. És minél nagyobb a számuk, annál nagyobb a kockázata annak, hogy „eltörnek” valamit.
A fürtön belül szabályozhatja, hogy ki mit csinálhat (lásd a cikket ""- kb. fordítás.). Ez azonban nem akadályozza meg a felhasználókat abban, hogy a felelősségi körükön belül valamit „megtörjenek”.
− A klaszterek nem növekedhetnek a végtelenségig
Az összes munkaterheléshez használt fürt valószínűleg meglehetősen nagy lesz (a csomópontok és a sorba rendezések számát tekintve).
De itt egy másik probléma is felmerül: a kubernetesi klaszterek nem növekedhetnek a végtelenségig.
A klaszter méretének elméleti korlátja van. Kubernetesben kb .
A való életben azonban a problémák sokkal korábban kezdődhetnek – például csak azzal .
A helyzet az, hogy a nagy klaszterek nagy terhelést jelentenek a Kubernetes vezérlőrétegre. Más szóval, a fürt hatékony működésének fenntartása gondos hangolást igényel.
Ezt a problémát az eredeti blog egy kapcsolódó cikkében tárgyalja "".
De nézzük az ellenkező megközelítést: sok kis klaszter.
2. Sok kis, speciális klaszter
Ezzel a megközelítéssel külön fürtöt használ minden telepített elemhez:
Sok kis klaszter
E cikk alkalmazásában a telepíthető elem egy alkalmazás egy példányára vonatkozik – például egy különálló alkalmazás fejlesztői verziójára.
Ez a stratégia a Kuberneteset használja speciálisként futásidő egyedi alkalmazáspéldányokhoz.
Nézzük meg ennek a megközelítésnek az előnyeit és hátrányait.
+ Korlátozott „robbanási sugár”
Ha egy fürt meghibásodik, a negatív következmények csak azokra a munkaterhelésekre korlátozódnak, amelyeket az adott fürtben telepítettek. Az összes többi munkaterhelés érintetlen marad.
+ Szigetelés
Az egyes fürtökben tárolt munkaterhelések nem osztanak meg erőforrásokat, például processzort, memóriát, operációs rendszert, hálózatot vagy egyéb szolgáltatásokat.
Az eredmény a független alkalmazások közötti szoros elszigeteltség, ami előnyös lehet a biztonságuk szempontjából.
+ Kis számú felhasználó
Tekintettel arra, hogy minden fürt csak korlátozott számú munkaterhelést tartalmaz, a hozzáférő felhasználók száma csökken.
Minél kevesebb ember fér hozzá a klaszterhez, annál kisebb a kockázata annak, hogy valami „eltörik”.
Nézzük a hátrányokat.
− Az erőforrások nem hatékony felhasználása
Amint azt korábban említettük, minden Kubernetes-fürt egy meghatározott felügyeleti erőforrás-készletet igényel: fő csomópontok, vezérlőréteg-összetevők, megfigyelési és naplózási megoldások.
Nagyszámú kis klaszter esetén az erőforrások nagyobb hányadát kell a menedzsmentre fordítani.
− Drága
Az erőforrások nem hatékony felhasználása automatikusan magas költségekkel jár.
Például, ha három helyett 30 főcsomópontot tart fenn azonos számítási teljesítménnyel, az szükségszerűen befolyásolja a költségeket.
− Nehézségek az ügyintézésben
Több Kubernetes-fürt kezelése sokkal nehezebb, mint egyetlen.
Például minden egyes fürthöz be kell állítania a hitelesítést és az engedélyezést. A Kubernetes verziót is többször frissíteni kell majd.
Valószínűleg automatizálásra lesz szüksége, hogy mindezen feladatokat hatékonyabbá tegye.
Most nézzünk kevésbé szélsőséges forgatókönyveket.
3. Alkalmazásonként egy fürt
Ezzel a megközelítéssel külön fürtöt hoz létre egy adott alkalmazás minden példányához:
Klaszter alkalmazásonként
Ez az út az elv általánosításának tekinthetőcsapatonként külön klaszter”, mivel általában egy mérnökcsapat fejleszt egy vagy több alkalmazást.
Nézzük meg ennek a megközelítésnek az előnyeit és hátrányait.
+ A klaszter az alkalmazáshoz igazítható
Ha egy alkalmazásnak speciális igényei vannak, akkor azok implementálhatók egy fürtben anélkül, hogy más fürtöket érintenének.
Ilyen igények lehetnek GPU-munkások, bizonyos CNI-bővítmények, szolgáltatásháló vagy más szolgáltatás.
Minden fürt személyre szabható a benne futó alkalmazáshoz, így csak a szükséges mennyiséget tartalmazza.
− Különböző környezetek egy klaszterben
Ennek a megközelítésnek az a hátránya, hogy a különböző környezetekből származó alkalmazáspéldányok együtt léteznek ugyanabban a fürtben.
Például az alkalmazás prod verziója ugyanabban a fürtben fut, mint a fejlesztői verzió. Ez azt is jelenti, hogy a fejlesztők ugyanabban a fürtben működnek, amelyben az alkalmazás éles verzióját üzemeltetik.
Ha a fejlesztők tevékenysége vagy a fejlesztői verzió hibái miatt hiba történik a fürtben, akkor a prod verzió is szenvedhet – ez ennek a megközelítésnek óriási hátránya.
És végül a listánk utolsó forgatókönyve.
4. Környezetenként egy fürt
Ez a forgatókönyv magában foglalja egy külön fürt kiosztását minden környezethez:
Környezetenként egy fürt
Például lehetnek klaszterei dev, teszt и döf, amelyben futtatni fogja az alkalmazás összes példányát, amelyet egy adott környezetnek szenteltek.
Íme ennek a megközelítésnek az előnyei és hátrányai.
+ A prod környezet izolálása
Ezen a megközelítésen belül minden környezet el van szigetelve egymástól. A gyakorlatban azonban ez különösen fontos termékkörnyezetben.
Az alkalmazás éles verziói immár függetlenek attól, hogy mi történik más fürtökben és környezetekben.
Így, ha hirtelen probléma merül fel a fejlesztői fürtben, az alkalmazások prod verziói továbbra is úgy működnek, mintha mi sem történt volna.
+ A klaszter a környezethez igazítható
Minden klaszter a környezetéhez igazítható. Például:
- eszközök telepítése a fejlesztéshez és a hibakereséshez a fejlesztői fürtben;
- telepítsen tesztkeretrendszereket és eszközöket a fürtbe teszt;
- erősebb hardvert és hálózati csatornákat használjon a fürtben döf.
Ez lehetővé teszi mind az alkalmazásfejlesztés, mind az üzemeltetés hatékonyságának növelését.
+ A termelési klaszterhez való hozzáférés korlátozása
Ritkán merül fel annak szükségessége, hogy közvetlenül egy termékklaszterrel dolgozzon, így jelentősen korlátozhatja a hozzáférő személyek körét.
Még tovább léphet, és teljesen megtagadhatja az emberektől a hozzáférést ehhez a fürthöz, és minden telepítést végrehajthat egy automatizált CI/CD eszköz segítségével. Ez a megközelítés pontosan ott minimalizálja az emberi hibák kockázatát, ahol az a leginkább releváns.
És most néhány szó a hátrányokról.
− Nincs elszigetelés az alkalmazások között
A megközelítés fő hátránya az alkalmazások közötti hardver- és erőforrás-szigetelés hiánya.
A nem kapcsolódó alkalmazások megosztják a fürt erőforrásait: a rendszermagot, a processzort, a memóriát és néhány egyéb szolgáltatást.
Mint említettük, ez potenciálisan veszélyes lehet.
− Képtelenség lokalizálni az alkalmazásfüggőségeket
Ha egy alkalmazásnak speciális követelményei vannak, akkor azoknak minden klaszterben meg kell felelniük.
Például, ha egy alkalmazás GPU-t igényel, akkor minden fürtnek tartalmaznia kell legalább egy GPU-val rendelkező dolgozót (még akkor is, ha azt csak az adott alkalmazás használja).
Ennek eredményeként magasabb költségeket és az erőforrások nem hatékony felhasználását kockáztatjuk.
Következtetés
Ha van egy adott alkalmazáskészlete, akkor azokat több nagy fürtbe vagy sok kicsibe is elhelyezheti.
A cikk a különféle megközelítések előnyeit és hátrányait tárgyalja, egy globális klasztertől a több kicsi és nagyon speciális klaszterig:
- egy nagy általános klaszter;
- sok kis, magasan specializálódott klaszter;
- alkalmazásonként egy fürt;
- környezetenként egy klaszter.
Tehát melyik megközelítést érdemes alkalmazni?
Mint mindig, a válasz a használati esettől függ: mérlegelnie kell a különböző megközelítések előnyeit és hátrányait, és ki kell választania a legoptimálisabb lehetőséget.
A választás azonban nem korlátozódik a fenti példákra – ezek bármilyen kombinációját használhatja!
Például minden csapat számára szervezhet néhány fürtöt: egy fejlesztői klasztert (amelyben lesznek környezetek dev и teszt) és fürt a számára Termelés (ahol a termelési környezet lesz elhelyezve).
A cikkben található információk alapján egy adott forgatókönyvhöz megfelelően optimalizálhatja az előnyöket és hátrányokat. Sok szerencsét!
PS
Olvassa el blogunkon is:
- «";
- «";
- «";
- «".
Forrás: will.com