(A videó az IC Enterprise Technologies meetup-sorozat 2020. december 10-i, Kubernetes mindenkinek? című állomásán készült.)
- A hozzászóláshoz be kell jelentkezni
- 533 megtekintés
Hozzászólások
"Manapság mindenki Kubernetesen szeretne futtatni valamit."
Óriási szerencse, hogy ez nem így van..
- A hozzászóláshoz be kell jelentkezni
ezek szerint neked radaron kivul van. de tenyleg extrem a buzz. mar a sima hostingcegek is azzal jonnek, h az ugyfelek ezzel nyaggatjak oket.
- A hozzászóláshoz be kell jelentkezni
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".
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
[ironia]
ja, persze, megkerulni a sysadmint es a security team-et, az mindenkinek jo lehet es meg GDPR "compliant" is
[/ironia]
- A hozzászóláshoz be kell jelentkezni
Senki nem akar megkerülni senkit. Csak aki írja a service-t, esetleg tudja is, hogy hogyan kellene skálázni és monitorozni, stb.
- A hozzászóláshoz be kell jelentkezni
É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."
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
És fejlesztőként meg tudod csinálni rendesen a clustert is meg a szolgáltatások indítását?
Meg. Nem egy Kubernetes clustert setupoltam már. Az a titka, hogy érteni kell hozzá.
- A hozzászóláshoz be kell jelentkezni
É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... :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
" 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.
- A hozzászóláshoz be kell jelentkezni
Lehet, hogy érdemes egy picit nyitottabban hozzáállni a kérdéshez, különben lehet, hogy egy idő után talán azt veszed észre, hogy nem téged, hanem az AWS konzolt fogja megkérni a devops kolléga...
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
extrem buzz volt a Ruby on Rails is tizen es valahany eve, aztan a Big Data, nem is annyira reg a VR aztan mindenik megallapodott es megtalalta a helyet :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
ez igy van, de uzemelteto sem :)
- A hozzászóláshoz be kell jelentkezni