ప్రోహోస్టర్ > బ్లాగ్ > పరిపాలన > AWSలో Kubernetes క్లౌడ్ ఖర్చులను ఆదా చేయండి

AWSలో Kubernetes క్లౌడ్ ఖర్చులను ఆదా చేయండి

వ్యాసం యొక్క అనువాదం కోర్సు ప్రారంభం సందర్భంగా తయారు చేయబడింది "కుబెర్నెట్స్ ఆధారంగా మౌలిక సదుపాయాల వేదిక".

AWSలో Kubernetes క్లౌడ్ ఖర్చులను ఆదా చేయండి

కుబెర్నెట్స్‌తో పనిచేసేటప్పుడు క్లౌడ్ ఖర్చులను ఎలా ఆదా చేయాలి? సరైన పరిష్కారం ఏదీ లేదు, కానీ ఈ కథనం మీ వనరులను మరింత సమర్థవంతంగా నిర్వహించడంలో మరియు మీ క్లౌడ్ కంప్యూటింగ్ ఖర్చులను తగ్గించడంలో మీకు సహాయపడే అనేక సాధనాలను వివరిస్తుంది.

నేను AWS కోసం కుబెర్నెట్స్‌తో ఈ కథనాన్ని వ్రాశాను, అయితే ఇది ఇతర క్లౌడ్ ప్రొవైడర్‌లకు (దాదాపు) అదే విధంగా వర్తిస్తుంది. మీ క్లస్టర్(లు) ఇప్పటికే ఆటోస్కేలింగ్ కాన్ఫిగర్ చేయబడిందని నేను ఊహిస్తున్నాను (క్లస్టర్-ఆటోస్కేలర్) వనరులను తీసివేయడం మరియు మీ విస్తరణను తగ్గించడం వలన మీ వర్కర్ నోడ్‌ల (EC2 ఉదంతాలు) కూడా తగ్గితేనే మీ డబ్బు ఆదా అవుతుంది.

В В В той статье будут rasmotrenы:

  • ఉపయోగించని వనరులను శుభ్రపరచడం (కుబే-జానిటర్)
  • పని చేయని సమయాల్లో స్కేలింగ్‌ను తగ్గించండి (kube-downscaler)
  • క్షితిజసమాంతర ఆటోస్కేలింగ్ (HPA)ని ఉపయోగించడం
  • అధిక వనరుల రిజర్వేషన్ తగ్గింపు (kube-resource-report, VPA)
  • స్పాట్ ఉదాహరణలను ఉపయోగించడం

ఉపయోగించని వనరులను శుభ్రపరచడం

వేగవంతమైన వాతావరణంలో పని చేయడం చాలా బాగుంది. మాకు సాంకేతిక సంస్థలు కావాలి వేగవంతమైంది. వేగవంతమైన సాఫ్ట్‌వేర్ డెలివరీ అంటే మరిన్ని PR విస్తరణలు, ప్రివ్యూ పరిసరాలు, నమూనాలు మరియు విశ్లేషణల పరిష్కారాలు. ప్రతిదీ కుబెర్నెట్స్‌లో అమర్చబడింది. పరీక్ష విస్తరణలను మాన్యువల్‌గా శుభ్రం చేయడానికి ఎవరికి సమయం ఉంది? వారం నాటి ప్రయోగాన్ని తొలగించడం గురించి మర్చిపోవడం సులభం. మనం మూసివేయడం మరచిపోయిన కారణంగా క్లౌడ్ బిల్లు పెరుగుతుంది:

AWSలో Kubernetes క్లౌడ్ ఖర్చులను ఆదా చేయండి

(హెన్నింగ్ జాకబ్స్:
జిజా:
(కోట్స్) కోరీ క్విన్:
అపోహ: మీ AWS ఖాతా అనేది మీరు కలిగి ఉన్న వినియోగదారుల సంఖ్యకు సంబంధించిన విధి.
వాస్తవం: మీ AWS స్కోర్ అనేది మీ వద్ద ఉన్న ఇంజనీర్ల సంఖ్యకు సంబంధించిన విధి.

ఇవాన్ కర్నోసోవ్ (ప్రతిస్పందనగా):
వాస్తవ వాస్తవం: మీ AWS స్కోర్ అనేది మీరు డిసేబుల్/తొలగించడం మర్చిపోయిన అంశాల సంఖ్య.)

