सिस्टम डिज़ाइन इंटरव्यू: Node Allocatable रिसोर्सेज के लिए आप Kubernetes v1.36 DRA का उपयोग कैसे करेंगे?

प्रश्न और दायरा

एक मल्टी-टेनेंट इन्फेरेंस क्लस्टर Dynamic Resource Allocation (DRA) के माध्यम से एक्सेलेरेटर एलोकेट करता है। ड्राइवर प्रति डिवाइस CPU, मेमोरी या hugepages की खपत करता है, और कुछ डिवाइसों को NUMA अलाइनमेंट की आवश्यकता होती है। एक Kubernetes v1.36 Node Allocatable प्लान डिज़ाइन करें ताकि शेड्यूलर DRA एलोकेशन और सामान्य Pod रिक्वेस्ट्स का एक साथ हिसाब रख सके। ResourceSlice मैपिंग, Pod स्टेटस, रोलआउट, मॉनिटरिंग और रोलबैक सीमाओं की व्याख्या करें।

आधिकारिक v1.36 DRA अपडेट Node Allocatable रिसोर्सेज को एक पहले इटरेशन के रूप में वर्णित करता है जो DRA-प्रबंधित CPU, मेमोरी और hugepages को मानक नोड अकाउंटिंग में लाता है। यह क्षमता अभी भी अल्फा में है, इसलिए डिज़ाइन को प्रयोगात्मक-फीचर सुरक्षा उपायों (guardrails) की आवश्यकता है।

संदर्भ और सीमाएं

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

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

• क्या आप रिसोर्स लेज़र, शेड्यूलर, DRA ड्राइवर, ResourceSlice और Pod स्टेटस को जोड़ सकते हैं।
• क्या आप डिवाइस क्षमता को डिवाइस एलोकेशन द्वारा उपभोग किए जाने वाले नोड रिसोर्सेज और सामान्य Pod रिक्वेस्ट्स से अलग पहचानते हैं।
• क्या आप NUMA, hugepages, आउट-ऑफ-ऑर्डर अपडेट्स, ड्राइवर रीस्टार्ट और पुराने (stale) ResourceSlices को संभालते हैं।
• क्या आप कैनरी, ऑब्जर्वेबिलिटी, रोलबैक और पुराने ड्राइवर की कम्पैटिबिलिटी के साथ एक अल्फा फीचर गेट को रोल आउट कर सकते हैं।
• क्या स्टेटस अपडेट्स केवल DRA सिंथेटिक सबरिसोर्सेज और नोड-स्कोप्ड अनुमतियों तक सीमित हैं।

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

“मैं DRA ड्राइवर से ResourceSlice पर nodeAllocatableResourceMappings में प्रत्येक डिवाइस के CPU, मेमोरी या hugepage योगदान को घोषित करवाऊंगा। शेड्यूलर बाउंड क्लेम के एलोकेशन को नोड लेज़र में सामान्य Pod रिक्वेस्ट्स के साथ मर्ज करता है, और प्रत्येक क्लेम को केवल एक बार गिनता है। एक निश्चित फ़ुटप्रिंट allocationMultiplier का उपयोग कर सकता है; एक क्षमता-आधारित फ़ुटप्रिंट capacityKey का उपयोग कर सकता है। Pod स्टेटस nodeAllocatableResourceClaimStatuses के माध्यम से परिणाम प्रदर्शित करता है। मैं DRANodeAllocatableResources को केवल कैनरी नोड्स पर सक्षम करूंगा, NUMA, पुराने अपडेट्स और पेंडिंग व्यवहार का परीक्षण करूंगा, और यदि लेज़र या मैपिंग असुरक्षित हो जाती है तो नए क्लेम रोक दूंगा।”

चरण-दर-चरण समाधान

1. रिसोर्स मॉडल को परिभाषित करें। डिवाइस ID, ResourceClaim, नोड, NUMA ज़ोन, रिसोर्स नाम, यूनिट, मैपिंग संस्करण और अवलोकन समय को एक रीप्ले करने योग्य लेज़र में स्टोर करें। डिवाइस क्षमता को CPU, मेमोरी और hugepage की खपत से अलग करें; एक क्लेम लेज़र में केवल एक बार दर्ज होना चाहिए।

