مقیاس خودکار و مدیریت منابع در Kubernetes (بازبینی و گزارش تصویری)

27 آوریل در کنفرانس اعتصاب 2019، به عنوان بخشی از بخش "DevOps"، گزارش "مقیاس سازی خودکار و مدیریت منابع در Kubernetes" ارائه شد. در مورد چگونگی استفاده از K8 برای اطمینان از در دسترس بودن برنامه های خود و اطمینان از عملکرد اوج صحبت می کند.

طبق سنت، ما از ارائه خوشحالیم ویدئوی گزارش (44 دقیقه، بسیار آموزنده تر از مقاله) و خلاصه اصلی به صورت متنی. برو!

موضوع گزارش را کلمه به کلمه تحلیل کنیم و از آخر شروع کنیم.

کوبرنیتس

فرض کنید کانتینرهای Docker روی هاست خود داریم. برای چی؟ برای اطمینان از تکرارپذیری و جداسازی، که به نوبه خود امکان استقرار ساده و خوب را فراهم می کند، CI/CD. ما از این دست وسایل نقلیه با کانتینر زیاد داریم.

Kubernetes در این مورد چه چیزی ارائه می دهد؟

1. ما دیگر به این ماشین ها فکر نمی کنیم و شروع به کار با "ابر" می کنیم. دسته ای از ظروف یا غلاف (گروه ظروف).
2. علاوه بر این، ما حتی به غلاف های فردی فکر نمی کنیم، بلکه بیشتر مدیریت می کنیمоگروه های بزرگتر چنین ابتدایی های سطح بالا به ما اجازه می دهد بگوییم که یک الگو برای اجرای یک حجم کاری خاص وجود دارد و در اینجا تعداد مورد نیاز برای اجرای آن وجود دارد. اگر متعاقباً الگو را تغییر دهیم، همه نمونه ها تغییر خواهند کرد.
3. با API اعلامی به جای اجرای دنباله ای از دستورات خاص، ما "ساختار جهان" (در YAML) را که توسط Kubernetes ایجاد شده است، توصیف می کنیم. و دوباره: وقتی توضیحات تغییر می کند، نمایش واقعی آن نیز تغییر می کند.

مدیریت منابع

پردازنده

اجازه دهید nginx، php-fpm و mysql را روی سرور اجرا کنیم. این سرویس ها در واقع فرآیندهای بیشتری در حال اجرا خواهند داشت که هر کدام به منابع محاسباتی نیاز دارند:

(اعداد روی اسلاید "طوطی" هستند، نیاز انتزاعی هر فرآیند برای قدرت محاسباتی)

برای آسان‌تر کردن کار با این، منطقی است که فرآیندها را در گروه‌ها ترکیب کنیم (به عنوان مثال، همه فرآیندهای nginx در یک گروه "nginx"). یک راه ساده و واضح برای انجام این کار این است که هر گروه را در یک ظرف قرار دهید:

برای ادامه، باید به یاد داشته باشید که یک کانتینر (در لینوکس) چیست. ظاهر آنها به لطف سه ویژگی کلیدی در هسته که مدت ها پیش پیاده سازی شده بود امکان پذیر شد: قابلیت های, فضای نام ها и گروه ها. و توسعه بیشتر توسط سایر فن آوری ها (از جمله "پوسته های" راحت مانند Docker) تسهیل شد:

در چارچوب گزارش، ما فقط علاقه مندیم گروه ها، زیرا گروه های کنترل بخشی از عملکرد کانتینرها (Docker و غیره) هستند که مدیریت منابع را پیاده سازی می کنند. فرآیندهای ترکیب شده در گروه ها، همانطور که می خواستیم، گروه های کنترل هستند.

بیایید به الزامات CPU برای این فرآیندها و اکنون برای گروه‌هایی از فرآیندها برگردیم:

(تکرار می کنم که همه اعداد بیانی انتزاعی از نیاز به منابع هستند)

