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

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

एक प्लेटफ़ॉर्म टीम Pods को दोबारा बनाए बिना (recreating के बिना) CPU और मेमोरी बदलना चाहती है। एक इन-प्लेस रीसाइज़ फ़्लो डिज़ाइन करें, बताएं कि कंटेनर को कब रीस्टार्ट होना चाहिए, अपर्याप्त क्षमता को कैसे संभालना है, और इसे कैसे मॉनिटर (observe) और रोलबैक करना है।

Kubernetes 1.33 में कंटेनर इन-प्लेस रीसाइज़ को Beta में प्रमोट किया गया; Pod-लेवल रिसोर्स रीसाइज़ 1.36 में Beta है। एक रनिंग Pod नए CPU और मेमोरी रिसोर्स प्राप्त कर सकता है, जबकि kubelet परिवर्तन को लागू करने या टालने (defer करने) के लिए resizePolicy, नोड क्षमता और cgroup स्थिति का उपयोग करता है। "Spec को बदलने" का मतलब "कभी रीस्टार्ट न होना" नहीं है।

इंटरव्यूअर क्या टेस्ट कर रहा है

Pod-लेवल की सीमाएं बनाम कंटेनर रिसोर्स, resizePolicy के CPU और मेमोरी सिमेंटिक्स, Pending और InProgress कंडीशंस, अव्यवहार्य (infeasible) और डिफर्ड (deferred) अनुरोध, scheduler बनाम kubelet की जिम्मेदारियां, QoS और प्राथमिकता (priority), तथा कैनरी और रोलबैक की सीमाओं को कवर करें।

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

"मैं रीसाइज़ को एक डिक्लेरेटिव अनुरोध और एक स्टेट मशीन बनाऊंगा। एक कंट्रोलर रिसोर्स spec को अपडेट करता है, kubelet व्यवहार्यता की जांच करता है, और PodResizePending या PodResizeInProgress की रिपोर्ट करता है; CPU अक्सर बिना रीस्टार्ट के लागू हो जाता है, जबकि मेमोरी रीस्टार्ट का व्यवहार प्रत्येक कंटेनर की resizePolicy का पालन करता है। एक अव्यवहार्य अनुरोध अपने कारण को बनाए रखता है और सीमाओं के तहत पुनः प्रयास करता है। प्लेटफ़ॉर्म observedGeneration, वास्तविक cgroups, रीस्टार्ट और QoS परिवर्तनों पर नज़र रखता है, और रोलबैक के लिए छोटे कैनरी तथा रिवर्स पैच का उपयोग करता है।"

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

चरण 1: रिसोर्स मॉडल को परिभाषित करें

कंटेनर रिसोर्स प्रत्येक कंटेनर के लिए requests और limits निर्धारित करते हैं; समर्थित वर्ज़न Pod-लेवल एग्रीगेट सीमाओं को भी प्रदर्शित करते हैं। एक Pod limit कुल उपयोग को सीमित करती है, लेकिन कंटेनर limit इससे अधिक नहीं हो सकती। API को यह स्पष्ट करना चाहिए कि वह spec.containers[*].resources को संपादित कर रहा है या spec.resources को।

चरण 2: एक डिक्लेरेटिव रीसाइज़ फ़्लो बनाएं

प्लेटफ़ॉर्म एक टारगेट और कारण स्वीकार करता है, रिसोर्स फ़ील्ड लिखता है, और पुराने मान, कर्ता (actor) और generation को संग्रहीत करता है। API कभी भी नोड cgroups को सीधे संपादित नहीं करता है। Kubelet नई generation का अवलोकन करता है, जांच करता है और इसे लागू करता है, फिर status लिखता है।

चरण 3: रीस्टार्ट पॉलिसी को संभालें

एक कंटेनर प्रति रिसोर्स एक पॉलिसी चुन सकता है:

resizePolicy:
  - resourceName: cpu
    restartPolicy: NotRequired
  - resourceName: memory
    restartPolicy: RestartContainer

NotRequired एक ऑनलाइन अपडेट का प्रयास करता है; RestartContainer नया मान लागू करने के लिए रीस्टार्ट की अनुमति देता है। restartPolicy: Never वाले Pod के लिए, प्रत्येक कंटेनर रिसोर्स को NotRequired का उपयोग करना चाहिए, अन्यथा अनुरोध अमान्य हो जाता है।

