AWS پر Kubernetes کلاؤڈ اخراجات پر بچت کریں۔

مضمون کا ترجمہ کورس کے آغاز کے موقع پر تیار کیا گیا تھا۔ "کوبرنیٹس پر مبنی انفراسٹرکچر پلیٹ فارم".

Kubernetes کے ساتھ کام کرتے وقت کلاؤڈ اخراجات کو کیسے بچایا جائے؟ کوئی واحد صحیح حل نہیں ہے، لیکن یہ مضمون کئی ٹولز کی وضاحت کرتا ہے جو آپ کو اپنے وسائل کو زیادہ مؤثر طریقے سے منظم کرنے اور آپ کے کلاؤڈ کمپیوٹنگ کے اخراجات کو کم کرنے میں مدد کر سکتے ہیں۔

میں نے یہ مضمون AWS کے لیے Kubernetes کو ذہن میں رکھتے ہوئے لکھا تھا، لیکن اس کا اطلاق (تقریباً) بالکل اسی طرح دوسرے کلاؤڈ فراہم کرنے والوں پر ہوگا۔ میں فرض کر رہا ہوں کہ آپ کے کلسٹر(ز) میں پہلے سے ہی آٹو اسکیلنگ کنفیگر ہو چکی ہے (کلسٹر آٹو اسکیلر)۔ وسائل کو ہٹانے اور اپنی تعیناتی کو کم کرنے سے آپ کے پیسے صرف اس صورت میں بچیں گے جب یہ آپ کے کارکن نوڈس (EC2 مثالوں) کے بیڑے کو بھی کم کر دے گا۔

یہ مضمون احاطہ کرے گا:

• غیر استعمال شدہ وسائل کی صفائی (کوبی چوکیدار)
• غیر کام کے اوقات میں اسکیلنگ کو کم کریں (kube-downscaler)
• افقی آٹو اسکیلنگ (HPA) کا استعمال کرتے ہوئے،
• ضرورت سے زیادہ وسائل کے ریزرویشن میں کمی (kube-resource-report, VPA)
• سپاٹ مثالوں کا استعمال کرتے ہوئے

غیر استعمال شدہ وسائل کو صاف کرنا

تیز رفتار ماحول میں کام کرنا بہت اچھا ہے۔ ہم ٹیک تنظیمیں چاہتے ہیں۔ تیز. تیز تر سافٹ ویئر ڈیلیوری کا مطلب مزید PR تعیناتیاں، پیش نظارہ ماحول، پروٹو ٹائپس، اور تجزیاتی حل بھی ہیں۔ سب کچھ Kubernetes پر تعینات ہے۔ ٹیسٹ کی تعیناتیوں کو دستی طور پر صاف کرنے کا وقت کس کے پاس ہے؟ ایک ہفتہ پرانے تجربے کو حذف کرنے کے بارے میں بھول جانا آسان ہے۔ بادل کا بل کسی ایسی چیز کی وجہ سے بڑھ جائے گا جسے ہم بند کرنا بھول گئے تھے:

(ہیننگ جیکبز:
زیزا:
کوری کوئن:
افسانہ: آپ کا AWS اکاؤنٹ آپ کے صارفین کی تعداد کا ایک فنکشن ہے۔
حقیقت: آپ کا AWS سکور آپ کے انجینئرز کی تعداد کا ایک فنکشن ہے۔

ایوان کرنوسوف (جواب میں):
اصل حقیقت: آپ کا AWS سکور ان چیزوں کی تعداد کا ایک فنکشن ہے جنہیں آپ غیر فعال/حذف کرنا بھول گئے ہیں۔)

کبرنیٹس چوکیدار (kube-janitor) آپ کے کلسٹر کو صاف کرنے میں مدد کرتا ہے۔ چوکیدار کی ترتیب عالمی اور مقامی دونوں استعمال کے لیے لچکدار ہے:

