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

समस्या और लागू होने वाले परिदृश्य

आप Kubernetes पर एक डिस्ट्रीब्यूटेड-ट्रेनिंग प्लेटफ़ॉर्म के मालिक हैं। एक वर्कलोड को PodGroup द्वारा दर्शाया जाता है, और इसके Pods को कम्युनिकेशन लेटेंसी कम करने के लिए एक रैक या ज़ोन साझा करना चाहिए। यदि एक टोपोलॉजी डोमेन कम से कम minCount Pods को फिट नहीं कर सकता है, तो वर्कलोड को अनशेड्यूल करने योग्य (unschedulable) ही रहना चाहिए।

यह प्लेटफ़ॉर्म-इंजीनियरिंग, SRE और सिस्टम-डिज़ाइन इंटरव्यू के लिए उपयुक्त है। डिफ़ॉल्ट रूप से अक्षम (disabled), Kubernetes v1.36 alpha Topology-Aware Scheduling मान लें, जिसमें प्रति PodGroup एक टोपोलॉजी बाधा (constraint) है।

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

• क्या आप टोपोलॉजी स्प्रेड (topology spread) के साथ क्रॉस-डोमेन बैलेंसिंग और एक गैंग के लिए समान-डोमेन प्लेसमेंट के बीच अंतर करते हैं।
• क्या PodGroup, नोड लेबल्स, कैंडिडेट प्लेसमेंट, रिसोर्स फिजिबिलिटी और एटॉमिक बाइंडिंग एक डेटा फ्लो बनाते हैं।
• क्या आप minCount, क्षमता की कमी, स्केल-अप और टोपोलॉजी-ट्रिगर्ड प्रीएम्प्शन की अनुपस्थिति की व्याख्या करते हैं।
• क्या आप डिज़ाइन को प्रोडक्शन-रेडी कहने से पहले अल्फा स्थिति, हेटेरोजेनियस ग्रुप्स और रोलबैक जोखिम की पहचान करते हैं।

उत्तर देने से पहले स्पष्टीकरण संबंधी प्रश्न

1. क्या Pods को एक रैक, ज़ोन या NUMA डोमेन साझा करना होगा? प्रत्येक टोपोलॉजी की (topology key) लेटेंसी और क्षमता संबंधी मान्यताओं को बदल देती है।
2. क्या प्रत्येक Pod को एक साथ शुरू होना चाहिए, या आगे बढ़ने के लिए minCount ही पर्याप्त है? यह Gang नीति और लोच (elasticity) निर्धारित करता है।
3. क्या Pods होमोजेनियस हैं? अलग-अलग रिसोर्स रिक्वेस्ट इस बात को प्रभावित करती हैं कि कोई कैंडिडेट प्लेसमेंट मिल सकता है या नहीं।
4. क्या क्लस्टर स्केल या प्रीएम्प्ट कर सकता है? v1.36 TAS केवल टोपोलॉजी को संतुष्ट करने के लिए प्रीएम्प्ट नहीं करता है।

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

"मैं लक्ष्य को रेप्लिकेट स्प्रेडिंग के बजाय एक टोपोलॉजी डोमेन के भीतर ग्रुप-लेवल फिजिबिलिटी के रूप में परिभाषित करता हूँ। एक Workload टेम्पलेट gang और minCount के साथ एक PodGroup बनाता है; नोड लेबल्स टोपोलॉजी की प्रदान करते हैं। शेड्यूलर कैंडिडेट नोड सबसेट्स उत्पन्न करता है, पूरे ग्रुप की जांच करता है, और फिजिबल प्लेसमेंट्स को स्कोर करता है। यदि कोई भी फिट नहीं होता है, तो ग्रुप अनशेड्यूल करने योग्य रहता है। कंट्रोलर और ऑटोस्केलर पूरे रिसोर्स शेप का आकलन करते हैं, और प्रीएम्प्शन को अलग से संभाला जाता है क्योंकि v1.36 TAS इसे ट्रिगर नहीं करता है। मैं अल्फा फीचर गेट के तहत डोमेन क्षमता, नोड की हानि और हेटेरोजेनियस रिक्वेस्ट्स का परीक्षण करता हूँ।"

चरण-दर-चरण विस्तृत विश्लेषण

1. सह-स्थान (co-location) बताएं, न कि स्प्रेडिंग

topologySpreadConstraints डोमेन में Pods को संतुलित करने के लिए maxSkew का उपयोग करता है; इस प्रश्न में सभी सदस्यों को एक टोपोलॉजी-लेबल मान साझा करने की आवश्यकता है। शब्दार्थ (semantics) को मिलाने से विपरीत प्लेसमेंट उत्पन्न होता है, इसलिए इनवेरिएंट को "एक डोमेन में कम से कम minCount फिट होना चाहिए" के रूप में लिखें।

2. PodGroup अनुबंध को परिभाषित करें

