اضافے سے بچت تک: Kubernetes لاگت کی بہتری

ایک سہ ماہی میں ہمارا AWS بل 34% بڑھ گیا۔ پروڈکٹ روڈ میپ میں کوئی تبدیلی نظر نہیں آئی۔ وجہ سادہ تھی: ہمارے Kubernetes کلسٹرز پیسے ضائع کر رہے تھے۔

انجینئرز اکثر اندازہ لگاتے ہیں کہ ایک سروس کو کتنے CPU اور memory کی ضرورت ہے۔ وہ حفاظت کے طور জন্য اسے بڑھا کر لکھ دیتے ہیں۔ اس سے فرضی صلاحیت (phantom capacity) پیدا ہو جاتی ہے۔ آپ ان وسائل کے لیے ادائیگی کرتے ہیں جنہیں آپ کی ایپلی کیشنز کبھی استعمال نہیں کرتیں۔

یہاں بتایا گیا ہے کہ ہم نے اسے کیسے ٹھیک کیا اور ماہانہ اخراجات میں 34% کی بچت کی۔

بنیادی مسئلہ: Requests بمقابلہ Limits

Requests وہ ہیں جن کی آپ ضمانت دیتے ہیں۔ Kubernetes اس نمبر کو آپ کے pod کو node پر رکھنے کے لیے استعمال کرتا ہے۔ یہی نمبر آپ کے بل کا تعین کرتا ہے۔

Limits ایک حد (ceiling) ہیں۔ اگر کوئی pod CPU limit تک پہنچ جائے تو وہ سست ہو جاتا ہے۔ اگر یہ memory limit تک پہنچ جائے تو یہ بند (die) ہو جاتا ہے۔

بہت سی ٹیمیں requests کو limits کے برابر رکھ دیتی ہیں۔ اس کا مطلب ہے کہ آپ 24/7 عروج کی صلاحیت (peak capacity) کے لیے ادائیگی کرتے ہیں، چاہے آپ کی سروس غیر فعال (idle) ہی کیوں نہ ہو۔

بچت کے لیے ہماری حکمت عملی

  • عمل کرنے سے پہلے پیمائش کریں: اصل استعمال دیکھنے کے لیے Prometheus اور Grafana کا استعمال کریں۔
  • percentiles کا استعمال کریں: 4 ہفتوں کے p95 استعمال کو دیکھیں۔ اوسط (averages) کا استعمال نہ کریں۔ اوسط اچانک اضافے (spikes) کو چھپا دیتے ہیں۔
  • requests کو درست سائز دیں: requests کو p95 استعمال کے ساتھ 20% اضافی حد (buffer) پر سیٹ کریں۔
  • CPU limits کو مینیج کریں: throttling سے بچنے کے لیے حساس سروسز پر سخت CPU limits سے گریز کریں۔
  • اسکیلنگ کو خودکار بنائیں: ٹریفک کے اضافے کے لیے HPA اور انفرادی pods کو ٹیون کرنے کے لیے VPA کا استعمال کریں۔

نتائج

ہم نے اپنے nodes کی تعداد 40 سے کم کر کے 26 کر دی۔ اوسط CPU استعمال 14% سے بڑھ کر 52% ہو گیا۔ ماہانہ کمپیوٹ اخراجات $48,200 سے کم ہو کر $31,900 رہ گئے۔ Latency میں درحقیقت 35% بہتری آئی۔

Optimization کوئی ایک بار کا پروجیکٹ نہیں ہے۔ یہ ایک عادت ہے۔ اگر آپ اندازے کی بنیاد پر resource request لکھتے ہیں، تو آپ پیسے ضائع کر رہے ہیں۔

آپ کے کلسٹر کے لیے چیک لسٹ:

• ایک ڈیش بورڈ بنائیں جو 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