बैकएंड इंटरव्यू: PodDisruptionBudget क्या सुरक्षित कर सकता है, और क्या सुरक्षित नहीं कर सकता?

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

आप पाँच की वांछित replica संख्या वाली Deployment-प्रबंधित सर्विस का संचालन करते हैं। क्लस्टर अपग्रेड के दौरान, एक नोड को drain किया जाना आवश्यक है और टीम को एक साथ कई replicas खोने की चिंता है। साक्षात्कारकर्ता आपसे PodDisruptionBudget को डिज़ाइन या समीक्षा करने और rolling releases, नोड विफलताओं और सीधे Pod deletion पर इसके प्रभावों को समझाने के लिए कहता है।

यह Kubernetes उपलब्धता सीमाओं और परिचालन तर्क का परीक्षण करता है। PDB सीमित करता है कि voluntary disruptions के कारण एक साथ कितने चयनित replicas अनुपलब्ध हो सकते हैं। यह कोई replica controller नहीं है और न ही हर विफलता के खिलाफ कोई गारंटी है। एक अच्छा उत्तर वांछित replicas, selectors, eviction entry point और शेष क्षमता को जोड़ता है।

साक्षात्कारकर्ता क्या मूल्यांकन कर रहा है

• क्या आप voluntary और involuntary disruption के बीच अंतर करते हैं।
• क्या आप minAvailable और maxUnavailable के परस्पर अनन्य (mutually exclusive) सेमेन्टिक्स की व्याख्या करते हैं।
• क्या आप जानते हैं कि PDB कंट्रोलर की वांछित replica संख्या और एक सटीक Pod selector पर निर्भर करता है।
• क्या आप drain retries, गैर-कवर किए गए deletion paths और rolling-update सीमाओं की व्याख्या कर सकते हैं।
• क्या आप उपलब्धता योजना में replicas, topology, probes और क्षमता जोड़ते हैं।

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

• क्या सर्विस Deployment, StatefulSet, या किसी अन्य समर्थित कंट्रोलर द्वारा प्रबंधित है?
• क्या selector केवल इसी वर्कलोड से मेल खाता है? एक व्यापक selector असंबंधित Pods को एक ही बजट में मिला सकता है।
• क्या आप node drains और scale-down से सुरक्षा कर रहे हैं, या बिजली चले जाने (power loss) से? PDB बाद वाले को नहीं रोक सकता।
• क्या पर्याप्त क्षमता और सही readiness के साथ replicas सभी ज़ोन में फैले हुए हैं? PDB eviction को सीमित करता है; यह क्षमता नहीं बनाता है।
• मेंटेनेंस को कब तक प्रतीक्षा करनी पड़ सकती है? बहुत सख्त बजट विंडो को बढ़ा सकता है, जबकि ढीला बजट क्षमता को कम करता है।

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

"PDB Eviction API के माध्यम से किए गए voluntary disruption अनुरोधों को बाधित करता है। पाँच replicas के साथ, minAvailable: 4 या maxUnavailable: 1 यह व्यक्त कर सकते हैं कि एक समय में अधिकतम एक खोना चाहिए, लेकिन ये फ़ील्ड परस्पर अनन्य हैं। बजट वर्कलोड के वांछित replicas और एक सटीक selector पर निर्भर करता है; नोड विफलता, सीधे Deployment deletion और एप्लिकेशन rolling updates इसके द्वारा पूरी तरह से नहीं रोके जाते हैं। यदि drain अस्वीकार कर दिया जाता है, तो मैं बजट, स्वस्थ replicas, क्षमता और eviction path का निरीक्षण करूँगा, जबकि शेष उपलब्धता डिज़ाइन के लिए replicas, topology और probes का उपयोग करूँगा।"

गहन-विश्लेषण उत्तर

व्यवधान को वर्गीकृत करें

Node drain, node maintenance और क्लस्टर के कुछ scale-down कार्य आमतौर पर Eviction API के माध्यम से Pod स्थानांतरण का अनुरोध करते हैं। वे voluntary disruptions हैं, इसलिए PDB अस्थायी रूप से eviction को अस्वीकार कर सकता है। Power loss, kernel failure या network isolation involuntary disruptions हैं; PDB उन्हें नहीं रोक सकता है, और परिणामी अनुपलब्ध Pods अभी भी बजट स्थिति को प्रभावित करते हैं।

परस्पर अनन्य फ़ील्ड्स को समझाएं

minAvailable बताता है कि eviction के बाद कितने मेल खाने वाले Pods उपलब्ध रहने चाहिए। maxUnavailable बताता है कि eviction के बाद कितने मेल खाने वाले Pods अनुपलब्ध हो सकते हैं। दोनों को एक साथ सेट नहीं किया जा सकता है। पाँच वांछित replicas के लिए, minAvailable: 4 और maxUnavailable: 1 उस आकार पर समान इरादा व्यक्त करते हैं, लेकिन प्रतिशत स्केल और राउंडिंग के साथ बदलते हैं, इसलिए वांछित संख्या और संस्करण सेमेन्टिक्स का उल्लेख करें।

वांछित replicas और selector पर निर्भरता दिखाएं