در عین حال، CPU خود منبع محدود خاصی دارد (در مثال این 1000 است)، که ممکن است همه فاقد آن باشند (مجموع نیازهای همه گروه ها 150+850+460=1460 است). در این صورت چه اتفاقی خواهد افتاد؟

هسته شروع به توزیع منابع می کند و آن را "عادلانه" انجام می دهد و به همان میزان منابع را به هر گروه می دهد. اما در حالت اول تعداد آنها بیشتر از حد نیاز است (333>150) بنابراین مازاد (333-150=183) در ذخیره باقی می ماند که بین دو ظرف دیگر نیز به طور مساوی توزیع می شود:

در نتیجه: ظرف اول منابع کافی داشت، دومی - منابع کافی نداشت، سومی - منابع کافی نداشت. این نتیجه اقدامات است زمانبندی "صادقانه" در لینوکس - CFS. عملکرد آن را می توان با استفاده از انتساب تنظیم کرد وزنها هر یک از ظروف به عنوان مثال، مانند این:

بیایید به مورد کمبود منابع در ظرف دوم (php-fpm) نگاه کنیم. همه منابع ظرف به طور مساوی بین فرآیندها توزیع می شوند. در نتیجه، فرآیند اصلی به خوبی کار می کند، اما همه کارگران سرعت خود را کاهش می دهند و کمتر از نیمی از نیاز خود را دریافت می کنند:

زمانبندی CFS اینگونه کار می کند. وزن‌هایی را که به کانتینرها اختصاص می‌دهیم بیشتر فراخوانی می‌کنیم درخواست ها. چرا این چنین است - به ادامه مطلب مراجعه کنید.

بیایید از طرف دیگر به کل وضعیت نگاه کنیم. همانطور که می دانید تمام جاده ها به رم و در مورد کامپیوتر به CPU منتهی می شوند. یک CPU، چندین کار - به یک چراغ راهنمایی نیاز دارید. ساده ترین راه برای مدیریت منابع "چراغ راهنمایی" است: آنها به یک فرآیند یک زمان دسترسی ثابت به CPU دادند، سپس به فرآیند بعدی و غیره.

این رویکرد سهمیه بندی سخت نامیده می شود (محدود کردن سخت). بیایید آن را به سادگی به یاد داشته باشیم محدودیت ها. با این حال، اگر محدودیت‌هایی را برای همه کانتینرها توزیع کنید، یک مشکل پیش می‌آید: mysql در حال رانندگی در جاده بود و در نقطه‌ای نیازش به CPU تمام شد، اما تمام فرآیندهای دیگر مجبور می‌شوند تا CPU منتظر بمانند. بیکار.

بیایید به هسته لینوکس و تعامل آن با CPU برگردیم - تصویر کلی به شرح زیر است:

cgroup دو تنظیم دارد - در اصل این دو "پیچ" ساده هستند که به شما امکان می دهد تعیین کنید:

1. وزن برای ظرف (درخواست) است سهام;
2. درصد کل زمان CPU برای کار بر روی وظایف کانتینر (محدودیت) است سهم.

چگونه CPU را اندازه گیری کنیم؟

راه های مختلفی وجود دارد:

1. چه شده است طوطی ها، هیچ کس نمی داند - شما باید هر بار مذاکره کنید.
2. علاقه واضح تر، اما نسبی: 50 درصد از یک سرور با 4 هسته و با 20 هسته چیزهای کاملاً متفاوتی هستند.
3. می توانید از موارد ذکر شده استفاده کنید وزنها، که لینوکس می داند، اما آنها نیز نسبی هستند.
4. مناسب ترین گزینه اندازه گیری منابع محاسباتی است ثانیه. آن ها در ثانیه از زمان پردازنده نسبت به ثانیه های زمان واقعی: 1 ثانیه از زمان پردازنده در هر 1 ثانیه واقعی داده شد - این یک هسته کامل CPU است.

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

