समस्या और संदर्भ
Kubernetes Pod-लेवल संसाधन एक Pod को कंटेनर-स्तरीय मानों के अतिरिक्त CPU, मेमोरी या hugepages के अनुरोध (requests) और सीमाएं (limits) घोषित करने की अनुमति देते हैं। जब दोनों मौजूद होते हैं तो Pod-स्तरीय मानों को प्राथमिकता मिलती है, और वे शेड्यूलिंग, QoS और OOM स्कोरिंग को प्रभावित करते हैं। रोलआउट से पहले PodLevelResources फीचर गेट और क्लस्टर संस्करण का सत्यापन किया जाना चाहिए।
मान लें कि प्रॉक्सी और वर्कर्स एक बर्स्टी (bursty) वर्कलोड साझा करते हैं, लेकिन प्रॉक्सी का एक लेटेंसी SLO है और वर्कर्स अतिरिक्त क्षमता का उपयोग कर सकते हैं। इसका लक्ष्य उस संबंध को व्यक्त करना है बिना शेड्यूलर या kubelet को ऐसा बजट लागू करने के लिए मजबूर किए जो टीम का इरादा नहीं था।
इंटरव्यूअर्स क्या मूल्यांकन करते हैं
इंटरव्यूअर्स एक स्पष्ट संसाधन स्वामित्व मॉडल, सही प्राथमिकता नियम और इस बात की जागरूकता देखते हैं कि Pod-स्तरीय अनुरोध शेड्यूलिंग और QoS को बदलते हैं। मजबूत उत्तर समग्र (aggregate) बनाम प्रति-कंटेनर गारंटी, सीमाएं, ऑटोस्केलिंग, ऑब्जर्वेबिलिटी और माइग्रेशन परीक्षणों पर चर्चा करते हैं।
एक सामान्य उत्तर कंटेनर अनुरोधों के योग को spec.resources में कॉपी कर देता है। एक मजबूत उत्तर यह स्पष्ट करता है कि क्या Pod बजट एक साझा पूल है, किस कंटेनर को न्यूनतम सीमा (floor) की आवश्यकता है, और किसी एक वर्कर को प्रॉक्सी के लेटेंसी हेडरूम का उपभोग करने से कैसे रोका जाए।
पहले स्पष्ट करने योग्य प्रश्न
- क्या Pod-स्तरीय अनुरोध एक साझा बजट है या प्रत्येक कंटेनर के लिए एक सख्त न्यूनतम सीमा है?
- कौन से Kubernetes संस्करण, फीचर गेट्स, रिसोर्स मैनेजर्स और ऑपरेटिंग सिस्टम कार्यक्षेत्र में हैं?
- क्या प्रॉक्सी को वर्कर्स से स्वतंत्र एक गारंटीकृत CPU फ्लोर या मेमोरी सीमा की आवश्यकता है?
- HPA, VPA और एविक्शन नीतियां नए स्कोप को कैसे देखती हैं?
- जब माइग्रेशन के दौरान Pod-स्तरीय और कंटेनर-स्तरीय दोनों अनुरोध निर्दिष्ट किए जाते हैं तो क्या होता है?
यदि कंटेनरों के स्केलिंग या विफलता डोमेन स्वतंत्र हैं, तो अलग Pods अधिक सुरक्षित हो सकते हैं। यदि वे वास्तव में एक जीवनचक्र और बर्स्ट बजट साझा करते हैं, तो Pod-स्तरीय संसाधन उस संबंध को अधिक सीधे व्यक्त कर सकते हैं।
30 सेकंड का उत्तर
“मैं पहले फीचर-गेट और संस्करण समर्थन का सत्यापन करूंगा, फिर Pod को एक स्पष्ट प्रॉक्सी फ्लोर के साथ एक साझा बजट के रूप में मॉडल करूंगा। Pod-स्तरीय अनुरोधों को प्राथमिकता मिलती है, इसलिए मैं अनपेक्षित मिश्रित सेटिंग्स से बचूंगा, QoS और OOM व्यवहार का परीक्षण करूंगा, और ऑटोस्केलर इनपुट की जांच करूंगा। मैं मैनिफेस्ट का कैनरी परीक्षण करूंगा, पुरानी नीति के साथ लेटेंसी, थ्रॉटलिंग, एविक्शन और लागत की तुलना करूंगा, और कंटेनर-स्तरीय अनुरोधों पर रोलबैक का विकल्प बनाए रखूंगा।”
चरण-दर-चरण डिज़ाइन
- संसाधन भूमिकाओं को मैप करें। प्रॉक्सी लेटेंसी संवेदनशीलता, वर्कर बर्स्टीनेस, स्थिर-अवस्था उपयोग और मेमोरी वृद्धि को मापें। तय करें कि क्या कंटेनर बजट साझा करते हैं या उन्हें अलग गारंटी की आवश्यकता है।
- क्षमता सत्यापित करें। Kubernetes सर्वर संस्करण, कंट्रोल प्लेन और नोड्स पर
PodLevelResourcesगेट, समर्थित संसाधन प्रकार और जहां लागू हो केवल-Linux सीमाओं की पुष्टि करें। - Pod बजट सेट करें। शेड्यूलिंग के लिए अनुरोध और समग्र अधिकतम सीमा (ceiling) के लिए लिमिट्स चुनें। सुनिश्चित करें कि बजट प्रॉक्सी के लेटेंसी फ्लोर और वर्कर बर्स्ट के लिए जगह छोड़ता है।
- अस्पष्ट प्राथमिकता से बचें। माइग्रेशन के दौरान, यह दस्तावेज़ करें कि Pod-स्तरीय मान कंटेनर-स्तरीय मानों को ओवरराइड करते हैं। पुराने कंटेनर मानों को हटा दें या उन्हें केवल तभी रखें जब नीति को जानबूझकर दोनों स्कोप की आवश्यकता हो।
- QoS और एविक्शन की जांच करें। QoS क्लास और OOM व्यवहार की पुनर्गणना करें, फिर नोड दबाव, थ्रॉटलिंग और वर्कर प्रतिस्पर्धा का परीक्षण करें। एक स्वस्थ समग्र बजट भी प्रॉक्सी के भुखमरी (starvation) को छिपा सकता है।
- रोल आउट करें और निरीक्षण करें। एक वर्कलोड का कैनरी परीक्षण करें और p95 लेटेंसी, CPU थ्रॉटलिंग, मेमोरी दबाव, OOM किल्स, एविक्शन, रीस्टार्ट और लागत को ट्रैक करें। केवल तभी विस्तार करें जब गार्डरेल्स स्थिर रहें।
विकल्पों में अलग Deployments, केवल कंटेनर-विशिष्ट अनुरोध, या स्पष्ट सीमाओं वाला एक साइडकार शामिल हैं। Pod-स्तरीय संसाधन तब सबसे अधिक उपयोगी होते हैं जब जीवनचक्र और बर्स्ट क्षमता को जानबूझकर साझा किया जाता है।
उदाहरण उत्तर
“प्रॉक्सी को एक लेटेंसी फ्लोर की आवश्यकता होती है, जबकि वर्कर्स अतिरिक्त CPU ले सकते हैं। मैं एक Pod अनुरोध सेट करूंगा जो सामान्य समग्र को दर्शाता है और बर्स्ट सीलिंग के लिए एक सीमा निर्धारित करेगा, फिर यह सत्यापित करूंगा कि वर्कर लोड के तहत प्रॉक्सी भूखा न रहे। माइग्रेशन के दौरान मैं परस्पर विरोधी कंटेनर अनुरोधों को हटा दूंगा या उनके उद्देश्य को दस्तावेज़ करूंगा क्योंकि Pod-स्तरीय मान प्रभावी होते हैं। मैं दो नोड्स पर कैनरी परीक्षण करूंगा, p95 लेटेंसी, थ्रॉटलिंग, OOM, एविक्शन और ऑटोस्केलर व्यवहार पर नजर रखूंगा, और यदि प्रॉक्सी SLO खराब होता है तो पिछली कंटेनर नीति पर रोलबैक कर दूंगा।”
सामान्य गलतियां
- गलती: यह मान लेना कि Pod अनुरोध स्वचालित रूप से प्रति-कंटेनर गारंटी हैं → यह विफल क्यों होता है: बजट साझा हो सकता है → समाधान: फ्लोर और अलगाव को स्पष्ट रूप से परिभाषित करें।
- गलती: परस्पर विरोधी कंटेनर मानों को बिना दस्तावेज़ के छोड़ देना → यह विफल क्यों होता है: Pod-स्तरीय प्राथमिकता ऑपरेटरों को भ्रमित करती है → समाधान: प्रभावी संसाधनों का दस्तावेजीकरण और परीक्षण करें।
- गलती: केवल CPU उपयोग की जांच करना → यह विफल क्यों होता है: मेमोरी दबाव और OOM व्यवहार बदल सकते हैं → समाधान: CPU, मेमोरी, QoS, एविक्शन और लेटेंसी का एक साथ निरीक्षण करें।
- गलती: केवल एक कंट्रोल-प्लेन घटक पर सुविधा सक्षम करना → यह विफल क्यों होता है: सभी आवश्यक नोड्स और घटकों को इसका समर्थन करना चाहिए → समाधान: रोलआउट से पहले क्लस्टर-व्यापी क्षमता सत्यापित करें।
फॉलो-अप प्रश्न और उत्तर
क्या होगा यदि प्रॉक्सी भूखा (starved) रह जाए, भले ही Pod अपनी सीमा के भीतर हो?
इसे एक प्रतिस्पर्धा (contention) विफलता के रूप में मानें। एक प्रॉक्सी फ्लोर जोड़ें, वर्कलोड को अलग करें, या कंटेनर-स्तरीय अलगाव का उपयोग करें; केवल समग्र हेडरूम लेटेंसी की गारंटी नहीं देता है।
Pod-स्तरीय अनुरोध QoS को कैसे प्रभावित करते हैं?
जब दोनों स्कोप मौजूद होते हैं तो वे प्राथमिकता लेते हैं और Pod के QoS और OOM गणनाओं को प्रभावित करते हैं। माइग्रेशन के दौरान क्लास की पुनर्गणना करें और नोड दबाव का परीक्षण करें।
क्या Windows Pods Pod-स्तरीय संसाधनों का उपयोग कर सकते हैं?
संस्करण-विशिष्ट सीमाओं की जांच करें। प्रलेखित Kubernetes 1.35 व्यवहार Windows Pods के लिए Pod-स्तरीय संसाधनों का समर्थन नहीं करता है, इसलिए वहां एक कंटेनर-स्तरीय नीति बनाए रखें।
आप इसके बजाय Pod को कब विभाजित करेंगे?
तब विभाजित करें जब कंटेनर स्वतंत्र रूप से स्केल करते हैं, विफल होते हैं, या उनके पास स्वतंत्र SLO होते हैं। एकल Pod तब बनाए रखें जब साझा जीवनचक्र और बर्स्ट बजट जानबूझकर और अवलोकनीय हो।