سد سخت‌افزاری Oxide در برابر Kubernetes؛ نیاز به بازطراحی برای اتصال گرم دیسک

تصور کنید لحظه‌ای را که انتزاع‌های نرم‌افزاری با محدودیت‌های صلب سخت‌افزاری برخورد می‌کنند؛ این دقیقاً همان نقطه‌ای است که اجرای Kubernetes در محیط‌های تولیدی روی زیرساخت‌های Bare-metal معمولاً به یک دیوار بتنی برخورد می‌کند. شرکت Oxide Computer Company در حال حاضر با ساخت یک اکوسیستم سفارشی از ادغام‌ها (Integrations) در حال پیمودن این شکاف است تا Kubernetes را به پشته سخت‌افزاری تخصصی خود بیاورد.

برای اکثر مهندسان، ابر (Cloud) مانند یک جعبه سیاه است که در آن ذخیره‌سازی و شبکه به‌طور خودکار و بدون دردسر کار می‌کنند. اما وقتی به سراغ یک پلتفرم سخت‌افزار-نرم‌افزار با طراحی مشترک (Co-designed) مانند Oxide می‌روید، نقاط اتصال استاندارد Kubernetes باید به‌صورت دستی به دستورات API خاص سخت‌افزار متصل شوند. این فرآیند دقیقاً فاش می‌کند که انتزاع‌های «استاندارد» صنعت در کجا شکست می‌خورند و کارایی خود را از دست می‌دهند.

در اواخر سال ۲۰۲۴، مشتریان و متقاضیان Oxide مشتاق بودند Kubernetes را روی این پلتفرم اجرا کنند، اما شرکت هیچ ادغام پشتیبانی‌شده‌ای برای کمک به آن‌ها در این مسیر نداشت. از نظر ساختاری، Kubernetes و Oxide یک جفت مکمل هستند: Kubernetes رفتار زیرساختی مورد انتظار خود را از طریق نقاط اتصال استاندارد تعریف می‌کند، در حالی که Oxide ابزارهای اولیه (Primitives) لازم برای پیاده‌سازی آن رفتار را از طریق APIهای خود ارائه می‌دهد. بنابراین، زیربنای لازم برای ادغام وجود داشت، اما نرم‌افزار واسط و درک روشنی از نیازهای واقعی مشتریان مفقود بود.

این شکاف، تمرکز اصلی نخستین مهندس نرم‌افزارهای راهکار (Solutions Software Engineer) شرکت Oxide بود که به‌طور خاص برای ساخت نرم‌افزارهایی که مشکلات مشتریان را حل کند، به شرکت پیوست. ماموریت او ساده اما دشوار بود: آسان‌تر کردن استقرار و بهره‌برداری از Kubernetes روی Oxide. این فرآیند در اولین هفته کاری این مهندس با دو منبع کلیدی آغاز شد: یک درخواست Pull Request ارسال شده توسط مشتری برای درایور گره Rancher و پیش‌نویس اولیه RFD 493 با عنوان «ادغام‌های اولیه Kubernetes».

تیم توسعه به‌جای طراحی ادغام‌ها در فضای انتزاعی و تئوریک، یک حلقه بازخورد بر اساس مشکلات واقعی مشتریان را دنبال کرد. آن‌ها چرخه حیات Kubernetes را از مرحله ایجاد خوشه‌ها (Provisioning) تا مدیریت بارهای کاری (Workloads) ردیابی کردند. این سفر آن‌ها را از مسیر Rancher، Omni و Cluster API عبور داد و در نهایت شکاف‌هایی را در بازسازی زیرساخت (Infrastructure Reconciliation)، شبکه و ذخیره‌سازی Stateful آشکار کرد. در هر مرحله، جریان‌های کاری مشتریان، شکاف بعدی را برملا می‌کرد و هم به ادغام‌های ساخته شده و هم به کارهای پلتفرمی که هنوز در پیش بود، شکل می‌داد.

لایه ایجاد خوشه (Provisioning)

