وقتی Kubernetes را در مقیاس تیمهای آمازون بر بستر Amazon EKS اجرا میکنید، گرهها مدام دچار مشکل میشوند. GPUها از گذرگاه PCIe جدا میشوند، runtime کانتینر قفل میکند، و رابطهای شبکه ناپدید میشوند. در میان دهها هزار خوشه، خرابیهای «نادر» سختافزاری چندین بار در روز در جایی از ناوگان روی میدهد.
برای سالها، واکنش همه یکسان بود: اپراتور بیدار میشود، داشبورد را باز میکند، SSH میزند، گره را cordon و drain میکند، نمونه را خاتمه میدهد و منتظر جایگزین میماند. هر مرحله با سرعت انسانی انجام میشود و هر کدام toil محسوب میشود. اگر خرابی ساعت ۳ بامداد آخر هفته رخ دهد، workload تا ساعتها افت کیفیت را تحمل میکند.
برای پر کردن این شکاف، تیم آمازون EKS Node Monitoring Agent را ساختند که در آوریل ۲۰۲۵ به صورت متنباز منتشر شد. این عامل خرابیهای گره را تشخیص میدهد و NodeConditions کوبرنتیز را مینویسد که مشکل را به Karpenter اطلاع میدهد تا در صورت نیاز به طور خودکار گره جایگزین شود. این عامل بخشی از یک سیستم بزرگتر است و برای درک جایگاه آن باید بدانید چه چیزی گرهها را مدیریت میکند.
«در دهها هزار خوشه، خرابیهای «نادر» سختافزاری چندین بار در روز، در جایی از ناوگان اتفاق میافتد.»
Amazon EKS Auto Mode زیرساخت خوشه را به طور کامل خودکار میکند: تأمین محاسبات، مقیاسدهی، شبکه، ذخیرهسازی، وصله سیستمعامل و hardening امنیتی، تا تیمها روی برنامهها تمرکز کنند. این سرویس به طور پویا نمونههای بهینه EC2 (از جمله نمونههای GPU خانواده P5، P6 و G6) را انتخاب میکند. EKS Auto Mode با تعمیر خودکار گره به عنوان رفتار پیشفرض عرضه میشود: تشخیص، طبقهبندی شدت و جایگزینی مبتنی بر Karpenter، همه بدون نیاز به نصب add-on یا پیکربندی controller اجرا میشوند.
شش درس ساخت گرههای خوددرمان Kubernetes در مقیاس
پس از عملیات روی هزاران خوشه، درسها به یک لیست کوتاه تبدیل شدهاند. این الگوها مختص سیستم آمازون نیستند و در NPD، NVSentinel، AKS Periscope و auto-repair GKE نیز دیده میشوند.
۱. reason codes یک API contract هستند
هر مصرفکننده پاییندستی (تعمیر controllerها، داشبوردها، اتوماسیون مشتری) با تطابق رشته literal به reason codes key میخورد. اضافهکردن reason code یک feature است، اما تغییر نام یا تغییر severity یک breaking change محسوب میشود. برای آنها همانطور که برای versioning API برنامهریزی میکنید، برنامهریزی کنید.
۲. Absent و Unknown یکسان نیستند
«ما تماشا نمیکنیم» و «ما تماشا میکنیم اما نمیتوانیم تشخیص دهیم» پاسخهای متفاوتی از اتوماسیون پاییندستی نیاز دارند. اگر monitor غیرفعال شما مقدار Unknown بنویسد، جایی controller روی آن اقدام میکند. وقتی تماشا نمیکنید، چیزی emit نکنید.
۳. از مرزهای مالکیت عبور نکنید
kubelet مالک شرایط مبتنی بر workload است و agent سلامت گره مالک خرابیهای سختافزاری و زیرساخت. عبور از این مرز باعث میشود سیستم تعمیر شما با سیستم eviction kubelet بجنگد و یکی از آنها تصمیم اشتباه بگیرد.
۴. تأخیر را از منبع اندازه بگیرید
SLO تشخیص شامل هر hop در زنجیره سیگنال است: رویداد سختافزاری به log درایور، log درایور به journald، journald به poll agent، و poll agent به نوشتن NodeCondition. طولانیترین hop غالب است. برای سیگنالهای سطح هسته، cadence flush journald گلوگاه است. برای تلهمتری GPU از طریق DCGM، تخلفات مبتنی بر push (DBE، XID، NVLink) تقریباً فوری هستند اما watches polled میدانی (سلامت fabric NVSwitch، throttle ساعت) یک کف ۵ دقیقهای دارند. بدانید هر تشخیص از کدام مسیر استفاده میکند.
۵. نویز پاییندستی را با ثبات جذب کنید
تشخیصدهندهها ذاتاً پرنویز هستند. GPU ممکن است یک XID 48 مقطعی از I2C bus error بدهد و سپس ده دقیقه پایدار کار کند. اگر agent هر XID را بلافاصله به NodeCondition تبدیل کند، Karpenter یک گرم جابجایی غیرضروری برای هر نویز انجام میدهد. طراحی آمازون از یک پنجرهی جذب با آستانه استفاده میکند: یک کانتر درون-فرآیند نگه میدارد و فقط زمانی که خطا در TTL آستانه باقی میماند، NodeCondition را مینویسد. این تکنیک از جابجاییهای توخالی جلوگیری میکند و تأخیر تشخیص خرابی واقعی را افزایش نمیدهد.
۶. jitter را پیادهسازی کنید تا تداخل workload GPU کاهش یابد
nvidia-smi و DCGM ابزارهای حساسی هستند. وقتی هزاران agent در fleet همزمان polling میکنند، workloadهای GPU روی گرههای همسایه دچار لرزشهای تأخیر میشوند. راهحل ساده است: در agent یک jitter تصادفی (تا ۳۰٪ از بازهی polling) به هر چرخه اضافه کنید. این کار بار را در طول زمان پخش میکند و تأثیرات رزونانسی را کاهش میدهد.
جمعبندی: ساخت خوددرمانی واقعی نیاز به طراحی دقیق دارد
تعمیر خودکار گرههای GPU در Kubernetes، خصوصاً در مقیاس ابری، چالشهای متعددی دارد که فراتر از یک agent ساده است. تیم آمازون با انتشار متنباز EKS Node Monitoring Agent این درسها را در اختیار جامعه قرار داده است. اگر به دنبال پیادهسازی سیستمی مشابه هستید، به API contractها، مرزهای مالکیت kubelet، و jitter کردن polling برای جلوگیری از تداخل workload توجه کنید.