بیایید یک مثال ساده را با یک سرور با 3 هسته CPU در نظر بگیریم، که در آن به سه پاد وزن (500، 1000 و 1500) داده می شود که به راحتی به قسمت های مربوطه از هسته های اختصاص داده شده به آنها (0,5، 1 و 1,5) تبدیل می شوند.

اگر سرور دومی را انتخاب کنید که در آن دوبرابر تعداد هسته‌ها (6) وجود دارد و همان غلاف‌ها را در آنجا قرار دهید، توزیع هسته‌ها را می‌توان به سادگی با ضرب در 2 (به ترتیب 1، 2 و 3) محاسبه کرد. اما یک لحظه مهم زمانی رخ می دهد که یک پاد چهارم روی این سرور ظاهر می شود که وزن آن برای راحتی 3000 خواهد بود. بخشی از منابع CPU (نیم هسته ها) را می گیرد و برای پادهای باقی مانده مجدداً محاسبه می شوند (نصف):

Kubernetes و منابع CPU

در Kubernetes، منابع CPU معمولاً در اندازه گیری می شوند میلی درکس، یعنی 0,001 هسته به عنوان وزن پایه در نظر گرفته شده است. (همان چیزی که در اصطلاحات Linux/cgroups سهم CPU نامیده می شود، اگرچه به طور دقیق تر، 1000 میلی کور = 1024 سهم CPU.) K8s تضمین می کند که پادهای بیشتری از منابع CPU برای مجموع وزن همه پادها روی سرور قرار نمی دهد.

چگونه این اتفاق می افتد؟ هنگامی که یک سرور را به یک خوشه Kubernetes اضافه می کنید، گزارش می شود که چند هسته CPU در دسترس است. و هنگام ایجاد یک پاد جدید، زمانبندی Kubernetes می داند که این پاد به چند هسته نیاز دارد. بنابراین، پاد به سروری اختصاص می‌یابد که در آن هسته‌های کافی وجود دارد.

چه اتفاقی خواهد افتاد اگر هیچ درخواست مشخص شده است (یعنی غلاف تعداد هسته های مشخصی که نیاز دارد ندارد)؟ بیایید بفهمیم که Kubernetes به طور کلی چگونه منابع را می شمارد.

برای یک پاد می توانید هم درخواست ها (زمان بندی CFS) و هم محدودیت ها را مشخص کنید (چراغ راهنمایی را به خاطر دارید؟):

• اگر آنها مساوی مشخص شوند، به pod یک کلاس QoS اختصاص داده می شود تضمین شده. این تعداد هسته همیشه در دسترس آن تضمین شده است.
• اگر درخواست کمتر از حد مجاز باشد - کلاس QoS قابل ترکیدن. آن ها به عنوان مثال، ما انتظار داریم که یک pod همیشه از 1 هسته استفاده کند، اما این مقدار محدودیتی برای آن نیست: گاهی پاد می تواند بیشتر استفاده کند (زمانی که سرور منابع رایگان برای این کار داشته باشد).
• همچنین یک کلاس QoS وجود دارد بهترین تلاش - شامل همان غلاف هایی است که درخواست برای آنها مشخص نشده است. منابع آخر به آنها داده می شود.

حافظه

با حافظه، وضعیت مشابه است، اما کمی متفاوت است - از این گذشته، ماهیت این منابع متفاوت است. به طور کلی، قیاس به شرح زیر است:

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

این همیشه برای ما مناسب نیست، بنابراین می توان تنظیم کرد که کدام فرآیندها برای ما مهم هستند و نباید کشته شوند. برای این کار از پارامتر استفاده کنید oom_score_adj.

بیایید به کلاس‌های QoS CPU برگردیم و با مقادیر oom_score_adj که اولویت‌های مصرف حافظه را برای پادها تعیین می‌کند، تشبیه کنیم:

• کمترین مقدار oom_score_adj برای یک پاد - -998 - به این معنی است که چنین غلافی باید آخرین بار کشته شود، این تضمین شده.
• بالاترین - 1000 - است بهترین تلاش، ابتدا چنین غلاف ها کشته می شوند.
• برای محاسبه مقادیر باقیمانده (قابل ترکیدن) فرمولی وجود دارد که ماهیت آن به این خلاصه می شود که هر چه یک غلاف منابع بیشتری درخواست کرده باشد، احتمال کشته شدن آن کمتر است.

