Kubernetesen sok DB konténer futtatása

Fórumok

Került hozzám egy projekt aminek javítani szeretnék a költséghatékonyságán. Ebben lenne jó egy picit együtt gondolkodni, meg tippeket is szívesen vennék.

Az a felállás, hogy ügyfelenként van egy Windows IIS szerveren futó webszolgáltatás, amit egy Linuxon futó MariaDB szolgál ki.

Minden AWS-en fut, de alapvető AWS szolgáltatásokat sem használnak, csak EC2-kön fut minden, közvetlenül telepítve, még konténerek sincsenek.

Az ügyfelek semmiféleképpen nem férhetnek hozzá egymás adataihoz, ezért minden ügyfélnek van egy külön Windows IIS és egy külön Linux EC2-je, bezárva a saját pici subnetjükbe. És ebből lassan 100 darab, ami ugye 200 EC2-t jelent.

Ez így szerintem nem jó hatékonyságú üzemeltetés. Sajnos az RDS nem opció momentán, mert a kereséshez fut egy indexelő szolgáltatás aminek a storage engine-e nem támogatott.

Arra gondoltam, hogy felhúznék a sok linuxos EC2 helyett egy EKS clustert. Arra felhúznék MariaDB konténereket, mellé az indexelő szolgáltatás konténerét, külön StatefulSettel és külön PVC-el mindegyik ügyfélnek. A Windowsos IIS-ek maradnának úgy ahogy, mert egyelőre nem konténerizálhatóak, csak átírnám a DB címét az új végpontokra. Ha jól sejtem NodePort-tal külön portra lehetne tenni mindegyik MariaDB konténert.

Van-e ebben a tervben valami nyilvánvalóan nagy buktató amire nem gondoltam?

Úgy gondolom, a Kubernetes segíthetne egy kicsit a hatékonyágon ebben a felállásban. Éjszaka, mikor nincs nagy terhelés, elég gondolom néhány node a ~100 DB konténerhez, nappal meg fel tudna húzni új nodeokat mikor nagyobb a forgalom. Másrészt meg a sok külön EC2-nek kezd elszállni az adminisztációs overheadje, mindet patchelni, monitorozni, backupolni, stb. külön-külön, nagyon szarul skálázódik.

Harmadrészt meg az IIS-függő webapp is átírás alatt van már multiplatform dotnetre, amit egyszer majd reményeim szerint szintén át lehetne tenni az EC2-kről Kubernetesre.

Hozzászólások

sub:) szerintem jarhato ut, de nem ertem miert sok melo patchelni azt a sok EC2 gepet az ansible vilagaban.

A patchelés még talán a kisebbik probléma, az AWS patch managerrel megy jelenleg. De majd MariaDB 10.4-ről 10.6-ra migrálást azt Ansible-el tervezem.

Leginkább azon javítanék, hogy teljes EC2-ket úgymond "elpazarlunk" mert dedikáltak egyetlen site-hoz. Van jónéhány olyan kisebb ügyfél, ahol 10-15 user van összesen. Na most ezért két EC2-t futtatni 24-7 szerintem nem hatékony, még akkor se ha reserved instancekről van szó. EKS-en meg sok ilyen kisebb ügyfél DB-je megférhetne összesen kevesebb node-on.

"Everything fails, all the time."

Belefér, hogy a scaling miatt bizonyos MySQL instanceok újraindulnak? Ha nincs HA, akkor szinte biztos kiesés. Ha jól értem, ezt napi legalább kétszer eljátszanád. 

Jogilag OK? Az ügyfelek oldaláról nem igény a külön subnet? 

Ha jól van időzítve, beleférhet egy kis kiesés. Mondjuk hajnali 1-kor scale-in, az nem kéne túl sokáig tartson, nem? Aránylag pici DB-kről van szó, jellemzően 500 MB alattiak, ha jól sejtem hamar indulnia kéne a podoknak.

Hajnali 4-5-kor meg scale-out, de reményeim szerint ez úgy viselkedne hogy előbb felhúzza a node-okat és csak utána kezdi átpakolni a podokat (vagyis újakat indítani az új nodeokon).

Jogi akadálya elméletileg nincs, amíg valahogy megoldjuk hogy ne fordulhasson elő adatcsere. A külön subnetezés csak a mi megvalósításunk, hogy jobban el lehessen szigetelni az ügyfelek sitejait. Pl. A ügyfél IIS szerverének véletlenül se tudod odaadni B ügyfél DB-jét mert a subnetek közt a security group nem engedi át a forgalmat.

