AWS මත Kubernetes වලාකුළු වියදම් මත ඉතිරි කරන්න

පාඨමාලා ආරම්භයට ආසන්න දිනක ලිපියේ පරිවර්තනය සකස් කරන ලදී "Kubernetes මත පදනම් වූ යටිතල පහසුකම් වේදිකාව".

Kubernetes සමඟ වැඩ කිරීමේදී වලාකුළු පිරිවැය ඉතිරි කර ගන්නේ කෙසේද? තනි නිවැරදි විසඳුමක් නොමැත, නමුත් මෙම ලිපිය ඔබට ඔබේ සම්පත් වඩාත් ඵලදායී ලෙස කළමනාකරණය කිරීමට සහ ඔබේ වලාකුළු පරිගණක පිරිවැය අඩු කිරීමට උපකාර වන මෙවලම් කිහිපයක් විස්තර කරයි.

මම AWS සඳහා Kubernetes මනසේ තබාගෙන මෙම ලිපිය ලිව්වෙමි, නමුත් එය අනෙකුත් වලාකුළු සපයන්නන්ට (පාහේ) හරියටම අදාළ වනු ඇත. මම උපකල්පනය කරන්නේ ඔබේ පොකුරු(ය) දැනටමත් ස්වයං පරිමාණය වින්‍යාස කර ඇති බවයි (පොකුරු-ස්වයං පරිමාණය) සම්පත් ඉවත් කිරීම සහ ඔබේ යෙදවීම අඩු කිරීම ඔබේ මුදල් ඉතිරි කරන්නේ එය ඔබේ සේවක නෝඩ් (EC2 අවස්ථා) අඩු කරන්නේ නම් පමණි.

මෙම ලිපිය ආවරණය කරනු ඇත:

• භාවිතයට නොගත් සම්පත් පිරිසිදු කිරීම (kube-janitor)
• වැඩ නොකරන වේලාවන්හිදී පරිමාණය අඩු කරන්න (kube-downscaler)
• තිරස් ස්වයං පරිමාණය (HPA) භාවිතා කිරීම
• අධික සම්පත් වෙන්කිරීම් අඩු කිරීම (kube-සම්පත්-වාර්තාව, VPA)
• Spot අවස්ථා භාවිතා කිරීම

භාවිතයට නොගත් සම්පත් පිරිසිදු කිරීම

වේගවත් පරිසරයක වැඩ කිරීම විශිෂ්ටයි. අපට තාක්ෂණික සංවිධාන අවශ්‍යයි වේගවත් කර ඇත. වේගවත් මෘදුකාංග බෙදාහැරීම යනු තවත් PR යෙදවීම්, පෙරදසුන් පරිසරයන්, මූලාකෘති සහ විශ්ලේෂණ විසඳුම් ය. සෑම දෙයක්ම Kubernetes මත යොදවා ඇත. පරීක්ෂණ යෙදවීම් අතින් පිරිසිදු කිරීමට කාලය ඇත්තේ කාටද? සතියක් පැරණි අත්හදා බැලීමක් මකා දැමීම අමතක කිරීම පහසුය. අපට වසා දැමීමට අමතක වූ දෙයක් හේතුවෙන් වලාකුළු බිල්පත ඉහළ යනු ඇත:

(Henning Jacobs:
Zhiza:
(උපුටා දැක්වීම්) Corey Quinn:
මිථ්‍යාව: ඔබේ AWS ගිණුම ඔබට ඇති පරිශීලකයින් සංඛ්‍යාවේ කාර්යයකි.
සත්‍යය: ඔබේ AWS ලකුණු යනු ඔබ සතු ඉංජිනේරුවන් සංඛ්‍යාවේ ශ්‍රිතයකි.

Ivan Kurnosov (ප්රතිචාර වශයෙන්):
සැබෑ සත්‍යය: ඔබේ AWS ලකුණු යනු ඔබට අබල කිරීමට/මකා දැමීමට අමතක වූ දේවල් ගණනේ ශ්‍රිතයකි.)

Kubernetes Janitor (kube-janitor) ඔබේ පොකුර පිරිසිදු කිරීමට උපකාරී වේ. මුරකරු වින්‍යාසය ගෝලීය සහ දේශීය භාවිතය සඳහා නම්‍යශීලී වේ:

• PR/පරීක්ෂණ යෙදවීම් සඳහා පොකුරු-පුළුල් රීති වලට ජීවත් වීමට උපරිම කාලය (TTL) අර්ථ දැක්විය හැක.
• දින 7කට පසු ස්පයික්/මූලාකෘතිය ස්වයංක්‍රීයව ඉවත් කිරීමට උදාහරණයක් ලෙස, තනි පුද්ගල සම්පත් janitor/ttl සමඟින් සටහන් කළ හැක.

සාමාන්‍ය රීති YAML ගොනුවේ අර්ථ දක්වා ඇත. එහි මාර්ගය පරාමිතිය හරහා ගමන් කරයි --rules-file kube-janitor දී. සියලුම නාම අවකාශයන් ඉවත් කිරීමට උදාහරණ රීතියක් මෙන්න -pr- දින දෙකකට පසු නමින්:

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

පහත උදාහරණය 2020 දී සියලුම නව Deployments/StatefulSets සඳහා Deployment සහ StatefulSet Pods මත යෙදුම් ලේබලය භාවිතය නියාමනය කරයි, නමුත් ඒ සමඟම සතියක් සඳහා මෙම ලේබලය නොමැතිව පරීක්ෂණ ක්‍රියාත්මක කිරීමට ඉඩ ලබා දේ:

- 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ක් සඳහා කාල සීමා සහිත demo ධාවනය කරන්න:

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

පිරිවැය වැඩිවීමේ තවත් ප්‍රභවයක් වන්නේ අඛණ්ඩ පරිමාවන් (AWS EBS) ය. Kubernetes StatefulSet එකක් මකා දැමීමෙන් එහි ස්ථීර වෙළුම් (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.

වැඩ නොකරන වේලාවන්හිදී පරිමාණය අඩු කරන්න

පරීක්ෂණ සහ වේදිකා පද්ධති සාමාන්‍යයෙන් ක්‍රියාත්මක වීමට අවශ්‍ය වන්නේ ව්‍යාපාරික වේලාවන් තුළ පමණි. පසු කාර්යාල/පරිපාලක මෙවලම් වැනි සමහර නිෂ්පාදන යෙදුම් සඳහාද අවශ්‍ය වන්නේ සීමිත ලබා ගැනීමක් පමණක් වන අතර එක රැයකින් අක්‍රිය කළ හැක.

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). 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 (kube-metrics-adapter) යනු Kubernetes සඳහා වන සාමාන්‍ය ප්‍රමිතික ඇඩැප්ටරයකි, එය කරල්වල තිරස් ස්වයං පරිමාණය සඳහා අභිරුචි සහ බාහිර ප්‍රමිතික එකතු කර සේවය කළ හැකිය. එය Prometheus මෙට්‍රික්ස්, 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 සඳහා ඔවුන්ගේ අත්දැකීම් සහ නිර්දේශ සමඟ ඉදිරිපත් කිරීමක් ඇත: ඔබේ මුදල් පසුම්බිය නොව ඔබේ යෙදවීම් පරිමාණය කරන්න.

සම්පත් වැඩිපුර වෙන් කිරීම අඩු කරන්න

Kubernetes වැඩ බර "සම්පත් ඉල්ලීම්" හරහා ඔවුන්ගේ CPU/මතක අවශ්‍යතා තීරණය කරයි. CPU සම්පත් මනිනු ලබන්නේ අතථ්‍ය මධ්‍ය වලින් හෝ වඩාත් බහුලව "මිලිකෝර්" වලින්, උදාහරණයක් ලෙස 500m යන්නෙන් 50% vCPU අදහස් වේ. මතක සම්පත් බයිට් වලින් මනිනු ලබන අතර, 500Mi වැනි පොදු උපසර්ග භාවිතා කළ හැක, එනම් මෙගාබයිට් 500 කි. සම්පත් ඉල්ලීම් සේවක නෝඩ් වල ධාරිතාව "අගුළු දැමීම", එනම් vCPUs 1000ක් සහිත node එකක් මත 4m CPU ඉල්ලීමක් සහිත පොඩ් එකක් අනෙකුත් කරල් සඳහා ඉතිරි වන්නේ vCPU 3ක් පමණි. [1]

