प्रतिनिधि इंटरव्यू विषय

आप Kubernetes restartPolicyRules का सुरक्षित रूप से उपयोग कैसे करेंगे?

बैकएंडकठिन
Offer.cc संपादकीय टीमप्रकाशित अपडेट किया गया

प्रश्न

एक वर्कर Pod में एक proxy, एक fetcher, और एक reporter शामिल हैं। किसी सिस्टम आउटेज को छिपाए बिना, विफलता के बाद केवल सही कंटेनर को रीस्टार्ट करने के लिए आप कंटेनर-स्तरीय restartPolicyRules का उपयोग कैसे करेंगे?

समस्या और संदर्भ

Kubernetes v1.35 कंटेनरों के लिए restartPolicyRules पेश करता है जब RestartAllContainers क्रिया सक्षम होती है। यह नियम एक एग्जिट कोड को रीस्टार्ट एक्शन में मैप कर सकता है, जबकि Pod का अभी भी एक लाइफ़साइकिल और रेडीनेस अनुबंध होता है। इस फ़ीचर को विफलता वर्गीकरण के रूप में मानें, न कि प्रोब्स या अलर्टिंग के प्रतिस्थापन के रूप में।

मान लें कि एक वर्कर Pod में विभिन्न विफलता डोमेन वाले तीन कंटेनर हैं। fetcher एक क्षणिक क्रेडेंशियल रीफ्रेश विफलता से उबर सकता है; एक proxy कॉन्फ़िगरेशन त्रुटि ऑपरेटर को सूचित (page) करनी चाहिए; एक reporter को अपने स्थानीय स्टेट के दूषित होने पर पूरे Pod को रीस्टार्ट करने की आवश्यकता हो सकती है।

इंटरव्यूअर्स क्या मूल्यांकन करते हैं

इंटरव्यूअर्स एक सटीक विफलता वर्गीकरण, फ़ीचर-गेट और संस्करण पूर्वापेक्षाओं के प्रति जागरूकता, और एक ऐसी योजना की तलाश करते हैं जो रीस्टार्ट लूप्स को घटनाओं को छिपाने से रोके। मजबूत उत्तर एग्जिट कोड्स को ओनरशिप, रेडीनेस, बैकऑफ़, मेट्रिक्स, और रोलआउट सुरक्षा से जोड़ते हैं।

एक सामान्य उत्तर हर कंटेनर में restartPolicyRules जोड़ता है। एक मजबूत उत्तर यह बताता है कि कौन से कोड स्थिर API सिमेंटिक्स हैं, कौन से आकस्मिक प्रोसेस विवरण हैं, और प्रत्येक कंटेनर के स्टेट के लिए यह कैसे साबित किया जाए कि रीस्टार्ट सुरक्षित है।

पहले स्पष्ट करने योग्य प्रश्न

  • प्रत्येक क्लस्टर में कौन से Kubernetes संस्करण और फ़ीचर गेट्स की गारंटी है?
  • क्या एग्जिट कोड एप्लिकेशन अनुबंध द्वारा नियंत्रित होते हैं या रनटाइम और शेल रैपर द्वारा उत्सर्जित होते हैं?
  • क्या कंटेनर स्टेट डिस्पोज़ेबल है, चेकपॉइंटेड है, या Pod में किसी अन्य कंटेनर से जुड़ा हुआ है?
  • जब वही कोड दोहराया जाता है तो क्या होना चाहिए: बैकऑफ़, Pod प्रतिस्थापन, या एस्केलेशन?
  • जब एक कंटेनर रीस्टार्ट हो रहा हो तो कौन से सिग्नल उपयोगकर्ता की रेडीनेस को परिभाषित करते हैं?

यदि कोड एक परीक्षित एप्लिकेशन अनुबंध का हिस्सा नहीं हैं, तो एक समान रीस्टार्ट नीति को प्राथमिकता दें और पहले प्रोसेस अनुबंध में सुधार करें। यदि स्टेट जुड़ा हुआ है, तो एक कंटेनर को रीस्टार्ट करने से उसके साथी कंटेनरों के साथ स्प्लिट-ब्रेन इंटरैक्शन उत्पन्न हो सकता है।

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