चरण 4: व्यवहार्यता और डिफर्ड स्टेटस को मॉडल करें

जब नोड टारगेट प्रदान नहीं कर सकता, तो kubelet Infeasible या Deferred जैसे कारणों के साथ PodResizePending की रिपोर्ट करता है; एक संसाधित अनुरोध PodResizeInProgress में प्रवेश कर सकता है। कंट्रोलर्स को केवल API spec के बजाय status को पढ़ना चाहिए और अनुरोधित generation के साथ status को जोड़ने के लिए observedGeneration का उपयोग करना चाहिए।

चरण 5: CPU और मेमोरी के साथ अलग व्यवहार करें

CPU आमतौर पर एप्लिकेशन को रीस्टार्ट किए बिना cgroup कोटा अपडेट कर सकता है। मेमोरी डाउनसाइज़िंग वर्तमान वर्किंग सेट द्वारा बाधित हो सकती है, और कुछ रनटाइम को इसे सुरक्षित रूप से लागू करने के लिए रीस्टार्ट की आवश्यकता होती है। CPU से मेमोरी व्यवहार का अनुमान न लगाएं; प्रति-रिसोर्स पॉलिसी पढ़ें और एक स्पष्ट इवेंट जारी करें।

चरण 6: शेड्यूलिंग और QoS का समन्वय करें

एक इन-प्लेस अपडेट रीशेड्यूलिंग नहीं है। किसी request को बढ़ाने के लिए नोड क्षमता की आवश्यकता हो सकती है, इसलिए डिफर्ड अनुरोधों को PriorityClass, QoS क्लास और प्रतीक्षा समय के आधार पर पुनः प्रयास करना चाहिए। अपडेट के बाद कोटा, QoS और अलर्ट की पुनर्गणना करें ताकि किसी नेमस्पेस या Guaranteed वर्कलोड का अनजाने में कम हिसाब न रह जाए।

चरण 7: प्रभावी मान का अवलोकन करें

वांछित spec, status कंडीशंस, observedGeneration, वास्तविक कंटेनर cgroups, रीस्टार्ट, OOMs, CPU थ्रॉटलिंग और मेमोरी वर्किंग सेट को एकत्र करें। यदि status पूर्ण बताता है लेकिन cgroups में बदलाव नहीं हुआ है, तो इसे विफलता मानें और परिवर्तनों को जमा करने के बजाय किसी अन्य पैच को ब्लॉक करें।

चरण 8: कैनरी, दर-सीमित (rate-limit), और रोलबैक

वर्कलोड और नोड पूल द्वारा बैचों में रीसाइज़ करें, समवर्ती ऑपरेशनों को सीमित करें, और Pending टाइमआउट और पुनः प्रयास की सीमाएं निर्धारित करें। विफलता पर सहेजे गए संसाधनों को पुनर्स्थापित करें; यदि मेमोरी पॉलिसी कंटेनर को रीस्टार्ट करती है, तो ट्रैफ़िक को ड्रेन करें और विस्तार करने से पहले तत्परता (readiness) सत्यापित करें। कंट्रोलर के पुनः प्रयासों को कार्य की नकल करने से रोकने के लिए प्रत्येक अनुरोध को एक idempotency key की आवश्यकता होती है।

ट्रेड-ऑफ़ और सीमाएं

रीस्टार्ट-मुक्त निरंतरता बनाम रिसोर्स निश्चितता

इन-प्लेस परिवर्तन रुकावट को कम करते हैं, लेकिन क्षमता और डिफर्ड स्थिति पूर्णता को एसिंक्रोनस बनाती है। लेटेंसी-संवेदनशील सेवाओं के लिए छोटे कदमों का उपयोग करें; बैच जॉब्स नियतात्मक (deterministic) परिणामों के लिए रीस्टार्ट स्वीकार कर सकते हैं।

Pod सीमाएं बनाम कंटेनर सटीकता

Pod रिसोर्स एक साझा सीमा व्यक्त करते हैं जबकि कंटेनर रिसोर्स महत्वपूर्ण कंटेनरों की रक्षा करते हैं। जब दोनों मौजूद हों, तो सत्यापित करें कि कंटेनर limits Pod सीमा के भीतर रहें और UI तथा ऑडिट रिकॉर्ड में प्रभावी सीमा दिखाएं।

