Խնայեք Kubernetes ամպային ծախսերը AWS-ում

Հոդվածի թարգմանությունը պատրաստվել է դասընթացի մեկնարկի նախօրեին «Կուբերնետեսի վրա հիմնված ենթակառուցվածքային հարթակ».

Ինչպե՞ս խնայել ամպային ծախսերը Kubernetes-ի հետ աշխատելիս: Չկա մեկ ճիշտ լուծում, բայց այս հոդվածը նկարագրում է մի քանի գործիքներ, որոնք կարող են օգնել ձեզ ավելի արդյունավետ կառավարել ձեր ռեսուրսները և նվազեցնել ձեր ամպային հաշվողական ծախսերը:

Ես գրել եմ այս հոդվածը՝ նկատի ունենալով Kubernetes-ը AWS-ի համար, բայց այն կկիրառվի (գրեթե) ճիշտ նույն կերպ այլ ամպային մատակարարների համար: Ես ենթադրում եմ, որ ձեր կլաստեր(ներ)ն արդեն կազմաձևված է ավտոմատ մասշտաբավորման (cluster-autoscaler) Ռեսուրսների հեռացումը և ձեր տեղակայումը նվազեցնելը միայն կխնայի ձեզ գումար, եթե այն նաև նվազեցնի ձեր աշխատանքային հանգույցների նավատորմը (EC2 օրինակներ):

Այս հոդվածը կներառի.

• չօգտագործված ռեսուրսների մաքրում (կուբե-դռնապան)
• Նվազեցնել մասշտաբները ոչ աշխատանքային ժամերին (kube-downscaler)
• օգտագործելով հորիզոնական ավտոմատ մասշտաբավորում (HPA),
• ավելորդ ռեսուրսների վերապահումների կրճատում (kube-resource-report, VPA)
• օգտագործելով Spot օրինակները

Չօգտագործված ռեսուրսների մաքրում

Արագ տեմպերով միջավայրում աշխատելը հիանալի է: Մենք ուզում ենք տեխնոլոգիական կազմակերպություններ արագացված. Ծրագրային ապահովման ավելի արագ առաքումը նաև նշանակում է ավելի շատ PR տեղակայում, նախադիտման միջավայրեր, նախատիպեր և վերլուծական լուծումներ: Ամեն ինչ տեղադրված է Kubernetes-ում: Ո՞վ ժամանակ ունի ձեռքով մաքրելու թեստային տեղակայումները: Հեշտ է մոռանալ շաբաթական փորձը ջնջելու մասին: Ամպային հաշիվը կբարձրանա այն պատճառով, որ մենք մոռացել ենք փակել.

(Հենինգ Ջեյքոբս.
Ժիզա.
(մեջբերումներ) Քորի Քուին.
Առասպել. Ձեր AWS հաշիվը ձեր ունեցած օգտատերերի թվի ֆունկցիան է:
Փաստ. Ձեր AWS միավորը ձեր ունեցած ինժեներների թվի ֆունկցիան է:

Իվան Կուրնոսով (ի պատասխան).
Իրական փաստ. Ձեր AWS միավորը կախված է այն բաների քանակից, որոնք մոռացել եք անջատել/ջնջել:)

Կուբերնետեսի դռնապան (kube-banitor) օգնում է մաքրել ձեր կլաստերը: Դռնապանի կոնֆիգուրացիան ճկուն է ինչպես գլոբալ, այնպես էլ տեղական օգտագործման համար.

• Կլաստերային կանոնները կարող են սահմանել PR/փորձարկման տեղակայման առավելագույն ժամկետը (TTL):
• Առանձին ռեսուրսները կարող են ծանոթագրվել janitor/ttl-ով, օրինակ՝ 7 օր հետո հասկը/նախատիպը ավտոմատ կերպով հեռացնելու համար:

Ընդհանուր կանոնները սահմանված են YAML ֆայլում: Դրա ուղին անցնում է պարամետրով --rules-file կուբե-դռնապանի մեջ։ Ահա բոլոր անվանատարածքները հեռացնելու օրինակելի կանոն -pr- երկու օր հետո անունով.

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

Հետևյալ օրինակը կարգավորում է կիրառական պիտակի օգտագործումը Deployment և StatefulSet pods-ի բոլոր նոր տեղակայումների/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-երը մաքրելու հատկություն: Օրինակ, այս կանոնը կհեռացնի բոլոր PVC-ները, որոնք տեղադրված չեն մոդուլով և որոնք չեն հղում 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-banitor.

Նվազեցրեք մասշտաբները ոչ աշխատանքային ժամերին