1. ResourceSlice मैपिंग प्रकाशित करें। DRA ड्राइवर ResourceSlice में nodeAllocatableResourceMappings लिखता है। मैपिंग कीज़ CPU, मेमोरी, ephemeral-storage या hugepages का प्रतिनिधित्व कर सकती हैं। प्रति-डिवाइस एक निश्चित फ़ुटप्रिंट को allocationMultiplier के साथ दर्शाया जा सकता है; क्षमता-आधारित खपत capacityKey का उपयोग कर सकती है।

resourceSlice:
  nodeAllocatableResourceMappings:
    cpu:
      allocationMultiplier: 2
    memory:
      allocationMultiplier: 4Gi
    hugepages-2Mi:
      capacityKey: consumed

यह केवल मैपिंग सिमेंटिक्स को दर्शाता है। फ़ील्ड प्रकारों और यूनिट्स की जांच वर्तमान Kubernetes API स्कीमा और ड्राइवर कार्यान्वयन के विरुद्ध की जानी चाहिए; यह सबमिट करने के लिए तैयार ऑब्जेक्ट नहीं है।

1. शेड्यूलिंग लेज़र को मर्ज करें। शेड्यूलर ResourceSlices और बाउंड ResourceClaims को पढ़ता है, DRA योगदान की गणना करता है, और सामान्य Pod रिक्वेस्ट्स को जोड़ता है। डुप्लिकेट से बचने (deduplication) के लिए एक स्थिर क्लेम की का उपयोग करें। यदि कोई ResourceSlice पुराना है या उसकी मैपिंग गायब है, तो पुरानी क्षमता के आधार पर शेड्यूल करने के बजाय नए Pods को पेंडिंग रखें और अलर्ट भेजें।

1. NUMA और ऑर्डरिंग को संभालें। NUMA एफिनिटी और संस्करणों को रिकॉर्ड करें। एलोकेशन, रिलीज़ या ResourceSlice अपडेट को केवल तभी कमिट करें जब नोड का वर्शन ऑर्डरिंग मोनोटोनिक हो। ड्राइवर रीस्टार्ट के दौरान, अस्थायी डबल एलोकेशन से बचने के लिए नए क्लेम स्वीकार करने से पहले मैपिंग का पुनर्निर्माण करें।

1. स्टेटस और टेलीमेट्री प्रदर्शित करें। Pod का status.nodeAllocatableResourceClaimStatuses क्लेम की नोड-रिसोर्स स्थिति को रिकॉर्ड करता है। लेज़र क्षमता, उपयोग, मैपिंग की आयु, पेंडिंग के कारण, डुप्लिकेट-रिजेक्शन काउंट और NUMA प्लेसमेंट विफलताओं को ट्रैक करें। स्टेटस राइट्स और शेड्यूलिंग निर्णयों को क्लेम UID के साथ सहसंबंधित (correlate) करें।

1. कैनरी और रोलबैक। कंट्रोल-प्लेन, शेड्यूलर और ड्राइवर कम्पैटिबिलिटी की पुष्टि होने के बाद, केवल कैनरी नोड्स के लिए DRANodeAllocatableResources को सक्षम करें। ResourceSlices, क्लेम के साथ मिश्रित सामान्य Pods, नोड रीस्टार्ट, ड्राइवर अपग्रेड और रिलीज़ का परीक्षण करें। विफलता पर, नए क्लेम रोकें, मौजूदा बाइंडिंग्स को सुरक्षित रखें, लेज़र को एक्सपोर्ट करें, मैपिंग की मरम्मत करें और संस्करण द्वारा फिर से शुरू करें। यह मानकर न चलें कि प्रत्येक क्लस्टर सुरक्षित रूप से अल्फा क्षमता को सक्षम कर सकता है।

