اسکژولر وظیفه مشخص کردن نود مناسب برای لانچ شدن Pod های مربوط به کوبرنتیز را بر عهده دارد. می‌توان بر حسب نیاز برای سرویس PaaS اسکژولر در کوبرنتیز را بنا به صلاحدید و با توجه به policy های خود customize کرد. یکی از‌های مهم در حوزه Devops است. و از ارکان اصلی در مدل کلودی PaaS محسوب می‌شود. اسکژولر وظیفه مشخص کردن نود مناسب برای لانچ شدن Pod های مربوط به کوبرنتیز را بر عهده دارد. می‌توان بر حسب نیاز برای سرویس PaaS اسکژولر در کوبرنتیز را بنا به صلاحدید و با توجه به policy های خود customize کرد. حتی می‌توان تحت توسعه برای سرویس‌های PaaS از چندین اسکژولر مختلف برای ساخته شدن پاد‌ها در کوبرنتیز بهره برد. اسکژولر در کلاسترهای مختلف کوبرنتیز مشخص می‌کند که pod روی چه نود‌هایی از worker ها ساخته شود و در اصل و به عبارتی دیگر اسکژولر مشخص می‌کند که Application‌های مختلف روی چه نود‌هایی از کلاستر Deploy شوند. Kube - scheduler اسکژولر در component به نام Kube - scheduler دارد که روی نود‌های master در کلاستر کوبرنتیز نصب می‌گردد. هر پاد قبل از اینکه ساخته شود، Kube - scheduler نود مناسب جهت ساخته شدن آن را مشخحص می‌کند و در صورتی‌که برای لانچ شدن پاد نودی با منابع مورد نیاز وجود نداشته باشد، پاد تا زمان خالی شدن منابع سخت افزاری نود‌ها ساخته و ایجاد نخواهد شد. هنگام ایجاد شدن پاد‌ها، اسکژولر در مرحله اول گروهی از نود‌ها که منابع مورد نیاز برای ایجاد شدن پاد‌ها را داشته باشند مشخص می‌کند که feasible nodes نام دارند. در اصل feasible nodes‌ها نود‌هایی هست که امکان ایجاد کردن پاد‌ها را دارند. بعد ار مشخص شدن نود‌های feasible نود‌های فوق با توجه به توابعی که وجود دارند به هر یک از نود‌ها امتیاز تخصیص می‌دهند و نودی که بالاترین میزان امتیاز را داشته باشد، پاد روی آن ایجاد خواهد شد. زمانی‌که اسکژولر تصمیم می‌گیر که پاد روی چه نودی ایجاد شود، آن زمان پروسسی به نام binding به وجود می‌آید تا زمانی که پاد ساخته شود. در مدل کلودی PaaS می‌توان اسکژولر را با توجه به نیازمندی های خود تغییر و حتی از چندین اسکژولر مختلف بهره مند شد. نحوه Node selection در Kube - scheduler فرآیند انتخاب نود مناسب در اسکژولر را می‌توان به دو گروه زیر تقسیم بندی کرد: در فیلترینگ، اسکژولر نود‌هایی که از لحاظ منابع قابلیت ایجاد پاد را داشته باشند مشخص می‌کند، و بعد از مشخص شدن نود‌ها وارد مرحله امتیاز دهی خواهد شد. اسکژولر برای نود‌های فوق با توجه به الگوریتمی‌که در توابع مربوط به خود تعریف شده است به نود‌ها امتیاز تخصیص خواهد داد و نهایتا هر نود که بالاترین میزان امتیاز را داشته باشد پاد روی آن ساخته خواهد شد. دو راه برای config کردن فیلترینگ و نحوه امتیاز دهی به نود‌ها وجود دارد که به شرح زیر می‌باشند. Scheduling Policies Scheduling Profiles Scheduling Policies تنظیمات پیش فرض مربوط به فیلترینگ و امتیاز دهی اسکژولر در را تغییر می‌دهد، می‌توانیم policy های مورد نظر خود را برای اسکژولر از طریق کانفیگ فایل مشخص و با فراخوانی آن با کامند kube - scheduler - - policy - config - file و یا با فراخوانی config map مشخص از طریق کامند kube - scheduler - - policy - configmap اعمال کنیم. می‌توان تنظیماتی در خصوص فیلترینگ در اسکژولر و الویت‌های امتیاز دهی در اسکژولر لحاظ کرد. اسکژولر و نحوه تنظیمات آن در یکی از مهمترین فاکتور ها محسوب می شود. مولفه‌های زیر برای تنظیمات فیلترینگ در اسکژولر کوبرنتیز وجود دارند. PodFitsHostPorts : بررسی می‌کند که نود برای بالا آمدن پاد پورت خالی دارد یا خیر. و اگر پورت خالی داشته باشد در لیست فیلترینگ اسکژولر قرار می‌گیرد. PodFitsHost : بررسی می‌کند که آیا‌هاست نیم نود، هاست نیم خاص مشخص شده از قبل است یا خیر، که اگر بود در لیست فیلترینگ اسکژولر قرار می‌گیرد. PodFitsResources : بررسی می‌کند که آیا نود‌ها منابع خالی دارند یا خیر. اگر داشته باشند، در لیست فیلترینگ اسکژولر قرار می‌گیرد. MatchNodeSelector : اگر در ساختار پاد label تعریف شده با label تعریف شده در نود یکسان باشد در فیلترینگ اسکژولر قرار می‌گیرد. NoDiskConflict : اگر والیوم مورد نظر پاد، روی نود mount شده باشد و ظرفیت پاد را پوشش دهد، نود در لیست فیلتر اسکژولر قرار می‌گیرد. الویت در امتیاز دهی SelectorSpreadPriority : پاد‌هایی که در ساختار Service یا StatefulSet یا ReplicaSet وجود دارند را می‌توان الویت برایشان در نظر گرفت. (الویت در امتیاز دهی) و فیلد‌های دیگری وجود دارند که از طریق لینک زیر در سایت رسمی‌کوبرنتیز قابل مشاهده هستند. Scheduling Profiles رفتار اسکژولر در کوبرنتیز را می‌توانیم در کانفیگ فایلی مشخص نماییم و سپس در قالب کانفیگ فایل yaml تنطیمات را فراخوانی کنیم. فایل فوق می‌بایست در مسیر پیش فرض کامند لاین کوبرنتیز باشد. یک نمونه از فایل yaml مربوطه به شرح زیر است. apiVersion : kubescheduler . config . ks . io / vbeta kind : KubeSchedulerConfiguration clientConnection : kubeconfig : etc / srv / kubernetes / kube - scheduler / kubeconfig می‌توان با تعریف پروفایل برای اسکژولر و استفاده از پلاگین‌های مختلف در پروفایل، رفتار پیش فرض اسکژولر را تغییر داد که این مهم بسیار پر کاربردی برای توسعه کوبرنتیر در ابزارهای می باشد. برخی از پلاگین‌های مورد استفاده در پروفایل‌های تعریفی اسکژولر به شرح زیر هستند: QueueSort : این پلاگین توابعی را ارایه می‌کند که توسط آن درخواست‌های ایجاد پاد در اسکژولر به صورت یک صف مرتب می‌شوند. PreFilter : این پلاگین جهت بررسی اطلاعات پاد و یا کلاستر قبل از فیلترینگ در اسکژولر است و قادر خواهد بود حتی یک پاد را قبل از فیلترینگ از لیست اسکژولر خارج کند. Filter : این پلاگین برای تعیین پیشفرض فیلترینگ اسکژولر در کوبرنتیز است که حتی می‌تواند نود خاص را از لیست نود‌های خود جهت ایجاد کردن پاد حدف نماید. PreScore : از این پلاگین برای تغییر پیش فرض اسکژولر قبل از امتیاز دهی استفاده می‌شود. Score : از این پلاگین برای امتیاز دادن به نود‌هایی که در لیست فیلترینگ اسکژولر وجود دارند استفاده می‌شود که نهایتا جمع امتیازهای هر نود محاسبه و هر نود که امتیاز بالاتری داشته باشد محل ایجاد پاد خواهد بود. Reserve : از این پلاگین زمانی استفاده می‌شد که منابع یک نود برای یک پاد خاص بخواهیم رزرو و در نظر گفته شود. Permit : این پلاگین می‌تواند مانع ایجاد شدن یک پاد مشخص شود. PreBind : این پلاگین هر کار مورد نیازی را انجام می‌دهد، قبل از اینکه پاد bound شود. Bind : این پلاگین برای ایجاد شدن یک پاد روی نودی مشخص است و زمانیکه از این پلاگین استفاده شود بقیه پلاگین‌ها در نظر گرفته نمی‌شوند. ( skip می‌شوند در نمونه yaml زیر پلاگین پیش فرض NodeResourcesLeastAllocated در اسکژولر را غیر فعال کرده است و پلاگین ساختگی به نام‌های MyCustomPluginA و MyCustomPluginB را معرفی و به انها وزن مشخص داده است. apiVersion : kubescheduler . config . ks . io / vbeta kind : KubeSchedulerConfiguration profiles : - plugins : score : disabled : - name : NodeResourcesLeastAllocated enabled : - name : MyCustomPluginA weight : - name : MyCustomPluginB weight : همچنین در صورتی که بخواهیم تمام پلاگین‌های پیشفرض اسکژولر در کوبرنتیز را غیر فعال کنیم می‌توانیم با این کار را انجام دهیم. در ساختار yaml زیر نیز دو پروفایل مربوط به اسکژولر معرفی شده است که در آنها تمام پلاگین‌های preScore و score غیر فعال شده اند. apiVersion : kubescheduler . config . ks . io / vbeta 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 بهینه بودن اسکژولر است که این مورد نیز باعث پایدار شدن سرویس های کاربران خواهد شد.