AWS-ൽ Kubernetes ക്ലൗഡ് ചെലവുകൾ ലാഭിക്കുക

കോഴ്‌സ് തുടങ്ങുന്നതിന്റെ തലേന്ന് തയ്യാറാക്കിയതാണ് ലേഖനത്തിന്റെ പരിഭാഷ "കുബർനെറ്റുകളെ അടിസ്ഥാനമാക്കിയുള്ള ഇൻഫ്രാസ്ട്രക്ചർ പ്ലാറ്റ്ഫോം".

കുബർനെറ്റസുമായി പ്രവർത്തിക്കുമ്പോൾ ക്ലൗഡ് ചെലവ് എങ്ങനെ ലാഭിക്കാം? ശരിയായ ഒരു പരിഹാരവുമില്ല, എന്നാൽ നിങ്ങളുടെ ഉറവിടങ്ങൾ കൂടുതൽ ഫലപ്രദമായി കൈകാര്യം ചെയ്യാനും നിങ്ങളുടെ ക്ലൗഡ് കമ്പ്യൂട്ടിംഗ് ചെലവ് കുറയ്ക്കാനും സഹായിക്കുന്ന നിരവധി ടൂളുകൾ ഈ ലേഖനം വിവരിക്കുന്നു.

AWS-നായി കുബർനെറ്റസ് മനസ്സിൽ വെച്ചാണ് ഞാൻ ഈ ലേഖനം എഴുതിയത്, എന്നാൽ മറ്റ് ക്ലൗഡ് ദാതാക്കൾക്കും ഇത് ബാധകമാകും (ഏതാണ്ട്). നിങ്ങളുടെ ക്ലസ്റ്റർ(കൾ) ഇതിനകം സ്വയമേവ സ്‌കെയിലിംഗ് ക്രമീകരിച്ചിട്ടുണ്ടെന്ന് ഞാൻ അനുമാനിക്കുന്നു (ക്ലസ്റ്റർ-ഓട്ടോസ്കെയിലർ). ഉറവിടങ്ങൾ നീക്കം ചെയ്യുകയും നിങ്ങളുടെ വിന്യാസം കുറയ്ക്കുകയും ചെയ്യുന്നത് നിങ്ങളുടെ വർക്കർ നോഡുകളുടെ (EC2 സംഭവങ്ങൾ) കുറയ്ക്കുകയാണെങ്കിൽ മാത്രമേ നിങ്ങളുടെ പണം ലാഭിക്കൂ.

ഈ ലേഖനം ഉൾപ്പെടും:

• ഉപയോഗിക്കാത്ത വിഭവങ്ങൾ വൃത്തിയാക്കുന്നു (കുബേ-ജാനിറ്റർ)
• ജോലി ചെയ്യാത്ത സമയങ്ങളിൽ സ്കെയിലിംഗ് കുറയ്ക്കുക (kube-downscaler)
• ഹോറിസോണ്ടൽ ഓട്ടോസ്‌കേലിംഗ് (HPA) ഉപയോഗിച്ച്
• അമിതമായ റിസർവേഷൻ കുറയ്ക്കൽ (kube-resource-report, VPA)
• സ്പോട്ട് സംഭവങ്ങൾ ഉപയോഗിക്കുന്നു

ഉപയോഗിക്കാത്ത വിഭവങ്ങൾ വൃത്തിയാക്കുന്നു

വേഗതയേറിയ അന്തരീക്ഷത്തിൽ പ്രവർത്തിക്കുന്നത് മികച്ചതാണ്. ഞങ്ങൾക്ക് സാങ്കേതിക സ്ഥാപനങ്ങൾ വേണം ത്വരിതപ്പെടുത്തി. വേഗതയേറിയ സോഫ്‌റ്റ്‌വെയർ ഡെലിവറി എന്നാൽ കൂടുതൽ പിആർ വിന്യാസങ്ങൾ, പ്രിവ്യൂ എൻവയോൺമെന്റുകൾ, പ്രോട്ടോടൈപ്പുകൾ, അനലിറ്റിക്‌സ് സൊല്യൂഷനുകൾ എന്നിവ അർത്ഥമാക്കുന്നു. എല്ലാം കുബർനെറ്റസിൽ വിന്യസിച്ചിരിക്കുന്നു. ടെസ്റ്റ് വിന്യാസങ്ങൾ സ്വമേധയാ വൃത്തിയാക്കാൻ ആർക്കാണ് സമയം? ഒരാഴ്‌ച പഴക്കമുള്ള ഒരു പരീക്ഷണം ഇല്ലാതാക്കുന്നത് മറക്കാൻ എളുപ്പമാണ്. ഞങ്ങൾ അടയ്ക്കാൻ മറന്ന എന്തെങ്കിലും കാരണം ക്ലൗഡ് ബിൽ ഉയരും:

(ഹെന്നിംഗ് ജേക്കബ്സ്:
Zhiza:
(ഉദ്ധരണികൾ) കോറി ക്വിൻ:
മിഥ്യാധാരണ: നിങ്ങളുടെ AWS അക്കൗണ്ട്, നിങ്ങൾക്കുള്ള ഉപയോക്താക്കളുടെ എണ്ണത്തിന്റെ പ്രവർത്തനമാണ്.
വസ്‌തുത: നിങ്ങളുടെ എ‌ഡബ്ല്യുഎസ് സ്‌കോർ നിങ്ങൾക്കുള്ള എഞ്ചിനീയർമാരുടെ എണ്ണത്തിന്റെ പ്രവർത്തനമാണ്.

ഇവാൻ കുർനോസോവ് (പ്രതികരണത്തിൽ):
യഥാർത്ഥ വസ്‌തുത: നിങ്ങളുടെ AWS സ്‌കോർ എന്നത് നിങ്ങൾ അപ്രാപ്‌തമാക്കാൻ/ഇല്ലാതാക്കാൻ മറന്ന കാര്യങ്ങളുടെ എണ്ണമാണ്.)

കുബെർനെറ്റസ് കാവൽക്കാരൻ (kube-janitor) നിങ്ങളുടെ ക്ലസ്റ്റർ വൃത്തിയാക്കാൻ സഹായിക്കുന്നു. ജാനിറ്റർ കോൺഫിഗറേഷൻ ആഗോളവും പ്രാദേശികവുമായ ഉപയോഗത്തിന് അയവുള്ളതാണ്:

• ക്ലസ്റ്റർ-വൈഡ് നിയമങ്ങൾക്ക് പിആർ/ടെസ്റ്റ് വിന്യാസങ്ങൾക്കായി പരമാവധി സമയം-ടു-ലൈവ് (ടിടിഎൽ) നിർവചിക്കാനാകും.
• 7 ദിവസത്തിന് ശേഷം സ്പൈക്ക്/പ്രോട്ടോടൈപ്പ് സ്വയമേവ നീക്കം ചെയ്യുന്നതിനായി, വ്യക്തിഗത ഉറവിടങ്ങൾ ജാനിറ്റർ/ടിടിഎൽ ഉപയോഗിച്ച് വ്യാഖ്യാനിക്കാം.

പൊതു നിയമങ്ങൾ YAML ഫയലിൽ നിർവചിച്ചിരിക്കുന്നു. അതിന്റെ പാത പരാമീറ്ററിലൂടെ കടന്നുപോകുന്നു --rules-file കുബേ-ജാനിറ്ററിൽ. എല്ലാ നെയിംസ്പേസുകളും നീക്കം ചെയ്യുന്നതിനുള്ള ഒരു ഉദാഹരണം ഇവിടെയുണ്ട് -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

ക്യൂബ്-ജാനിറ്റർ പ്രവർത്തിക്കുന്ന ഒരു ക്ലസ്റ്ററിൽ 30 മിനിറ്റ് സമയ പരിമിതമായ ഡെമോ പ്രവർത്തിപ്പിക്കുക:

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

വർദ്ധിച്ചുവരുന്ന ചെലവുകളുടെ മറ്റൊരു ഉറവിടം പെർസിസ്റ്റന്റ് വോള്യങ്ങളാണ് (AWS EBS). ഒരു Kubernetes StatefulSet ഇല്ലാതാക്കുന്നത് അതിന്റെ സ്ഥിരമായ വോള്യങ്ങൾ ഇല്ലാതാക്കില്ല (PVC - PersistentVolumeClaim). ഉപയോഗിക്കാത്ത EBS വോള്യങ്ങൾ എളുപ്പത്തിൽ പ്രതിമാസം നൂറുകണക്കിന് ഡോളർ ചിലവാക്കിയേക്കാം. ഉപയോഗിക്കാത്ത പിവിസികൾ വൃത്തിയാക്കാൻ കുബർനെറ്റസ് ജാനിറ്ററിന് ഒരു ഫീച്ചർ ഉണ്ട്. ഉദാഹരണത്തിന്, ഒരു മൊഡ്യൂൾ മൌണ്ട് ചെയ്യാത്തതും 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