1. सुरक्षा सीमा (Security boundary)। DRA ड्राइवर को केवल उसके स्टेटस अपडेट के लिए आवश्यक सिंथेटिक-सबरिसोर्स अनुमतियां दें। नोड-लोकल ड्राइवर नोड-अवेयर वर्ब्स और न्यूनतम-विशेषाधिकार (least-privilege) RBAC का उपयोग करते हैं। विफल राइट्स पर अलर्ट होना चाहिए और पुनः प्रयास किया जाना चाहिए; अनुमतियों का विस्तार करने से लेज़र की विसंगति ठीक नहीं होती है।

मॉडल उत्तर

मैं Node Allocatable को एक वर्शन वाले रिसोर्स लेज़र के रूप में मानूंगा। ड्राइवर nodeAllocatableResourceMappings में CPU, मेमोरी या hugepages के लिए डिवाइस योगदान घोषित करता है; निश्चित योगदान allocationMultiplier का उपयोग करते हैं, और क्षमता-आधारित योगदान capacityKey का उपयोग करते हैं। शेड्यूलर बाउंड क्लेम को पढ़ता है, प्रत्येक क्लेम के योगदान को सामान्य Pod रिक्वेस्ट्स के साथ मर्ज करता है, और क्लेम UID द्वारा डुप्लिकेट हटाता है ताकि डिवाइस उपयोग और नोड-रिसोर्स उपयोग को दो बार न गिना जाए।

लेज़र नोड, डिवाइस, NUMA, मैपिंग संस्करण और अवलोकन समय को रिकॉर्ड करता है। पुराने ResourceSlice, वर्शन रिग्रेशन या ड्राइवर रीस्टार्ट के दौरान, नए Pods पुरानी क्षमता से शेड्यूल होने के बजाय पेंडिंग रहते हैं। Pod का nodeAllocatableResourceClaimStatuses रीडबैक और निदान का समर्थन करता है, लेकिन यह लेज़र कंसिस्टेंसी जांच की जगह नहीं लेता है।

चूंकि v1.36 अल्फा बना हुआ है, इसलिए मैं पहले कैनरी नोड्स पर DRANodeAllocatableResources सक्षम करूंगा और मिश्रित क्लेम और Pods, NUMA, नोड रीस्टार्ट, रिलीज़ और ड्राइवर अपग्रेड का परीक्षण करूंगा। रोलबैक नए क्लेम को रोकता है, मौजूदा बाइंडिंग्स को सुरक्षित रखता है, और मैपिंग मरम्मत से पहले लेज़र को एक्सपोर्ट करता है। RBAC DRA सिंथेटिक सबरिसोर्सेज और नोड-स्कोप्ड अनुमतियों तक सीमित है।

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

• गलती: प्रति डिवाइस एक बार और क्लेम रीट्राई के बाद दोबारा नोड CPU काटना → यह क्यों विफल होता है: कोई स्थिर आइडेम्पोटेंसी की नहीं है → सुधार: क्लेम UID, डिवाइस ID और मैपिंग संस्करण द्वारा डुप्लिकेट हटाएं।
• गलती: उदाहरण वाले YAML को प्रोडक्शन API ऑब्जेक्ट के रूप में सबमिट करना → यह क्यों विफल होता है: फ़ील्ड स्कीमा और यूनिट्स वर्शन वाले हैं → सुधार: ResourceSlice API और ड्राइवर वर्शन को सत्यापित करें।
• गलती: ResourceSlice अनुपलब्ध होने पर पुरानी क्षमता का उपयोग जारी रखना → यह क्यों विफल होता है: पुराना डेटा ओवरकमिट कर सकता है → सुधार: एक फ्रेशनेस विंडो का उपयोग करें और समाप्त होने के बाद नए क्लेम को पेंडिंग रखें।
• गलती: अल्फा गेट को एक साथ हर जगह सक्षम करना → यह क्यों विफल होता है: कम्पैटिबिलिटी और रोलबैक का परीक्षण नहीं किया गया है → सुधार: कैनरी, मेट्रिक्स, क्लेम एडमिशन स्टॉप और एक रिकवरेबल लेज़र का उपयोग करें।
• गलती: स्टेटस-राइट एरर को ठीक करने के लिए RBAC का विस्तार करना → यह क्यों विफल होता है: यह डेटा कंसिस्टेंसी को ठीक किए बिना अधिकार बढ़ाता है → सुधार: सिंथेटिक सबरिसोर्सेज, नोड-अवेयर वर्ब्स और ऑडिट लॉग्स का उपयोग करें।

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

