مانیتوریگ و نگهداری کلاستر ابری کوبرنتیز

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

در این میان، نه تنها پلتفرم کوبرنتیز پرطرفدار است، بلکه پلتفرمی است که استقرار (روز 1) و مدیریت آن (روز 2 عملیات) سخت و غیر ضروری است. یکی از وعده‌های پلتفرم‌های ارکستراسیون کانتینر این است که توسعه‌دهندگان را برای تسریع در استقرار برنامه‌های خود بدون نگرانی در مورد مقیاس‌پذیری و وابستگی‌های زیرساخت آسان‌تر کنند. اما هزینه ای برای پرداخت وجود دارد و آن پیچیدگی و بار فزاینده برای تیم های عملیاتی مسئول مدیریت پلتفرم است. اگرچه کوبرنتیز به شدت خودکار است و خود درمانی انجام می‌دهد اما به صورتی نیست که شما آن را رها کنید و اجازه دهید به تنهایی اجرا شود. خرابی در یکی از اجزای کلاستر می‌تواند تمام برنامه‌های در حال اجرا روی آن را از کار بیندازد. 

چرا باید منابع کوبرنتیز را مدیریت کنید؟

کلاسترها منابع نامحدودی ندارند و به طور کلی، این یک سناریوی معمولی نیست که هر برنامه یا راه حلی کلاستر کوبرنتیز خاص خود را داشته باشد، مگر اینکه خیلی خاص باشند و قرار باشد به ترتیب مشخصی اجرا شوند.

این بدان معناست که برنامه ها معمولاً منابع تلفیقی را به اشتراک می گذارند. روش درست برای تخصیص این منابع در سازمان‌ها و برنامه‌های کاربردی متفاوت است، اما خبر خوب این است که کوبرنتیز دارای ویژگی‌های زیادی برای مدیریت منابع است.

تام منویل، سرپرست مهندسی در Kasten می گوید: «Kubernetes را می توان در هر جایی مستقر کرد، اما این بدان معناست که زیرساخت مورد نیاز برای محیط شما منحصر به فرد خواهد بود. درک منابع مورد نیاز در محیط خود و تخصیص مناسب آنها بسیار مهم است. همانطور که خوشه شما مقیاس می شود، زیرساخت شما نیز باید مقیاس شود. خوشبختانه، گسترش اندازه خوشه آسان است و در بسیاری از موارد، این می تواند به طور خودکار اتفاق بیفتد.»

اهمیت مدیریت منابع

• تضمین می کند که برنامه‌های شما منابع کافی برای اجرای روان و دستیابی به اهداف عملکرد خود را دارند.

• از مصرف منابع بیشتر از نیاز برنامه‌های شما جلوگیری می‌کند، که می‌تواند بر سایر برنامه‌ها تأثیر بگذارد یا باعث کمبود منابع شود.

• کوبرنتیز را قادر می سازد تا بر اساس منابع مورد نیاز و در دسترس بودن برنامه‌ها و نودهای شما تصمیمات زمان بندی اتخاذ کند.

• به شما امکان می‌دهد تا با بهینه سازی استفاده از منابع و تخصیص کلاستر خود، هزینه و کارایی زیرساخت خود را کنترل کنید.

نظارت بر کوبرنتیز یک جنبه مهم از عملیات روز دوم است و اغلب به عنوان یک چالش مهم تلقی می‌شود. بیایید به برخی از موارد استفاده از عملیات روز 2 نگاه کنیم.

مدیریت استفاده از منابع

یکی از اصول طراحی کوبرنتیز این است که همیشه به بهینه سازی استفاده از منابع محاسباتی بر اساس ورکلودها نگاه کنیم. این به صورت جادویی اتفاق نمی افتد. ما باید اطمینان حاصل کننیم که منابع کافی در کلاستر برای استقرار برنامه‌های جدید، مقابله با افزایش تقاضا یا خرابی نودها وجود دارد و در عین حال از تأثیرات بر ورکلودهای موجود جلوگیری می‌کند.

