[Video] Production-Ready Kubernetes

Címkék

Sági-Kazár Márk (Banzai Cloud)

Manapság mindenki Kubernetesen szeretne futtatni valamit. Mindegy, hogy mit, csak ott fusson, mert menő. Való igaz, hogy a Kubernetes sok problémát és folyamatot megkönnyít, de arról már sokan elfeledkeznek, hogy mennyi mindenre van szükség egy megbízható, magas rendelkezésre állású, hibatűrő cluster futtatásához, legyen az a minden akár költség, eszköz vagy tudás. Az előadásban ezekről lesz szó ...nagyon röviden, hiszen erről is végtelen sokat lehetne beszélni.

(A videó az IC Enterprise Technologies meetup-sorozat 2020. december 10-i, Kubernetes mindenkinek? című állomásán készült.)

Hozzászólások

"Manapság mindenki Kubernetesen szeretne futtatni valamit."

Óriási szerencse, hogy ez nem így van..

Arra kifejezés sincs, hogy mennyire, de elkerülni sajnos nem tudom, Openshift-et üzemeltetnem kell kényszerből. De az egész hype-pal kicsit sem értek egyet és extrém mértékű túlzásnak gondolom. Bőven nem megváltás, sem a Kubernetes, sem maga a konténer-technológia, lehet pár esetben helye, de nem ennek kéne lennie a jövőbeni "mindent vivő slágernek".

Mondjuk fejlesztőként az, hogy nagyjából magam (azaz a csapat) tudja managelni, diagnosztizálni, javítani az összes teszt és prod env-ben az app összes példányát, anélkül, hogy a devops/sysadmin srácokat/lányokat kellene nyaggatnunk, az igazán hasznos és jó dolog.

És fejlesztőként meg tudod csinálni rendesen a clustert is meg a szolgáltatások indítását?

Mert látok olyanokat, akik 5-7-9 gépet kérnek (VM) mert kubernetes cluster kell nekik, de nemhogy a clustert, még azt sem bírják beállítani, hogy a dockerben induljon el automatikusan a szarja... És  azon megy a hiszti, hogy miért kell a maintenance restart, mert nem indulnak el a cuccok automatán. Nekik kell kézzel indítani, így hát ne is éjszaka legyen már, hanem munkaidőben, ja és egyszerre max 1 gépet, mert ha több kiesik akkor bedől az egész.

Szóval ez az, amikor iszonyat nagy körítéssel, többszörösen túlallokált erőforrással, sok plusz munkával sikerül azt elérni, hogy a stabilitás és a rendelkezésre állás kisebb, mintha egy core2duo pc zúgna a sarokban, és arról futna docker meg minden bloatware cucc nélkül az app. Gratulálok, ez az igazi devops.

"Sose a gép a hülye."

Tipikus peldaja annak a mondasnak, hogy "Ferrarival, hatramenetben, a hatso udvaron..."

Mindennek megvan a helye, de amig mindenkit elvakit a hype sajnos ezzel kel ellni, nem ez az elso technologia amit ennyire tol a hype es nem is az utolso.

Sajnos sokan es sok, kulonben eletkepes projekt e miatt tonkre fog menni

És fejlesztőként meg tudod csinálni rendesen a clustert is meg a szolgáltatások indítását?

A cluster felépítése mióta dev feladat? Erre vannak a devops kollégák. Ők szolgáltatják nekünk az "infrát", mi manageljük a saját szarjaink.

Ők azt csinálják amit szeretnek: tutujgatják az infrát.

Mi azt csináljuk, amit nem szeretünk, de muszáj: üzemeltetjük a szarjainkat, ahelyett, hogy megírnánk és lepasszolnánk az üzemeltetésnek. A mi dolgunk a szoftver fejlesztése, az ő dolguk az üzemeltetése, nem? Hát nem?! Francnak szivatnak engem azzal, hogy nem elég hogy megírom, még futtassam is, meg tartsam karban a szoftvert? Ki hallott már ilyet?! Szoftverfejlesztő vagyok, nem üzemeltető a mindenségit neki!!!!44

