សន្សំលើការចំណាយលើពពក Kubernetes នៅលើ AWS

ការបកប្រែអត្ថបទត្រូវបានរៀបចំនៅមុនថ្ងៃចាប់ផ្តើមនៃវគ្គសិក្សា "វេទិកាហេដ្ឋារចនាសម្ព័ន្ធផ្អែកលើ Kubernetes".

តើធ្វើដូចម្តេចដើម្បីសន្សំលើការចំណាយលើពពកនៅពេលធ្វើការជាមួយ Kubernetes? មិនមានដំណោះស្រាយត្រឹមត្រូវតែមួយទេ ប៉ុន្តែអត្ថបទនេះពិពណ៌នាអំពីឧបករណ៍ជាច្រើនដែលអាចជួយអ្នកក្នុងការគ្រប់គ្រងធនធានរបស់អ្នកឱ្យកាន់តែមានប្រសិទ្ធភាព និងកាត់បន្ថយការចំណាយលើកុំព្យូទ័រលើពពករបស់អ្នក។

ខ្ញុំបានសរសេរអត្ថបទនេះជាមួយ Kubernetes សម្រាប់ AWS នៅក្នុងចិត្ត ប៉ុន្តែវានឹងអនុវត្ត (ស្ទើរតែ) ដូចគ្នាទៅនឹងអ្នកផ្តល់សេវាពពកផ្សេងទៀត។ ខ្ញុំសន្មត់ថាចង្កោមរបស់អ្នកបានកំណត់រចនាសម្ព័ន្ធ autoscaling រួចហើយ (cluster-autoscaler) ការដកធនធានចេញ និងកាត់បន្ថយការដាក់ពង្រាយរបស់អ្នក នឹងជួយសន្សំប្រាក់អ្នកបាន លុះត្រាតែវាកាត់បន្ថយក្រុមអ្នកធ្វើការ (ឧទាហរណ៍ EC2)។

អត្ថបទនេះនឹងគ្របដណ្តប់៖

• សម្អាតធនធានដែលមិនប្រើ (kube-janitor)
• កាត់បន្ថយការធ្វើមាត្រដ្ឋានក្នុងអំឡុងពេលមិនធ្វើការ (kube-downscaler)
• ដោយប្រើការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិផ្ដេក (HPA),
• ការកាត់បន្ថយការកក់ធនធានលើសលប់ (kube-resource-report, VPA)
• ដោយប្រើឧទាហរណ៍ Spot

ការសម្អាតធនធានដែលមិនប្រើ

ធ្វើការក្នុងបរិយាកាសដែលមានល្បឿនលឿនគឺអស្ចារ្យណាស់។ យើងចង់បានអង្គការបច្ចេកវិទ្យា បង្កើនល្បឿន. ការចែកចាយកម្មវិធីលឿនជាងមុនក៏មានន័យថា ការដាក់ពង្រាយ PR កាន់តែច្រើន បរិស្ថានមើលជាមុន គំរូ និងដំណោះស្រាយវិភាគ។ អ្វីគ្រប់យ៉ាងត្រូវបានដាក់ពង្រាយនៅលើ Kubernetes ។ តើអ្នកណាមានពេលវេលាដើម្បីសម្អាតការដាក់ពង្រាយសាកល្បងដោយដៃ? វាងាយស្រួលក្នុងការភ្លេចអំពីការលុបការពិសោធន៍ដែលមានរយៈពេលមួយសប្តាហ៍។ វិក្កយបត្រលើពពកនឹងកើនឡើងដោយសារតែអ្វីមួយដែលយើងភ្លេចបិទ៖

(Henning Jacobs:
ហ្សីហ្សា៖
(ដកស្រង់) Corey Quinn៖
ទេវកថា៖ គណនី AWS របស់អ្នកគឺជាមុខងារនៃចំនួនអ្នកប្រើប្រាស់ដែលអ្នកមាន។
ការពិត៖ ពិន្ទុ AWS របស់អ្នកគឺជាមុខងារនៃចំនួនវិស្វករដែលអ្នកមាន។

Ivan Kurnosov (ឆ្លើយតប)៖
ការពិត៖ ពិន្ទុ AWS របស់អ្នកគឺជាមុខងារនៃចំនួនអ្វីដែលអ្នកភ្លេចបិទ/លុប។)