"Everything fails, all the time."

Ha már a jogi oldal felmerült: Azt azért fontos látni, hogy az egy node-on futó Kubernetes POD-ok között csak egy Linux cgroups a védelem, míg külön EC2 instance-nál az Amazon VM infrastruktúrája. Ezt azért érdemes lepapírozni, ÁSZF módosítást elfogadtatni az ügyfelekkel, esetleg prémium szolgáltatásként felajánlani, hogy külön node-on fusson a DB-jük (kb. ugyanaz mint most, csak K8S-sel menedzselve).

Azt jól gondolom, hogy ugyanaz az alkalmazás fut sok példányban? Tehát ez egy multitenant-os alkalmazás, ahol a multitenancy úgy lett megoldva, hogy nem az alkalmazás kezeli, hanem magából az alkalmazásból van sok példány?

NodePort jó lehet arra, hogy a DB pod-okat publikáld a kubernetesen kívülre.

Viszont a kubernetesben való skálázásra nem az a tipikus use case, hogy a stateful pod-okat leállítod és nagyobb CPU/memory request-tel és limit-tel újraindítod őket reggel (ugye ezt a stateless esetben inkább úgy oldják meg, hogy több pod-ot indítanak). Ha az van, hogy a terhelés mindegyik db pod-ra pont ugyanakkor érkezik, akkor persze mást nem igazán lehet tenni ezen az újraindítás dolgon kívül, ha este spórolni akarsz.

Viszont kérdés, hogy tényleg mindig pont ugyanakkor van-e terhelés? Nem oszlik el napközben? Nem lenne célszerű úgy futtatni inkább, hogy kevesebb de nagyméretű worker node-ok, és egyszerűen azáltal oszlik el a terhelés, hogy a worker node-on belül melyik DB pod futtat éppen query-ket? Persze ezzel önmagában nem spórolsz éjszakára, ahhoz mindenképp kell az említett rövid leállás a stateful pod-ok újraindítása miatt.

Ami még egy limitáció AWS-ben és belefuthatsz, ha nagy worker node-jaid vannak, hogy egy adott worker node - EC2 típustól függően - legfeljebb 20-30 EBS volume-ot tud attacholni, mint PVC. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/volume_limits.html Ezt mindenképp vedd figyelembe tervezésnél!

Igen, ugyanaz a site fut sok példányban, különböző tenant-szintű beállításokkal.

Amire elsőre gondoltam stateless skálázás nem biztos hogy a legjobb ötlet ahogy írod is, nem olyan egyszerű. Egyelőre az is sokat segítene ha nincs skálázás csak nem 1 EC2 - 1 MariaDB az arány, és egy worker node modjuk elfuttat 20-at.

A terhelés mintája elég jól látszik Cloudwatchon a site-ok elé tett ALB-ken. us-east-2-n vagyunk és az ügyfelek nagyrésze is geográfiailag ennek a közelében van, szépen követi a napi ciklust.  Ugyanez látszik a DB-ben is a login logokból, normál munkaidőn kívül minimális az aktivitás.

Az éjjeli backup (db dump) és az újraindexelés miatt így is van egy kis csuklás hajnali 1-2 körül, még soha senki nem szólt érte.

Az EBS volume limitet köszi, azt jó észben tartani.

"Everything fails, all the time."

A konténerizáció nem annyi, hogy ez mostantól konténerben fut. Ebbe sokan belefutnak.

Első lépésként legyen kimondva, hogy ebbe az irányba mentek. Utána le kell ülni a fejlesztőkkel és megkeresni mind üzemeltetés, mind fejlesztés oldalról milyen akadályok lehetnek, majd erre kell egy előzetes becslés, hogy ezt mennyi idő lefejleszteni. Ha megvannak az idők és a módosítandó részek a szoftverben, akkor az Ops oldalon meg lehet kezdeni a tervezést.