به طور پیش فرض، کانتینرها با محدودیت‌های نامحدود اجرا می شوند. یک کانتینر (یا یک pod) که روی یک نود اجرا می شود ممکن است تمام CPU یا حافظه موجود را استفاده کند و بر روی سایر پادهای روی نود تأثیر بگذارد، عملکرد را کاهش دهد (یا بدتر) و مانع از برنامه ریزی ورکلود جدید در نود شود. اگر منابع نودها تمام شود، کوبرنتیز ممکن است شروع به حذف پادها یا برنامه ها کند. یک کانتینر با کد ناکارآمد ممکن است بر ورکلودهای حیاتی تأثیر بگذارد و عملاً کل نود را غیرقابل استفاده کند، یا بدتر از آن، به دلیل تکرار، می تواند کل کلاستر را تحت تأثیر قرار دهد. اگر به‌درستی استفاده از منابع را در کلاستر خود کنترل نکنید، به‌طور اجتناب‌ناپذیری با افزایش ورکلود با مشکلاتی مواجه خواهید شد.

مکانیزمی که کوبرنتیز برای جلوگیری از چنین مشکلاتی در اختیار اپراتورهای پلتفرم قرار می‌دهد، با تعریف سهمیه منابع و اعمال درخواست‌ها و محدودیت‌ها است. درخواست ها حداقل منابعی هستند که یک کانتینر برای اجرا نیاز دارد. از سوی دیگر، محدودیت ها حداکثر منابعی هستند که یک کانتینر مجاز به استفاده از آن است. پس از رسیدن به حد مجاز، کوبرنتیز اقداماتی را انجام می دهد که به نوع منبع بستگی دارد. تنظیمات درخواست و محدودیت توسط Kubernetes برای اختصاص دادن یک کلاس QoS (کیفیت خدمات) به پادها استفاده می شود. وقتی یک نود بیش از حد متعهد می شود و منابعش تمام می شود، کلاس QoS pod روی زمان بندی خارج کردن یک نود یا اولویت تخلیه (که اول پاد خارج می شود) تأثیر خواهد داشت.

همانطور که پیش‌تر شد، CPU یک منبع فشرده است. همیشه می‌توانید برش‌های زمان CPU کمتر یا کوتاه‌تری را به یک فرآیند اختصاص دهید. بنابراین هنگامی که به حد مجاز رسید، Kubernetes کانتیر را محدود نمی‌کند، اما کاهش می‌دهد، یعنی کندتر کار می‌کند و به طور بالقوه بر عملکرد (و برنامه مرتبط) تأثیر می‌گذارد.

بدیهی است که حافظه ماهیتی متفاوت دارد. برخلاف CPU، قابل تراکم نیست. هنگامی که یک کانتینر حافظه را تخصیص داد، نمی توان آن را بازیابی کرد مگر اینکه توسط خود کانتینر آزاد شود. بنابراین برای محافظت از نود و سایر پادهای در حال اجرا بر روی آن، اگر یک کانتینر حافظه بیش از حد خود را تخصیص دهد، محدود می‌شود (به عنوان "OOMKilled" یا Out of Memory Killed نامیده می شود).

این به شما تصویری از اهمیت مدیریت صحیح استفاده از منابع برای عملیات Kubernetes می‌دهد. شما می‌خواهید مطمئن شوید که هیچ استقراری نمی‌تواند نودها را پایین بیاورد و بر ورکلودهای حیاتی تجاری تأثیر بگذارد. همچنین می‌خواهید تضمین کنید که این ورکلودها زمانی که مستقر می‌شوند، برنامه‌ریزی می‌شوند و به نفع پادهای کمتر بحرانی خارج نمی‌شوند. البته، ممکن است فکر کنید، Kubernetes دارای قابلیت مقیاس‌بندی خودکار است، پس چرا باید در مورد منابع خود را مشغول کنم؟ خوب، درک هزینه های اجرای پلتفرم، بهینه سازی استفاده و جلوگیری از خارج شدن از کنترل این هزینه ها، وظیفه تیم عملیاتی است.

به طور معمول، ادمین‌های پلتفرم مرزهای منطقی را در کوبرنتیز ایجاد می‌کنند که در آن ورکلودها اجرا می‌شوند که به نام فضاهای نام شناخته می‌شوند. سپس می‌توانند ResourceQuotas را برای هر Namespace تعریف کنند، که مشخص می‌کند چه مقدار CPU و حافظه پادها را می‌تواند در فضای نام درخواست کند. با ResourceQuotas، تیم‌های توسعه باید درخواست‌ها و محدودیت‌های منابع را برای پادهای خود مشخص کنند، در غیر این صورت، برنامه‌ریزی نمی‌شوند. این امر سیاست های استفاده از منابع، محافظت از کلاستر و ورکلود را اعمال می کند. چگونه سهمیه مناسب را پیدا کنیم، چه چیزی باید به عنوان درخواست و محدودیت CPU یا Memory استفاده شود؟ این مثال دیگری است که در آن نظارت کمک بزرگی می کند زیرا تصویر مصرف منابع فعلی را ارائه می دهد و به تنظیم مداوم آن تنظیمات کمک می کند.