स्वचालित पुनः प्रयास बनाम अनुमोदन

अस्थायी क्षमता की कमी सीमित पुनः प्रयास के योग्य है। मेमोरी रीस्टार्ट, QoS परिवर्तन, या प्रोडक्शन पीक के लिए अनुमोदन या मेंटेनेंस विंडो की आवश्यकता हो सकती है; असीमित पुनः प्रयास असुरक्षित हैं।

विफलता अभ्यास (failure drills) और विकास योजना

नोड में क्षमता का अभाव है

नोड क्षमता से अधिक का विस्तार सबमिट करें, Infeasible या Deferred की पुष्टि करें, और सत्यापित करें कि पुनः प्रयास पुराने प्रभावी मान को नहीं बदलते हैं।

मेमोरी परिवर्तन कंटेनर को रीस्टार्ट करता है

मेमोरी के लिए RestartContainer सेट करें और ट्रैफ़िक ड्रेन, रीस्टार्ट, तत्परता बहाली (readiness recovery), और इवेंट क्रम का अवलोकन करें। सुनिश्चित करें कि कंट्रोलर रीस्टार्ट को व्यावसायिक विफलता के रूप में रिपोर्ट न करे।

Generations की रेस (Race conditions)

दो टारगेट तेज़ी से सबमिट करें। पुरानी generation को नए टारगेट को अधिलेखित (overwrite) नहीं करना चाहिए, और अंतिम observedGeneration को cgroup मान से मेल खाना चाहिए।

सामान्य गलतियाँ और फॉलो-अप

गलती 1: यह मान लेना कि इन-प्लेस रीसाइज़ कभी रीस्टार्ट नहीं होता

फॉलो-अप: रीस्टार्ट का क्या कारण है? एक कंटेनर की resizePolicy इसके लिए बाध्य कर सकती है, विशेष रूप से मेमोरी के लिए; Pod-लेवल रीसाइज़ की कोई अलग रीस्टार्ट पॉलिसी नहीं होती है, लेकिन कंटेनर पॉलिसी अभी भी लागू होती है।

गलती 2: spec अपडेट को पूर्णता के रूप में मानना

फॉलो-अप: आप सफलता की पुष्टि कैसे करते हैं? केवल वांछित फ़ील्ड के बजाय कंडीशंस, observedGeneration, cgroups, कंटेनर इवेंट्स और रीस्टार्ट काउंट की जांच करें।

गलती 3: क्षमता गायब होने पर बार-बार पैचिंग करना

फॉलो-अप: क्या सही है? Pending कारण को बनाए रखें, प्राथमिकता और समय सीमा के भीतर पुनः प्रयास करें, और माइग्रेशन, एक छोटा टारगेट, या अनुमोदन की पेशकश करें।

विस्तारित फॉलो-अप और मॉडल उत्तर

CPU और मेमोरी को अलग-अलग डिज़ाइन क्यों करें?

CPU कोटा आमतौर पर ऑनलाइन बदल सकता है; मेमोरी डाउनसाइज़िंग वर्किंग सेट और रनटाइम व्यवहार द्वारा बाधित होती है और रीस्टार्ट हो सकती है। एक साझा API को अभी भी प्रति-रिसोर्स पॉलिसी और स्थिति की आवश्यकता होती है।

आप डुप्लिकेट रीसाइज़ को नए टारगेट को अधिलेखित करने से कैसे रोकते हैं?

सशर्त अपडेट के लिए रिसोर्स वर्ज़न या generation का उपयोग करें, केवल नवीनतम टारगेट स्वीकार करें, और observedGeneration के माध्यम से स्थिति और cgroups का मिलान (reconcile) करें।

आपको इन-प्लेस रीसाइज़ से कब बचना चाहिए?

जब मजबूत अलगाव (isolation) की आवश्यकता हो, क्षमता अस्थिर हो, एप्लिकेशन रीस्टार्ट सहन न कर सके, या रिसोर्स परिवर्तन रनटाइम मान्यताओं का उल्लंघन करते हों, तो रोलिंग रिप्लेसमेंट का उपयोग करें। इन-प्लेस रीसाइज़ को एक नियंत्रित अनुकूलन (optimization) के रूप में रखें।