"मैं पहले Kubernetes संस्करण और फ़ीचर गेट को सत्यापित करूँगा, फिर प्रत्येक कंटेनर के अनुबंध में एग्जिट-कोड सिमेंटिक्स को परिभाषित करूँगा। मैं केवल क्षणिक, स्टेटलेस विफलताओं को रीस्टार्ट करूँगा; स्थायी कॉन्फ़िगरेशन विफलताओं को दृश्यमान होने दूँगा; और दूषित साझा स्टेट के लिए Pod प्रतिस्थापन का उपयोग करूँगा। मैं नियम मैचों, रीस्टार्ट काउंट्स, बैकऑफ़, रेडीनेस, और दोहराए गए कोड अलर्ट्स को इंस्ट्रूमेंट करूँगा, नीति को कैनरी करूँगा, और त्रुटि दर या रीस्टार्ट लूप बढ़ने पर इसे रोलबैक करूँगा।"

चरण-दर-चरण डिज़ाइन

  1. पूर्वापेक्षाओं की जाँच करें। v1.35 व्यवहार, RestartAllContainers, एडमिशन नीति, और क्या क्लस्टर का कंट्रोलर और ऑब्ज़र्वेबिलिटी स्टैक नए फ़ील्ड्स को समझते हैं, इसकी पुष्टि करें।
  2. एग्जिट-कोड ओनरशिप को परिभाषित करें। एक छोटा प्रलेखित सेट आरक्षित करें जैसे क्षणिक रीफ्रेश, स्थायी कॉन्फ़िगरेशन, और अपूरणीय स्टेट। रैपर्स का परीक्षण करें ताकि सिग्नल गलती से रीमैप न हों।
  3. सबसे छोटी सुरक्षित कार्रवाई को मैप करें। क्षणिक कोड के लिए स्टेटलेस fetcher को रीस्टार्ट करें। खराब कॉन्फ़िगरेशन के लिए proxy को रीस्टार्ट न करें; इसे NotReady के रूप में सामने लाएं और अलर्ट करें। साझा स्टेट अमान्य होने पर Pod को बदलें।
  4. निर्भरताओं को सुरक्षित रखें। निर्भरता अनुबंध पर रेडीनेस को गेट करें, शटडाउन हुक को समन्वित करें, और जब तक रीस्टार्ट किए गए कंटेनर में वार्म स्टेट न हो, तब तक ट्रैफ़िक स्वीकार करने से बचें।
  5. पुनरावृत्ति को नियंत्रित करें। रीस्टार्ट काउंट्स, एक्सपोनेंशियल बैकऑफ़, और एक दोहराए गए कोड अलर्ट को संयोजित करें। एक नियम जो लगातार रीस्टार्ट होता रहता है, उसे अंततः एक ऑपरेटर-दृश्यमान विफलता बन जाना चाहिए।
  6. धीरे-धीरे रोल आउट करें। एक वर्कलोड पर कैनरी करें, पिछली नीति के साथ रीस्टार्ट-लूप दर, रिकवरी समय, त्रुटि दर, और Pod चर्न की तुलना करें, फिर केवल तभी विस्तार करें जब सुरक्षा मानक बने रहें।

विकल्पों में एक कंटेनर के अंदर एक सुपरवाइज़र, स्वतंत्र विफलता डोमेन के लिए अलग Deployments, या एक कंट्रोलर शामिल है जो Pod को बदलता है। सबसे सरल सीमा चुनें जो स्टेट को सुरक्षित रखती है और विफलता को दृश्यमान बनाती है।

उदाहरण उत्तर

