प्रश्न और संदर्भ
एक कंट्रोलर को केवल ऑब्जेक्ट नाम, लेबल्स, नेमस्पेस और resourceVersion की आवश्यकता होती है, फिर भी यह बड़े Pod spec और status फ़ील्ड्स को पढ़ता है। लिस्ट अनुरोधों के लिए Kubernetes मेटाडेटा-ओनली नेगोशिएशन का उपयोग करें, फिर असमर्थित एग्रीगेटेड APIs, 406 रिस्पॉन्स और उसके बाद के watch की व्याख्या करें।
इंटरव्यूअर क्या जांच रहा है
- क्या आप
Acceptपैरामीटर्स को सही ढंग से बनाते हैं और सिंगल-ऑब्जेक्ट तथा लिस्ट निरूपण (representations) में अंतर करते हैं। - क्या आप आंशिक रिस्पॉन्स को एक निरूपण (representation) के रूप में समझते हैं, न कि एक मनमाने फ़ील्ड-फ़िल्टर पैच के रूप में।
- क्या आप स्टार्टअप को विफल किए बिना या हमेशा के लिए पुनः प्रयास (retry) किए बिना 406, वर्शन-स्क्यू और पूर्ण-ऑब्जेक्ट फ़ॉलबैक को डिज़ाइन करते हैं।
- क्या list/watch
resourceVersionऔर कैश कंसिस्टेंसी सही बनी रहती है।
पहले पूछे जाने वाले स्पष्टीकरण प्रश्न
रिसोर्स और सर्वर सीमा
क्या टारगेट एक in-tree API, एक CRD, या एक एग्रीगेटेड API है? क्या प्रत्येक apiserver और प्रॉक्सी मेटाडेटा-ओनली रिस्पॉन्स का समर्थन करते हैं?
उपयोग पैटर्न
क्या क्लाइंट केवल अस्तित्व और लेबल इंडेक्स बनाता है, या इसे बाद में spec की आवश्यकता होगी? क्या इसे लिस्ट के तुरंत बाद watch शुरू करना चाहिए?
विफलता नीति (Failure policy)
क्या आंशिक रिस्पॉन्स अनुपलब्ध होने पर क्लाइंट पूर्ण ऑब्जेक्ट्स पढ़ सकता है, या बैंडविड्थ और मेमोरी बजट की सुरक्षा के लिए इसे स्पष्ट रूप से विफल होना चाहिए?
30-सेकंड का उत्तर ढांचा
मैं लिस्ट के लिए application/json;as=PartialObjectMetadataList;g=meta.k8s.io;v=v1 को प्राथमिकता दूंगा और केवल मेटाडेटा के साथ लिस्ट resourceVersion को स्वीकार करूंगा। मैं फॉलबैक के रूप में निम्न-गुणवत्ता वाले application/json को जोड़ूंगा, फिर रिस्पॉन्स kind की जांच करूंगा ताकि पता चल सके कि वास्तव में क्या लौटाया गया था। बिना फॉलबैक के, 406 को पुनः प्रयास करने योग्य स्टॉर्म के बजाय एक असमर्थित क्षमता के रूप में समझें। लौटाए गए रिसोर्स वर्शन से watch शुरू करें और निरूपण को कैश में रिकॉर्ड करें।
डीप-डाइव उत्तर चरण
1. निरूपणों (Representations) में अंतर करें
एक ऑब्जेक्ट के लिए as=PartialObjectMetadata और एक कलेक्शन के लिए as=PartialObjectMetadataList का उपयोग करें। रिस्पॉन्स spec और status को छोड़ देता है और मेटाडेटा को बनाए रखता है; यह सीरियलाइज़ेशन, नेटवर्क और डिकोड लागत को कम करता है लेकिन उन कॉलर्स की सेवा नहीं कर सकता जिन्हें व्यावसायिक फ़ील्ड की आवश्यकता होती है।
2. एक फ़ॉलबैक अनुरोध का निर्माण करें
GET /api/v1/pods
Accept: application/json;as=PartialObjectMetadataList;g=meta.k8s.io;v=v1, application/json;q=0.9यदि पसंदीदा निरूपण अनुपलब्ध है, तो सर्वर सामान्य JSON चुन सकता है। क्लाइंट को kind, apiVersion, और Content-Type का निरीक्षण करना चाहिए; केवल HTTP 200 यह साबित नहीं करता है कि आंशिक ऑब्जेक्ट लौटाया गया था।
3. स्ट्रिक्ट मोड और 406 को संभालें
जब अनुरोध केवल एक आंशिक निरूपण का विज्ञापन करता है जिसे टारगेट API सपोर्ट नहीं करता है, तो Kubernetes 406 लौटाता है। इसे एक क्षमता परिणाम के रूप में रिकॉर्ड करें और नीति के अनुसार पूर्ण ऑब्जेक्ट पर स्विच करें, रिसोर्स को छोड़ दें, या कॉन्फ़िगरेशन त्रुटि प्रदर्शित करें। एक ही Accept हेडर को अनिश्चित काल तक पुनः प्रयास न करें या 406 को एक क्षणिक नेटवर्क विफलता के रूप में वर्गीकृत न करें।
4. एग्रीगेटेड APIs और CRDs को संभालें
बिल्ट-इन APIs आम तौर पर मेटाडेटा-ओनली रिस्पॉन्स का समर्थन करते हैं, लेकिन एग्रीगेशन के पीछे एक API ऐसा नहीं कर सकता है। CRD और तृतीय-पक्ष कार्यान्वयन भी केवल पूर्ण ऑब्जेक्ट्स को प्रदर्शित कर सकते हैं। रिसोर्स और सर्वर द्वारा क्षमताओं की जांच करें, समाप्ति (expiry) के साथ परिणाम को कैश करें, और कभी भी एक रिसोर्स की सफलता को हर रिसोर्स के लिए सामान्यीकृत न करें।
5. list/watch कंसिस्टेंसी को बनाए रखें
लिस्ट resourceVersion watch के लिए शुरुआती बिंदु बना रहता है। इसे सहेजें, समाप्ति, डिस्कनेक्ट और relist को संभालें, और याद रखें कि मेटाडेटा-ओनली रिसोर्स-वर्शन सिमेंटिक्स के बजाय निरूपण को बदलता है। एक पूर्ण-ऑब्जेक्ट फ़ॉलबैक को कैश को पॉप्युलेट करने के लिए उसी वर्शन का उपयोग करना चाहिए, जिससे पुराना मिश्रित डेटा से बचा जा सके।
6. कैश और अपग्रेड व्यवहार को डिज़ाइन करें
कैश प्रविष्टियों को निरूपण और फ़ील्ड उपलब्धता रिकॉर्ड करनी चाहिए। एक पाथ जिसे spec की आवश्यकता होती है, उसे यह नहीं मानना चाहिए कि यह मेटाडेटा-ओनली प्रविष्टि में मौजूद है; नाम से एक नियंत्रित पूर्ण GET जारी करें। सर्वर या प्रॉक्सी को अपग्रेड करने के बाद Accept क्षमता की फिर से जांच करें ताकि एक अनावश्यक पूर्ण-ऑब्जेक्ट पाथ हमेशा के लिए न बना रहे।
7. लागत और सुरक्षा को मापें
अनुरोध बाइट्स, डिकोड CPU, हीप पीक, लिस्ट लेटेंसी, watch पुनः कनेक्ट दर और पूर्ण-GET अनुपात की तुलना करें। लेबल्स, एनोटेशन और ओनर संदर्भों में अभी भी संवेदनशील डेटा हो सकता है; केवल मेटाडेटा लौटाए जाने के कारण प्राधिकरण (authorization) गायब नहीं होता है। प्रत्येक एनोटेशन को लॉग और मेट्रिक्स में डंप करने से बचें।
एक उच्च-गुणवत्ता वाला नमूना उत्तर
मैं PartialObjectMetadataList को प्राथमिकता दूंगा और फ़ॉलबैक के रूप में निम्न-गुणवत्ता वाले सामान्य JSON को शामिल करूंगा। क्लाइंट लौटाए गए kind को मान्य करता है और 406 पर एक क्षमता स्विच करता है। यह लिस्ट resourceVersion से एक watch शुरू करता है और कैश में फ़ील्ड उपलब्धता रिकॉर्ड करता है। एग्रीगेटेड APIs, CRDs, और spec की आवश्यकता वाले पाथ्स को अलग-अलग जांच और रीड मिलते हैं, जबकि बाइट्स, CPU, मेमोरी और रीकनेक्ट मेट्रिक्स लाभ को साबित करते हैं।
सामान्य गलतियाँ
- लिस्ट के लिए सिंगल-ऑब्जेक्ट
PartialObjectMetadataपैरामीटर का उपयोग करना। - मेटाडेटा-ओनली को मनमाना सर्वर-साइड फ़ील्ड फ़िल्टरिंग मानना और रिस्पॉन्स kind को अनदेखा करना।
- जब कोई फ़ॉलबैक नहीं दिया गया हो तो 406 को पुनः प्रयास करने योग्य 5xx मानना।
- यह मान लेना कि in-tree क्षमता एग्रीगेटेड APIs या प्रत्येक CRD पर लागू होती है।
- लिस्ट
resourceVersionको छोड़ना और गलत बिंदु से watch को पुनः आरंभ करना। - डिकोड CPU, हीप पीक, या पुनः कनेक्ट लागत के बिना केवल रिस्पॉन्स आकार को मापना।
फ़ॉलो-अप प्रश्न और उत्तर
लिस्ट के लिए PartialObjectMetadataList का उपयोग क्यों करें?
एक कलेक्शन अनुरोध एक लिस्ट निरूपण लौटाता है, और PartialObjectMetadataList स्पष्ट रूप से कहता है कि प्रत्येक आइटम में केवल मेटाडेटा होता है। सिंगल-ऑब्जेक्ट रूप एक GET के लिए है; क्लाइंट को उन्हें मिलाना और अनुमान नहीं लगाना चाहिए।
यदि सर्वर आंशिक रिस्पॉन्स का समर्थन नहीं करता है तो क्या होगा?
निम्न-गुणवत्ता वाले फ़ॉलबैक के रूप में सामान्य JSON के साथ, रिस्पॉन्स kind का निरीक्षण करें और पूर्ण ऑब्जेक्ट का उपयोग करें। स्ट्रिक्ट मोड में, 406 को अनुपलब्ध क्षमता के रूप में रिकॉर्ड करें और रिसोर्स नीति के अनुसार छोड़ दें या विफल करें। हमेशा के लिए पुनः प्रयास न करें।
क्या मेटाडेटा-ओनली resourceVersion को बदलता है?
नहीं। यह निरूपण को बदलता है, resourceVersion सिमेंटिक्स को नहीं। लिस्ट वर्शन अभी भी watch और कैश कंसिस्टेंसी को एंकर करता है।
क्या सभी CRDs इस अनुरोध का समर्थन करते हैं?
ऐसा न मानें। एग्रीगेटेड APIs और CRDs आंशिक निरूपण लागू नहीं कर सकते हैं; प्रति रिसोर्स क्षमता की जांच करें और कैश करें।
आपको पूर्ण ऑब्जेक्ट कब पढ़ना चाहिए?
जब किसी निर्णय के लिए spec, status, या किसी अन्य व्यावसायिक फ़ील्ड की आवश्यकता होती है। एक इंडेक्स बनाने के लिए मेटाडेटा का उपयोग करें, फिर नाम या इवेंट द्वारा एक नियंत्रित पूर्ण GET ट्रिगर करें।