Kubernetes storage kérdések

Linux-haladó

Sziasztok!

Nálam több tapasztalattal rendelkező Kubernetes szakik véleményére lennék kíváncsi, hogy milyen storage megoldást érdemes választani a lentebb pár mondatban körbeírt rendszernek.

Kb 200 pod-ot szeretnék futtatni, mindegyiknek lenne egy konfigurációs volume-ja, illetve egy tároló volume-ja, ami kb. 1-2GB max, max. 1000db fájl Podonként. Az IO karakterisztika leginkább csak olvasás, néha kell a volume-ba új fájlt helyezni, de ezt nem is az alkalmazás végzi (így jó lenne ha elérhető lenne a volume egy másik pod-ból is pl. ahol a feltöltés zajlik).

A kevés adatmennyiség és a többnyire RO operáció miatt nem különösebben szeretnék NFS clustert építeni a Kubernetes mögé, így valami olyanban gondolkodom, ami magában a Kubernetesben képes megvalósítani a PV kezelést. Amit nézegettem: OpenEBS, Rook. Gyakorlatilag abban van megkötve a kezem, hogy support miatt OLCNE-re építkezünk, ez hivatalosan a Rook-ot támogatja/szereti. A CEPH-el nem lenne bajom, de gyakorlatilag a 3 worker, 2-2 SSD untig elég lenne, ebben a környezetben meg nem muzsikál a legjobban a CEPH, bár az is tény h. írási IO igényem nagyon minimális. Olvasási sem túl sok egyébként, 1-2 IOPS / Pod kb.

Amit szeretnék:

  • legalább 2 példányban tárolni az adatokat (ceph esetén 3-as replika, ez ott meg is lenne oldva)
  • kívülről hozzá szeretnék férni (pl. másik Pod-ból ReadWriteMany)
  • szeretném menteni lehetőleg PV szinten, nem tákolva

Ami good to have:

  • később esetleg Write-karakterisztikájú workload-ot is tenni rá (pl. loggyűjtő)
  • skálázni lehessen mind méret, mind teljesítmény tekintetében lehetőleg dinamikusan, zero downtime mellett
  • out-of-the-box dashboard v. valami csillivilli statisztika tool (cli is lehet éppen)

A hw részét most engedjük el, ha netán a Rook lesz a befutó, akkor 10Gbe network alap lesz, bár most nincs kéznél, illetve megfelelő mennyiségű, minőségű SSD-t is vennénk, szóval ez nem lesz szűk keresztmetszet és nem a szomszédbácsi winxp-s gépén szeretném mindezt megvalósítani :)

Köszi!

  • 954 megtekintés

( Sixday v | 2023. 08. 21., h – 14:40 )

Konfig managementre PV-t hasznalni egy nagyon rossz architect dontes.

Vagy huzza az app direkt gitbol a configot, vagy ha bena/legacy/zartforrasu az app es file kell neki akkor siman rakd be configmap-ba.

A configmap-al az a gondom h. rettentően korlátos. Key-value gyakorlatilag, ami azért lássuk be, sok alkalmazásnak nem elég. Azt értem amit írsz h. ez egy rossz döntés zöldmezőn, mint architect, de ezen a ponton egy problémát szeretnék megoldani, nem újakat generálni. Hosszabb távon a git-ből húzás lesz a jó irány (most is van etckeeper külön branchenként a gépek), ami felé már tettünk lépéseket.

Barmilyen text file tartalmat bele lehet tolni egy configmapba (pl. certeket, privat kulcsokat, tetszoleges alkalmazas konfiguraciojat, stb.), egyaltalan nem kell key-value-nak lennie, valamint 1 configmap-ban lehet tobb ilyen bejegyzes is.

Pl. nalunk van olyan is hogy a jenkins reszlegesen titkositott credentials.xml file-ja kompletten egy configmapbol jon (a hozza tartozo 3 kulcs meg egy secretbol) es onnan szippantja fel a jenkins pod.

Utana amikor a pod mountolja akkor ujra ott a file, mintha mise tortent volna :)

Jogos, mert a value lehet gyakorlatilag egy "fulltext" is. 