വാരാന്ത്യങ്ങളിൽ ക്ലസ്റ്റർ വർക്കർ നോഡുകൾ അളക്കുന്നതിനുള്ള ഒരു ഗ്രാഫ് ഇതാ:

~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, വിന്യാസ നിർദ്ദേശങ്ങളിലും അധിക ഓപ്ഷനുകളിലും നിങ്ങൾക്ക് താൽപ്പര്യമുണ്ടെങ്കിൽ.

തിരശ്ചീന യാന്ത്രിക സ്കെയിലിംഗ് ഉപയോഗിക്കുക

പല ആപ്ലിക്കേഷനുകളും/സേവനങ്ങളും ഒരു ഡൈനാമിക് ലോഡിംഗ് പാറ്റേൺ കൈകാര്യം ചെയ്യുന്നു: ചിലപ്പോൾ അവയുടെ മൊഡ്യൂളുകൾ നിഷ്‌ക്രിയമായിരിക്കും, ചിലപ്പോൾ അവ പൂർണ്ണ ശേഷിയിൽ പ്രവർത്തിക്കും. പരമാവധി പീക്ക് ലോഡിനെ നേരിടാൻ പോഡുകളുടെ ഒരു സ്ഥിരം ഫ്ലീറ്റ് പ്രവർത്തിപ്പിക്കുന്നത് ലാഭകരമല്ല. ഒരു റിസോഴ്‌സിൽ ഉടനീളം തിരശ്ചീനമായ യാന്ത്രിക സ്കെയിലിംഗിനെ കുബർനെറ്റസ് പിന്തുണയ്ക്കുന്നു 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) പോഡുകളുടെ തിരശ്ചീന ഓട്ടോസ്‌കേലിംഗിനായി ഇഷ്‌ടാനുസൃതവും ബാഹ്യവുമായ മെട്രിക്കുകൾ ശേഖരിക്കാനും സേവിക്കാനും കഴിയുന്ന കുബർനെറ്റസിനായുള്ള ഒരു ജനറിക് മെട്രിക്സ് അഡാപ്റ്ററാണ്. ഇത് പ്രോമിത്യൂസ് മെട്രിക്‌സ്, 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 സൂചിപ്പിക്കുന്നു. മെമ്മറി ഉറവിടങ്ങൾ ബൈറ്റുകളിൽ അളക്കുന്നു, 500 മെഗാബൈറ്റ് എന്നർത്ഥം വരുന്ന 500Mi പോലെയുള്ള പൊതുവായ പ്രത്യയങ്ങൾ ഉപയോഗിക്കാം. വർക്കർ നോഡുകളിൽ റിസോഴ്‌സ് അഭ്യർത്ഥന "ലോക്ക്" കപ്പാസിറ്റി, അതായത് 1000 vCPU-കളുള്ള ഒരു നോഡിൽ 4m CPU അഭ്യർത്ഥനയുള്ള പോഡ് മറ്റ് പോഡുകൾക്ക് 3 vCPU-കൾ മാത്രമേ ലഭ്യമാകൂ. [1]

സ്ലാക്ക് (അധിക കരുതൽ) അഭ്യർത്ഥിച്ച ഉറവിടങ്ങളും യഥാർത്ഥ ഉപയോഗവും തമ്മിലുള്ള വ്യത്യാസമാണ്. ഉദാഹരണത്തിന്, 2 GiB മെമ്മറി ആവശ്യപ്പെടുന്ന എന്നാൽ 200 MiB മാത്രം ഉപയോഗിക്കുന്ന ഒരു പോഡിന് ~1,8 GiB "അധിക" മെമ്മറി ഉണ്ട്. അധികമായാൽ പണം ചിലവാകും. 1 GiB അനാവശ്യ മെമ്മറിക്ക് പ്രതിമാസം ~$10 ചിലവാകും എന്ന് ഒരാൾക്ക് ഏകദേശം കണക്കാക്കാം. [2]

കുബെർനെറ്റസ് റിസോഴ്സ് റിപ്പോർട്ട് (kube-resource-report) അധിക കരുതൽ ശേഖരം പ്രദർശിപ്പിക്കുകയും സമ്പാദ്യ സാധ്യത നിർണ്ണയിക്കാൻ നിങ്ങളെ സഹായിക്കുകയും ചെയ്യും:

കുബെർനെറ്റസ് റിസോഴ്സ് റിപ്പോർട്ട് ആപ്ലിക്കേഷനും കമാൻഡും ഉപയോഗിച്ച് സമാഹരിച്ച അധികഭാഗം കാണിക്കുന്നു. വിഭവ ആവശ്യകതകൾ കുറയ്ക്കാൻ കഴിയുന്ന സ്ഥലങ്ങൾ കണ്ടെത്താൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു. ജനറേറ്റ് ചെയ്ത HTML റിപ്പോർട്ട് റിസോഴ്സ് ഉപയോഗത്തിന്റെ ഒരു സ്നാപ്പ്ഷോട്ട് മാത്രമാണ് നൽകുന്നത്. മതിയായ റിസോഴ്സ് അഭ്യർത്ഥനകൾ നിർണ്ണയിക്കാൻ നിങ്ങൾ കാലക്രമേണ CPU/മെമ്മറി ഉപയോഗം നോക്കണം. "സാധാരണ" CPU-ഹെവി സേവനത്തിനായുള്ള ഒരു ഗ്രാഫാന ചാർട്ട് ഇതാ: എല്ലാ പോഡുകളും അഭ്യർത്ഥിച്ച 3 CPU കോറുകളേക്കാൾ വളരെ കുറവാണ് ഉപയോഗിക്കുന്നത്:

CPU അഭ്യർത്ഥന 3000m ൽ നിന്ന് ~ 400m ആയി കുറയ്ക്കുന്നത് മറ്റ് ജോലിഭാരങ്ങൾക്കുള്ള വിഭവങ്ങൾ സ്വതന്ത്രമാക്കുകയും ക്ലസ്റ്റർ ചെറുതാകാൻ അനുവദിക്കുകയും ചെയ്യുന്നു.

"ഇസി2 സംഭവങ്ങളുടെ ശരാശരി സിപിയു ഉപയോഗം പലപ്പോഴും ഒറ്റ-അക്ക ശതമാനം പരിധിയിലാണ്" കോറി ക്വിൻ എഴുതുന്നു. EC2 ന് വേണ്ടി ശരിയായ വലുപ്പം കണക്കാക്കുന്നത് ഒരു മോശം തീരുമാനമായിരിക്കാംഒരു YAML ഫയലിൽ ചില Kubernetes റിസോഴ്‌സ് അന്വേഷണങ്ങൾ മാറ്റുന്നത് എളുപ്പവും വലിയ സമ്പാദ്യവും കൊണ്ടുവരും.

എന്നാൽ YAML ഫയലുകളിൽ ആളുകൾ മൂല്യങ്ങൾ മാറ്റണമെന്ന് ഞങ്ങൾക്ക് ശരിക്കും ആവശ്യമുണ്ടോ? ഇല്ല, യന്ത്രങ്ങൾക്ക് ഇത് വളരെ നന്നായി ചെയ്യാൻ കഴിയും! കുബെർനെറ്റസ് ലംബ പോഡ് ഓട്ടോസ്കെയിലർ (VPA) അത് ചെയ്യുന്നു: ജോലിഭാരത്തിനനുസരിച്ച് റിസോഴ്സ് അഭ്യർത്ഥനകളും നിയന്ത്രണങ്ങളും പൊരുത്തപ്പെടുത്തുന്നു. കാലക്രമേണ VPA സ്വീകരിച്ച പ്രൊമിത്യൂസ് സിപിയു അഭ്യർത്ഥനകളുടെ (നേർത്ത നീല വര) ഒരു ഉദാഹരണ ഗ്രാഫ് ഇതാ:

Zalando അതിന്റെ എല്ലാ ക്ലസ്റ്ററുകളിലും VPA ഉപയോഗിക്കുന്നു അടിസ്ഥാന സൗകര്യ ഘടകങ്ങൾക്കായി. നോൺ-ക്രിട്ടിക്കൽ ആപ്ലിക്കേഷനുകൾക്കും VPA ഉപയോഗിക്കാം.