نحوه برنامه ریزی پادها با درخواست منابع

هنگامی که یک Pod ایجاد می کنید، زمانبندی کوبرنتیز یک نود را برای اجرای پاد انتخاب می کند. هر گره دارای حداکثر ظرفیت برای هر یک از انواع منابع است: مقدار CPU و حافظه ای که می تواند برای پادها فراهم کند. زمان‌بند اطمینان می‌دهد که برای هر نوع منبع، مجموع درخواست‌های منبع کانتینرهای زمان‌بندی‌شده کمتر از ظرفیت گره است. توجه داشته باشید که اگرچه استفاده واقعی از حافظه یا منبع CPU در نودها بسیار کم است، اما اگر بررسی ظرفیت ناموفق باشد، زمانبند همچنان از قرار دادن پاد روی گره خودداری می کند. هنگامی که استفاده از منابع بعداً افزایش می یابد، به عنوان مثال، در زمان اوج روزانه در نرخ درخواست، این امر در برابر کمبود منبع در یک نود محافظت می کند.

سلامت نود و ورکلود

استفاده از منابع یکی از جنبه هایی است که بر سلامت کلاستر و ورکلود شما تأثیر می گذارد. اما موارد بسیار دیگری نیز وجود دارد.

برای درک آنچه در جریان است، باید چرخه حیات اشیاء k8s خود (پادها، سرویس‌ها، نودها) و رویدادهای مرتبط را نیز مشاهده کنید.

شما می خواهید بتوانید درک کنید:

• کدام نودها و پادها ناسالم هستند و چرا.

• چرا تعداد فعلی کپی‌های پاد شما با وضعیت مورد نظر مطابقت ندارد.

• چند بار کانتینرها توسط کوبرنتیز راه اندازی مجدد می شوند و چرا.

• کدام پادها را نمی توان برای یک نود برنامه ریزی کرد و کدام یک از یک نود خارج شده اند.

• چه وقتی کوبرنتیز مقیاس خودکار (بالا/پایین) را انجام می‌دهد و روی چه چیزی.

برای این موارد، علاوه بر معیارهای استفاده از منابع، باید رویدادهای کلاستر و معیارهای وضعیت شی را نظارت کنید.

رویدادهای کوبرنتیز نوعی شیء هستند که زمینه را در مورد آنچه در داخل یک کلاستر اتفاق می‌افتد فراهم می‌کنند. نمونه‌هایی از چنین رویدادهایی عبارتند از: زمانی که یک نود در حال اتمام منابع است، یک پاد OOM از بین می‌رود، یک تصویر کانتینر نمی‌تواند از رجیستری خارج شود، زنده بودن پاد یا آمادگی خرابی‌های پراب، زمان‌بندی، و فعالیت‌های تکرار، یا بیرون راندن پاد از یک نود.

اشیاء رویداد، رویدادهای گزارش معمولی نیستند. آنها توسط سرور API تولید می شوند و در گزارش های تولید شده توسط کلاستر گنجانده نمی شوند. اما آنها برای عملیات پلتفرم بسیار ارزشمند هستند، زیرا معمولاً یکی از اولین چیزهایی هستند که وقتی مشکلی با ورکلود پیش می‌آید به آن نگاه می‌کنید. از آنجایی که هیچ گونه سابقه نگهداری طولانی مدت و مکانیسم داخلی برای ارسال آنها به حافظه خارجی وجود ندارد، باید مطمئن شوید که راه حل نظارتی شما به طور مداوم آنها را جمع آوری می کند و آنها را برای تجزیه و تحلیل پس از مشکل، به مدت طولانی ذخیره می کند.

