A Daytona szerint az AI-ügynökök futtatásához több kell a Kubernetesnél

Más működési modellre készítették a Kubernetes-t

A Daytona október 29-én közzétett elemzése szerint a Kubernetes elsősorban olyan konténeres munkaterhelésekhez illeszkedik, amelyeknél az egyes példányok felcserélhetők. Ilyenek a hosszú ideig futó mikroszolgáltatások és a vízszintesen skálázott API-k. Ezeknél a számítási kapacitás és az állapot általában elválik egymástól, a telepítési folyamat pedig kiszámítható.

Az AI-ügynökök működése ettől eltér. Minden feladat saját környezetet, fájlrendszert és életciklust igényelhet, miközben az ügynökök kódot futtatnak, eszközöket hívnak meg, fájlokat módosítanak, majd a köztes eredmények alapján újabb lépéseket választanak. A Daytona szerint a környezetnek közben biztonságosan meg kell őriznie a korábbi lépések során létrejött kontextust is.

A vállalat álláspontja szerint a Kubernetes használatakor a csapatok ezért további vezérlőket, tárolási rétegeket és külső eszközöket kezdenek összeépíteni. Ez idővel nehezen karbantartható függőséghálózathoz vezethet, miközben a mérnökök az ügynökök fejlesztése helyett az infrastruktúra összekapcsolásával és hibakeresésével foglalkoznak.

A skálázás több ponton is nehézséget okoz

A Daytona négy fő problémát emel ki. Több ezer párhuzamos feladatnál a csapatoknak maguknak kell megoldaniuk a környezetek létrehozását, nyomon követését és törlését. A hibás életciklus-kezelés elárvult sandboxokat hagyhat maga után, amelyek más munkaterhelésektől foglalják el a tárhelyet.

Gondot okoz a rendelkezésre bocsátás sebessége is. Egy kódoló ügynöknek a feladat megkezdése előtt meg kell várnia a kapacitás létrehozását, a pod ütemezését, a lemezkép letöltését és a megfelelő konfigurációk betöltését. Az egyes lépések külön-külön rövidnek tűnhetnek, együtt azonban késleltethetik a feladatindítást.

A biztonságos elkülönítés további többlettel járhat. A Daytona példaként a gVisort és a Kata Containerst, valamint a Ciliumhoz vagy Calicóhoz hasonló CNI-bővítményeket említi. A vállalat szerint a Kata Containers növeli az alap erőforrás-felhasználást, a megosztott kernelt használó gVisor pedig lassíthatja a bemeneti és kimeneti műveleteket.

Az erőforrásigény ráadásul kiszámíthatatlan. A rendszer órákig tétlen lehet, majd egyszerre több száz vagy több ezer környezetre lehet szükség. A Daytona példája szerint 500 előkészített sandbox 500 vCPU és 1 TB memória lefoglalását jelentheti még az ügynökök munkájának megkezdése előtt. Kisebb tartalék esetén viszont a feladatok sorba állhatnak, amíg új podok és csomópontok indulnak.

A Daytona saját futtatási réteget kínál

A Daytona olyan, teljesen menedzselt sandboxplatformként mutatja be megoldását, amelyet ügynöki munkaterhelések nagy léptékű futtatására szántak. A vállalat szerint a futtatási réteg közvetlenül a csapatok saját klasztereire is telepíthető, miközben a Kubernetes továbbra is vezérlősíkként működik.

A Daytona deklaratív építőjével definiálhatók a környezetek, a szervező komponens pedig önálló, egy példányhoz tartozó sandboxokat kezel felhőinfrastruktúrán, virtuális gépeken és bare metal szervereken. A vállalat szerint így minden sandbox saját erőforrásokkal és életciklussal rendelkezik, az alapul szolgáló infrastruktúrától függetlenül.

A Daytona állítása szerint a Trajectory havonta több mint 15 órát takarít meg azzal, hogy nem kell különböző Kubernetesre épülő megoldásokat összekapcsolnia. A cég emellett előmelegített pillanatképsablonokból, igény szerint hoz létre sandboxokat, és közlése szerint az új Firecracker microVM-ek kiépítése kevesebb mint 90 ezredmásodpercet vesz igénybe.

Az üzenet a felhasználók számára az, hogy a Kubernetes továbbra is része lehet az ügynökök infrastruktúrájának, de az ügynökök sajátos végrehajtási igényeihez külön futtatási rétegre lehet szükség. A Daytona ezt a réteget saját platformjával kívánja biztosítani, a Kubernetes lecserélése nélkül.