Kubernetes Janitor (kube-janitor) ជួយសម្អាតចង្កោមរបស់អ្នក។ ការកំណត់រចនាសម្ព័ន្ធអ្នកថែទាំគឺអាចបត់បែនបានសម្រាប់ទាំងការប្រើប្រាស់ជាសកល និងក្នុងតំបន់៖

• ច្បាប់ទូលំទូលាយជាក្រុមអាចកំណត់ពេលវេលាអតិបរមាដើម្បីបន្តផ្ទាល់ (TTL) សម្រាប់ការដាក់ពង្រាយ PR/test ។
• ធនធានបុគ្គលអាចត្រូវបានកំណត់ចំណាំជាមួយ janitor/ttl ឧទាហរណ៍ដើម្បីដក spike/prototype ដោយស្វ័យប្រវត្តិបន្ទាប់ពី 7 ថ្ងៃ។

ច្បាប់ទូទៅត្រូវបានកំណត់នៅក្នុងឯកសារ YAML ។ ផ្លូវរបស់វាត្រូវបានឆ្លងកាត់ប៉ារ៉ាម៉ែត្រ --rules-file នៅ kube-janitor ។ នេះ​ជា​ច្បាប់​ឧទាហរណ៍​មួយ​ដើម្បី​លុប​ដក​ឃ្លា​ឈ្មោះ​ទាំងអស់​ចេញ​ជាមួយ -pr- នៅក្នុងឈ្មោះបន្ទាប់ពីពីរថ្ងៃ:

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

ឧទាហរណ៍ខាងក្រោមធ្វើនិយ័តកម្មការប្រើប្រាស់ស្លាកកម្មវិធីនៅលើ Deployment and StatefulSet pods សម្រាប់ Deployments/StatefulSets ថ្មីទាំងអស់ក្នុងឆ្នាំ 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 នាទីនៅលើចង្កោមដែលកំពុងដំណើរការ kube-janitor៖

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

ប្រភពមួយទៀតនៃការកើនឡើងថ្លៃដើមគឺបរិមាណជាប់លាប់ (AWS EBS)។ ការលុប Kubernetes StatefulSet មិនលុបភាគបន្តរបស់វា (PVC - PersistentVolumeClaim) ទេ។ បរិមាណ EBS ដែលមិនបានប្រើអាចបណ្តាលឱ្យមានការចំណាយរាប់រយដុល្លារក្នុងមួយខែយ៉ាងងាយស្រួល។ Kubernetes Janitor មានមុខងារសម្អាត PVC ដែលមិនប្រើ។ ឧទាហរណ៍ ច្បាប់នេះនឹងដក 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-janitor.

កាត់បន្ថយការធ្វើមាត្រដ្ឋានក្នុងអំឡុងពេលមិនធ្វើការ

ប្រព័ន្ធសាកល្បង និងដំណាក់កាលជាធម្មតាត្រូវបានទាមទារសម្រាប់ប្រតិបត្តិការតែក្នុងអំឡុងពេលម៉ោងធ្វើការប៉ុណ្ណោះ។ កម្មវិធីផលិតកម្មមួយចំនួន ដូចជា Back office/admin tools ក៏ត្រូវការតែមានកំណត់ ហើយអាចបិទបានពេញមួយយប់។

Kubernetes Downscaler (kube-downscaler) អនុញ្ញាតឱ្យអ្នកប្រើប្រាស់ និងប្រតិបត្តិករធ្វើមាត្រដ្ឋានប្រព័ន្ធក្នុងអំឡុងពេលមិនធ្វើការ។ ការដាក់ពង្រាយ និង StatefulSets អាចធ្វើមាត្រដ្ឋានទៅសូន្យការចម្លង។ 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ប្រសិនបើអ្នកចាប់អារម្មណ៍លើការណែនាំអំពីការដាក់ពង្រាយ និងជម្រើសបន្ថែម។

