सिस्टम डिज़ाइन इंटरव्यू: आप Kubernetes Pod-लेवल रीसाइज़ कंट्रोलर कैसे डिज़ाइन करेंगे?

प्रॉम्प्ट और संदर्भ

एक मल्टी-कंटेनर Pod में एक API प्रॉक्सी, कैश साइडकार और बैच वर्कर है। टीम Pod को हटाए बिना लेटेंसी और कतार की लंबाई के आधार पर Pod-लेवल CPU और मेमोरी बजट को एडजस्ट करना चाहती है। ऑब्जर्वेशन, निर्णय, /resize राइट्स, स्टेटस ट्रैकिंग, समवर्ती सुरक्षा (concurrency protection), अव्यवहार्य अनुरोधों और रोलबैक सहित कंट्रोलर को डिज़ाइन करें।

इंटरव्यूअर क्या जांचता है

• क्या आप वांछित संसाधनों (desired resources), वास्तविक संसाधनों (actual resources) और कंटेनर रीस्टार्ट पॉलिसी के बीच अंतर करते हैं।
• क्या आप इडेम्पोटेंट रीकंसाइलेशन (idempotent reconciliation), स्टेटस कंडीशन्स और स्थगित/अव्यवहार्य (deferred/infeasible) रीट्राई डिज़ाइन करते हैं।
• क्या Pod बजट और कंटेनर अनुरोधों की स्पष्ट सीमाएँ और सुरक्षा मानक (safety rails) हैं।
• क्या मेट्रिक्स, अनुमतियाँ (permissions), रिकवरी और प्रोग्रेसिव रोलआउट डिज़ाइन का हिस्सा हैं।

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

1. क्या क्लस्टर Pod-लेवल रीसाइज़ का समर्थन करता है, और कौन से फीचर गेट्स तथा kubectl वर्ज़न इंस्टॉल हैं?
2. क्या कंट्रोलर CPU, मेमोरी, या Pod और कंटेनर दोनों संसाधनों को बदलता है?
3. कौन से कंटेनर रीस्टार्ट हो सकते हैं, और किनमें गैर-बाधित (non-interruptible) कनेक्शन या स्टेट हैं?
4. क्या लक्ष्य लागत में कमी, एक SLO, या अचानक आने वाली कतार (bursty queue) को संभालना है?

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

मैं एक इवेंट-ड्रिवन इडेम्पोटेंट रीकंसाइलर बनाऊंगा: मेट्रिक्स और Pod स्थिति पढ़ें, बजट, SLO, नोड क्षमता और कूलडाउन के भीतर एक लक्ष्य की गणना करें, फिर /resize सब-रिसोर्स के माध्यम से एक छोटा बदलाव सबमिट करें। स्टेटस observedGeneration, PodResizePending, PodResizeInProgress, और Infeasible या Deferred कारणों को रिकॉर्ड करता है; रीट्राई बैकऑफ़, प्राथमिकता और अधिकतम गणना का उपयोग करते हैं। CPU और मेमोरी का अलग-अलग मूल्यांकन किया जाता है, कंटेनर resizePolicy का सम्मान किया जाता है, और मेमोरी जोखिम या SLO गिरावट पर अंतिम सत्यापित बजट को रीस्टोर किया जाता है। प्रत्येक राइट का एक ओनर, ऑडिट ट्रेल और RBAC सीमा होती है।

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

रिसोर्स मॉडल और सुरक्षा सीमा को परिभाषित करें

Pod-लेवल spec.resources एक समग्र (aggregate) बजट है; कंटेनर requests और limits अभी भी गारंटी और रीस्टार्ट व्यवहार को प्रभावित करते हैं। नेमस्पेस कोटा या नोड क्षमता से परे अनुरोधों को अस्वीकार करते हुए, प्रति-वर्कलोड न्यूनतम, अधिकतम, स्टेप, कूलडाउन और SLO गार्डरेल्स बनाए रखें।

मेट्रिक्स एकत्र करें और एक लक्ष्य की गणना करें

लेटेंसी, कतार की लंबाई, CPU थ्रॉटलिंग, वर्किंग सेट और OOM इवेंट्स का उपयोग करें। किसी एक स्पाइक पर प्रतिक्रिया करने से बचने के लिए विंडो और हिस्टैरिसीस (hysteresis) लागू करें; लक्ष्य को Pod बजट और कंटेनर-अनुरोधों-के-योग (sum-of-container-request) दोनों बाधाओं को पूरा करना चाहिए।

एक इडेम्पोटेंट रीसाइज़-सब-रिसोर्स अपडेट सबमिट करें

कंट्रोलर एक रिसोर्स वर्ज़न और ओनर के साथ वांछित स्थिति को अपडेट करता है। उदाहरण अनुरोध:

spec:
  resources:
    requests:
      cpu: "300m"
      memory: "512Mi"
    limits:
      cpu: "1"
      memory: "1Gi"

/resize सब-रिसोर्स को कॉल करें और resourceVersion की जांच करें। टकराव (conflict) होने पर, किसी उपयोगकर्ता या अन्य कंट्रोलर को ओवरराइट करने के बजाय फिर से पढ़ें और रीकंसाइल करें।

कंडीशन्स और रीट्राई प्राथमिकता को ट्रैक करें