कंट्रोल प्लेन Pod owner references के माध्यम से प्रबंधित वर्कलोड को ढूंढता है और .spec.replicas से इच्छित संख्या प्राप्त करता है। Selector को Deployment या StatefulSet लेबलों से मेल खाना चाहिए और संकीर्ण (narrow) रहना चाहिए। एक selector जो कई अनुप्रयोगों से मेल खाता है, एक साझा बजट बनाता है; समर्थित स्वामी संसाधन के बिना, Kubernetes कुल संख्या का विश्वसनीय रूप से अनुमान नहीं लगा सकता है।

सीमा दिखाने के लिए एक कॉन्फ़िगरेशन का उपयोग करें

यह उदाहरण voluntary eviction से अधिकतम एक चयनित Pod को अनुपलब्ध होने की अनुमति देता है जब वर्कलोड पाँच replicas का इरादा रखता है:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: checkout-api
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: checkout-api

यह हर समय चार स्वस्थ Pods की गारंटी नहीं देता है। एक replica पहले से ही अस्वस्थ हो सकता है, या कोई नोड अचानक विफल हो सकता है। रोलआउट से पहले, selector, readiness, वांछित replicas और बहु-ज़ोन क्षमता को सत्यापित करें।

Drain अस्वीकृति और पुनः प्रयास (retry) को समझाएं

जब वर्तमान में किसी eviction की अनुमति नहीं है, स्वस्थ replicas पहले से ही minAvailable से कम हैं, या बजट नियंत्रक स्थिति की गणना नहीं कर सकता है, तो Eviction API अनुरोध को अस्वीकार कर सकता है। kubectl drain विफल अनुरोधों को तब तक समय-समय पर पुनः प्रयास करता है जब तक कि Pods समाप्त न हो जाएं या टाइमआउट न हो जाए। समस्या निवारण PDB स्थिति, चयनित Pods, स्वस्थ संख्या, readiness विफलताओं और इस पुष्टि के साथ शुरू होता है कि रखरखाव कार्रवाई वास्तव में Eviction API का उपयोग करती है।

Rolling updates और सीधे deletion को अलग करें

Deployment और StatefulSet rolling updates उनकी अपनी अपडेट रणनीति द्वारा शासित होते हैं; PDB उन नियमों का पूर्ण विकल्प नहीं है। PDB किसी Pod या Deployment के हर सीधे विलोपन को भी बाधित नहीं कर सकता है। रिलीज़ सिस्टम को PDB को सभी रिलीज़ सुरक्षा सौंपने के बजाय maxUnavailable, maxSurge, readiness और रोलबैक व्यवहार को संयोजित करना चाहिए।

PDB के बाहर विश्वसनीयता जोड़ें

PDB एक प्रकार के व्यवधान को कवर करता है। नोड या ज़ोन विफलता का विरोध करने के लिए पर्याप्त replicas, topology spread, capacity headroom, सही readiness और liveness, graceful termination और connection draining की भी आवश्यकता होती है। कोरम-आधारित stateful सेवाओं के लिए, बजट को कोरम की आवश्यकताओं से प्राप्त करें; stateless सेवाओं के लिए, वास्तविक ट्रैफ़िक, पुनर्प्राप्ति समय और क्षमता परीक्षणों के साथ उपलब्धता को मान्य करें।

मॉडल उच्च-गुणवत्ता वाला उत्तर

"Deployment पाँच replicas चाहता है, इसलिए मैं पहले यह सत्यापित करूँगा कि PDB selector केवल checkout-api से मेल खाता है और readiness व क्रॉस-ज़ोन क्षमता मजबूत है। यदि voluntary eviction को चार उपलब्ध replicas छोड़ने चाहिए, तो मैं minAvailable: 4 या maxUnavailable: 1 का उपयोग कर सकता हूँ; वे परस्पर अनन्य हैं, और मैं स्केलिंग व्यवहार के आधार पर एक पूर्ण मान या प्रतिशत चुनूँगा।

PDB node drains, रखरखाव और कुछ scale-down कार्रवाइयों की सुरक्षा करता है जो Eviction API का उपयोग करते हैं। यह power loss, kernel failure या सीधे Pod deletion को नहीं रोक सकता है, और rolling updates मुख्य रूप से Deployment रणनीति द्वारा नियंत्रित होते हैं। यदि drain अस्वीकार कर दिया जाता है, तो मैं स्वस्थ replicas, बजट स्थिति, selector, readiness विफलताओं, क्षमता और eviction path का निरीक्षण करूँगा; kubectl drain टाइमआउट होने तक पुनः प्रयास कर सकता है।

मैं replicas, topology spread, readiness, graceful termination और release rollback के साथ PDB को मान्य करूँगा। एक बजट जो बहुत सख्त है, रखरखाव को अवरुद्ध कर सकता है, जबकि एक जो बहुत ढीला है, न्यूनतम क्षमता का उल्लंघन कर सकता है, इसलिए सीमा सार्वभौमिक प्रतिशत के बजाय ट्रैफ़िक और विफलता ड्रिल्स से आनी चाहिए।"

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

