प्रॉम्प्ट और कार्यक्षेत्र
यह नोड कंट्रोल-प्लेन/रनटाइम सीमा के बारे में एक सिस्टम-डिज़ाइन प्रश्न है। मानक CRI ListContainers, ListPodSandbox, और ListImages यूनेरी (unary) RPCs हैं जो प्रत्येक परिणाम को एक ही रिस्पॉन्स में लौटाते हैं। एक घने नोड पर, क्रमबद्ध (serialized) परिणाम gRPC की डिफ़ॉल्ट 16 MiB प्रति-संदेश सीमा से अधिक हो सकता है, जिससे kubelet सामंजस्य (reconciliation) बाधित होता है। Kubernetes v1.36 अल्फ़ा CRIListStreaming फ़ीचर गेट पेश करता है ताकि kubelet सर्वर-साइड स्ट्रीमिंग RPCs के माध्यम से परिणाम प्राप्त कर सके। डिज़ाइन को थ्रूपुट, मेमोरी, कम्पैटिबिलिटी फ़ॉलबैक और रोलआउट जोखिम को एक साथ संबोधित करना चाहिए।
साक्षात्कारकर्ता क्या मूल्यांकन करता है
- क्या आप केवल यह कहने के बजाय कि नोड बड़ा है, संदेश आकार, सीरियलाइज़ेशन आवंटन और सामंजस्य विफलता को आपस में जोड़ते हैं।
- क्या आप list-plus-events स्थिरता को बनाए रखते हुए स्ट्रीमिंग सूची ट्रांसपोर्ट को वॉच या इवेंट स्ट्रीम से अलग पहचानते हैं।
- क्या उपभोक्ता (consumer) के पास बैकप्रेशर, रद्दीकरण (cancellation), समय सीमा (deadlines) और स्पष्ट आंशिक-परिणाम सेमेन्टिक्स हैं।
- क्या आप डिफ़ॉल्ट रूप से अक्षम (disabled) अल्फ़ा गेट, रनटाइम क्षमता और स्वचालित फ़ॉलबैक को समझते हैं।
- क्या आप कैनरी, मेट्रिक्स, अलर्ट और रोलबैक शर्तों को परिभाषित कर सकते हैं।
पूछने के लिए स्पष्टीकरण प्रश्न
- पीक के समय कितने रनिंग, स्टॉप्ड और सैंडबॉक्स ऑब्जेक्ट मौजूद हैं, और यह संख्या कितनी तेजी से बढ़ती है?
- क्या कंटेनर रनटाइम तीनों स्ट्रीमिंग RPCs को लागू करता है, और अपग्रेड विंडो में कौन से संस्करण हैं?
- क्या लक्षण संदेश-सीमा त्रुटि है, kubelet मेमोरी दबाव है, या रनटाइम के अंदर धीमी सूची निर्माण है?
- क्या छोटे सामंजस्य पुनः प्रयास (reconciliation retries) स्वीकार्य हैं, और किन विफलताओं को पूरी तरह विफल (fail closed) होना चाहिए?
- क्या अल्फ़ा गेट को एक पृथक (isolated) नोड पूल पर सक्षम किया जा सकता है, और इसे कितनी जल्दी वापस (rollback) लिया जा सकता है?
30-सेकंड का उत्तर
“पहले मैं यह सत्यापित करूँगा कि यूनेरी CRI सूचियाँ प्रत्येक ऑब्जेक्ट को एक gRPC संदेश में रखती हैं, इसलिए लगभग दस हजार ऑब्जेक्ट डिफ़ॉल्ट 16 MiB सीमा तक पहुँच सकते हैं और आवंटन स्पाइक बना सकते हैं। Kubernetes v1.36 का CRIListStreaming गेट अल्फ़ा है और डिफ़ॉल्ट रूप से अक्षम है; इसे सक्षम करने के साथ, kubelet तीन सर्वर-साइड स्ट्रीमिंग RPCs का उपयोग करता है और रनटाइम चंक्स भेजता है जिन्हें उपभोक्ता धीरे-धीरे मर्ज करता है। मैं केवल उन रनटाइम्स पर कैनरी करूँगा जो RPCs का समर्थन करते हैं, बफ़र्स को सीमित करते हैं, रद्दीकरण का प्रसार करते हैं, और सूची अवधि, संदेश बाइट्स, मेमोरी और सामंजस्य त्रुटियों पर नज़र रखते हैं। असमर्थित रनटाइम स्वचालित रूप से यूनेरी पर वापस आ जाते हैं, लेकिन घने नोड्स को अभी भी एक अलर्ट की आवश्यकता होती है क्योंकि पुराना विफलता मोड बना रहता है।”
चरण-दर-चरण गहन विश्लेषण
चरण 1: एकल-संदेश विफलता को अलग करें
यूनेरी रिस्पॉन्स में पूरी सूची होती है, इसलिए क्लाइंट को प्रोटोबफ़ डिकोडिंग, ऑब्जेक्ट आवंटन और स्थिति विलय से पीक का अनुभव होता है। डिफ़ॉल्ट gRPC संदेश सीमा लगभग 16 MiB है; ऑब्जेक्ट संख्या, फ़ील्ड की लंबाई और छवि नाम यह निर्धारित करते हैं कि यह पार हो गया है या नहीं। लगभग दस हजार कंटेनर एक अनुभव-आधारित पैमाना संकेत है, कोई प्रोटोकॉल थ्रेशोल्ड नहीं; ऑब्जेक्ट आकार, रनटाइम लॉग और kubelet मेट्रिक्स के साथ इसकी पुष्टि करें।
चरण 2: स्ट्रीमिंग अनुबंध को परिभाषित करें
CRIListStreaming सक्षम होने पर, kubelet StreamContainers, StreamPodSandboxes, और StreamImages का उपयोग करता है। रनटाइम, सर्वर के रूप में, बैच भेजता है; क्लाइंट पूरी सूची को एक संदेश में रखने के बजाय प्रत्येक बैच को डिकोड और मर्ज करता है। मौजूदा सामंजस्य तर्क जारी रहने से पहले अंतिम सूची को अभी भी एक सुसंगत स्नैपशॉट की आवश्यकता होती है। एक स्ट्रीमिंग सूची कोई वॉच नहीं है और एक निरंतर इवेंट सदस्यता नहीं बनाती है।
चरण 3: बैकप्रेशर, रद्दीकरण और विफलता को नियंत्रित करें
एक डेडलाइन सेट करें और अप्रसंस्कृत (unprocessed) बैचों और ऑब्जेक्ट बफ़र्स को सीमित करें। यदि प्रसंस्करण पिछड़ जाता है, तो रीड्स को रोकें या रनटाइम को प्रवाह नियंत्रण (flow control) देखने दें। जब नोड गायब हो जाता है, सिंक संस्करण समाप्त हो जाता है, या कॉलर रद्द कर देता है, तो लीक हुए गोराउटीन्स (goroutines) और कनेक्शन को रोकते हुए स्ट्रीम को बंद कर दें। मध्य-स्ट्रीम डिस्कनेक्ट को पूर्ण सफलता के रूप में रिपोर्ट नहीं किया जाना चाहिए: अस्थायी स्नैपशॉट को त्यागें और पुनः प्रयास करें, या पूर्ण स्थिति को कमिट करने से पहले आइडम्पोटेंट (idempotent) रिकवरी के साथ स्पष्ट रूप से वर्ज़न किए गए चेकपॉइंट का उपयोग करें। पुनः प्रयासों में ऑब्जेक्ट्स की दोबारा गिनती नहीं होनी चाहिए।
चरण 4: कम्पैटिबिलिटी के साथ रोल आउट करें
इन्वेंट्री करें कि क्या रनटाइम तीनों स्ट्रीमिंग RPCs को लागू करता है, फिर एक अलग नोड पूल पर फ़ीचर गेट सक्षम करें। एक असमर्थित रनटाइम पिछड़े अनुकूलता (backward compatibility) के लिए स्वचालित रूप से यूनेरी पर वापस आ जाता है; वह फ़ॉलबैक कोई क्षमता समाधान नहीं है। नोड क्षमता को लेबल करें और यूनेरी पर बने रहने वाले उच्च-घनत्व वाले नोड्स पर अलर्ट करें। कैनरी के दौरान, स्ट्रीमिंग और फ़ॉलबैक नोड्स के बीच सूची अवधि, पीक RSS, डिकोड कतार, स्ट्रीम पुनः प्रयास और सामंजस्य विफलता दर की तुलना करें।
चरण 5: ऑब्ज़र्वेबिलिटी और क्षमता संरक्षण जोड़ें
प्रत्येक सूची के लिए ऑब्जेक्ट गणना, बैच गणना, बाइट्स प्रति बैच, कुल अवधि, पहले बैच का समय, स्ट्रीम रद्दीकरण और पुनः प्रयास के कारणों को रिकॉर्ड करें। उन्हें kubelet वर्किंग सेट, रनटाइम CPU, कनेक्शन गणना और नोड दबाव के साथ सहसंबंधित करें ताकि यह देखा जा सके कि मेमोरी पीक लंबे प्रसंस्करण समय में बदल गए हैं या नहीं। ऑब्जेक्ट सीमाएं, समय सीमा और प्रवेश नियंत्रण (admission control) सेट करें; सूची को चुपचाप छोटा करने के बजाय सीमा पार होने पर एक निदान योग्य त्रुटि लौटाएं। सफलता का अर्थ केवल एक तेज़ पहला बैच नहीं, बल्कि एक पूर्ण सामंजस्य स्थिति है।
चरण 6: रोलबैक और अपग्रेड सीमाओं को परिभाषित करें
अल्फ़ा गेट डिफ़ॉल्ट रूप से अक्षम है, और इसका दायरा kubelet कॉन्फ़िगरेशन के माध्यम से प्रतिवर्ती (reversible) होना चाहिए। यदि रनटाइम क्रैश होता है, डिस्कनेक्ट बढ़ता है, सूची स्थिरता विफल होती है, या मेमोरी में सुधार नहीं होता है, तो गेट को अक्षम करें और प्रभावित kubelets को पुनरारंभ करें, फिर रनटाइम और kubelet लॉग का निरीक्षण करें। रनटाइम अपग्रेड के दौरान क्षमता का पता लगाने और फ़ॉलबैक को बनाए रखें; बहु-संस्करण मैट्रिक्स पास होने के बाद ही नोड पूल का विस्तार करें।
उच्च गुणवत्ता वाला नमूना उत्तर
“मैं केवल gRPC सीमा बढ़ाने के बजाय, इस घटना का कारण यूनेरी CRI सूची के एकल-संदेश और ऑब्जेक्ट-आवंटन स्पाइक्स को मानूंगा। Kubernetes v1.36 का CRIListStreaming एक अल्फ़ा क्षमता है जो डिफ़ॉल्ट रूप से अक्षम है; एक बार सक्षम होने के बाद, kubelet तीन सर्वर-साइड स्ट्रीमिंग RPCs को कॉल करता है और रनटाइम कंटेनर, सैंडबॉक्स और छवि परिणामों को बैचों में भेजता है। क्लाइंट एक डेडलाइन, सीमित बफ़र्स और रद्दीकरण के साथ बैचों को एक अस्थायी स्नैपशॉट में मर्ज करता है। एक डिस्कनेक्ट अधूरे स्नैपशॉट को त्याग देता है और सामंजस्य से पहले आइडम्पोटेंट रूप से पुनः प्रयास करता है। कैनरी पहले रनटाइम RPC समर्थन को सत्यापित करता है, फिर बैच गणना, पहले और कुल अवधि, kubelet RSS, पुनः प्रयास और स्थिति त्रुटियों की तुलना करता है। असमर्थित रनटाइम यूनेरी पर वापस आ जाते हैं, इसलिए घने फ़ॉलबैक नोड्स को अभी भी अलर्ट की आवश्यकता होती है क्योंकि 16 MiB और मेमोरी-स्पाइक जोखिम बने रहते हैं। कोई भी स्थिरता त्रुटि गेट रोलबैक को ट्रिगर करती है।”
सामान्य गलतियाँ
- स्ट्रीमिंग सूची को एक वॉच मानना और स्नैपशॉट-से-इवेंट सीमा को खो देना।
- केवल gRPC सीमा को बढ़ाना जबकि सीरियलाइज़ेशन और kubelet डिकोड पीक की अनदेखी करना।
- सभी बैचों के आने से पहले सामंजस्य कमिट करना, जिससे डिस्कनेक्ट के बाद आंशिक स्थिति रह जाती है।
- यह मान लेना कि स्वचालित फ़ॉलबैक ने असमर्थित रनटाइम्स की पहचान किए बिना समस्या को हल कर दिया।
- RSS, बैच आकार, पुनः प्रयास और स्थिति पूर्णता के बजाय केवल औसत अवधि को मापना।
- ऑब्जेक्ट आकार और मेट्रिक्स की जाँच करने के बजाय लगभग दस हजार कंटेनरों को एक निश्चित ट्रिगर के रूप में प्रस्तुत करना।
अनुवर्ती प्रश्न और उत्तर
क्या मध्य-स्ट्रीम डिस्कनेक्ट के बाद पहले से प्राप्त ऑब्जेक्ट्स को रखा जा सकता है?
डिफ़ॉल्ट रूप से पूर्ण सूची के रूप में नहीं। बैचों को एक अस्थायी स्नैपशॉट में लिखें और डिस्कनेक्ट के बाद इसे त्याग दें, या किसी संस्करणित चेकपॉइंट से आइडम्पोटेंट रूप से पुनर्प्राप्त करें। प्रोटोकॉल के पूर्णता मार्कर और सत्यापन के सफल होने के बाद ही कमिट करें।
क्या होगा यदि रनटाइम केवल एक स्ट्रीमिंग RPC लागू करता है?
प्रति विधि क्षमता की जांच करें और असमर्थित विधियों को यूनेरी RPCs पर रखें। प्रति नोड एक क्षमता लेबल रिकॉर्ड करें और घने नोड्स पर अलर्ट करें; आंशिक सक्षमता प्रत्येक सूची विफलता मोड को नहीं हटाती है।
केवल संदेश सीमा क्यों नहीं बढ़ाई जाती?
एक बड़ी सीमा केवल आवंटन, प्रतिलिपि और GC स्पाइक्स को बढ़ाते हुए एकल-संदेश विफलता को टालती है। यह kubelet/रनटाइम लेटेंसी स्पाइक्स को भी बढ़ा सकता है। चंक्ड स्ट्रीमिंग को प्राथमिकता दें और पूर्ण स्थिति और क्षमता सुधार साबित करने के लिए मेट्रिक्स का उपयोग करें।