Kubernetes इंटरव्यू: आप kube-scheduler API कॉल्स को नॉन-ब्लॉकिंग कैसे बनाते हैं?

प्रॉम्प्ट और दायरा

एक क्लस्टर एक ऐसे शेड्यूलिंग प्लगइन को सक्षम करता है जो API सर्वर को कॉल करता है। जब API लेटेंसी बढ़ती है, तो सिंक्रोनस कॉल्स शेड्यूलिंग चक्रों को घेर लेती हैं और अनशेड्यूल्ड Pods जमा होने लगते हैं। KEP-5229 द्वारा वर्णित एसिंक्रोनस दृष्टिकोण को डिज़ाइन करें, जिसमें प्राथमिकता कतार (priority queue), रिक्वेस्ट कोएलेसिंग (coalescing), पुनः प्रयास, रद्दीकरण (cancellation), निष्पक्षता और रोलबैक शामिल हों।

साक्षात्कारकर्ता क्या जांच रहा है

• क्या आप सीरियल शेड्यूलिंग-चक्र सिमेंटिक्स को एसिंक्रोनस API साइड इफेक्ट्स से अलग करते हैं।
• क्या एक सीमित (bounded) प्राथमिकता कतार और कोएलेसिंग भुखमरी (starvation) और डुप्लिकेट राइट्स को रोकते हैं।
• क्या आप इडेम्पोटेंसी कीज़ (idempotency keys), डेडलाइन, रद्दीकरण, पुराने (stale) परिणाम और स्थायी त्रुटियों को परिभाषित करते हैं।
• क्या आप प्राथमिकता निष्पक्षता, बैकप्रेशर, मेट्रिक्स और फ़ीचर-गेटेड रोलआउट को कवर करते हैं।

पूछने के लिए स्पष्टीकरण प्रश्न

1. क्या यह कॉल एक रीड है, एक इडेम्पोटेंट राइट है, या बाहरी संसाधन का निर्माण है? साइड इफेक्ट्स पुनः प्रयास की सीमाओं को परिभाषित करते हैं।
2. क्या प्लगइन इवेंचुअल बाहरी स्थिति को स्वीकार कर सकता है, या बाइंडिंग से पहले स्थिति की पुष्टि करना आवश्यक है?
3. क्या विफलता Pod को अनशेड्यूलेबल के रूप में पुनः कतारबद्ध करती है, या केवल API ऑपरेशन का पुनः प्रयास करती है? उन लूप्स को अलग रखें।
4. क्लस्टर API QPS, समवर्ती शेड्यूलिंग स्तर और कतार बजट क्या हैं?

30-सेकंड उत्तर ढांचा

धीमे API ऑपरेशन्स को शेड्यूलिंग थ्रेड्स से हटाकर एक सीमित प्राथमिकता कतार में ले जाएं। शेड्यूलर एक इडेम्पोटेंसी की के साथ एक कार्य सबमिट करता है और अन्य Pods के साथ आगे बढ़ता है। समान कीज़ को कोएलेस करते हुए, Pod प्राथमिकता और प्रतीक्षा समय के अनुसार सेवा दें। कार्य पूरा होने पर केवल एक सुरक्षित पुनर्मूल्यांकन ट्रिगर होता है; पुराने परिणाम किसी Pod को बाइंड नहीं कर सकते। डेडलाइन, रद्दीकरण, बैकऑफ और समवर्ती सीमाओं के साथ त्रुटियों को पुनः प्रयास योग्य और स्थायी में वर्गीकृत करें। कतार की गहराई, प्रतीक्षा समय, सफलता दर और शेड्यूलिंग लेटेंसी का उपयोग करके फ़ीचर गेट के पीछे रोल आउट करें; थ्रेशोल्ड विफल होने पर एसिंक्रोनस पथ को अक्षम करें और वापस लौटें (fall back)।

चरण-दर-चरण गहन विश्लेषण

1. सिंक्रोनस सीमा को परिभाषित करें

शेड्यूलिंग चक्र एक नोड का चयन करता है और शेड्यूलिंग संदर्भ का स्वामी होता है; एक एसिंक्रोनस कार्य वह काम करता है जिसमें देरी हो सकती है। यदि परिणाम एक अनिवार्य बाइंडिंग पूर्व-आवश्यकता है, तो इसे पेंडिंग के रूप में मॉडल करें और पुष्टि होने तक बाइंडिंग को रोकें। केवल वही कार्य एसिंक्रोनस बनाया जा सकता है जो वर्तमान चक्र से समझौता नहीं कर सकता।