"fetcher के लिए, एग्जिट कोड 42 का अर्थ एक अल्पकालिक क्रेडेंशियल रीफ्रेश विफलता है और इसे रीस्टार्ट करना सुरक्षित है क्योंकि इसमें कोई स्थायी स्थानीय स्टेट नहीं है। एक कॉन्फ़िगरेशन त्रुटि NotReady बनी रहती है और ओनर को पेज करती है; इसे रीस्टार्ट करने से केवल वही विफलता दोहराई जाएगी। यदि reporter दूषित स्थानीय चेकपॉइंट्स का पता लगाता है, तो मैं Pod को समाप्त कर दूँगा ताकि एक साफ़ वॉल्यूम या प्रतिस्थापन सुसंगत रूप से रिकवर हो सके। मैं फ़ीचर गेट के पीछे के नियमों को एक कैनरी पर शिप करूँगा, बार-बार मैचों और रीस्टार्ट लूप्स पर अलर्ट करूँगा, और रिकवरी समय या त्रुटि दर बिगड़ने पर नीति को हटा दूँगा।"

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

  • त्रुटि: प्रत्येक गैर-शून्य एग्जिट को क्षणिक मानना → यह क्यों विफल होता है: स्थायी दोष मूक रीस्टार्ट लूप बन जाते हैं → समाधान: परीक्षित एग्जिट-कोड सिमेंटिक्स को परिभाषित करें।
  • त्रुटि: फ़ीचर-गेट और क्लस्टर अंतर (skew) को अनदेखा करना → यह क्यों विफल होता है: विभिन्न वातावरणों में मैनिफ़ेस्ट अलग तरह से व्यवहार करते हैं → समाधान: एडमिशन और रोलआउट जाँचें जोड़ें।
  • त्रुटि: युग्मित (coupled) स्टेट वाले एक कंटेनर को रीस्टार्ट करना → यह क्यों विफल होता है: साथी कंटेनर असंगत स्टेट बनाए रखते हैं → समाधान: Pod को बदलें या रिकवरी का समन्वय करें।
  • त्रुटि: केवल कंटेनर रीस्टार्ट्स की निगरानी करना → यह क्यों विफल होता है: रीस्टार्ट स्वस्थ दिखने के बावजूद उपयोगकर्ताओं को त्रुटियाँ दिखाई दे सकती हैं → समाधान: रीस्टार्ट मेट्रिक्स को रेडीनेस और सेवा SLOs के साथ जोड़ें।

फ़ॉलो-अप प्रश्न और उत्तर

क्या होगा यदि एग्जिट कोड 42 एक शेल रैपर द्वारा उत्सर्जित होता है और इमेज अपडेट के बाद बदल जाता है?

कोड को एक API के रूप में मानें। रैपर को पिन और टेस्ट करें, ओनरशिप का दस्तावेजीकरण करें, और अनुबंध बदलने पर रोलआउट को विफल करें। रनटाइम-विशिष्ट कोड्स को चुपचाप इनहेरिट न करें।

आप रीस्टार्ट लूप को आउटेज छिपाने से कैसे रोकते हैं?

बार-बार नियम मिलान, रीस्टार्ट दर, बैकऑफ़ संतृप्ति, और रेडीनेस के नुकसान पर अलर्ट करें। प्रयासों की एक सीमित संख्या के बाद, Pod प्रतिस्थापन या एक ऑपरेटर-दृश्यमान विफलता पर एस्केलेट करें।

पूरे Pod को रीस्टार्ट करना कब अधिक सुरक्षित होता है?

जब स्टेट साझा किया जाता है, इनिशियलाइज़ेशन क्रम मायने रखता है, या एक कंटेनर का भ्रष्टाचार उसके साथियों को अमान्य कर सकता है, तो Pod प्रतिस्थापन का उपयोग करें। असंगत आंशिक रिकवरी की तुलना में व्यापक रीस्टार्ट बेहतर है।

आप इस फ़ीचर को कैसे रोलबैक करेंगे?

वर्कलोड टेम्पलेट पर नीति को अक्षम करें, पिछले रीस्टार्ट व्यवहार को पुनर्स्थापित करें, और सत्यापित करें कि पुरानी प्रतिकृतियां (replicas) अभिसरण (converge) करती हैं। एग्जिट-कोड अनुबंध और डैशबोर्ड बनाए रखें ताकि रोलबैक देखने योग्य (observable) बना रहे।

सार्वजनिक स्रोत

संबंधित प्रश्न