اسکژولر در کوبرنتیز

کوبرنتیز یکی از  orchestrator‌های مهم در حوزه  Devops است. و از ارکان اصلی در مدل کلودی  PaaSمحسوب می‌شود. اسکژولر وظیفه مشخص کردن نود مناسب برای لانچ شدن Pod ‌های مربوط به کوبرنتیز را بر عهده دارد. می‌توان بر حسب نیاز برای سرویس PaaS اسکژولر در کوبرنتیز را بنا به صلاحدید و با توجه به policy ‌های خود customize کرد. حتی می‌توان تحت توسعه برای سرویس‌های PaaS از چندین اسکژولر مختلف برای ساخته شدن پاد‌ها در کوبرنتیز بهره برد. اسکژولر در کلاسترهای مختلف کوبرنتیز مشخص می‌کند که pod روی چه نود‌هایی از worker ‌ها ساخته شود و در اصل و به عبارتی دیگر اسکژولر مشخص می‌کند که Application‌های مختلف روی چه نود‌هایی از کلاستر Deployشوند.

مطالعه بیشتر: امنیت در Kubernetes

Kube-scheduler

اسکژولر در کوبرنتیز component به نام Kube-scheduler دارد که روی نود‌های master در کلاستر کوبرنتیز نصب می‌گردد. هر پاد قبل از اینکه ساخته شود، Kube-scheduler نود مناسب جهت ساخته شدن آن را مشخحص می‌کند و در صورتی‌ که برای لانچ شدن پاد نودی با منابع مورد نیاز وجود نداشته باشد، پاد تا زمان خالی شدن منابع سخت افزاری نود‌ها ساخته و ایجاد نخواهد شد.

هنگام ایجاد شدن پاد‌ها، اسکژولر در مرحله اول گروهی از نود‌ها که منابع مورد نیاز برای ایجاد شدن پاد‌ها را داشته باشند مشخص می‌کند که feasible nodes نام دارند. در اصل feasible nodes‌ ها نود‌هایی هست که امکان ایجاد کردن پاد‌ها را دارند. بعد ار مشخص شدن نود‌های feasible نود‌های فوق با توجه به توابعی که وجود دارند به هر یک از نود‌ها امتیاز تخصیص می‌دهند و نودی که بالاترین میزان امتیاز را داشته باشد، پاد روی آن ایجاد خواهد شد. زمانی‌ که اسکژولر تصمیم می‌گیر که پاد روی چه نودی ایجاد شود، آن زمان پروسسی به نام binding به وجود می‌آید تا زمانی که پاد ساخته شود. در مدل کلودی PaaS می‌توان اسکژولر را با توجه به نیازمندی های خود تغییر و حتی از چندین اسکژولر مختلف بهره مند شد.

نحوه Node selection در  Kube-scheduler

فرآیند انتخاب نود مناسب در اسکژولر را می‌توان به دو گروه زیر تقسیم بندی کرد :

1. فیلترینگ
2. امتیاز دهی

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

1. Scheduling Policies
2. Scheduling Profiles

Scheduling Policies

تنظیمات پیش فرض مربوط به فیلترینگ و امتیاز دهی اسکژولر در کوبرنتیز را تغییر می‌دهد، می‌توانیم policy ‌های مورد نظر خود را برای اسکژولر از طریق کانفیگ فایل مشخص و با فراخوانی آن با کامند kube-scheduler –policy-config-file <filename> و یا با فراخوانی  config map مشخص از طریق کامند kube-scheduler –policy-configmap <ConfigMap> اعمال کنیم.

می‌توان تنظیماتی در خصوص فیلترینگ در اسکژولر و الویت‌های امتیاز دهی در اسکژولر لحاظ کرد.اسکژولر و نحوه تنظیمات آن در سرویسPaaS  یکی از مهمترین فاکتور ها محسوب می شود.

مولفه‌های زیر برای تنظیمات فیلترینگ در اسکژولر کوبرنتیز وجود دارند.

PodFitsHostPorts:

 بررسی می‌کند که نود  برای بالا آمدن پاد پورت خالی دارد یا خیر. و اگر پورت خالی داشته باشد در لیست فیلترینگ اسکژولر قرار می‌گیرد.

PodFitsHost:

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

PodFitsResources:

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

MatchNodeSelector:

اگر در ساختار پاد  label تعریف شده با label  تعریف شده در نود یکسان باشد در فیلترینگ اسکژولر قرار می‌گیرد.

NoDiskConflict:

 اگر والیوم مورد نظر پاد، روی نود mount شده باشد و ظرفیت پاد را پوشش دهد، نود در لیست فیلتر اسکژولر قرار می‌گیرد.

اولویت در امتیاز دهی

SelectorSpreadPriority:

 پاد‌هایی که در ساختار Service یا StatefulSet یا  ReplicaSet وجود دارند را می‌توان الویت برایشان در نظر گرفت. (الویت در امتیاز دهی) و فیلد‌های دیگری وجود دارند که از طریق لینک زیر در سایت رسمی ‌کوبرنتیز قابل مشاهده هستند.

https://kubernetes.io/docs/reference/scheduling/policies/

Scheduling Profiles

