प्रॉम्प्ट और स्कोप
नोड बूट होने के बाद, kubelet Ready रिपोर्ट कर सकता है, भले ही GPU ड्राइवर, CNI, स्टोरेज प्लगइन या लोकल एजेंट उपयोग के योग्य न हो। यदि शेड्यूलर बहुत जल्दी Pods को शेड्यूल कर देता है, तो वर्कलोड बार-बार विफल होते हैं या बिना किसी स्पष्ट त्रुटि के धीमे हो जाते हैं। एक Node Readiness Controller डिज़ाइन करें जो अतिरिक्त पूर्व-आवश्यकताओं (prerequisites) को घोषित करे, उनके पूरा होने तक शेड्यूलिंग को रोके, और नोड के जीवनचक्र में बाद में किसी निर्भरता (dependency) के विफल होने पर उसे संभाले।
यह प्लेटफ़ॉर्म इंजीनियरिंग, SRE और Kubernetes कंट्रोलर इंटरव्यू के लिए उपयुक्त है। सार्वजनिक Kubernetes इंटरव्यू सामग्री NotReady नोड्स, taints और tolerations, और Pending-Pod समस्या निवारण को कवर करती है। आधिकारिक Node Readiness Controller प्रोजेक्ट एक NodeReadinessRule API, स्वचालित taint प्रबंधन, केवल-बूटस्ट्रैप और निरंतर मोड, और dry run का वर्णन करता है। नीचे दिया गया डिज़ाइन एक सुविचारित इंटरव्यू उत्तर है, न कि किसी कंपनी का दावा किया गया प्रश्न।
इंटरव्यूअर क्या मूल्यांकन करता है
इंटरव्यूअर यह देखना चाहता है कि आप "नोड Ready है" को "नोड इस वर्कलोड वर्ग के लिए उपयुक्त है" से अलग करते हैं या नहीं। एक मजबूत उत्तर कंडीशन स्रोतों, नियम के दायरे, taint idempotency, रीस्टार्ट रिकवरी, observable स्थिति, और गलती से पूरे फ्लीट को ब्लॉक होने से बचाने के उपायों को परिभाषित करता है।
एक कमजोर उत्तर एक ऐसा DaemonSet लिखता है जो सब कुछ जांचता है। एक मजबूत उत्तर यह समझाता है कि कंडीशन रिपोर्टिंग को पॉलिसी प्रवर्तन (policy enforcement) से अलग क्यों किया जाता है, केवल-बूटस्ट्रैप निरंतर प्रवर्तन से कैसे भिन्न है, dry run ब्लास्ट रेडियस का अनुमान कैसे लगाता है, और पुरानी पड़ चुकी कंडीशन्स, कंट्रोलर पार्टिशन और परस्पर विरोधी नियमों को कैसे संभाला जाए।
उत्तर देने से पहले स्पष्ट करने वाले प्रश्न
- क्या कंट्रोलर को केवल नोड बूटस्ट्रैप की रक्षा करनी चाहिए, या बाद में ड्राइवर विफल होने पर नई शेड्यूलिंग को भी रोकना चाहिए? यह प्रवर्तन मोड और रिकवरी कार्रवाई को निर्धारित करता है।
- कंडीशन्स कौन उत्पन्न करता है: Node Problem Detector, एक डिवाइस प्लगइन, एक CNI एजेंट, या एक कस्टम DaemonSet? अविश्वसनीय स्रोतों को पहचान और नवीनता (freshness) जांच की आवश्यकता होती है।
- क्या सभी कंडीशन्स का True होना आवश्यक है, या कोई भी एक कंडीशन पास हो सकती है? GPU, नेटवर्क और स्टोरेज को आमतौर पर अलग-अलग नोड पूल और नियमों की आवश्यकता होती है।
- क्या कोई गलत (false) कंडीशन नए Pods को ब्लॉक करती है या मौजूदा Pods को बेदखल (evict) करती है? पहला प्रतिवर्ती (reversible) है; दूसरे को मजबूत साक्ष्य और एक अलग निष्कासन (eviction) नीति की आवश्यकता होती है।
30-सेकंड का उत्तर ढांचा
"मैं कंडीशन रिपोर्टिंग, नियम मूल्यांकन और taint निष्पादन को अलग रखूँगा। एक NodeReadinessRule नोड्स का चयन करता है और उन कंडीशन्स को सूचीबद्ध करता है जिनका True होना आवश्यक है; कंट्रोलर केवल-बूटस्ट्रैप या निरंतर प्रवर्तन के अनुसार NoSchedule taint को जोड़ता या हटाता है। राइट्स (Writes) idempotent, observable और dry-run सक्षम होने चाहिए। नियम और कंडीशन स्थिति API सर्वर में रहती है ताकि रीस्टार्ट के बाद स्थिति का पुनर्निर्माण किया जा सके। मैं पहले प्रभाव को लॉग करूँगा, एक नोड पूल को सक्षम करूँगा, और विफलता होने पर पूरे क्लस्टर को unschedulable बनाने के बजाय राइट्स को रोकूँगा या नियम को वापस (rollback) लूँगा।"
चरण-दर-चरण उत्तर
सीमा से शुरुआत करें। कंट्रोलर GPU या नेटवर्क की जांच (probe) नहीं करता है; यह Node Conditions का उपभोग करता है। Node Problem Detector, एक डिवाइस प्लगइन, या एक कस्टम एजेंट तथ्यों की रिपोर्ट करता है। यह मौजूदा प्रोब इकोसिस्टम का पुनर्चिंतन करता है और "जांच विफल रही" को "शेड्यूलिंग की अनुमति है" से अलग करता है। एक कंडीशन में प्रकार, स्थिति, अपडेट समय, स्रोत और एक अवलोकन पीढ़ी (observation generation) होनी चाहिए; कोई पुरानी कंडीशन वर्कलोड को अधिकृत करना जारी नहीं रख सकती है।
नियम मॉडल में एक नोड चयनकर्ता, कंडीशन सेट, लक्ष्य taint और प्रवर्तन मोड शामिल हैं। आधिकारिक प्रोजेक्ट के लिए आवश्यक है कि taint को हटाने से पहले प्रत्येक सूचीबद्ध कंडीशन संतुष्ट हो और यह लेबल द्वारा विषम नोड्स का चयन करने का समर्थन करता है। bootstrap-only इनिशियलाइज़ेशन सफल होने के बाद उस नियम का मूल्यांकन करना बंद कर देता है। continuous तब taint को फिर से जोड़ता है जब कोई महत्वपूर्ण कंडीशन बाद में False हो जाती है। पहला मोड इमेज प्री-पुल या हार्डवेयर सेटअप के लिए उपयुक्त है; दूसरा उन निर्भरताओं के लिए उपयुक्त है जिन्हें लगातार स्वस्थ रहना चाहिए।
कंट्रोल लूप नियमों, नोड्स और कंडीशन्स को पढ़ता है, वांछित taints की गणना करता है, और रिसोर्स वर्ज़न का उपयोग करके अपडेट लागू करता है। राइट्स idempotent होने चाहिए और टकराव होने पर पुनः प्रयास किए जाने चाहिए: केवल इस कंट्रोलर के स्वामित्व वाले taints को प्रबंधित करें, कभी भी किसी व्यवस्थापक या किसी अन्य कंट्रोलर के taint को न हटाएं। यदि दो नियम अलग-अलग अर्थों के साथ एक ही taint कुंजी का दावा करते हैं, तो एडमिशन वैलिडेशन को टकराव को अस्वीकार करना चाहिए; अन्यथा एक नियम गलती से दूसरे नियम की सुरक्षा को हटा सकता है।
विफलता पथों को स्पष्ट करें। जब कोई रिपोर्टर अपडेट करना बंद कर देता है, तो fail-closed या fail-open एक उत्पाद विकल्प है: एक महत्वपूर्ण सुरक्षा निर्भरता fail-closed हो सकती है, जबकि कम जोखिम वाला बूटस्ट्रैप एक छोटे TTL के साथ fail-open हो सकता है। एक डिस्कनेक्ट किए गए कंट्रोलर को मौजूदा taints को साफ़ नहीं करना चाहिए; यह रिकवरी के बाद रीकॉन्साइल (reconcile) करता है। यदि कोई नोड हटा दिया जाता है या उसके लेबल बदल जाते हैं, तो नियम को गैर-लागू के रूप में चिह्नित करें ताकि पुरानी स्थिति किसी प्रतिस्थापन नोड को ब्लॉक न कर सके।
ऑब्जर्वेबिलिटी में प्रति नियम मेल खाने वाले नोड्स, अनुपलब्ध या पुरानी कंडीशन्स, वांछित बनाम वास्तविक taint ड्रिफ्ट, किसी कंडीशन के True होने से लेकर शेड्यूलिंग योग्यता तक की लेटेंसी, और गेटेड-Pod संख्या शामिल होनी चाहिए। स्टेटस को क्रेडेंशियल्स या संवेदनशील डिवाइस डेटा को लॉग किए बिना विफल कंडीशन और अंतिम मूल्यांकन समय को प्रदर्शित करना चाहिए। कंट्रोल प्लेन की सुरक्षा के लिए, नोड और नियम के अनुसार कतारबद्ध करें, तेजी से होने वाले कंडीशन परिवर्तनों को संयोजित (coalesce) करें, और प्रत्येक हार्टबीट के लिए API-सर्वर राइट से बचें।
Dry run के साथ रोल आउट करें। आधिकारिक प्रोजेक्ट का dry run taints लागू किए बिना इच्छित कार्रवाइयों को रिकॉर्ड करता है और नियम स्थिति को अपडेट करता है। प्रभावित नोड्स और Pending Pods का निरीक्षण करें, फिर एक नोड पूल को सक्षम करें। रोलबैक नए नियम मूल्यांकन को रोकता है, मौजूदा सुरक्षा taints को बनाए रखता है, कंडीशन स्रोत को ठीक करता है, और फिर से रीकॉन्साइल करता है; यह एक कमांड के साथ प्रत्येक NoSchedule taint को नहीं हटाता है।
विकल्पों में प्रत्येक वर्कलोड में nodeSelector जोड़ना, Pod schedulingGates का उपयोग करना, या बूटस्ट्रैप स्क्रिप्ट से taints जोड़ना शामिल है। वर्कलोड चयनकर्ता ज्ञात उपभोक्ताओं के एक छोटे सेट के लिए उपयुक्त हैं लेकिन भविष्य के Pods को छोड़ देते हैं। एक Pod gate एक Pod की सुरक्षा करता है, जबकि यह समस्या एक नोड की सुरक्षा करती है। स्क्रिप्ट में साझा स्थिति और रिकवरी की कमी होती है। एक कंट्रोलर CRD, एक कंट्रोल लूप और एक अन्य विफलता डोमेन की लागत पर, विषम नोड्स और साझा क्लस्टरों के लिए उपयुक्त है।
उच्च-गुणवत्ता वाला नमूना उत्तर
मैं केवल "क्या नए Pods को यहाँ शेड्यूल किया जा सकता है?" के लिए जिम्मेदार एक डिक्लेरेटिव कंट्रोलर का निर्माण करूँगा। Node Problem Detector, डिवाइस प्लगइन्स, या CNI एजेंट्स कंडीशन्स लिखते हैं; कंट्रोलर उनके प्रोब्स की नकल नहीं करता है। एक नियम नोड्स का चयन करता है, उन कंडीशन्स को सूचीबद्ध करता है जिनका True होना आवश्यक है, एक NoSchedule taint का नाम देता है, और एक मोड चुनता है। बूटस्ट्रैप कार्य bootstrap-only का उपयोग करता है: एक बार GPU ड्राइवर और नेटवर्क एजेंट तैयार हो जाने के बाद, taint हटा दिया जाता है। निरंतर निर्भरताएँ continuous का उपयोग करती हैं: बाद में विफलता होने पर taint फिर से जुड़ जाता है, लेकिन यह मौजूदा Pods को स्वचालित रूप से बेदखल नहीं करता है।
कंट्रोलर केवल अपने स्वामित्व मार्कर वाले taints का स्वामित्व लेता है और उनका समाधान करता है, जो idempotency के लिए रिसोर्स वर्ज़न और टकराव पुनः प्रयासों का उपयोग करता है। समान taint कुंजी के लिए परस्पर विरोधी दावों को अस्वीकार कर दिया जाता है। नियम स्थिति मेल खाने वाले नोड्स, अनुपलब्ध या पुरानी कंडीशन्स, taint ड्रिफ्ट और मूल्यांकन समय की रिपोर्ट करती है। मैं पहले dry run तैनात करूँगा, Pending Pods के साथ अनुमानित प्रभाव की तुलना करूँगा, और एक नोड पूल पर कैनरी परीक्षण करूँगा। कंट्रोलर डाउन होने के दौरान, मौजूदा सुरक्षा बनाए रखें; रिकवरी के बाद, रीकॉन्साइल करें। रोलबैक हर क्लस्टर taint को साफ़ करने के बजाय मूल्यांकन को रोकता है और कंडीशन स्रोत की मरम्मत करता है।
सामान्य गलतियाँ
- गलती → कंट्रोलर को हर नोड में SSH कराना; विफलता → यह Kubernetes कंडीशन स्रोतों को बायपास करता है और अनुमति सीमा को विस्तृत करता है; समाधान → विशेष एजेंट्स को कंडीशन्स की रिपोर्ट करने दें और कंट्रोलर में पॉलिसी मूल्यांकन रखें।
- गलती → एक बार के बूटस्ट्रैप के लिए
continuousका उपयोग करना; विफलता → पूर्ण हो चुके नोड्स लगातार अस्थिर (flap) रहते हैं और unschedulable बने रहते हैं; समाधान →bootstrap-onlyका उपयोग करें और पूर्णता को रिकॉर्ड करें। - गलती → समान कुंजी वाले किसी भी taint को हटा देना; विफलता → किसी व्यवस्थापक या किसी अन्य कंट्रोलर की सुरक्षा समाप्त हो सकती है; समाधान → ओनरशिप मार्कर, टकराव वैलिडेशन और फ़ील्ड-स्तरीय अपडेट का उपयोग करें।
- गलती → कंट्रोलर रीस्टार्ट के बाद सभी taints को साफ़ करना; विफलता → रिकवरी विंडो के दौरान वर्कलोड गैर-तैयार नोड्स पर लैंड कर जाते हैं; समाधान → स्थिति बनाए रखें और रिसोर्स-वर्ज़न जांच के साथ रीकॉन्साइल करें।
फॉलो-अप प्रश्न और प्रतिक्रियाएं
क्या होगा यदि कंडीशन रिपोर्टर अपडेट करना बंद कर देता है: fail-open या fail-closed?
निर्भरता को वर्गीकृत करें। GPU ड्राइवर, क्रिप्टो मॉड्यूल और क्रॉस-ज़ोन नेटवर्किंग समाप्ति समय (expiry time) के साथ fail-closed का उपयोग कर सकते हैं, जिससे क्षमता के अस्थायी नुकसान को स्वीकार किया जा सकता है। कम जोखिम वाला एक बार का बूटस्ट्रैप एक सफल रिकॉर्ड और छोटे TTL के साथ fail-open हो सकता है। दोनों ही मामलों में, "unknown" को False से अलग मापें ताकि गायब टेलीमेट्री को स्वास्थ्य न समझ लिया जाए।
दो नियम एक नोड से मेल खाते हैं और एक ही taint कुंजी का दावा करते हैं। आप क्या करेंगे?
एडमिशन या नियम संकलन के दौरान सिमेंटिक टकराव को अस्वीकार करें, जिसके लिए अलग कुंजियों या एक स्पष्ट समग्र स्वामी (aggregate owner) की आवश्यकता होती है। कंट्रोलर प्रत्येक नियम के लिए वांछित स्थिति रखता है और एक समग्र taint को केवल तभी हटाता है जब प्रत्येक स्वामी अपनी रिलीज़ स्थिति को पूरा करता है। रीकॉन्साइल करने वाला अंतिम नियम अकेले इसे नहीं हटा सकता है।
आप कैसे साबित करेंगे कि dry run क्लस्टर क्षमता को समाप्त नहीं करेगा?
मेल खाने वाले नोड्स, उपलब्ध शेड्यूलिंग योग्य क्षमता, Pod अनुरोधों और टोपोलॉजी स्प्रेड को एक प्रभाव रिपोर्ट में रखें। एक नोड पूल का अनुकरण करें, गेटेड Pods, ऑटोस्केलर कतारों और शेड्यूलिंग लेटेंसी का निरीक्षण करें, फिर विस्तार करें। यदि महत्वपूर्ण वर्कलोड में हेडरूम की कमी है, तो प्रवर्तन से पहले नोड पूल या नियम को बदलें।
जब कोई नोड निरंतर तैयारी में विफल हो जाता है तो मौजूदा Pods को बेदखल क्यों नहीं किया जाता है?
"कोई नया Pod नहीं" और "मौजूदा Pods असुरक्षित हैं" अलग-अलग निर्णय हैं। NoSchedule नए प्लेसमेंट को रोकते हुए निरंतरता बनाए रखता है; निष्कासन (eviction) को अपने स्वयं के PDB, ग्रेसफुल टर्मिनेशन और डेटा-सुरक्षा नीति की आवश्यकता होती है। एक अलग निष्कासन कंट्रोलर को केवल तभी कार्य करना चाहिए जब साक्ष्य यह कहते हों कि मौजूदा वर्कलोड असुरक्षित हैं।