دومین گروه از پروژه‌های Open Source که در یک سال گذشته به CNCF Sandbox اضافه شدند، شامل ۹ پروژه است که در بازه مارس تا می پذیرفته شده‌اند. این مجموعه، به‌طور پررنگ روی دو محور می‌چرخد: AI/ML و رویکردهای جایگزین برای اجرای workloadهای مختلف. یکی از نکات جالب این موج هم این است که بیشتر پروژه‌ها خیلی سریع‌تر از قبل مسیر پذیرش در CNCF را طی کرده‌اند؛ حتی یکی از آن‌ها در کمتر از شش ماه به این مرحله رسیده است. حالا ببینیم این نرم‌افزارها چه چیزی برای جامعه Cloud Native دارند 😎

مثل همیشه، پروژه‌ها را بر اساس دسته‌بندی رسمی CNCF مرور می‌کنیم و از بخشی شروع می‌کنیم که تعداد بیشتری پروژه دارد.

Automation & Configuration

1. KitOps
KitOps مدل‌های AI/ML را در قالب بسته‌های یکپارچه‌ای با نام ModelKits جمع می‌کند. داخل این بسته‌ها همه چیزهایی که برای بازتولید، تست و deploy مدل لازم است قرار می‌گیرد: code، model weights، datasetها، promptها، تنظیمات محیط و داده‌های دیگر. KitOps می‌تواند با مدل‌های مختلف کار کند؛ از LLMها گرفته تا multimodal modelها و predictive modelها.

هر ModelKit با یک manifest در قالب YAML و با نام Kitfile تعریف می‌شود. این فایل، جزئیات model، code مثل notebookها و scriptها، datasetها، promptها و مستندات را مشخص می‌کند. بعد از آماده شدن، با CLI مربوط به kit می‌توانید مدل‌ها را create، manage، run و deploy کنید. این ابزار را می‌شود داخل CI/CD pipeline هم استفاده کرد و برای سیستم‌های رایجی مثل Argo CD، Dagger و GitHub Actions هم tutorial دارد. یک راه دیگر برای مدیریت ModelKitها هم استفاده از Python library است.

تمام assetها مثل model، dataset و configuration به‌صورت جداگانه داخل OCI layerهای مستقل ذخیره می‌شوند و هرکدام SHA-256 digest مخصوص خودشان را دارند. برای ذخیره‌سازی هم هر registry سازگار با OCI 1.1+ قابل استفاده است.

بعد از شکل‌گیری KitOps، specification رسمی آن به پروژه‌ای جدا به نام ModelPack تبدیل شد. ModelPack حالا یک پروژه CNCF Sandbox است و به‌عنوان یک استاندارد vendor-neutral برای بسته‌بندی، توزیع و اجرای AI modelها شناخته می‌شود. در مقاله بعدی، بیشتر به آن می‌پردازیم، چون از نظر رسمی در batch بعدی به CNCF اضافه شده است ✨

2. OpenTofu
OpenTofu با اینکه تازه به CNCF Sandbox اضافه شده، اما از قبل برای خیلی‌ها شناخته‌شده است. این پروژه در آگوست ۲۰۲۳ و بعد از آن شروع شد که HashiCorp license مربوط به Terraform را به BSL یا Business Source License تغییر داد؛ مجوزی که Open Source محسوب نمی‌شود و با واکنش منفی شدید جامعه روبه‌رو شد.

این واکنش آن‌قدر گسترده بود که فقط دو هفته بعد از اعلام تغییر license، بیش از ۱۰۰ شرکت و صدها نفر اعلام کردند که یک fork از Terraform با نام OpenTofu می‌سازند؛ نام اولیه این پروژه OpenTF بود. ماه بعد، پروژه تحت مالکیت Linux Foundation قرار گرفت. چند ماه بعد هم، در ژانویه ۲۰۲۴، برای ورود به CNCF Sandbox درخواست داد.

اما چرا این درخواست این‌قدر طول کشید؟ دلیل اصلی چالش‌های حقوقی بود؛ از جمله Cease and Desist نامه HashiCorp که ادعای copyright infringement درباره بعضی تغییرات OpenTofu را مطرح می‌کرد. از طرف دیگر، موضوع license پروژه هم مهم بود، چون OpenTofu با MPL منتشر شده بود و CNCF معمولاً فقط پروژه‌های Apache-licensed را می‌پذیرد؛ بنابراین نیاز به استثنا از طرف CNCF Governing Board داشت.