2. एक सीमित प्राथमिकता कतार बनाएं

प्रत्येक कार्य में एक Pod UID, ऑपरेशन प्रकार, इडेम्पोटेंसी की, डेडलाइन और रद्दीकरण संदर्भ होता है। कतार की एक क्षमता सीमा होती है। भरे होने पर, असीमित मेमोरी जमा करने के बजाय एक स्पष्ट बैकप्रेशर सिग्नल लौटाएं। उच्च प्राथमिकता वाले कार्य को पहले पूरा करें, जबकि एजिंग या कोटा स्थायी भुखमरी को रोकते हैं।

submit(key, priority, deadline, operation)
if same key is pending: coalesce(operation)
else if queue is full: return Backpressure
else enqueue(operation)

3. कोएलेसिंग और इडेम्पोटेंसी

कोएलेसिंग एक तार्किक ऑपरेशन के लिए समवर्ती अनुरोधों को मर्ज करता है; यह API-सर्वर इडेम्पोटेंसी प्रदान नहीं करता है। राइट्स के लिए स्थिर संसाधन कीज़, सशर्त अपडेट या सर्वर-साइड इडेम्पोटेंसी की आवश्यकता होती है। पुनः प्रयास करने से पहले पिछले परिणाम की जांच करें ताकि कोई बाहरी संसाधन दो बार न बने। विभिन्न संस्करणों या लक्ष्यों के अनुरोधों को केवल इसलिए मर्ज नहीं किया जाना चाहिए क्योंकि उनके स्ट्रिंग्स समान दिखते हैं।

4. पूर्णता, रद्दीकरण और पुराने परिणाम

एक पूर्णता इवेंट प्रकाशित करें जो संबंधित Pods से पुनर्मूल्यांकन करने के लिए कहे; यह न मान लें कि शेड्यूलिंग स्थिति अभी भी मान्य है। जब Pod हटा दिया जाता है, प्रीएम्प्ट हो जाता है, या एक नए शेड्यूलिंग संदर्भ में प्रवेश करता है, तो कार्य को रद्द कर दें। अपनी समय सीमा पार कर चुके परिणामों को छोड़ दें और कारण रिकॉर्ड करें। समाप्त हो चुके संदर्भ से सफल API कॉल को पुरानी बाइंडिंग निष्पादित नहीं करनी चाहिए।

5. पुनः प्रयास, बैकप्रेशर और निष्पक्षता

घातीय बैकऑफ के साथ टाइमआउट, क्षणिक नेटवर्क त्रुटियों और 429 प्रतिक्रियाओं का पुनः प्रयास करें। प्रमाणीकरण विफलताओं, अमान्य मापदंडों और संघर्षों के लिए स्थायी-विफलता प्रबंधन या नई गणना की आवश्यकता होती है। वर्कर संख्या, प्रति-प्लगइन कोटा और API QPS को सीमित करें। Pod शेड्यूलिंग पुनः प्रयासों को API-कार्य पुनः प्रयासों से अलग गिनें, अन्यथा एक धीमा ऑपरेशन कतार को बढ़ा सकता है।

6. संगतता, रोलआउट और रोलबैक

प्लगइन APIs और शेड्यूलिंग सिमेंटिक्स को बनाए रखें जबकि एसिंक्रोनस पथ को फ़ीचर गेट के पीछे रखें। कम जोखिम वाले प्लगइन्स और कम समवर्ती क्लस्टर्स के साथ शुरुआत करें। शेड्यूलिंग P99, कतार प्रतीक्षा, API लेटेंसी, कार्य विफलताओं, डुप्लिकेट अनुरोधों और अनशेड्यूलेबल पुनः प्रयासों की तुलना करें। यदि बैकलॉग, बाइंडिंग त्रुटियां या API दबाव आधार रेखा से अधिक हो जाता है, तो नए सबमिशन रोकें, कार्यों को ड्रेन या रद्द करें, और सिंक्रोनस पथ पर वापस लौटें।

मॉडल उच्च-गुणवत्ता वाला उत्तर

