کوبرنتیز یکی از Orchestratorهای پرکاربرد و متن باز در حوزه Devops و زیرساخت است که می‌توان با توسعه آن به پلتفرمی مناسب در مدل کلودی PaaS دست یافت
کوبرنتیز یکی از Orchestratorهای پرکاربرد و متن باز در حوزه Devops و زیرساخت است که می‌توان با توسعه آن به پلتفرمی مناسب در مدل کلودی PaaS دست یافت. در این مقاله به اعمال محدودیت‌های استفاده از منابع سخت افزاری در kuberenetes پرداخته شده است که پیش نیاز مطالعه این مقاله آشنایی با کوبرنتیز و داکر است. لازم به ذکر است که در آکادمی ابری مقالات متعددی جهت آشنایی با داکر و کوبرنتیز وجود دارد.
از روش‌های مختلف می‌توان منابع مورد استفاده در کانتینر‌های کوبرنتیز را محدود کرد که قطعا اعمال محدودیت‌های درست و به جا در کوبرنتیز بسیار مهم و حائز اهمیت است. برای روشن شدن اهمیت این موضوع می‌توانیم کلاستری با 10 نود worker در نظر بگیریم، کلاستری که یک application فروشگاه اینترنتی روی آن بارگذاری شده است. در نظر می‌گیریم که این فروشگاه اینترنتی دارای چندین کانتینر مربوط به اتصال کاربر به درگاه‌های مختلف بانکی است. در نظر می‌گیریم یکی از کانتینر‌های متصل به درگاه به دلایلی با ترافیک بسیار زیادی رو به رو شده است. ترافیک به حدی است که کانتینر مربوطه تمام نود‌های کلاستر را درگیر کرده است، در چنین شرایط کل APP از کار خواهد افتاد، چرا که منابعی برای استفاده کانتینر‌های دیگر، وجود نخواهد داشت. اینجاست که اهمیت استفاده از محدودیت‌ها و یا quota اهمیت خود را نشان می‌دهد.
با روش‌های مختلفی می‌توان محدودیت استفاده از منابع را پیاده سازی کرد که به برخی از آن‌ها خواهیم پرداخت.
Pod resource quota
می‌توانیم به طور مستقیم محدودیت استفاده از منابع را در podهای خود مشخص کنیم. با استفاده از فیلد resources در ساختار مانفیست این امکان میسر خواهد شد. فیلد resources از دو بخش مهم limits و requests تشکیل شده است که به توضیحات این دو فیلد خواهیم پرداخت.
در فیلد requests ما مشخص می‌کنیم که اسکژولر در kubernetes با توجه به آن تصمیم گیری کند، که Pod مورد نظر روی چه نودی بالا بیاید، به عبارتی دیگر اسکژولر برای تصمیم گیری خود، این که Pod را روی چه نودی بالا بیاورد دارای الگوریتم‌هایی است که این الگوریتم‌ها می‌آیند و به فیلد requests در Pod توجه می‌کنند و بر مبنای requests مشخص شده در Pod تصمیم گیری خواهند کرد که Pod روی چه نودی از workerها لانچ شود. در فیلد limit نیز دقیقا مشخص می‌شود که کانتینر مشخص شده در Pod دقیقا تا چه اندازه اجازه استفاده از منابع را خواهد داشت و قطعا بیشتر از فیلد مشخص شده در limit اجازه استفاده از منابع را نخواهد گرفت. در مانفیست زیر به یک نمونه از resource quota جهت بررسی و تحلیل قرار داده شده است.
در مثال فوق در پاد با نام high-priority محدودیت جهت استفاده از رم و پردازنده قرار داده شده است. محدودیتی کانتینر معرفی شده در pod می‌تواند به نهایتا تا 10 گیگ رم و 500m پردازنده را مورد استفاده قرار دهد.
Namespace resource quota
در این روش می‌توان محدودیت برای namespace مشخص، در کوبرنتیز اعمال کرد. در این روش برای موار بسیار زیادی در کوبرنتیز می‌توانیم محدودیت ایجاد کنیم. کلاستری در کوبرنتیز را در نظر می‌گیریم که توسط 10 تیم مختلف مدیریت می‌شوند و به آن دسترسی دارند، برای جلوگیری از بروز مشکلات متعددی از قبیل اشتباهات افراد در نوشتن مانیفست‌ها و مشکلات Pod ها می‌توان برای هر تیم یک name space مجزا در نظر گرفت که هر name space را با توجه به نیازمندی‌های آن تیم از نظر محدودیت‌های استفاده از منابع و موارد مختلف در کوبرنتیز مدیریت کرد.
جهت استفاده از این نوع محدودیت می‌توان از Kind جداگانه‌ای به نام Resource Quota استفاده کرد. در این نوع Kind می‌توان روی موارد زیادی در name space مشخص شده محدودیت ایجاد کرد. می‌توان در ساخت سرویس‌ها و لود بالانسر‌ها و حتی secretها محدودیت ایجاد کرد. در مثال زیر یک مانیفست از نوع Resource Quota گرد آوری شده است.
همان طور که در مثال مشخص است، در فیلد name space نام name space که می‌خواهیم برای آن محدودیت‌های مختلفی اعمال شود مشخص می‌گردد که در این مثال برای name space با نام default محدودیت‌ها اعمال خواهد شد. در این name space بیشتر از 200 سرویس و 50 تا secret نمی‌توان ساخت. در این مانفیست حتی برای ephemeral storage نیز محدودیت لحاظ شده است. ephemeral storage ها دیتا‌های موقت کانتینر‌ها هستند که با متوقف شدن Pod ها از بین خواهند رفت. همان طور که مشخص است حتی تعداد والیوم‌های مورد استفاده نیز در این مثال محدود شده‌اند و در این name space نمی‌توان بیش از 20 والیوم مورد استفاده قرار داد. در kind از نوع resource quota می‌توان هر object در کوبرنتیز را محدود کرد.
Limit Ranges
در نسخه 1. 10 به بعد کوبرنتیز Kind از نوع limit range معرفی شد. این نوع kind زمانی کاربرد دارد که در ساختار pod محدودیتی لحاظ نشده باشد. به عبارتی دیگر زمانی که در ساختار پاد‌های مختلف ما در کلاستر کوبرنتیز محدودیت استفاده از منابع مشخص نشده باشد، اسکژولر در کوبرنتیز می‌آید و محدودیت‌های تعریف شده در Kind از نوع limit Range را اعمال می‌کند. limit range روی پاد‌هایی از کوبرنتیز اعمال خواهد شد که آن پاد در ساختار مانیفستش محدودیتی تعریف نشده باشد.
محدودیت‌های مشخص شده‌ای در این نوع مانیفست‌ها به ازای هر کانتینر اعمال خواهد شد. در مثال زیر مانیفست limit range گردآوری شده است.
فیلد default request فیلدی است که اسکژولر بر مبنای آن تصمیم خواهد گرفت که پاد‌ها روی چه نودی لانچ شوند و در فیلد default مشخص شده است که کانتینر‌های هر پاد حداکثر و حداقل میزان استفاده منابع آن‌ها چه قدر می‌تواند باشد.
نکته : توصیه می‌شود که از یک نوع محدودیت استفاده کنیم چرا که استفاده از همه نوع‌های مختلف محدودیت می‌تواند کاملا گیچ کننده باشد.
اولویت اعمال محدودیت‌ها
حالت گارانتی
زمانی که ریکوئست و لیمیت یکی باشد کوبرنتیز گارانتی می‌کند که منابع رو دقیقا به پاد اختصاص دهد که این حالت، حالتی است که از الویت بالایی برخودار است.
حالت bustable
هنگامی که لیمیت را از ریکوئیست بزگتر در نظر می‌گیریم، حالت bustable گفته می‌شود که نسبت به گارانتی از الویت کمتری برخوردار است. و زمانی که پادی داشته باشیم که در حالت گارانتی برای 2 گیگ رم در نظر گرفته باشد و پاد دیگری وجود داشته باشد که حالت لیمیت و ریکوئست آن‌ها برابر نباشد و لیمیت تعیین شده برایشان 2 گیگ رم باشد، الویت با پاد اول در استفاده از منابع است. چراکه حالت گارانتی از الویت بالایی در استفاده از منابع برخوردار است.
حالت best effort
زمانی که لیمیت تعریف نمی‌کنیم حالت best effort به وجود خواهد آمد. که کمترین الویت را خواهد داشت. در صورتی که دو پاد بالا آمده باشند که یکی هیچ محدودیتی برایش تعریف نشده باشد و دیگری دارای محدودیت باشد الویت استفاده از منابع به پاد دارای محدودیت خواهد بود.
نتیجه
به جهت مدیریت درست و بهتر در کلاستر کوبرنتیز، استفاده و پیاده سازی محدودیت‌ها در ساختار‌های مختلف با توجه به سیاست‌های تعیین شده، الزامی‌است در صورت عدم اعمال محدودیت‌ها ، نرم افزار deploy شده در کلاستر به احتمال زیاد دچار مشکل خواهد شد.