Jelenleg inkább az a problémám h. túl sok újdonságot nem merek lerakni az asztalra, mert kiég az agya az olyan kollégáknak akik pl. git-en sem szocializálódtak még, nem hogy ilyen csoda dolgokon, ráadásul realtime kell futásidőben néha a konfigot módosítani és csak realodolgatjuk a service-t, mert alapvetően nem egy cloud native cuccról van szó (hogy miért arról hosszasan beszélhetnénk, elég az hozzá h. rtp, sip, stb. sz.pókör).

Így egyelőre marad a PV "mountolva" /etc/legacyapp folderben, de a következő lépés valami ilyesmi lesz, bár a GIT-es verzió jön be, csak akkor ott valami olyan pipeline kellene h. configupdate git-ben, review, majd deploy a megfelelő podba, reload és kész a szegény ember CI/CD -je :)

A helyi korulmenyeket te ismered :)

A kovetkezo lepeshez viszont mindenkeppen azt javaslom hogy pull-oljatok es ne pusholjatok a podba, vagyis vagy az app vagy egy seged-app 3-5 percenkent nezzen ra a gitre es ha valtozas van akkor pull es reload. Igy a CI/CD folyamatod egy sima git review-ra csokken.

De az meg jobb ha megiscsak configmapbe rakod a konfigot es azt frissited egy kulso service-el, az appnak pedig csak a config file-t kell lokalban figyelnie es ha valtozik akkor reload.

köszi, ezek valóban hasznos előadások a témában. Jelenleg a legnagyobb gondom az h. a csapatban nincs meg a technikai tudás, ráadásul még fejlesztünk is, a fejlesztők pedig végképp legacy módon dolgoznak.

A Kubernetes mint igény azért fogalmazódott meg a fejemben, mert -bár lehetne mezítlábas Docker + Docker compose alapokon is menni- ez a defacto container orchrestation technológia, amibe mindenki beleállt és nem szeretném úgy megépíteni a céges infra alapjait, ahogy azt eddig tették. Értsd: nem akarok már eleve legacy rendszert csinálni, de gyakorlatilag az is nagyon nehézkes, hogy egy ideális állapotra álljunk át, hiszen a fejekben nem tudok 1-2 hét alatt ilyen mértékű változást beindítani.

Itt jött képbe h. akkor kezdjük azzal h. Kuberetes (200 VM helyett mindenképp a konténerek jelentik a jövőt, hiszen gyakorlatilag 1 processt futtatunk a vmekben -> microservice), hiszen erre lehet majd alapozni, de első körben a lehető legkevesebb változást kellene okozni, mert mire az üzemeltetés beletanul, illetve a fejlesztésbe bele tudok vinni olyan fogalmakat h. CI/CD az sokkal több idő, mint üzemeltetés oldalról megfogni a dolgot és a nagyon overkill VM-eket konténerizálni első körben.

Hát kb. itt tartunk most :) 

A Kubernetes jó választás ha sok microservice van.

Ehhez viszont a fejlesztői gondolkodásmód kevés lesz. Fel kell venni a DevOps gondolkodásmódot hozzá és ez legalább egy egész embert fog igényelni. Tehát valaki vagy kiesik a fejlesztésből vagy célszerű felvenni/megbízni olyat, akinek ez a szakterülete és ezzel dolgozik minden nap.

Válasszuk ketté. Első körben olyan microservice-eket raknánk a Kubernetesbe, amiket nem mi fejlesztünk, tehát az egész szemléletmód váltás, megvalósítás az üzemeltetés vállát nyomja. A gond az, hogy eleve legacy amit konténerizálni akarunk (Cloud Native szempontból legacy), tehát olyan finomságok kellenek hozzá, mint pl. a Multus CNI, mert kell neki teljesértékű network (kb. 10k udp portot nehézkes lenne másként kezelni és/vagy kívülről fogadni), erre nem láttam még jó példát K8s-ben, mint Service.

