با نزدیک شدن به پایان سال، نگاهی داریم به پروژههای جدید CNCF که در سال 2025 توسط جامعه Cloud Native و کمیته فنی نظارت CNCF یا همان TOC معرفی شدند. این مطلب به موج اول این پروژهها میپردازد؛ ۱۳ پروژهای که در ژانویه 2025 وارد Sandbox شدند. این تعداد برای TOC یک رکورد مهم محسوب میشود، چون بیشترین تعداد پروژهای است که در یک ماه پذیرفته شدهاند. ✨
این گروه از پروژهها یک ویژگی مهم هم دارد: چهار پروژه از Red Hat به این مجموعه اضافه شدهاند؛ موضوعی که بعد از اعلام این شرکت در KubeCon + CloudNativeCon NA 2024 شکل گرفت. مثل همیشه، پروژهها را بر اساس دستهبندی رسمیشان مرور میکنیم و از دستهای شروع میکنیم که آیتمهای بیشتری دارد. 🚀
Container Runtime
1. Podman Container Tools
Podman برای خیلی از تیمهای DevOps و SRE نامی آشناست، اما شاید همه ندانند که این پروژه ابتدا با نام kpod شناخته میشد و بخشی از CRI-O بود. CRI-O یک پیادهسازی Container Runtime Interface یا CRI است که Red Hat آن را توسعه داده است. Podman در ابتدا بهعنوان جایگزینی سبکتر برای Docker مطرح شد و بعد از مسیرش از مخزن kubernetes-incubator به یک پروژه Graduated در CNCF رسید.
Podman از دل CRI-O بیرون آمد تا تجربهای شبیه Docker CLI ارائه کند؛ یعنی بتوانید کانتینرهای مستقل یا گروهی از کانتینرها را بدون نیاز به daemon اجرا کنید. همین daemonless بودن باعث شد اجرای rootless هم برایش ممکن شود و از نظر امنیتی برای خیلی از سناریوها جذابتر باشد. این پروژه در کنار libpod، یک CLI با نام podman هم دارد.
امروز Podman یک ابزار مدرن برای مدیریت container، pod، image و volume است و CLI آن تا حد زیادی با Docker سازگاری دارد. در دنیای Red Hat، از RHEL گرفته تا OpenShift، این ابزار انتخاب پیشفرض است و در برخی توزیعهای دیگر مثل SUSE Linux Enterprise هم دیده میشود.
Podman روی Linux بهصورت مستقیم اجرا میشود و روی Mac و Windows هم با podman machine قابل استفاده است؛ در این حالت یک virtual machine با Linux guest بالا میآید و کانتینرها داخل آن اجرا میشوند.
یکی از مهمترین تفاوتهای Podman تمرکز جدی آن روی security است، چون daemonless و rootless است. در کنار آن، اکوسیستم ابزارهای مرتبط هم دارد که Podman Desktop یکی از مهمترینهای آن است. از آنجا که Podman Desktop هم اخیراً وارد CNCF Sandbox شده، در ادامه بیشتر به آن میپردازیم. 📦
طبق survey سال 2025 سایت Stack Overflow، حدود 11٪ از توسعهدهندگان در جهان از Podman استفاده میکنند، در حالی که این عدد برای Docker حدود 71٪ است.
2. bootc
bootc یک API و CLI برای بهروزرسانی in-place سیستمعامل با استفاده از OCI images ارائه میدهد. ایده اصلی پروژه این است که updateهای سیستمعامل هم مثل imageهای کانتینری بستهبندی و توزیع شوند. با این مدل، bootc تلاش میکند یک الگوی پیشفرض برای Linux سیستمها بسازد که در آن سیستمها به شکل image ساخته و تحویل داده شوند.
به زبان ساده، bootc یک bootable container image را همراه با Linux kernel اجرا میکند، updateهای جدید سیستمعامل را از registry بررسی و دریافت میکند، آنها را اعمال میکند و اگر لازم باشد امکان rollback به deployment قبلی را هم فراهم میسازد.
این پروژه با دو bootloader یعنی bootupd از Fedora CoreOS و systemd-boot کار میکند. برای ذخیرهسازی هم از OSTree استفاده میکند تا imageهای کانتینری روی یک سیستم مبتنی بر OSTree برای host بوتشده قرار بگیرند. هنگام build کانتینر هم میتوان از package managerهایی مثل apt و dnf استفاده کرد.
برخی قابلیتهای experimental آن شامل استفاده از composefs بهعنوان backend جایگزین ذخیرهسازی، نمایش پیشرفت بهصورت interactive و حتی factory reset برای سیستمهای bootc موجود است. 🛠️
3. composefs
composefs با شعار «پایداری disk imageها، انعطافپذیری فایلها» طراحی شده و هدفش این است که disk imageهایی هم قابل اعتماد باشند و هم انعطافپذیر. این پروژه میتواند برای container imageها و همچنین سیستمهای host بوتشونده مثل OSTree یا bootc استفاده شود.
composefs خودش دادهها را ذخیره نمیکند، اما چند قابلیت مهم را روی filesystemهای موجود اضافه میکند. ایدههای اصلی آن شامل استفاده از overlay بهعنوان رابط kernel، جدا نگهداشتن دادههای regular file از metadata، استفاده از EROFS برای ساخت metadata tree و ذخیرهسازی content-addressed برای فایلهای مشترک است تا چند mount بتوانند از یک داده مشترک استفاده کنند. این کار هم روی disk و هم در page cache باعث sharing بهتر دادهها میشود.
برای اعتبارسنجی content fileها هم از fs-verity استفاده میکند. این پروژه دو ابزار CLI با نامهای mkcomposefs و mount.composefs دارد و برای Rust هم binding ارائه میدهد. 🔍
Scheduling & Orchestration
4. k0s
k0s یک distribution سبک و شناختهشده Kubernetes است که با طراحی ساده و مینیمال خود شناخته میشود. در واقع، این پروژه یک نسخه vanilla از Kubernetes را بهصورت یک binary واحد ارائه میدهد؛ با نیازمندیهای سیستمی کم، وابستگی host حداقلی و راهاندازی ساده.
همین سادگی در مدیریت کلاستر هم دیده میشود. ابزار k0sctl برای upgrade نسخه Kubernetes و همچنین backup و restore کلاستر در دسترس است. با k0s میتوان single-node، multi-node و حتی air-gapped Kubernetes setupها را روی bare-metal، زیرساخت on-prem، محیطهای edge و IoT یا cloudهای عمومی و خصوصی اجرا کرد.
هدف پروژه این است که تا حد ممکن non-opinionated باشد؛ یعنی به کاربران آزادی بدهد تا componentهای دلخواه Kubernetes را انتخاب کنند و پروژه آنها را بهصورت تحمیلی داخل خود embed نکند. به همین دلیل، k0s بر پایه codebase اصلی Kubernetes است و این موارد را پشتیبانی میکند:
store backendهای مختلف برای Kubernetes، از جمله SQLite بهعنوان گزینه پیشفرض برای single-node، و همچنین etcd برای multi-node و MySQL و PostgreSQL؛
CRI pluginهای سفارشی، با containerd بهعنوان گزینه پیشفرض؛
CNI pluginهای سفارشی، با kube-router بهصورت پیشفرض و Calico بهعنوان جایگزین آماده استفاده؛
تمام CSI pluginها.
حدود یک ماه پیش هم k0s درخواست رسمی خود را برای رفتن به سطح Incubating ثبت کرد. 📈
5. KubeFleet
KubeFleet خودش را یک راهکار “multi-cluster application management” برای Kubernetes معرفی میکند. این پروژه برای operatorهایی طراحی شده که با چند کلاستر سروکار دارند و به آنها کمک میکند workloadها را orchestration کنند، زمانبندی انجام دهند و تغییرات را بهصورت مرحلهای rollout کنند.
در بخش orchestration، میتوان منابع Kubernetes را از طریق hub cluster روی member clusterها deploy کرد. در بخش scheduling هم KubeFleet چند نوع plugin داخلی دارد، از جمله topology spread، cluster affinity، same placement affinity، cluster eligibility و taint & toleration. بسته به نوع plugin، extension pointهای آن هم متفاوت است؛ مثل pre-filter/filter، pre-score/score و batch/post-batch.
در حال حاضر تنها strategy موجود RollingUpdate است و برای deploymentهای پیچیده، staged rollout را پشتیبانی میکند.
KubeFleet از مدل pull مبتنی بر agent استفاده میکند و دو Kubernetes controller دارد: fleet-hub-agent که منابع را در hub cluster ایجاد و reconcile میکند، و fleet-member-agent که با دریافت آخرین منابع از hub همین کار را برای member cluster انجام میدهد.
در مستندات این پروژه، یک tutorial هم برای integration با Argo CD وجود دارد که توضیح میدهد چطور میتوان این ابزارها را کنار هم گذاشت و از مزیت GitOps در deploymentهای multi-cluster بهره برد. 🔄
Orchestration & Management
6. SpinKube
SpinKube برای توسعه، استقرار و مدیریت workloadهای WebAssembly در Kubernetes طراحی شده است. این پروژه از چند بخش اصلی تشکیل شده و همین ساختار نشان میدهد که SpinKube چطور کار میکند و چه مسئلهای را حل میکند.
Spin بهعنوان framework و CLI برای ساخت، توزیع و اجرای Wasm applicationها عمل میکند. در کنار آن، Spin SDKها برای زبانهای مختلف برنامهنویسی ارائه شدهاند که نسخههای رسمی آنها برای JavaScript، Rust، Go و Python در دسترس هستند.
این SDKها APIهای قدرتمندی دارند و از HTTP و Redis triggerها، key-value storeهایی مثل SQLite، Redis، Valkey و Azure Cosmos DB و همچنین relational databaseهایی مانند MySQL و PostgreSQL پشتیبانی میکنند.
Spin Operator برای deploy و اجرای Wasm appها در Kubernetes استفاده میشود؛ این appها بهصورت custom resource تعریف میشوند. در کنار آن، Containerd Shim Spin بهعنوان runtime shim برای appهای Spin که توسط containerd مدیریت میشوند عمل میکند.
Runtime Class Manager هم یک Kubernetes operator دیگر است که چرخه عمر containerd shimها را مدیریت میکند؛ از جمله تنظیم، نصب و بهروزرسانی آنها. Spin Kube Plugin هم مجموعهای از CLI commandها را برای سادهسازی مدیریت Spin appها در Kubernetes فراهم میکند، مثل deploy کردن یا کنترل تنظیمات autoscaling.
Spin applicationها میتوانند از متغیرهای موجود در Kubernetes objectها مثل ConfigMap و Secret و همچنین providerهای خارجی مثل Vault و Azure Key Vault استفاده کنند.
برای observability هم SpinKube دادهها را به OpenTelemetry collector میفرستد و آنجا میتواند traceها را به Jaeger منتقل کند. integration با KEDA هم برای autoscaling وجود دارد. 📊
7. container2wasm
container2wasm هم یکی دیگر از پروژههای مرتبط با WebAssembly است. این پروژه بهطور خلاصه containerها را به Wasm تبدیل میکند و برای سناریوهایی مناسب است که میخواهید workloadهای کانتینری را با الگوی اجرایی سبکتر و سریعتر در محیطهای سازگار با WebAssembly اجرا کنید. ⚙️