• यह दावा करना कि PDB नोड विफलता को रोकता है: voluntary और involuntary disruption को भ्रमित किया गया है → दावे को Eviction API पथ तक सीमित करें।
• minAvailable और maxUnavailable दोनों सेट करना: फ़ील्ड परस्पर अनन्य हैं → एक बजट अभिव्यक्ति चुनें।
• केवल वर्तमान Pods की गिनती करना: बजट वांछित replicas का उपयोग करता है → owner references और .spec.replicas का निरीक्षण करें।
• संपूर्ण नेमस्पेस का चयन करना: असंबंधित ऐप्स एक ही बजट साझा करते हैं → एक संकीर्ण वर्कलोड selector का उपयोग करें।
• यह कहना कि PDB rolling updates और सीधे विलोपन की सुरक्षा करता है: नियंत्रकों और विलोपन पथों के अलग-अलग सेमेन्टिक्स होते हैं → प्रत्येक नीति और अनुमति पथ का निरीक्षण करें।
• Drain ब्लॉक होने पर PDB को हटाना: क्षमता का जोखिम बढ़ सकता है → पहले स्वस्थ replicas, probes, बजट स्थिति और क्षमता का निरीक्षण करें।
• Topology या क्षमता के बिना PDB को कॉन्फ़िगर करना: जीवित Pods एक ही failure domain साझा कर सकते हैं → ज़ोन, हेडरूम और ड्रिल्स को संयोजित करें।
• प्रतिशत को एक निश्चित replica संख्या के रूप में मानना: स्केलिंग अर्थ बदल देती है → वांछित स्केल, राउंडिंग और ऑटोस्केलिंग व्यवहार बताएं।

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

फॉलो-अप 1: पाँच replicas के लिए minAvailable: 80% का क्या अर्थ है?

इसके लिए Kubernetes प्रतिशत और राउंडिंग नियमों द्वारा उत्पादित उपलब्ध संख्या की आवश्यकता होती है। यह न मानें कि यह हमेशा ठीक चार ही होता है; वर्तमान API सेमेन्टिक्स को सत्यापित करें और स्केलिंग के बाद व्यवहार का निरीक्षण करें।

फॉलो-अप 2: Drain अभी भी सर्विस को अनुपलब्ध क्यों बना सकता है?

PDB केवल स्वीकृत voluntary evictions को सीमित करता है; यह पहले से अस्वस्थ Pods की मरम्मत नहीं कर सकता, क्षमता नहीं बना सकता, एकल-ज़ोन एकाग्रता को पूर्ववत नहीं कर सकता, या एप्लिकेशन को कनेक्शन माइग्रेशन को सहन करने योग्य नहीं बना सकता। Readiness, topology, क्षमता और graceful termination को एक साथ मान्य किया जाना चाहिए।

फॉलो-अप 3: क्या kubectl delete pod PDB द्वारा अवरुद्ध होता है?

यह न मानें कि ऐसा होता है। Kubernetes दस्तावेज़ बताते हैं कि Pods या Deployments को सीधे हटाने से PDB सुरक्षा को बायपास किया जा सकता है, इसलिए अनुमतियाँ, ऑडिट और रिलीज़ प्रक्रियाओं को उस पथ को प्रतिबंधित करना चाहिए।

फॉलो-अप 4: PDB शून्य अनुमत व्यवधान (allowed disruptions) दिखाता है। क्या आपको इसे पहले ढीला करना चाहिए?

पहले selector, वांछित replicas, स्वस्थ replicas, readiness विफलताओं और नियंत्रक स्थिति का निरीक्षण करें। आँख बंद करके बजट को ढीला करने से स्वास्थ्य संबंधी समस्या छिप सकती है। यदि रखरखाव के लिए वास्तव में अस्थायी परिवर्तन की आवश्यकता है, तो क्षमता और रोलबैक का मूल्यांकन करें, विंडो को रिकॉर्ड करें और नीति को पुनर्स्थापित करें।

फॉलो-अप 5: Stateful और stateless सेवाएँ कैसे भिन्न हैं?

एक stateful सर्विस को कोरम या स्थिरता प्रोटोकॉल के न्यूनतम replicas को बनाए रखना चाहिए और पुनर्संतुलन (rebalancing) व पुनर्प्राप्ति को मान्य करना चाहिए। एक stateless सर्विस आमतौर पर शेष क्षमता, लेटेंसी और कनेक्शन ड्रेनिंग पर ध्यान केंद्रित करती है। केवल replica संख्या से उपलब्धता का कोई भी दावा साबित नहीं होता है।

फॉलो-अप 6: आप कैसे सत्यापित करते हैं कि PDB प्रभावी है?

एक नियंत्रित विंडो में, Eviction API और एक node drain का अभ्यास करें, फिर अस्वीकृति, पुनः प्रयास, termination grace, ट्रैफ़िक, त्रुटियों और पुनर्प्राप्ति समय का निरीक्षण करें। नोड विफलता और सीधे विलोपन पथों का भी परीक्षण करें ताकि टीम PDB सीमा को सर्व-विफलता गारंटी समझने की गलती न करे।