Az ops oldalon a fenti információk alapján az alábbi kérdések merülnének fel a teljesség igénye nélkül:

  • Adatbázis:
    • hol tároljuk? (RDS vs saját konténer)
    • Lehet-e  gy nagy adatbázis clusterben tárolni az összes DB-t?
    • DB mentési stratégia
    • Ha saját konténerek, akkor minden DB server cluster módban fusson? Hány példányban legyen replikálva? Milyen szinten legyen kiesés ellen védelem? (Elég ha a db cluster módban fut és a két példány mondjuk külön worker node-n vagy a ló másik oldala és több EKS más régiókban load balancerrel. Az igazság valahol a kettő között lesz)
    • Ügyfelek elszeparálásának meghatározása (egy namespace per ügyfél vagy egy cluster per ügyfél)
    • ktg-ek alakulása (javasolt 2-3 verziót megtervezni,  majd megvizsgálni költség hatékonyság oldalról is.
    • Konténerek biztonsága
  • Applikáció
    • Kód biztonsága (konténerizálás módja, kód védelem)
    • Ingess-ek
    • Buildek áttervezése
    • Akartok-e technológiákban is modernizálódni, mint pl. GitOps (megvalósításban: FluxCD, ArgoCD stb.)
    • Verzió upgradek és rollback-ek.

Még sok minden más előjöhet a konténerizáció és a Kubernetes kapcsán, de ez ad egy elég jó képet arról,  hogy 2 teljesen más világról van szó és egy az egyben nem feltétlenül átvihető, ill. nem nyer semmit vele akkor pl. az OPS.

Jogos, teljesen jó kérdések amiken el kell gondolkozni mielőtt belevágunk. A probléma az, hogy ez egy pici cég ami most aránylag hirtelen növekedésnek indult, amolyan régi startup. És gyakorlatilag egyedül vagyok az egész IT modernizációra, jómagam sem éppen tapasztalt Kubernetes-admin.

Van még két veterán rendszergazda kollégám akik még a dockerrel is hadilábon állnak, de legalább mindketten nyitottak új dolgok megtanulására is.

Lehet, hogy kissé fordítva ülök a lovon ezzel az elképzeléssel, de ennek is megvan az oka: Az IIS-webapp .net Frameworköt használ, mire ebből bármi multiplatform konténerekre szétszedés és portolás .net core-ra megtörténne, az még optimista becsléseim szerint is minimum 3 év, de lehet hogy 5. De legalább már elindultak ebbe az irányba a fejlesztők.

Addig viszont legalább ami linuxon futtatható azt szeretném optimálisabban hostolni, én már azt is előrelépésnek gondolnám. Szerintem sok cég jár ebben a cipőben, ha jól tudom például a Nomad is ilyen feladatokra lett kitalálva ahol vegyesen van

"Everything fails, all the time."

Mivel azt írtad, hogy igazából a tudásotok fejlesztésre vár Kubernetes témában és a fejlesztőknek is kell idő az átállásra,  ezért ezzel indítanék és mindhárman megcsinálhatnátok egy Kubernetes kurzust. Akinek kell a Docker tudás is,az kezdjen azzal és utána csak a Kubernetes.

Rakjatok össze játszótereket, ahol a Docker és a Kubernetes tudásotokat fejleszthetitek ill. a PoC-ket kipróbálhatjátok majd.

Az miért nem jó, hogy egy DB szervered van, és minden ügyfélnek saját felhasználója, ami csak a saját adatbázisát látja?

Gondolom azért, mert láttam már olyan ERP-t aminél a user auth annyi volt, hogy felvettek egy DB User-t és neki állították, hogy melyik db melyik tábláihoz van hozzáférése. Ami még akár jó is lehet, csak ha jelen esetben listázod a usereket, akkor mindet meg fogod kapni aki a DB-re fel van véve(mondom ezt úgy, hogy lehet nem is ez a jelen koncepció). (De ez az eset akkor a legjobb amikor MS SQL-t használsz és kinyögik, hogy nem elég az alap szerver hanem per user licenc is kell...)

láttam már olyan ERP-t aminél a user auth annyi volt, hogy felvettek egy DB User-t és neki állították, hogy melyik db melyik tábláihoz van hozzáférése

Ez nettó user error, nálam minden webappnak dedikált usere van, ami csak a saját DB-jéhez férhet hozzá.

De ez az eset akkor a legjobb amikor MS SQL-t használsz és kinyögik, hogy nem elég az alap szerver hanem per user licenc is kell...

A kérdező MariaDB-t használ, ott ez nem probléma :-)

