معماری Orbit وقتی از یه خوشه بیشتر داری
خلاصهٔ کاملتر
این پست، قسمت آخر یه سری فنی دربارهٔ Orbit ـه؛ یه مدیر خوشه (cluster manager) که نویسندهش از صفر نوشته. سؤال این قسمت اینه: وقتی از یه Constellation — یعنی یه خوشه با چند ده هزار ماشین، لجر، زمانبند و هویت — بیشتر داری، چی بالاسرشون میشینه؟ به گفتهٔ نویسنده، Kubernetes و Borg دو جواب کاملاً متضاد به این سؤال دادن و همین تضاد، طراحی این لایه رو شکل داده.
کوبرنتیز خوشه رو واحد مقیاس گرفت، پس تا از یکی بیرون بزنی باید چندتا اجرا کنی و بعد یه اکوسیستم federation بهش بچسبونی تا مثل یکی رفتار کنن؛ استقلال خوشهها مجانی به دست میاد و هزینهش رو تو هماهنگی میدی. Borg برعکس رفت و خود cell رو بزرگتر کرد و فقط برای محدود نگهداشتن blast radius براش سقف گذاشت. نویسنده میگه Orbit هر دو چیزی رو میخواد که با هم در تنشان: جداسازی سخت، و بهینهسازی در سطح کل ناوگان.
راه رسیدن به هر دو، یه قاعدهٔ کوتاهه: لایهٔ Fleet حق داره توصیه کنه، ولی حق دستور دادن نداره. منطقش روشنه؛ اگه یه خوشه بدون این لایه نتونه کار بپذیره یا زمانبندی کنه، همون لایه تبدیل میشه به یه نقطهٔ شکست واحد که کل ناوگان رو میگیره — دقیقاً همون ریسک همبستهٔ خرابی که سقفگذاشتن روی اندازهٔ cell قرار بود جلوش رو بگیره. خود اینترفیس هم طوری نوشته شده که این محدودیت تو چشم باشه:
pub trait FleetPlane: Send + Sync {
async fn register(&self, summary: ConstellationSummary) -> Result<(), FleetError>;
async fn placement_hint(&self, needs: &ResourceVec) -> Result<Option<PlacementHint>, FleetError>;
async fn record_consumption(&self, constellation: &str, amount: &ResourceVec) -> Result<(), FleetError>;
}هیچ متدی اینجا نیست که یه capsule رو جایی بذاره، چیزی تو لجر خوشه commit کنه، یا جلوی کار کردن خوشه رو بگیره. چیزی که بالا میره خلاصه و میزان مصرفه، و چیزی که پایین میاد فقط یه hint ـه. خود خوشهها هم از بالا فقط به شکل یه ساختار خلاصه دیده میشن: ظرفیت، مصرف، تعداد نود، تعداد ماموریت و یه فیلد سلامت با سه حالت Healthy و Degraded و Unreachable. همون فیلد سلامت، ابزار توزیع بار هم هست: خوشهٔ خراب یا غیرقابلدسترس اصلاً واجد شرایط کار جدید نیست.
تنها «هوشمندی» این لایه، پیشنهاد جایگذاریه: بین خوشههای سالمی که ظرفیت کافی دارن، اونی که کمترین بهرهبرداری رو داره برمیگردونه، همراه با یه امتیاز و یه دلیل قابلخوندن. نکته اینه که خروجی یه پیشنهاد با توجیهه، نه یه فرمان: کلاینت میتونه نپرسه، و اگه این لایه قطع باشه یه خوشه رو جور دیگه انتخاب میکنه و کارش رو راه میندازه.
سهمیهٔ سراسری هم عمداً از مسیر بحرانی بیرون نگه داشته شده. نویسنده تأکید میکنه که سهمیهٔ معتبر و قابلاتکا همون تعهد per-Constellation روی لجر خوشهست که خطیپذیره و پذیرش کار رو واقعاً کنترل میکنه؛ چیزی که تو لایهٔ Fleet میشینه یه تجمیع نهایتاً سازگاره برای برنامهریزی. هزینهش رو هم پنهون نمیکنه: یه تیم ممکنه چند لحظه از بودجهٔ کلیش رد بشه تا تجمیع خودش رو برسونه. برای «یه تیم کل ناوگان رو قحطیزده نکنه» این کافیه، برای سقف سخت صورتحساب نه.
بخش صادقانهٔ پست هم همینه که این لایه کمساختهترین بخش سیستمه و عمداً آخر از همه ساخته شده. چیزی که وجود داره یه پیادهسازی مرجع درونحافظهای، سرویس gRPC دورش و تایپهای سهمیه و خلاصهست؛ چیزی که نازکه، یکپارچگیه. نویسنده معتقده عمیقترین ریسک اینجا کد نیست، انضباطه: «فقط توصیهای» یه خاصیته که باید فعالانه ازش دفاع کنی، چون همیشه یه فیچر وسوسهکننده هست که آروم این لایه رو حیاتی میکنه و تا روز بد اولش نمیفهمی چی شده.
نکات کلیدی:
- لایهٔ Fleet فقط ثبت خلاصه، تجمیع مصرف و پیشنهاد جایگذاری انجام میده؛ هیچ متد دستوری نداره
- هر Constellation یه دامنهٔ خرابی سخته و باید بدون لایهٔ بالا هم کامل کار کنه
- خوشه از بالا فقط به شکل خلاصه دیده میشه؛ نگهداشتن جزئیات کامل، همون اشتباه etcd تو مقیاس بزرگتره
- فیلد سلامت، مبنای واجد شرایط بودن برای کار جدیده
- سهمیهٔ سراسری نهایتاً سازگاره: تبادل عمدی دقت جهانی با دسترسپذیری
- ریسک اصلی فنی نیست؛ نگهداشتن این لایه در حالت توصیهای یه انتخاب همیشگیه
