प्रॉम्प्ट और दायरा
प्रीइम्पशन के बाद बार-बार होने वाले फ़िल्टरिंग को कम करने के लिए एक बाहरी शेड्यूलिंग कंपोनेंट Pending Pod के लिए एक नोड की सिफारिश करता है। Kubernetes nominatedNodeName के आधार पर, सहयोग प्रोटोकॉल डिज़ाइन करें और बताएं कि यह nodeName को क्यों नहीं बदल सकता, शेड्यूलर ओवरराइट्स और रिसोर्स परिवर्तनों को कैसे हैंडल किया जाता है, और आप रोलबैक कैसे करते हैं।
Kubernetes v1.35 nominatedNodeName को बीटा के रूप में चिह्नित करता है। यह एक status फ़ील्ड है जिसका उपयोग बाहरी कंपोनेंट्स किसी पेंडिंग Pod के लिए नोड को नॉमिनेट करने के लिए कर सकते हैं। यह नॉमिनेशन बेस्ट-एफ़र्ट (best effort) होता है, शेड्यूलर इसे ओवरराइट कर सकता है, और नॉमिनेटेड नोड अभी भी शेड्यूलिंग जांच में विफल हो सकता है। इंटरव्यू यह जांचता है कि क्या आप इरादे के संकेत (intent hint) को अंतिम बाइंडिंग से अलग रखते हैं।
इंटरव्यूअर क्या जांच रहा है
Status-राइट अनुमतियाँ और ओनरशिप, नॉमिनेशन और फ़िल्टरिंग का समय, प्रीइम्पशन विक्टिम्स का ग्रेसफुल टर्मिनेशन, nodeName और nominatedNodeName के बीच सिमेंटिक अंतर, आइडम्पोटेंट और एक्सपायर होने वाले बाहरी निर्णय, मेट्रिक्स, और फ़ीचर-गेट रोलआउट व रोलबैक को कवर करें।
30-सेकंड का उत्तर
"मैं nominatedNodeName को एक वापस लेने योग्य संकेत (revocable hint) मानता हूँ, कोई वादा नहीं। एक बाहरी कंपोनेंट केवल स्पष्ट अनुमति के साथ status को अपडेट करता है और एक वर्शन व कारण रिकॉर्ड करता है; शेड्यूलर हर चक्र पर नॉमिनेटेड नोड को मान्य करता है और इसके विफल होने पर सभी उम्मीदवारों पर वापस (fallback) आ जाता है। एक उच्च-प्राथमिकता वाला Pod नोड ले सकता है, और शेड्यूलर फ़ील्ड को फिर से लिख सकता है या साफ़ कर सकता है। मैं अंतिम nodeName और बाइंडिंग इवेंट को परिणाम के रूप में उपयोग करता हूँ, हिट दर, फ़ॉलबैक दर, शेड्यूलिंग लेटेंसी और विक्टिम टर्मिनेशन समय को मापता हूँ, और यदि वे सिग्नल बिगड़ते हैं तो फ़ीचर गेट या बाहरी राइटर को अक्षम कर देता हूँ।"
चरण-दर-चरण समाधान
चरण 1: फ़ील्ड सिमेंटिक्स को अलग करें
nodeName Pod spec में एक हार्ड असाइनमेंट है। यह शेड्यूलर को बायपास करता है, और एक अनुपलब्ध या छोटे आकार का नोड सीधे Pod को विफल कर सकता है। nominatedNodeName status में होता है और पेंडिंग Pod के लिए एक उम्मीदवार को व्यक्त करता है; एक बाहरी नॉमिनेटर और शेड्यूलर प्रीइम्पशन दोनों इसे लिख सकते हैं, इसलिए यह सॉफ्ट स्टेट (soft state) है।
चरण 2: बाहरी अनुमतियाँ परिभाषित करें
बाहरी कंपोनेंट को केवल लक्षित Pod के status को अपडेट करने के लिए न्यूनतम RBAC दें, और नॉमिनेशन का कारण, एल्गोरिदम वर्शन और टाइमस्टैम्प को एनोटेशन या इवेंट में रिकॉर्ड करें। इसे spec.nodeName नहीं लिखना चाहिए या यह नहीं मानना चाहिए कि status अपडेट से kubelet तुरंत Pod को बाइंड कर देगा।
apiVersion: v1
kind: Pod
metadata:
name: batch-worker
status:
nominatedNodeName: worker-07चरण 3: शेड्यूलर ओनरशिप का सम्मान करें
शेड्यूलर प्रीइम्पशन के बाद या WaitOnPermit या PreBind में प्रवेश करते समय फ़ील्ड को लिख सकता है। बाहरी कंपोनेंट को ओवरराइट्स को स्वीकार करना चाहिए और राइट वॉर (write war) से बचना चाहिए। प्रत्येक अपडेट से पहले resourceVersion की तुलना करें; टकराव (conflict) होने पर, फिर से पढ़ें और पुनर्गणना करें।
चरण 4: फ़िल्टरिंग और फ़ॉलबैक डिज़ाइन करें
शेड्यूलर पहले यह जांचता है कि क्या नॉमिनेटेड नोड अभी भी रिसोर्स, अफ़िनिटी, taint और टोपोलॉजी फ़िल्टर पास करता है। यदि ऐसा नहीं होता है, तो सामान्य उम्मीदवार प्रवाह जारी रहता है। बाहरी कंपोनेंट को नॉमिनेट करने से पहले एक तेज़ प्री-चेक करना चाहिए, लेकिन इसका परिणाम कभी भी शेड्यूलर का अंतिम निर्णय नहीं होता है।
चरण 5: प्रीइम्पशन विंडो को संभालें
प्रीइम्पशन विक्टिम्स को एक ग्रेसफुल टर्मिनेशन अवधि देता है, इसलिए जब तक वे बाहर नहीं निकल जाते, नॉमिनेटेड नोड अनुपयुक्त बना रह सकता है। शेड्यूलर फ़ील्ड को साफ़ कर सकता है या किसी उच्च-प्राथमिकता वाले Pod को नोड सौंप सकता है। व्यावसायिक ट्रैफ़िक को नॉमिनेशन status को तत्परता (readiness) मानने के बजाय बाइंडिंग इवेंट की प्रतीक्षा करनी चाहिए।
चरण 6: निर्णयों को आइडम्पोटेंट और एक्सपायर होने योग्य बनाएं
प्रत्येक नॉमिनेशन के साथ एक ट्रेस करने योग्य निर्णय ID और छोटा TTL संलग्न करें। नोड-रिसोर्स परिवर्तन, Pod spec अपडेट, प्राथमिकता में बदलाव, या कतार का पुनर्गठन पुराने नॉमिनेशन को पुराना (stale) बना देता है। बार-बार समाधान (reconciliation) केवल तब तक समान मान लिखना चाहिए जब तक निर्णय मान्य रहता है।
चरण 7: ऑब्ज़र्वेबिलिटी परिभाषित करें
नॉमिनेशन-राइट सफलता, status टकराव, नॉमिनेटेड नोड्स पर फ़िल्टर विफलताएं, फ़ॉलबैक शेड्यूलिंग लेटेंसी, Pending-से-बाइंडिंग समय, विक्टिम टर्मिनेशन समय और फ़ील्ड-क्लियर काउंट को मापें। रिग्रेशन का पता लगाने के लिए उन्हें क्लस्टर, प्राथमिकता, शेड्यूलर और बाहरी एल्गोरिदम वर्शन द्वारा विभाजित करें।
चरण 8: रोल आउट और रोल बैक करें
शेड्यूलिंग लेटेंसी और प्रीइम्पशन परिणामों की तुलना करते हुए, पहले कुछ नेमस्पेस और कम जोखिम वाले PriorityClasses में इस पाथ को सक्षम करें। यदि फ़िल्टरिंग समय, गलत बाइंडिंग, या status चर्न बढ़ता है, तो बाहरी status राइट्स को रोकें और शेड्यूलर फ़ीचर गेट को अक्षम करें। सामान्य शेड्यूलिंग को उपलब्ध रखें; nodeName लिखकर फ़ॉलबैक को बाध्य न करें।
ट्रेड-ऑफ़ और सीमाएं
nominatedNodeName या nodeName
nominatedNodeName फ़िल्टरिंग, प्रीइम्पशन और बाइंडिंग को शेड्यूलर के नियंत्रण में रखता है, जिससे यह बाहरी सिफारिश के लिए उपयुक्त हो जाता है। nodeName शेड्यूलर को बायपास करता है और उन्नत मामलों के लिए आरक्षित है जहां कॉलर रिसोर्स और विफलता की जिम्मेदारी स्वीकार करता है; यह एक सामान्य त्वरण तंत्र (acceleration mechanism) नहीं है।
पहले संकेत या प्रत्येक नोड को स्कैन करना
पहले संकेत को आज़माने से प्रीइम्पशन के बाद बड़े क्लस्टर में बार-बार होने वाले फ़िल्टरिंग को कम किया जा सकता है, लेकिन नोड बदल चुका हो सकता है। एक पूर्ण फ़ॉलबैक स्कैन शुद्धता का आधार (correctness floor) है और इसे प्रदर्शन अनुकूलन के लिए हटाया नहीं जा सकता है।
दृश्यता या नियंत्रण
Status अंतिम नियंत्रण दिए बिना शेड्यूलिंग के इरादे को दृश्यमान बनाता है। अलर्ट, कंट्रोलर्स और बिज़नेस ऑटोमेशन को केवल nominatedNodeName के बजाय बाइंडिंग, FailedScheduling और इवेंट्स को देखना चाहिए।
विफलता अभ्यास और विकास
नॉमिनेटेड नोड अपनी क्षमता खो देता है
नॉमिनेशन के बाद एक उच्च-प्राथमिकता वाला Pod शुरू करें और सत्यापित करें कि शेड्यूलर फ़ील्ड को ओवरराइट या साफ़ करता है और मूल Pod स्थायी रूप से Pending रहने के बजाय फ़ॉलबैक करता है।
एक status अपडेट टकराव (conflict) करता है
एक ही Pod के status को समवर्ती (concurrently) रूप से अपडेट करें और सत्यापित करें कि बाहरी कंपोनेंट शेड्यूलर को पुराने ऑब्जेक्ट से ओवरराइट करने के बजाय resourceVersion टकराव के बाद फिर से पढ़ता है।
विक्टिम टर्मिनेशन धीमा है
प्रीइम्पशन विक्टिम को एक लंबा termination grace period दें। पुष्टि करें कि नॉमिनेटेड नोड बहुत जल्दी उपलब्ध के रूप में रिपोर्ट न हो और Pending-से-बाइंडिंग लेटेंसी की पूंछ (tail) की निगरानी करें।
सामान्य गलतियाँ और फॉलो-अप
गलती 1: nominatedNodeName को बाइंडिंग परिणाम के रूप में मानना
फॉलो-अप: क्या फ़ील्ड मौजूद होने के बाद Pod के वहां चलने की गारंटी है? नहीं। शेड्यूलर फिर से फ़िल्टर करता है; अंतिम nodeName और बाइंडिंग इवेंट ही परिणाम हैं।
गलती 2: नॉमिनेशन को nodeName से बदलना
फॉलो-अप: सीधे nodeName क्यों न लिखें? यह रिसोर्स, taint, अफ़िनिटी और प्रीइम्पशन सुरक्षा उपायों को बायपास करता है और किसी अनुपयुक्त नोड पर विफल हो सकता है।
गलती 3: बार-बार status को ओवरराइट करना
फॉलो-अप: क्या होगा यदि शेड्यूलर फ़ील्ड को बदल देता है? ओनरशिप रेस को स्वीकार करें, शेड्यूलर से लड़ने के बजाय resourceVersion, निर्णय TTLs और आइडम्पोटेंट समाधान का उपयोग करें।
गहन फॉलो-अप और मॉडल उत्तर
नॉमिनेटेड नोड अंतिम क्यों नहीं हो सकता है?
विक्टिम टर्मिनेशन के दौरान, कोई अन्य नोड क्षमता जारी कर सकता है या एक उच्च-प्राथमिकता वाला Pod नॉमिनेटेड नोड ले सकता है। शेड्यूलर प्रयास जारी रखता है और नॉमिनेशन को साफ़ या ओवरराइट कर सकता है।
आप कैसे साबित करते हैं कि अनुकूलन काम करता है?
रोलआउट से पहले और बाद में फ़िल्टर समय, Pending-से-बाइंडिंग लेटेंसी, नॉमिनेशन हिट दर, फ़ॉलबैक दर और विक्टिम टर्मिनेशन समय की तुलना करें। केवल राइट काउंट तेज़ शेड्यूलिंग को साबित नहीं करता है।
बाहरी कंपोनेंट के लिए न्यूनतम सुरक्षा सीमा क्या है?
केवल अधिकृत Pods पर status अपडेट करें, कभी भी nodeName या प्राथमिकता और रिसोर्स spec न लिखें, और बाइंडिंग इवेंट के माध्यम से परिणाम की पुष्टि करें। प्रत्येक निर्णय एक्सपायर होने योग्य, ऑडिट योग्य और रोलबैक करने योग्य होना चाहिए।