AWS இல் Kubernetes கிளவுட் செலவுகளைச் சேமிக்கவும்

இக்கட்டுரையின் மொழியாக்கம் பாடநெறி தொடங்கும் தினத்தன்று தயாரிக்கப்பட்டது "குபெர்னெட்ஸை அடிப்படையாகக் கொண்ட உள்கட்டமைப்பு தளம்".

குபெர்னெட்டஸுடன் பணிபுரியும் போது கிளவுட் செலவை எவ்வாறு சேமிப்பது? சரியான தீர்வு எதுவும் இல்லை, ஆனால் உங்கள் வளங்களை மிகவும் திறம்பட நிர்வகிக்கவும் உங்கள் கிளவுட் கம்ப்யூட்டிங் செலவுகளைக் குறைக்கவும் உதவும் பல கருவிகளை இந்தக் கட்டுரை விவரிக்கிறது.

நான் இந்தக் கட்டுரையை AWS க்காக Kubernetes ஐ மனதில் கொண்டு எழுதினேன், ஆனால் இது மற்ற கிளவுட் வழங்குநர்களுக்கும் (கிட்டத்தட்ட) அதே வழியில் பொருந்தும். உங்கள் க்ளஸ்டர்(கள்) ஏற்கனவே ஆட்டோஸ்கேலிங் கட்டமைக்கப்பட்டுள்ளது என்று கருதுகிறேன் (கொத்து-தானியங்கி) ஆதாரங்களை அகற்றுவது மற்றும் உங்கள் வரிசைப்படுத்தலைக் குறைப்பது உங்கள் பணியாளர் முனைகளின் (EC2 நிகழ்வுகள்) குறைந்தால் மட்டுமே உங்கள் பணத்தை மிச்சப்படுத்தும்.

இந்த கட்டுரை உள்ளடக்கும்:

• பயன்படுத்தப்படாத வளங்களை சுத்தம் செய்தல் (குபே-காவலர்)
• வேலை செய்யாத நேரங்களில் அளவைக் குறைக்கவும் (kube-downscaler)
• கிடைமட்ட ஆட்டோஸ்கேலிங் (HPA) பயன்படுத்தி,
• அதிகப்படியான ஆதார ஒதுக்கீட்டைக் குறைத்தல் (குபே-வள-அறிக்கை, VPA)
• ஸ்பாட் நிகழ்வுகளைப் பயன்படுத்துதல்

பயன்படுத்தப்படாத வளங்களை சுத்தம் செய்தல்

வேகமான சூழலில் வேலை செய்வது மிகவும் நல்லது. தொழில்நுட்ப நிறுவனங்களை நாங்கள் விரும்புகிறோம் துரிதப்படுத்தப்பட்டது. வேகமான மென்பொருள் டெலிவரி என்பது அதிக PR வரிசைப்படுத்தல்கள், முன்னோட்ட சூழல்கள், முன்மாதிரிகள் மற்றும் பகுப்பாய்வு தீர்வுகளை குறிக்கிறது. அனைத்தும் குபெர்னெட்டஸில் பயன்படுத்தப்படுகின்றன. சோதனை வரிசைப்படுத்தல்களை கைமுறையாக சுத்தம் செய்ய யாருக்கு நேரம் இருக்கிறது? ஒரு வாரம் பழமையான பரிசோதனையை நீக்குவதை மறந்துவிடுவது எளிது. நாம் மூட மறந்த சில காரணங்களால் கிளவுட் பில் உயரும்:

(ஹென்னிங் ஜேக்கப்ஸ்:
ஜிசா:
(மேற்கோள்கள்) கோரி க்வின்:
கட்டுக்கதை: உங்கள் AWS கணக்கு என்பது உங்களிடம் உள்ள பயனர்களின் எண்ணிக்கையின் செயல்பாடாகும்.
உண்மை: உங்கள் AWS மதிப்பெண் என்பது உங்களிடம் உள்ள பொறியாளர்களின் எண்ணிக்கையின் செயல்பாடாகும்.

இவான் குர்னோசோவ் (பதில்):
உண்மையான உண்மை: உங்கள் AWS மதிப்பெண் என்பது நீங்கள் முடக்க/நீக்க மறந்த விஷயங்களின் எண்ணிக்கையாகும்.)

குபெர்னெட்ஸ் காவலாளி (kube-janitor) உங்கள் கிளஸ்டரை சுத்தம் செய்ய உதவுகிறது. காவலாளி உள்ளமைவு உலகளாவிய மற்றும் உள்ளூர் பயன்பாட்டிற்கு நெகிழ்வானது:

• க்ளஸ்டர் அளவிலான விதிகள் PR/சோதனை வரிசைப்படுத்தல்களுக்கான அதிகபட்ச நேர-நேரத்தை (TTL) வரையறுக்கலாம்.
• 7 நாட்களுக்குப் பிறகு, ஸ்பைக்/முன்மாதிரியை தானாக அகற்ற, எடுத்துக்காட்டாக, தனிப்பட்ட ஆதாரங்களை ஜானிட்டர்/டிடிஎல் மூலம் சிறுகுறிப்பு செய்யலாம்.

பொதுவான விதிகள் YAML கோப்பில் வரையறுக்கப்பட்டுள்ளன. அதன் பாதை அளவுரு வழியாக அனுப்பப்படுகிறது --rules-file kube-துவாரத்தில். அனைத்து பெயர்வெளிகளையும் அகற்றுவதற்கான எடுத்துக்காட்டு விதி இங்கே உள்ளது -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). குபெர்னெட்டஸ் ஸ்டேட்ஃபுல்செட்டை நீக்குவது அதன் நிலையான தொகுதிகளை (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

உங்கள் கிளஸ்டரை சுத்தமாக வைத்திருக்கவும், கிளவுட் கம்ப்யூட்டிங் செலவுகள் மெதுவாகக் குவிவதைத் தடுக்கவும் குபெர்னெட்ஸ் ஜானிட்டர் உதவும். வரிசைப்படுத்தல் மற்றும் உள்ளமைவு வழிமுறைகளுக்கு, பின்பற்றவும் 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, வரிசைப்படுத்தல் வழிமுறைகள் மற்றும் கூடுதல் விருப்பங்களில் நீங்கள் ஆர்வமாக இருந்தால்.

கிடைமட்ட ஆட்டோஸ்கேலிங் பயன்படுத்தவும்

பல பயன்பாடுகள்/சேவைகள் டைனமிக் லோடிங் பேட்டர்னைக் கையாளுகின்றன: சில நேரங்களில் அவற்றின் தொகுதிகள் செயலற்றதாக இருக்கும், சில சமயங்களில் அவை முழுத் திறனில் வேலை செய்யும். அதிகபட்ச உச்ச சுமையை சமாளிக்க நிரந்தர காய்களை இயக்குவது சிக்கனமானது அல்ல. குபெர்னெட்ஸ் ஒரு ஆதாரம் முழுவதும் கிடைமட்ட தானாக அளவிடுதலை ஆதரிக்கிறது கிடைமட்டPodAutoscaler (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) என்பது குபெர்னெட்ஸிற்கான ஒரு பொதுவான அளவீட்டு அடாப்டர் ஆகும், இது காய்களின் கிடைமட்ட தன்னியக்க அளவீடுகளுக்கான தனிப்பயன் மற்றும் வெளிப்புற அளவீடுகளை சேகரித்து வழங்க முடியும். இது 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 க்கான பரிந்துரைகளுடன் விளக்கக்காட்சி உள்ளது: உங்கள் பணப்பையை அல்ல, உங்கள் வரிசைப்படுத்தல்களை அளவிடவும்.

வளங்களை அதிகமாக முன்பதிவு செய்வதைக் குறைக்கவும்

குபெர்னெட்ஸ் பணிச்சுமைகள் "வளக் கோரிக்கைகள்" மூலம் அவர்களின் CPU/நினைவகத் தேவைகளைத் தீர்மானிக்கின்றன. CPU ஆதாரங்கள் மெய்நிகர் கோர்களில் அல்லது பொதுவாக "மில்லிகோர்களில்" அளவிடப்படுகின்றன, உதாரணமாக 500m என்பது 50% vCPU ஐக் குறிக்கிறது. நினைவக வளங்கள் பைட்டுகளில் அளவிடப்படுகின்றன, மேலும் 500Mi போன்ற பொதுவான பின்னொட்டுகளைப் பயன்படுத்தலாம், அதாவது 500 மெகாபைட்கள். 1000 vCPU களைக் கொண்ட ஒரு முனையில் 4m CPU கோரிக்கையைக் கொண்ட ஒரு பாட், மற்ற காய்களுக்கு 3 vCPU கள் மட்டுமே கிடைக்கும். [1]

மந்தமான (அதிகப்படியான இருப்பு) கோரப்பட்ட வளங்களுக்கும் உண்மையான பயன்பாட்டிற்கும் உள்ள வித்தியாசம். எடுத்துக்காட்டாக, 2 GiB நினைவகத்தைக் கோரும் ஆனால் 200 MiB மட்டுமே பயன்படுத்தும் ஒரு பாட் ~1,8 GiB "அதிகப்படியான" நினைவகத்தைக் கொண்டுள்ளது. அதிகப்படியான பணம் செலவாகும். 1 GiB தேவையற்ற நினைவகத்திற்கு மாதத்திற்கு ~$10 செலவாகும் என்று ஒருவர் தோராயமாக மதிப்பிடலாம். [2]

குபெர்னெட்ஸ் வள அறிக்கை (kube-resource-report) அதிகப்படியான இருப்புக்களைக் காட்டுகிறது மற்றும் சேமிப்பு திறனைக் கண்டறிய உங்களுக்கு உதவும்:

குபெர்னெட்ஸ் வள அறிக்கை பயன்பாடு மற்றும் கட்டளை மூலம் திரட்டப்பட்ட அதிகப்படியானதைக் காட்டுகிறது. இது வள தேவைகளைக் குறைக்கக்கூடிய இடங்களைக் கண்டறிய உங்களை அனுமதிக்கிறது. உருவாக்கப்பட்ட HTML அறிக்கை வள பயன்பாட்டின் ஸ்னாப்ஷாட்டை மட்டுமே வழங்குகிறது. போதுமான ஆதார கோரிக்கைகளைத் தீர்மானிக்க, காலப்போக்கில் CPU/மெமரி பயன்பாட்டைப் பார்க்க வேண்டும். "வழக்கமான" CPU-கடுமையான சேவைக்கான Grafana விளக்கப்படம் இங்கே உள்ளது: அனைத்து காய்களும் கோரப்பட்ட 3 CPU கோர்களை விட கணிசமாக குறைவாகவே பயன்படுத்துகின்றன:

CPU கோரிக்கையை 3000m முதல் ~400m வரை குறைப்பது மற்ற பணிச்சுமைகளுக்கான ஆதாரங்களை விடுவிக்கிறது மற்றும் கிளஸ்டர் சிறியதாக இருக்க அனுமதிக்கிறது.

"EC2 நிகழ்வுகளின் சராசரி CPU பயன்பாடு பெரும்பாலும் ஒற்றை இலக்க சதவீத வரம்பில் வட்டமிடுகிறது" கோரி க்வின் எழுதுகிறார். EC2 க்கான போது சரியான அளவை மதிப்பிடுவது தவறான முடிவாக இருக்கலாம்YAML கோப்பில் சில Kubernetes ஆதார வினவல்களை மாற்றுவது எளிதானது மற்றும் பெரிய சேமிப்பைக் கொண்டுவரலாம்.

ஆனால் YAML கோப்புகளில் மக்கள் மதிப்புகளை மாற்றுவதை நாங்கள் உண்மையில் விரும்புகிறோமா? இல்லை, இயந்திரங்கள் அதை சிறப்பாக செய்ய முடியும்! குபெர்னெட்ஸ் செங்குத்து பாட் ஆட்டோஸ்கேலர் (VPA) அதைச் செய்கிறது: பணிச்சுமைக்கு ஏற்ப ஆதார கோரிக்கைகள் மற்றும் கட்டுப்பாடுகளை மாற்றியமைக்கிறது. காலப்போக்கில் VPA ஆல் மாற்றியமைக்கப்பட்ட Prometheus CPU கோரிக்கைகளின் (மெல்லிய நீலக் கோடு) எடுத்துக்காட்டு வரைபடம் இங்கே:

Zalando அதன் அனைத்து கிளஸ்டர்களிலும் VPA ஐப் பயன்படுத்துகிறது உள்கட்டமைப்பு கூறுகளுக்கு. முக்கியமற்ற பயன்பாடுகளும் VPA ஐப் பயன்படுத்தலாம்.

பொன் நிற தலை மயிர் Fairwind என்பது ஒரு பெயர்வெளியில் ஒவ்வொரு வரிசைப்படுத்தலுக்கும் VPA ஐ உருவாக்கி அதன் டாஷ்போர்டில் VPA பரிந்துரையைக் காண்பிக்கும் ஒரு கருவியாகும். டெவலப்பர்கள் தங்கள் பயன்பாடுகளுக்கான சரியான CPU/மெமரி கோரிக்கைகளை அமைக்க இது உதவும்:

நான் சிறியதாக எழுதினேன் VPA பற்றிய blogpost 2019 இல், மற்றும் சமீபத்தில் CNCF இறுதிப் பயனர் சமூகம் VPA சிக்கலைப் பற்றி விவாதித்தது.

EC2 ஸ்பாட் நிகழ்வுகளைப் பயன்படுத்துதல்

கடைசியாக ஆனால் குறைந்தது அல்ல, ஸ்பாட் நிகழ்வுகளை குபெர்னெட்ஸ் தொழிலாளர் முனைகளாகப் பயன்படுத்துவதன் மூலம் AWS EC2 செலவுகளைக் குறைக்கலாம் [3]. தேவைக்கேற்ப விலைகளுடன் ஒப்பிடும்போது ஸ்பாட் நிகழ்வுகள் 90% வரை தள்ளுபடியில் கிடைக்கும். EC2 Spot இல் Kubernetes ஐ இயக்குவது ஒரு நல்ல கலவையாகும்: அதிக கிடைக்கும் தன்மைக்கு நீங்கள் பல்வேறு நிகழ்வு வகைகளைக் குறிப்பிட வேண்டும், அதாவது நீங்கள் அதே அல்லது குறைந்த விலையில் பெரிய முனையைப் பெறலாம், மேலும் அதிக திறன் கொண்ட Kubernetes பணிச்சுமைகளால் பயன்படுத்தப்படலாம்.

EC2 ஸ்பாட்டில் குபெர்னெட்ஸை எவ்வாறு இயக்குவது? பல விருப்பங்கள் உள்ளன: 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"

குபெர்னெட்டஸுடன் ஸ்பாட்டைப் பயன்படுத்துவது பற்றிய சில குறிப்புகள்:

• ஸ்பாட் டெர்மினேஷன்களை நீங்கள் கையாள வேண்டும், உதாரணமாக நிகழ்வை நிறுத்தும்போது முனையை இணைப்பதன் மூலம்
• Zalando பயன்படுத்துகிறது முள் கரண்டி நோட் பூல் முன்னுரிமைகளுடன் அதிகாரப்பூர்வ கிளஸ்டர் ஆட்டோஸ்கேலிங்
• புள்ளி முனைகள் கட்டாயப்படுத்த முடியும் ஸ்பாட்டில் இயக்க பணிச்சுமைகளின் "பதிவுகளை" ஏற்கவும்

சுருக்கம்

உங்கள் கிளவுட் பில்லைக் குறைக்க, வழங்கப்பட்ட சில கருவிகள் உங்களுக்கு பயனுள்ளதாக இருக்கும் என்று நம்புகிறேன். கட்டுரையின் பெரும்பாலான உள்ளடக்கங்களையும் நீங்கள் காணலாம் YouTube மற்றும் ஸ்லைடுகளில் DevOps Gathering 2019 இல் எனது பேச்சு.

குபெர்னெட்ஸில் கிளவுட் செலவுகளைச் சேமிப்பதற்கான உங்கள் சிறந்த நடைமுறைகள் யாவை? தயவு செய்து எனக்கு தெரியப்படுத்துங்கள் Twitter (@try_except_).

[1] உண்மையில், முன்பதிவு செய்யப்பட்ட கணினி ஆதாரங்களால் கணுவின் செயல்திறன் குறைக்கப்படுவதால், 3க்கும் குறைவான vCPUகள் பயன்படுத்தக்கூடியதாக இருக்கும். குபெர்னெட்ஸ் இயற்பியல் முனை திறன் மற்றும் "வழங்கப்பட்ட" வளங்களை வேறுபடுத்துகிறார் (கணு ஒதுக்கக்கூடியது).

[2] கணக்கீட்டு எடுத்துக்காட்டு: ஒரு m5. 8 GiB நினைவகம் கொண்ட ஒரு பெரிய நிகழ்வு மாதத்திற்கு ~$84 ​​(eu-central-1, On-Demand), அதாவது. 1/8 முனையைத் தடுப்பது தோராயமாக ~$10/மாதம் ஆகும்.

[3] முன்பதிவு செய்யப்பட்ட நிகழ்வுகள், சேமிப்புத் திட்டம் போன்ற உங்களின் EC2 பில்லைக் குறைக்க இன்னும் பல வழிகள் உள்ளன - அந்தத் தலைப்புகளை நான் இங்கு விவரிக்க மாட்டேன், ஆனால் நீங்கள் கண்டிப்பாக அவற்றைப் பார்க்க வேண்டும்!

படிப்பைப் பற்றி மேலும் அறிக.

ஆதாரம்: www.habr.com