ប្រើ​ការ​ធ្វើ​មាត្រដ្ឋាន​ដោយ​ស្វ័យ​ប្រវត្តិ​ផ្ដេក

កម្មវិធី/សេវាកម្មជាច្រើនដោះស្រាយជាមួយលំនាំផ្ទុកថាមវន្ត៖ ពេលខ្លះម៉ូឌុលរបស់ពួកគេនៅទំនេរ ហើយពេលខ្លះពួកគេដំណើរការពេញសមត្ថភាព។ ប្រតិបត្តិការកងនាវាអចិន្រ្តៃយ៍ដើម្បីទប់ទល់នឹងបន្ទុកអតិបរមាគឺមិនសន្សំសំចៃទេ។ 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 (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/memory របស់ពួកគេតាមរយៈ "សំណើធនធាន" ។ ធនធានស៊ីភីយូត្រូវបានវាស់ជាស្នូលនិម្មិត ឬជាទូទៅនៅក្នុង "មីលីគ័រ" ឧទាហរណ៍ 500m បង្កប់ន័យ 50% vCPU ។ ធនធានអង្គចងចាំត្រូវបានវាស់ជាបៃ ហើយបច្ច័យទូទៅអាចត្រូវបានប្រើដូចជា 500Mi ដែលមានន័យថា 500 មេកាបៃ។ ធនធានស្នើសុំសមត្ថភាព "ចាក់សោ" នៅលើថ្នាំងកម្មករ មានន័យថា ផតដែលមានសំណើស៊ីភីយូ 1000 ម នៅលើថ្នាំងដែលមាន vCPU ចំនួន 4 នឹងទុកតែ vCPU 3 ប៉ុណ្ណោះដែលមានសម្រាប់ផតផតផតថល។ [1]

Slack (បម្រុងលើស) គឺជាភាពខុសគ្នារវាងធនធានដែលបានស្នើសុំ និងការប្រើប្រាស់ជាក់ស្តែង។ ឧទាហរណ៍ ផតដែលស្នើសុំអង្គចងចាំ 2 GiB ប៉ុន្តែប្រើតែ 200 MiB មានអង្គចងចាំ "លើស" ~ 1,8 GiB ។ លើសត្រូវចំណាយប្រាក់។ មនុស្សម្នាក់អាចប៉ាន់ស្មានបានថា 1 GiB នៃអង្គចងចាំដែលលែងត្រូវការនោះមានតម្លៃ ~ $10 ក្នុងមួយខែ។ [2]

របាយការណ៍ធនធាន Kubernetes (kube-resource-report) បង្ហាញទុនបម្រុងលើស ហើយអាចជួយអ្នកកំណត់សក្តានុពលនៃការសន្សំ៖

របាយការណ៍ធនធាន Kubernetes បង្ហាញចំនួនលើសដែលសរុបដោយកម្មវិធី និងពាក្យបញ្ជា។ នេះអនុញ្ញាតឱ្យអ្នកស្វែងរកកន្លែងដែលតម្រូវការធនធានអាចត្រូវបានកាត់បន្ថយ។ របាយការណ៍ HTML ដែលបង្កើតបានផ្តល់នូវរូបភាពនៃការប្រើប្រាស់ធនធានតែប៉ុណ្ណោះ។ អ្នកគួរតែមើលការប្រើប្រាស់ CPU/memory លើសម៉ោងដើម្បីកំណត់សំណើធនធានគ្រប់គ្រាន់។ នេះគឺជាតារាង Grafana សម្រាប់សេវាកម្មស៊ីភីយូ "ធម្មតា"៖ ផតទាំងអស់កំពុងប្រើប្រាស់តិចជាងស្នូលស៊ីភីយូ 3 ដែលបានស្នើសុំយ៉ាងសំខាន់៖

ការកាត់បន្ថយការស្នើសុំ CPU ពី 3000m ទៅ ~400m បង្កើនធនធានសម្រាប់បន្ទុកការងារផ្សេងទៀត និងអនុញ្ញាតឱ្យចង្កោមតូចជាង។

"ការប្រើប្រាស់ស៊ីភីយូជាមធ្យមនៃវត្ថុ EC2 ជាញឹកញាប់ដាក់ក្នុងជួរភាគរយមួយខ្ទង់" សរសេរ Corey Quinn. ខណៈពេលដែលសម្រាប់ EC2 ការប៉ាន់ប្រមាណទំហំត្រឹមត្រូវអាចជាការសម្រេចចិត្តមិនល្អការផ្លាស់ប្តូរសំណួរធនធាន Kubernetes មួយចំនួននៅក្នុងឯកសារ YAML គឺងាយស្រួល ហើយអាចនាំមកនូវការសន្សំយ៉ាងច្រើន។

ប៉ុន្តែតើយើងពិតជាចង់ឱ្យមនុស្សផ្លាស់ប្តូរតម្លៃនៅក្នុងឯកសារ YAML មែនទេ? ទេ ម៉ាស៊ីនអាចធ្វើវាបានប្រសើរជាង! Kubernetes Vertical Pod Autoscaler (VPA) ធ្វើដូចនោះ៖ សម្របសំណើធនធាន និងឧបសគ្គដោយយោងតាមបន្ទុកការងារ។ នេះគឺជាក្រាហ្វឧទាហរណ៍នៃសំណើស៊ីភីយូ Prometheus (បន្ទាត់ពណ៌ខៀវស្តើង) ដែលកែសម្រួលដោយ VPA ក្នុងរយៈពេលកន្លងមក៖

Zalando ប្រើប្រាស់ VPA នៅក្នុងក្រុមទាំងអស់របស់វា។ សម្រាប់ធាតុផ្សំនៃហេដ្ឋារចនាសម្ព័ន្ធ។ កម្មវិធីដែលមិនសំខាន់ក៏អាចប្រើ VPA ផងដែរ។

ហ្គីលហ្គោល ពី Fairwind គឺជាឧបករណ៍ដែលបង្កើត VPA សម្រាប់ការដាក់ពង្រាយនីមួយៗនៅក្នុង namespace ហើយបន្ទាប់មកបង្ហាញការណែនាំ VPA នៅលើផ្ទាំងគ្រប់គ្រងរបស់វា។ វាអាចជួយអ្នកអភិវឌ្ឍន៍កំណត់សំណើ CPU/memory ត្រឹមត្រូវសម្រាប់កម្មវិធីរបស់ពួកគេ៖

ខ្ញុំបានសរសេរតូចមួយ ប្រកាសប្លក់អំពី VPA ក្នុងឆ្នាំ 2019 ហើយថ្មីៗនេះ សហគមន៍អ្នកប្រើប្រាស់ចុងក្រោយ CNCF បានពិភាក្សាអំពីបញ្ហា VPA.

ការប្រើប្រាស់ EC2 Spot Instances

ជាចុងក្រោយ ការចំណាយលើ AWS EC2 អាចត្រូវបានកាត់បន្ថយដោយប្រើ Spot instances ជាថ្នាំងកម្មករ Kubernetes [3]. Spot instances អាច​រក​បាន​ក្នុង​ការ​បញ្ចុះ​តម្លៃ​រហូត​ដល់ 90% បើ​ធៀប​នឹង​តម្លៃ​តាម​តម្រូវការ។ ការដំណើរការ Kubernetes នៅលើ EC2 Spot គឺជាការរួមបញ្ចូលគ្នាដ៏ល្អមួយ៖ អ្នកត្រូវបញ្ជាក់ប្រភេទវត្ថុផ្សេងៗគ្នាជាច្រើនសម្រាប់ភាពអាចរកបានកាន់តែខ្ពស់ មានន័យថាអ្នកអាចទទួលបានថ្នាំងធំជាងមុនសម្រាប់តម្លៃដូចគ្នា ឬទាបជាង ហើយសមត្ថភាពកើនឡើងអាចត្រូវបានប្រើដោយបន្ទុកការងារ Kubernetes ដែលមានផ្ទុក។

តើធ្វើដូចម្តេចដើម្បីដំណើរការ Kubernetes នៅលើ EC2 Spot? មានជម្រើសជាច្រើន៖ ប្រើសេវាកម្មភាគីទីបីដូចជា SpotInst (ឥឡូវហៅថា "Spot" កុំសួរខ្ញុំពីមូលហេតុ) ឬគ្រាន់តែបន្ថែម Spot AutoScalingGroup (ASG) ទៅក្នុងចង្កោមរបស់អ្នក។ ឧទាហរណ៍ នេះ​ជា​ព័ត៌មាន​សង្ខេប CloudFormation សម្រាប់ "capacity-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"

កំណត់ចំណាំមួយចំនួនអំពីការប្រើប្រាស់ Spot ជាមួយ Kubernetes៖

• អ្នក​ត្រូវ​ដោះស្រាយ​ការ​បញ្ចប់ Spot ជា​ឧទាហរណ៍​ដោយ​ការ​បញ្ចូល​ថ្នាំង​នៅ​ពេល​វត្ថុ​ត្រូវ​បាន​បញ្ឈប់
• Zalando ប្រើ សម ការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិនូវចង្កោមជាផ្លូវការជាមួយនឹងអាទិភាពក្រុមថ្នាំង
• ថ្នាំងចំណុច អាចត្រូវបានបង្ខំ ទទួលយក "ការចុះឈ្មោះ" នៃបន្ទុកការងារដើម្បីដំណើរការនៅក្នុង Spot

សង្ខេប

ខ្ញុំសង្ឃឹមថាអ្នករកឃើញឧបករណ៍មួយចំនួនដែលបានបង្ហាញមានប្រយោជន៍ក្នុងការកាត់បន្ថយវិក្កយបត្រលើពពករបស់អ្នក។ អ្នក​អាច​ស្វែង​រក​មាតិកា​ភាគ​ច្រើន​នៃ​អត្ថបទ​ផង​ដែរ​នៅ ការពិភាក្សារបស់ខ្ញុំនៅ DevOps Gathering 2019 នៅលើ YouTube និងក្នុងស្លាយ.

តើអ្វីជាការអនុវត្តល្អបំផុតរបស់អ្នកសម្រាប់ការសន្សំការចំណាយលើពពកនៅលើ Kubernetes? សូមប្រាប់ខ្ញុំនៅ Twitter (@try_except_).

[1] តាមពិត vCPU តិចជាង 3 នឹងនៅតែអាចប្រើប្រាស់បាន ដោយសារការបញ្ជូនរបស់ថ្នាំងត្រូវបានកាត់បន្ថយដោយធនធានប្រព័ន្ធដែលបានបម្រុងទុក។ Kubernetes បែងចែករវាងសមត្ថភាពថ្នាំងរូបវន្ត និងធនធាន "ផ្តល់" (ថ្នាំងដែលអាចបែងចែកបាន។).

[2] ឧទាហរណ៍នៃការគណនា៖ មួយ m5.large instance ដែលមានអង្គចងចាំ 8 GiB គឺ ~ $84 ក្នុងមួយខែ (eu-central-1, On-Demand), i.e. ការទប់ស្កាត់ 1/8 node គឺប្រហែល ~ $10/ខែ។

[3] មានវិធីជាច្រើនទៀតដើម្បីកាត់បន្ថយវិក្កយបត្រ EC2 របស់អ្នក ដូចជាវត្ថុដែលបានបម្រុងទុក ផែនការសន្សំ។ល។

ស្វែងយល់បន្ថែមអំពីវគ្គសិក្សា។

ប្រភព: www.habr.com