شرکت Oxide اکنون سه مسیر مجزا برای ایجاد خوشه‌ها پشتیبانی می‌کند تا اطمینان حاصل شود که جریان‌های کاری مختلف سازمانی پوشش داده شده‌اند. از آنجایی که هیچ رویکرد واحدی برای همه مشتریان مناسب نبود، سه ادغام مجزا منتشر شد:

• Rancher Node Driver: این یک پلاگین اجرایی است که به Rancher می‌آموزد چگونه ماشین‌های مجازی را روی پلتفرم Oxide ایجاد و مدیریت کند. این ابزار عملیات Rancher را به درخواست‌های API Oxide ترجمه می‌کند. پس از نصب، مشتریان می‌توانند نمونه‌های Oxide را به‌عنوان گره‌هایی در خوشه‌های Kubernetes تحت مدیریت Rancher ایجاد کنند. این اولین ادغام رسمی بود که از یک مشارکت مشتری ادغام شد و با موفقیت در محیط تولید (Production) مورد استفاده قرار گرفت.
• Omni Infrastructure Provider: این ابزار در مشارکت با Sidero Labs ساخته شده است و اجازه می‌دهد از Omni برای ایجاد خوشه‌هایی که روی Talos Linux اجرا می‌شوند، استفاده شود. Omni از طریق ارائه‌دهندگان زیرساخت به پلتفرم‌ها متصل می‌شود تا نمونه‌های Talos Linux را ایجاد کرده و آن‌ها را در Omni ثبت کند. این ادغام در یک بازه زمانی بسیار فشرده هفت‌هفته‌ای توسعه یافت تا در یک رویداد مشترک Oxide+Sidero در جریان KubeCon آمریکای شمالی ۲۰۲۵ به نمایش گذاشته شود.
• Cluster API Provider Oxide (CAPOx): یک رویکرد بومی در Kubernetes است که از منابع سفارشی (Custom Resources) برای ایجاد، مقیاس‌دهی، ارتقاء و حذف خوشه‌ها به‌صورت Declarative استفاده می‌کند، بدون اینکه به پلتفرم شخص ثالثی مانند Rancher یا Omni نیاز باشد. توسعه این مورد در ابتدا به دلیل محدودیت ظرفیت مهندسی به تعویق افتاد، اما بعداً توسط همکارانی به نام‌های جاش و براندون در پاسخ به افزایش تقاضای مشتریان توسعه یافت.

جزئیات ایجاد خوشه و موانع فنی

ساخت این ارائه‌دهنده‌ها اصطکاک‌های فنی قابل‌توجهی را بین پلتفرم و سیستم‌عامل مهمان (Guest OS) آشکار کرد:

• باگ سیستم فایل Talos Linux: در جریان ادغام Omni، تیم متوجه شد که Oxide از سیستم فایل FAT12 برای داده‌های کاربر cloud-init استفاده می‌کند، در حالی که بررسی سیستم فایل در Talos Linux فقط سعی می‌کرد یک Superblock از نوع ISO 9660 را از دیسک پیکربندی NoCloud بخواند. وقتی خواندن ISO 9660 شکست می‌خورد، بررسی متوقف می‌شد و Talos سعی نمی‌کرد VFAT یا MS-DOS را امتحان کند. در نتیجه، Talos هرگز داده‌های کاربر Oxide را که برای پیوستن به Omni ضروری بود، نمی‌خواند. این مشکل در موارد siderolabs/omni#1633 و siderolabs/talos#11948 ردیابی شد.
• راهکار موقت KubeCon: از آنجایی که اصلاح این باگ به‌موقع برای KubeCon منتشر نمی‌شد، تیم یک راهکار موقت (Workaround) اجرا کرد: پر کردن داده‌های کاربر با کامنت‌ها برای افزایش اندازه آن تا حدی که سیستم را مجبور کند از یک Superblock از نوع ISO 9660 استفاده کند.
• ادغام با اکوسیستم CAPI: جریان کاری CAPOx چندین ابزار دیگر Oxide را به کار می‌گیرد. ابزار Kubernetes Image Builder از یک پلاگین Packer برای ایجاد تصاویر VM اکساید آماده برای CAPI استفاده می‌کند. پس از ایجاد، این خوشه‌ها از مدیریت‌کننده کنترل‌کننده ابر (CCM) اکساید برای ادغام با پلتفرم در زمان اجرا استفاده می‌کنند.
• ارزش‌های مشارکت: همکاری با Sidero Labs به عنوان یک کاربرد عملی از RFD 68 (مشارکت به عنوان ارزش‌های مشترک) عمل کرد، زیرا هر دو تیم برای حل مشکلات سیستم فایل Talos به‌طور نزدیک با یکدیگر همکاری کردند.

