Kubernetes job triggelese

Linux-haladó

Sziasztok,

meg tudna valaki magyarazni, mi alapjan futnak le a kubernetes job-ok?

Van egy konyvtaram python szkriptekkel.

Hogyan lehet barmelyik inditasakor kubernetes job-ot letrehozni es lefuttatni az eredmenyt pedig egy logfile-ba irni

(mountolt pvc - ami tartalma pod delete eseten megmarad.)

Koszonom a segitseget.

Ardi

  • 464 megtekintés

( vl v | 2023. 05. 24., sze – 12:01 )

Szerkesztve: 2023. 05. 24., sze – 12:06

A Job objektum létrehozáskor fut le. A CronJob objektum pedig a cron speckó szerinti időpontokban Job objektumokat hoz létre.

Job objektumot a K8s API-n keresztül lehet létrehozni, pl.:

- kubectl paranccsal CLI-ből
- direktben a REST API meghívásával (curl, Ansible-ben kubernetes.core.k8s module, Goban kubernetes/client-go, Pythonban kubernetes module)
- ha van valami dashboardod (pl. kubernetes dashboard), akkor ott kattintva

hmm, a felsoroltakbol az elso 2 ok.

En inkabb vmi olyasmire gondoltam, hogy python script inditasakor (mondjuk webes feluletes gomb inditasa s barmilyen mas szkript mint parameter megadasa) letrehozodik a Job objektum es vegrehajtodik az uj szkript.

Valami ilyesmire gondoltam:

https://stefanopassador.medium.com/launch-kubernetes-job-on-demand-with…

Nincs erre valami egyszerubb megoldas?

ardi

Nincs erre valami egyszerubb megoldas?

Hát úgy érted, hogy a feladat tudna-e kisebb lenni? Nyilván nem. Be lehet csomagolni az egészet egy libbe, és akkor el van hide-olva előled a komplexitás. Mellesleg, egy nagyon fontos elemet nem érint a megvalósítás: megvárni a Job lefutását és a kimenetét leszedni. Illetve kezelni a hibákat (mondjuk valamiért a Job nem indul el), és értelmesen visszajelezni.

Hat en csinalnek egy flask API-t a k9s-en belul ami figyeli a kereseket. Amikor legut egy python scripted a vegen lesz egy request erre az API-ra. A pod-ban levo API server a megfelelo RBAC jogosultsagokkal rendelkezve aztan k9s API hivassal letrehoz egy job-ot. A log meg megy fluentdbe, logstashbe, filebeat-be akarmibe. De amugy meg ott lesz a node-on a containerlogban. 

Én is ezt csinálnám, de azt az API-t akkor valahogyan védeni kell. A job létrehozás meg feltételezi, hogy van jogosultságod piszkálni a rendszert.

Egy elmeháborodott script futtató script így is kinézhet:

  • Létrehoz egy ConfigMapet, benne az összes scripttel.
  • Létrehoz egy Jobot, ami mountolja a ConfigMap-et, egy mezei python image-et használ és a benne lévő parancs az, hogy futtassa a scriptet.
  • Lekérdezi a Job Podját, pl. kubectl describe job vagy kubectl get po | grep
  • Ha véletlenül még fut a job, akkor kubectl logs <pod> --follow

Aztán keresek egy gépet, ami nincs lezárva, és a tulajdonosának a nevében rakom fel a közös repóba a scriptet, mert le akarom tagadni 😀

( kris | 2023. 05. 24., sze – 20:17 )

Szerintem a gap talán ott van, hogy ez a mondat, hogy szkriptjeim vannak egy könyvtárban, k8s-ben értelmezhetetlen. k8s-ben container imagejeid, podjaid, persistent volume claimjeid, meg configmapjaid vannak.

Tehát először kell egy konténert építened ami tud python-t futtatni (vannak függőségek? -- be kell őket építeni), aztán valahogy a szkripteket bele kell varázsolni vagy a konténer image-be (build time) vagy a job által triggrelt pod-ba (configmap / PVC volume mount, run time).

A kimenetet lekérdezni az api-n keresztül tudod (amíg fut a pod) vagy valamilyen megoldással el kell mentened... fluent-bit/fluentd/valami sidecar, vagy a PVC-re lemented.

Az a gondolat, hogy a szkript önmagát k8s jobként lefutassa ... az nem tudom mire jó, nem látom a use case-t és macerás is, keveredik a control plane a runtime-mal, veszélyes kavarás.

Van a python-nak egyébként jó k8s lib-je azzal könnyen tudsz jobokat csinálni.