ورکشاپ پنجم داکرمی ثبت نام کن...

بررسی کامل فرآیند پاد تو نود کوبرنتیز (قسمت دهم)

تو قسمت دهم از مسیر بلاگ پست‌های کوبرنتیز، میریم سراغ مفاهیم فرآیند pod to node و دقیق تر بررسی می‌کنیم که چجوری اسکجولر تصمیم میگیره که هر کدوم از پادهای ما رو روی کدوم نود کوبرنتیز استقرار بده.

خب یه مروری کنیم پست‌های قبلی رو:

توصیه می‌کنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.

مقدمه:

قبل‌تر دیدیم که اسکجولر پادهایی که جدیدا درست شدن رو بررسی می‌کنه و برای هرپاد جدیدی که اسکجولر اونو بررسی میکنه، یک نود مناسب پیدا میکنه. در واقع اسکجولر مسئول پیدا کردن بهترین نود برای پاد هست تا روی اون نود ران بشه. اسکجولر این کار رو بر اساس قوانینی که قبلا توضیح دادیم انجام میده در ادامه یه مقدار بیشتر در مورد این فرآیند توضیح میدیم.

راه‌های مختلفی برای انجام این فرآیند هست اما تمام راه حل هایی که توصیه شده هستند از Label و Selector ها استفاده می‌کنند برای آسان کردن این فرآیند.

node selector
node selector
 

Node Selector Scenario:

ساده‌ترین و توصیه‌شده‌ترین روش برای اعمال محدودیت انتخاب نود nodeSelector است.

یک فیلد در PodSpec است که یک Map از جفت‌های کلید-مقدار (key-value) را مشخص می‌کند.

برای اینکه یک پاد واجد شرایط اجرا روی یک نود باشد، نود باید تمام جفت‌های کلید-مقداری که در nodeSelector مشخص شده است را به عنوان برچسب (Label) داشته باشد (نود می‌تواند برچسب‌های اضافی دیگری نیز داشته باشد). رایج‌ترین استفاده از nodeSelector شامل یک جفت کلید-مقدار است.

node selector
node selector
 

Node Name Scenario:

استفاده از nodeName ساده‌ترین روش برای اعمال محدودیت انتخاب نود است، اما به دلیل محدودیت‌هایی که دارد معمولاً استفاده نمی‌شود. nodeName یک فیلد در PodSpec است. اگر این فیلد خالی نباشد، Scheduler پاد را نادیده می‌گیرد و kubelet در نود مشخص‌شده سعی می‌کند پاد را اجرا کند.

بنابراین، اگر nodeName در PodSpec مشخص شده باشد، نسبت به روش‌های دیگر برای انتخاب نود اولویت دارد.

Affinity and Anti-affinity Scenario:

تا اینجا متوجه شدیم که اسکجولر میشینه حساب کتاب میکنه که مثلا پاد رو نفرسته جایی که منابع مورد نیازش وجود نداشته باشه و اگه یادتون باشه گفتیم که یه بار فیلترینگ انجام میده که ببینه اصلا روی کدوم نود ها میشه این پاد رو برد و بعدش فرآیند Scoring رو انجام میده که پیدا کنه حالا از بین اینهایی که میشه کدومش بهتر هستند برای این پاد. این مباحث رو تو قسمت اسکجولر توضیح دادم.
آیا اینکه cpu و ram کافی برای اون پاد روی نود باشه کافیه؟ آیا ما میتونیم با جزئیات بیشتری از اسکجولر بخوایم که مقصد پاد رو مشخص کنه؟ مثلا میشه بگیم هرجا یه پاد از backend هست یه پاد از redis هم باشه؟ یا مثلا میتونیم بگیم که تا جای ممکن پادهای فلان سرویس رو پخششون کن که کنار هم توی یک نود نباشن؟

Pod Affinity
Pod Affinity
 

دیدیم که nodeSelector یک روش بسیار ساده برای محدود کردن پادها به نودهایی با برچسب‌های خاص فراهم می‌کند. ویژگی affinity/anti-affinity به طور قابل توجهی انواع محدودیت‌هایی که می‌توانید بیان کنید را گسترش می‌دهد.

مفهوم affinity شامل دو نوع وابستگی است:

  1. Node Affinity (وابستگی به نود)
  2. Inter-Pod Affinity/Anti-Affinity (وابستگی/ضد وابستگی بین پادها)

نوع اول یعنی Node Affinity از نظر مفهومی مشابه nodeSelector است و به شما اجازه می‌دهد که مشخص کنید پاد شما با توجه به برچسب‌های نود، روی کدام نودها واجد شرایط اجرا باشد.

در حال حاضر دو نوع Node Affinity وجود دارد:

۱. RequiredDuringSchedulingIgnoredDuringExecution

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

۲. PreferredDuringSchedulingIgnoredDuringExecution

این نوع به Scheduler پیشنهاد می‌دهد که قوانین وابستگی را رعایت کند، اما تضمینی برای رعایت آن‌ها وجود ندارد. یه جورایی می‌گیم که بهتره که این پاد مثلا این طوری اسکجول بشه اما اگر شرایط برقرار نبود جای دیگه‌ای هم اومد بالا مشکلی نیست. یه جورایی می‌گیم بهش که ترجیح می‌دیم که این طوری پیش بره اما اگر نشد مشکلی نیست.

بخش IgnoredDuringExecution در نام این قوانین نشان می‌دهد که مشابه nodeSelector، اگر در زمان اجرا برچسب‌های یک نود تغییر کنند به‌طوری که قوانین وابستگی دیگر رعایت نشوند، پاد همچنان به اجرای خود روی آن نود ادامه می‌دهد.

مثلا ممکنه پادهایی داشته باشیم که میخوایم فقط روی نودهایی از کلاستر دیپلوی بشن که اونجا gpu هم وجود داشته باشه.

required labelde affinity
required labelde affinity
 

در مثال بالا از required label استفاده شده بنابراین حتما پاد اگر دیپلوی بشه روی نودی که لیبل gpu=true داره، دیپلوی میشه.

node affinity preferred labels
node affinity preferred labels
 

در مثال بالا می‌بینیم که از Preferred labels استفاده شده، یعنی به نوعی ترجیح ما این هست که این پاد روی نودهایی بره که توی zone1 هستند و share اونها به صورت dedicated لیبل زده شده اما اگر به هردلیلی این اتفاق نیافتد کوبرنتیز از اینکه این پاد روی نود دیگری دیپلوی شود جلوگیری نمی‌کند.

سینتکس جدید Node Affinity از عملگرهای زیر پشتیبانی می‌کند:

In (در لیست بودن)

این عملگر بررسی می‌کند که آیا مقدار برچسب نود در لیستی از مقادیر مشخص‌شده وجود دارد یا نه.
مثال:

				
					key: &quotenvironment&quot
operator: &quotIn&quot
values: [&quotproduction&quot, &quotstaging&quot]

این تنظیم به پاد اجازه می‌دهد فقط روی نودهایی اجرا شود که مقدار برچسب environment برابر با production یا staging باشد.

NotIn (در لیست نبودن)

بررسی می‌کند که مقدار برچسب نود در لیستی از مقادیر مشخص‌شده نباشد.
مثال:

				
					key: &quotenvironment&quot
operator: &quotNotIn&quot
values: [&quotdevelopment&quot, &quottest&quot]

این تنظیم به پاد اجازه می‌دهد روی نودهایی اجرا شود که مقدار برچسب environment برابر با development یا test نباشد.

Exists (وجود داشتن)

بررسی می‌کند که آیا برچسب مشخص‌شده روی نود وجود دارد یا خیر.
مثال:

				
					key: &quotregion&quot
operator: &quotExists&quot

این تنظیم به پاد اجازه می‌دهد روی نودهایی اجرا شود که برچسب region داشته باشند (بدون توجه به مقدار آن).

DoesNotExist (وجود نداشتن)

بررسی می‌کند که آیا برچسب مشخص‌شده روی نود وجود ندارد.
مثال:

				
					key: &quotregion&quot
operator: &quotDoesNotExist&quot

این تنظیم به پاد اجازه می‌دهد فقط روی نودهایی اجرا شود که برچسب region نداشته باشند.

Gt (بزرگ‌تر بودن)

بررسی می‌کند که آیا مقدار برچسب نود بزرگ‌تر از مقدار مشخص‌شده است یا خیر.
مثال:

				
					key: &quotcpu-count&quot
operator: &quotGt&quot
values: [&quot4&quot]

این تنظیم به پاد اجازه می‌دهد روی نودهایی اجرا شود که مقدار برچسب cpu-count بیشتر از ۴ باشد.

Lt (کوچک‌تر بودن)

بررسی می‌کند که آیا مقدار برچسب نود کوچک‌تر از مقدار مشخص‌شده است یا خیر.
مثال:

				
					key: &quotcpu-count&quot
operator: &quotLt&quot
values: [&quot8&quot]
Youtube Linkedin Instagram X-twitter

دیدگاه‌ خود را بنویسید

مقاله های داکرمی
Kubernetes

دیزاین کلاستر (قسمت سیزدهم)

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

توضیحات بیشتر »
Kubernetes

کنترل دسترسی به کوبر (قسمت دوازدهم)

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

توضیحات بیشتر »
بارگذاری بیشتر
پیمایش به بالا