Na, nekem is lehetne ilyen a hozzáállásom, de nem ilyen. Manapság az a trendi, hogy a fejlesztő csapat üzemeltesse a saját szarjait, mert van benne ráció. Nem szeretem én se, hogy rám tukmálták az üzemeltetés egy részét (mert ugye egy fejlesztőnek mindenhez _is_ értenie kell), mert jobban élvezem a szoftver írását, mint a konfig fileok turkálását, de azért még mindig egyszerűbb, mint állandóan szívni a random sysadminnal, mert már megint nem érti, hogy mit akarok és segítség helyett inkább lekezel. Tudod mit? Inkább üzemeltetem a saját serviceimet, de még egyszer ne kelljen egy megfáradt, megcsömörlött, csapatjátékra képtelen, soft-skillekkel kevéssé megáldott rendszeradminnal dolgoznom... :) 

Mert látok olyanokat, akik 5-7-9 gépet kérnek (VM) mert kubernetes cluster kell nekik ... ja és egyszerre max 1 gépet, mert ha több kiesik akkor bedől az egész.

Mi AWS alapon dolgozunk egy ideje, az utolsó DC idén lesz leszerelve. Ott meg annyi a dolgom skálázódás esetén, hogy nem 3-at, hanem 4-et írok a konfigba.

Friss történet, ma (csütörtök) sikerült megoldanunk. Még november végén szólt az egyik devops kolléga, hogy szar van a palacsintában, az egyik service-ünk irgalmatlanul eszi a memóriát, node-onként 1.5Gi-tal, hogy valahogy eldöcögjön prod-ban, fél óra alatt megevett másfél GB RAM-ot, majd kifogyva a memóriából a node elcrashelt. Még terheletlenül is. De fejlesztői csapatként időnk nem volt ezzel foglalkozni, mások voltak a prioritások.

Na, kedden jött el az a pillanat hogy már a teszt környezetre se tudtunk deployolni, valami nagyon beakadt, és egyszerűen sorra haltak meg a pod-ok, még mielőtt a k8s azt tudta volna mondani, hogy ez a deployment healthy, majd folytatta volna egy folyamatos crashloopbackoff-fal, de legalább adott pillanatban 1 élő node-dal.

Ennek már a fele se tréfa, szóval megoldottuk azzal, hogy egy szintre hoztuk a teszt node-ok memória foglalását prod-dal, 1Gi helyett kaptak 1.5-öt.

Ennyi, probléma megoldva. Tudtunk tovább foglalkozni a fontos dolgokkal.

Nem, amúgy nem. Írtam a devops srácnak, hogy "figyi, ideiglenesen megemelem a memória limitet a teszt környezetben 1.5-re, és prioritizálom a csapattal a probléma okának feltárását". Erre nyilván dobott egy "aha, nem most jöttem le a falvédőről" választ, hiszen "Nothing more permanent than a temporary fix", meg ugye "nem is a 1.5GB a ciki, hanem az a 12 node, ami prodban megy és amiknek a harmada adott pillanatban épp újraindul" úgyhogy mondtam is neki, hogy jogos, megemeltem a memória limitet, hogy unblockoljam a teszterünk és a többi munkát félretéve neki álltam debugolni.

Gyanakodtam erre, gyanakodtam arra, mígnem támadt egy (utólag) jónak bizonyult ötletem. Épp ma tartottam egy kis prezentációt az ArgoCD-ről fejlesztői szemmel, próbálva ösztönözni a többi csapatot, hogy kezdjenek migrálni az új deployment megoldásra. Ebben megemlítettem, hogy "hát igen, ezzel a problémával szenvedünk éppen, de ArgoCD UI-on a memória felhasználás nem látszik, szóval nem váltja ki teljesen pl. a k9s-t, ha debugolni kell. És mellesleg ha valaki már találkozott ezzel a problémával, nyugodtan zaklasson az előadás után" :)

Jött is egy kolléga, hogy nekik is volt hasonló és látja, hogy az a service-ünk még mindig Java8-on van (lassan decommissioned lesz, túl sok energiát nem tennénk bele szívesen), és a J8 nem szereti a konténereket. Mondom oké, próbáljuk meg J11 alapon, hátha. Elsőre a teszt környezetben nyilván, mert ha megoldja a problémát, akkor a teszterünk tolhat rajta egy teljes regressziót, ami azért megterhelő neki is.