Sajnos van olyan ügyfelünk, aki olyan (német gyártmányú, élő, fejlesztés alatt álló) szoftvert vett, ahol

  1. minden user-nek SQL CAL kell, mert az SQL-lel hitelesíttetik a user-t annak ellenére, hogy van app szerver, nem az SQL szerverhez kapcsolódik a kliens szoftver,
  2. annyira szar a kliens szoftver kódja, hogy a desktop-okra telepítve használhatatlan, így Remote Desktop CAL-ok is kellettek minden user-nek és plusz egy szerver az RDS szolgáltatásra (a másikon az SQL és az app szerver fut).

Elképesztő pazarlás szerintem, ráadásul sokszor ennek ellenére (vagy éppen ezért?) nem is működik jól a rendszer...

Ez lenne a legegyszerűbb megoldás de sajnos több okból sem játszik.

Egyrészt ha megáll valamiért a DB szerver, akkor az összes site megállna egyszerre. Másrészt, könnyen előfordulhat hogy valaki elkonfigurál egy usert és véletlenül más adathoz is hozzáférhet. Egészségügyi adatokat is tárolnak a site-okon, ott bármilyen keveredésből elég komoly probléma van.

A keresési indexelés ideje is megnőhetne, most éjszakánként újraépítik az indexet, a kisebbekkel pár perc alatt végez. De ha egyetlen DB szerveren kéne minden DB-n külön végigfutnia, szerintem elég sokáig tartana (ez egyébként k8s alatt is probléma lehet, amin el kell gondolkodnom)

"Everything fails, all the time."

"Egyrészt ha megáll valamiért a DB szerver," - A MariskaDB is fürtözhető (galera), úgyhogy a "megáll a DB" max. akkor van, ha a node-ok több,mint a fele megpusztul. Az "elkonfigurál egy usert" ellen HBAC-jellegű védelem kell: a tenant1 user a tenant1app szerverről a tenant1 DB-hez férhet csak hozzá. Postgres esetén et pg_hba.conf -ban megadott összerendelés, nem SQL-ből megy. Hogy Mariskának van-e ilyen képessége, azt nem tudom, amikor csillió éve volt hozzá szerencsém, akkor ott ilyen igény nem merült fel.

"most éjszakánként újraépítik az indexet" - Wtf??? Ennyire szuboptimális a DB működése, hogy naponta ki kell kukázni az indexeket?

Hogy Mariskának van-e ilyen képessége, azt nem tudom, amikor csillió éve volt hozzá szerencsém, akkor ott ilyen igény nem merült fel.

Ezeknek a problémáknak az a megoldása, hogy nem kézzel kell kúrogatni, és akkor olyan policy checket raksz hozzá, amilyet csak megkövetel a haza.

"Másrészt meg a sok külön EC2-nek kezd elszállni az adminisztációs overheadje, mindet patchelni, monitorozni, backupolni, stb. külön-külön, nagyon szarul skálázódik."
Ez a resze mukodni fog jol, managed nodegroups es elfelejtheted a problemat.

"Éjszaka, mikor nincs nagy terhelés, elég gondolom néhány node a ~100 DB konténerhez, nappal meg fel tudna húzni új nodeokat mikor nagyobb a forgalom."
Ez a resz viszont nem ugy mukodik ahogy te gondolod.
Alapveto szabaly hogy db kontenereknel a pod request es a limiteket egyenlore allitjuk, igy viszont pont annyi node fog kellene ejjel is meg nappal is.
Ha nem igy teszel akkor amikor elfogy egy node-on a memoria akkor db pod-ok evictelve lesznek, vagyis szolgaltataskiesest generalsz.
Ha ez neked belefer akkor hajra, ha nem akkor viszont alaposabban at kell gondolnod az elkepzelesedet.

Ettol fuggetlenul szerintem mar az is nyereseg lesz hogy nem 1 ec2 = 1 db setuppal fogsz menni hanem biztosan rafer tobb db pod egy node-ra.

Alapveto szabaly hogy db kontenereknel a pod request es a limiteket egyenlore allitjuk, igy viszont pont annyi node fog kellene ejjel is meg nappal is.
Ha nem igy teszel akkor amikor elfogy egy node-on a memoria akkor db pod-ok evictelve lesznek, vagyis szolgaltataskiesest generalsz.

