DevOps इंजीनियर इंटरव्यू सवाल

किसी workload के लिए CPU और memory के requests और limits कैसे सेट करते हैं?

इंटरव्यूअर असल में क्या परख रहा है, अपना जवाब कैसे स्ट्रक्चर करें, और एक बोला हुआ उदाहरण जिसे आप अपना सकते हैं।

छोटा जवाब

requests को देखे गए इस्तेमाल से सेट करें, आमतौर पर CPU के लिए median के आसपास और memory के लिए peak के करीब, क्योंकि requests ही scheduling और capacity तय करते हैं। memory limit को request के पास रखें, क्योंकि उससे ऊपर जाते ही container मार दिया जाता है, और CPU limits में सावधानी बरतें क्योंकि वे throttling पैदा करते हैं जो बिना वजह वाली latency की शक्ल में दिखती है। नंबरों को असली डेटा के साथ दोबारा देखें, एक सर्विस से दूसरी में कॉपी न करें।

इंटरव्यूअर यह क्यों पूछते हैं

यह व्यावहारिक सवाल है जहां गलत जवाब प्रोडक्शन में असली दर्द देते हैं, और इंटरव्यूअर के पास शायद इसके निशान हैं। वे चाहते हैं कि आपको पता हो कि CPU compressible है और memory नहीं, कि CPU limits धीमे होने की जगह throttling देती हैं, और कि requests scheduling और cluster की लागत दोनों तय करते हैं। quality of service classes और इस्तेमाल नापने का तरीका बताना गहराई दिखाता है।

अपना जवाब कैसे स्ट्रक्चर करें

  • समझाएं कि requests scheduling चलाते हैं और limits enforcement।
  • CPU और memory को अलग रखें क्योंकि उनका बर्ताव अलग है।
  • असली डेटा से नंबर निकालने का तरीका बताएं।
  • throttling, out of memory kills और quality of service का ज़िक्र करें।

उदाहरण जवाब

बोला हुआ उदाहरण, पहले व्यक्ति में

requests वह हैं जिनसे scheduler pod की जगह तय करता है और असल में आप जिनका पैसा दे रहे हैं, और limits वह छत है जिसे runtime लागू करता है। दोनों resources का बर्ताव बिल्कुल अलग है। CPU compressible है, तो CPU limit से टकराने का मतलब है container throttle हो गया, और यह बिना किसी साफ वजह के latency spikes की तरह दिखता है, जिसे डिबग करना भयानक है। memory compressible नहीं, तो memory limit पार करने का मतलब है container सीधे मार दिया गया। इससे मेरे डिफ़ॉल्ट बनते हैं: CPU request देखे गए median इस्तेमाल से थोड़ी गुंजाइश के साथ सेट करता हूं, और latency के लिहाज़ से संवेदनशील सर्विसेज़ पर CPU limits को लेकर आमतौर पर सतर्क रहता हूं, या उन्हें उदारता से सेट करता हूं। memory के लिए request असली peak के पास और limit उसके करीब रखता हूं, ताकि कोई leak चुपचाप node खाने की जगह जल्दी और साफ दिखकर फेल हो। नंबर मैं दो हफ्ते के असली इस्तेमाल के percentiles से लेता हूं, किसी दूसरी सर्विस से कॉपी करके नहीं, और load tests के बाद दोबारा देखता हूं। दूसरा पहलू यह है कि फुलाए हुए requests ही मुख्य वजह हैं कि clusters खाली दिखते हैं और फिर भी कुछ schedule नहीं कर पाते।

जल्दी ही यह इंटरव्यू देने जा रहे हैं? GhostPilot आपकी लाइव कॉल सुनता है, सवाल पूछे जाते ही उसे पकड़ लेता है, और रियल-टाइम में एक स्ट्रक्चर्ड जवाब आपकी स्क्रीन पर डाल देता है। अगले मॉक में इसे आजमाएं, या ले लें एक $29 Session Pass, कोई सब्सक्रिप्शन नहीं, असली इंटरव्यू के लिए।

देखें यह कैसे काम करता है

फॉलो-अप सवाल जिनकी उम्मीद रखें

  • जब कोई pod अपनी memory limit पार कर जाता है तो उसके साथ क्या होता है?
  • आप जानबूझकर CPU limit क्यों छोड़ सकते हैं?
  • quality of service classes eviction के क्रम पर कैसे असर डालती हैं?

DevOps इंजीनियर के और सवाल

आपका इंटरव्यूअर इसका अपना वर्ज़न पूछेगा। फ्री Question Predictor में अपना असली जॉब डिस्क्रिप्शन पेस्ट कीजिए और वो 20 सवाल पाइए जो उस रोल में सबसे ज्यादा पूछे जाने की संभावना है, साथ में यह भी कि हर सवाल असल में क्या टटोल रहा है।

मेरे सवाल प्रेडिक्ट करें

मुश्किल सवाल पूछे जाने से पहले उनकी रिहर्सल कीजिए

एक लाइव कोपायलट के साथ प्रैक्टिस कीजिए, फिर तैयार होकर अंदर जाइए। $29 Session Pass आपको इंटरव्यू पार करा देता है, न कोई सब्सक्रिप्शन, न कोई लॉक-इन।

GhostPilot पाएं