Megjegyzés fordítás.: ez az anyag az oktatási projektből — válasz egy népszerű kérdésre a Kubernetes alapú infrastruktúra tervezésekor. Reméljük, hogy a különböző lehetőségek előnyeivel és hátrányaival kapcsolatos részletes leírások segítenek az optimális választásban a projekted számára is.
Röviden összefoglalva: egy és ugyanazon munkaterhelést futtathatsz több nagy klaszteren (minden klaszterre sok workload jut), vagy sok kicsin (kevés terheléssel minden klaszteren).
Az alábbi táblázatban minden megközelítés előnyeit és hátrányait értékeljük:
Kubernetes alkalmazásként való felhasználásakor gyakran felmerülnek alapvető kérdések a klaszterek beállításának részleteivel kapcsolatban:
- Hány klasztert használjunk?
- Mekkora legyen a méretük?
- Mit kell tartalmaznia minden klaszternak?
Ebben a cikkben minden kérdésre próbálok választ adni, elemezve minden megközelítés előnyeit és hátrányait.
A kérdés felvetése
Szoftverfejlesztőként valószínűleg párhuzamosan több alkalmazást is fejlesztesz és üzemeltetsz.
Ezen kívül a számos példány valószínűleg különböző környezetekben fut — például, ezek lehetnek dev, teszt és prod.
Ezért egy egész mátrixot kapunk alkalmazásokból és környezetekből:
Alkalmazások és környezetek
A fenti példában 3 alkalmazás és 3 környezet található, ami összesen 9 lehetséges variációt jelent.
Minden alkalmazás példánya önálló deployment egységet képvisel, amellyel függetlenül lehet dolgozni.
p(x) – alkalmazás példány többekből állhat melyek mindegyikét figyelembe kell venni a teljes körű védelem biztosítása érdekében:, mint például frontend, backend, adatbázis stb. Mikroszolgáltatásos alkalmazás esetén a példány minden mikroszolgáltatást magában foglal.
Ennek következtében a Kubernetes felhasználók számára felmerül néhány kérdés:
- Érdemes-e minden alkalmazás példányt egy klaszterben elhelyezni?
- Érdemes-e minden alkalmazás példányhoz külön klasztert létrehozni?
- Vagy esetleg érdemes lenne a fenti megközelítések kombinációját alkalmazni?
Mindezek a lehetőségek teljesen életképesek, mivel a Kubernetes rugalmas rendszer, amely nem korlátozza a felhasználókat a lehetőségekben.
Íme néhány lehetséges lehetőség:
- egy nagy közös klaszter;
- számos kisebb, szakosodott klaszter;
- egy klaszter minden egyes alkalmazásra;
- egy klaszter minden egyes környezetre.
Ahogy az alábbiakban látható, az első két megközelítés a lehetőségek skálájának ellentétes végén helyezkedik el:
Néhány nagy klasztertől (balra) a sok kicsi klaszterig (jobbra)
Általánosságban elmondható, hogy egy klaszter "nagyobb", mint a másik, ha több csomópontja és podja van. Például, egy 10 csomóponttal és 100 poddal rendelkező klaszter nagyobb, mint egy 1 csomóponttal és 10 poddal rendelkező klaszter.
Nos, kezdjük el!
1. Egy nagy közös klaszter
Az első lehetőség az, hogy az összes munkaterhelést egy klaszterben helyezzük el:
Egy nagy klaszter
Ennek a megközelítésnek a keretein belül a klaszter általános célú infrastruktúrás platformként működik, — mindent, amire szüksége van, egyszerűen a meglévő Kubernetes klaszterben telepít.
A Kubernetes lehetővé teszi, hogy logikailag elválasszuk a klaszter egyes részeit egymástól, így minden alkalmazás példányhoz saját névtér használható.
Nézzük meg ennek a megközelítésnek az előnyeit és hátrányait.
+ Hatékony erőforrás-használat
Egyetlen klaszter esetén csak egy példányra van szükség minden erőforrásból, amely a Kubernetes klaszter futtatásához és kezeléséhez szükséges.
Például ez érvényes a mester csomópontokra. Általában minden Kubernetes klaszterre 3 mester csomópont jut, így egyetlen klaszter esetén is ennyi marad (míg 10 klaszterhez 30 mester csomópont szükséges).
A fent említett finomság más, a klaszter egész területén működő szolgáltatásokra is vonatkozik, mint például terheléselosztók, Ingress vezérlők, hitelesítési, naplózási és monitoring rendszerek.
Egy klaszterben minden szolgáltatás az összes munkaterheléshez igénybe vehető (nem szükséges másolatokat létrehozni, mint több klaszter esetén).
+ Költséghatékonyság
Ennek következményeként, kevesebb klaszter általában olcsóbb, mivel csökkenti a fölösleges erőforrások költségeit.
Ez különösen érvényes a mester csomópontokra, amelyek jelentős összeget képviselhetnek, függetlenül attól, hogy helyben (on-premises) vagy felhőben helyezik el őket.
Néhány menedzselt Kubernetes szolgáltatás, mint például a vagy , ingyenes irányító réteggel rendelkeznek. Ebben az esetben a költségek kérdése már nem olyan éles.
Vannak managed szolgáltatások is, amelyek fix díjat számítanak fel az egyes Kubernetes klaszterek működéséért (például, ).
+ Hatékony adminisztráció
Könnyebb egyetlen klasztert irányítani, mint többet.
Az adminisztráció a következő feladatokat foglalhatja magában:
- a Kubernetes verziójának frissítése;
- CI/CD csővezeték beállítása;
- CNI plug-in telepítése;
- a felhasználói hitelesítési rendszer beállítása;
- hozzáférés-ellenőrző telepítése;
és még sok más...
Egyetlen klaszter esetén mindezért csak egyszer kell foglalkozni.
Több klaszter esetén a műveleteket többször meg kell ismételni, ami valószínűleg bizonyos folyamatok automatizálását és eszközök alkalmazását követeli meg a folyamatok rendszerességének és egységességének biztosítása érdekében.
Most pedig néhány szót a hátrányokról.
− Egységes hibapont
Hiba esetén a kiborgaló klaszter azonnal leállítja mindent a terheléseket!
Számos olyan lehetőség létezik, amikor valami nem a tervek szerint alakul:
- a Kubernetes frissítése váratlan mellékhatásokat okozhat;
- a klaszter szintű komponens (például a CNI plug-in) nem úgy működik, ahogyan várható volt;
- a klaszter egyik komponense hibásan van konfigurálva;
- hiba az alsóbb infrastruktúrában.
Egy ilyen incidens súlyos kárt okozhat minden olyan terhelésben, amely a közös klaszterben található.
− A szigorú izoláció hiánya
A közös klaszterben való dolgozás azt jelenti, hogy az alkalmazások közösen használják a hardware-t, hálózati lehetőségeket és az operációs rendszert a klaszter csomópontjain.
Bizonyos értelemben két, különböző alkalmazással rendelkező konténer, amely ugyanazon a nodon fut, hasonló a két folyamat működéséhez ugyanazon a gépen az operációs rendszer ugyanazon magja alatt.
A Linux konténerek bizonyos formájú izolációt biztosítanak, de ez messze nem olyan erős, mint amit például a virtuális gépek nyújtanak. Lényegében a konténerben futó folyamat ugyanaz a folyamat, amely a host operációs rendszerben fut.
Ez biztonsági szempontból problémát jelenthet: a hasonló megszervezés elvileg lehetővé teszi, hogy a nem kapcsolódó alkalmazások kölcsönhatásba lépjenek egymással (szándékosan vagy véletlenül).
Ezenkívül az összes munkaterhelés a Kubernetes klaszteren belül közösen használ bizonyos klaszterszintű szolgáltatásokat, mint például — ez lehetővé teszi az alkalmazások számára, hogy megtalálják a klaszter más alkalmazásainak szolgáltatásait.
A fent említett pontok különböző jelentéssel bírhatnak az alkalmazások biztonsági követelményeitől függően.
A Kubernetes különböző eszközöket biztosít a biztonsági problémák elkerülésére, mint például és . Azonban ezek helyes beállításához bizonyos tapasztalat szükséges, és nem képesek minden biztonsági rést lefedni.
Fontos mindig észben tartani, hogy a Kubernetes eredetileg a közös használatra, nem pedig az izolációra és biztonságra lett kifejlesztve..
− Nincs szigorú multi-tenancy
Tekintettel a Kubernetes klaszterben található közös erőforrások bőségére, számos mód létezik arra, hogy a különböző alkalmazások „lábnyomot hagyjanak egymásra”.
Például egy alkalmazás monopolizálhat egy közös erőforrást (mint például a CPU vagy a memória), és megfoszthat más alkalmazásokat, amelyek ugyanazon a csomóponton futnak, annak elérésétől.
A Kubernetes különféle mechanizmusokat biztosít az ilyen viselkedés ellenőrzésére, mint például (lásd még a "” — ford. megj.), és . Azonban, mint a biztonság esetében, a beállításuk nem trivialis, és nem képesek megelőzni minden nem várt mellékhatást.
− Nagy számú felhasználó
Egyetlen klaszter esetén számos embernek kell hozzáférést biztosítani. És minél több a számuk, annál nagyobb a kockázata, hogy valamit "elrontanak".
A klaszteren belül nyomon lehet követni, hogy ki és mit tehet a (lásd a "” — ford. megj.). Azonban ez nem akadályozza meg a felhasználókat abban, hogy "elrontsanak" valamit a saját felelősségi területükön belül.
− A klaszterek nem nőhetnek korlátlanul
A klaszter, amelyet minden munkaterheléshez használnak, valószínűleg meglehetősen nagy lesz (csomópontok és pod-ok számában).
De itt egy másik probléma merül fel: a Kubernetes klaszterek nem nőhetnek korlátlanul.
Van egy elméleti korlát a klaszter méretére. A Kubernetesben ez körülbelül .
A valós életben azonban a problémák sokkal korábban kezdődhetnek — például mindössze .
Az a helyzet, hogy a nagy klaszterek nagy terhelést rónak a Kubernetes vezérlő rétegére. Más szavakkal, ahhoz, hogy a klaszter működőképes maradjon és hatékonyan használja az erőforrásokat, alapos beállítást igényel.
Ez a probléma a megfelelő cikkben vizsgálódik az eredeti blogon, amelynek címe „».
De nézzük meg az ellenkező megközelítést: sok kis klasztert.
2. Számos kis, specializált klaszter
E megközelítés keretein belül minden telepített elemhez külön klasztert használ.
Sok kis klaszter
E cikk szempontjából a telepített elem alatt egy alkalmazás példányát értjük — például egy önálló alkalmazás dev-verzióját.
Ebben a stratégiában a Kubernetes egy specializált futtatási környezetként működik az egyes alkalmazás példányok számára.
Nézzük meg ennek a megközelítésnek az előnyeit és hátrányait.
+ Korlátozott „robbanásköz”
Ha a klaszter „megtörik”, a negatív következmények csupán azokat a terheléseket érintik, amelyeket ebben a klaszterben telepítettek. Minden más workload érintetlen marad.
+ Izoláció
Az egyes klaszterekben elhelyezett workload-ok nem rendelkeznek közös erőforrásokkal, mint például processzor, memória, operációs rendszer, hálózat vagy más szolgáltatások.
Ennek eredményeként szigorú izolációt kapunk a nem összefüggő alkalmazások között, ami jótékony hatással lehet a biztonságukra.
+ Kevés felhasználó
Tekintettel arra, hogy minden klaszterben csupán egy korlátozott számú workload található, csökken a hozzáféréssel rendelkező felhasználók száma.
Minél kevesebb embernek van hozzáférése a klaszterhez, annál kisebb a kockázat, hogy valami „megtörik”.
Nézzük meg a hátrányokat.
− Hatékonytalan erőforrás-használat
Ahogy korábban említettük, minden Kubernetes klaszternek megvan a maga szükséges kezelő erőforrása: mester csomópontok, vezérlő réteg összetevői, monitorozási és naplózási megoldások.
Ha sok kis klaszter van, akkor nagyobb arányú erőforrást kell allokálni a kezelésre.
− Magas költségek
A hatékonytalan erőforrás-használat automatikusan magas költségeket vonz.
Például a 30 master-node tartalma a három helyett ugyanannyi számítási teljesítmény mellett biztosan hatással lesz a költségekre.
− Adminisztrációs nehézségek
Több Kubernetes klaszter adminisztrálása sokkal nehezebb, mint egyedül dolgozni egyen.
Például be kell állítania az autentikációt és az autorizációt minden klaszterre. A Kubernetes verziófrissítését is többször kell elvégezni.
Valószínűleg automatizálásra lesz szüksége, hogy növelje ezeknek a feladatoknak a hatékonyságát.
Most nézzük meg a kevésbé szélsőséges forgatókönyveket.
3. Egy klaszter minden alkalmazásra
Ennek a megközelítésnek a keretében külön klasztert hoz létre minden egyes konkrét alkalmazás példányának:
Klaszter alkalmazásonként
Ez a megközelítés a külön klaszter a csapatnak elv általánosításaként tekinthető, mivel általában egy mérnökcsapat foglalkozik egy vagy több alkalmazás fejlesztésével.+ A klasztert az alkalmazás igényeire lehet szabniHa az alkalmazásnak különleges igényei vannak, azokat a klaszterben megvalósíthatja, anélkül hogy más klasztereket befolyásolna.
Nézzük meg ennek a megközelítésnek az előnyeit és hátrányait.
Ezek az igények magukban foglalhatják a GPU-s worker-eit, bizonyos CNI plugineket, service mesht vagy bármilyen más szolgáltatást.
Minden klasztert az abban futó alkalmazás igényeihez igazíthatja, hogy csak az szükséges elemeket tartalmazza.
− Különböző környezetek egy klaszterben
Ennek a megközelítésnek a hátránya, hogy a különböző környezetekből származó alkalmazáspéldányok együtt élnek egy klaszterben.
Például a gyártás verziója az alkalmazásnak ugyanabban a klaszterben működik, mint a fejlesztési verzió. Ez azt is jelenti, hogy a fejlesztők ugyanabban a klaszterben dolgoznak, amelyben a gyártás verziója üzemel.
Ha a fejlesztők cselekedetei vagy a fejlesztési verzió hibái miatt a klaszterben hiba lép fel, akkor potenciálisan a gyártás verzió is károsodhat — ennek a megközelítésnek hatalmas hátránya.
Nos, végül itt a lista utolsó forgatókönyve.
4. Egy klaszter minden környezetre
Ez a forgatókönyv külön klaszterek fenntartását feltételezi minden környezet számára:
Egy klaszter környezetenként
Például lehetnek klaszterei, amelyekben minden alkalmazás példányait futtatja, amelyeket egy adott környezet számára szán.
Íme az ilyen megközelítés előnyei és hátrányai.
+ A gyártási környezet elkülönítése dev, teszt és prod, amelyekben az összes alkalmazáspéldányt futtatni fogja, amelyek egy adott környezethez készültek.
Ez azt jelenti, hogy a különböző környezetekhez való izolálás megvalósul.
+ Prod-környezet elkülönítése
Ennek a megközelítésnek köszönhetően minden környezet elszigetelt egymástól. A gyakorlatban azonban ez különösen fontos a prod-környezet számára.
Az alkalmazás production verziói már nem függenek a többi klaszter és környezet működésétől.
Így, ha a dev-klaszterben váratlan probléma merül fel, a prod-alkalmazások továbbra is működnek, mintha mi sem történt volna.
+ A klaszter a környezethez igazítható
Minden klasztert a saját környezetéhez lehet igazítani. Például, lehet:
- fejlesztési és hibakeresési eszközöket telepíteni a dev-klaszterbe;
- tesztelő keretrendszereket és eszközöket telepíteni a klaszterbe; teszt;
- nagyobb teljesítményű hardvereket és hálózati csatornákat használni a klaszterben; prod.
Ez lehetővé teszi a fejlesztés és az alkalmazások üzemeltetésének hatékonyságának növelését.
+ A hozzáférés korlátozása a production klaszterhez
A prod-klaszterrel való közvetlen munkavégzés szükségessége ritkán merül fel, így jelentősen korlátozható azoknak a köre, akik hozzáférhetnek.
Tovább is lehet menni, és teljesen megfosztani az embereket ennek a klaszternek a hozzáférésétől, az összes telepítést automatizált CI/CD eszközzel végrehajtva. Ez a megközelítés minimalizálja az emberi hibák kockázatát pontosan ott, ahol ez a legfontosabb.
Most pedig néhány szót a hátrányokról.
− Az alkalmazások közötti elszigetelés hiánya
A megközelítés alapvető hátránya az alkalmazások közötti hardver- és erőforrás-elszigetelés hiánya.
A nem összefüggő alkalmazások közösen használják a klaszter erőforrásait: a rendszermagot, a processzort, a memóriát és néhány más szolgáltatást.
Amint azt már említettük, ez potenciálisan veszélyes lehet.
− Az alkalmazások függőségeinek lokalizálásának lehetetlensége
Ha egy alkalmazásnak különleges követelményei vannak, azt minden klaszterben teljesíteni kell.
Például, ha egy alkalmazásnak GPU-ra van szüksége, akkor minden klaszternek tartalmaznia kell legalább egy munkást GPU-val (még akkor is, ha azt csak ez az alkalmazás használja).
Ennek következményeként nagyobb költségekkel és erőforrások hatékonytalan felhasználásával kockáztatunk.
Zárás
Egy meghatározott alkalmazáskészlet esetén ezeket több nagy klaszterbe vagy sok kis klaszterbe helyezhetjük el.
A cikk az egy globális klaszter és több kis, szakosodott klaszter közötti különböző megközelítések előnyeit és hátrányait tárgyalja.
- egy nagy közös klaszter;
- számos kisebb, szakosodott klaszter;
- egy klaszter minden egyes alkalmazásra;
- egy klaszter minden egyes környezetre.
Tehát, melyik megközelítést válasszuk?
Mint általában, a válasz a felhasználási forgatótól függ: mérlegelni kell a különböző megközelítések előnyeit és hátrányait, és kiválasztani a legoptimálisabb megoldást.
Bár a választás nem korlátozódik a fenti példákra – bármilyen kombinációjukat alkalmazhatjuk!
Például, páronként szervezhetünk klasztereket minden csapat számára: egy klaszter a fejlesztéshez (amely tartalmazza a környezeteket dev és teszt) és egy klaszter a production (ahol a production környezet található).
A cikk információira támaszkodva megfelelően optimalizálhatja az előnyöket és hátrányokat a konkrét forgatókönyvhez. Sok sikert!
P.S.
Olvasson további információkat a blogunkban:
- «»;
- «»;
- «»;
- «».
Forrás: habr.com
