स्पाइक्स से बचत तक: Kubernetes Cost Optimization

एक तिमाही में हमारा AWS बिल 34% बढ़ गया। प्रोडक्ट रोडमैप में कोई बदलाव नहीं दिखा। कारण सरल था: हमारे Kubernetes क्लस्टर पैसे बर्बाद कर रहे थे।

इंजीनियर अक्सर अंदाज़ा लगाते हैं कि किसी सर्विस को कितने CPU और memory की आवश्यकता है। सुरक्षित रहने के लिए वे इसे बढ़ाकर (round up) लिख देते हैं। इससे 'फैंटम कैपेसिटी' (phantom capacity) पैदा होती है। आप उन संसाधनों के लिए भुगतान करते हैं जिनका आपके एप्लिकेशन कभी उपयोग नहीं करते।

यहाँ बताया गया है कि हमने इसे कैसे ठीक किया और मासिक लागत में 34% की बचत की।

मुख्य समस्या: Requests बनाम Limits

Requests वह है जिसकी आप गारंटी देते हैं। Kubernetes आपके pod को node पर रखने के लिए इस संख्या का उपयोग करता है। यही संख्या आपके बिल को निर्धारित करती है।

Limits एक ऊपरी सीमा (ceiling) की तरह हैं। यदि कोई pod CPU limit तक पहुँच जाता है, तो उसकी गति धीमी हो जाती है। यदि यह memory limit तक पहुँच जाता है, तो यह बंद (die) हो जाता है।

कई टीमें requests को limits के बराबर सेट कर देती हैं। इसका मतलब है कि आप 24/7 पीक कैपेसिटी के लिए भुगतान करते हैं, भले ही आपकी सर्विस idle क्यों न हो।

बचत के लिए हमारी रणनीति

  • कार्रवाई करने से पहले मापें: वास्तविक उपयोग देखने के लिए Prometheus और Grafana का उपयोग करें।
  • Percentiles का उपयोग करें: 4 हफ्तों के p95 उपयोग को देखें। Averages का उपयोग न करें। Averages स्पाइक्स को छिपा देते हैं।
  • Requests को सही आकार दें (Right-size): Requests को p95 उपयोग प्लस 20% बफर पर सेट करें।
  • CPU limits को मैनेज करें: Throttling से बचने के लिए संवेदनशील सेवाओं पर बहुत सख्त CPU limits न रखें।
  • Scaling को ऑटोमेट करें: ट्रैफिक स्पाइक्स के लिए HPA और व्यक्तिगत pods को ट्यून करने के लिए VPA का उपयोग करें।

परिणाम

हमने अपने node count को 40 से घटाकर 26 कर दिया। औसत CPU utilization 14% से बढ़कर 52% हो गया। मासिक compute लागत $48,200 से घटकर $31,900 हो गई। Latency में वास्तव में 35% का सुधार हुआ।

Optimization कोई एक बार का प्रोजेक्ट नहीं है। यह एक आदत है। यदि आप अंदाज़े के आधार पर resource request लिखते हैं, तो आप पैसे बर्बाद कर रहे हैं।

आपके क्लस्टर के लिए चेकलिस्ट:

• एक dashboard बनाएं जो requested बनाम वास्तविक उपयोग दिखाए। • 4 सप्ताह के डेटा के आधार पर requests सेट करें। • बदलाव करने देने से पहले VPA को recommendation mode में चलाएं। • हर तिमाही में resource specs की समीक्षा करें। • इंजीनियरिंग टीमों को उनकी अपनी लागत की दृश्यता (visibility) प्रदान करें।

Source: https://dev.to/samarth_05/from-spikes-to-savings-practical-k8s-cost-optimization-for-2026-75k

Optional learning community: https://t.me/GyaanSetuAi