Փորձարկման և փուլային համակարգերը սովորաբար պետք է գործեն միայն աշխատանքային ժամերին: Որոշ արտադրական հավելվածներ, ինչպիսիք են back office/admin գործիքները, նույնպես պահանջում են սահմանափակ հասանելիություն և կարող են անջատվել մեկ գիշերվա ընթացքում:

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 blank:

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 ադապտեր (kube-metrics-adapter) ընդհանուր չափման ադապտեր է Kubernetes-ի համար, որը կարող է հավաքել և մատուցել հատուկ և արտաքին չափումներ՝ պատիճների հորիզոնական ավտոմատ մասշտաբավորման համար: Այն աջակցում է մասշտաբավորմանը՝ հիմնված Պրոմեթևսի չափումների, 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/հիշողության կարիքները «ռեսուրսների հարցումների» միջոցով: CPU-ի ռեսուրսները չափվում են վիրտուալ միջուկներով կամ ավելի հաճախ «միլիկորներով», օրինակ 500 մ-ը ենթադրում է 50% vCPU: Հիշողության ռեսուրսները չափվում են բայթերով, և կարող են օգտագործվել սովորական վերջածանցներ, օրինակ՝ 500Mi, ինչը նշանակում է 500 մեգաբայթ: Ռեսուրսների հարցումների «կողպման» հզորությունը աշխատող հանգույցների վրա, ինչը նշանակում է, որ 1000 vCPU ունեցող հանգույցի վրա 4 մ պրոցեսորի հարցումով պատիճը հասանելի կթողնի միայն 3 vCPU-ն այլ հանգույցների համար: [1]

Թուլություն (ավելորդ պահուստ) պահանջվող ռեսուրսների և իրական օգտագործման միջև տարբերությունն է: Օրինակ, մի պատիճ, որը պահանջում է 2 ԳԲ հիշողություն, բայց օգտագործում է միայն 200 ՄԲ, ունի ~1,8 ԳԲ «ավելորդ» հիշողություն: Ավելորդ գումարը ծախսում է: Մոտավորապես կարելի է գնահատել, որ 1 ԳԲ ավելորդ հիշողության արժեքը ամսական 10 դոլար է: [2]

Kubernetes ռեսուրսների հաշվետվություն (kube-resource-report) ցուցադրում է ավելցուկային պահուստները և կարող է օգնել ձեզ որոշել խնայողությունների ներուժը.

Kubernetes ռեսուրսների հաշվետվություն ցույց է տալիս հավելվածով և հրամանով ագրեգացված ավելցուկը: Սա թույլ է տալիս գտնել այնպիսի վայրեր, որտեղ ռեսուրսների պահանջարկը կարող է կրճատվել: Ստեղծված HTML հաշվետվությունը տրամադրում է միայն ռեսուրսների օգտագործման պատկերը: Դուք պետք է դիտարկեք պրոցեսորի/հիշողության օգտագործումը ժամանակի ընթացքում՝ համապատասխան ռեսուրսների հարցումները որոշելու համար: Ահա Grafana աղյուսակը «սովորական» պրոցեսորով ծանրաբեռնված ծառայության համար. բոլոր բլոկները զգալիորեն ավելի քիչ են օգտագործում, քան պահանջվող 3 պրոցեսորի միջուկները.

CPU-ի պահանջը 3000 մ-ից մինչև ~400 մ կրճատելը ազատում է ռեսուրսները այլ ծանրաբեռնվածության համար և թույլ է տալիս, որ կլաստերը փոքր լինի:

«EC2 օրինակների միջին պրոցեսորի օգտագործումը հաճախ սավառնում է միանիշ տոկոսային միջակայքում», գրում է Քորի Քուինը. Մինչդեռ EC2-ի համար ճիշտ չափը գնահատելը կարող է վատ որոշում լինելKubernetes-ի որոշ ռեսուրսների հարցումներ փոխելը YAML ֆայլում հեշտ է և կարող է հսկայական խնայողություններ բերել:

Բայց մենք իսկապես ուզում ենք, որ մարդիկ փոխեն արժեքները YAML ֆայլերում: Ոչ, մեքենաները կարող են դա անել շատ ավելի լավ: Կուբերնետես Ուղղահայաց pod Autoscaler (VPA) անում է հենց դա՝ հարմարեցնում է ռեսուրսների հարցումները և սահմանափակումները՝ ըստ ծանրաբեռնվածության: Ահա Պրոմեթևսի պրոցեսորի հարցումների օրինակելի գրաֆիկ (բարակ կապույտ գիծ), որը հարմարեցվել է VPA-ի կողմից ժամանակի ընթացքում.