Ez félig igaz: a memóriát nem lehet overbookolni, azaz a request.memory = limit.memory production rendszerekben kötelező, ellenkező esetben a node-on lesz OOM, amikor a konténerek megpróbálják a request és a limit közötti különbséget elhasználni. Viszont cpu-ra ugyanez nem igaz, ott bátran lehet nagyobb a limit, mint a request.

"Ettol fuggetlenul szerintem mar az is nyereseg lesz hogy nem 1 ec2 = 1 db setuppal fogsz menni hanem biztosan rafer tobb db pod egy node-ra."

Első körben már ez is nagy eredmény volna, igazából ez lenne a lényege az egész projektnek. Ha esetleg sikerül valami értelmesebb scalinget beállítani hozzá már csak a hab a tortán kategória lenne.

"Everything fails, all the time."

Nem muszáj 1 computeot használnod.

Kubernetesnél is lesz SPOF, méghozzá a storage. Vagy egy Ceph-et is akarsz még telepíteni a k8s mellé? Vagy EBS-t használni az Amazonon?

Meg nyilván ott sem fog minden példány külön nodeon futni, különben ugyanott leszel, mint most, csak betettél még egy layert.

Sajnos az RDS nem opció momentán, mert a kereséshez fut egy indexelő szolgáltatás aminek a storage engine-e nem támogatott.

Bővebben? 

Ha jól értem, a lényeg annyi hogy SphinxSE pluginnal (ha_sphinx) működik a keresés, így tud a searchd-vel kommunikálni a MariaDB szerver.

Az összes keresés, indexelés a MariaDB-n kívül történik és csak az eredményt kapja vissza a searchd-től. Fut még egy service, az indexer ami újraépíti a searchd-nek az indexeket éjszakánként.

"Everything fails, all the time."

Semennyire nem tudok építő jellegű tartalmat hozzáadni a topichoz, cde kérdezni szeretnék, hogy tanuljak.

Miért pont EC2-n fut egy ilyen rendszer, ami non-stop működik, miközben a fizetés másodperc alapon történik (hacsak nem Reserved vagy hasonló konstrukcióban működik az account)?

Ha jól értem/tudom, az EC2 sem ad HA képességeket, azt az ügyfél magának alakítja ki több instance-ból, ha akarja. Akkor miért nem érdemesebb valami olyan helyen virtuális gépeket bérelni, ahol nem a skálázásra van optimalizálva a fizetési rendszer, hanem a folyamatos futásra?

Nem tudom mennyibe kerül így egy-egy user havi EC2 költsége a két VM-re, de nagyon érdekelne. Sohasem dolgozam még Amazon szolgáltatásokkal, nem tudom hogyan kell elképzelni a nagyságrendet egy ilyen volumenű bérletnél.

Ha bárki szán rá időt írni valami for dummies-t pár sorban, megköszönöm!

A 2 db VM költsége simán bele van építve az árba, a havi költsége a szolgáltatásnak szerintem 1 nagyságrenddel nagyobb lehet, mint az AWS költségek.

Ha van rá keret, akkor én is a 3 nagy (Amazon, Google, Azure) közül az egyiket használnám alapnak + esetleg valamelyik másikat backupként. Ha azt írod a szerződésbe, hogy akkor áll meg a szolgáltatásod (infrastruktúra része), amikor az Amazon is megáll, azt mindenki el fogja fogadni "vis mayor" helyzetnek. Ha kiderül, hogy 1000 USD+ -t fizet havonta, és megáll a szolgáltatás, mert 20 EUR-ért volt hosztolva a Contabonál (akik, mint az közismert, 99%-os rendelkezésre állást vállalnak), ott már legalábbis erősen magyarázkodni kell.

Nyilván van a kettő között is megoldás, Vultr, Digitalocean ... stb.,  de ha jól értem, itt sem az a gond, hogy spórolni kell, hanem hatékonyságot szeretne a kolléga növelni.

Pontosan így van. Még annyit hozzátennék, hogy annakidején (olyan 8-10 éve) az AWS volt a legkiforrottabb cloud szolgáltató, azért kezdték el ott kiépíteni a rendszereket.

Plusz sok külső tool támogatja, pl. Terraform, Packer, van hozzá igen okos CLI, aránylag normális support, stb.

