شرکتها در مورد استفاده یا کنار گذاشتن Kubernetes دچار سردرگمی هستند. در حالی که برخی از شرکتها تصمیم گرفتند به طور کامل از آن دور شوند، بسیاری اکنون پس از آزمایش و آزمایش معماریهای یکپارچه، بارهای کاری خود را به Kubernetes باز میگردانند. متأسفانه، هر دو رویکرد نقاط ضعف خود را دارند و هیچ راه حل کامل واحدی وجود ندارد.
سال گذشته، شرکت لجستیک حمل و نقل اوبر تصمیم گرفت پلتفرم یادگیری ماشین خود را ارتقا دهد و بارهای کاری ML خود را به Kubernetes منتقل کند. و به طور معمول اوبر، نه تنها مهاجرت کرد، بلکه برخی از ابزارهای خود را نیز در این راه ساخت تا همه چیز به آرامی اجرا شود.
در یک وبلاگ اخیر، تیم فناوری اوبر این انتقال و انگیزه پشت آن را توضیح داد. خطوط لوله ML با حجم عظیمی از دادهها، به ویژه در طول آموزش مدل، سروکار دارند. اینها مشاغل پردازش دستهای هستند که به وظایف توزیعشده بزرگ تقسیم میشوند و همه در یک جریان به هم متصل میشوند.
تا اواسط سال 2023، آنها از یک دروازه شغلی داخلی به نام MADLJ برای اجرای مشاغل مبتنی بر Spark و Ray استفاده میکردند. در حالی که این تنظیمات کار را انجام میداد، اما با مجموعهای از سردردها همراه بود. مهندسان ML مجبور بودند مدیریت جزئی قرار دادن شغل را انجام دهند: انتخاب خوشهها، مناطق، SKUهای دقیق GPU. یک حرکت اشتباه به معنای صفهای طولانی، GPUهای بیکار، یا بدتر از آن - آزمایشهای متوقف شده بود.
بخشی از مشکل، وابستگی MADLJ به Peloton بود که روی Apache Mesos اجرا میشد. Mesos از مد افتاده است، بنابراین اوبر تصمیم گرفت زمان آن رسیده است که به Kubernetes، که اکنون استاندارد صنعت است، تغییر کند.
ابزارهایی مانند Spark و Ray از قبل از Kubernetes پشتیبانی میکنند، که این تصمیم را بسیار ساده میکند. اما اوبر همه چیز را دور نریخت. این شرکت برخی از ویژگیهای سفارشی Peloton (مانند استخرهای منابع و اشتراکگذاری الاستیک) را برای کار با Kubernetes تطبیق داد.
رابرت نیشیهارا، یکی از بنیانگذاران Anyscale، که Ray را ایجاد کرد، در مورد وبلاگ اوبر توضیح داد که Ray و Kubernetes چگونه با هم کار میکنند. او گفت: "هر کدام به تنهایی بخشی از تصویر را از دست میدهند. آنها با هم، یک پشته نرمافزاری برای هوش مصنوعی تشکیل میدهند که به هر دو مجموعه نیازها رسیدگی میکند."
آنچه اوبر میخواست بسازد
برای رفع این مشکل، اوبر یک لایه ارکستراسیون یکپارچه برای مشاغل ML ساخت. اکنون، مهندسان به سادگی نوع شغل (به عنوان مثال، Spark یا Ray) و نیازهای منابع (CPU/GPU، حافظه) را تعریف میکنند، و سیستم بقیه را انجام میدهد. یک زمانبندی هوشمند شغل، بارهای کاری را در چندین خوشه Kubernetes بر اساس در دسترس بودن منابع، مکان و هزینه در زمان واقعی مسیریابی میکند.
هسته اصلی این تنظیمات، مدیریت منابع فدرال است، که باعث میشود خوشههای محاسباتی اوبر مانند یک استخر منابع واحد به نظر برسند.
اولین مورد، لایه برنامه کاربردی است که خطوط لوله ML در آن قرار دارند. آنها با APIها تعامل دارند و درخواستهای شغلی را در یک فرمت اعلانی تمیز و زیبا ارسال میکنند. سپس صفحه کنترل جهانی قرار دارد که مغز عملیات است. این روی Kubernetes اجرا میشود و دارای یک سرور API سفارشی و کنترلرها برای رسیدگی به مشاغل است.
در نهایت، صفحات کنترل محلی وجود دارند، که خوشههای Kubernetes فردی هستند که در واقع مشاغل را اجرا میکنند.
در صفحه کنترل جهانی، اوبر منابع سفارشی Kubernetes را برای نمایش مشاغل معرفی کرد. همچنین یک کنترلر شغلی ساخت که این درخواستهای شغلی را تماشا میکند و تشخیص میدهد کجا آنها را اجرا کند. هنگامی که یک خوشه مناسب پیدا کرد، شغل را راهاندازی میکند، آن را تا پایان کار نظارت میکند و سپس همه چیز را تمیز میکند.
این به طور خودکار رازها، چرخه عمر، بازیابی خرابی و مسیریابی خاص تیم را از طریق سیستم مالکیت داخلی اوبر (uOwn) مدیریت میکند. این نه تنها تجربه توسعهدهنده را بهبود میبخشد، بلکه کارایی زیرساخت را در مقیاس افزایش میدهد.
آنچه این را به ویژه قدرتمند میکند این است که فقط مخصوص Ray نیست - این یک لایه انتزاعی است که میتواند برای هر نوع شغلی با مشخصات منابع اعلانی کار کند. بنابراین، چه در حال آزمایش مشاغل آموزشی کوچک باشید و چه در حال راهاندازی اجراهای توزیعشده گسترده در سراسر GPUها، این پلتفرم به طور شفاف هماهنگی و مقیاسبندی را انجام میدهد.
اگر در حال اجرای ML توزیع شده هستید و میخواهید از آشفتگی زیرساخت جلوگیری کنید، پشته Ray-on-Kubernetes اوبر یک طرح اولیه ارزشمند برای مطالعه است.
وقتی صحبت از شرکتهای خودروسازی میشود، بسیاری از آنها از Kubernetes برای مدیریت و توسعه نرمافزار خود استفاده میکنند. این شامل شرکتهایی مانند تسلا، فورد، مرسدس بنز، فولکس واگن، DENSO و شرکتهای خودران مانند Waymo، Aurora و Zoox میشود. اما این داستان برای زمان دیگری است.
Ray مورد اعتماد بسیاری است
Ray توسط Anyscale قهرمان واقعی در اینجا است. Ray توسط رهبران هوش مصنوعی مانند OpenAI، AWS، Cohere، Canva، Airbnb و Spotify مورد اعتماد است و یک موتور محاسباتی منبع باز است که برای سادهسازی محاسبات توزیعشده برای برنامههای هوش مصنوعی و پایتون طراحی شده است. این به توسعهدهندگان اجازه میدهد تا بدون نیاز به دانش عمیق در مورد سیستمهای توزیعشده، بارهای کاری را بدون زحمت مقیاسبندی کنند.
گرگ براکمن، یکی از بنیانگذاران OpenAI، در یک پست وبلاگ گفت: "در OpenAI، Ray به ما اجازه میدهد تا بسیار سریعتر از قبل در مقیاس تکرار کنیم. ما از Ray برای آموزش بزرگترین مدلهای خود، از جمله ChatGPT، استفاده میکنیم."
همانطور که مدلهای هوش مصنوعی از نظر اندازه و پیچیدگی رشد میکنند، توسعهدهندگان باید از تنظیمات تک ماشینی به محیطهای چند گرهای و شتابدهنده GPU منتقل شوند. Ray این شکاف را با یک چارچوب متحد که پیچیدگی محاسبات توزیعشده را انتزاع میکند، پر میکند.
مطمئناً، این مشکلات خود را دارد، اما اوبر موفق میشود آنها را با Kubernetes مدیریت کند.