टेम्पलेट Gang नीति, minCount और एक टोपोलॉजी की घोषित करता है। एक उदाहरणात्मक कॉन्फ़िगरेशन है:

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
spec:
  schedulingPolicy:
    gang:
      minCount: 4
  schedulingConstraints:
    topology:
      - key: topology.example.com/rack

नोड्स को स्थिर, नियंत्रित लेबल मानों की आवश्यकता होती है। PodGroup प्लेसमेंट व्यक्त करता है; Workload कंट्रोलर अभी भी मेंबर निर्माण, वर्शन और लाइफसाइकिल का प्रबंधन करता है।

3. कैंडिडेट प्लेसमेंट की व्याख्या करें

शेड्यूलर पहले रिसोर्सेज, टेंट्स (taints), एफिनिटी और टोपोलॉजी की का उपयोग करके कैंडिडेट नोड सबसेट्स उत्पन्न करता है। इसके बाद यह जांचता है कि क्या पूरा PodGroup प्रत्येक सबसेट के भीतर फिट बैठता है और फिजिबल प्लेसमेंट्स को स्कोर करता है। यह शुरुआती Pods को डोमेन में बाइंड करने और शेष सदस्यों को minCount को संतुष्ट करने में असमर्थ छोड़ने से बचाता है।

4. क्षमता, स्केल-अप और प्रीएम्प्शन को संभालें

यदि किसी भी कैंडिडेट डोमेन में पर्याप्त क्षमता नहीं है, तो पूरा ग्रुप अनशेड्यूल करने योग्य रहता है। ऑटोस्केलर को पहले Pending Pod के लिए स्केल करने के बजाय पूर्ण CPU, मेमोरी, GPU और डोमेन शेप का उपभोग करना चाहिए। v1.36 TAS टोपोलॉजी को संतुष्ट करने के लिए Pod या Workload प्रीएम्प्शन को ट्रिगर नहीं करता है, इसलिए क्षमता आरक्षण (reservations), कतारें (queues), या एक स्पष्ट अपस्ट्रीम प्रीएम्प्शन नीति अलग आवश्यकताएं हैं।

5. मेंबर पुनः निर्माण और डोमेन स्टिकिनेस को संभालें

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

6. अल्फा और हेटेरोजेनियस सीमाओं का मूल्यांकन करें

v1.36 API अल्फा है और डिफ़ॉल्ट रूप से अक्षम है। आधिकारिक रिलीज़ नोट्स में कहा गया है कि हेटेरोजेनियस PodGroups या इंटर-Pod निर्भरताओं के लिए प्लेसमेंट मिलने की गारंटी नहीं है, भले ही कोई प्लेसमेंट मौजूद हो। प्रोडक्शन गेट्स में वर्शन, फीचर गेट, शेड्यूलर प्लगइन, ऑटोस्केलर और रोलबैक शामिल होने चाहिए; एक सफल शेड्यूल कोई सार्वभौमिक गारंटी नहीं है।

7. एक सत्यापन और रोलबैक लूप बनाएं

उसी ट्रेनिंग वर्कलोड को ठीक-ठाक (just-enough) डोमेन क्षमता, एक गायब नोड, गायब टोपोलॉजी लेबल्स, विभिन्न GPU प्रकारों और मेंबर पुनः निर्माण के साथ चलाएं। कैंडिडेट डोमेन, फिजिबल-मेंबर काउंट, Pending कारणों, प्रतीक्षा समय, क्रॉस-डोमेन ट्रैफ़िक और ट्रेनिंग थ्रूपुट को रिकॉर्ड करें। यदि कैनरी परीक्षण विफल हो जाते हैं, तो ऑडिट के लिए PodGroup इवेंट्स को संरक्षित करते हुए फीचर गेट को अक्षम करें या सामान्य Gang शेड्यूलिंग पर वापस लौटें।

उच्च-गुणवत्ता वाला नमूना उत्तर

मैं इनवेरिएंट को संतुलन के लिए स्प्रेड बाधाओं का उपयोग करने के बजाय "कम से कम minCount सदस्य एक साथ एक टोपोलॉजी डोमेन में फिट होते हैं" के रूप में परिभाषित करूँगा। एक Workload कंट्रोलर Gang, minCount और एक टोपोलॉजी की के साथ एक PodGroup बनाता है, फिर Pods बनाता है जो इसे संदर्भित करते हैं। शेड्यूलर रिसोर्सेज और नोड लेबल्स से कैंडिडेट डोमेन उत्पन्न करता है, पूरे ग्रुप की जांच करता है, और केवल फिजिबल डोमेन को स्कोर करता है; यदि कोई काम नहीं करता है, तो ग्रुप Pending रहता है। ऑटोस्केलर ग्रुप शेप से स्केल करता है, जबकि प्रीएम्प्शन अलग है क्योंकि v1.36 TAS इसे ट्रिगर नहीं करता है। फिर से बनाए गए सदस्य डोमेन स्टिकिनेस बनाए रखते हैं; यदि वह डोमेन खो जाता है, तो एक नई जनरेशन बनाएं। अंत में, प्रतीक्षा समय, क्रॉस-डोमेन ट्रैफ़िक और ट्रेनिंग थ्रूपुट को मापते हुए अल्फा गेट के पीछे नोड हानि, गायब लेबल्स, हेटेरोजेनियस GPUs और रोलबैक का परीक्षण करें।

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