زمان اجرا و شبکه

ایجاد یک ماشین مجازی تنها نیمی از نبرد است؛ خوشه باید بداند آیا سخت‌افزار زیرین هنوز وجود دارد یا خیر. برای حل این مشکل، Oxide یک مدیریت‌کننده کنترل‌کننده ابر (Cloud Controller Manager یا CCM) ساخت. این جزء به عنوان پل ارتباطی زمان اجرا عمل می‌کند و اشیاء Node در Kubernetes را با نمونه‌های Oxide همگام می‌کند تا از تلاش خوشه برای استفاده از سخت‌افزارهای حذف‌شده جلوگیری کند.

بدون این بازسازی (Reconciliation)، یک خوشه نمی‌توانست به‌طور قابل‌اطمینانی تشخیص دهد که آیا یک گره Kubernetes غیرقابل دسترس، به‌طور موقت در دسترس نیست یا اینکه نمونه Oxide پشتیبان آن به‌طور کلی حذف شده است. کنترل‌کننده گره در CCM به‌طور مداوم با API اکساید صحبت می‌کند تا شناسه‌های نمونه (Instance IDs) و آدرس‌های شبکه را ثبت کند. این ابزار گزارش می‌دهد که آیا یک نمونه در حال اجرا است، خاموش شده یا دیگر وجود ندارد. این امر به Kubernetes اجازه می‌دهد تا گره‌ها را مقداردهی اولیه کرده و زمانی که نمونه‌های پشتیبان آن‌ها حذف شدند، آن‌ها را به‌طور ایمن حذف کند.

به‌طور حیاتی، CCM یک نقطه اتصال بادوام فراهم می‌کند؛ با تکامل Oxide، کنترل‌کننده‌های جدید آگاه از زیرساخت را می‌توان بدون به‌روزرسانی هر یک از ادغام‌های ایجاد خوشه، به CCM اضافه کرد. CCM نمونه‌ها را ایجاد نمی‌کند یا خوشه‌ها را مستقر نمی‌سازد — این کار بر عهده درایور گره Rancher، ارائه‌دهنده Omni و CAPOx باقی می‌ماند — اما یک ادغام زمان اجرای مشترک را در تمام این جریان‌های کاری فراهم می‌کند.

شبکه چالش متفاوتی را ایجاد کرد: نبود یک Load Balancer بومی در Oxide. برای باز کردن مسیر سرویس‌های LoadBalancer، تیم سیستمی را با استفاده از IPهای شناور (Floating IPs) پیاده‌سازی کرد. IPهای شناور آدرس‌هایی از استخرهای IP خارجی یک رک هستند که می‌توانند به نمونه‌ها متصل یا از آن‌ها جدا شوند و آن‌ها را از خارج از VPCهای خودشان قابل دسترس کنند.

از آنجایی که Oxide آدرس‌های مقصد را قبل از رسیدن به مهمان به IPهای داخلی ترجمه می‌کند، دیتاپلین سرویس Kubernetes باید IP داخلی را به عنوان فرانت-اند (Frontend) در نظر بگیرد. جریان ترافیک این مسیر را دنبال می‌کند: درخواست کلاینت به IP شناور (مثلاً 45.154.216.233:80) $
ightarrow$ شبکه Oxide آن را به IP داخلی ترجمه می‌کند (مثلاً 172.30.0.5:80) $
ightarrow$ گره Kubernetes بسته را در IP داخلی دریافت می‌کند $
ightarrow$ دیتاپلین سرویس یک Endpoint را انتخاب می‌کند $
ightarrow$ پاد ترافیک را دریافت می‌کند.

