لما بتشغل تطبيق على Kubernetes، الـscheduler هو اللي بياخد قرار يحدد فيه الـpod هتروح على أنهي node. لكن أحياناً بتحتاج تتحكم في القرار ده بنفسك عشان تضمن إن الـpods اللي محتاجة موارد معينة (زي GPUs أو SSDs) تروح على الـnodes اللي فيها الموارد دي بس. فيه أكتر من طريقة للتحكم ده، كل واحدة ليها استخدامها ودرجة تعقيدها.

الـ NodeName

دي أبسط وأكثر طريقة مباشرة عشان تحدد الـnode اللي الـpod هتشتغل عليها. أنت بتكتب اسم الـnode اللي عايز الـpod تشتغل عليها مباشرةً. ميزتها الأساسية هي البساطة والسرعة لأن الـscheduler بيتم تجاوزه تماماً لما يلاقي الخاصية دي مستخدمه. عيبها إنها غير مرنة، لو الـnode اللي بالاسم ده تحديداً مش متاحة لأي سبب الـpod مش هتشتغل وهتفضل في حالة Pending، وده بيخليها غير مناسبة تماماً لبيئات العمل الكبيرة اللي بتتغير باستمرار.

الـ Node Selectors

دي طريقة بسيطة ومفيدة بتستخدم الـlabels. كل اللي بتعمله إنك بتضيف label على الـnode بتاعتك (مثلاً: hardware=gpu-enabled)، وبعدين بتحدد الـlabel ده في الـspec بتاع الـpod. لو الـscheduler ملاقاش node بالـlabel ده الـpod مش هتشتغل. ميزتها هي وضوحها وسهولة استخدامها للمتطلبات البسيطة، وكمان بتختار من مجموعة من الـnodes ليهم صفة معينة، مش node واحدة بعينها. عيبها الأساسي إن لو مافيش nodes مطابقة الـpod مش هيكون عندها أي بديل ومش هاتشتغل.

الـ Node Affinity

دي نسخة أكثر مرونة من الـNode Selectors. الـNode Affinity بتسمحلك تعمل قواعد أكثر تعقيدًا للجدولة، مثلاً قواعد إلزامية (required) اللي لازم الـpod تلتزم بيها، أو قواعد مفضّلة (preferred) بتدي مرونة أكتر للـpod إنها تتجدول على أي node تانية لو القواعد المفضّلة مش متوفرة. ميزتها هي مرونتها العالية في التحكم، لكنها أكثر تعقيداً من الـNode Selectors ولا تمنع أي pods تانية من الجدولة على نفس الـnode.

الـ Taints and Tolerations

دي بقى بتشتغل بشكل عكسي تماماً. الـTaint ده علامة على الـnode بتقول “مفيش أي pod تيجي هنا إلا لو عندها toleration”. ودي مهمة عشان تحمي الـnodes المخصصة لموارد معينة زي الـGPUs أو قواعد البيانات وتمنع أي pods تانية من استخدامها بالغلط. ميزتها الرئيسية هي قدرتها على عزل الموارد بشكل فعال، لكن عيبها إنها لا تجذب الـpods للـnode، ووظيفتها الأساسية هي الطرد والمنع، وعشان كده في أغلب الأحيان بتستخدم مع طرق تانية زي Node Selectors.

الـ Custom Scheduler

لو كل اللي فات مش كفاية أو مش بيغطي كل احتياجاتك، يبقى ده البديل الأخير. الاختيار ده متقدم جداً لأنه بيسمح لك تبني الـscheduler بتاعك من الصفر أو تستخدم scheduler مبني من طرف ثالث. ده بيديك تحكم كامل في عملية الجدولة وبيخليك تحدد قواعد معقدة جداً بناءً على احتياجاتك الخاصة، زي مثلاً جدولة الـpods بناءً على تكلفة تشغيل الـnodes أو أي عوامل تانية مش متوفرة في الـscheduler الافتراضي. بيُستخدم في البيئات الكبيرة والمعقدة جداً اللي بتحتاج جدولة خاصة، زي الشركات اللي بتقدم خدمات AI أو شركات الحوسبة السحابية. ميزتها هي المرونة المطلقة والتحكم الكامل في الجدولة، لكن عيبها طبعاً هو التعقيد الكبير في البناء والإدارة.