ردیابی علت تعلیق Jobهای Kubernetes با افزونه Kueue در Headlamp

به گزارش وبلاگ Kubernetes، افزونه Kueue برای Headlamp مسیر بررسی Jobهای معلق را به رابط گرافیکی این ابزار آورده است. نسخه 0.1.0-alpha به مدیران زیرساخت کمک میکند پیش از جستوجوی خطا در Podها، مشخص کنند آیا Kueue اصلاً Workload را برای استفاده از منابع پذیرفته است یا خیر.
تفکیک پذیرش Workload از زمانبندی Pod
در کلاسترهای تحت مدیریت Kueue، ایجادنشدن Pod یا نبود لاگ برنامه لزوماً نشانه اختلال در زمانبند Kubernetes نیست. Kueue ابتدا با توجه به سیاست صف، سهمیه منابع، ResourceFlavor، بررسیهای پذیرش و Workloadهای منتظر تصمیم میگیرد که اجرای یک Job مجاز است یا باید همچنان معلق بماند.
افزونه جدید، وضعیت Workload و شرطهای مهمی مانند Admitted و QuotaReserved را در Headlamp نمایش میدهد. اگر Admitted=True باشد، مرحله پذیرش انجام شده و ادامه عیبیابی باید در نماهای Job و Pod و رویدادهای زمانبند انجام شود. در مقابل، مقدار false برای QuotaReserved یا وضعیت Inadmissible میتواند از کمبود سهمیه، توقف صف، نبود ResourceFlavor مناسب یا یک admission check حلنشده خبر دهد.
کاربر میتواند از صفحه Workload، درخواست تجمیعی CPU و حافظه را بررسی کند و سپس ارتباط آن را با LocalQueue، ClusterQueue، ResourceFlavor و Cohort دنبال کند. این زنجیره مشخص میکند Job وارد کدام صف شده، چه ظرفیتی در اختیار آن است و آیا امکان استفاده از سهمیه مشترک وجود دارد.
نمای خواندنی با محدودیتهای نسخه آلفا
در نمونه ارائهشده، یک Job دارای سه Pod است و هر Pod یک CPU درخواست میکند؛ بنابراین Workload در مجموع به سه CPU و سه جایگاه Pod نیاز دارد. ClusterQueue فقط دو CPU و دو جایگاه ارائه میکند و Kueue به همین دلیل Job را تا آزادشدن سهمیه یا تغییر تنظیمات معلق نگه میدارد. این وضعیت مسئله ظرفیت پذیرش است، نه شاهدی از شکست kube-scheduler.
نسخه 0.1.0-alpha صرفاً نماهای خواندنی برای منابع Kueue v1beta2 فراهم میکند و گردشکار مستقلی برای ساخت، ویرایش، توقف، ادامه یا حذف ندارد. دسترسی به اطلاعات نیز تابع مجوزهای هویت Kubernetes در Headlamp است. برای تیمهای زیرساخت ابری، مزیت اصلی این افزونه کوتاهکردن مسیر تشخیص و کاهش نیاز به مرور چند فرمان و فایل YAML بزرگ است؛ هرچند ابزارهای خط فرمان برای اسکریپتها، GitOps و مشاهده دقیق اشیا همچنان جایگاه خود را دارند.
در نتیجه، نقطه شروع مناسب برای Job معلق این است: ابتدا وضعیت پذیرش Kueue بررسی شود؛ تنها پس از پذیرش Workload باید علت Pending ماندن Podها در سطح نود، ذخیرهسازی، affinity، taint یا دریافت ایمیج جستوجو شود.