पहले वर्गीकृत करें कि किन कॉल्स में देरी हो सकती है और कौन सी बाइंडिंग पूर्व-आवश्यकताएं हैं। पूर्व को एक सीमित प्राथमिकता कतार में रखें और बाद वाले को एक स्पष्ट पेंडिंग स्थिति के रूप में प्रस्तुत करें। Pod UID, ऑपरेशन प्रकार, इडेम्पोटेंसी की, डेडलाइन और रद्दीकरण संदर्भ शामिल करें; समान कीज़ को कोएलेस करें और भरे होने पर बैकप्रेशर लागू करें। वर्कर्स केवल इडेम्पोटेंट या सुरक्षित रूप से पुनः प्रयास योग्य ऑपरेशन्स निष्पादित करते हैं, क्षणिक त्रुटियों पर बैकऑफ करते हैं और स्थायी त्रुटियों को प्लगइन विफलता प्रबंधन को सौंपते हैं। पूर्णता पुनर्मूल्यांकन को ट्रिगर करती है, कभी भी बिना शर्त बाइंड नहीं करती। फ़ीचर गेट के पीछे रोल आउट करें और शेड्यूलिंग P99, कतार गहराई, API QPS, डुप्लिकेट दर, विफलता दर और बाइंडिंग शुद्धता को मापें। उल्लंघन होने पर, सबमिशन रोकें, कार्यों को साफ़ करें और फॉलबैक करें।

सामान्य गलतियां

• प्रत्येक कॉल को बैकग्राउंड में भेजना → एक बाइंडिंग पूर्व-आवश्यकता को बायपास किया जा सकता है → पहले शेड्यूलिंग स्टेट मशीन बनाएं।
• एक वैश्विक FIFO का उपयोग करना → उच्च प्राथमिकता वाले Pods कम प्राथमिकता वाले काम के पीछे प्रतीक्षा करते हैं → प्राथमिकता, एजिंग और कोटा जोड़ें।
• अनुरोध टेक्स्ट द्वारा डुप्लिकेट हटाना → संस्करण या साइड इफेक्ट्स गलत तरीके से मर्ज हो सकते हैं → संसाधन कीज़ और स्पष्ट इडेम्पोटेंसी का उपयोग करें।
• हमेशा पुनः प्रयास करते रहना → एक API आउटेज कतार का तूफ़ान बन जाता है → डेडलाइन, बैकऑफ, प्रयास सीमा और सर्किट ब्रेकर का उपयोग करें।
• केवल थ्रूपुट मापना → लेटेंसी और शुद्धता संबंधी समस्याएं छिपी रहती हैं → कतार, API, पुनः प्रयास और बाइंडिंग का निरीक्षण करें।

अनुवर्ती प्रश्न और उत्तर

क्या एक ही Pod के लिए रीड और राइट को कोएलेस किया जा सकता है?

अकेले Pod UID से नहीं। एक रीड संसाधन संस्करण द्वारा कोएलेस हो सकता है; एक राइट के लिए ऑपरेशन प्रकार, लक्ष्य और इडेम्पोटेंसी की आवश्यकता होती है, जबकि आवश्यक क्रम को बनाए रखना होता है।

कतार भरी होने पर किस कार्य को छोड़ दिया जाना चाहिए?

डेडलाइन, प्राथमिकता और पुनर्निर्माण क्षमता का उपयोग करें। एक गैर-त्यागने योग्य बाइंडिंग पूर्व-आवश्यकता को बैकप्रेशर उत्पन्न करना चाहिए। किसी भी छोड़े गए कार्य से एक स्पष्टीकरण योग्य पुनः प्रयास या विफलता स्थिति उत्पन्न होनी चाहिए, कभी भी मूक विलोपन (silent deletion) नहीं होना चाहिए।

क्या होगा यदि Pod के प्रीएम्प्ट होने के बाद API कॉल सफल हो जाती है?

पुराने संदर्भ को आगे लिखने से रोकने के लिए रद्दीकरण और ऑब्जेक्ट-संस्करण जांच का उपयोग करें। ऑडिट के लिए सफलता को बनाए रखें, फिर पुराने बाइंड इरादे का पुन: उपयोग करने के बजाय नए शेड्यूलिंग संदर्भ को पुनर्गणना करने दें।