ස්ලැක් (අතිරික්ත සංචිත) ඉල්ලූ සම්පත් සහ සැබෑ භාවිතය අතර වෙනස වේ. උදාහරණයක් ලෙස, 2 GiB මතකයක් ඉල්ලා සිටින නමුත් 200 MiB පමණක් භාවිතා කරන පොඩ් එකක "අතිරික්ත" මතකය ~1,8 GiB ඇත. අතිරික්ත මුදල් වැය වේ. 1 GiB අතිරික්ත මතකයක් සඳහා මසකට ~$10ක් වැය වන බව කෙනෙකුට දළ වශයෙන් ඇස්තමේන්තු කළ හැක. [2]

Kubernetes සම්පත් වාර්තාව (kube-resource-report) අතිරික්ත සංචිත ප්‍රදර්ශනය කරන අතර ඉතිරිකිරීමේ හැකියාව තීරණය කිරීමට ඔබට උපකාර කළ හැක:

Kubernetes සම්පත් වාර්තාව යෙදුම සහ විධානය මගින් එකතු කරන ලද අතිරික්තය පෙන්වයි. සම්පත් ඉල්ලුම අඩු කළ හැකි ස්ථාන සොයා ගැනීමට මෙය ඔබට ඉඩ සලසයි. උත්පාදනය කරන ලද HTML වාර්තාව සම්පත් භාවිතයේ සැණෙපොතක් පමණක් සපයයි. ප්‍රමාණවත් සම්පත් ඉල්ලීම් තීරණය කිරීම සඳහා ඔබ කාලයත් සමඟ CPU/මතක භාවිතය දෙස බැලිය යුතුය. මෙන්න "සාමාන්‍ය" CPU-බර සේවාවක් සඳහා Grafana ප්‍රස්ථාරයක්: සියලුම කරල් ඉල්ලූ CPU මධ්‍ය 3 ට වඩා සැලකිය යුතු තරම් අඩුවෙන් භාවිතා කරයි:

CPU ඉල්ලීම 3000m සිට ~400m දක්වා අඩු කිරීම අනෙකුත් වැඩ බර සඳහා සම්පත් නිදහස් කරන අතර පොකුර කුඩා වීමට ඉඩ සලසයි.

"EC2 නිදසුන්වල සාමාන්‍ය CPU භාවිතය බොහෝ විට තනි ඉලක්කම් ප්‍රතිශත පරාසයක පවතී" Corey Quinn ලියයි. EC2 සඳහා අතරතුර නිවැරදි ප්රමාණය තක්සේරු කිරීම නරක තීරණයක් විය හැකියYAML ගොනුවක සමහර Kubernetes සම්පත් විමසුම් වෙනස් කිරීම පහසු වන අතර විශාල ඉතුරුම් ලබා ගත හැක.

නමුත් YAML ගොනු වල අගයන් වෙනස් කරන පුද්ගලයින් අපට සැබවින්ම අවශ්‍යද? නැත, යන්ත්‍රවලට එය වඩා හොඳින් කළ හැකිය! කුබර්නෙටස් සිරස් Pod Autoscaler (VPA) එය සිදු කරයි: වැඩ බර අනුව සම්පත් ඉල්ලීම් සහ සීමාවන් අනුවර්තනය කරයි. කාලයත් සමඟ VPA විසින් අනුවර්තනය කරන ලද Prometheus CPU ඉල්ලීම්වල (තුනී නිල් රේඛාව) උදාහරණ ප්‍රස්ථාරයක් මෙන්න:

Zalando එහි සියලුම පොකුරු වල VPA භාවිතා කරයි යටිතල පහසුකම් සංරචක සඳහා. විවේචනාත්මක නොවන යෙදුම් ද VPA භාවිතා කළ හැක.

ගෝල්ඩිලොක්ස් Fairwind වෙතින් යනු නාම අවකාශයක එක් එක් යෙදවීම සඳහා VPA නිර්මාණය කර එහි උපකරණ පුවරුවේ VPA නිර්දේශයක් පෙන්වන මෙවලමකි. එය සංවර්ධකයින්ට ඔවුන්ගේ යෙදුම් සඳහා නිවැරදි CPU/මතක ඉල්ලීම් සැකසීමට උදවු කළ හැක:

මම පොඩි එකක් ලිව්වා VPA ගැන blogpost 2019 දී සහ මෑතකදී CNCF අවසන් පරිශීලක ප්‍රජාව VPA ගැටලුව සාකච්ඡා කළේය.

