برای هر منبع Kubernetes، می توانید دو نوع الزامات را پیکربندی کنید - Requests و Limits. اولی حداقل الزامات را برای در دسترس بودن منابع گره رایگان لازم برای اجرای یک کانتینر یا غلاف توضیح می دهد، دومی به شدت منابع موجود برای کانتینر را محدود می کند.
وقتی Kubernetes زمان‌بندی پادها را انجام می‌دهد، بسیار مهم است که کانتینرها منابع کافی برای عملکرد صحیح داشته باشند. اگر قصد دارید یک برنامه بزرگ را روی یک گره با محدودیت منابع مستقر کنید، ممکن است به دلیل اینکه حافظه گره کم است یا قدرت CPU تمام می شود، اجرا نشود. در این مقاله، ما به چگونگی رفع کمبود توان محاسباتی با استفاده از درخواست‌ها و محدودیت‌های منابع خواهیم پرداخت.
درخواست‌ها و محدودیت‌ها مکانیسم‌هایی هستند که Kubernetes از آنها برای مدیریت منابعی مانند CPU و حافظه استفاده می‌کند. درخواست ها چیزی هستند که تضمین می کنند کانتینر منبع درخواستی را دریافت می کند. اگر یک کانتینر منبعی را درخواست کند، Kubernetes آن را فقط در گره‌ای برنامه‌ریزی می‌کند که بتواند آن را فراهم کند. محدودیت ها کنترل می کند که منابع درخواست شده توسط کانتینر هرگز از مقدار معینی تجاوز نکند.
یک کانتینر فقط می تواند قدرت محاسباتی خود را تا حد معینی افزایش دهد و پس از آن محدود می شود. بیایید ببینیم چگونه کار می کند. بنابراین، دو نوع منبع وجود دارد - پردازنده و حافظه. زمان‌بندی Kubernetes از داده‌های مربوط به این منابع استفاده می‌کند تا بفهمد که در کجا باید پادهای خود را اجرا کنید. یک مشخصات منبع معمولی برای یک غلاف به این صورت است.
هر ظرف در یک غلاف می تواند پرس و جوها و محدودیت های خود را تعیین کند، همه چیز افزودنی است. منابع پردازنده بر حسب میلی کور تعریف می شوند. اگر ظرف شما برای اجرا به دو هسته کامل نیاز دارد، مقدار آن را روی 2000 متر تنظیم کنید. اگر ظرف تنها به قدرت 1/4 هسته نیاز داشته باشد، مقدار آن 250 متر خواهد بود. به خاطر داشته باشید که اگر مقدار منبع CPU را بیشتر از تعداد هسته های بزرگترین گره اختصاص دهید، پاد شما اصلاً برای شروع برنامه ریزی نمی شود. اگر یک Pod داشته باشید که به چهار هسته نیاز دارد و خوشه Kubernetes فقط از دو ماشین مجازی اصلی تشکیل شده باشد، وضعیت مشابهی رخ خواهد داد.
مگر اینکه برنامه شما به طور خاص برای استفاده از چندین هسته طراحی شده باشد (برنامه هایی مانند محاسبات علمی پیچیده و عملیات پایگاه داده به ذهنتان می رسد)، بهترین روش این است که درخواست های CPU را روی 1 یا کمتر تنظیم کنید و سپس نسخه های تکراری بیشتری را برای مقیاس پذیری اجرا کنید. این راه حل به سیستم انعطاف پذیری و قابلیت اطمینان بیشتری می دهد.
وقتی نوبت به محدودیت‌های CPU می‌رسد، همه چیز جالب‌تر می‌شود زیرا یک منبع فشرده‌پذیر در نظر گرفته می‌شود. اگر برنامه شما شروع به نزدیک شدن به محدودیت قدرت پردازنده کند، Kubernetes شروع به کاهش سرعت محفظه شما با استفاده از CPU Throttling می کند - فرکانس پردازنده را کاهش می دهد. این به این معنی است که CPU به طور مصنوعی درنگ می شود و عملکرد بالقوه بدتری به برنامه می دهد، اما فرآیند خاتمه یا حذف نمی شود.
منابع حافظه بر حسب بایت تعریف می شوند. معمولاً مقدار در تنظیمات با مگابایت Mib اندازه گیری می شود، اما می توانید هر مقداری را از بایت تا پتابایت تنظیم کنید. در اینجا همان وضعیتی که در مورد CPU اعمال می شود - اگر درخواستی برای مقدار حافظه بیشتر از مقدار حافظه روی گره های خود قرار دهید، آن pod برای اجرا برنامه ریزی نمی شود. اما برخلاف منابع CPU، حافظه فشرده نمی شود زیرا راهی برای محدود کردن استفاده از آن وجود ندارد. بنابراین اجرای کانتینر به محض اینکه از حافظه اختصاص داده شده به آن فراتر رود، متوقف می شود.
مهم است به خاطر داشته باشید که نمی‌توانید درخواست‌هایی را پیکربندی کنید که از منابعی که گره‌ها می‌توانند ارائه کنند بیشتر باشد. مشخصات منابع مشترک برای ماشین های مجازی GKE را می توانید در لینک های زیر این ویدئو بیابید.
در یک دنیای ایده‌آل، تنظیمات پیش‌فرض کانتینر برای اجرای روان کارها کافی است. اما دنیای واقعی اینطور نیست، مردم می توانند به راحتی پیکربندی استفاده از منابع را فراموش کنند، یا هکرها درخواست ها و محدودیت هایی را تعیین می کنند که فراتر از توانایی های واقعی زیرساخت است. برای جلوگیری از وقوع چنین سناریوهایی، می توانید سهمیه منابع ResourceQuota و LimitRange را پیکربندی کنید.
هنگامی که یک فضای نام ایجاد شد، می توان آن را با استفاده از سهمیه ها مسدود کرد. به عنوان مثال، اگر فضای نام prod و dev را دارید، الگو به این صورت است که اصلاً سهمیه تولید وجود ندارد و سهمیه‌های توسعه بسیار دقیقی وجود دارد. این به Prod اجازه می‌دهد در صورت افزایش شدید ترافیک، تمام منابع موجود را تصاحب کند و برنامه‌نویس را کاملاً مسدود کند.
سهمیه منابع ممکن است به این شکل باشد. در این مثال 4 بخش وجود دارد - اینها 4 خط پایین کد هستند.
بیایید به هر یک از آنها نگاه کنیم. Requests.cpu حداکثر تعداد درخواست‌های CPU ترکیبی است که می‌تواند از همه کانتینرهای موجود در فضای نام بیاید. در این مثال، می توانید 50 کانتینر با 10 میلیون درخواست، پنج کانتینر با 100 میلیون درخواست، یا فقط یک کانتینر با 500 میلیون درخواست داشته باشید. تا زمانی که تعداد کل requests.cpu یک فضای نام معین کمتر از 500 متر باشد، همه چیز خوب خواهد بود.
Memory requested requests.memory حداکثر مقدار درخواست حافظه ترکیبی است که همه کانتینرها در فضای نام می توانند داشته باشند. همانطور که در مورد قبلی، می توانید 50 کانتینر 2 مگابایتی، پنج کانتینر 20 مگابایتی یا یک کانتینر 100 مگابایتی داشته باشید تا زمانی که مقدار کل حافظه درخواستی در فضای نام کمتر از 100 مگابایت باشد.
Limits.cpu حداکثر مقدار ترکیبی از توان CPU است که همه کانتینرها در فضای نام می توانند استفاده کنند. ما می توانیم این را محدودیت درخواست قدرت پردازنده در نظر بگیریم.
در نهایت، limits.memory حداکثر مقدار حافظه مشترکی است که همه کانتینرها در فضای نام می توانند استفاده کنند. این یک محدودیت برای کل درخواست های حافظه است.
بنابراین، به طور پیش‌فرض، کانتینرها در یک خوشه Kubernetes با منابع محاسباتی نامحدود اجرا می‌شوند. با سهمیه منابع، مدیران خوشه می توانند مصرف منابع و ایجاد منابع را بر اساس فضای نام محدود کنند. در یک فضای نام، یک غلاف یا کانتینر می‌تواند به اندازه‌ای که توسط سهمیه منابع فضای نام تعیین می‌شود، توان و حافظه CPU را مصرف کند. با این حال، این نگرانی وجود دارد که یک غلاف یا ظرف ممکن است تمام منابع موجود را در انحصار خود درآورد. برای جلوگیری از این وضعیت، از یک محدوده محدود استفاده می شود - سیاستی برای محدود کردن تخصیص منابع (برای غلاف یا کانتینرها) در فضای نام.
محدوده حد محدودیت هایی را ارائه می دهد که می تواند:
- از حداقل و حداکثر استفاده از منابع محاسباتی برای هر ماژول یا ظرف در فضای نام اطمینان حاصل کنید.
- اجرای حداقل و حداکثر درخواست ذخیره سازی Starage Request برای هر PersistentVolumeClaim در فضای نام.
- برقراری رابطه بین یک درخواست و یک محدودیت برای یک منبع در فضای نام؛
- درخواست‌ها/محدودیت‌های پیش‌فرض را برای منابع محاسباتی در فضای نام تنظیم کنید و به طور خودکار آنها را در زمان اجرا به کانتینرها تزریق کنید.
به این ترتیب می توانید یک محدوده محدود در فضای نام خود ایجاد کنید. بر خلاف سهمیه، که برای کل فضای نام اعمال می شود، محدوده محدود برای کانتینرهای جداگانه استفاده می شود. این می تواند کاربران را از ایجاد ظروف بسیار کوچک یا برعکس، غول پیکر در فضای نام جلوگیری کند. محدوده حد ممکن است شبیه به این باشد.
مانند مورد قبلی، در اینجا 4 بخش قابل تشخیص است. بیایید به هر یک نگاه کنیم.
بخش پیش‌فرض محدودیت‌های پیش‌فرض را برای کانتینر در غلاف تعیین می‌کند. اگر این مقادیر را روی محدوده شدید تنظیم کنید، هر کانتینری که این مقادیر به صراحت برای آن تنظیم نشده باشد، از مقادیر پیش فرض پیروی می کند.
بخش درخواست پیش‌فرض defaultRequest درخواست‌های پیش‌فرض را برای کانتینر در پاد پیکربندی می‌کند. مجدداً، اگر این مقادیر را روی محدوده شدید تنظیم کنید، هر کانتینری که به صراحت این گزینه ها را تنظیم نمی کند، به طور پیش فرض روی این مقادیر قرار می گیرد.
بخش max حداکثر محدودیت هایی را که می توان برای یک ظرف در غلاف تنظیم کرد مشخص می کند. مقادیر در بخش پیش‌فرض و محدودیت‌های کانتینر را نمی‌توان بالاتر از این حد تنظیم کرد. توجه به این نکته ضروری است که اگر مقدار روی max تنظیم شود و بخش پیش فرض وجود نداشته باشد، حداکثر مقدار به مقدار پیش فرض تبدیل می شود.
بخش min حداقل درخواست هایی را که می توان برای یک کانتینر در یک pod تنظیم کرد مشخص می کند. با این حال، مقادیر در بخش پیش‌فرض و پرس‌و‌جوهای کانتینر را نمی‌توان زیر این حد تنظیم کرد.
مجدداً، توجه به این نکته مهم است که اگر این مقدار تنظیم شود، پیش‌فرض نیست، سپس مقدار حداقل به دستور پیش‌فرض تبدیل می‌شود.
این درخواست‌های منبع در نهایت توسط برنامه‌ریز Kubernetes برای اجرای بارهای کاری شما استفاده می‌شود. برای اینکه بتوانید کانتینرهای خود را به درستی پیکربندی کنید، درک نحوه عملکرد آن بسیار مهم است. فرض کنید می خواهید چند پاد را در خوشه خود اجرا کنید. با فرض معتبر بودن مشخصات غلاف، برنامه Kubernetes از متعادل‌سازی دوره‌ای برای انتخاب یک گره برای اجرای حجم کار استفاده می‌کند.
Kubernetes بررسی می‌کند که آیا Node 1 منابع کافی برای انجام درخواست‌های کانتینرهای پاد را دارد یا نه، و اگر نداشت، به گره بعدی می‌رود. اگر هیچ یک از گره‌های سیستم نتواند درخواست‌ها را برآورده کند، پادها به حالت انتظار می‌روند. با استفاده از ویژگی های موتور Google Kubernetes مانند مقیاس خودکار گره، GKE می تواند به طور خودکار وضعیت انتظار را تشخیص دهد و چندین گره اضافی دیگر ایجاد کند.
اگر متعاقباً ظرفیت گره شما تمام شود، مقیاس خودکار تعداد گره ها را کاهش می دهد تا در هزینه شما صرفه جویی شود. به همین دلیل است که Kubernetes پادها را بر اساس درخواست ها زمان بندی می کند. با این حال، محدودیت ممکن است بیشتر از درخواست‌ها باشد و در برخی موارد گره ممکن است واقعاً با منابع تمام شود. ما این حالت را حالت تعهد بیش از حد می نامیم.
همانطور که گفتم، وقتی نوبت به CPU می رسد، Kubernetes شروع به محدود کردن پادها می کند. هر غلاف به اندازه درخواست خود دریافت می کند، اما اگر به حد مجاز نرسد، throttling اعمال می شود.
وقتی نوبت به منابع حافظه می‌رسد، Kubernetes مجبور است در مورد اینکه کدام پادها را حذف کند و کدام پادها را تا زمانی که منابع سیستم را آزاد کنید یا کل سیستم از کار بیفتد، نگه دارد، تصمیم بگیرد.
بیایید سناریویی را تصور کنیم که در آن حافظه دستگاه شما تمام می شود - Kubernetes چگونه با آن برخورد می کند؟
Kubernetes به دنبال پادهایی است که از منابع بیشتری نسبت به درخواست آنها استفاده می کنند. بنابراین اگر کانتینرهای شما اصلاً درخواستی ندارند، به این معنی است که آنها به طور پیش فرض از بیش از آنچه خواسته اند استفاده می کنند، صرفاً به این دلیل که اصلاً چیزی نخواسته اند! چنین کانتینرهایی به کاندیدای اصلی برای خاموش شدن تبدیل می شوند. کاندیداهای بعدی کانتینری هستند که تمام درخواست‌هایشان را برآورده کرده‌اند اما همچنان زیر سقف حداکثر هستند.
بنابراین اگر Kubernetes چندین پاد را پیدا کند که از پارامترهای درخواستی آنها فراتر رفته است، آنها را بر اساس اولویت مرتب می کند و سپس پایین ترین غلاف ها را حذف می کند. اگر همه پادها اولویت یکسانی داشته باشند، Kubernetes آن دسته از پادهایی را که بیش از سایر پادها از درخواست آنها بیشتر است، خاتمه می دهد.
در موارد بسیار نادر، Kubernetes ممکن است پادهایی را که هنوز در محدوده درخواست‌های آنها هستند، لغو کند. این می تواند زمانی اتفاق بیفتد که اجزای سیستم حیاتی مانند عامل Kubelet یا Docker شروع به مصرف منابع بیشتر از آنچه برای آنها رزرو شده است، کنند.
بنابراین، در مراحل اولیه شرکت‌های کوچک، یک خوشه Kubernetes می‌تواند بدون تنظیم درخواست‌ها و محدودیت‌های منابع به خوبی کار کند، اما با شروع بزرگ‌تر شدن تیم‌ها و پروژه‌های شما، شما در معرض خطر مشکلاتی در این زمینه هستید. افزودن پرس و جوها و محدودیت ها به ماژول ها و فضاهای نام نیاز به تلاش بسیار کمی دارد و می تواند دردسرهای زیادی را نجات دهد.
چند تبلیغ 🙂
از اینکه با ما ماندید متشکرم آیا مقالات ما را دوست دارید؟ آیا می خواهید مطالب جالب تری ببینید؟ با ثبت سفارش یا معرفی به دوستان از ما حمایت کنید , یک آنالوگ منحصر به فرد از سرورهای سطح ورودی که توسط ما برای شما اختراع شده است: (در دسترس با RAID1 و RAID10، حداکثر 24 هسته و حداکثر 40 گیگابایت DDR4).
Dell R730xd 2 برابر ارزان تر در مرکز داده Equinix Tier IV در آمستردام؟ فقط اینجا در هلند! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - از 99 دلار! در مورد بخوانید
منبع: www.habr.com