این منجر به یک خروجی منحصر‌به‌فرد در kubectl get service می‌شود که در آن کنترل‌کننده سرویس دو ورودی در status.loadBalancer.ingress منتشر می‌کند: IP شناور در حالت Proxy و IP داخلی گره در حالت VIP. ورودی‌های وضعیت به این شکل هستند:

status:
  loadBalancer:
    ingress:
      - ip: 45.154.216.233
        ipMode: Proxy
      - ip: 172.30.0.5
        ipMode: VIP

در نتیجه، ستون EXTERNAL-IP هر دو آدرس را نشان می‌دهد (مثلاً 45.154.216.233,172.30.0.5)، هرچند تنها IP شناور از بیرون قابل دسترس است. این یک انتزاع ناقص است، اما اجازه می‌دهد تا زمان عرضه یک Load Balancer بومی در Oxide، از یک جریان کاری رایج Kubernetes پشتیبانی شود.

این پیاده‌سازی در حال حاضر از externalTrafficPolicy: Cluster پشتیبانی می‌کند و به گره انتخاب شده اجازه می‌دهد ترافیک را به هر Endpoint در خوشه ارجاع دهد. اگر گرهی ناپدید شود، CCM آی‌پی شناور را به گره واجد شرایط دیگری منتقل کرده و آدرس داخلی را در وضعیت سرویس به‌روز می‌کند.

دیوار ذخیره‌سازی

ذخیره‌سازی جایی است که ادغام با یک مسدودکننده معماری بنیادی برخورد کرد. کاربران Kubernetes درخواست ذخیره‌سازی پایدار را از طریق اشیاء PersistentVolumeClaim ارسال می‌کنند و انتظار دارند یک درایور رابط ذخیره‌سازی کانتینری (CSI) حجم‌ها را مدیریت کند. در حالی که Oxide دیسک‌هایی دارد، Kubernetes هیچ راه بومی برای مدیریت چرخه حیات آن‌ها نداشت.

در ابتدا، مشتریان از Longhorn استفاده کردند که درایور CSI خود را فراهم می‌کند و داده‌ها را در دیسک‌های Worker تکثیر می‌کند. با این حال، این کار یک مشکل عظیم «تقویت نوشتن» (Write Amplification) ایجاد کرد. نسخه‌های Longhorn توسط دیسک‌های توزیع‌شده Oxide پشتیبانی می‌شدند که خودشان به‌طور پیش‌فرض سه نسخه را روی Sledهای مجزا ذخیره می‌کنند. در یک حجم Longhorn با سه نسخه که توسط دیسک‌های تکثیر شده سه-گانه Oxide پشتیبانی می‌شود، یک عملیات نوشتن برنامه می‌تواند به ۹ نوشتن فیزیکی روی دیسک تبدیل شود. مقدار دقیق تقویت نوشتن فیزیکی به بار کاری و پیکربندی بستگی دارد، اما مشتریان می‌خواستند از این تکثیر تکراری اجتناب کنند.

برای کاهش این مشکل، Oxide دیسک‌های محلی (Local Disks) را معرفی کرد. دیسک‌های محلی هیچ تکثیر داخلی ندارند و به Sled خود متصل می‌مانند، که آن‌ها را برای سیستم‌هایی مانند Longhorn که تکثیر را در سطح گره Kubernetes مدیریت می‌کنند، ایده‌آل می‌کند. این رویکرد در حال حاضر در نمایش Rancher برای جلوگیری از روی هم قرار گرفتن دو سیستم ذخیره‌سازی تکثیر شده استفاده می‌شود، اگرچه Longhorn همچنان چرخه حیات ذخیره‌سازی را مدیریت می‌کند و نه یک ادغام بومی Oxide.

برای یک ادغام بومی، تیم پلاگین CSI اکساید (RFD 595) را توسعه داد. جریان کاری مورد نظر این بود:

1. کاربر یک PersistentVolumeClaim ایجاد می‌کند.
2. کنترل‌کننده CSI یک دیسک توزیع‌شده Oxide ایجاد می‌کند.
3. کنترل‌کننده دیسک را به نمونه Oxide انتخاب شده متصل می‌کند.
4. پلاگین گره CSI آن را برای پاد فرمت و Mount می‌کند.

با این حال، تیم با یک مسدودکننده بحرانی مواجه شد: Oxide نیاز دارد که یک نمونه (Instance) قبل از اتصال یا جداسازی دیسک، متوقف (Stop) شود. در حالی که Kubernetes انتظار دارد یک درایور CSI ذخیره‌سازی را به یک Worker در حال اجرا پس از زمان‌بندی (Scheduling) یک پاد متصل کند. متوقف کردن یک گره Worker برای اتصال دیسک، هر بار کاری دیگر روی آن گره را مختل می‌کند و می‌تواند باعث عملیات زنجیره‌ای زمان‌بندی و اتصال شود.

در نتیجه، پلاگین CSI در حال حاضر متوقف شده است. راه حل این مشکل نیازمند یک تلاش مهندسی در تمام لایه‌ها (Full-stack) است تا قابلیت اتصال گرم (Hot-plugging) دیسک از هایپروایزر تا API پیاده‌سازی شود. این تغییر نشان‌دهنده فلسفه اصلی پروژه Oxide است: وقتی یک ادغام Kubernetes شکست می‌خورد، راه حل همیشه یک لایه نرم‌افزاری واسط (Shim) نیست. گاهی اوقات، این امر مستلزم تغییر در نحوه مدیریت منابع توسط سخت‌افزار و هایپروایزر است.

نقشه راه آینده و اکوسیستم

شرکت Oxide به‌جای یک ادغام واحد، به سمت یک اکوسیستم کامل حرکت می‌کند. زیربنای فعلی شامل Rancher، Omni و CAPOx برای ایجاد خوشه است و CCM خدمات مشترک زمان اجرا را فراهم می‌کند. تیم اکنون در حال گسترش استفاده داخلی (Dogfooding) با ارائه‌دهنده Cluster API است تا عملیات روزمره را آزمایش کند.

اهداف کوتاه‌مدت عبارتند از:

• تکمیل قابلیت Hot-plug دیسک و عرضه پلاگین بومی CSI.
• افزودن پشتیبانی از مقیاس‌پذیری خودکار (Autoscaling).
• گسترش کنترل‌کننده سرویس CCM برای پشتیبانی از زیرشبکه‌های خارجی.

برنامه‌های بلندمدت شامل گسترش ادغام‌های Kubernetes برای بهره‌مندی از ویژگی‌های آتی پلتفرم، از جمله برچسب‌گذاری منابع (Resource Tagging)، پشتیبانی از OIDC و Load Balancing بومی است. هنگامی که یک سرویس Load-balancing بومی معرفی شود، کنترل‌کننده سرویس CCM به‌روزرسانی خواهد شد و به مشتریان اجازه می‌دهد سرویس‌های LoadBalancer موجود خود را حفظ کنند در حالی که زیرساخت زیرین تغییر می‌کند.

این کار نشان می‌دهد که چگونه معماری‌های Kubernetes و Oxide مکمل یکدیگر هستند. Kubernetes نقاط اتصال استاندارد را فراهم می‌کند و Oxide ابزارهای اولیه API را ارائه می‌دهد. با تلقی کردن اصطکاک مشتریان به عنوان سیگنالی برای بهبود محصول، Oxide به اصلاح SDKها و APIهای خود از دیدگاه کاربر ادامه می‌دهد. این حلقه بازخورد روشی است که اکوسیستم از طریق آن به رشد خود ادامه خواهد داد.

برای مشاهده ادغام‌های Cluster API و CCM در حین حرکت به سمت آمادگی کامل برای تولید، ویدئوی رسمی استقرار را تماشا کنید.