Kubernetes scheduler यह कैसे तय करता है कि pod कहां चलेगा?

यह दो चरणों में चलता है। filtering उन nodes को हटा देता है जो pod को होस्ट नहीं कर सकते, इसका आधार होता है allocatable capacity के मुकाबले resource requests, node selectors, वे taints जिन्हें pod tolerate नहीं करता, और volume या affinity की शर्तें। फिर scoring बचे हुए nodes को नियमों से रैंक करता है, जैसे nodes में फैलाव और कम लोड वाले को तरजीह। जीतने वाले से bind होता है, और उस node का kubelet असल में pod चालू करता है।

scheduler ऐसे pods पर नज़र रखता है जिन्हें कोई node नहीं मिला है, और उन्हें filtering तथा scoring से गुज़ारता है। filtering हर वह node बाहर कर देती है जो चल ही नहीं सकता: pod के requests के लिए पर्याप्त allocatable CPU या memory नहीं, node selector मेल नहीं खाता, ऐसा taint जिसकी कोई toleration नहीं, या ऐसा volume जो उस zone में attach नहीं हो सकता। फिर scoring बचे हुए को रैंक करती है, फैलाव और संतुलित इस्तेमाल को तरजीह देते हुए, और सबसे ऊपर वाला node जीतकर bind हो जाता है। ऑपरेशनल तौर पर जो बात मायने रखती है वह यह कि scheduling requests पर होती है, इस पर नहीं कि pod असल में कितना इस्तेमाल करता है। तो dashboards में cluster पंद्रह प्रतिशत भरा दिख सकता है और फिर भी कुछ schedule करने से मना कर सकता है, क्योंकि सबने requests असली इस्तेमाल से कहीं ऊपर सेट कर रखे हैं। जब कोई pod Pending में बैठा हो, मैं सीधे उस pod के events देखता हूं, क्योंकि scheduler ठीक ठीक बता देता है कि कौन सा predicate और कितने nodes पर फेल हुआ। placement गढ़ने के लिए मैं availability के वास्ते zones के आर पार topology spread constraints इस्तेमाल करता हूं, और खास hardware वाले nodes से आम workloads दूर रखने के लिए taints और tolerations।