🥇 AWS تي Kubernetes ڪلائوڊ خرچن تي بچت

مضمون جو ترجمو ڪورس جي شروعات جي موقعي تي تيار ڪيو ويو "بنيادي پليٽ فارم Kubernetes تي ٻڌل".

ڪبرنيٽس سان ڪم ڪرڻ وقت ڪلائوڊ خرچن تي ڪيئن بچت ڪجي؟ هتي ڪو به واحد صحيح حل ناهي، پر هي آرٽيڪل ڪيترن ئي اوزارن کي بيان ڪري ٿو جيڪي توهان جي وسيلن کي وڌيڪ مؤثر طريقي سان منظم ڪرڻ ۽ توهان جي ڪلائوڊ ڪمپيوٽنگ جي قيمتن کي گهٽائڻ ۾ مدد ڪري سگھن ٿا.

مون هي مضمون لکيو آهي ڪبرنيٽس سان AWS لاءِ ذهن ۾، پر اهو لاڳو ٿيندو (تقريبا) بلڪل ساڳي طرح ٻين ڪلائوڊ فراهم ڪندڙن تي. مان سمجهان ٿو ته توهان جا ڪلسٽر اڳ ۾ ئي آٽو اسڪيلنگ ترتيب ڏنل آهن (ڪلسٽر-آٽو اسڪيلر). وسيلن کي ختم ڪرڻ ۽ توهان جي تعیناتي کي اسڪيل ڪرڻ صرف توهان کي پئسا بچائيندو جيڪڏهن اهو توهان جي ڪم ڪندڙ نوڊس جي بيبي کي گھٽائي ٿو (EC2 مثالن).

هي آرٽيڪل ڍڪيندو:

غير استعمال ٿيل وسيلن کي صاف ڪرڻ (ڪعبي جي سنڀاليندڙ)
غير ڪم ڪندڙ ڪلاڪن دوران اسڪيلنگ کي گھٽايو (kube-downscaler)
افقي خودڪار اسڪيلنگ (HPA) استعمال ڪندي،
اضافي وسيلن جي رزرويشن جي گھٽتائي (kube-resource-report, VPA)
اسپاٽ مثال استعمال ڪندي

غير استعمال ٿيل وسيلن کي صاف ڪرڻ

تيز رفتار ماحول ۾ ڪم ڪرڻ وڏو آهي. اسان ٽيڪنالاجي تنظيمون چاهيون ٿا تيز. تيز سافٽ ويئر پهچائڻ جو مطلب پڻ وڌيڪ پي آر ڊيٽنگون، پريويو ماحول، پروٽوٽائپس، ۽ تجزياتي حل. هر شي ڪبرنيٽس تي ترتيب ڏني وئي آهي. ڪنهن وٽ وقت آهي دستي طور تي ٽيسٽ جي ترتيبن کي صاف ڪرڻ؟ اهو هڪ هفتي پراڻي تجربو کي ختم ڪرڻ جي باري ۾ وسارڻ آسان آهي. بادل بل ختم ٿي ويندو ڪجهه سببن جي ڪري جنهن کي اسان بند ڪرڻ وساري ويٺا آهيون:

(هيننگ جيڪبس:
زيزا:
(اقتباس) ڪوري ڪوئن:
افسانه: توهان جو AWS اڪائونٽ توهان جي استعمال ڪندڙن جي تعداد جو هڪ فنڪشن آهي.
حقيقت: توهان جو AWS سکور توهان جي انجنيئرن جي تعداد جو هڪ فنڪشن آهي.

Ivan Kurnosov (جواب ۾):
حقيقي حقيقت: توهان جو AWS سکور انهن شين جي تعداد جو هڪ فنڪشن آهي جيڪو توهان وسري ويو غير فعال / حذف ڪرڻ.)

ڪبرنيٽس جانيٽر (kube-janitor) توهان جي ڪلستر کي صاف ڪرڻ ۾ مدد ڪري ٿي. جينيٽر جي جوڙجڪ ٻنهي عالمي ۽ مقامي استعمال لاء لچڪدار آهي:

ڪلستر-وائڊ ضابطا بيان ڪري سگھن ٿا وڌ ۾ وڌ وقت-کي-جي-رهڻ (TTL) PR/ٽيسٽ جي مقرري لاءِ.
انفرادي وسيلن کي 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- دربان.

غير ڪم ڪندڙ ڪلاڪن دوران اسڪيلنگ کي گھٽايو

ٽيسٽ ۽ اسٽيجنگ سسٽم کي عام طور تي صرف ڪاروباري ڪلاڪن دوران هلائڻ جي ضرورت آهي. ڪجھ پيداوار ايپليڪيشنون، جيئن ته واپس آفيس / منتظم اوزار، پڻ صرف محدود دستيابي جي ضرورت هوندي آهي ۽ رات جو معذور ٿي سگھي ٿو.

ڪبرنيٽس ڊائون اسڪيلر (kube-downscaler) صارفين ۽ آپريٽرن کي غير ڪم ڪندڙ ڪلاڪن دوران سسٽم کي گھٽائڻ جي اجازت ڏئي ٿو. ڊيپلائيمينٽس ۽ اسٽيٽفيل سيٽ صفر ريپليڪس تائين ماپ ڪري سگھن ٿا. CronJobs معطل ٿي سگھي ٿو. 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. ڊيپلائيمينٽن کي عارضي طور تي خارج ڪري سگھجي ٿو downscaler/exclude- تان جو تشريح مڪمل ٽائم اسٽيمپ سان فارميٽ ۾ YYYY-MM-DD HH:MM (UTC). جيڪڏهن ضروري هجي ته، سڄي ڪلستر کي واپس اسڪيل ڪري سگهجي ٿو هڪ پوڊ کي تشريح سان ترتيب ڏيڻ سان downscaler/force-uptime، مثال طور، شروع ڪندي nginx blank:

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, جيڪڏھن توھان دلچسپي وٺندا آھيو لڳائڻ جي هدايتن ۽ اضافي اختيارن ۾.

افقي خودڪار اسڪيلنگ استعمال ڪريو

ڪيتريون ئي ايپليڪيشنون/خدمتون هڪ متحرڪ لوڊشيڊنگ جي نموني سان ڊيل ڪن ٿيون: ڪڏهن ڪڏهن انهن جا ماڊل بيڪار هوندا آهن، ۽ ڪڏهن ڪڏهن اهي پوري صلاحيت تي ڪم ڪندا آهن. وڌ ۾ وڌ چوٽي جي لوڊ کي منهن ڏيڻ لاءِ پوڊ جو مستقل جهاز هلائڻ اقتصادي نه آهي. ڪبرنيٽس هڪ وسيلن ۾ افقي خودڪار اسڪيلنگ کي سپورٽ ڪري ٿو 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 لاءِ هڪ عام ميٽرڪس اڊاپٽر آهي جيڪو پوڊس جي افقي خودڪار اسڪيلنگ لاءِ ڪسٽم ۽ خارجي ميٽرڪس گڏ ڪري ۽ خدمت ڪري سگهي ٿو. اهو پروميٿيوس ميٽرڪس، SQS قطار، ۽ ٻين سيٽنگن جي بنياد تي اسڪيلنگ کي سپورٽ ڪري ٿو. مثال طور، توهان جي ڊيپلائيمينٽ کي ماپڻ لاءِ ڪسٽم ميٽرڪ جي نمائندگي ڪري ٿو ايپليڪيشن پاران پاڻ JSON جي طور تي /ميٽرڪ استعمال ۾:

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: توهان جي تعیناتي کي ماپ ڪريو، نه توهان جي والٽ.

وسيلن جي اوور بکنگ کي گھٽايو