• کلسٹر وسیع قواعد PR/ٹیسٹ تعیناتیوں کے لیے زیادہ سے زیادہ ٹائم ٹو لائیو (TTL) کی وضاحت کر سکتے ہیں۔
• انفرادی وسائل کو janitor/ttl کے ساتھ تشریح کیا جا سکتا ہے، مثال کے طور پر 7 دنوں کے بعد خود بخود اسپائک/پروٹو ٹائپ کو ہٹانا۔

عام اصول YAML فائل میں بیان کیے گئے ہیں۔ اس کا راستہ پیرامیٹر سے گزرتا ہے۔ --rules-file کوبی چوکیدار میں یہاں تمام نام کی جگہوں کو ہٹانے کے لیے ایک مثال کا اصول ہے۔ -pr- دو دن کے بعد نام پر:

- id: cleanup-resources-from-pull-requests
  resources:
    - namespaces
  jmespath: "contains(metadata.name, '-pr-')"
  ttl: 2d

مندرجہ ذیل مثال 2020 میں تمام نئی تعیناتیوں/StatefulSets کے لیے تعیناتی اور StatefulSet پوڈز پر ایپلیکیشن لیبل کے استعمال کو منظم کرتی ہے، لیکن ساتھ ہی ایک ہفتے تک اس لیبل کے بغیر ٹیسٹوں پر عمل درآمد کی اجازت دیتی ہے۔

- id: require-application-label
  # удалить deployments и statefulsets без метки "application"
  resources:
    - deployments
    - statefulsets
  # см. http://jmespath.org/specification.html
  jmespath: "!(spec.template.metadata.labels.application) && metadata.creationTimestamp > '2020-01-01'"
  ttl: 7d

کلسٹر پر 30 منٹ تک محدود وقت کے لیے ڈیمو چلائیں:

kubectl run nginx-demo --image=nginx
kubectl annotate deploy nginx-demo janitor/ttl=30m

بڑھتی ہوئی لاگت کا ایک اور ذریعہ مستقل حجم (AWS EBS) ہے۔ Kubernetes StatefulSet کو حذف کرنے سے اس کے مستقل حجم (PVC - PersistentVolumeClaim) حذف نہیں ہوتے ہیں۔ غیر استعمال شدہ EBS والیوم آسانی سے سینکڑوں ڈالر فی مہینہ کے اخراجات کا باعث بن سکتے ہیں۔ Kubernetes Janitor میں غیر استعمال شدہ PVCs کو صاف کرنے کی خصوصیت ہے۔ مثال کے طور پر، یہ قاعدہ تمام PVCs کو ہٹا دے گا جو ماڈیول کے ذریعہ نہیں لگائے گئے ہیں اور جن کا حوالہ StatefulSet یا CronJob کے ذریعہ نہیں ہے:

# удалить все PVC, которые не смонтированы и на которые не ссылаются StatefulSets
- id: remove-unused-pvcs
  resources:
  - persistentvolumeclaims
  jmespath: "_context.pvc_is_not_mounted && _context.pvc_is_not_referenced"
  ttl: 24h

Kubernetes Janitor آپ کو اپنے کلسٹر کو صاف رکھنے اور کلاؤڈ کمپیوٹنگ کے اخراجات کو آہستہ آہستہ جمع ہونے سے روکنے میں مدد کر سکتا ہے۔ تعیناتی اور ترتیب کی ہدایات کے لیے، پیروی کریں۔ README kube- چوکیدار.

غیر کام کے اوقات میں اسکیلنگ کو کم کریں۔

ٹیسٹ اور سٹیجنگ سسٹم عام طور پر صرف کاروباری اوقات کے دوران کام کرنے کے لیے درکار ہوتے ہیں۔ کچھ پروڈکشن ایپلی کیشنز، جیسے بیک آفس/ایڈمن ٹولز، کو بھی صرف محدود دستیابی کی ضرورت ہوتی ہے اور راتوں رات غیر فعال ہو سکتے ہیں۔