కుబెర్నెటెస్ కాపలాదారు (kube-janitor) మీ క్లస్టర్‌ను శుభ్రం చేయడంలో సహాయపడుతుంది. కాపలాదారు కాన్ఫిగరేషన్ ప్రపంచ మరియు స్థానిక ఉపయోగం రెండింటికీ అనువైనది:

  • క్లస్టర్-విస్తృత నియమాలు PR/పరీక్ష విస్తరణల కోసం గరిష్టంగా ప్రత్యక్ష ప్రసారం (TTL)ని నిర్వచించగలవు.
  • వ్యక్తిగత వనరులను ద్వారపాలకుడు/ttlతో ఉల్లేఖించవచ్చు, ఉదాహరణకు 7 రోజుల తర్వాత స్పైక్/ప్రోటోటైప్‌ను స్వయంచాలకంగా తీసివేయడం.

సాధారణ నియమాలు YAML ఫైల్‌లో నిర్వచించబడ్డాయి. దాని మార్గం పరామితి గుండా వెళుతుంది --rules-file kube-janitor లో. అన్ని నేమ్‌స్పేస్‌లను తీసివేయడానికి ఇక్కడ ఒక ఉదాహరణ నియమం ఉంది -pr- రెండు రోజుల తర్వాత పేరులో:

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

కింది ఉదాహరణ 2020లో అన్ని కొత్త డిప్లాయ్‌మెంట్‌లు/స్టేట్‌ఫుల్‌సెట్‌ల కోసం డిప్లాయ్‌మెంట్ మరియు స్టేట్‌ఫుల్‌సెట్ పాడ్‌లపై అప్లికేషన్ లేబుల్ వినియోగాన్ని నియంత్రిస్తుంది, అయితే అదే సమయంలో ఈ లేబుల్ లేకుండా ఒక వారం పాటు పరీక్షలను అమలు చేయడానికి అనుమతిస్తుంది:

- 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

క్లస్టర్ నడుస్తున్న kube-janitorలో 30 నిమిషాల పాటు సమయ-పరిమిత డెమోని అమలు చేయండి:

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

పెరుగుతున్న ఖర్చులకు మరొక మూలం నిరంతర వాల్యూమ్‌లు (AWS EBS). కుబెర్నెటెస్ స్టేట్‌ఫుల్‌సెట్‌ను తొలగించడం వలన దాని నిరంతర వాల్యూమ్‌లు (PVC - PersistentVolumeClaim) తొలగించబడవు. ఉపయోగించని EBS వాల్యూమ్‌లు సులభంగా నెలకు వందల డాలర్ల ఖర్చులకు దారితీస్తాయి. Kubernetes Janitor ఉపయోగించని PVCలను శుభ్రం చేయడానికి ఒక ఫీచర్‌ను కలిగి ఉంది. ఉదాహరణకు, ఈ నియమం మాడ్యూల్ ద్వారా మౌంట్ చేయని మరియు StatefulSet లేదా CronJob ద్వారా సూచించబడని అన్ని PVCలను తీసివేస్తుంది:

# удалить все 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-janitor.

పని చేయని సమయాల్లో స్కేలింగ్‌ను తగ్గించండి

పరీక్ష మరియు స్టేజింగ్ సిస్టమ్‌లు సాధారణంగా పని వేళల్లో మాత్రమే పనిచేయవలసి ఉంటుంది. బ్యాక్ ఆఫీస్/అడ్మిన్ టూల్స్ వంటి కొన్ని ప్రొడక్షన్ అప్లికేషన్‌లకు కూడా పరిమిత లభ్యత అవసరం మరియు రాత్రిపూట నిలిపివేయబడవచ్చు.