ڪبرنيٽس ڪم لوڊ انهن جي سي پي يو / ياداشت جي ضرورتن کي "وسيع درخواستن" ذريعي طئي ڪري ٿو. سي پي يو وسيلا ورچوئل ڪور ۾ ماپيا ويندا آهن يا وڌيڪ عام طور تي ”ملي ڪورز“ ۾، مثال طور 500m مطلب 50% vCPU. ياداشت جا ذريعا بائيٽ ۾ ماپيا ويندا آهن، ۽ عام لاڳاپا استعمال ڪري سگھجن ٿا، جهڙوڪ 500Mi، جنهن جو مطلب آهي 500 ميگا بائيٽ. ڪم ڪندڙ نوڊس تي وسيلن جي درخواست ”لاڪ“ جي گنجائش، مطلب ته هڪ پوڊ 1000m سي پي يو جي درخواست سان نوڊ تي 4 وي سي پي يوز سان گڏ صرف 3 وي سي پي يو باقي پوڊز لاءِ دستياب هوندا. [1]

سست (اضافي رزرو) درخواست ڪيل وسيلن ۽ حقيقي استعمال جي وچ ۾ فرق آهي. مثال طور، هڪ پوڊ جيڪو 2 GiB ميموري جي درخواست ڪري ٿو پر صرف 200 MiB استعمال ڪري ٿو ~ 1,8 GiB "اضافي" ياداشت. اضافي خرچ پئسا. ڪو اندازو لڳائي سگھي ٿو ته 1 GiB بيڪار ياداشت جي قيمت ~ $10 هر مهيني. [2]

Kubernetes وسيلن جي رپورٽ (kube-resource-report) اضافي ذخيرا ڏيکاري ٿو ۽ بچت جي صلاحيت کي طئي ڪرڻ ۾ توهان جي مدد ڪري سگهي ٿي:

Kubernetes وسيلن جي رپورٽ ظاھر ڪري ٿو اضافي مجموعو ايپليڪيشن ۽ حڪم سان. هي توهان کي انهن هنڌن کي ڳولڻ جي اجازت ڏئي ٿو جتي وسيلن جي گهرج کي گهٽائي سگهجي ٿي. ٺاهيل HTML رپورٽ صرف وسيلن جي استعمال جو هڪ سنيپ شاٽ مهيا ڪري ٿي. توھان کي ڏسڻ گھرجي سي پي يو / ياداشت جي استعمال کي وقت سان گڏ مناسب وسيلن جي درخواستن جو تعين ڪرڻ لاءِ. هتي هڪ گرافانا چارٽ آهي "عام" سي پي يو-هاري سروس لاءِ: سڀئي پوڊ استعمال ڪري رهيا آهن خاص طور تي 3 درخواست ڪيل سي پي يو ڪور کان گهٽ:

3000m کان ~ 400m تائين CPU جي درخواست کي گھٽائڻ ٻين ڪم لوڊ لاءِ وسيلا آزاد ڪري ٿو ۽ ڪلستر کي ننڍو ٿيڻ جي اجازت ڏئي ٿو.

"اي سي 2 مثالن جو سراسري سي پي يو استعمال اڪثر ڪري ھڪڙي عددي فيصد جي حد ۾ ھورندو آھي،" لکي ٿو Corey Quinn. جڏهن ته EC2 لاء صحيح سائيز جو اندازو لڳائڻ هڪ خراب فيصلو ٿي سگهي ٿوYAML فائل ۾ ڪجھ Kubernetes وسيلن جي سوالن کي تبديل ڪرڻ آسان آھي ۽ وڏي بچت آڻي سگھي ٿو.

پر ڇا اسان واقعي چاهيون ٿا ته ماڻهو YAML فائلن ۾ قدر تبديل ڪن؟ نه، مشينون اهو گهڻو بهتر ڪري سگهن ٿيون! ڪبرنيٽس عمودي پوڊ آٽو اسڪيلر (VPA) صرف اهو ڪري ٿو: ڪم جي لوڊ جي مطابق وسيلن جي درخواستن ۽ رڪاوٽن کي ترتيب ڏئي ٿو. هتي Prometheus CPU درخواستن جو هڪ مثال گراف آهي (ٿلهي نيري لائن) وقت سان گڏ VPA پاران ترتيب ڏنل:

Zalando ان جي سڀني ڪلستر ۾ VPA استعمال ڪري ٿو بنيادي ڍانچي جي اجزاء لاء. غير نازڪ ايپليڪيشنون پڻ استعمال ڪري سگھن ٿيون VPA.

