संकेत और संदर्भ
प्लेटफ़ॉर्म टीम Kubernetes Pod-स्तरीय CPU और मेमोरी आकार बदलना सक्षम कर रही है। उत्पाद टीमें स्वचालित ट्यूनिंग चाहती हैं, वित्त विभाग लागत को लेकर चिंतित है, और SRE को चिंता है कि मेमोरी परिवर्तन कंटेनरों को रीस्टार्ट कर सकते हैं। एक क्रॉस-टीम प्रवेश (admission), ऑडिट, घटना-प्रतिक्रिया (incident-response), और रोलबैक नीति बनाएं।
साक्षात्कारकर्ता क्या परीक्षण करता है
- क्या तकनीकी क्षमता स्पष्ट स्वामित्व, अनुमति और बजट सीमाओं में बदलती है।
- क्या जोखिम स्तर यह निर्धारित करते हैं कि कौन से वर्कलोड स्वचालित रूप से आकार बदल सकते हैं।
- क्या स्थिति की शर्तें (status conditions), रीस्टार्ट नीति और SLO अनुमोदन के प्रमाण बनते हैं।
- क्या ऑडिट और अभ्यास यह साबित करते हैं कि नीति किसी घटना के दौरान काम करती है।
स्पष्ट करने के लिए प्रश्न
- कौन से नेमस्पेस, वातावरण और वर्कलोड आकार बदल सकते हैं?
- सीमाओं को कौन अनुमोदित करता है, लागत का स्वामित्व किसके पास है, और कौन तत्काल परिवर्तनों को रोक (freeze) सकता है?
- आप कंटेनर
resizePolicy, स्टेटफ़ुल कनेक्शन और मेमोरी-रीस्टार्ट जोखिम का पता कैसे लगाते हैं? - क्या संगठन के पास पहले से ही कोटा, परिवर्तन विंडो, ऑडिट और घटना कमान (incident command) है?
30-सेकंड का उत्तर
मैं वातावरण, व्यावसायिक महत्ता और रीस्टार्ट जोखिम के आधार पर स्तर निर्धारित करूँगा: विकास वातावरण स्वचालित रूप से ट्यून हो सकता है, जबकि महत्वपूर्ण उत्पादन सेवाओं के लिए अनुमोदन की आवश्यकता होती है। नीति CPU और मेमोरी की सीमाएं, स्टेप, कूलडाउन, नेमस्पेस कोटा और SLO सुरक्षा उपाय तय करती है, और स्वामी, कारण और observedGeneration के साथ /resize सब-रिसोर्स की आवश्यकता होती है। प्रवेश अस्पष्टीकृत या सीमा से बाहर के अनुरोधों को अस्वीकार करता है; इवेंट्स Pending, InProgress, Infeasible, और Deferred के बीच अंतर करते हैं। ऑडिट लागत को रीस्टार्ट से जोड़ते हैं, और नियमित अभ्यास फ़्रीज़, रोलबैक और स्वामित्व हस्तांतरण का अभ्यास कराते हैं।
चरण-दर-चरण विस्तृत विवरण
जोखिम स्तरों को परिभाषित करें
वातावरण, SLO, डेटा स्थिति, कनेक्शन रुकावट क्षमता और कंटेनर resizePolicy के आधार पर स्तर बनाएं। महत्वपूर्ण स्टेटफ़ुल, भुगतान और कंट्रोल-प्लेन वर्कलोड डिफ़ॉल्ट रूप से अनुमोदित मेमोरी परिवर्तनों पर सेट होते हैं; कम जोखिम वाले स्टेटलेस वर्कलोड सीमाओं के भीतर ट्यून हो सकते हैं।
प्रवेश नियम स्थापित करें
नेमस्पेस अनुमति सूची (allowlists), संसाधन सीमाएं, स्टेप, कूलडाउन, नोड क्षमता, कोटा, परिवर्तन विंडो और लेबल की आवश्यकता रखें। प्रत्येक अनुरोध में मीट्रिक स्रोत, लक्ष्य और अपेक्षित लागत का उल्लेख होना चाहिए।
नीति को Kubernetes स्थिति से बांधें
कंट्रोलर के लिए वांछित/वास्तविक संसाधन, observedGeneration और आकार बदलने की शर्तों को पढ़ना आवश्यक बनाएं। केवल वास्तविक मूल्यों से मेल खाने वाला पूर्ण InProgress ही सफलता है; Pending, Infeasible, और Deferred कारणों के साथ दृश्यमान रहते हैं।
रीस्टार्ट और रोलबैक को संभालें
मेमोरी परिवर्तन कंटेनरों को रीस्टार्ट कर सकते हैं, इसलिए सेवाएं कनेक्शन ड्रेनिंग, स्थिति रिकवरी और अधिकतम रीस्टार्ट गणना घोषित करती हैं। एक सीमा (gate) को पार करने पर स्वचालन फ़्रीज़ हो जाता है और अंतिम स्थिर बजट बहाल हो जाता है; Pod चरण Running व्यावसायिक निरंतरता का प्रमाण नहीं है।
लागत और ऑडिट को प्रथम श्रेणी बनाएं
पहले/बाद का CPU और मेमोरी, अवधि, लागत अनुमान, स्वामी, अनुमोदक और परिणाम रिकॉर्ड करें। वित्त विभाग नेमस्पेस, टीम और वर्कलोड के अनुसार बजट भिन्नता देखता है; SRE SLO, OOM और रीस्टार्ट घटनाओं को सहसंबंधित करता है।
घटनाओं का अभ्यास करें और शासन को विकसित करें
नोड क्षमता की कमी, कंट्रोलर आउटेज, खराब बजट और व्यापक रोलबैक का अभ्यास करें। बाद में नीति, रनबुक और संपर्कों को अपडेट करें; प्रत्येक अपवाद की एक समाप्ति तिथि होती है ताकि कोई अस्थायी अनुमति सूची स्थायी न बन जाए।
मॉडल उत्तर
मैं Pod के आकार बदलने को एक खुला स्विच नहीं, बल्कि एक शासित परिवर्तन मानूँगा। वातावरण, SLO, स्थिति और resizePolicy द्वारा स्तर बनाएं; महत्वपूर्ण स्टेटफ़ुल सेवाओं के लिए अनुमोदन की आवश्यकता होती है। प्रवेश नेमस्पेस, सीमाएं, स्टेप, कूलडाउन, कोटा, क्षमता और परिवर्तन विंडो तय करता है, और स्वामी, कारण और observedGeneration के साथ /resize की आवश्यकता होती है। कंट्रोलर Pending, Infeasible, और Deferred की रिपोर्ट करता है और केवल वास्तविक स्थिति से सफलता की पुष्टि करता है। मेमोरी रीस्टार्ट गेट्स के लिए ड्रेनिंग और रिकवरी की आवश्यकता होती है; उल्लंघन होने पर फ़्रीज़ और रोलबैक किया जाता है। ऑडिट लागत, SLO, OOM और restartCount को जोड़ते हैं, और अभ्यास फ़्रीज़, रोलबैक और स्वामित्व हस्तांतरण का पूर्वाभ्यास कराते हैं।
सामान्य गलतियाँ
- किसी अनुमोदक, फ़्रीज़ प्राधिकरण या स्वामी के बिना संसाधन सीमाएं लिखना।
- प्रत्येक उत्पादन नेमस्पेस में स्वचालित मेमोरी आकार बदलने की अनुमति देना।
/resizeस्थितियों और कंटेनर रीस्टार्ट नीति की अनदेखी करना।- Running Pod चरण को निर्बाध व्यावसायिक सेवा का प्रमाण मानना।
- लागत ऑडिट, अपवाद समाप्ति और रोलबैक अभ्यासों को छोड़ना।
- किसी घटना के शुरू होने के बाद ही स्वामियों और रनबुक्स की तलाश करना।
अनुवर्ती प्रश्न
किन सेवाओं के लिए डिफ़ॉल्ट रूप से स्वचालित मेमोरी आकार बदलना बंद होना चाहिए?
ऐसी महत्वपूर्ण सेवाएं जिन्हें जल्दी ड्रेन नहीं किया जा सकता, जिनकी स्थिति रिकवरी महंगी है, या रीस्टार्ट पर स्थिरता का जोखिम है, उन्हें अनुमोदन और एक पूर्ण अभ्यास की आवश्यकता होनी चाहिए।
आप टीमों को Pods संपादित करके नीति को दरकिनार करने से कैसे रोकते हैं?
अनधिकृत राइट्स को अस्वीकार करने के लिए प्रवेश (admission), RBAC, फ़ील्ड प्रबंधन और ऑडिट का उपयोग करें; आपातकालीन अनुमति समय-सीमित, ट्रैक करने योग्य होती है और स्वचालित रूप से समाप्त हो जाती है।
लागत और SLO के बीच टकराव होने पर कौन निर्णय लेता है?
नीति पहले से ही प्राथमिकता और बजट सीमाएं निर्धारित करती है; कंट्रोलर को चुपचाप चुनने देने के बजाय एक नामित उत्पाद और SRE स्वामी सीमा से ऊपर निर्णय लेते हैं।
आपको कैसे पता चलेगा कि नीति काम कर रही है?
अस्वीकार किए गए सीमा से बाहर के अनुरोधों, SLO गिरावट, OOM, रीस्टार्ट, बजट भिन्नता, रोलबैक समय और अभ्यास पूर्णता की तुलना करें, फिर प्रत्येक टीम के साथ समीक्षा करें।