من Kube Eagle را ایجاد کردم - یک صادرکننده پرومتئوس. معلوم شد که این چیز جالبی است که به درک بهتر منابع خوشه های کوچک و متوسط کمک می کند. در پایان، من صدها دلار صرفه جویی کردم زیرا انواع ماشین های مناسب را انتخاب کردم و محدودیت های منابع برنامه را برای بارهای کاری پیکربندی کردم.
من از مزایای آن به شما خواهم گفت ، اما ابتدا توضیح خواهم داد که چه چیزی باعث سر و صدا شد و چرا نظارت با کیفیت بالا مورد نیاز بود.
من چندین خوشه از 4 تا 50 گره را مدیریت کردم. هر خوشه حاوی 200 میکروسرویس و برنامه است. برای استفاده بهتر از سخت افزار موجود، بیشتر استقرارها با منابع RAM و CPU قابل انفجار پیکربندی شدند. به این ترتیب، پادها می توانند در صورت لزوم منابع موجود را بگیرند و در عین حال با سایر برنامه های این گره تداخل نداشته باشند. خوب، عالی نیست؟
و اگرچه خوشه نسبتاً CPU (8٪) و RAM (40٪) مصرف می کرد، ما دائماً با مشکلاتی در مورد استفاده از پادها در هنگام تلاش برای تخصیص حافظه بیشتر از آنچه در گره بود، داشتیم. در آن زمان ما فقط یک داشبورد برای نظارت بر منابع Kubernetes داشتیم. مثل این:
داشبورد Grafana فقط با معیارهای cAdvisor
با چنین پنلی، دیدن گره هایی که حافظه و CPU زیادی مصرف می کنند، مشکلی نیست. مشکل این است که بفهمیم دلیل آن چیست. برای نگه‌داشتن غلاف‌ها در جای خود، می‌توان منابع تضمین‌شده را روی همه پادها تنظیم کرد (منابع درخواستی برابر با حد مجاز). اما این هوشمندانه ترین استفاده از سخت افزار نیست. این خوشه چند صد گیگابایت حافظه داشت، در حالی که برخی از گره ها گرسنه بودند، در حالی که برخی دیگر 4 تا 10 گیگابایت در ذخیره داشتند.
به نظر می رسد که زمانبندی Kubernetes بارهای کاری را به طور نابرابر در منابع موجود توزیع کرده است. زمانبندی Kubernetes پیکربندی‌های مختلفی را در نظر می‌گیرد: قوانین وابستگی، لکه‌ها و تحمل‌ها، انتخابگرهای گره که می‌توانند گره‌های موجود را محدود کنند. اما در مورد من چیزی شبیه به آن وجود نداشت و پادها بسته به منابع درخواستی در هر گره برنامه ریزی شده بودند.
گرهی که بیشترین منابع رایگان را دارد و شرایط درخواست را برآورده می کند برای پاد انتخاب شد. ما متوجه شدیم که منابع درخواست شده روی گره ها با استفاده واقعی مطابقت ندارد و اینجاست که Kube Eagle و قابلیت های نظارت بر منابع آن به کمک آمدند.
من تقریباً همه خوشه‌های Kubernetes را فقط با آنها نظارت دارم и . Node Exporter آماری در مورد استفاده از ورودی/خروجی و دیسک، CPU و RAM ارائه می‌کند، در حالی که Kube State Metrics معیارهای شی Kubernetes مانند درخواست‌ها و محدودیت‌های منابع CPU و حافظه را نشان می‌دهد.
ما باید معیارهای استفاده را با معیارهای درخواست ها و محدودیت ها در گرافانا ترکیب کنیم و سپس تمام اطلاعات مربوط به مشکل را به دست خواهیم آورد. این ساده به نظر می‌رسد، اما این دو ابزار در واقع برچسب‌ها را متفاوت نام‌گذاری می‌کنند، و برخی از معیارها اصلاً برچسب متادیتا ندارند. Kube Eagle همه کارها را خودش انجام می دهد و پنل به شکل زیر است:
ما موفق به حل بسیاری از مشکلات با منابع و صرفه جویی در تجهیزات شدیم:
- برخی از توسعه‌دهندگان نمی‌دانستند که میکروسرویس‌ها به چند منبع نیاز دارند (یا به سادگی زحمت نمی‌کشند). هیچ راهی برای یافتن درخواست های نادرست برای منابع وجود نداشت - برای این ما نیاز به دانستن مصرف به اضافه درخواست ها و محدودیت ها داریم. اکنون آنها معیارهای Prometheus را می بینند، استفاده واقعی را نظارت می کنند و درخواست ها و محدودیت ها را تنظیم می کنند.
- برنامه های JVM تا جایی که می توانند RAM مصرف می کنند. زباله جمع کن تنها زمانی حافظه را آزاد می کند که بیش از 75 درصد استفاده شود. و از آنجایی که اکثر سرویس ها دارای حافظه انفجاری هستند، همیشه توسط JVM اشغال می شد. بنابراین، تمام این سرویس‌های جاوا رم بسیار بیشتری از حد انتظار مصرف می‌کردند.
- برخی از برنامه‌ها حافظه زیادی درخواست می‌کنند و زمانبندی Kubernetes این گره‌ها را به برنامه‌های دیگر نمی‌دهد، حتی اگر در واقع آزادتر از سایر گره‌ها بودند. یکی از توسعه دهندگان به طور تصادفی یک رقم اضافی به درخواست اضافه کرد و یک قطعه رم بزرگ برداشت: 20 گیگابایت به جای 2. هیچ کس متوجه نشد. برنامه دارای 3 کپی بود، بنابراین 3 گره تحت تأثیر قرار گرفتند.
- محدودیت‌های منابع را معرفی کردیم، غلاف‌ها را با درخواست‌های صحیح مجدداً برنامه‌ریزی کردیم، و تعادل ایده‌آلی در استفاده از سخت‌افزار در همه گره‌ها به دست آوردیم. ممکن بود چند گره به طور کامل بسته شوند. و سپس دیدیم که ماشین‌های اشتباهی داشتیم (CPU گرا، نه حافظه گرا). ما نوع را تغییر دادیم و چندین گره دیگر را حذف کردیم.
نمایش نتایج: از
با منابع انفجاری در خوشه، از سخت‌افزار موجود به‌طور کارآمدتر استفاده می‌کنید، اما زمانبندی Kubernetes بر اساس درخواست‌ها برای منابع، پادها را زمانبندی می‌کند، و این مشکل است. برای کشتن دو پرنده با یک سنگ: برای جلوگیری از مشکلات و استفاده کامل از منابع، نیاز به نظارت خوب دارید. به همین دلیل مفید خواهد بود (صادر کننده پرومتئوس و داشبورد گرافانا).
منبع: www.habr.com