EC2 Spot අවස්ථා භාවිතා කිරීම

අවසාන වශයෙන් නොව අවම වශයෙන්, AWS EC2 පිරිවැය Kubernetes සේවක නෝඩ් ලෙස Spot අවස්ථා භාවිතා කිරීමෙන් අඩු කළ හැක. [3]. ඉල්ලුම මත මිල ගණන්වලට සාපේක්ෂව ස්ථානීය අවස්ථා 90% දක්වා වට්ටමක් ලබා ගත හැකිය. EC2 Spot මත Kubernetes ධාවනය කිරීම හොඳ සංයෝජනයකි: ඔබට වැඩි ලබා ගත හැකි අවස්ථා සඳහා විවිධ අවස්ථා වර්ග කිහිපයක් සඳහන් කිරීමට අවශ්‍ය වේ, එනම් ඔබට විශාල node එකක් සමාන හෝ අඩු මිලකට ලබා ගත හැකි අතර වැඩි ධාරිතාවය බහාලුම් කළ Kubernetes වැඩ බර මගින් භාවිතා කළ හැක.

EC2 Spot මත Kubernetes ධාවනය කරන්නේ කෙසේද? විකල්ප කිහිපයක් තිබේ: SpotInst වැනි තෙවන පාර්ශ්ව සේවාවක් භාවිතා කරන්න (දැන් "Spot" ලෙස හැඳින්වේ, ඇයි මගෙන් අහන්න එපා) හෝ ඔබේ පොකුරට 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"

Kubernetes සමඟ Spot භාවිතා කිරීම පිළිබඳ සමහර සටහන්:

• ඔබට Spot terminations හැසිරවීමට අවශ්‍ය වේ, උදාහරණයක් ලෙස එම අවස්ථාව නැවැත්වූ විට node එක ඒකාබද්ධ කිරීමෙන්
• Zalando භාවිතා කරයි දෙබලක නෝඩ් සංචිත ප්‍රමුඛතා සහිත නිල පොකුරු ස්වයංක්‍රීය පරිමාණය
• පැල්ලම් නෝඩ් බල කළ හැක Spot හි ධාවනය කිරීමට වැඩ බර "ලියාපදිංචි කිරීම්" පිළිගන්න

සාරාංශය

ඔබගේ වලාකුළු බිල්පත අඩු කිරීම සඳහා ඉදිරිපත් කර ඇති සමහර මෙවලම් ප්‍රයෝජනවත් වනු ඇතැයි මම බලාපොරොත්තු වෙමි. ඔබට ලිපියේ බොහෝ අන්තර්ගතයන් ද සොයාගත හැකිය YouTube සහ slides හි DevOps Gathering 2019 හි මගේ කතාව.

Kubernetes හි ක්ලවුඩ් පිරිවැය ඉතිරි කිරීම සඳහා ඔබේ හොඳම භාවිතයන් මොනවාද? කරුණාකර මට දන්වන්න Twitter (@ try_except_).

[1] ඇත්ත වශයෙන්ම, සංචිත පද්ධති සම්පත් මගින් නෝඩයේ ප්‍රතිදානය අඩු වන බැවින් vCPU 3කට වඩා අඩු ප්‍රමාණයක් භාවිත කළ හැකි වනු ඇත. Kubernetes භෞතික නෝඩ් ධාරිතාව සහ "ප්‍රතිපාදන" සම්පත් අතර වෙනස හඳුනා ගනී (නෝඩ් වෙන් කළ හැකිය).

[2] ගණනය කිරීමේ උදාහරණය: 5 GiB මතකයක් සහිත එක් m8. විශාල අවස්ථාවක් මසකට ~$84 ​​(eu-central-1, On-Demand), i.e. 1/8 නෝඩය අවහිර කිරීම දළ වශයෙන් ~$10/මසකට වේ.

[3] ඔබේ EC2 බිල්පත අඩු කිරීමට තවත් බොහෝ ක්‍රම තිබේ, එනම් වෙන් කළ අවස්ථා, ඉතුරුම් සැලැස්ම යනාදිය - මම එම මාතෘකා මෙහි ආවරණය නොකරමි, නමුත් ඔබ අනිවාර්යයෙන්ම ඒවා සොයා බැලිය යුතුය!

පාඨමාලාව ගැන තව දැනගන්න.

මූලාශ්රය: www.habr.com