Zalando-ն օգտագործում է VPA-ն իր բոլոր կլաստերներում ենթակառուցվածքի բաղադրիչների համար։ Ոչ կարևոր հավելվածները կարող են նաև օգտագործել VPA:

Goldilocks Fairwind-ից գործիք է, որը ստեղծում է VPA յուրաքանչյուր տեղակայման համար անվանատարածքում, այնուհետև ցուցադրում է VPA-ի առաջարկությունն իր վահանակի վրա: Այն կարող է օգնել մշակողներին սահմանել ճիշտ CPU/հիշողության հարցումներ իրենց հավելվածների համար.

Ես մի փոքրիկ գրեցի բլոգային գրառում VPA-ի մասին 2019 թվականին, իսկ վերջերս՝ XNUMXթ CNCF վերջնական օգտագործողների համայնքը քննարկել է VPA-ի հարցը.

Օգտագործելով EC2 Spot օրինակներ

Վերջին, բայց ոչ պակաս կարևորը, AWS EC2-ի ծախսերը կարող են կրճատվել՝ օգտագործելով Spot օրինակները որպես Kubernetes աշխատանքային հանգույցներ: [3]. Spot օրինակները հասանելի են մինչև 90% զեղչով՝ ըստ պահանջարկի գների: EC2 Spot-ով Kubernetes-ի գործարկումը լավ համադրություն է. դուք պետք է նշեք մի քանի տարբեր տիպի օրինակներ՝ ավելի բարձր հասանելիության համար, այսինքն՝ կարող եք ավելի մեծ հանգույց ստանալ նույն կամ ավելի ցածր գնով, իսկ ավելացված հզորությունը կարող է օգտագործվել բեռնարկղային Kubernetes-ի աշխատանքային ծանրաբեռնվածությամբ:

Ինչպե՞ս գործարկել Kubernetes-ը EC2 Spot-ում: Կան մի քանի տարբերակներ՝ օգտագործեք երրորդ կողմի ծառայություն, ինչպիսին է SpotInst-ը (այժմ կոչվում է «Spot», մի հարցրեք, թե ինչու), կամ պարզապես ավելացրեք Spot AutoScalingGroup (ASG) ձեր կլաստերին: Օրինակ, ահա CloudFormation հատվածը «հզորությամբ օպտիմիզացված» 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"

Մի քանի նշում՝ Kubernetes-ի հետ Spot-ի օգտագործման վերաբերյալ.

• Դուք պետք է կարգավորեք Spot ավարտումները, օրինակ՝ միացնելով հանգույցը, երբ օրինակը դադարեցվի
• Zalando-ն օգտագործում է պատառաքաղ պաշտոնական կլաստերի ավտոմատ մասշտաբավորում՝ հանգույցների լողավազանի առաջնահերթություններով
• Կետային հանգույցներ կարելի է ստիպել ընդունեք «գրանցումները» ծանրաբեռնվածության՝ տեղում գործարկելու համար

Ամփոփում

Հուսով եմ, որ ներկայացված գործիքներից մի քանիսը օգտակար կգտնեք ձեր ամպային հաշիվը նվազեցնելու համար: Հոդվածի բովանդակության մեծ մասը կարող եք գտնել նաև այստեղ իմ ելույթը DevOps Gathering 2019-ին YouTube-ում և սլայդներում.

Որո՞նք են ձեր լավագույն փորձը Kubernetes-ում ամպային ծախսերը խնայելու համար: Խնդրում եմ տեղեկացնել ինձ ժամը Twitter (@try_except_).

[1] Փաստորեն, 3-ից պակաս vCPU-ներ կմնան օգտագործելի, քանի որ հանգույցի թողունակությունը կրճատվում է վերապահված համակարգի ռեսուրսներով: Kubernetes-ը տարբերակում է ֆիզիկական հանգույցի հզորությունը և «տրամադրված» ռեսուրսները (Հանգույցի հատկացում).

[2] Հաշվարկի օրինակ. 5 ԳԲ հիշողությամբ մեկ m8.large օրինակը ամսական ~$84 ​​է (eu-central-1, On-Demand), այսինքն. 1/8 հանգույցի արգելափակումը մոտավորապես ~ $10/ամսական է:

[3] Ձեր EC2 հաշիվը նվազեցնելու շատ այլ եղանակներ կան, ինչպիսիք են Պահպանված դեպքերը, Խնայողական պլանը և այլն: Ես չեմ անդրադառնա այդ թեմաներին այստեղ, բայց դուք անպայման պետք է ուսումնասիրեք դրանք:

Իմացեք ավելին դասընթացի մասին:

Source: www.habr.com