ºÝºÝߣ

Editor's Notes

• #2: Sziasztok! Papp David vagyok a Recart dolgozom.A kovetkeyo honapba lesz 2 eve. A regi nevunk GhostMonitor volt egy nagyobb brand valtason estunk at. Ha valaki esetleg nem hallot volna meg rolunk akkor azzal foglalkozunk ,hogy a webshopok konverziojat emeleljuk ami jelenti ,hogy minel tobb vasaroljuk legyen. Egy rovid cegtortent ,hogy mi mikent juttotunk el ide. Ugy-e aki nem ismer minket az felteszi a kerdest minek is van nekunk szuksegunk kontenerek vagy-e egyaltalan barmilyen microservices architecktura. Egyreszt gondoljatok bele milyen nehez dolgunk. Nah nem kell sajnalni mineket csak erdemes megerteni a problemankat. ?. Mi egy SaaS vagyunk amit az ugyfelek igenybe vehetnek. Nah mar most ha egy ugyfel beregisztral akkor mi nemtudunk rola semmit mennyi latogatja van mekkora forgalmat bonyolit le¡­stb. A mi kis tracking rendszerunk beepul a shopjaba automatan es hasznalja boldogan. Ez ahhoz hasonlo mint a google analytics amint barki betelepithet az oldalaba a legkisebbetol a legnagyobbig es ez meg se omlik ossze ?. Nah erre a problemara minekunk is fel kell keszulni mert mi sem ismerjuk a masik oldalt. Nagyabbol naponta 20-30 uj regisztracionk van es kb. 2500 aktiv e-commerce shopunk van ami b2b szektorba egy eleg szep szam.
• #3: A rendszerhez persze adhatunk kezzel hozza nodeokat es a podokat is szabalyozhatjuk kezzel. De ez valjuk be nem tul hatekony modszer arra, hogy egy eles rendszert uzemeltesssunk. ?Jo lenne valami automatikus rendszert hasznalni erre mert ha ejjel 3 kor fel kell azert kelni mert a rendszer eroforras hianyba szenved azt valszeg senki nem szeretne a terembe ulok kozul.?  A kubernetesbe van megoldas az application es a node scalingre is.
• #4: Miert van szuksegunk erre?  Amennyiben a rendszert nem csak egy szemelyes felhasznalasra akkor szuksegunk lesz valami scaling megoldasra. Persze ott van a vertikalis skalazas de draga es nem lesz tul hosszu tavu sem es eleg sok problemaval jar egyutt.
• #5: Node scaling  A nodeok skalazasara 2 fajta modszer van jelen a kubernetesbe a tetris es a headroom. Mind kettonek van elonye es hatranya.? Ha uzleti oldalrol kozelitem meg a kerdest akkor koltseg szempontbol a tetris a jobb megoldas. Ha technologiai oldalrol kozelitem meg akkor pedig a headroom.  De azert nem ennyire fekete-feher a dolog.  Kezdjuk eloszor a tetris logikaval.  Tetris  Remelem mindenki ismeri a tetris nevu jatekot ?. En anno eleg sokat jatszodtam vele.  A kubernetesben levo tetris logika egyeszeru. Pont annyi eroforrast tart a rendszerben mint amennyire szuksege van.?  Ennek pozitivuma nincs felhasznaltlan eroforras a rendszerben es igenyel a rendszer uj eroforrast ha szuksege van ra.  A hatranya az, hogy amennyiben kapunk nagyobb terhelest vagy a rendszeren belul egy nagyobb eroforras igenyu feladat jelentkezik varni kell amig az uj nodeok bejonnek.?  Viszont ez egy koltseg hatekonyabb megoldas mint a headroom.  Nalunk egy node 2-4 percig tart amig bejon a clusterbe. Pl. a deploy process megall es var peding allapotba kerulnek a podok ez nem tul hatekony lassukbe. De van a problemara megoldas. A legtobb kubernetes autoscaler megoldast ezt a modot tamogatja.
• #6: Headroom  Nevezhetjuk egyszeruen buffernek is. Az elmelet lenyege ,hogy mindig hagyunk szabad kapacitast a rendszerben. Hogy mennyit az szerintem rendszerre valogatja.  Mivel nalunk gyakran fordulnak elo peakek a rendszerben ezert mi normal mukodes soran ha nincs varhato nagy kampany idoszak akkor nagyabbol 30%-os buffert hagyjunk meg.  De, hogy ne legyen tul draga a rendszert fentartani csak spotinstekkel dolgozzunk az alkalmazasok alatt. A rendszer korulbelul 95% spotinstekre epul.  Van egy keplet a headroom-ra.  15 Units count + 1024 CPU Headroom + 512 MiB Memory headroom  15360 CPU unit jelent?  Az elmeletben ez ket magos instancebol ez kb 8-t jelent vagy 4 magosbol 4-t.?  A gyakorlatban vannak evicion policyk es a rendszernek tartunk fent eroforrast igy kb 9.5 es 5.5 fel instance van pluszba a rendszerbe.
• #7: Application scaling  Most mar ,hogy tudjuk skalazni a nodeokat nezzuk meg mi tudunk az alkalmazasinkkal csinalni. 79 darab servicebol all a jelenlegi rendszerunk. A rendszerben nem egyenloen oszlik el a terheles ha egy nagyobb kampany kikuldes van akkor van kell fel scalelni 1-2 servicet majd le kell scalelni. Ez egy orok szelhalom harc. Regen nem volt tul szeles a paletta amibol valasztani lehetett pod scaleingbe.  HPA A fo komponen a Horizental Pod Autoscaling nevu resource ezzel tudjuk skalazni az alkalmazasinkat kubernetesen belul.  v1 A v1-s verzio ?csak CPU alapjan tud skalazni. Tehat ha egy pod az eloremeghatarozott CPU mennyiseg x % szazaleket elfogyasztotta akkor a rendszer inditott belole megegyet. Van egy minimum es egy maximum ertek amit meg belehet neki allitani.  custom metrics A jovo egyertelmuen ez a megoldas-e. Mivel nem biztos ,hogy csak CPU alapjan szeretnenk skalazni az alkalamzasinkat.?  Vegyunk egy egyszeru peldat pl. nginx.