ഗോൾഡിലോക്ക്സ് ഒരു നെയിംസ്‌പെയ്‌സിലെ ഓരോ വിന്യാസത്തിനും ഒരു VPA സൃഷ്‌ടിക്കുകയും അതിന്റെ ഡാഷ്‌ബോർഡിൽ ഒരു VPA ശുപാർശ പ്രദർശിപ്പിക്കുകയും ചെയ്യുന്ന ഒരു ഉപകരണമാണ് Fairwind. ഡെവലപ്പർമാർക്ക് അവരുടെ ആപ്ലിക്കേഷനുകൾക്കായി ശരിയായ CPU/മെമ്മറി അഭ്യർത്ഥനകൾ സജ്ജമാക്കാൻ ഇത് സഹായിക്കും:

ഞാൻ ചെറുതായി എഴുതി വിപിഎയെക്കുറിച്ചുള്ള ബ്ലോഗ്പോസ്റ്റ് 2019-ലും അടുത്തിടെ CNCF എൻഡ് യൂസർ കമ്മ്യൂണിറ്റി VPA പ്രശ്നം ചർച്ച ചെയ്തു.

EC2 സ്പോട്ട് സംഭവങ്ങൾ ഉപയോഗിക്കുന്നു

അവസാനമായി പക്ഷേ, കുബെർനെറ്റസ് വർക്കർ നോഡുകളായി സ്പോട്ട് സംഭവങ്ങൾ ഉപയോഗിച്ച് AWS EC2 ചെലവ് കുറയ്ക്കാനാകും. [3]. ഓൺ-ഡിമാൻഡ് വിലകളുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ സ്‌പോട്ട് സംഭവങ്ങൾ 90% വരെ കിഴിവിൽ ലഭ്യമാണ്. EC2 Spot-ൽ Kubernetes പ്രവർത്തിപ്പിക്കുന്നത് ഒരു നല്ല സംയോജനമാണ്: ഉയർന്ന ലഭ്യതയ്ക്കായി നിങ്ങൾ നിരവധി വ്യത്യസ്ത ഉദാഹരണ തരങ്ങൾ വ്യക്തമാക്കേണ്ടതുണ്ട്, അതായത് ഒരേ അല്ലെങ്കിൽ കുറഞ്ഞ വിലയ്ക്ക് നിങ്ങൾക്ക് ഒരു വലിയ നോഡ് ലഭിക്കും, കൂടാതെ വർദ്ധിപ്പിച്ച ശേഷി കണ്ടെയ്നറൈസ് ചെയ്ത Kubernetes വർക്ക്ലോഡുകൾക്ക് ഉപയോഗിക്കാനാകും.

EC2 Spot-ൽ Kubernetes എങ്ങനെ പ്രവർത്തിപ്പിക്കാം? കുറച്ച് ഓപ്ഷനുകൾ ഉണ്ട്: SpotInst (ഇപ്പോൾ "സ്പോട്ട്" എന്ന് വിളിക്കുന്നു, എന്തുകൊണ്ടെന്ന് എന്നോട് ചോദിക്കരുത്) പോലുള്ള ഒരു മൂന്നാം കക്ഷി സേവനം ഉപയോഗിക്കുക അല്ലെങ്കിൽ നിങ്ങളുടെ ക്ലസ്റ്ററിലേക്ക് ഒരു Spot AutoScalingGroup (ASG) ചേർക്കുക. ഉദാഹരണത്തിന്, ഒന്നിലധികം ഉദാഹരണ തരങ്ങളുള്ള "ശേഷി-ഒപ്റ്റിമൈസ് ചെയ്ത" Spot ASG-യ്‌ക്കായുള്ള ഒരു CloudFormation സ്‌നിപ്പറ്റ് ഇതാ:

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 ഉപയോഗിക്കുന്നു നാൽക്കവല നോഡ് പൂൾ മുൻഗണനകളുള്ള ഔദ്യോഗിക ക്ലസ്റ്റർ ഓട്ടോസ്കേലിംഗ്
• സ്പോട്ട് നോഡുകൾ നിർബന്ധിക്കാം സ്‌പോട്ടിൽ പ്രവർത്തിക്കാൻ ജോലിഭാരങ്ങളുടെ "രജിസ്‌ട്രേഷൻ" സ്വീകരിക്കുക

സംഗ്രഹം

നിങ്ങളുടെ ക്ലൗഡ് ബിൽ കുറയ്ക്കുന്നതിന് അവതരിപ്പിച്ച ചില ടൂളുകൾ നിങ്ങൾക്ക് ഉപയോഗപ്രദമാണെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു. ലേഖനത്തിന്റെ മിക്ക ഉള്ളടക്കങ്ങളും നിങ്ങൾക്ക് ഇവിടെയും കണ്ടെത്താനാകും 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