به گزارش از وبسایت cncf، Kubernetes سالهاست که به تیمهای پلتفرم کمک کرده تا برنامههای کانتینری را با روشی یکپارچهتر استقرار دهند، مقیاسپذیر کنند و مدیریت کنند. حالا همین تیمها بیش از گذشته از آنها انتظار میرود که از AI هم پشتیبانی کنند. این تغییر عملاً آغاز شده است. بر اساس CNCF 2025 Annual Cloud Native Survey، 66٪ از سازمانهایی که مدلهای generative AI را میزبانی میکنند، برای بخشی یا همه workloadهای inference خود از Kubernetes استفاده میکنند. با این حال، تنها 7٪ از سازمانها مدلهای AI را بهصورت روزانه deploy میکنند. این فاصله نشان میدهد که «اجرای AI روی Kubernetes» با «آماده بودن یک پلتفرم Kubernetes برای بهرهبرداری مداوم از AI» یکسان نیست.
این چالش در تیمهای پلتفرم هم دیده میشود. پژوهش 2025 State of AI in Platform Engineering نشان داده است که 35٪ از تیمهای پلتفرم هنوز workloadهای AI را orchestration نمیکنند؛ موضوعی که از فاصله میان adoption AI و platformهای عملیاتی موردنیاز برای پشتیبانی در مقیاس خبر میدهد.
AI به معنی کنار گذاشتن cloud native practices نیست. Kubernetes، GitOps، observability، automation و self-service همچنان پایههای ارزشمندی هستند. اما AI نیازهای تازهای در حوزه compute، scheduling، model delivery و operations ایجاد میکند. 🙂
پس چه چیزهایی باید تغییر کند؟
گسترش مدل منابع فراتر از CPU و memory
AI اغلب بهعنوان یک workload مبتنی بر GPU مطرح میشود، اما pipelineهای واقعی AI در محیط production معمولاً heterogeneous هستند. data preparation، preprocessing، retrieval، orchestration و منطق برنامه ممکن است روی CPU اجرا شوند، در حالی که training یا inference از GPU یا acceleratorهای دیگر استفاده میکند. در نتیجه، یک workload واحد میتواند به چند نوع منبع وابسته باشد.
این موضوع scheduling را تغییر میدهد. تیمهای پلتفرم باید در کنار CPU، memory، topology و ویژگیهای workload، نوع و دسترسپذیری accelerator را هم در نظر بگیرند. Kubernetes نیز در حال تکامل برای پشتیبانی از این نیاز است. برای نمونه، Dynamic Resource Allocation (DRA) روشی انعطافپذیرتر و declarativeتر برای درخواست سختافزارهای تخصصی در اختیار workloadها قرار میدهد. هدف فقط در دسترس قرار دادن GPU نیست؛ هدف این است که compute ناهمگن هم بخشی از یک مدل منسجم منابع در Kubernetes باشد. 🚀
گسترش CI/CD به چرخه عمر model
تیمهای cloud native با CI/CD و GitOps، تحویل application را تکرارپذیر کردهاند. AI یک artifact مهم دیگر هم اضافه میکند: model.
بهجای مدیریت فقط این جریان:
Code → build → test → deploy
تیمها ممکن است اکنون لازم باشد این جریان را مدیریت کنند:
Code + model + configuration → evaluate → deploy → observe → update
modelها میتوانند حجیم باشند، به runtime یا hardware خاصی وابسته باشند و پیش از deployment نیاز به evaluation داشته باشند. بنابراین، تیمهای پلتفرم باید بتوانند بهروشنی به این پرسشها پاسخ دهند: کدام application، model و configuration در حال اجرا هستند و آیا میتوانیم آن deployment را دوباره بازتولید کنیم؟
اصل ماجرا آشناست: تغییرات باید versioned، repeatable و auditable بمانند. فقط کافی است pipeline تحویل، چیزی فراتر از کد application را هم در نظر بگیرد.
فقط cluster را مشاهده نکنید، workload را هم زیر نظر بگیرید
متریکهای سنتی زیرساخت همچنان مهماند، اما CPU، memory و request latency تمام داستان AI را نشان نمیدهند. بسته به نوع workload، تیمها ممکن است به visibility در زمینههای دیگری هم نیاز داشته باشند؛ از جمله میزان استفاده از accelerator و memory، زمانهای scheduling و queue، inference latency، زمان بارگذاری model، throughput و سلامت endpoint.
نکته مهم این نیست که برای AI یک monitoring stack جداگانه ساخته شود. مهم این است که observability موجود در cloud native گسترش پیدا کند تا telemetry مربوط به زیرساخت، application و AI بتواند در سراسر workload با هم ارتباط داده شود. این کار پاسخ به پرسشی را آسانتر میکند که صرفاً با GPU utilization نمیتوان به آن رسید: workload واقعاً کجا منتظر مانده است؟ 🔍
برای توسعهدهندگان AI یک golden path بسازید
توسعهدهندگان AI نباید برای deploy کردن یک model، متخصص Kubernetes و زیرساخت باشند. تیمهای پلتفرم میتوانند مسیرهای self-service استانداردی ارائه دهند که تصمیمهای رایج زیرساختی و عملیاتی را در خود رمزگذاری کردهاند:
Model → resources → deployment → endpoint → observability → policy
توسعهدهندگان مشخص میکنند workload به چه چیزی نیاز دارد و پلتفرم یک پیادهسازی تکرارپذیر ارائه میدهد. این همان اصل platform engineering است که به سادهتر شدن تحویل برنامههای cloud native کمک کرد. تفاوت اینجاست که golden path اکنون باید در کنار containerها، CPU و memory، modelها و acceleratorها را هم بشناسد.
AI را به یک workload production دیگر تبدیل کنید
AI انواع جدیدی از منابع و نیازهای چرخه عمر را وارد میکند، اما بسیاری از چالشهای عملیاتی آن آشنا هستند. جامعه cloud native پیشتر الگوهای قدرتمندی برای orchestration، declarative infrastructure، delivery خودکار، observability، policy و self-service توسعهدهنده دارد.
فرصت اصلی این است که همین الگوها گسترش پیدا کنند، نه اینکه یک مدل عملیاتی موازی برای AI ساخته شود.
یک پلتفرم Kubernetes زمانی AI-ready میشود که تیمها بتوانند workloadهای AI را بهصورت منسجم deploy کنند، آنها را end-to-end مشاهده کنند، منابع درست را تخصیص دهند و مسیر ثابتی برای حرکت توسعهدهندگان از experimentation به production فراهم کنند.
دیگر پرسش این نیست که آیا Kubernetes میتواند AI را اجرا کند یا نه. پرسش اصلی این است که آیا بهرهبرداری از AI روی Kubernetes میتواند به همان اندازه اجرای هر workload production دیگری عادی و روزمره شود؟ ✨