Kubernetes ڈاؤن اسکیلر (kube-downscaler) صارفین اور آپریٹرز کو غیر کام کے اوقات کے دوران سسٹم کو کم کرنے کی اجازت دیتا ہے۔ تعیناتیاں اور اسٹیٹفول سیٹ صفر نقل تک پیمانہ کر سکتے ہیں۔ کرون جابس کو معطل کیا جا سکتا ہے۔ Kubernetes Downscaler کو پورے کلسٹر، ایک یا زیادہ نام کی جگہوں، یا انفرادی وسائل کے لیے ترتیب دیا گیا ہے۔ آپ یا تو "بیکار وقت" یا اس کے برعکس "کام کا وقت" سیٹ کر سکتے ہیں۔ مثال کے طور پر، راتوں اور ویک اینڈ کے دوران اسکیلنگ کو جتنا ممکن ہو کم کرنا:

image: hjacobs/kube-downscaler:20.4.3
args:
  - --interval=30
  # не отключать компоненты инфраструктуры
  - --exclude-namespaces=kube-system,infra
  # не отключать kube-downscaler, а также оставить Postgres Operator, чтобы исключенными БД можно было управлять
  - --exclude-deployments=kube-downscaler,postgres-operator
  - --default-uptime=Mon-Fri 08:00-20:00 Europe/Berlin
  - --include-resources=deployments,statefulsets,stacks,cronjobs
  - --deployment-time-annotation=deployment-time

اختتام ہفتہ پر کلسٹر ورکر نوڈس کو اسکیلنگ کرنے کا گراف یہ ہے:

~13 سے 4 ورکر نوڈس کو کم کرنے سے یقینی طور پر آپ کے AWS بل میں نمایاں فرق پڑتا ہے۔

لیکن اگر مجھے کلسٹر "ڈاؤن ٹائم" کے دوران کام کرنے کی ضرورت ہو؟ کچھ تعیناتیوں کو downscaler/exclude: true annotation شامل کرکے اسکیلنگ سے مستقل طور پر خارج کیا جاسکتا ہے۔ YYYY-MM-DD HH:MM (UTC) فارمیٹ میں مطلق ٹائم اسٹیمپ کے ساتھ Downscaler/exclude-entil تشریح کا استعمال کرتے ہوئے تعیناتیوں کو عارضی طور پر خارج کیا جا سکتا ہے۔ اگر ضروری ہو تو، تشریح کے ساتھ پوڈ لگا کر پورے کلسٹر کو پیچھے سے چھوٹا کیا جا سکتا ہے۔ downscaler/force-uptime، مثال کے طور پر، nginx خالی لانچ کرکے:

kubectl run scale-up --image=nginx
kubectl annotate deploy scale-up janitor/ttl=1h # удалить развертывание через час
kubectl annotate pod $(kubectl get pod -l run=scale-up -o jsonpath="{.items[0].metadata.name}") downscaler/force-uptime=true

ملاحظہ کریں README kube-downscaler، اگر آپ تعیناتی کی ہدایات اور اضافی اختیارات میں دلچسپی رکھتے ہیں۔

افقی آٹو اسکیلنگ کا استعمال کریں۔

بہت سی ایپلیکیشنز/سروسز ایک متحرک لوڈنگ پیٹرن سے نمٹتی ہیں: بعض اوقات ان کے ماڈیولز بیکار ہوتے ہیں، اور بعض اوقات وہ پوری صلاحیت سے کام کرتے ہیں۔ زیادہ سے زیادہ چوٹی کے بوجھ سے نمٹنے کے لیے پھلیوں کے مستقل بیڑے کو چلانا اقتصادی نہیں ہے۔ Kubernetes ایک وسائل میں افقی آٹو اسکیلنگ کو سپورٹ کرتا ہے۔ HorizontalPodAutoscaler (HPA)۔ سی پی یو کا استعمال اکثر اسکیلنگ کے لیے ایک اچھا اشارہ ہوتا ہے:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        averageUtilization: 100
        type: Utilization