رفتار اسکژولر در کوبرنتیز را می‌توانیم در کانفیگ فایلی مشخص نماییم و سپس در قالب کانفیگ فایل yaml  تنطیمات را فراخوانی کنیم.

فایل فوق می‌بایست در مسیر پیش فرض کامند لاین کوبرنتیز باشد. یک نمونه از فایل yaml مربوطه به شرح زیر است.

apiVersion: kubescheduler. config. k8s. io/v1beta1

kind: KubeSchedulerConfiguration

clientConnection:

 kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig

می‌توان با تعریف پروفایل برای اسکژولر و استفاده از پلاگین‌های مختلف در پروفایل، رفتار پیش فرض اسکژولر را تغییر داد که این مهم بسیار پر کاربردی برای توسعه کوبرنتیر در ابزارهای PaaS  می باشد.

برخی از پلاگین‌های مورد استفاده در پروفایل‌های تعریفی اسکژولر به شرح زیر هستند :

QueueSort:

 این پلاگین توابعی را ارائه می‌کند که توسط آن درخواست‌های ایجاد پاد در اسکژولر به صورت یک صف مرتب می‌شوند.

PreFilter:

این پلاگین جهت بررسی اطلاعات پاد و یا کلاستر قبل از فیلترینگ در اسکژولر است و قادر خواهد بود حتی یک پاد را قبل از فیلترینگ از لیست اسکژولر خارج کند.

Filter:

این پلاگین برای تعیین پیشفرض فیلترینگ اسکژولر در کوبرنتیز است که حتی می‌تواند نود خاص را از لیست نود‌های خود جهت ایجاد کردن پاد حدف نماید.

PreScore:

از این پلاگین برای تغییر پیش فرض اسکژولر قبل از امتیاز دهی استفاده می‌شود.

Score:

 از این پلاگین برای امتیاز دادن به نود‌هایی که در لیست فیلترینگ اسکژولر وجود دارند استفاده می‌شود که نهایتا جمع امتیازهای هر نود محاسبه و هر نود که امتیاز بالاتری داشته باشد محل ایجاد پاد خواهد بود.

Reserve:

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

Permit:

این پلاگین می‌تواند مانع ایجاد شدن یک پاد مشخص شود.

PreBind:

 این پلاگین هر کار مورد نیازی را انجام می‌دهد، قبل از اینکه پاد bound شود.

Bind:

 این پلاگین برای ایجاد شدن یک پاد روی نودی مشخص است و زمانیکه از این پلاگین استفاده شود بقیه پلاگین‌ها در نظر گرفته نمی‌شوند.) (skipمی‌شوند

در نمونه yaml زیر پلاگین پیش فرض NodeResourcesLeastAllocated در اسکژولر را غیر فعال کرده است و پلاگین ساختگی به نام‌های MyCustomPluginA و MyCustomPluginB را معرفی و به آنها وزن مشخص داده است.

apiVersion: kubescheduler. config. k8s. io/v1beta1

kind: KubeSchedulerConfiguration

profiles:

 - plugins:

   score:

    disabled:

    - name: NodeResourcesLeastAllocated

    enabled:

    - name: MyCustomPluginA

     weight: 2

    - name: MyCustomPluginB

     weight: 1

همچنین در صورتی که بخواهیم تمام پلاگین‌های پیشفرض اسکژولر در کوبرنتیز را غیر فعال کنیم می‌توانیم با * این کار را انجام دهیم.

در ساختار yaml زیر نیز دو پروفایل مربوط به اسکژولر معرفی شده است که در آنها تمام پلاگین‌های preScore  و score  غیر فعال شده‌اند.

apiVersion: kubescheduler. config. k8s. io/v1beta1

kind: KubeSchedulerConfiguration

profiles:

 - schedulerName: default-scheduler

 - schedulerName: no-scoring-scheduler

  plugins:

   preScore:

    disabled:

    - name: '*'

   score:

    disabled:

    - name: '*'

زمانی که در تنظیمات yaml  یک پاد  به نام اسکژولر که می‌بایست  podدر آن اسکژول شود اشاره نشود، به صورت پیش فرض  API Server  مقادیر default-scheduler را برای آن پاد در نظر می‌گیرد و در صورتی که بخواهیم یک پاد با پروفایل مشخصی که ما برای اسکژولر تعریف کردیم اسکژول و ایجاد کنیم حتما می‌بایست در ساختار پاد با کمک فیلدspec. schedulerName. .و وارد کردن نام پروفایل خود این کار را انجام دهیم.

نتیجه

Kube-scheduler در کوبرنتیز همانند یک قیف عمل می‌کند، در ابتدا نود‌هایی که قابلیت ایجاد پاد‌ها را دارند فیلتر می‌کند و سپس به هر نود با توجه به الگوریتم‌های پیش فرض امتیازی تخصیص می‌دهد، و نهایتا پاد روی نودی ایجاد خواهد شد که بالاترین امتیاز را کسب کرده باشد. می‌توان با کانفیگ‌های مشخص رفتار اسکژولر در کوبرنتیز را تغییر داد و از پروفایل‌ها برای اسکژول کردن پاد‌ها نیز استفاده کرد.یکی از امتیازات در مدل کلودی PaaS  بهینه بودن اسکژولر است  که این مورد نیز باعث پایدار شدن سرویس های کاربران خواهد شد.