دومین "پیچ" - limit_in_bytes - برای محدودیت با آن، همه چیز ساده تر است: ما به سادگی حداکثر مقدار حافظه صادر شده را اختصاص می دهیم، و در اینجا (برخلاف CPU) هیچ سوالی در مورد نحوه اندازه گیری آن (حافظه) وجود ندارد.

در کل

هر غلاف در Kubernetes داده شده است requests и limits - هر دو پارامتر برای CPU و حافظه:

1. بر اساس درخواست‌ها، زمان‌بندی Kubernetes کار می‌کند، که غلاف‌ها را بین سرورها توزیع می‌کند.
2. بر اساس تمام پارامترها، کلاس QoS غلاف تعیین می شود.
3. وزن نسبی بر اساس درخواست های CPU محاسبه می شود.
4. زمانبندی CFS بر اساس درخواست های CPU پیکربندی شده است.
5. قاتل OOM بر اساس درخواست های حافظه پیکربندی شده است.
6. یک "چراغ راهنمایی" بر اساس محدودیت های CPU پیکربندی شده است.
7. بر اساس محدودیت های حافظه، یک محدودیت برای cgroup پیکربندی شده است.

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

مقیاس خودکار

K8s cluster-autoscaler

بیایید تصور کنیم که کل خوشه قبلاً اشغال شده است و باید یک غلاف جدید ایجاد شود. در حالی که غلاف نمی تواند ظاهر شود، در وضعیت آویزان است در انتظار. برای اینکه ظاهر شود، می‌توانیم سرور جدیدی را به خوشه وصل کنیم یا ... cluster-autoscaler را نصب کنیم، که این کار را برای ما انجام می‌دهد: یک ماشین مجازی از ارائه‌دهنده ابر (با استفاده از درخواست API) سفارش دهید و آن را به خوشه متصل کنید. ، پس از آن غلاف اضافه خواهد شد.

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

تا زمانی که اندازه خوشه را افزایش دادیم، همه چیز خوب بود، اما وقتی خوشه چه اتفاقی می‌افتد شروع به آزاد کردن خود کرد? مشکل این است که انتقال پادها (برای آزاد کردن هاست) از نظر منابع بسیار دشوار و گران است. Kubernetes از رویکرد کاملا متفاوتی استفاده می کند.

دسته ای از 3 سرور را در نظر بگیرید که دارای Deployment هستند. دارای 6 پاد: اکنون برای هر سرور 2 عدد وجود دارد. بنا به دلایلی می خواستیم یکی از سرورها را خاموش کنیم. برای این کار از دستور استفاده می کنیم kubectl drain، که:

• ارسال پادهای جدید به این سرور را ممنوع خواهد کرد.
• پادهای موجود در سرور را حذف می کند.

از آنجایی که Kubernetes مسئول حفظ تعداد غلاف (6) است، به سادگی بازسازی خواهد کرد آنها را در سایر گره ها، اما نه در گره ای که غیرفعال است، زیرا قبلاً برای میزبانی غلاف های جدید به عنوان غیرقابل دسترس علامت گذاری شده است. این یک مکانیک اساسی برای Kubernetes است.

با این حال، یک تفاوت ظریف در اینجا نیز وجود دارد. در وضعیت مشابه، برای StatefulSet (به جای Deployment)، اقدامات متفاوت خواهد بود. اکنون ما یک برنامه حالت دار داریم - به عنوان مثال، سه پاد با MongoDB، که یکی از آنها نوعی مشکل دارد (داده ها خراب شده اند یا خطای دیگری که مانع از راه اندازی صحیح پاد می شود). و ما دوباره تصمیم می گیریم یک سرور را غیرفعال کنیم. چه اتفاقی خواهد افتاد؟