आपको allocationMultiplier बनाम capacityKey का उपयोग कब करना चाहिए?

जब प्रत्येक एलोकेशन एक निश्चित CPU या मेमोरी मात्रा की खपत करता है, तो allocationMultiplier का उपयोग करें। जब खपत डिवाइस क्षमता या वर्कलोड के साथ बदलती है, ड्राइवर-परिभाषित, ऑडिट करने योग्य सिमेंटिक्स के साथ, तो capacityKey का उपयोग करें। दोनों विकल्पों के लिए यूनिट्स और वर्शनिंग को स्थिर रखें।

आप सामान्य Pod रिक्वेस्ट्स और DRA मैपिंग की डबल काउंटिंग से कैसे बचते हैं?

एक लेज़र रखें: सामान्य रिक्वेस्ट्स रिक्वेस्ट स्ट्रीम में प्रवेश करती हैं, जबकि DRA योगदान क्लेम UID द्वारा की (keyed) किए गए एलोकेशन स्ट्रीम में प्रवेश करते हैं। शेड्यूलर प्रत्येक मैपिंग को एक बार लागू करता है और स्रोत व संस्करण को रिकॉर्ड करता है। डुप्लिकेट कीज़ को अस्वीकार कर दिया जाता है और अलर्ट किया जाता है।

क्या ड्राइवर रीस्टार्ट के तुरंत बाद शेड्यूलिंग फिर से शुरू होनी चाहिए?

नहीं। ResourceSlices का पुनर्निर्माण करें, बाउंड क्लेम को मान्य करें, मोनोटोनिक संस्करणों और क्षमता की पुष्टि करें, फिर नए क्लेम स्वीकार करें। पुनर्निर्माण के दौरान, मौजूदा बाइंडिंग्स को सुरक्षित रखें और नए Pods को पेंडिंग रखें।

आप कैसे दिखाते हैं कि NUMA प्लेसमेंट अकाउंटिंग को सुरक्षित रखता है?

क्रॉस-NUMA, सेम-NUMA, रिलीज़-रीट्राई और नोड-रीस्टार्ट इवेंट्स को रीप्ले करें। नोड के कुल, NUMA सब-लेज़र्स और Pod स्टेटस की तुलना करें। प्लेसमेंट विफलताओं, लेज़र डाइवर्जेंस, पेंडिंग समय और डुप्लिकेट-रिजेक्शन काउंट को ट्रैक करें।

अल्फा क्षमता को कब प्रमोट किया जा सकता है?

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

संदर्भ

• Kubernetes v1.36 DRA update (Kubernetes Blog)
• Feature Gates (Kubernetes Documentation)
• ResourceSlice API (Kubernetes Documentation)
• Pod API (Kubernetes Documentation)
• DRA hardening guide (Kubernetes Documentation)

इंटरव्यू चेकलिस्ट

ड्राइवर से ResourceSlice, क्लेम, शेड्यूलर, Node Allocatable लेज़र और Pod स्टेटस तक का फ्लो बनाएं। फिर इसमें आइडेम्पोटेंसी, वर्शन, NUMA, कैनरी और न्यूनतम विशेषाधिकार जोड़ें।

एक वाक्य में निष्कर्ष

DRA Node Allocatable तब सफल होता है जब एक एकल, वर्शन वाला, रोलबैक-सुरक्षित लेज़र प्रत्येक क्लेम के वास्तविक नोड-रिसोर्स योगदान का हिसाब रखता है।

अभ्यास जारी रखें

मैपिंग को मल्टी-नोड ResourceClaims तक विस्तारित करें और बताएं कि टोपोलॉजी, फ्रेशनेस और रिकवरी शेड्यूलिंग निर्णयों को कैसे बदलते हैं।