Igaz, ma már van Contabo meg Digitalocean provider mindkettőhöz, de nem tudom mennyire kiforrottak és mennyire sokan használják. Az AWS Terraform providerrel ha bármibe beleszaladsz, valószínűleg már más is beleszaladt mert rengetegen használják és hamar meglesz a megoldás.

"Everything fails, all the time."

"Az AWS Terraform providerrel ha bármibe beleszaladsz, valószínűleg már más is beleszaladt mert rengetegen használják és hamar meglesz a megoldás."

ez altalaban igy van, de az eleted azert ne tedd ra. vannak furcsasagok, honapos kesesek alapszolgaltatasok eseten stb. pl. erre viszonylag sokat kellett varnunk furcsa modon (nem k8s mondjuk, csak epp ez jutott eszembe).

vegigolvasva a kommenteket meg az jutott eszembe, hogy koltseghatekonysag teren tudnal esetleg nyerni EKS Anywhere-rel. itt egy blog amit korabban konyvjelzoztem (csak forditsd le angolra). nem probaltam, de akar betanulni/jatszoternek is tokeletes lehet szamotokra, mivel ha megsem lesznek a gepeid "kint", siman tudsz ec2 instakat is alatenni (de a hetzner olcsobb a nap vegen, az tuti, a tf providere meg mukodik rendben, szoval a ket szolgaltato egyuttmukodesevel sem lesz baj).

meg akar azt is betippelnem, hogy eks anywhere+hetzner alapon tudnal ha-t epiteni a mostani arszinteden,szoval akar emiatt is erdemes lehet ranezni.

Köszönöm a válaszaitokat!

Azért kérdeztem rá, mert az összes felhőről szóló előadás úgy kezdődik, hogy azért lesz drága a felhő mindenkinek, mert rosszul használja, normál fizikai vagy virtuális gépeket visznek felhőbe, folyamatos futára, ahol a rendszer az idő nagy rászében semmit sem csinál, csak életben van és viszi másodperc alapon a pénzt hasznontalanul. Aztán ennek elkerülésére kell a dinamikus létrehozás-megszűntetés, de legalább bekapcsolás-leállítás, hogy kordában maradjon a költség.

De ha jól értem, ez csak akkor szempont, ha az árba "nem fér bele", a szolgáltatói díj java részét az AWS (vagy valamelyik másik) vinné el. Amennyiben az ügyfél által fizetett díj elég magas, akkor sokkal kényelmesebb a nagy felhő szolgáltatók megbízhatósága, "egyszerűsége", mint saját komplett rendszer építeni (bárhol) fizikai vagy virtuális alapon.

A ~100 stacknek mennyire kell együtt mozogniuk verziózásban? Pl. ha jön egy nagyobb MariaDB frissítés, akkor mindegyikre kimehet, vagy 10 beszállító azt mondja, hogy még fél évig nem lesz támogatott?

A Kubernetes alatt mi lenne a felállás? 100 külön namespace? Lenne itt valami HA a DB-knek, vagy 1-1 pod/sts? Limitek/requesteket hogy állapítanád meg? Pl az egyik ügyfél ezer kérés/sec-el bombázza míg a másik 1000 kérés/nap. 

Jó kérdések, köszi! Sorjában:

  • együtt kéne mozogniuk, de mondhatni elég konzervatívan frissítgetnek. Azt hozzáteszem hogy kb. 3 éve 10.4-en vannak és az még 2024-ig nem EOL. Talán jövőre átmegyünk 10.6-ra ami jó lesz egészen 2026-ig majd. Minor verzió frissítés meg gondolom nem túl komplikált pl. 10.4.24-ről 10.4.26-ra.
  • Namespaces: még nem vagyok benne biztos, eddig labelezésre gondoltam.
  • Alapvetően nincs HA. Az a kivételes néhány nagyobb ügyfél aki kért HA-t, teljesen külön Galera-clustereken van és egyelőre ott is maradnak, hozzájuk most nem tervezek nyúlni.
  • Mindenkinek 1 DB 1 Pod lenne, ahogy most 1 DB 1 EC2.
  • A limitek most úgy mennek hogy hány user licensz van a webappban. Olyan 100-120 userig momentán t3.small Linux EC2-ket használunk, felette, ha lassú és kell, t3.mediumot. Ha ez sem elég, a fent említett HA irányába terelik az ügyfelet. Valami ennek megfeleltethető módszert kellene kitalálnom Kubernetesen.
  • Ez most úgy megy hogy aki esetleg 1k/sec szinten leterheli, ott a Zabbix beriaszt és tudunk nekik szólni hogy ezt így nem kéne, vagy upgradeljenek a fentebb említett HA verzióra. A többieknek meg a fent említett módon kellene keresnem valamilyen megfeleltetést, hogy a mostani kezdő méretű t3.smallnál azért ne legyen lassabb ott sem, ahol alig van aktivitás.

