Kubernetes Node and Application scaling
•Download as PPTX, PDF•
0 likes•72 views
Howto scaling our node and application in Kubernetes environment. Headroom and Tetris node scale. HPA v1 and custom metrics. Our Black friday success story.
Recommended
Recommended
More Related Content
What's hot
What's hot (10)
More from David Papp
Recently uploaded
Recently uploaded (20)
Kubernetes Node and Application scaling
- 1. David Papp pappdav.com - @pappdav Co-founder -
- 2. Kubernetes Node and Application scaling
- 4. Node Scaling
- 5. Units count * CPU resources Units count * Memory resources
- 9. Question?
Editor's Notes
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.