प्रॉम्प्ट और संदर्भ
एक स्टेटलेस सर्विस कई ज़ोन में चलती है और 2 से 30 रेप्लिकास तक स्केल करती है। नोड विफलताओं, स्केलिंग और रोलिंग रिलीज़ के दौरान, टीम नए रिलीज़ को शेड्यूल करने के लिए असंभव बनाए बिना रेप्लिकास को किसी एक विफलता डोमेन में केंद्रित होने से बचाना चाहती है। topologySpreadConstraints डिज़ाइन करें और बताएं कि DoNotSchedule, ScheduleAnyway, या anti-affinity का उपयोग कब करना है।
साक्षात्कारकर्ता क्या मूल्यांकन करता है
- क्या आप उपलब्धता को स्पष्ट नोड, ज़ोन और क्षेत्र विफलता-डोमेन लक्ष्यों में बदलते हैं।
- क्या आप
maxSkew,minDomains,topologyKey, औरwhenUnsatisfiableको सही ढंग से समझाते हैं। - क्या आप सेलेक्टर, अनुपलब्ध टोपोलॉजी-लेबल, और छोटे-रेप्लिका एज केस को पकड़ते हैं।
- क्या प्लेसमेंट, PDBs, रोलिंग अपडेट्स, ऑटोस्केलिंग और ऑब्जर्वेबिलिटी एक एकल डिज़ाइन के रूप में काम करते हैं।
स्पष्टीकरण हेतु प्रश्न
- क्या ज़ोन बिजली, नेटवर्किंग और क्षमता में स्वतंत्र हैं, और क्या क्षेत्रीय विफलता दायरे में है?
- एक विफलता डोमेन खोने के बाद कितने रेप्लिकास शेष रहने चाहिए?
- क्या एक अनशेड्यूल करने योग्य Pod को प्रतीक्षा करनी चाहिए, उपलब्धता कम करनी चाहिए, या अस्थायी असंतुलन (skew) को सहन करना चाहिए?
- क्या वर्कलोड लेबल्स, नोड टोपोलॉजी लेबल्स और डिफ़ॉल्ट बाधाएं प्लेटफ़ॉर्म-प्रबंधित हैं?
- क्या पुराने और नए संस्करण रोलिंग अपडेट के दौरान समान
labelSelectorका उपयोग करते हैं?
30-सेकंड का उत्तर
मैं पहले विफलता डोमेन और न्यूनतम क्षमता को परिभाषित करूंगा, फिर नोड्स और ज़ोन के लिए अलग-अलग प्लेसमेंट लक्ष्य निर्धारित करूंगा। महत्वपूर्ण सेवाएं सीमित DoNotSchedule का उपयोग करती हैं; सामान्य या लचीले वर्कलोड एक सॉफ्ट लक्ष्य के रूप में ScheduleAnyway का उपयोग करते हैं। maxSkew पात्र डोमेन में एक सेलेक्टर के अंतर को सीमित करता है, जबकि minDomains डोमेन गायब होने पर भ्रामक गणनाओं को रोकता है। रोलआउट से पहले मैं लेबल्स, स्केलिंग, रोलिंग अपडेट्स और सिंगल-डोमेन विफलता का परीक्षण करूंगा; प्रोडक्शन में मैं प्रति डोमेन रेप्लिकास, Pending समय, उपलब्ध क्षमता और PDB डिसरप्शन बजट की निगरानी करूंगा।
गहन उत्तर
चरण 1: डोमेन और क्षमता को परिभाषित करें
नोड्स, ज़ोन और क्षेत्रों को अलग-अलग topologyKey मानों में मैप करें। यदि सर्विस को ज़ोन हानि से बचना है, तो कम से कम दो ज़ोन में पर्याप्त रेप्लिकास रखें; केवल दो रेप्लिकास के साथ, आप तीन ज़ोन में समान प्लेसमेंट और एक को खोने के बाद दो स्वस्थ रेप्लिकास का वादा नहीं कर सकते। सख्ती चुनने से पहले क्षमता इनवेरिएंट बताएं।
चरण 2: maxSkew और minDomains चुनें
maxSkew एक लक्षित डोमेन और वैश्विक न्यूनतम के बीच अनुमत अंतर है; DoNotSchedule के साथ, इसे पार करने पर Pod Pending अवस्था में रहता है। minDomains यह व्यक्त करता है कि कितने पात्र डोमेन आवश्यक हैं और एक छोटे डोमेन सेट को वैध वितरण के रूप में मानने से रोकता है। छोटे-रेप्लिका सेवाओं का परीक्षण करें ताकि यह बाधा रिलीज़ को अवरुद्ध न करे।
चरण 3: हार्ड और सॉफ्ट बाधाओं को अलग करें
कंट्रोल-प्लेन या भुगतान सेवाएं ज़ोन-स्तरीय DoNotSchedule का उपयोग कर सकती हैं और प्लेसमेंट विफलता को क्षमता अलर्ट में बदल सकती हैं। बैच या टालने योग्य कार्य ScheduleAnyway का उपयोग कर सकते हैं, जिससे शेड्यूलर को अस्थायी असंतुलन की अनुमति देते हुए अंतर (skew) को कम करने के लिए कहा जा सकता है। हार्ड एंटी-एफ़िनिटी एक साधारण "सह-स्थित न करें" नियम के लिए उपयुक्त है; बहु-स्तरीय टोपोलॉजी और मापने योग्य असंतुलन आमतौर पर स्प्रेड बाधाओं के साथ अधिक स्पष्ट होते हैं।
चरण 4: सेलेक्टर्स और लेबल्स को भरोसेमंद बनाएं
बाधा labelSelector को वास्तविक Pod टेम्पलेट से मेल खाना चाहिए, अन्यथा नए Pods की गलत सेट के विरुद्ध गणना की जा सकती है। नोड्स को स्थिर ज़ोन, क्षेत्र और होस्टनाम लेबल्स की आवश्यकता होती है; टोपोलॉजी कुंजी के बिना एक नोड उस डोमेन गणना में सही ढंग से भाग नहीं लेता है। टीमों द्वारा टूटे हुए मेनिफेस्ट को कॉपी करने से पहले एडमिशन जांच को सेलेक्टर्स, लेबल्स और डिफ़ॉल्ट को मान्य करना चाहिए।
चरण 5: रिलीज़, PDBs और स्केलिंग का समन्वय करें
एक रोलिंग अपडेट में पुराने रेप्लिकास, नए रेप्लिकास और maxUnavailable को एक साथ ध्यान में रखना चाहिए। एक PDB स्वैच्छिक व्यवधान को सीमित करता है; यह क्रॉस-डोमेन प्लेसमेंट का स्थान नहीं लेता है। ऑटोस्केलर को Pending Pods और प्रति-डोमेन क्षमता को समझना चाहिए, अन्यथा सख्त बाधाएं बिना उपयोगी नोड्स जोड़े हमेशा के लिए प्रतीक्षा कर सकती हैं।
चरण 6: विफलता और गिरावट (Degradation) कार्यों को परिभाषित करें
नोड हानि, ज़ोन हानि और अनुपलब्ध नोड लेबल्स का अभ्यास करें, फिर देखें कि क्या नए Pod्स को अस्वीकार कर दिया गया है, विषम (skewed) किया गया है, या Pending रखा गया है। महत्वपूर्ण सेवाएं कम प्राथमिकता वाली रिलीज़ को रोक सकती हैं, स्वस्थ डोमेन में क्षमता जोड़ सकती हैं, या केवल-पढ़ने के मोड में प्रवेश कर सकती हैं। उपलब्धता जोखिम को दर्ज किए बिना प्रोडक्शन में हार्ड बाधा को न हटाएं। डिग्रेडेशन कार्यों का संस्करण बनाएं और उन्हें रोल बैक करें।
चरण 7: वितरण मेट्रिक्स के साथ सत्यापित करें
वर्कलोड, संस्करण और टोपोलॉजी डोमेन द्वारा रेप्लिकास, असंतुलन (skew), Pending अवधि, शेड्यूलिंग कारण, उपलब्ध क्षमता, PDB डिसरप्शन और अनुरोध त्रुटियों को रिकॉर्ड करें। लोड परीक्षणों में 2 से 30 रेप्लिकास, असमान डोमेन क्षमता, रोलिंग अपडेट्स और ऑटोस्केलिंग को कवर किया जाना चाहिए। लक्ष्य यह साबित करना है कि डोमेन हानि के बाद शेष क्षमता SLO को पूरा करती है, न कि केवल यह कि रेप्लिकास विभिन्न नोड्स पर उतरे हैं।
मॉडल उत्तर
मैं नोड्स, ज़ोन और क्षेत्रों को तीन विफलता-डोमेन परतों के रूप में मॉडल करूंगा और पहले ज़ोन खोने के बाद आवश्यक न्यूनतम रेप्लिकास निर्धारित करूंगा। सर्विस Pods टेम्पलेट से मेल खाने वाले सेलेक्टर का उपयोग करते हैं; बाधाएं होस्टनाम और ज़ोन पर अलग-अलग लागू होती हैं। महत्वपूर्ण सेवाएं DoNotSchedule के साथ एक छोटे ज़ोन maxSkew का उपयोग करती हैं, जबकि बैच कार्य ScheduleAnyway का उपयोग करता है। यदि पात्र डोमेन minDomains से नीचे आते हैं, तो भ्रामक वितरण को चुपचाप स्वीकार करने के बजाय एक क्षमता अलर्ट जारी करें। रोलिंग अपडेट के दौरान PDB, maxUnavailable और पुराने/नए सेलेक्टर्स को मान्य करें, और ऑटोस्केलर से Pending कारणों और डोमेन क्षमता का निरीक्षण करवाएं। ऑब्जर्वेशन मोड में रोल आउट करें, फिर प्रति-डोमेन रेप्लिकास, Pending समय, विफलता-डोमेन ड्रिल और व्यावसायिक SLOs को रोलबैक गेट्स के रूप में उपयोग करके धीरे-धीरे हार्ड बाधाओं को सक्षम करें।
सामान्य गलतियां
topologyKeyया क्षमता लक्ष्य का नाम लिए बिना "ज़ोन में डिप्लॉय करें" कहना।maxSkewको एक पूर्ण प्रति-डोमेन रेप्लिका सीमा के रूप में मानना।- सेलेक्टर बेमेल को अनदेखा करना और इसलिए गलत Pod सेट की गणना करना।
- PDB को शेड्यूलर बाधा के रूप में या प्रत्येक नोड विफलता से सुरक्षा के रूप में मानना।
- केवल दो रेप्लिकास के साथ तीन ज़ोन में समान प्लेसमेंट और ज़ोन हानि के बाद कोई गिरावट न होने का वादा करना।
- उपलब्धता ट्रेड-ऑफ को रिकॉर्ड किए बिना Pending को हटाने के लिए
DoNotScheduleको हटाना।
फॉलो-अप प्रश्न
फॉलो-अप 1: क्या ScheduleAnyway अभी भी उपलब्धता में मदद करता है?
हाँ। यह कम असंतुलन (skew) को शेड्यूलिंग प्राथमिकता बनाता है, जबकि क्षमता सीमित होने पर वर्कलोड को चलने की अनुमति देता है। यह टालने योग्य कार्य या अन्य अतिरेक (redundancy) वाले वर्कलोड के लिए उपयुक्त है; महत्वपूर्ण सेवाएं पहले से स्केल कर सकती हैं और एक हार्ड बाधा का उपयोग कर सकती हैं।
फॉलो-अप 2: केवल pod anti-affinity का उपयोग क्यों न करें?
एंटी-एफ़िनिटी कहता है कि चयनित Pods के साथ सह-स्थित न हों। यह कई टोपोलॉजी स्तरों, संख्यात्मक असंतुलन और न्यूनतम डोमेन आवश्यकताओं को कम प्रत्यक्ष रूप से व्यक्त करता है। स्प्रेड बाधाएं क्रॉस-डोमेन असंतुलन का वर्णन करती हैं, जबकि एंटी-एफ़िनिटी एक बहिष्करण नियम के लिए उपयोगी बनी रहती है।
फॉलो-अप 3: क्या होता है जब minDomains गलत होता है?
बहुत कम पात्र डोमेन के साथ, असंतुलन के लिए उपयोग किया जाने वाला वैश्विक न्यूनतम एक बाधा को संतुष्ट दिखा सकता है या Pods को Pending रख सकता है। एडमिशन जांच और क्षमता अलर्ट में डोमेन उपलब्धता शामिल करें, और क्लस्टर संस्करण के लिए फ़ील्ड व्यवहार सत्यापित करें।
फॉलो-अप 4: रोलिंग रिलीज़ वितरण को क्यों तोड़ सकती है?
पुराने और नए संस्करण अलग-अलग सेलेक्टर्स का उपयोग कर सकते हैं, या maxUnavailable और maxSurge अस्थायी रूप से एक डोमेन में रेप्लिकास जोड़ सकते हैं। मध्यवर्ती स्थितियों का अनुकरण करें और रिलीज़ से पहले संस्करण और डोमेन द्वारा असंतुलन का निरीक्षण करें।
फॉलो-अप 5: क्या होगा यदि किसी नोड में ज़ोन लेबल नहीं है?
यह अनुरोधित टोपोलॉजी गणना में सही ढंग से भाग नहीं लेगा। नोड की मरम्मत करें या उसे अलग करें; बिना लेबल वाले नोड को एक स्वतंत्र विफलता डोमेन के रूप में न गिनें।
फॉलो-अप 6: आप कैसे साबित करते हैं कि SLO ज़ोन विफलता से बचता है?
एक आइसोलेशन ड्रिल चलाएं और शेष डोमेन में शेड्यूलेबल क्षमता, स्वस्थ रेप्लिकास, अनुरोध त्रुटियों और पुनर्प्राप्ति समय को सत्यापित करें। शेड्यूलिंग से लेकर व्यावसायिक मेट्रिक्स तक के पूरे पथ को मान्य करने के लिए PDB स्थिति, Pending कारणों और स्केल-अप समय को रिकॉर्ड करें।