بعد از نزدیک به یک سال انتظار، CNCF TOC در ژانویه ۲۰۲۵ پروژه را بررسی کرد و چند ماه بعد رسماً آن را پذیرفت. امروز OpenTofu یک جایگزین community-driven برای Terraform در حوزه IaC است که syntax اصلی HCL، همان backendها و بخش بزرگی از قابلیت‌های نسخه مادر را پشتیبانی می‌کند.

قبلاً هم OpenTofu را بررسی کرده‌ایم و شاید مهم‌ترین قابلیت متمایز آن هنوز همان client-side state encryption باشد. به‌طور کلی، انتخاب OpenTofu بیشتر از آن‌که به خاطر یک feature خاص باشد، به خاطر پایبندی به یک راهکار Open Source و vendor-neutral است 👍

3. kagent
این پروژه یک framework برای ساخت و اجرای AI agentها داخل Kubernetes ارائه می‌دهد. برای استفاده از آن، ابتدا باید agent را با یک system prompt، مجموعه‌ای از toolها و یک LLM configuration تعریف کنید.

Toolها چه هستند؟ اول، toolهای داخلی دارد که با تعداد زیادی از پروژه‌های Cloud Native کار می‌کنند؛ از جمله Kubernetes، Helm، Istio، Cilium، Argo، Grafana و Prometheus. دوم، می‌توانید agentهای دیگر را هم به‌عنوان tool استفاده کنید. سوم، kagent از سایر MCP (Model Configuration Protocol) toolها و حتی HTTP toolها هم پشتیبانی می‌کند، البته اگر OpenAPI-compliant باشند و قابل discovery شوند.

در بخش LLM configuration هم kagent از providerهای مختلف پشتیبانی می‌کند؛ از جمله Amazon Bedrock، Anthropic، Azure OpenAI، Gemini، Google Vertex AI، Ollama و OpenAI. حتی می‌توانید از مدل‌های دیگر که با OpenAI API-compatible LLM سازگار هستند هم استفاده کنید، مثل Cohere AI.

وقتی agent تعریف شد، همه چیز به‌صورت Kubernetes custom resource ذخیره می‌شود. برای هر بخش، custom resource جدا وجود دارد: خود agent، toolهای آن، providerهای LLM و سایر اجزا. بعد از آن، یک Kubernetes controller که این custom resourceها را watch می‌کند، همه چیز لازم را برای اجرای agent می‌سازد.

از این مرحله به بعد، می‌توانید agent را از طریق UI، CLI یا Web GUI مدیریت کنید. مثلاً می‌شود agentها را list کرد یا برایشان message فرستاد. در Web UI مربوط به kagent هم امکان chat با agent وجود دارد 💬

kagent از Human-in-the-Loop هم پشتیبانی می‌کند؛ یعنی agent می‌تواند از کاربر سؤال بپرسد و برای بعضی اقدام‌هایی که toolها انجام می‌دهند، تأیید کاربر لازم باشد. برای بهتر شدن نحوه استفاده agent از toolها هم از skills استفاده می‌شود؛ یعنی می‌توانید دستورالعمل مشخصی برای این‌که toolها چه زمانی و چطور استفاده شوند تعریف کنید.

skills می‌توانند به شکل توضیحات static تعریف شوند که به آن‌ها actions-to-actions یا A2A گفته می‌شود، یا به‌صورت code/module/function اجرایی که داخل container image بسته‌بندی شده‌اند؛ در این حالت، container-based نام می‌گیرند.

kagent قابلیت audit برای همه promptها و پاسخ‌های agent را هم فراهم می‌کند و tracing را هم می‌توان برای آن فعال کرد؛ در مستنداتش حتی یک نمونه برای Jaeger هم آمده است. علاوه بر این، یک پروژه جدا به نام kmcp هم وجود دارد که توسعه local برای MCP serverها و toolهایی را که می‌شود با kagent استفاده کرد، ساده‌تر می‌کند.