Zalando نے اسکیلنگ کے لیے حسب ضرورت میٹرکس کو آسانی سے مربوط کرنے کے لیے ایک جزو بنایا ہے: کیوب میٹرکس اڈاپٹر (kube-metrics-adapter) Kubernetes کے لیے ایک عام میٹرکس اڈاپٹر ہے جو پوڈز کی افقی آٹو اسکیلنگ کے لیے اپنی مرضی کے مطابق اور بیرونی میٹرکس کو جمع اور پیش کر سکتا ہے۔ یہ Prometheus میٹرکس، SQS قطاروں، اور دیگر ترتیبات کی بنیاد پر اسکیلنگ کو سپورٹ کرتا ہے۔ مثال کے طور پر، اپنی تعیناتی کو ایک حسب ضرورت میٹرک تک پیمانہ کرنے کے لیے جس کی نمائندگی خود ایپلیکیشن JSON کے بطور /metrics استعمال کرتی ہے:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
  annotations:
    # metric-config.<metricType>.<metricName>.<collectorName>/<configKey>
    metric-config.pods.requests-per-second.json-path/json-key: "$.http_server.rps"
    metric-config.pods.requests-per-second.json-path/path: /metrics
    metric-config.pods.requests-per-second.json-path/port: "9090"
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: requests-per-second
      target:
        averageValue: 1k
        type: AverageValue

غیر ریاستی خدمات کی کارکردگی کو بہتر بنانے کے لیے HPA کے ساتھ افقی آٹو اسکیلنگ کو ترتیب دینا پہلے سے طے شدہ اقدامات میں سے ایک ہونا چاہیے۔ Spotify کے پاس ان کے تجربے اور HPA کے لیے سفارشات کے ساتھ ایک پریزنٹیشن ہے: اپنی تعیناتیوں کی پیمائش کریں، اپنے بٹوے کو نہیں۔.

وسائل کی اوور بکنگ کو کم کریں۔

Kubernetes کام کا بوجھ اپنی CPU/میموری کی ضروریات کا تعین "وسائل کی درخواستوں" کے ذریعے کرتے ہیں۔ CPU وسائل کو ورچوئل کور میں یا زیادہ عام طور پر "ملی کورز" میں ماپا جاتا ہے، مثال کے طور پر 500m کا مطلب 50% vCPU ہے۔ میموری کے وسائل کو بائٹس میں ماپا جاتا ہے، اور عام لاحقے استعمال کیے جا سکتے ہیں، جیسے 500Mi، جس کا مطلب ہے 500 میگا بائٹس۔ ریسورس کی درخواستیں ورکر نوڈس پر "لاک" کی گنجائش رکھتی ہیں، یعنی 1000 vCPUs والے نوڈ پر 4m CPU کی درخواست کے ساتھ ایک پوڈ دوسرے پوڈز کے لیے صرف 3 vCPUs دستیاب رہ جائے گا۔ ہے [1]

سست (اضافی ریزرو) درخواست کردہ وسائل اور حقیقی استعمال کے درمیان فرق ہے۔ مثال کے طور پر، ایک پوڈ جو 2 GiB میموری کی درخواست کرتا ہے لیکن صرف 200 MiB استعمال کرتا ہے اس میں ~ 1,8 GiB "اضافی" میموری ہے۔ ضرورت سے زیادہ رقم خرچ ہوتی ہے۔ کوئی اندازہ لگا سکتا ہے کہ 1 GiB بے کار میموری کی قیمت ~$10 فی مہینہ ہے۔ ہے [2]

Kubernetes وسائل کی رپورٹ (kube-resource-report) اضافی ذخائر دکھاتا ہے اور بچت کی صلاحیت کا تعین کرنے میں آپ کی مدد کر سکتا ہے:

Kubernetes وسائل کی رپورٹ ایپلی کیشن اور کمانڈ کے ذریعہ جمع کردہ اضافی کو ظاہر کرتا ہے۔ یہ آپ کو ایسی جگہیں تلاش کرنے کی اجازت دیتا ہے جہاں وسائل کی طلب کو کم کیا جا سکتا ہے۔ تیار کردہ HTML رپورٹ صرف وسائل کے استعمال کا سنیپ شاٹ فراہم کرتی ہے۔ مناسب وسائل کی درخواستوں کا تعین کرنے کے لیے آپ کو وقت کے ساتھ CPU/میموری کے استعمال کو دیکھنا چاہیے۔ یہاں ایک "عام" CPU- ہیوی سروس کے لیے گرافانا چارٹ ہے: تمام پوڈز 3 درخواست کردہ CPU کور سے نمایاں طور پر کم استعمال کر رہے ہیں:

CPU کی درخواست کو 3000m سے ~400m تک کم کرنا دوسرے کام کے بوجھ کے لیے وسائل کو آزاد کرتا ہے اور کلسٹر کو چھوٹا ہونے دیتا ہے۔

"EC2 مثالوں کا اوسط CPU استعمال اکثر واحد ہندسوں کی فیصد کی حد میں منڈلاتا ہے،" کوری کوئن لکھتے ہیں۔. جبکہ EC2 کے لیے صحیح سائز کا اندازہ لگانا برا فیصلہ ہو سکتا ہے۔YAML فائل میں کچھ Kubernetes وسائل کے سوالات کو تبدیل کرنا آسان ہے اور بہت زیادہ بچت لا سکتا ہے۔

لیکن کیا ہم واقعی چاہتے ہیں کہ لوگ YAML فائلوں میں اقدار کو تبدیل کریں؟ نہیں، مشینیں یہ بہت بہتر کر سکتی ہیں! کوبرنیٹس عمودی پوڈ آٹو اسکیلر (VPA) صرف وہی کرتا ہے: وسائل کی درخواستوں اور رکاوٹوں کو کام کے بوجھ کے مطابق ڈھالتا ہے۔ پرومیتھیس سی پی یو کی درخواستوں (پتلی نیلی لکیر) کا ایک مثال گراف ہے جسے وقت کے ساتھ VPA نے ڈھال لیا ہے۔

Zalando اپنے تمام کلسٹرز میں VPA استعمال کرتا ہے۔ بنیادی ڈھانچے کے اجزاء کے لیے۔ غیر اہم ایپلیکیشنز بھی VPA استعمال کر سکتی ہیں۔

گولڈیلاکس Fairwind سے ایک ایسا ٹول ہے جو نام کی جگہ میں ہر تعیناتی کے لیے VPA بناتا ہے اور پھر اپنے ڈیش بورڈ پر VPA کی سفارش دکھاتا ہے۔ یہ ڈویلپرز کو اپنی ایپلی کیشنز کے لیے درست CPU/میموری کی درخواستیں سیٹ کرنے میں مدد کر سکتا ہے۔

میں نے ایک چھوٹا سا لکھا VPA کے بارے میں بلاگ پوسٹ 2019 میں، اور حال ہی میں CNCF اینڈ یوزر کمیونٹی نے VPA مسئلہ پر تبادلہ خیال کیا۔.

EC2 اسپاٹ مثالوں کا استعمال

آخری لیکن کم از کم، AWS EC2 کے اخراجات کو Spot مثالوں کو Kubernetes ورکر نوڈس کے طور پر استعمال کرکے کم کیا جا سکتا ہے۔ ہے [3]. اسپاٹ مثالیں آن ڈیمانڈ قیمتوں کے مقابلے میں 90% تک کی رعایت پر دستیاب ہیں۔ EC2 Spot پر Kubernetes کو چلانا ایک اچھا مجموعہ ہے: آپ کو زیادہ دستیابی کے لیے کئی مختلف مثالوں کی قسمیں بتانے کی ضرورت ہے، یعنی آپ ایک ہی یا کم قیمت پر ایک بڑا نوڈ حاصل کر سکتے ہیں، اور بڑھتی ہوئی صلاحیت کو کنٹینرائزڈ Kubernetes ورک بوجھ کے ذریعے استعمال کیا جا سکتا ہے۔