MongoDB میتوانست می‌میرد زیرا به حد نصاب نیاز دارد: برای خوشه‌ای متشکل از سه نصب، حداقل دو نصب باید کار کنند. با این حال، این اتفاق نمی افتد - با تشکر از PodDisruptionBudget. این پارامتر حداقل تعداد مورد نیاز غلاف کار را تعیین می کند. دانستن اینکه یکی از پادهای MongoDB دیگر کار نمی کند و مشاهده اینکه PodDisruptionBudget برای MongoDB تنظیم شده است minAvailable: 2، Kubernetes به شما اجازه حذف یک پاد را نمی دهد.

خط پایین: برای اینکه حرکت (و در واقع ایجاد مجدد) پادها به درستی هنگام آزاد شدن خوشه کار کند، باید PodDisruptionBudget را پیکربندی کرد.

مقیاس بندی افقی

بیایید وضعیت دیگری را در نظر بگیریم. برنامه ای وجود دارد که به عنوان Deployment در Kubernetes اجرا می شود. ترافیک کاربر به پادهای آن می آید (مثلاً سه مورد از آنها وجود دارد) و ما یک شاخص خاص را در آنها اندازه می گیریم (مثلاً بار CPU). وقتی بار افزایش می یابد، آن را در یک برنامه زمان بندی ثبت می کنیم و تعداد پادها را برای توزیع درخواست ها افزایش می دهیم.

امروزه در Kubernetes این کار نیازی به انجام دستی ندارد: افزایش/کاهش خودکار تعداد غلاف ها بسته به مقادیر نشانگرهای بار اندازه گیری شده پیکربندی می شود.

سوالات اصلی در اینجا عبارتند از: دقیقا چه چیزی را اندازه گیری کنیم и چگونه تفسیر کنیم مقادیر به دست آمده (برای تصمیم گیری در مورد تغییر تعداد غلاف). شما می توانید مقدار زیادی اندازه گیری کنید:

نحوه انجام این کار از نظر فنی - جمع آوری معیارها و غیره. - من در گزارش مفصل صحبت کردم نظارت و Kubernetes. و توصیه اصلی برای انتخاب پارامترهای بهینه است آزمایش!

وجود دارد روش استفاده (اشباع استفاده و خطاها) که معنای آن به شرح زیر است. بر چه اساسی مقیاس بندی مثلا php-fpm منطقی است؟ بر اساس این واقعیت که کارگران در حال اتمام هستند، این است استفاده. و اگر کارگران تمام شده باشند و اتصالات جدید پذیرفته نشود، این قبلاً وجود دارد اشباع. هر دوی این پارامترها باید اندازه گیری شوند و بسته به مقادیر باید مقیاس بندی انجام شود.

به جای یک نتیجه گیری

این گزارش یک ادامه دارد: در مورد مقیاس بندی عمودی و نحوه انتخاب منابع مناسب. در ویدیوهای بعدی در مورد این موضوع صحبت خواهم کرد یوتیوب ما - مشترک شوید تا فرصت را از دست ندهید!

فیلم ها و اسلایدها

ویدئویی از اجرا (44 دقیقه):

ارائه گزارش:

PS

گزارش های دیگر در مورد Kubernetes در وبلاگ ما:

• «گسترش و تکمیل Kubernetes» (آندری پولوفوف؛ 8 آوریل 2019 در Saint HighLoad++);
• «پایگاه های داده و Kubernetes» (دیمیتری استولیاروف؛ 8 نوامبر 2018 در HighLoad++);
• «نظارت و Kubernetes» (دیمیتری استولیاروف؛ 28 مه 2018 در RootConf);
• «بهترین تمرینات CI/CD با Kubernetes و GitLab» (دیمیتری استولیاروف؛ 7 نوامبر 2017 در HighLoad++);
• «تجربه ما با Kubernetes در پروژه های کوچک» (دیمیتری استولیاروف؛ 6 ژوئن 2017 در RootConf).

منبع: www.habr.com