PodResizePending और PodResizeInProgress के साथ-साथ observedGeneration जैसी कंडीशन्स को पढ़ें। Infeasible का अर्थ है कि वर्तमान बाधाएं अनुरोध को पूरा नहीं कर सकती हैं; Deferred का अर्थ है कि इसे स्थगित कर दिया गया है। कारण, अगला प्रयास और गणना को बनाए रखें (persist करें)। वर्कलोड प्राथमिकता, QoS और प्रतीक्षा समय के आधार पर रीट्राई शेड्यूल करें ताकि कम प्राथमिकता वाले काम कभी भी हमेशा के लिए भूखे (starve) न रहें।

कंटेनर रीस्टार्ट पॉलिसी को संभालें

Pod-लेवल के बदलाव कंटेनर-लेवल resizePolicy को ट्रिगर कर सकते हैं। CPU बिना रीस्टार्ट के लागू हो सकता है जबकि मेमोरी के लिए रीस्टार्ट की आवश्यकता हो सकती है; प्रत्येक कंटेनर की पॉलिसी, कनेक्शन और स्थिति का निरीक्षण करें। गैर-रीस्टार्ट करने योग्य अनुरोधों को एक सुरक्षा कतार के पीछे रखें और केवल Pod-लेवल की सफलता से कभी भी व्यावसायिक निरंतरता की रिपोर्ट न करें।

निरीक्षण करें, रोलबैक करें और उच्च उपलब्धता बनाए रखें

लक्ष्य और वास्तविक मान, कंडीशन ट्रांज़िशन, रीस्टार्ट गणना, लेटेंसी SLO, मेमोरी पीक और विफलता के कारण को रिकॉर्ड करें। लीडर चुनाव (leader election) के साथ कंट्रोलर रेप्लिकस चलाएं और Pod कुंजी द्वारा कतार से डुप्लिकेट हटाएं। खराब बजट, OOM या SLO गिरावट पर, अंतिम स्थिर लक्ष्य को रीस्टोर करें और मानवीय समीक्षा के लिए ऑटोमेशन को रोक दें।

मॉडल उत्तर

मैं एक इडेम्पोटेंट रीकंसाइलर बनाऊंगा जो लेटेंसी, कतार, थ्रॉटलिंग, वर्किंग सेट और OOM मेट्रिक्स को पढ़ता है, फिर न्यूनतम/अधिकतम बजट, स्टेप, कूलडाउन, नोड क्षमता और नेमस्पेस कोटा के भीतर एक लक्ष्य की गणना करता है। /resize के माध्यम से छोटे रिसोर्स-वर्ज़न वाले बदलाव सबमिट करें; टकराव होने पर फिर से पढ़ें। observedGeneration, Pending, InProgress, Infeasible, Deferred कारण और रीट्राई समय रिकॉर्ड करें, प्राथमिकता और प्रतीक्षा के आधार पर रीट्राई शेड्यूल करें। मेमोरी परिवर्तन द्वारा किसी कंटेनर को रीस्टार्ट करने से पहले प्रत्येक कंटेनर की रीसाइज़ पॉलिसी का निरीक्षण करें। लीडर चुनाव, मेट्रिक्स और ऑडिट लॉग का उपयोग करें; SLO गिरावट या OOM पर अंतिम स्थिर बजट को रीस्टोर करें और ऑटोमेशन को रोकें।

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

• Pod spec को सीधे संपादित करना और यह मान लेना कि kubelet इसे लागू करता है, /resize सब-रिसोर्स की अनदेखी करना।
• केवल वांछित संसाधनों को पढ़ना और वास्तविक संसाधनों तथा कंडीशन्स की अनदेखी करना।
• कूलडाउन और हिस्टैरिसीस को छोड़ देना, जिससे दोलन (oscillation) और बार-बार रीस्टार्ट होते हैं।
• Deferred अनुरोधों को हमेशा के लिए छोड़ देना या Infeasible अनुरोधों को बिना किसी सीमा के पुनः प्रयास करना।
• कंटेनर resizePolicy और मेमोरी-रीस्टार्ट जोखिम की अनदेखी करना।
• resourceVersion, ओनर और RBAC का अभाव होना, जिससे कंट्रोलर्स एक-दूसरे को ओवरराइट कर देते हैं।

फॉलो-अप प्रश्न

आप दो कंट्रोलर्स को एक-दूसरे को ओवरराइट करने से कैसे रोकते हैं?

स्पष्ट स्वामित्व (explicit ownership), resourceVersion, फ़ील्ड प्रबंधन और एक राइट ओनर का उपयोग करें; बिना शर्त ओवरराइट करने के बजाय टकराव होने पर फिर से पढ़ें और इरादे को मर्ज करें।

आप Infeasible और Deferred में कैसे अंतर करते हैं?

Infeasible का अर्थ है कि वर्तमान बाधाएं लक्ष्य को पूरा नहीं कर सकती हैं और इसके लिए एक नए लक्ष्य या क्षमता की आवश्यकता होती है; Deferred अस्थायी है और इसके कारण तथा प्राथमिकता को बनाए रखते हुए पुनः प्रयास किया जाना चाहिए।

ऑटोमेशन को कब रोकना चाहिए?

OOM, निरंतर SLO गिरावट, अपरिवर्तित कंडीशन्स, अत्यधिक रीस्टार्ट या अमान्य अवलोकनों पर रोकें, साथ ही एक मैन्युअल रिकवरी पथ बनाए रखें।

आप कैसे साबित करते हैं कि कोई रुकावट नहीं आई?

पॉलिसी के अनुसार रीसाइज़ कंडीशन्स, कंटेनर restartCount, कनेक्शन त्रुटियों, लेटेंसी और कतार मेट्रिक्स को सहसंबंधित (correlate) करें; Pod चरण का केवल Running बने रहना पर्याप्त नहीं है।