بسیاری از رویدادهای مربوط به پادها باعث تغییر حالت در چرخه حیات شی می شود که در طی آن می توان با انواع مختلفی از مسائل مواجه شد. یک پاد سالم باید در حالت "آماده" باشد. در طول چرخه عمر خود، حالت های مختلفی را پشت سر می گذارد، اما اگر در یکی از آنها گیر کند، به طور کلی نشان دهنده وجود یک مشکل است. به عنوان مثال، اگر نمی‌توان یک پاد را برای اجرا در هر نودی برنامه‌ریزی کرد زیرا منابع کافی در دسترس نیست، ممکن است در حالت «در انتظار» گیر کند. اگر برنامه ریزی شده باشد اما تصاویر کانتینر را نتوان از رجیستری بیرون کشید، در حالت "انتظار" گیر می کند. وقتی یک پاد به دلیلی خراب می شود، دوباره راه اندازی می شود. اگر بارها و بارها خراب شود، در نهایت در حالت "CrashloopBackOff" قرار می گیرد و باید نگاهی به زنجیره رویدادها بیندازید تا بفهمید چرا در آن حالت قرار دارد. ممکن است مشکل از کد برنامه باشد، همچنین ممکن است یک پراب فعال که پیکربندی نادرست داشته باشد یا چیز دیگری باشد.

همانطور که می بینید، پیگیری و نظارت بر وضعیت های شی مهم است تا بفهمید که مشکلات مربوط به ورکلود شما از کجا ممکن است ناشی شود.

نظارت در جهان کوبرنتیز

کوبرنتیز یک سیستم پیچیده است، نظارت بر چنین محیطی مستلزم مجموعه ای متفاوت از قابلیت ها نسبت به استک‌های کلاسیک است. از این رو، تعجب آور نیست که ببینیم، طبق نظرسنجی CNCF 2019، پیچیدگی (38٪) و نظارت (32٪) در بین 5 چالش برتر در استفاده، استقرار و مدیریت کانتینرها رتبه بندی می شوند.

در استراتژی نظارت خود، باید رویکردی جامع و نمای واحد را در نظر بگیرید:

نظارت بر برنامه ورکلودها: به دلیل ماهیت پویا، پیچیده، چند زبانه و پراکنده ورکلود، اتوماسیون یک امر ضروری است: کشف خودکار خدمات و وابستگی ها، ابزار دقیق خودکار و ردیابی توزیع شده، دید عمیق خودکار. تکیه بر پیکربندی‌های دستی دستوری برای شکست است.

نظارت بر خود پلتفرم کوبرنتیز: مسائل پلتفرم می‌توانند باعث شکست‌های آبشاری با عواقب فاجعه‌بار شوند، بنابراین نه تنها نظارت بر برنامه ورکلود مهم است، بلکه داشتن بینش در مورد سلامت کلاستر کوبرنتیز و استفاده از منابع نیز بسیار مهم است.

نظارت بر زیرساخت: بدون توجه به تعداد لایه‌های انتزاعی که Kubernetes و کانتینرها ارائه می‌کنند، همچنان در زیرساخت، مجازی و فیزیکی اجرا می‌شوند. درک زیرساخت تاثیری که می تواند بر پلتفرم و برنامه ای که اجرا می کند داشته باشد، مهم است. ممکن است خودتان آن زیرساخت را مدیریت نکنید، به خصوص اگر کوبرنتیز را در ابرهای عمومی اجرا کنید، اما همچنان به سطحی از دید در الگوهای استفاده از منابع نیاز دارید.

نتیجه

مدیریت کارآمد منابع یک جنبه حیاتی در اجرای برنامه‌های کاربردی در کوبرنتیز است. با تخصیص و بهینه سازی موثر منابع محاسباتی، سازمان‌ها می‌توانند به کارایی، مقیاس پذیری و در دسترس بودن بالاتری دست یابند.

با استفاده از مؤلفه‌های کلیدی مانند پادها، نودها، درخواست‌ها و محدودیت‌های منابع، سهمیه‌های منابع و Autoscaler Pod، استفاده بهینه از منابع تضمین شده و امکان اجرای برنامه‌های کاربردی با کارایی بالا در کلاسترهای کوبرنتیز فراهم می‌شود.

پیاده‌سازی استراتژی‌هایی مانند اندازه‌گیری مناسب درخواست‌ها و محدودیت‌های منابع، اجرای سهمیه‌های منابع، استفاده از Autoscaler Pod Horizontal، نظارت و بهینه‌سازی، و استفاده از اتوماسیون و زیرساخت می‌تواند کارایی و مقیاس‌پذیری را بیشتر بهینه کند.