"Everything fails, all the time."

Szerintem ez több szívással jár (ebben a felállásban ahogy tervezed) mint amennyi hasznot hoz. Olvasva a fenti hozzászólásokat, kérdéseket, business kritikus az alkalmazás, ami nem biztos, hogy fel van készítve a konténerizációra. A kubernetes nem azt garantálja, hogy egy pod mindig futni fog, hanem azt, hogy az adott deploymenthez tartozó podból mindig fog futni valamennyi (annyi, amennyit meghatároztál). EKS-nél jártunk úgy, hogy scheduled retirement matt cserélődtek a hostok, és a podok új node-okon jöttek létre. Ennek időpontját meghatározni te nem nagyon tudod, ami máris kockázattal jár. HA nélkül mysql-t/mariadb-t kubernetesen kezelni felér egy oroszrulettel.

A skálázódás jelen esetben db oldalról nem releváns neked, max a siteok oldaláról. Egy kicsit úgy érzem - javíts ki ha tévedek -, hogy azért akartok K8S irányba menni, mert ez most a trendi. Pedig nem mindenre jó a K8S.

Aztán ha jól értem, akkor az ec2-k esetében sincs redundancia, vagy backup. Mi történik, hogy ha megáll az egyik db ec2? Tolerálható a probléma? Ha igen, akkor mehet kubernetesbe is, mert ott sem lesz kisebb a leállás kockázata.

Amit szintén el kell dönteni, hogy egy alkalmazást üzemeltettek a sok usernek, vagy sok alkalmazást a sok usernek, ahogy ezt fentebb már kérdezték is.

Szóval, ha kritikus az alkalmazás, akkor én a következő irányba mennék el:

Kubernetes Namespacek (RBAC-ot jól kell konfigurálni):

- minden user külön namespacebe

- HA megoldás a db-nek

A világ IQ-ja állandó, csak egyre többen vagyunk rá....

StatefulSetről volt szó eddig, nem deploymentről, de utánanézek ennek a scheduled retirement dolognak.

Igen, valóban nem konténeresített az összes alkotóeleme a webappnak, de ettől még amelyik backend serviceket lehet konténerben futtatni, miért ne használnám ki az előnyeit legalább azoknak?

Jól érted, most sincs redundancia az EC2-kkel. Ha megáll, jön a zabbix alert, valaki bejelentkezik aki épp ügyeletes, és reagál a problémára. A megoldandó feladat itt nem a rendelkezésreállás növelése, hanem az erőforrások hatékonyabb kihasználása. Persze csökkenti sem szeretném a mostani átlagos rendelkezésreállást, de azoknak az ügyfeleknek akiknek erre van igénye, van teljesen külön HA-setup 3 nodeos Galera clusterrel.

Ezzel a Kubernetesbe zsúfolt MariaDB megoldással a kicsiket céloznám meg, mert abból sok van és feleslegesen foglalnak erőforrásokat.

"Everything fails, all the time."

Én lehet, hogy arra indulnék el, hogy a kicsiknek is megcsinálni a 3 node-os Galera clustert, de Kubernetes alapon, és utána, ha már náluk ki van tesztelve, akkor a nagy ügyfeleket is átmozgatni erre az infrastruktúrára, csak náluk esetleg 3 külön node-ot indítani, vagy akár külön clustert, de ugyanazokat a toolokat használva. Ezzel tudnád igazán a működtetési / humán költségeket csökkenteni.

Tegyük fel, hogy most 5 node-on van az 5 db kis DB, és valójában egy node-ra K8S-sel be tudnál csomagolni 5 DB-t. Így 3 node-dal HA adatbázist tudnál biztosítani 5 ügyfélnek, és megkezdeni a tesztelését a nagy ügyfelek átállításának.

Közben el lehet kezdeni marketingelni a fejlesztőknek, hogy ők valójában át akarnak állni K8S alapú cloud native fejlesztésre, csak még nem tudnak róla. :)