• लक्षण: maxSkew के साथ समान-डोमेन प्लेसमेंट की व्याख्या करना। यह क्यों विफल होता है: स्प्रेड का लक्ष्य वितरण है, जो Gang सह-स्थान के विपरीत है। समाधान: पहले PodGroup सिंगल-डोमेन इनवेरिएंट बताएं।
• लक्षण: Pods को एक-एक करके बाइंड करना। यह क्यों विफल होता है: शुरुआती बाइंडिंग कई डोमेन में क्षमता की खपत करती हैं और minCount तक पहुंचने का कोई रास्ता नहीं छोड़ती हैं। समाधान: पहले पूर्ण कैंडिडेट प्लेसमेंट का मूल्यांकन करें।
• लक्षण: मान लेना कि TAS स्वचालित रूप से प्रीएम्प्ट करता है। यह क्यों विफल होता है: v1.36 स्पष्ट रूप से कहता है कि टोपोलॉजी-अवेयर शेड्यूलिंग प्रीएम्प्शन को ट्रिगर नहीं करती है। समाधान: आरक्षण, कतारें या एक अपस्ट्रीम प्रीएम्प्शन कंट्रोलर डिज़ाइन करें।
• लक्षण: हेटेरोजेनियस ग्रुप्स और अल्फा स्थिति को अनदेखा करना। यह क्यों विफल होता है: प्लेसमेंट की गारंटी नहीं है और यह सुविधा डिफ़ॉल्ट रूप से अक्षम है। समाधान: वर्शन, गेट, प्लगइन और रोलबैक चेक जोड़ें।

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

क्या होगा यदि एक रैक minCount को फिट नहीं कर सकता है, लेकिन दो रैक मिलकर कर सकते हैं?

समान-डोमेन इनवेरिएंट पूरा नहीं होता है, इसलिए ग्रुप को Pending रखें या केवल तभी minCount कम करें जब एप्लिकेशन लोच (elasticity) की अनुमति देता हो। चुपचाप क्रॉस-रैक प्लेसमेंट पर फॉलबैक न करें क्योंकि कम्युनिकेशन की मान्यता बदल गई है।

ऑटोस्केलर को सही तरीके से कैसे स्केल करना चाहिए?

पूर्ण रिसोर्स रिक्वेस्ट, टोपोलॉजी की और minCount को एक स्केल यूनिट के रूप में मानें। एक टारगेट डोमेन में आवश्यक नोड प्रकारों और संख्या का अनुमान लगाएं, स्केल-अप के बाद उम्मीदवारों को फिर से उत्पन्न करें, और एक प्रतीक्षा समय सीमा (wait deadline) लागू करें।

फिर से बनाया गया सदस्य दूसरे डोमेन में क्यों नहीं जा सकता?

दस्तावेज़ीकृत व्यवहार नए सदस्यों को उसी डोमेन में रखता है जहाँ मौजूदा सदस्य चलते हैं; किसी एक को स्थानांतरित करने से लेटेंसी और साझा-रिसोर्स की मान्यताएँ बदल जाती हैं। यदि डोमेन स्थायी रूप से खो जाता है, तो पुराने को चुपचाप बदलने के बजाय एक नया PodGroup जनरेशन बनाएं।

यह टोपोलॉजी स्प्रेड बाधाओं (topology spread constraints) के साथ कैसे सह-अस्तित्व में रह सकता है?

एक ट्रेनिंग जॉब के अंदर सदस्यों को सह-स्थित करने के लिए TAS का उपयोग करें; कई जॉब्स में रेप्लिकेट्स को वितरित करने के लिए स्प्रेड का उपयोग करें। दोनों को एक Pod पर रखने से पहले, परीक्षण करें कि क्या उनकी हार्ड बाधाओं में एक गैर-खाली प्रतिच्छेदन (non-empty intersection) है, अन्यथा Pods Pending रह सकते हैं।

साधारण Gang शेड्यूलिंग TAS से बेहतर कब होगी?

साधारण Gang तब चुनें जब क्रॉस-डोमेन कम्युनिकेशन सस्ता हो, डोमेन क्षमता अक्सर सीमित हो, अल्फा फीचर आपके रोलआउट के लिए तैयार न हो, या वर्कलोड को साझा रैक की आवश्यकता न हो। TAS को केवल तभी सक्षम करें जब थ्रूपुट लाभ क्षमता और परिचालन लागत को सही ठहराते हों।