Fókuszban a WG Eszközmenedzsment

A mesterséges intelligencia, a perem- és telekommunikációs munkaterhek Kubernetes-en belüli növekvő népszerűsége új követelményeket támasztott a hardverkezelés terén. Most már a CPU-időn és a memória-elosztásokon túli hardverspecifikációkra van szükségünk. Ez magában foglalja a GPU-k, TPU-k, hálózati interfészek és egyéb hardverek allokálását, néha a pod indítása után, és alkalmanként időmegosztáson keresztül. E speciális hardver hatékony kezelése a Device Management Working Group küldetése. Alapvető projektjük, a Dinamikus Erőforrás-Allokáció (DRA) nemrégiben elérte a GA státuszt, ami alapvető változást jelent abban, ahogyan a projekt a hardverintenzív munkaterheket kezeli nagy léptékben. Ebben a reflektorfényben Kevin Klues, Patrick Ohly és John Belamaric, a munkacsoport elnökei beszélgetnek a régi eszközmodell korlátairól, a programozás nehézségeiről és arról, hogyan építenek egy programozhatóbb, hardver-tudatosabb jövőt a Kubernetes számára. Bevezetés a hardverkezelésbe Natalie Fisher: Bemutatnád magadat, a szerepedet, és hogyan kerültél kapcsolatba a Device Management Working Group-pal? Kevin Klues: A nevem Kevin Klues. A NVIDIA-nál vagyok kiváló mérnök. A hardverkezelő munkacsoport társelnöke vagyok a Kubecon EU 2024 óta, és részt veszek a DRA-val (a munkacsoport fő szállítmánya) is mióta 2019/2020-ban elkezdtük. 2019 óta a kubelet karbantartója vagyok, a hardvermanager, a CPU manager és a topology manager alkotórészeire összpontosítva. Azok a kihívások, amelyeket a külső gyorsítók (pl. GPU-k) munkaterhekhez való használata során tapasztaltunk, indították el a DRA-ra való munkát is. Patrick Ohly: Főmérnök vagyok az Intel-nél. A Kubernetes-en belül a SIG Testing és a SIG Instrumentation technikai vezetője vagyok, valamint a Device Management WG társelnöke. A WG Strukturált Naplózásának társelnöke voltam, és tagja a Vezető Bizottságnak. Néhány korai hozzájárulásom a Kubernetes-hez az ephemerális CSI kötetek és a tárolókapacitás nyomon követése volt, tehát volt némi tapasztalatom az API tervezésében, megvalósításában és ütemezésében. Tudtuk, hogy egy újabb API bevezetése a gyorsítók számára nehéz feladat lesz. Kissé bolondosan elfogadtam ezt a kihívást 2020-ban, megírtam a kezdeti DRA KEP-et (most „klasszikus DRA”-ként ismert) és a legtöbb megvalósítást, majd újra kezdtem egy második KEP-pel a mai „strukturált paraméterek DRA”-hoz. Kezdetben nehéz volt meggyőzni a karbantartókat, hogy ez a munka szükséges. Csak 2023 körül növekedett a DRA iránti érdeklődés, ami a munkacsoport megalakulásához vezetett. John Belamaric: Senior Staff SWE vagyok a Google-nál, és a WG Device Management harmadik társelnöke, szintén a megalakulás óta. 2019 óta a SIG Architecture társelnöke is vagyok. Ahogy Patrick említette, 2023 végén valóban megugrott a DRA iránti érdeklődés. A kezdeti megvalósítás a vízszintes skálázást rendkívül nehézzé tette, ezért volt némi aggodalom a közösségben, hogy előre ugrunk a bétába. Megpróbáltam segíteni a problémák kezelésében, és a hárman, Tim Hockin mellett, keményen dolgoztunk azon, hogy konszenzusra jussunk egy új terv körül. Az együttműködés elősegítése érdekében a munkacsoportot a 2024-es KubeCon párizsi megbeszélése után alakítottuk meg. A probléma és a megoldás A munkacsoport egy alapvető újragondolásból alakult ki, hogy a Kubernetes hogyan lép interakcióba a speciális hardverrel. Ennek az evolúciónak a középpontjában a Dinamikus Erőforrás-Allokáció (DRA) áll. Ahelyett, hogy az eszközöket egyszerű egész számokként kezelnénk, a DRA egy strukturált keretet biztosít, amely négy különböző szakaszra bontja a hardverkezelést: Modellezés: A gyártók a ResourceSlice API-t használják, hogy hirdessék hardverük finom részletekkel és kapacitással rendelkeznek. Kérés: A felhasználók a ResourceClaim API-n keresztül határozzák meg a konkrét hardverigényeiket – például GPU memória vagy interconnect igények. Ütemezés: A Kubernetes ütemező ezeket az API-kat használja, hogy intelligensen párosítsa a munkaterhelési követelményeket a rendelkezésre álló hardverrel. Aktuálás: Miután egy megfeleltetést készítettek, a rendszer kezeli a "kézfogót", amely előkészíti és biztosítja az eszközt a Pod használatára. NF: A nem ismerők számára, mi a Device Management Working Group, és milyen problémákat próbál megoldani? KK: A Device Management Working Group célja, hogy lehetővé tegye az egyszerű és hatékony konfigurálást, megosztást és gyorsítók, valamint más speciális hardverek allokálását a Kubernetes munkaterheknél. Gondolj GPU-kra, TPU-kra, FPGA-kra és hasonló eszközökre, amelyek nem illeszkednek a Kubernetes hagyományos erőforrásmodelljébe. Az általunk megoldani kívánt probléma az, hogy a régi Device Plugin API (amely a Kubernetes-ben a hardvergyorsítók kifejezésére szolgál) alapvetően korlátozott. Az eszközöket átlátszó egész számokként kezeli: kérheted, hogy "2 GPU-t" szeretnél, de nem mondhatsz semmi jelentőséget arról, milyen GPU-kra van szükséged, hogyan kellene őket összekapcsolni, hogy megoszthatók-e, vagy hogyan kellene őket felosztani. Ez rendben volt egyszerű esetekben, de a modern AI/ML munkaterhek semmiképpen sem egyszerűek. Több csomóponton terjednek el, specifikus interconnect topológiákat igényelnek, és egyre inkább szükséges, hogy a hardvert dinamikusan megosszák vagy felosszák. A munkacsoport fő szállítmánya a Dinamikus Erőforrás-Allokáció (DRA), egy új keretrendszer, amely a merev eszközplugin modellt egy rugalmas, deklaratív API-val helyettesíti. A DRA lehetővé teszi, hogy a munkaterhek leírják hardverigényeiket (pl. GPU típus, memória kapacitás, interconnect topológia, kívánt felosztás), és a meghajtók részletesen nyilvántarthatják az eszközök attribútumait, amelyekre az ütemező reagálhat. A DRA a Kubernetes 1.34-ben jutott GA-ba, és a körülötte lévő ökoszisztéma (pl. meghajtók, eszközök és új API bővítések) gyorsan növekszik. PO: Ahogy Kevin mondta, a munkacsoport az DRA fejlesztésére tett lépések köré alakult. A kezdeti munkát csupán néhány ember aktív részvételével végeztük, és talán csak ilyen keretek között lehetett sikeresen végrehajtani. De mivel annyi különféle területet érintett a Kubernetes-en belül, szükségünk volt egy helyre, ahol erről beszélhettünk, és bevonhattuk a Kubernetes karbantartóinak, eszközgyártóknak és, kisebb mértékben, a végfelhasználóknak a szélesebb közösségét. A munkacsoport egy ilyen helyet biztosít, rendszeres online találkozókkal (egy időpont az amerikai/EMEA, egy az EMEA/Ázsia számára) és a KubeCon-nál. JB: A DRA az első probléma, amellyel a WG foglalkozott. Az eszközök kiválasztására, allokálására és konfigurálására összpontosít. A problémát négy részre bontottuk: hogyan modellezheti a gyártó az eszközt és hirdetheti kapacitását, hogyan kérheti a felhasználó azt, hogyan ütemezhetjük a kérést a hirdetett kapacitásra, és hogyan érvényesíthetjük az eredményt (azaz hogyan készítsük el az eszközt, hogy készen álljon és elérhető legyen a Pod számára). Ami alapvető az általunk alkalmazott megközelítésben, hogy figyelembe vesszük a hardver hihetetlen sokszínűségét és a hardveripar gyors ütemű változását. Tudtuk, hogy nem tudunk lépést tartani a változásokkal, ha a Kubernetes API-knak minden típusú hardver esetében változniuk kell. Ehelyett általános megközelítést hoztunk létre, amely a Kubernetes számára fontos hardver aspektusokra összpontosít. Amit eddig tettünk, az a hardverek ütemezésére és konfigurációjára vonatkozó aspektusokra összpontosított. Kialakítottunk egy eszközmodellező API-t (ResourceSlice API), amelyet a gyártók használnak az eszközeik ütemezési jellemzőinek modellezésére, és lehetővé tesszük a felhasználók számára, hogy tetszőleges konfigurációkat küldjenek az eszközökhöz. Ezzel a Kubernetes „programozhatóvá” válik, hogy megértse ezeket az eszközök jellemzőit, anélkül, hogy módosítani kellene. De a DRA, ahogy most van, nagyon a ütemezésre összpontosít. Más eszközkezelési aspektusok is a munkacsoport hatáskörébe tartoznak. Különösen az eszközhibák kimutatására és csökkentésére is fókuszálunk, és egyre jobb támogatást próbálunk építeni a Kubernetes-be. Ahogy Kevin is utalt rá, az eszközöket gyakran csoportokban allokálják és használják, nem pedig egyesével. Az, hogy a megfelelő eszközöket válasszák egy csoportban, attól függ, hogyan kapcsolódnak egymáshoz; például a NVIDIA GPU-k egy bármire-bármire gyártási elrendezésben lehetnek egy NVLINK tartományon belül, míg a TPU-k 3D toroid kapcsolaton rendelkezhetnek. Ez érinti az eszközök „kiválasztását, allokálását és konfigurálását”, és még sok munkánk van, hogy ezeket az esettanulmányokat kezelhessük. Egy cross-SIG törekvés Mivel az eszközkezelés érinti az ütemezést, a csomópont működését, az automatikus skálázást, a hálózatokat és az API tervet, a munka természetesen több SIG-re is kiterjed a Kubernetes projekt keretein belül. NF: Hogyan működik a együttműködés ezek között a SIG-ek között a gyakorlatban, és miért is van szükség rá? KK: Az eszközkezelés szinte az összes Kubernetes réteghez kapcsolódik, ezért a munkacsoportot az elejétől kezdve cross-SIG törekvésként alakították meg. Öt érintett SIG-ünk van: sig-node, sig-scheduling, sig-autoscaling, sig-network és sig-architecture. A gyakorlatban a munkacsoport koordinációs rétegként működik. Nem közvetlenül birtokolunk kódot; helyette a szállítmányaink KEP-ként és a megfelelő SIG-ek által megvalósítva állnak rendelkezésre. Amit biztosítunk, az egy egységes fórum, ahol a schedulert, a kubeletet, az autoscalert és a hálózati réteget építő emberek együtt gondolkodhatnak, nem pedig izoláltan. Miért szükséges ez? Vegyünk egy egyszerű példát: egy felhasználó egy olyan GPU-készletet kér, amelynek kommunikálnia kell NVLink-en keresztül. Ez a követelmény magában foglalja az ütemezőt (ahol a podok a megfelelő csomópontokra kerülnek), a kubelet-et (az eszközök konfigurálása és azok exponálása a tároló számára), és potenciálisan az automatikus skálázást (a megfelelő csomóponttípus biztosítása, ha az nem létezik). Ha ez a három csoport függetlenül tervezik, akkor ellentmondó absztrakciók, megismételt logika és integrációs hibák keletkeznek, amelyek csak a termelésben bukkannak fel. A munkacsoport biztosítja, hogy egyetlen koherens API és adatmódus áramoljon ezen összes komponens között. A cross-SIG modell azt is jelenti, hogy a tervezési döntéseket több szempontból is felülvizsgálják. Valaki a sig-scheduling csoportból észlelheti az ütemező bonyolultságát, amit egy sig-node hozzájáruló esetleg figyelmen kívül hagyna, és fordítva. Ez kissé lelassítja az egyes döntéseket, de sokkal robusztusabb eredményeket hoz. Jelenlegi fókuszterületek A DRA most, hogy általánosan elérhető, a munkacsoport fókusza kiterjedt a fejlettebb ütemezési modellek, a közös szemantika, az operatív láthatóság és az egyre bonyolultabb hardver topológiák támogatására. NF: Melyek a legfontosabb kezdeményezések vagy szállítmányok, amelyekre a munkacsoport jelenleg összpontosít? KK: Fenntartunk egy projekt táblát a Kubernetes Project Board-on, valós idejű nyomon követéssel az kezdeményezéseink és azok előrehaladása alapján. PO: A DRA alapjainak terjedelme és funkciókészlete szándékosan korlátozott volt, hogy ésszerű időn belül elérhesse a GA-t. További KEP-ek új funkciókat adnak hozzá, saját ütemezésük szerint. Ezek durván három kategóriába sorolhatóak: Az DRA kifejezőképességének kiterjesztése, hogy támogassa a bonyolultabb eszközöket és ütemezési forgatókönyveket. Második napos műveletek támogatása, mint például az egészségmonitorozás. A többcsomópontú támogatás javítása, elsősorban a munkaterhekre figyelmes ütemezéssel. A projekt tábla mellett egy táblázatot is fenntartunk, amely összefoglalja az összes KEP-t, amely jelenleg aktív. Ez a státusz a 1.36-ra; több is valószínű, hogy a 1.37-re hozzáadják: KEP Leírás Kiadás 1.32 1.33 1.34 1.35 1.36 4381 DRA: Strukturált Paraméterek Béta Béta Stabil 5004 DRA: Kiterjesztett Erőforrás-Kérelmek DRA-n keresztül Alpha Alpha Béta 4817 DRA: Erőforrás-Igény Státusza Alpha Béta Béta Béta Béta 5018 DRA: Névterületi Kontrolált Admin Hozzáférés Alpha Béta Béta Stabil 5055 DRA: Eszköz Fajták és Toleranciák Alpha Alpha Alpha Béta 4816 DRA: Prioritizált Alternatívák az Eszköz Kérésekben Alpha Béta Béta Stabil 5075 DRA: Felhasználható Kapacitás Alpha Alpha Béta 4815 DRA: Particionálható Eszközök Alpha Alpha Alpha Béta 5304 DRA: Attribútumok Lefelé API Alpha 5729 DRA: ResourceClaim Támogatás a Munkaterhekkel Alpha 4680 Erőforrás Egészségügyi Státusz a Pod Státuszában Alpha Alpha Alpha Alpha Béta 5517 DRA: Natív Erőforrás-Kérelmek Alpha 5677 DRA: Erőforrás Elérhetőségi Láthatóság Alpha 5007 DRA: Eszközkötés Feltételei Alpha Alpha Béta 5491 DRA: Lista Típusok az Attribútumokhoz Alpha NF: Az egyik alapvető kihívás az eszközök hatékony kihasználása és megosztása. Milyen előrelépés történt ezen a területen? JB: Jó kérdés. Az egyik módja, hogy ezt úgy gondoljuk, hogy mit teszünk a két alapvető API-ban: ResourceClaim és ResourceSlice. A ResourceClaim API az, amellyel a felhasználó eszközöket kér. Néhány funkciót építettünk be, amelyek lehetővé teszik a felhasználó számára, hogy rugalmasabb legyen a kéréseiben. Például ahelyett, hogy egy adott GPU modellt kérne, kérheti, hogy „csak egy GPU, amely legalább egy bizonyos mennyiségű memóriával rendelkezik.” Vagy kérheti alternatívák listáját: "Szeretnék egy A100 (80GB) GPU-t, de ha az nincs, akkor elfogadom 2 A100 (40 GB) GPU-t." Ez lehetőséget biztosít az ütemezőnek a kérés kielégítésére, ami jobb beszerezhetőséget és kihasználtságot eredményezhet a korábban ki nem választott hardverek esetében. A ResourceClaim API lehetővé teszi a felhasználók számára az eszközök kifejezett megosztását. Több tárolót (ugyanazon vagy különböző Podokban) a ResourceClaim felé irányíthat; ez lehetővé teszi, hogy a folyamatban lévő igénylés által allokált eszközöket mindegyik tárolóban használják, ha az eszköz ezt támogatja. A ResourceSlice API az, ahogy a gyártók modellezik és hirdetik eszközeiket. Itt valósítjuk meg más megosztási modellek támogatását is. Például van egy módunk az „átfedő partíciók” ábrázolására, lehetővé téve az ütemező számára, hogy dinamikusan válasszon egy MIG-partíciót, és automatikusan elérhetetlenné tegye az összes átfedő MIG-partíciót. Ez jól működik egy olyan kérés mellett, mint „adj nekem bármilyen GPU-t, amely legalább 20 GB memóriával rendelkezik” - az ütemező ezt meg tudja valósítani MIG-gal vagy egy valódi GPU-val. Néhány funkciót mindkettőben változásokat igényel. Van egy másik megosztási módszerünk, amelyet „felhasználható kapacitásnak” nevezünk. Az explicit megosztás esetében, amit fentebb említettem, a felhasználónak ugyanazon ResourceClaim-re kell mutatnia a tárolóiakat; van egy ResourceClaim, amelyet több tároló és Pod oszt meg. A felhasználható kapacitás esetén az eszközmegosztás inkább úgy működik, mint ahogyan a Pod-ok egy Node-on osztoznak. A felhasználó létrehoz egy ResourceClaim-et, amely bizonyos mennyiségű erőforrást kér, például „Szükségem van egy NIC-re, amely 2Gbps sávszélességgel rendelkezik.” Az ütemező tudja, hogy van egy NIC, amely 40Gbps sávszélességgel rendelkezik, és így 2Gbps-t allokál ebből a 40Gbps-ből, és ezt a ResourceClaim-hez adja. Ebben az esetben minden Pod-nak megvan a saját ResourceClaim-je, de az alapul szolgáló eszköz megosztott ezek között az igények között. A helyszíni DRA meghajtónak kell megfelelően beállítania az eszközt ehhez a fajta megosztáshoz (a NIC esetében valószínűleg egy alsó interfész létrehozásával). Ezt „platform által közvetített megosztásnak” nevezzük, hogy megkülönböztessük az explicit "felhasználó által közvetített megosztástól". Valódi hatás Bár a munka nagyrészt mélyen technikai, a mögöttes cél gyakorlati: lehetővé tenni a Kubernetes számára, hogy jobban támogassa a valós világ AI/ML és hardverintenzív munkaterheket nagy léptékben. NF: Melyek a legnagyobb kihívások, amelyekkel a felhasználók szembesülnek ma hardverintenzív munkaterhek (mint az AI/ML) futtatásakor Kubernetes alatt? PO: Az ilyen munkaterhek számos szempontból eltérnek a hagyományos konténer munkaterhektől: több, egymással kommunikáló podból állhatnak, amelyeknek együttesen kell futniuk („csoportos ütemezés”). Gyakran hosszú lejáratúak és költségesek az inicializálás során, és teljesítményük érzékeny arra, hogy hol futnak (topológia egy node-on belül és interconnectek több pod között). A Kubernetes ütemezője hagyományosan nem támogatta ezeket jól, mivel egy podot ütemez egy időben, és nem tud a csomóponton belüli topológiáról. Számos külső ütemező próbálja kitölteni ezt a hiányt, ami gyakran nem ideális, különösen, ha a Kubernetes ütemező más podokat ütemez a klaszterbe. NF: Hogyan gondolkodjanak a platform mérnökök az eszközkezelésről a Kubernetes platformok tervezésekor? JB: Még mindig tanulunk ebben, de a DRA egyik ötlete egy „igény alapú” specifikációkhoz való elmozdulás elősegítése. Ez csökkentheti a kapcsolódást a végfelhasználók, akik írják a munkaterhelés specifikációját, és a klaszteradminisztrátorok, akik beállítják a klasztereket. Ahelyett, hogy megegyeznének a címkézési konvenciókról és megkövetelnék, hogy a felhasználók megértsék a klaszter topológiáját, a felhasználók meghatározhatják, hogy mire van szükségük a munkaterhelésükhöz, és az ütemező kitalálja, hogyan lehet azt kielégíteni. Ha ezt sikerül megvalósítani, az még a bonyolult munkaterheket is hordozhatóbbá teheti a klaszterek között. Kihívások és kompromisszumok Mint sok területen a Kubernetes-ben, a rugalmasság és a kifejeződő képesség növelése újabb bonyolultsági szinteket vezet be, különösen az ütemezés és az optimalizálás körül. NF: Melyek a legsúlyosabb technikai kihívások, amelyekkel a munkacsoport jelenleg foglalkozik? PO: Van egy belső konfliktus a rugalmasság és az ütemezési bonyolultság között. A jelenlegi megvalósítás célja, hogy találjunk valamilyen megoldást, amely kielégíti a kért erőforrásokat, de nem feltétlenül a legjobbat, ami „legjobb”-nak jelentheti, ami szintén nem mindig világos. A másik nagy kihívás, hogy a csomópont által allokálható erőforrásokat (RAM, CPU) eszközökként exponáljuk további metaadatokkal; ez szükséges a munkaterhek ütemezésének finomhangolásához, amelyeknek tökéletesen illeszkedniük kell egy node–on belül az optimális teljesítmény érdekében. JB: Patrick listája jó. A bonyolult eszközmodellezés nehéz, és ügyelni kell arra, hogy a megfelelő szemantikai tulajdonságokat építsük be, hogy ezek sok különböző hardverre vonatkozzanak. Ezen kívül az ütemezés általában nagyon bonyolult, és NP-nehéz probléma. Mindezen metaadatok és flexibilidadek, amelyeket a DRA hozzáad, több lehetőséget ad az ütemezőnek, aminek vannak előnyei és hátrányai. Több lehetőség hasznos, ha a választásaid korlátozottak, mivel lehetővé teszi, hogy olyat ütemezz, amit egyébként nem tudnál. De azt is jelenti, hogy még nehezebb optimális megoldást találni, amikor sok lehetőség van a megadott klaszterben. A DRA eddig jól működik a közös felhasználási esetekhez, de sok munkánk van még az ütemezési megoldás optimalizálásának javítására, és annak biztosítására, hogy a választás teljesítménye megfelelő legyen. Jövőbe tekintve A kihívások ellenére a munkacsoport különböző hozzájárulói izgatottak maradtak az innováció ütemével és a körülöttük formálódó közösség növekedésével az eszközkezelés terén a Kubernetes-ben. NF: Jövőbeli kilátásaidban mivel izgatnak a legjobban az eszközkezelés fejlődése a Kubernetes-ben? KK: A NVIDIA nemrégiben adományozta a DRA meghajtót a GPU-khoz a Kubernetes projektnek. Személy szerint izgatott vagyok amiatt, hogy több közösségi tag elkezd hozzájárulni a projekthez és formálni annak jövőbeli irányvonalát. PO: Számomra elsősorban az új hozzájárulók számáról és arról szól, hogy több ember lép fel, hogy segítsen. Ez új kihívásokat jelent a javaslatok áttekintése és a fejlesztők támogatása terén, hogy azokat megvalósítsák és egyesítsék. Jó látni mások sikerét, és kedvező előjelei a jövőnek, hogy egyre több ember ismeri a témát. JB: Sok dolog miatt izgatott vagyok. A közösség valóban növekedett, és számos érdekes fejlesztést dolgoznak ki, amelyek lehetővé teszik a bonyolultabb eszközök modellezését és a többcsomópontos eszközök jobb modellezését. Nagyon izgatott vagyok, hogy milyen kreatív módon használják majd az emberek ezeket az API-kat. Ezeket elsősorban arra tervezték, hogy a "hardverekre" összpontosítsanak, de úgy, mint ahogy „minden fájl” a Unix/Linux rendszeren, az API-k maguk is elég rugalmasak abban, hogy mit modelleznek. Valóban egy programozhatóbb ütemezőt építenek ki, amelynek érdekes alkalmazásai lehetnek. Például nemrégiben prototípusként használtam a DRA-t, hogy a podokat olyan node-okhoz ütemezzem, ahol egy nagy AI modell már helyben van tárolva. Igazán rugalmas, és nagy bizalmam van a közösség innovációjában, ezért úgy vélem, számos váratlan megoldást fogunk látni az ökoszisztémában. Bekapcsolódás NF: Hogyan tudnak a hozzájárulók részt venni a Device Management Working Group munkájában? KK: A legegyszerűbb első lépés, ha csatlakozik levelezőlistánkhoz a wg-device-management@kubernetes.io címen. A feliratkozás automatikusan naptármeghívókat ad a kéthetes találkozóinkhoz a naptárához. Két időpontunk van, hogy a különböző időzónákban is helyet biztosítsunk: Európa/Amerikák: Keddenként 8:30 AM PT (kéthetes) Ázsia/Európa: Szerdánként 9:00 AM CET (kéthetes) A találkozók jegyzőkönyvei, napirendjei és felvételei mind nyilvánosan hozzáférhetők (linkek elérhetők a Device Management oldalon). Megtapasztalhatja a folyamatban lévő munkát, mielőtt részt venne az első összeülésén. A Slack-en keressen minket a #wg-device-management csoportban a Kubernetes Slack munkaterében. Ez a legjobb hely gyors kérdésekkel kapcsolatban vagy hogy bemutatkozzon. A DRA Meghajtó NVIDIA GPU-khoz most közösségi projekt lett, és nagyszerű kezdet. Ez egy valós, termelési szintű megvalósítás, amelyet a tágabb közösség most együtt formál. Minden szinten - legyen szó az API tervezéséről, az ütemező belső működéséről, a meghajtó fejlesztéséről vagy a dokumentációról - várjuk a hozzájárulásokat. Gyere és mondj hellót. Összegzés Ahogy a Kubernetes fejlődik, hogy támogassa az AI/ML forradalmat és a nagy teljesítményű számítást, a WG Device Management keretein belül végzett munka egyre fontosabbá válik abban, ahogyan a modern munkaterheket ütemezik és működtetik nagy léptékben. A Dinamikus Erőforrás-Allokáció (DRA) elismerésétől a jövőbeli egészségmonitorozási és topológia-tudatos ütemezés nagy hullámaiba, ez a csoport lényegében újraírja a szoftver és a hardver közötti „kézfogót”. Ha Ön is érdekelt a hardver-tudatos orchestrálás jövőjének formálásában, most van az ideális idő, hogy bekapcsolódjon. Legyen szó az API finomításáról, a meghajtók kiépítéséről vagy a dokumentáció javításáról, a munkacsoport szívesen várja a közösség különböző tapasztalatát és nézőpontjait.