Minden jó, ha vége jó, J11 megoldotta, memória használat konstans ~200MB, nincs crash, stb. stb. A változtatás rolloutolásával vissza tudjuk scale-elni a pod-jainkat, pénzt spórolunk a cégnek, stb. stb.

Tanulság? Nem sok. Prioritások vannak. Korábban nem volt rá idő, mert business szerint inkább ezt és ezt kell fejleszteni, mert az hoz pénzt. Most se volt sok idő rá, de azért ez már tényleg szégyen volt. Mindenesetre örülök, hogy megoldottuk, és örülök, hogy jelentősen csökken majd az "IT lábnyomunk". Tanulság esetleg annyi, hogy AWS és k8s elég rugalmas ahhoz, hogy a szar kódot is elfuttassa egy ideig bármiféle érezhető probléma nélkül, és elég rugalmas ahhoz is, hogy a probléma elhárultával vissza lehessen scale-elni az infrastruktúrát, így a fejlesztői csapat az épp aktuális prioritásokra tud fókuszálni.

És miért ugrottam rá minden mást félretéve? Mert a devops kolléga normális, és nem basztatott, nem lekezelt, nem lefitymált, csak tényt közölt 3 hónapja, amire most tudtunk érdemben reagálni. Ő is megérti, és nem szapulja a deveket, hogy "jajj b+ még ehhez se értesz??!", hanem ha leülsz vele, akkor elmagyarázza, hogy mi és hogy megy. (Nagyon meg is lepődött, mikor ArgoCD-re álltunk át. Egyszer átrágtuk a főbb pontokat online, legközelebb csak akkor kerestem, mikor megkérdeztem tőle, hogy akkor prod-ba telepíthetünk-e már, vagy kell hozzá valami engedély. Fel is terjesztettek a havi mittudoménmilyen díjra, úgy meghatódtak, hogy milyen önjáró devek is vannak :)).

Gratulálok, ez az igazi devops.

hat, ezzel nem ertek egyet. a hype sok, nyilvanvalo. de a felgyorsult fejlesztes, a hatekony csapatmunka, monolitikus kodok microservice-ekre bontasa kikovezte az utat. ez az irany. az eroforras pazarlo vm-ek ebben a kornyezetben logikusan tendaltak a kontenerek fele, sok kontener pedig a kubernetes fele. persze sokan esz nelkul hazsnaljak ott ahol nem kene, de meg van a helye, fontos technologia, es szerintem egy evtizedre meghatarozza az it iranyat. ez az uj linux. :) arrol nem is beszelve, hogy az is boostolja a folyamatot, hogy a fejlesztoi es uzemeltetoi kornyezetek erosen egysegesednek.

" ez az uj linux."

Szerencsére ez még nem igaz. Ha neadjisten valaha bekövetkezik, aznap lesz a napja, hogy elhagyom a területet.

"a fejlesztoi es uzemeltetoi kornyezetek erosen egysegesednek"

Mint ahogy ez sincs így a jelenlegi helyemen (multi, csak az üzemeltetés többszáz fő), épp, csak felütötte a fejét a "devops", de tőlünk (alapinfra) szerencsére nagyon függetlenül dolgozik és semmi közös pontja a munkánknak azon túl, ha igényelnek egy szervert, telepítjük nekik.

Ami, ahogy fentebb is írtam, nem is zavarna, akkor már inkább elmegyek kapálni, annyira távol áll tőlem ez az egész "devops" és konténeres őrület(nettó infrás Linux admin vagyok)..mint mondtam, van, hogy látom értelmét (sőt, egyfelől az infráját részben üzemeltetnem kell, másrészt magam is használok ilyen technológiát), de ez nem jelenti, hogy szeretem, vagy, hogy egyébként kényelmes lenne használni (nem az).

Self hosted kubernetes esetén van még egy fontos komponens ami nem volt említve, a belső (metallb) és külső (ez mindenhol custom, de ha valaki tud erről oktatást/bemutatót megköszönném) load balancer, ami nélkül elérhetetlen a klaszter kintről. Annak idején elég sok időmbe telt erre rájönni.

Kicsit kezd .NET érzésem lenni, de majd csak rájövünk, hogy egy elektromos fogkefe vezérlő szoftveréhez nem kell Kubernetes cluster...

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.