سونو وڪڻ Fairwind کان هڪ اوزار آهي جيڪو هر هڪ مقرري لاءِ هڪ وي پي اي ٺاهي ٿو نالي جي جڳهه ۾ ۽ پوءِ ڏيکاري ٿو هڪ وي پي اي سفارش ان جي ڊيش بورڊ تي. اهو ڊولپرز کي انهن جي ايپليڪيشنن لاءِ صحيح سي پي يو / ياداشت جي درخواستن کي ترتيب ڏيڻ ۾ مدد ڪري سگهي ٿو:

مون هڪ ننڍڙو لکيو VPA بابت بلاگ پوسٽ 2019 ۾، ۽ تازو ۾ CNCF آخري صارف ڪميونٽي VPA مسئلي تي بحث ڪيو.

EC2 اسپاٽ مثالن کي استعمال ڪندي

آخري نه پر گهٽ ۾ گهٽ، AWS EC2 قيمتون گھٽائي سگھجن ٿيون اسپاٽ مثال استعمال ڪندي ڪبرنيٽس ورڪر نوڊس جي طور تي [3]. آن ڊيمانڊ قيمتن جي مقابلي ۾ اسپاٽ مثال 90٪ رعايت تي دستياب آهن. EC2 اسپاٽ تي ڪبرنيٽس کي هلائڻ هڪ سٺو ميلاپ آهي: توهان کي وڌيڪ دستيابي لاءِ ڪيترن ئي مختلف مثالن جي قسمن کي بيان ڪرڻ جي ضرورت آهي، مطلب ته توهان ساڳئي يا گهٽ قيمت لاءِ وڏو نوڊ حاصل ڪري سگهو ٿا، ۽ وڌايل گنجائش ڪنٽينر ٿيل ڪبرنيٽس ڪم لوڊ ذريعي استعمال ڪري سگهجي ٿي.

EC2 اسپاٽ تي ڪبرنيٽس کي ڪيئن هلائڻ؟ اتي ڪيترائي اختيار آھن: ھڪڙي ٽئين پارٽي جي خدمت استعمال ڪريو جيئن SpotInst (ھاڻي "Spot" سڏيو ويندو آھي، مون کان نه پڇو ڇو)، يا صرف پنھنجي ڪلستر ۾ ھڪڙو Spot AutoScalingGroup (ASG) شامل ڪريو. مثال طور، ھتي آھي CloudFormation snippet for a "capity-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 Gathering 2019 تي يوٽيوب تي ۽ سلائيڊز ۾.

ڪبرنيٽس تي بادل جي خرچن کي بچائڻ لاءِ توهان جا بهترين طريقا ڪهڙا آهن؟ مهرباني ڪري مون کي خبر ڏيو تي Twitter (@try_except_).

[1] حقيقت ۾، 3 وي سي پي يوز کان گھٽ استعمال جي قابل رھندا جيئن نوڊ جي ذريعي گھٽجي ويندي آھي محفوظ ڪيل سسٽم وسيلن جي ذريعي. ڪبرنيٽس فزيڪل نوڊ جي گنجائش ۽ "روزي ڪيل" وسيلن جي وچ ۾ فرق ڪري ٿو (نوڊ مختص).

[2] حساب ڪتاب جو مثال: هڪ m5.large مثال 8 GiB ميموري سان ~$84 هر مهيني آهي (eu-central-1, On-Demand), يعني. 1/8 نوڊ کي بلاڪ ڪرڻ لڳ ڀڳ ~ $10/مهينو آهي.

[3] توھان جي EC2 بل کي گھٽائڻ لاءِ ڪيترائي وڌيڪ طريقا آھن، جھڙوڪ محفوظ ٿيل مثال، بچت جو منصوبو، وغيره. - مان انھن عنوانن کي ھتي نه ڍڪيندس، پر توھان کي انھن تي ضرور غور ڪرڻ گھرجي!

ڪورس بابت وڌيڪ ڄاڻو.

جو ذريعو: www.habr.com

AWS تي Kubernetes ڪلائوڊ خرچن تي بچايو