EC2 اسپاٹ پر کبرنیٹس کو کیسے چلائیں؟ بہت سے اختیارات ہیں: تیسری پارٹی کی سروس استعمال کریں جیسے SpotInst (اب "Spot" کہا جاتا ہے، مجھ سے کیوں نہ پوچھیں)، یا صرف اپنے کلسٹر میں Spot AutoScalingGroup (ASG) شامل کریں۔ مثال کے طور پر، یہاں ایک CloudFormation کا ٹکڑا ہے "capcity-optimized" Spot ASG کے لیے متعدد مثال کی اقسام کے ساتھ:

MySpotAutoScalingGroup:
 Properties:
   HealthCheckGracePeriod: 300
   HealthCheckType: EC2
   MixedInstancesPolicy:
     InstancesDistribution:
       OnDemandPercentageAboveBaseCapacity: 0
       SpotAllocationStrategy: capacity-optimized
     LaunchTemplate:
       LaunchTemplateSpecification:
         LaunchTemplateId: !Ref LaunchTemplate
         Version: !GetAtt LaunchTemplate.LatestVersionNumber
       Overrides:
         - InstanceType: "m4.2xlarge"
         - InstanceType: "m4.4xlarge"
         - InstanceType: "m5.2xlarge"
         - InstanceType: "m5.4xlarge"
         - InstanceType: "r4.2xlarge"
         - InstanceType: "r4.4xlarge"
   LaunchTemplate:
     LaunchTemplateId: !Ref LaunchTemplate
     Version: !GetAtt LaunchTemplate.LatestVersionNumber
   MinSize: 0
   MaxSize: 100
   Tags:
   - Key: k8s.io/cluster-autoscaler/node-template/label/aws.amazon.com/spot
     PropagateAtLaunch: true
     Value: "true"

کبرنیٹس کے ساتھ اسپاٹ کے استعمال پر کچھ نوٹ:

• آپ کو اسپاٹ ٹرمینیشنز کو ہینڈل کرنے کی ضرورت ہے، مثال کے طور پر جب مثال کو روک دیا جاتا ہے تو نوڈ کو ضم کرکے
• Zalando استعمال کرتا ہے کانٹا نوڈ پول ترجیحات کے ساتھ سرکاری کلسٹر آٹو اسکیلنگ
• اسپاٹ نوڈس مجبور کیا جا سکتا ہے اسپاٹ میں چلانے کے لیے کام کے بوجھ کی "رجسٹریشنز" کو قبول کریں۔

خلاصہ

مجھے امید ہے کہ آپ کو اپنے کلاؤڈ بل کو کم کرنے میں پیش کردہ کچھ ٹولز کارآمد معلوم ہوں گے۔ آپ اس پر بھی مضمون کے زیادہ تر مشمولات تلاش کر سکتے ہیں۔ یوٹیوب پر اور سلائیڈز میں DevOps اجتماع 2019 میں میری گفتگو.

Kubernetes پر کلاؤڈ اخراجات کو بچانے کے لیے آپ کے بہترین طریقے کیا ہیں؟ براہ کرم مجھے بتائیں ٹویٹر (@try_except_).

ہے [1] درحقیقت، 3 سے کم vCPUs قابل استعمال رہیں گے کیونکہ نوڈ کا تھرو پٹ محفوظ نظام کے وسائل سے کم ہو جاتا ہے۔ Kubernetes جسمانی نوڈ کی صلاحیت اور "فراہم شدہ" وسائل کے درمیان فرق کرتا ہے (نوڈ ایلوکیٹ ایبل).

ہے [2] حساب کی مثال: 5 GiB میموری کے ساتھ ایک m8.large مثال ~$84 ​​فی مہینہ ہے (eu-central-1، آن ڈیمانڈ)، یعنی 1/8 نوڈ کو مسدود کرنا تقریباً ~$10/مہینہ ہے۔

ہے [3] آپ کے EC2 بل کو کم کرنے کے اور بھی بہت سے طریقے ہیں، جیسے کہ ریزروڈ انسٹینسز، سیونگز پلان وغیرہ۔

کورس کے بارے میں مزید جانیں۔

ماخذ: www.habr.com