یہ ہینڈ بک 7 قدمی پلے بک کے لیے ایک مکمل گائیڈ ہے جس نے پروڈکٹ کوڈ کی ایک لائن کو چھوئے بغیر میرا EKS بل $85,000/ماہ سے $34,000/ماہ تک لے لیا ہے۔
میں نے 10 سے زیادہ کمپنیوں میں EKS کلسٹرز کا آڈٹ کیا ہے۔ ہم ہر بار فضلے کے ایک جیسے نمونے دیکھتے ہیں: ضرورت سے زیادہ نوڈس، AZs کے درمیان ڈیٹا کی منتقلی، اور غیر فعال EBS والیوم۔ اور سب سے مہنگی غلطی آپ کے سائز سے پہلے ایک کمپیوٹ کمٹمنٹ خریدنا ہے۔
یہ ہینڈ بک اس کا حل ہے۔ میں نے اس 7 قدمی پلے بک کو ہر اس کمپنی پر EKS لاگت کو 50-60% تک کم کرنے کے لیے استعمال کیا ہے جس نے اسے لاگو کیا ہے۔ پروڈکٹ کوڈ میں کوئی تبدیلی یا ڈاؤن ٹائم نہیں ہے۔ بنیادی ڈھانچے کی اصلاح درست ترتیب میں چلتی ہے۔
اس گائیڈ کے اختتام تک، آپ جان لیں گے کہ پوڈ ریسورس کی درخواستوں کو کس طرح رائٹ سائز کرنا ہے، کارپینٹر کو ذہین بن پیکنگ اور اسپاٹ ڈائیورسیفکیشن کے لیے لاگو کرنا، 20% سستی کمپیوٹ کے لیے ہم آہنگ کام کے بوجھ کو Graviton میں منتقل کرنا، اور VPC اینڈ پوائنٹس کا استعمال کرتے ہوئے NAT گیٹ وے فیس کو مکمل طور پر ختم کرنا۔
تمام Terraform ماڈیولز، NodePool ٹیمپلیٹس، اور آٹومیشن اسکرپٹس جن کا اس گائیڈ میں حوالہ دیا گیا ہے، ساتھی ذخیرہ میں github.com/aayostem/eks-cost-optimization پر دستیاب ہیں۔ ریپوزٹری میں ہر قدم کے لیے ڈیپلائی کرنے کے لیے تیار کنفیگریشن شامل ہے، لہذا آپ اسی دوپہر کو پڑھنے سے عمل درآمد تک جا سکتے ہیں۔
انڈیکس
جو آپ سیکھیں گے۔
-
پوڈ ریسورس کی درخواستوں کو مناسب سائز کے لیے VPA کی سفارشات کا استعمال کیسے کریں۔
-
اسپاٹ ڈائیورسیفکیشن اور خودکار انضمام کے ساتھ کارپینٹر سیٹ اپ مکمل کریں۔
-
تمام غیر GPU ورک بوجھ کے لیے Graviton3 کی منتقلی
-
NAT گیٹ وے ڈیٹا کی منتقلی کے اخراجات کو ختم کرنے کے لیے VPC اینڈ پوائنٹس
-
EBS gp2 سے gp3 میں ہجرت کریں — کارکردگی میں کمی کے بغیر 20% سستا
-
مشترکہ داخلے کے ذریعے بیلنسر انضمام کو لوڈ کریں۔
-
ROI کو زیادہ سے زیادہ کرنے کے لیے 7 قدموں کی ترتیب – اور ترتیب اختیاری کیوں نہیں ہے
آئیے اندر غوطہ لگاتے ہیں۔
شرطیں
پیروی کرنے سے پہلے، آپ کو ضرورت ہو گی:
علم:
-
ایک بار جب آپ Kubernetes سے واقف ہو جاتے ہیں، تو آپ ایپلیکیشنز کو تعینات کر سکتے ہیں اور پوڈز کا معائنہ کر سکتے ہیں۔
-
بنیادی AWS علم – EC2 مثال کی اقسام، VPCs، اور EBS والیوم کو سمجھیں۔
-
Terraform HCL اور Kubernetes YAML پڑھنے میں آسان ہیں۔
اوزار اور رسائی:
-
ایک موجودہ EKS کلسٹر جو Kubernetes 1.27 یا اس سے اوپر چلا رہا ہے۔
-
kubectlترتیب دینا اور ایک کلسٹر کی طرف اشارہ کرنا -
AWS CLI v2 انسٹال اور مناسب اجازتوں کے ساتھ تصدیق شدہ
-
ہیلم 3 نصب (کارپینٹر اور کیوبکوسٹ کے لیے)
-
کلسٹر میں میٹرکس سرور انسٹال ہے۔
ساتھی ذخیرہ: شروع کرنے سے پہلے اپنے ذخیرے کو کلون کریں۔ اس میں تمام YAML، Terraform، اور شیل اسکرپٹس شامل ہیں جن کا اس گائیڈ میں حوالہ دیا گیا ہے۔
git clone https://github.com/aayostem/eks-cost-optimization
cd eks-cost-optimization
متوقع بچت: عام اضافی پروویژننگ کے ساتھ $85,000/ماہ پر چلنے والے کلسٹر کے لیے، آپ تمام سات مراحل کو مکمل کرنے کے بعد $40,000 سے $55,000/ماہ کی بچت کی توقع کر سکتے ہیں۔ ہر ماہ $10,000 سے کم کمانے والے چھوٹے کلسٹرز میں عام طور پر 40-50% کمی نظر آتی ہے۔
حصہ 1: معیار — آپ کا EKS پیسہ کہاں جاتا ہے۔
1.1 عام EKS لاگت کا تجزیہ
کسی بھی چیز کو چھونے سے پہلے، آپ کو یہ جاننا ہوگا کہ آپ کا پیسہ کہاں جا رہا ہے۔ پہلے غلط زمرے کو بہتر بنانا آپ کی ٹیم کے لیے انجینئرنگ کے ہفتوں کا وقت ضائع کرنے اور کوئی معنی خیز کمی دیکھنے کا ایک طریقہ ہے۔
یہاں ایک عام $85,000 فی مہینہ EKS کلسٹر کی خرابی ہے:
| زمرہ | ماہانہ لاگت | فیصد | ضائع کرنے کی صلاحیت |
|---|---|---|---|
| کمپیوٹ (EC2 نوڈس) | $52,000 | 61% | زیادہ – زیادہ فراہمی، غلط مثال کی قسم |
| ڈیٹا کی منتقلی | $15,300 | 18% | بہت زیادہ — کراس-AZ اور NAT گیٹ وے چارجز |
| ذخیرہ (EBS والیوم) | $10,200 | 12% | میڈیم — منقطع جلدیں اور gp2 بمقابلہ gp3 |
| لوڈ بیلنسر | $4,250 | 5% | کم سے درمیانے درجے تک – سنگل سروس ALB |
| ای کے ایس کنٹرول ہوائی جہاز | $72 | <1% | کوئی نہیں – یہ ایک مقررہ لاگت ہے۔ |
| مختلف | $3,178 | 4% | کم |
کمپیوٹ اور ڈیٹا کی منتقلی ایک ساتھ 79% لاگت اور 90% قابل اصلاح فضلہ ہے۔ وہ مقاصد ہیں۔
شروع کرنے سے پہلے، درج ذیل کمانڈ کو چلا کر اپنا تجزیہ چیک کریں:
# Pull last month's cost breakdown by service
# Save this output — it becomes your before number
aws ce get-cost-and-usage \
--time-period Start=\((date -d 'last month' +%Y-%m-01),End=\)(date +%Y-%m-01) \
--granularity MONTHLY \
--group-by Type=DIMENSION,Key=SERVICE \
--metrics UnblendedCost \
--query 'ResultsByTime[0].Groups[*].{Service:Keys[0],Cost:Metrics.UnblendedCost.Amount}' \
--output table | sort -k3 -rn
اسکرین شاٹ لیں اور آؤٹ پٹ کو محفوظ کریں۔ اگلے مرحلے پر جانے سے پہلے آپ اپنی اصل بچت کو دیکھنے کے لیے ہر قدم کے بعد ان کا موازنہ کر سکتے ہیں۔
1.2 مہنگی ترین غلطی: غلط اصلاحی ترتیب
یہاں یہ ہے کہ زیادہ تر ٹیمیں کیا کرتی ہیں جب انہیں AWS کا بڑا بل موصول ہوتا ہے:
-
بچت کے منصوبے فوراً خریدیں اور 30% کی چھوٹ کے ساتھ ضائع کرنا بند کریں۔
-
اس کے بعد ہم نے کارپینٹر کو لاگو کیا اور دریافت کیا کہ ہم نے غلط مثال والے خاندانوں سے زیادتی کی ہے۔
-
اس کے بعد آپ Graviton کی طرف ہجرت کرتے ہیں اور دریافت کرتے ہیں کہ بچت کے منصوبے میں ARM مثالیں شامل نہیں ہیں۔
نتیجے کے طور پر، آپ کو 12 سے 36 ماہ کے فضلے کی ادائیگی ختم ہو جاتی ہے جو 3 ہفتوں میں ختم ہو سکتی تھی۔
صحیح ترتیب یہ ہے:
Step 1: Right-size pod requests ← Always first
Step 2: Implement Karpenter ← Dynamic provisioning on rightsized requests
Step 3: Enable Spot for non-prod ← Karpenter handles fallback automatically
Step 4: Migrate to Graviton ← Karpenter makes this seamless
Step 5: Add VPC endpoints ← Eliminate data transfer charges
Step 6: Optimise EBS volumes ← Quick win, run alongside other steps
Step 7: Consolidate load balancers ← Final structural cleanup
اس کے بعد آپ کے ابھی مقرر کردہ آپٹمائزڈ معیار کی بنیاد پر بچت کا منصوبہ خریدیں۔
واحد اصول یہ ہے کہ پہلے اصلاح کریں اور پھر عہد کریں۔ سیونگ پلان خریدنے سے پہلے آپ جو بھی قدم اٹھاتے ہیں اس سے آپ کے پاس ایک سے تین سال تک کی رقم کم ہو جائے گی۔
حصہ 2: اسکیلنگ پوڈ ریسورس کی درخواستیں۔
2.1 ضرورت سے زیادہ فراہم کردہ درخواستیں مہنگی کیوں ہیں۔
Kubernetes وسائل کی بنیاد پر پوڈ کو شیڈول کرتا ہے۔ درخواست – اصل استعمال نہیں۔ 2 vCPUs اور 4 GB میموری کی درخواست کرنے والے پوڈ کے لیے ایک نوڈ کی ضرورت ہوتی ہے جو اس صلاحیت کو استعمال کر سکے، قطع نظر اس کے کہ پوڈ اسے استعمال کرتا ہے۔
غلط نقطہ نظر، جو درخواست کو زیادہ سے زیادہ بدترین تخمینہ پر سیٹ کرتا ہے، یہ ہے:
# Bad: Resource requests set during initial deployment, never revisited
# This pod actually uses 250m CPU and 512Mi memory on average
resources:
requests:
cpu: "2" # 8x more than actual usage
memory: "4Gi" # 8x more than actual usage
limits:
cpu: "4"
memory: "8Gi"
اگر تمام پوڈز کو 8 گنا سے زیادہ سبسکرائب کیا جاتا ہے، تو آپ کے کلسٹر کو آپ کے کام کے بوجھ سے 8 گنا زیادہ نوڈس کی ضرورت ہوگی۔ یہ وہ جگہ ہے جہاں بل کی 61% کمپیوٹ لائن آتی ہے۔
سب سے پہلے، کسی بھی چیز کو تبدیل کرنے سے پہلے اپنے اصل استعمال کو چیک کریں۔
# Install Metrics Server if not already running
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
# Check actual CPU and memory usage per pod
# Compare these numbers against your current resource requests
kubectl top pods --all-namespaces --sort-by=cpu
متوقع آؤٹ پٹ عام فرق دکھا رہا ہے:
NAMESPACE NAME CPU(cores) MEMORY(bytes)
production payment-api-xxx 25m 128Mi
production user-api-xxx 15m 96Mi
production notification-svc-xxx 5m 64Mi
staging worker-xxx 10m 256Mi
اگر پوڈ ہر ایک میں 2 سی پی یو کور کی درخواست کرتے ہیں لیکن درحقیقت 25 سے 15 ملین کور استعمال کرتے ہیں تو اس سے زیادہ درخواست کا تناسب 50 سے 80 گنا ہے۔ کلسٹر میں تمام نوڈس زیادہ تر خالی جگہیں ہیں جن کے لیے آپ ادائیگی کرتے ہیں۔
2.2 سفارشات کے لیے عمودی پوڈ آٹو اسکیلنگ کا استعمال کریں۔
Vertical Pod Autoscaler (VPA) ایک Kubernetes جزو ہے جو ہر تعیناتی کے لیے تاریخی CPU اور میموری کے استعمال کا تجزیہ کرتا ہے اور وسائل کی بہترین درخواستوں کی سفارش کرتا ہے۔ سب سے پہلے، اسے صرف تجویز کردہ موڈ میں استعمال کریں۔ یہ خود بخود آپ کو بتاتا ہے کہ بغیر کسی تبدیلی کے کیا سیٹ کرنا ہے، لہذا آپ کے پاس مکمل کنٹرول ہے اور آپ خود تبدیلیوں کا جائزہ لے سکتے ہیں اور ان کا اطلاق کرسکتے ہیں۔
درست نفاذ یہ ہے:
# Good: VPA in recommendation-only mode
# Watches your pod's actual usage for 24+ hours, then recommends right-sized requests
# updateMode: "Off" means it only recommends — it never restarts your pods
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
name: payment-api-vpa
namespace: production
spec:
targetRef:
apiVersion: apps/v1
kind: Deployment
name: payment-api
updatePolicy:
updateMode: "Off" # Recommendation only — you apply manually after review
resourcePolicy:
containerPolicies:
- containerName: "*"
minAllowed:
cpu: "100m" # VPA will never recommend below this floor
memory: "256Mi"
maxAllowed:
cpu: "2" # VPA will never recommend above this ceiling
memory: "4Gi"
VPA انسٹال کریں اور سفارشات تلاش کریں۔
# Install VPA components
kubectl apply -f https://github.com/kubernetes/autoscaler/releases/download/vertical-pod-autoscaler-1.0.0/vpa-v1.0.0.yaml
# Apply the VPA manifest for each deployment you want to right-size
kubectl apply -f vpa/payment-api-vpa.yaml
# Wait 24 hours for VPA to collect usage data, then check recommendations
kubectl describe vpa payment-api-vpa -n production
VPA کی سفارشات میں شامل ہیں:
Recommendation:
Container Recommendations:
Container Name: payment-api
Lower Bound:
cpu: 50m
memory: 128Mi
Target:
cpu: 250m ← Set your requests to this value
memory: 512Mi ← Set your requests to this value
Upper Bound:
cpu: 500m
memory: 1Gi
اپنی تعیناتی پر سفارشات کا اطلاق کریں۔
# Good: Right-sized requests based on VPA Target recommendation
resources:
requests:
cpu: "250m" # Down from 2000m — an 8x reduction
memory: "512Mi" # Down from 4096Mi — an 8x reduction
limits:
cpu: "500m" # 2x the request — headroom for genuine spikes
memory: "1Gi" # 2x the request
عام تعیناتی کی اقسام کے لیے تمام VPA مینی فیسٹ ہیں۔ vpa/ یہ ساتھی ذخیرہ میں ہے۔
2.3 دائیں سائز کا ROI
| میٹرک نظام | پہلے | بعد میں | بہتری |
|---|---|---|---|
| اوسط CPU استعمال | 18% | 65% | +47 فیصد پوائنٹس |
| نوڈس کی تعداد درکار ہے۔ | 42 | 28 | -33% |
| ماہانہ کمپیوٹ لاگت | $52,000 | $36,400 | -$15,600/مہینہ |
سفارشات کو لاگو کرنے کے بعد، بہتری دیکھیں۔
# Check cluster-level utilisation after right-sizing
# Target: 60–75% CPU and memory utilisation across nodes
kubectl top nodes
حصہ 3: بن پیکنگ اور جگہ کی تنوع کے لیے کارپینٹر۔
کارپینٹر ایک اوپن سورس Kubernetes نوڈ پروویژنر ہے جو AWS پر بنایا گیا ہے اور CNCF کو عطیہ کیا گیا ہے۔
جیسا کہ ڈیفالٹ Kubernetes Cluster Autoscaler پہلے سے ترتیب شدہ نوڈ گروپس کو اوپر اور نیچے کرتا ہے، کارپینٹر پوڈ کی زیر التواء اصل وسائل کی درخواستوں اور ان سے ملنے کے لیے بالکل موزوں EC2 مثال کی اقسام کو دیکھتا ہے۔ اس کا مطلب یہ ہے کہ آپ صرف دو یا تین پہلے سے تشکیل شدہ مثالوں کے بجائے ہزاروں دستیاب مثال کے خاندانوں میں سے متحرک طور پر منتخب کرتے ہیں۔ یہ کم استعمال کے لیے چلنے والے نوڈس کی مسلسل نگرانی کرتا ہے اور کام کے بوجھ کو کم نوڈس پر مستحکم کرکے خالی نوڈس کو خود بخود ختم کرتا ہے۔
نتیجے کے طور پر، کلسٹر کا سائز ہمیشہ سیٹ اپ کے وقت متوقع سائز کے بجائے موجودہ کام کے بوجھ کے لیے درکار سائز میں تبدیل کیا جاتا ہے۔
3.1 کلسٹر آٹو اسکیلر کی حدود
کلسٹر آٹو اسکیلر پہلے سے طے شدہ نوڈ گروپس کے ساتھ کام کرتا ہے۔ جیسا کہ آپ دستیاب مثال کی اقسام کو ترتیب دیتے ہیں، گروپ کو اوپر اور نیچے کی پیمائش ہوتی ہے۔
حد یہ ہے کہ آپ صرف پہلے سے تشکیل شدہ اقسام کی مثالیں فراہم کر سکتے ہیں۔ آپ متحرک طور پر صحیح مثال کی قسم کا انتخاب نہیں کر سکتے ہیں اس کی بنیاد پر کہ آپ کے موجودہ کام کے بوجھ کو درحقیقت کیا ضرورت ہے۔
جامد نوڈ گروپس کو استعمال کرنے کا غلط طریقہ یہ ہے:
# Bad: Two static node groups, each over-provisioning against worst-case scenarios
# CPU-optimised group runs even when workloads are memory-bound
# Memory-optimised group runs even when workloads are CPU-bound
eksctl create nodegroup \
--cluster my-cluster \
--name cpu-optimized \
--instance-types c5.2xlarge \
--nodes-min 5 --nodes-max 20
eksctl create nodegroup \
--cluster my-cluster \
--name memory-optimized \
--instance-types r5.2xlarge \
--nodes-min 3 --nodes-max 10
ہم بیک وقت ہر خاندان کے لیے بدترین صورت حال کے لیے تیاری کر رہے ہیں۔ کسی بھی لمحے، ایک گروہ کو کم استعمال کیا جا رہا ہے اور دوسرا گروہ پھیل رہا ہے۔ نہ ہی درست ہے۔
3.2 کارپینٹر اس مسئلے کو کیسے حل کرتا ہے۔
کارپینٹر پوڈ کی زیر التواء اصل وسائل کی درخواستوں کی نگرانی کرتا ہے اور اس کے مطابق مثال کی صحیح قسم کی فراہمی کرتا ہے۔ دو پہلے سے تشکیل شدہ مثال کی اقسام کے ساتھ ساتھ ہزاروں دستیاب مثال کی اقسام میں سے انتخاب کریں۔ مزید برآں، جب استعمال میں کمی آتی ہے، تو یہ خود بخود کم استعمال شدہ نوڈس کو کم نوڈس پر چلانے والے کام کے بوجھ کو مضبوط کر کے بند کر دیتا ہے۔
درست نفاذ یہ ہے:
# Good: Karpenter NodePool
# Karpenter selects the optimal instance type based on pending pod requirements
# Tries Spot first, falls back to On-Demand automatically when Spot isn't available
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: default
spec:
template:
spec:
requirements:
# Allow both x86 and ARM (Graviton) — Karpenter picks the cheaper option
- key: kubernetes.io/arch
operator: In
values: ["amd64", "arm64"]
# Try Spot first, fall back to On-Demand if unavailable
- key: karpenter.sh/capacity-type
operator: In
values: ["spot", "on-demand"]
# Exclude families with poor price-to-performance ratio
- key: karpenter.k8s.aws/instance-family
operator: NotIn
values: ["t2", "t3a"]
limits:
cpu: "1000"
memory: "4000Gi"
disruption:
# Remove underutilised nodes and reschedule their pods automatically
consolidationPolicy: WhenUnderutilized
# Recycle nodes after 30 days to ensure fresh, patched AMIs
expireAfter: 720h
ہر ترتیب کا کردار مندرجہ ذیل ہے:
-
consolidationPolicy: WhenUnderutilized: کارپینٹر مسلسل نوڈ کے استعمال کی نگرانی کرتا ہے اور پوڈ کو دوسری جگہ منتقل کرنے کے لیے کم استعمال شدہ نوڈس کو ہٹاتا ہے۔ نوڈس کی تعداد خود بخود کم ہو جاتی ہے کیونکہ بوجھ بغیر کسی دستی مداخلت کے کم ہوتا ہے۔ -
expireAfter: 720h: 30 دن سے زیادہ پرانے نوڈس کو مناسب طریقے سے تبدیل کیا جاتا ہے، اس بات کو یقینی بناتے ہوئے کہ آپ کا انفراسٹرکچر ہمیشہ موجودہ سیکیورٹی پیچ کے ساتھ جدید ترین EKS سے بہتر AMIs چلا رہا ہے۔ -
values: ["spot", "on-demand"]: کارپینٹر پہلے جگہ کی صلاحیت کو آزماتا ہے۔ اگر اسپاٹ آپ کی درخواست کردہ مثال کی قسم کے لیے دستیاب نہیں ہے، تو یہ بغیر کسی اطلاع یا دستی کارروائی کے واپس آن ڈیمانڈ پر آ جاتا ہے۔
کلسٹر آٹو اسکیلر سے محفوظ طریقے سے ہجرت کریں:
# Step 1: Install Karpenter alongside Cluster Autoscaler — do not remove CAS yet
helm repo add karpenter https://charts.karpenter.sh
helm install karpenter karpenter/karpenter \
--namespace karpenter \
--create-namespace \
--set settings.clusterName=your-cluster-name
# Step 2: Apply NodePool and NodeClass configuration
kubectl apply -f karpenter/nodepool.yaml
kubectl apply -f karpenter/nodeclass.yaml
# Step 3: Taint existing legacy nodes so new pods schedule on Karpenter nodes
# This migrates workloads gradually — zero downtime
kubectl taint nodes -l eks.amazonaws.com/nodegroup=cpu-optimized \
group=legacy:NoSchedule
# Step 4: Watch pods reschedule to Karpenter-managed nodes over the next hour
kubectl get pods -o wide --all-namespaces | grep -v legacy
# Step 5: After 30 days of stable operation, remove the old node groups
eksctl delete nodegroup --cluster my-cluster --name cpu-optimized
eksctl delete nodegroup --cluster my-cluster --name memory-optimized
نوڈ پول اور نوڈ کلاس ٹیمپلیٹس تعینات کرنے کے لیے تیار ہیں۔ karpenter/ یہ ساتھی ذخیرہ میں ہے۔
3.3 غیر پیداواری کام کے بوجھ کے لیے جگہ کی مثالیں۔
اسٹیجنگ اور ڈویلپمنٹ ورک بوجھ کو آن ڈیمانڈ مثالوں کی قابل اعتماد ضمانتوں کی ضرورت نہیں ہے۔ اسپاٹ پر منتقل ہونے سے اس نوڈ کی قیمت پر 60-90% کی بچت ہوتی ہے۔ کارپینٹر خود بخود پوڈز کو جگہ کی بندش سے نمٹنے کے لیے دوبارہ ترتیب دیتا ہے۔ ریاست کے بغیر کام کے بوجھ کے لیے، بندش صارفین کے لیے پوشیدہ ہے۔
# Good: Spot-only NodePool for staging environments
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: staging-spot
spec:
template:
metadata:
labels:
billing/environment: staging
spec:
taints:
- key: environment
value: staging
effect: NoSchedule # Only pods that tolerate this taint schedule here
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ["spot"] # Spot only for non-production
disruption:
consolidationPolicy: WhenUnderutilized
3.4 کارپینٹر اور سپاٹ کا ROI
| میٹرک نظام | پچھلا (کلسٹر آٹو اسکیلر) | کے بعد (بڑھئی + جگہ) | بہتری |
|---|---|---|---|
| نوڈس کی اوسط تعداد | 28 | 18 | -36% |
| اوسط CPU استعمال | 65% | 82% | +17 فیصد پوائنٹس |
| سٹیجنگ ماحول کے اخراجات | $8,000/ماہ | $2,400/ماہ | -70% |
| نئی پھلیوں کے لیے توسیع کا وقت | 3-5 منٹ | 30~60 سیکنڈ | -80% |
حصہ 4: گریویٹن موومنٹ
AWS Graviton ARM پر مبنی پروسیسرز کا ایمیزون کا اپنا خاندان ہے، جو EC2 مثال کی اقسام میں دستیاب ہے جن کے نام اس پر ختم ہوتے ہیں: g – m7g, c7g, r7gوغیرہ
Graviton مثالوں کی قیمت تقابلی Intel یا AMD x86 مثالوں سے تقریباً 20% کم ہے۔ زیادہ تر سرور سائیڈ ورک بوجھ (Node.js, Python, Go, Java) کے لیے، وہ فی ڈالر 20-40% بہتر کارکردگی بھی فراہم کرتے ہیں کیونکہ پروسیسر کا فن تعمیر اس قسم کے کام کے بوجھ کے لیے موزوں ہے۔
Graviton استعمال کرنے کے لیے اپنا ایپلیکیشن کوڈ تبدیل نہ کریں۔ اپنے کنٹینر امیج بلڈ کے فن تعمیر کے جھنڈے اور اپنی Kubernetes تعیناتی کے نوڈ سلیکٹر کو تبدیل کریں۔
4.1 کیوں Graviton کارکردگی پر سمجھوتہ کیے بغیر پیسے بچاتا ہے۔
منتقلی سے پہلے آپ کو پہلا سوال جس کا جواب دینا ہوگا وہ یہ ہے کہ آیا آپ کے کنٹینر کی تصویر ARM64 کو سپورٹ کرتی ہے۔ Docker Hub پر زیادہ تر سرکاری تصاویر ملٹی آرکیٹیکچر امیجز کے طور پر دستیاب ہیں۔ آپ کو دونوں آرکیٹیکچرز کے لیے واضح طور پر اپنی ایپلیکیشن امیجز بنانا ہوں گی۔
یقینی بنائیں کہ آپ کی تصویر ARM64 کو سپورٹ کرتی ہے۔
# Check if an image has an ARM64 manifest
docker manifest inspect your-registry/your-app:latest | jq '.manifests[].platform'
ملٹی آرکیٹیکچر امیج کے لیے متوقع آؤٹ پٹ:
{"architecture": "amd64", "os": "linux"},
{"architecture": "arm64", "os": "linux", "variant": "v8"}
اگر arm64 اشارہ کرنے پر، آپ کی تصویر تیار ہے۔ بصورت دیگر، آپ کو پہلے ملٹی آرکیٹیکچر امیج بنانے اور آگے بڑھانے کی ضرورت ہوگی۔
ملٹی آرکیٹیکچر امیجز بنائیں اور پش کریں:
# Build for both x86 and ARM in a single command using Docker Buildx
docker buildx create --use --name multi-arch-builder
docker buildx build \
--platform linux/amd64,linux/arm64 \
--tag your-registry/your-app:latest \
--push \
.
4.2 کام کے بوجھ کو Graviton میں منتقل کریں۔
اگر کارپینٹر پہلے سے انسٹال ہے، تو گریویٹن کی منتقلی تعیناتی کے وقت ایک لیبل کی تبدیلی ہے۔ کارپینٹر خود بخود مناسب ARM64 نوڈس فراہم کرتا ہے۔
درست نفاذ یہ ہوگا:
# Good: nodeSelector directs the pod to Graviton nodes
# Karpenter provisions an arm64 node if one isn't already available
apiVersion: apps/v1
kind: Deployment
metadata:
name: payment-api
spec:
template:
spec:
nodeSelector:
kubernetes.io/arch: arm64 # Schedule exclusively on Graviton nodes
containers:
- name: api
image: your-registry/payment-api:latest # Must be multi-arch
بے وطن خدمات سے شروع کرتے ہوئے آہستہ آہستہ ہجرت کریں۔
# Step 1: Migrate one stateless service and monitor for 48 hours
kubectl patch deployment payment-api \
-p '{"spec":{"template":{"spec":{"nodeSelector":{"kubernetes.io/arch":"arm64"}}}}}'
# Step 2: Watch for errors in the first 30 minutes
kubectl logs -l app=payment-api --tail=100 -f
# Step 3: Verify the pod is running on a Graviton node
# The NODE column should show a Graviton instance type (m7g, c7g, r7g)
kubectl get pods -l app=payment-api -o wide
# Step 4: After 48 hours of stable operation, migrate the next service
ایسے حالات ہیں جہاں آپ کو Graviton میں منتقل نہیں ہونا چاہئے، جیسے GPU ورک لوڈ، مقامی x86 بائنری انحصار کے ساتھ ایپلی کیشنز، یا کام کے بوجھ جن کے لیے آپ نے ابھی تک ملٹی آرکیٹیکچر امیج نہیں بنایا ہے۔
4.3 Graviton’s ROI
| کام کے بوجھ کی قسم | x86 ماہانہ لاگت | Graviton ماہانہ لاگت | بچت |
|---|---|---|---|
| ویب سروسز (Node.js، Python) | $18,000 | $14,400 | $3,600/ماہ |
| ڈیٹا پروسیسنگ | $12,000 | $9,600 | $2,400/مہینہ |
| API سروس (گو، جاوا) | $8,000 | $6,400 | $1,600/مہینہ |
| بندوق | $38,000 | $30,400 | $7,600/مہینہ |
حصہ 5: ڈیٹا کی منتقلی کے لیے VPC اینڈ پوائنٹس
5.1 NAT گیٹ وے ٹیکس
وہ تمام بائٹس جو آپ کے EKS پوڈ سے AWS سروسز (S3, DynamoDB, ECR, SQS) تک جاتے ہیں NAT گیٹ وے سے گزرتے ہیں جب تک کہ آپ VPC اینڈ پوائنٹ کنفیگر نہ کریں۔ NAT گیٹ وے پروسیس شدہ ڈیٹا کے فی GB $0.045 چارج کرتا ہے۔
ایک مصروف EKS کلسٹر ECR سے کنٹینر کی تصاویر کھینچتا ہے، S3 پر لکھتا ہے، اور پولنگ SQS قطاریں NAT گیٹ وے کے ذریعے ہر ماہ سینکڑوں ٹیرا بائٹس پر کارروائی کر سکتی ہیں، جس سے ٹریفک کے چارجز میں ہزاروں ڈالر خرچ ہوتے ہیں جنہوں نے AWS نیٹ ورک کو حقیقت میں کبھی نہیں چھوڑا۔
اختتامی پوائنٹس شامل کرنے سے پہلے اپنے موجودہ NAT گیٹ وے کے اخراجات کی پیمائش کریں۔
# Get last month's NAT Gateway data processing charges
aws ce get-cost-and-usage \
--time-period Start=\((date -d 'last month' +%Y-%m-01),End=\)(date +%Y-%m-01) \
--granularity DAILY \
--filter '{
"Dimensions": {
"Key": "USAGE_TYPE",
"Values": ["NATGateway-Bytes"]
}
}' \
--metrics UnblendedCost \
--query 'ResultsByTime[*].{Date:TimePeriod.Start,Cost:Total.UnblendedCost.Amount}' \
--output table
5.2 VPC اینڈ پوائنٹس — 30 منٹ میں حل ہو گئے۔
VPC اینڈ پوائنٹس آپ کے VPC اور AWS سروسز کے درمیان ایک نجی کنکشن بناتے ہیں، NAT گیٹ وے کو چھوئے بغیر AWS بیک بون کے ذریعے ٹریفک کو روٹ کرتے ہیں۔ ڈیٹا ٹرانسفر مفت ہو جاتا ہے۔ ہر اختتامی نقطہ کی قیمت NAT گیٹ وے پروسیسنگ لاگت سے نمایاں طور پر کم ہے جو اس کی جگہ لیتی ہے، جو کہ تقریباً \(0.01/گھنٹہ – تقریباً \)7.20/مہینہ ہے۔
یہاں چار سب سے عام EKS ٹریفک مقامات کے لیے مکمل نفاذ ہیں:
# Get your VPC ID and primary route table ID first
VPC_ID=$(aws eks describe-cluster --name your-cluster \
--query 'cluster.resourcesVpcConfig.vpcId' --output text)
ROUTE_TABLE_ID=$(aws ec2 describe-route-tables \
--filters Name=vpc-id,Values=$VPC_ID Name=association.main,Values=true \
--query 'RouteTables[0].RouteTableId' --output text)
echo "VPC: \(VPC_ID | Route Table: \)ROUTE_TABLE_ID"
# S3 gateway endpoint — free to create, eliminates all S3 traffic through NAT
aws ec2 create-vpc-endpoint \
--vpc-id $VPC_ID \
--service-name com.amazonaws.us-east-1.s3 \
--route-table-ids $ROUTE_TABLE_ID
# DynamoDB gateway endpoint — also free, same mechanism as S3
aws ec2 create-vpc-endpoint \
--vpc-id $VPC_ID \
--service-name com.amazonaws.us-east-1.dynamodb \
--route-table-ids $ROUTE_TABLE_ID
# ECR API interface endpoint — eliminates NAT charges on image pulls
aws ec2 create-vpc-endpoint \
--vpc-id $VPC_ID \
--vpc-endpoint-type Interface \
--service-name com.amazonaws.us-east-1.ecr.api \
--subnet-ids $(aws ec2 describe-subnets \
--filters Name=vpc-id,Values=$VPC_ID Name=tag:Tier,Values=private \
--query 'Subnets[*].SubnetId' --output text)
# ECR Docker endpoint — required alongside ECR API for complete image pull coverage
aws ec2 create-vpc-endpoint \
--vpc-id $VPC_ID \
--vpc-endpoint-type Interface \
--service-name com.amazonaws.us-east-1.ecr.dkr \
--subnet-ids $(aws ec2 describe-subnets \
--filters Name=vpc-id,Values=$VPC_ID Name=tag:Tier,Values=private \
--query 'Subnets[*].SubnetId' --output text)
ٹیرافارم ماڈیول ایک ہی میں چاروں اینڈ پوائنٹس بنانے کے لیے apply یہ اندر ہے۔ terraform/vpc-endpoints/ یہ ساتھی ذخیرہ میں ہے۔
تصدیق کریں کہ اینڈ پوائنٹ ٹریفک کو صحیح طریقے سے روٹ کر رہا ہے۔
aws ec2 describe-vpc-endpoints \
--filters Name=vpc-id,Values=$VPC_ID \
--query 'VpcEndpoints[*].{Service:ServiceName,State:State,Type:VpcEndpointType}' \
--output table
# Expected: all endpoints showing State=available
VPC اختتامی پوائنٹس کا 5.3 ROI
| سروس | پچھلا (NAT کے ذریعے) | کے بعد (VPC اختتامی نقطہ) | ماہانہ بچت |
|---|---|---|---|
| S3 ڈیٹا کی منتقلی | $4,500 | $0 | $4,500 |
| ECR تصاویر درآمد کریں۔ | $800 | $0 | $800 |
| DynamoDB سوالات | $1,200 | $0 | $1,200 |
| اختتامی قیمت | – | $29 (4 اختتامی پوائنٹس) | -$29 |
| خالص بچت | $6,471/مہینہ |
حصہ 6: EBS والیوم آپٹیمائزیشن
6.1 gp2 سے gp3 میں منتقلی
IOPS میں EBS gp2 والیوم کی قیمت اسٹوریج کے سائز کی بنیاد پر رکھی گئی ہے (3 IOPS فی GB، کم از کم 100 IOPS کے ساتھ)۔ EBS gp3 والیوم سائز سے قطع نظر 3,000 IOPS کی بنیادی لائن فراہم کرتے ہیں اور اس کی قیمت فی GB 20% کم ہے۔ نقل مکانی بغیر کسی وقت کے آن لائن کی جاتی ہے۔
تمام gp2 والیوم تلاش کریں اور منتقل کریں۔
# Step 1: List all gp2 volumes and their sizes
aws ec2 describe-volumes \
--filters Name=volume-type,Values=gp2 \
--query 'Volumes[*].{ID:VolumeId,Size:Size,State:State}' \
--output table
# Step 2: Migrate each gp2 volume to gp3 — no instance stop required
# The modify operation runs online while the volume stays attached and in use
aws ec2 describe-volumes \
--filters Name=volume-type,Values=gp2 \
--query 'Volumes[*].VolumeId' \
--output text | tr '\t' '\n' | while read vol; do
echo "Migrating $vol from gp2 to gp3..."
aws ec2 modify-volume \
--volume-id $vol \
--volume-type gp3
done
# Step 3: Verify all volumes are now gp3
aws ec2 describe-volumes \
--filters Name=volume-type,Values=gp2 \
--query 'Volumes[*].VolumeId' \
--output text
# Expected: empty output — zero gp2 volumes remaining
6.2 یتیم جلدوں اور سنیپ شاٹس کو تلاش کرنا اور ہٹانا
جب ایک Kubernetes PertantVolumeClaim کو حذف کر دیا جاتا ہے، تو بعض اوقات بنیادی EBS والیوم کو صاف نہیں کیا جاتا ہے۔ یہ چلتا رہے گا اور بل دیا جائے گا۔
# Find unattached EBS volumes — status=available means not attached to any instance
aws ec2 describe-volumes \
--filters Name=status,Values=available \
--query 'Volumes[*].{ID:VolumeId,Size:Size,Created:CreateTime}' \
--output table
# Find EBS snapshots older than 90 days
aws ec2 describe-snapshots \
--owner-ids self \
--query "Snapshots[?StartTime<='$(date -d '90 days ago' --iso-8601=seconds)'].[SnapshotId,StartTime,VolumeSize]" \
--output table
اسنیپ شاٹ کو حذف کرنے سے پہلے، اپنے RDS خودکار بیک اپ شیڈول کا حوالہ دیں تاکہ یہ یقینی بنایا جا سکے کہ یہ آپ کے پروڈکشن ڈیٹا بیس کا واحد بیک اپ نہیں ہے۔
EBS کی اصلاح کا 6.3 ROI
| مرضی | پہلے | بعد میں | ماہانہ بچت |
|---|---|---|---|
| gp2 → gp3 منتقلی (کل 1TB) | $102 | $72 | $30 |
| غیر منسلک والیوم ہٹا دیے جاتے ہیں (50 × 100 GB) | $500 | $0 | $500 |
| پچھلے سنیپ شاٹس کو صاف کیا گیا (500 GB) | $25 | $0 | $25 |
| بندوق | $627 | $72 | $555/مہینہ |
حصہ 7: لوڈ بیلنس انضمام
مسئلہ 7.1 - ایک لوڈ بیلنس فی سروس
بہت سی ٹیمیں الگ الگ ٹیمیں بناتی ہیں۔ LoadBalancer تمام مائیکرو سروسز کے لیے ایک سروس۔ AWS میں، ہر ایپلیکیشن لوڈ بیلنس کی لاگت تقریباً \(16.20/ماہ کی بنیادی فیس + \)0.008/LCU-گھنٹہ پروسیس شدہ ٹریفک کے لیے ہوتی ہے۔ 20 مائیکرو سروسز پر، ایک درخواست پر کارروائی سے پہلے یہ $324 فی مہینہ ہے۔
غلط طریقہ یہ ہے:
# Bad: This creates a dedicated AWS ALB every time it's applied
# 20 microservices = 20 ALBs = $324+/month before any traffic charges
apiVersion: v1
kind: Service
metadata:
name: payment-api
spec:
type: LoadBalancer # Creates a dedicated ALB
ports:
- port: 80
targetPort: 8080
7.2 حل - مشترکہ داخلی کنٹرولر
Ingress کنٹرولر ایک Kubernetes جزو ہے جو کلسٹر کے اندر ایک Pod کے طور پر چلتا ہے اور میزبان نام اور URL پاتھ کی بنیاد پر متعدد سروسز تک ٹریفک کو روٹ کرنے کے لیے ایک بیرونی لوڈ بیلنس کو پروگرام کرتا ہے۔ ایک AWS ایپلیکیشن لوڈ بیلنسر فی مائیکرو سروس کے بجائے، آپ کو پاتھ پر مبنی روٹنگ کے ساتھ کل ایک ALB ملتا ہے جو ہر درخواست کو درست بیک اینڈ سروس کی طرف لے جاتا ہے۔ نتیجے کے طور پر، آپ کم قیمت پر وہی روٹنگ رویہ حاصل کر سکتے ہیں۔
درست نفاذ یہ ہوگا:
# Good: One Ingress resource routes all external traffic
# The AWS Load Balancer Controller creates one ALB for all services listed here
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: shared-ingress
namespace: production
annotations:
kubernetes.io/ingress.class: alb
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
alb.ingress.kubernetes.io/ssl-redirect: "443"
spec:
rules:
- host: api.company.com
http:
paths:
- path: /payments
pathType: Prefix
backend:
service:
name: payment-service
port:
number: 8080
- path: /users
pathType: Prefix
backend:
service:
name: user-service
port:
number: 8080
- host: dashboard.company.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: dashboard-service
port:
number: 3000
tls:
- hosts:
- api.company.com
- dashboard.company.com
secretName: tls-wildcard-cert
یقینی بنائیں کہ داخلے کا انتظام کیا گیا ہے اور ایک ALB DNS نام تفویض کیا گیا ہے۔
# Watch until the ADDRESS column shows the ALB DNS name (typically 2–3 minutes)
kubectl get ingress shared-ingress -n production -w
لاگت کا فرق:
| نقطہ نظر | لوڈ بیلنسر | ماہانہ لاگت |
|---|---|---|
| لوڈ بیلنس سروس فی مائیکرو سروس (20 سروسز) | 20 ALBs | ~$400/مہینہ |
| واحد وصول کرنے والا کنٹرولر | 1 البی | ~$27/مہینہ |
| ماہانہ بچت | ~$373/مہینہ |
مشترکہ داخلی منشور یہاں پر واقع ہے: k8s/ingress/ یہ ساتھی ذخیرہ میں ہے۔
7 قدموں کی ترتیب کو مکمل کریں۔
| قدم | کارروائی | عمل درآمد کا وقت | تخمینی ماہانہ بچت |
|---|---|---|---|
| 1 | مناسب سائز کے پوڈ ریسورس کی درخواستیں (VPA) | 1 ہفتہ | $15,600 |
| 2 | انضمام کے ذریعے کارپینٹر کی تنصیب | 1 ہفتہ | $8,400 |
| 3 | سٹیجنگ اور ترقی کو اسپاٹ پر منتقل کریں۔ | 1 ہفتہ | $11,200 |
| 4 | ہم آہنگ کام کے بوجھ کو Graviton میں منتقل کریں۔ | 2 ہفتے | $7,600 |
| 5 | S3، ECR، اور DynamoDB کے لیے VPC اینڈ پوائنٹس شامل کریں۔ | 1 دن | $6,471 |
| 6 | gp2 کو gp3 میں منتقل کریں اور یتیم والیوم کو حذف کریں۔ | 1 دن | $555 |
| 7 | مشترکہ داخلے کے ساتھ لوڈ بیلنسرز کو مربوط کریں۔ | 1 دن | $373 |
| بندوق | 3-4 ہفتے | $49,799/مہینہ |
اس شرح پر سالانہ بچت: $597,588. انجینئرنگ کا وقت درکار ہے: ایک انجینئر، فی مرحلہ ایک سپرنٹ۔
EKS لاگت کی اصلاح کے بہترین طریقے
کرنا: کسی بھی دوسری اصلاح سے پہلے اپنی پوڈ ریسورس کی درخواستوں کو مناسب سائز دیں۔ تمام بعد کے اقدامات آپ کی درست درخواست پر منحصر ہوں گے۔
کرنا: کارپینٹر کو استعمال کرتے ہوئے لاگو کریں: consolidationPolicy: WhenUnderutilized. خود بخود اور مسلسل نوڈ کی گنتی کو بہتر بناتا ہے۔
کرنا: اپنے اسٹیجنگ اور ترقیاتی کام کے بوجھ کو اسپاٹ پر منتقل کریں۔ کام کے بوجھ کے لیے جو رکاوٹوں کو برداشت کرتے ہیں، بچتیں 60-90% ہیں۔
کرنا: ہم آہنگ کام کے بوجھ کو Graviton میں منتقل کریں۔ زیادہ تر ویب سروسز اور APIs بغیر کسی کوڈ میں تبدیلی کے چلتے ہیں۔
کرنا: ڈیٹا کی منتقلی کے اخراجات کا جائزہ لینے سے پہلے S3، DynamoDB، اور ECR کے لیے VPC اینڈ پوائنٹس شامل کریں۔
کرنا: gp2 والیوم کو gp3 میں منتقل کریں۔ یہ آن لائن ہے، کوئی ڈاؤن ٹائم نہیں ہے، اور یہ فوری طور پر 20% سستا ہے۔
کرنا: تمام بیرونی ٹریفک کے لیے فی سروس لوڈ بیلنسر کے بجائے ایک مشترکہ انگریس کنٹرولر استعمال کریں۔
مت کرو: 1-6 مراحل کو مکمل کرنے سے پہلے بچت کا منصوبہ خریدیں۔ فضلہ 1 سے 3 سال تک پھنس جائے گا۔
مت کرو: کلسٹر آٹو اسکیلر کے ساتھ جامد نوڈ گروپس کا استعمال کریں کیونکہ آپ کے کام کا بوجھ مکس تبدیل ہوتا ہے۔ کارپینٹر اسے متحرک طور پر ہینڈل کرتا ہے۔
مت کرو: آن ڈیمانڈ مثالوں پر سٹیجنگ اور ڈیولپمنٹ ماحول چلائیں۔ جگہ کی بندش قابل انتظام ہے، لیکن لاگت کا فرق نہیں ہے۔