కుబెర్నెటెస్ డౌన్‌స్కేలర్ (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

వారాంతాల్లో క్లస్టర్ వర్కర్ నోడ్‌లను స్కేలింగ్ చేయడానికి ఇక్కడ గ్రాఫ్ ఉంది:

AWSలో Kubernetes క్లౌడ్ ఖర్చులను ఆదా చేయండి

~13 నుండి 4 వర్కర్ నోడ్‌లను తగ్గించడం వలన మీ AWS బిల్లులో ఖచ్చితంగా గుర్తించదగిన తేడా ఉంటుంది.

అయితే క్లస్టర్ "డౌన్‌టైమ్" సమయంలో నేను పని చేయాల్సి వస్తే? డౌన్‌స్కేలర్/మినహాయింపు: నిజమైన ఉల్లేఖనాన్ని జోడించడం ద్వారా నిర్దిష్ట విస్తరణలు స్కేలింగ్ నుండి శాశ్వతంగా మినహాయించబడతాయి. YYYY-MM-DD HH:MM (UTC) ఫార్మాట్‌లో సంపూర్ణ టైమ్‌స్టాంప్‌తో డౌన్‌స్కేలర్/ఎక్స్‌క్లూడ్-వరకు ఉల్లేఖనాన్ని ఉపయోగించి విస్తరణలను తాత్కాలికంగా మినహాయించవచ్చు. అవసరమైతే, ఉల్లేఖనంతో పాడ్‌ని అమర్చడం ద్వారా మొత్తం క్లస్టర్‌ను తిరిగి స్కేల్ చేయవచ్చు 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, మీరు విస్తరణ సూచనలు మరియు అదనపు ఎంపికలపై ఆసక్తి కలిగి ఉంటే.

క్షితిజ సమాంతర ఆటోస్కేలింగ్‌ని ఉపయోగించండి

అనేక అప్లికేషన్లు/సర్వీసులు డైనమిక్ లోడింగ్ నమూనాతో వ్యవహరిస్తాయి: కొన్నిసార్లు వాటి మాడ్యూల్స్ నిష్క్రియంగా ఉంటాయి మరియు కొన్నిసార్లు అవి పూర్తి సామర్థ్యంతో పని చేస్తాయి. గరిష్ట పీక్ లోడ్‌ను ఎదుర్కోవడానికి శాశ్వత ప్యాడ్‌లను నిర్వహించడం ఆర్థికంగా లేదు. కుబెర్నెటెస్ వనరు అంతటా క్షితిజ సమాంతర స్వీయ-స్కేలింగ్‌కు మద్దతు ఇస్తుంది క్షితిజసమాంతర పోడ్ ఆటోస్కేలర్ (HPA). CPU వినియోగం తరచుగా స్కేలింగ్ కోసం మంచి సూచిక:

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 కోసం సిఫార్సులతో ప్రదర్శనను కలిగి ఉంది: మీ వ్యాలెట్‌లను స్కేల్ చేయండి, మీ వాలెట్ కాదు.

రిసోర్స్ ఓవర్‌బుకింగ్‌ను తగ్గించండి

కుబెర్నెట్స్ పనిభారం వారి CPU/మెమరీ అవసరాలను "వనరుల అభ్యర్థనల" ద్వారా నిర్ణయిస్తుంది. CPU వనరులు వర్చువల్ కోర్లలో లేదా సాధారణంగా "మిల్లికోర్లు"లో కొలుస్తారు, ఉదాహరణకు 500m అంటే 50% vCPU. మెమరీ వనరులు బైట్‌లలో కొలుస్తారు మరియు 500 మెగాబైట్‌లు అంటే 500Mi వంటి సాధారణ ప్రత్యయాలను ఉపయోగించవచ్చు. రిసోర్స్ రిక్వెస్ట్‌లు వర్కర్ నోడ్‌లపై "లాక్" కెపాసిటీ, అంటే 1000 vCPUలు ఉన్న నోడ్‌లో 4m CPU అభ్యర్థన ఉన్న పాడ్ ఇతర పాడ్‌లకు 3 vCPUలు మాత్రమే అందుబాటులో ఉంచుతుంది. [1]

స్లాక్ (అదనపు నిల్వ) అభ్యర్థించిన వనరులు మరియు వాస్తవ వినియోగం మధ్య వ్యత్యాసం. ఉదాహరణకు, 2 GiB మెమరీని అభ్యర్థించి, 200 MiB మాత్రమే ఉపయోగించే పాడ్‌లో ~1,8 GiB "అదనపు" మెమరీ ఉంటుంది. అధిక ధనం ఖర్చవుతుంది. 1 GiB రిడెండెంట్ మెమరీకి నెలకు ~$10 ఖర్చవుతుందని స్థూలంగా అంచనా వేయవచ్చు. [2]

కుబెర్నెట్స్ రిసోర్స్ రిపోర్ట్ (kube-resource-report) అదనపు నిల్వలను ప్రదర్శిస్తుంది మరియు పొదుపు సామర్థ్యాన్ని గుర్తించడంలో మీకు సహాయపడుతుంది:

AWSలో Kubernetes క్లౌడ్ ఖర్చులను ఆదా చేయండి

కుబెర్నెట్స్ రిసోర్స్ రిపోర్ట్ అప్లికేషన్ మరియు కమాండ్ ద్వారా అదనపు మొత్తం చూపిస్తుంది. ఇది వనరుల డిమాండ్లను తగ్గించగల స్థలాలను కనుగొనడానికి మిమ్మల్ని అనుమతిస్తుంది. రూపొందించబడిన HTML నివేదిక వనరుల వినియోగం యొక్క స్నాప్‌షాట్‌ను మాత్రమే అందిస్తుంది. తగిన వనరుల అభ్యర్థనలను గుర్తించడానికి మీరు కాలక్రమేణా CPU/మెమొరీ వినియోగాన్ని చూడాలి. "విలక్షణమైన" CPU-హెవీ సర్వీస్ కోసం గ్రాఫానా చార్ట్ ఇక్కడ ఉంది: అన్ని పాడ్‌లు అభ్యర్థించిన 3 CPU కోర్ల కంటే చాలా తక్కువగా ఉపయోగిస్తున్నాయి:

AWSలో Kubernetes క్లౌడ్ ఖర్చులను ఆదా చేయండి

CPU అభ్యర్థనను 3000m నుండి ~400mకి తగ్గించడం వలన ఇతర పనిభారం కోసం వనరులను ఖాళీ చేస్తుంది మరియు క్లస్టర్ చిన్నదిగా ఉండటానికి అనుమతిస్తుంది.

"EC2 ఉదంతాల యొక్క సగటు CPU వినియోగం తరచుగా ఒకే-అంకెల శాతం పరిధిలో ఉంటుంది" కోరీ క్విన్ రాశారు. EC2 కోసం అయితే సరైన పరిమాణాన్ని అంచనా వేయడం తప్పు నిర్ణయం కావచ్చుYAML ఫైల్‌లో కొన్ని కుబెర్నెట్స్ రిసోర్స్ క్వెరీలను మార్చడం సులభం మరియు భారీ పొదుపులను పొందవచ్చు.

అయితే YAML ఫైల్‌లలో వ్యక్తులు విలువలను మార్చాలని మేము నిజంగా కోరుకుంటున్నారా? లేదు, యంత్రాలు దీన్ని మరింత మెరుగ్గా చేయగలవు! కుబెర్నెటీస్ వర్టికల్ పాడ్ ఆటోస్కేలర్ (VPA) అలా చేస్తుంది: పని భారం ప్రకారం వనరుల అభ్యర్థనలు మరియు పరిమితులను స్వీకరించడం. కాలక్రమేణా VPA ద్వారా స్వీకరించబడిన ప్రోమేతియస్ CPU అభ్యర్థనల (సన్నని నీలిరంగు గీత) ఉదాహరణ గ్రాఫ్ ఇక్కడ ఉంది:

AWSలో Kubernetes క్లౌడ్ ఖర్చులను ఆదా చేయండి

Zalando దాని అన్ని క్లస్టర్‌లలో VPAని ఉపయోగిస్తుంది మౌలిక సదుపాయాల భాగాల కోసం. నాన్-క్రిటికల్ అప్లికేషన్‌లు కూడా VPAని ఉపయోగించవచ్చు.

గోల్డిలాక్స్ Fairwind అనేది నేమ్‌స్పేస్‌లో ప్రతి విస్తరణ కోసం VPAని సృష్టించే ఒక సాధనం మరియు దాని డాష్‌బోర్డ్‌లో VPA సిఫార్సును ప్రదర్శిస్తుంది. డెవలపర్‌లు తమ అప్లికేషన్‌ల కోసం సరైన CPU/మెమొరీ అభ్యర్థనలను సెట్ చేయడంలో ఇది సహాయపడుతుంది:

AWSలో Kubernetes క్లౌడ్ ఖర్చులను ఆదా చేయండి

చిన్నగా రాశాను VPA గురించి బ్లాగ్ పోస్ట్ 2019లో మరియు ఇటీవల CNCF తుది వినియోగదారు సంఘం VPA సమస్యను చర్చించింది.

EC2 స్పాట్ ఉదంతాలను ఉపయోగించడం

చివరిది కానీ, AWS EC2 ఖర్చులను కుబెర్నెట్స్ వర్కర్ నోడ్‌లుగా స్పాట్ ఇన్‌స్టాన్స్‌లను ఉపయోగించడం ద్వారా తగ్గించవచ్చు [3]. ఆన్-డిమాండ్ ధరలతో పోలిస్తే స్పాట్ ఉదంతాలు 90% వరకు తగ్గింపుతో అందుబాటులో ఉన్నాయి. EC2 స్పాట్‌లో కుబెర్నెట్‌లను అమలు చేయడం మంచి కలయిక: మీరు అధిక లభ్యత కోసం అనేక విభిన్న ఉదాహరణ రకాలను పేర్కొనాలి, అంటే మీరు అదే లేదా తక్కువ ధరకు పెద్ద నోడ్‌ని పొందవచ్చు మరియు పెరిగిన సామర్థ్యాన్ని కంటెయినరైజ్డ్ కుబెర్నెట్స్ వర్క్‌లోడ్‌ల ద్వారా ఉపయోగించవచ్చు.

EC2 స్పాట్‌లో కుబెర్నెట్‌లను ఎలా అమలు చేయాలి? అనేక ఎంపికలు ఉన్నాయి: SpotInst (ఇప్పుడు "Spot" అని పిలుస్తారు, ఎందుకు అని నన్ను అడగవద్దు) వంటి మూడవ పక్ష సేవను ఉపయోగించండి లేదా మీ క్లస్టర్‌కి Spot AutoScalingGroup (ASG)ని జోడించండి. ఉదాహరణకు, బహుళ ఉదాహరణ రకాలతో "సామర్థ్యం-ఆప్టిమైజ్ చేయబడిన" 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 ఉపయోగిస్తుంది ఫోర్క్ నోడ్ పూల్ ప్రాధాన్యతలతో అధికారిక క్లస్టర్ ఆటోస్కేలింగ్
  • స్పాట్ నోడ్స్ బలవంతంగా చేయవచ్చు Spotలో అమలు చేయడానికి పనిభారం యొక్క "రిజిస్ట్రేషన్లను" అంగీకరించండి

సారాంశం

మీ క్లౌడ్ బిల్లును తగ్గించడంలో మీరు అందించిన కొన్ని సాధనాలు ఉపయోగకరంగా ఉన్నాయని నేను ఆశిస్తున్నాను. మీరు కథనంలోని చాలా విషయాలను ఇక్కడ కూడా కనుగొనవచ్చు YouTube మరియు స్లయిడ్‌లలో DevOps Gathering 2019లో నా ప్రసంగం.

Kubernetesలో క్లౌడ్ ఖర్చులను ఆదా చేయడానికి మీ ఉత్తమ పద్ధతులు ఏమిటి? దయచేసి నాకు తెలియజేయండి Twitter (@try_except_).

[1] వాస్తవానికి, రిజర్వు చేయబడిన సిస్టమ్ వనరుల ద్వారా నోడ్ యొక్క నిర్గమాంశ తగ్గినందున 3 కంటే తక్కువ vCPUలు ఉపయోగించబడతాయి. కుబెర్నెటెస్ భౌతిక నోడ్ సామర్థ్యం మరియు "నిర్ధారిత" వనరుల మధ్య తేడాను చూపుతుంది (నోడ్ కేటాయించదగినది).

[2] గణన ఉదాహరణ: 5 GiB మెమరీతో ఒక m8. పెద్ద ఉదాహరణ నెలకు ~$84 ​​(eu-central-1, ఆన్-డిమాండ్), అనగా. 1/8 నోడ్‌ను నిరోధించడం అనేది సుమారుగా ~$10/నెలకు.

[3] మీ EC2 బిల్లును తగ్గించడానికి రిజర్వ్ చేయబడిన సందర్భాలు, పొదుపు ప్రణాళిక మొదలైన అనేక మార్గాలు ఉన్నాయి - నేను ఆ అంశాలను ఇక్కడ కవర్ చేయను, కానీ మీరు వాటిని ఖచ్చితంగా పరిశీలించాలి!

కోర్సు గురించి మరింత తెలుసుకోండి.

మూలం: www.habr.com

ఒక వ్యాఖ్యను జోడించండి