Jenkins, Kubernetes kérdés
N Jenkins munkával, M párhuzamosra generált Jenkins stage-ekben helm chart csoportok telepítése avagy létezik-e kubernetes shared queue?
Sziasztok!
Egy érdekes problémába futottam bele Kubernetes, Jenkins, helm chart témakörben.
Adott egy szoftver ami microservice-ekké lett átalakítva, a különböző egységei mind különböző helm chart-ok.
Egy teszt-automatizálási rendszert készítettem - Adott sok-sok yaml amely tulajdonképpen a termék különböző lehetőségeit tartalmazza, a rendszer gyakorlatilag ezekből a változókból generál values file-okat a helm chart-ok részére telepítés céljából.
Egy teszt nem más, mint egy csoportja a helm chart-ok telepítésének (majd további teendőket végez), nyilván a változóknak megfelelően beállított telepítést eredményezve. Mindegyik "helm chart csoport" multi-tenant jelleggel, különböző namespace-ekbe kerül, így nem különösebben zavarják egymást.
Jenkins, amikor ezt a teszt-automatizálási feladatot lefuttatja, sajnos mivel nincs végtelen erőforrás, nem telepíthet párhuzamosan "végtelen" tesztet, azaz a helm chart-ok csoportját.
Mivel a Jenkins-ben a parallel stage nem korlátozható könnyedén, én ezt a feladatot egyelőre (később majd automatizálom) konkrét számú (úgyis 99%-ban egyelőre X erőforrás kell nekik szóval később ráér számolgatni), egy LinkedBlockingQueue-val oldottam meg, amelynek segítségével igaz, hogy 1 Jenkins munkafeladat 200 tesztet szeretne futtatni, egy időben a LinkedBlockingQueue miatt, csak Integer maxParallel-t fog egy időben telepíteni, tekintve, hogy nem szeretném hogy a telepítések a sorrendbeli telepítés miatt úgymond "deadlock"-oljanak. Ilyen deadlock lenne, ha mondjuk 200-szor próbálja telepíteni a helm chart csoport első elemét, és tegyük fel épp a 147-ig jut el, mire kifogy az erőforrásból, és hát az első 147 nem tudja folytatni a második chart telepítésével, a többi pedig az előző befejezésére vár hogy az elsőt telepítse - itt pedig a deadlock, egymásra várnak. Tehát ezt ezzel a LinkedBlockingQueue-val sikerült megoldani, viszont ez csak az egyik fele a problémának.
Nyilván van az az eset, hogy nem 1 Jenkins munka kér 200 tesztet, hanem mondjuk 200 kér 300-at, azaz N Jenkins feladat kér M tesztet.
A probléma viszont az, hogy adott Jenkins feladatnak fogalma sincs hogy az épp előtte sorban álló (vagy épp konkurrensen futó többinek) még mennyi terve van hogy telepítsen és abból is, mennyi helm chart-ot. Erre jönne jól, ha nem a Jenkins feladat uralná a queue-t, hanem mondjuk a kubernetes, azaz, hogy ha a Kubernetes-ben lenne egy úgymond shared queue, ahol a tesztek nevei és a Jenkins munkák kezdeti időpontjai hogy a sorrend különböző branch-ekből meghívásra is választ adva működjön (JobId nem lenne szerencsés ugye).
Ergo oké, hogy a LinkedBlockingQueue adott Jenkins-ben működik, csak hát a Jenkins feladatok egymás között kellene hogy ismerjék a Queue-t.
A "helmfile" nem megoldás;
Egy Kubernetes-ben létrehozott "locking megoldás" addig amíg egy adott feladat a queue-t lekérdezi hogy hány névtér került már létrehozásra (pl. ezzel ki lehetne szűrni hogy hány teszt fut épp) szintén elég gáz megoldás lenne több szempontból is.
Egyelőre lehet tekerni az erőforrásokon: megfelezem adott Jenkins feladat queue-ját és 2 párhuzamos feladatot engedek be Jenkins-el. Ez viszont nem igazából skálázható, nem is natív és ráadásul elég problémás ha egy adott teszt időben túl hosszú ideig fut és emiatt az adott queue üresen áll, miközben a többi pedig rá vár.
Ennél még a Jenkins node-ok is jobban teljesítenek, igaz, ott a queue-t a Jenkins maga uralja, ahol az adott Node-ok Executor-okkal oldják ezt meg.
Arra is gondoltam, hogy a Kubernetes-t nem "Cloud"-ként állítom be, hanem Node-ként és "hadd SSH-zzon bele aztán futtasson PodMan-el egy konténert", de ezt "talán inkább hagyjuk".
Rátaláltam a Kueue-ra, ezzel kapcsolatban az jutott eszembe, hogy lehet hogy egy meta-helm-chart-ot kellene generálnom ami függ az adott csoport tagjaitól, ergo ha a termék adott konfigurációja 5 chart-ot akar telepíteni, hozzak létre egy meta-helm-chart-ot amelyben a deployment-ek resource-ai listázva vannak és "egyként" adjam deployment-ként oda Kueue-nak.
Azt viszont látom hogy a kueue-t alapvetően "Job"-ra tervezték és nem helm chart-ra. Az is elég sajnálatos, hogy a Jenkins támogatása a Kubernetes pluginnal hírül sem olyan korrekt mint a Node-ok esetében.
Valakinek van erre ötlete?
- Tovább (Jenkins, Kubernetes kérdés)