A szemlélet megvan az én részemen, a technikai része is, csak azt sem lehet prod rendszerben, hogy akkor hirtelen mindent is kicserélünk és rátukmáljuk az egészet olyanokra, akik most látnak életükben először konténert. Ez egy folyamat lesz, nem tudok varázsütésre OpenShift-be költözni pl, mert nincs meg hozzá sem a háttér, sem a tudás, sem a fejlesztői szemlélet.

Azt látom jelenleg iránynak, hogy ezeket a microservice-eket Kubernetesbe költöztetjük, valahogy megoldjuk a konfig menedzsmentet (lehet ez GitLab + Argo is), az adatok jó és helyes tárolását (itt jött képbe ez a forum topic), felépítünk rá egy kezdetleges pipeline-t, aztán ha ez jó és lehet mutogatni h. miért jó, akkor könnyebb belehúzni a változásba a DEV részt és a saját fejlesztésű dolgokat.

Ja és még annyi h. hiába cserélem akár az üzemeltetést, hiába hozok be olyan embert a DEV-be aki vágja, hiszen azokat is rá kell ültetni erre a körhintára, akik már ezt csinálják -fogjuk rá h. legacy szemlélettel- 10+ éve.

( djsmiley v | 2023. 08. 21., h – 14:55 )

Szerkesztve: 2023. 08. 21., h – 14:55

_nemide_

( _Franko_ v | 2023. 08. 21., h – 18:09 )

Ceph overkill, a Rook jó lehet, ilyen terhelésre amúgy a GlusterFS is megfelelő, az elvileg szintén támogatott RHEL/OL kapcsán és nem pilótavizsgás.

https://iotguru.cloud

A rook is ceph, csak kicsit ki van könnyítve.

Glustert nem támogatja már az Oracle Cloud Native Environment 1.7-től, szóval azt kilőném, nem akarok olyan komponenst behozni, amire később nem tudok supportot venni ha a szükség úgy hozza.

A rook viszont támogatott, a Longhornt meg támogatja a Suse ha kell. A gluster jó móka, de nem vállalom a kockázatot inkább.

( kallaics | 2023. 08. 22., k – 06:37 )

Szerkesztve: 2023. 08. 22., k – 06:40

Ahogy fent is írták korábban, a koncepció is fejlesztésre szorul. Amennyiben most ismerkedtek a Kubernetessel, akkor először fel kell venni az ehhez szükséges tudást, hogy jobban megértsétek a teljes konceptet,  avagy hogyan is működik a Kubernetes.

Ha van egy jó alap, akkor csinálni lehetne egy PoC-t, ahol különböző dolgokat ki tudtok próbálni. Erre akár egy minikube is jó lehet. Eles rendszerhez pedig rendes k8s.

Ha ti magatok szeretnétek kubernetes infrastruktúrát üzemeltetni, akkor ehhez is fel kell venni a megfelelő tudást és architektúrálisan kitalálni mit szeretnétek. Erre jobb, kész supportált megoldást venni hosszú távon.

Tehát az lenne a lényeg, hogy ez nem egy dodzsem, hogy egy pedál és kormány aztán hadd menjen. Itt bizony fel kell venni a szükséges tudást mindenképpen. Ezen felül rengeteget túrni a netet, hogy mások hogyan implementálják a dolgaikat, milyen toolkit-ek vannak ehhez stb.

Ehhez jönnek a build folyamatok (CI), registry, képbe kerülhet a GitOps (CD) és egyéb dolgok.

Ha már GitOps, akkor ennek a kapcsolódó fogalomnak is célszerű utánaolvasni és elsajátítani a hozzá tartozó gondolkodás módot.

Javaslom ha már megvannak az alapok, akjor van Youtube-on a DevOps Toolkit nevű csatorna Viktor Farcic-al. Sok érdekes videója van.

Érdemes lehet követni a Cloud Native Foundation oldalán, https://cncf.io -n milyen projectek vannak,  mert jó kis gyűjtőhelye a Kuberneteshez kapcsolódó alkalmazásoknak.

Ha ezeket megnézitek, akkor kiderül, hogy a Kubernetes sokkal többről szól, mint egy VM vagy vagy egy Docker és rengeteg jó szolgáltatás épül köré,  amiket használni is érdemes.