4. Cadence
Cadence یک orchestration engine یا در واقع یک code platform برای ساخت applicationهای distributed است. این پروژه به شما اجازه می‌دهد با الگوی fault-oblivious stateful programming کدنویسی کنید و در نهایت، durability، availability و scalability اپلیکیشن را تضمین می‌کند.

مفهوم اصلی Cadence workflow است؛ workflow با code تعریف می‌شود و fault-oblivious و stateful است، یعنی نسبت به خرابی یا downtime حساس نیست و state خودش را حفظ می‌کند. مفهوم مهم دیگر activity است که به شما اجازه می‌دهد از محدودیت‌های deterministic workflow عبور کنید و مثلاً مستقیم APIهای خارجی را صدا بزنید. البته Cadence state مربوط به activity را در صورت failure بازیابی نمی‌کند.

از مفاهیم مهم دیگر این پروژه eventها هستند که workflow می‌تواند به آن‌ها واکنش نشان دهد، و queryها که وضعیت داخلی workflow را به دنیای بیرون expose می‌کنند. use caseهای رایج Cadence شامل چندین call به microserviceها، jobهای دوره‌ای و batch jobها، polling taskها، اپلیکیشن‌های event-driven، provisioning زیرساخت، deploy اپلیکیشن و workflowهای DSL است.

یک application معمولی مبتنی بر Cadence از workflowها، activityها و external clientها تشکیل می‌شود که همگی برای اجرا به سرویس Cadence متکی هستند. کد اپلیکیشن را می‌توان با SDKهای رسمی نوشت که برای Go و Java در دسترس‌اند. تلاش‌هایی هم برای SDKهای Python و Ruby انجام شده، اما به نظر می‌رسد دیگر نگهداری نمی‌شوند.

سرویس Cadence یک application چندمستاجری و مقیاس‌پذیر است که قابلیت‌های خود را از طریق یک gRPC API strongly typed ارائه می‌دهد. backend این platform stateless است، اما workflow history در یک database ذخیره می‌شود؛ گزینه‌هایی مثل Apache Cassandra، MySQL/TiDB یا PostgreSQL/CockroachDB برای آن پشتیبانی می‌شوند.

Cadence یک CLI برای مدیریت workflowها و یک Web UI برای مشاهده آن‌ها هم دارد. برای deploy در Kubernetes هم Helm chart ارائه می‌کند، و برای مانیتورینگ ساده‌تر، chartهایی برای یکپارچه‌سازی با Grafana و dashboardهای از پیش تنظیم‌شده در دسترس هستند 📊

Container Runtime

5. Hyperlight
این کتابخانه Rust یک lightweight virtual machine manager را پیاده‌سازی می‌کند. ایده اصلی Hyperlight این است که بتواند microVMها را در زمان فوق‌العاده کم، یعنی حدود ۱ تا ۲ میلی‌ثانیه، بالا بیاورد.

این VMها micro هستند، چون بر خلاف virtual machineهای سنتی، یک operating system کامل یا guest kernel داخلشان وجود ندارد. guestها باید مشخصاً برای Hyperlight و با استفاده از guest library آن، در Rust یا C، پیاده‌سازی شوند. در عوض، این VMها hypervisor-isolated هستند و راه امنی برای اجرای code غیرقابل اعتماد فراهم می‌کنند.

Hyperlight از Linux KVM، Hyper-V روی Windows با WHP، و Hyper-V برای Linux با mshv به‌عنوان hypervisor پشتیبانی می‌کند. چون VMها تقریباً فوری ساخته می‌شوند، این پروژه برای سناریوهای scale-to-zero و موقعیت‌هایی که باید سریع به eventها واکنش نشان داد، گزینه خوبی است.

هرچند سرعت آن به پای functionهای native نمی‌رسد، اما از بسیاری از راهکارهای virtualisation مثل Firecracker سریع‌تر است. استفاده از Hyperlight در سناریوهای مختلف هم با subprojectهایی ساده‌تر می‌شود که اجرای workloadهای گوناگون را داخل microVM ممکن می‌کنند.

برای مثال، Hyperlight-wasm می‌تواند Wasm moduleها و componentها را داخل sandboxهای مبتنی بر VM اجرا کند. Hyperlight-js هم یک JavaScript runtime است که داخل Hyperlight اجرا می‌شود ⚙️