Sparaðu á Kubernetes skýkostnaði á AWS

Þýðing á greininni var unnin í aðdraganda námskeiðsins "Infrastructure pallur byggt á Kubernetes".

Sparaðu á Kubernetes skýkostnaði á AWS

Hvernig á að spara skýkostnað þegar unnið er með Kubernetes? Það er engin ein rétt lausn, en þessi grein lýsir nokkrum verkfærum sem geta hjálpað þér að stjórna auðlindum þínum á skilvirkari hátt og draga úr kostnaði við tölvuský.

Ég skrifaði þessa grein með Kubernetes fyrir AWS í huga, en hún mun eiga við (næstum) nákvæmlega á sama hátt fyrir aðrar skýjaveitur. Ég geri ráð fyrir að klasarnir þínir séu nú þegar með sjálfvirka stærðarstillingu (cluster-autoscaler). Að fjarlægja tilföng og minnka dreifinguna þína mun aðeins spara þér peninga ef það dregur einnig úr flota starfsmannahnúta (EC2 tilvik).

Þessi grein mun fjalla um:

Hreinsun á ónotuðum auðlindum

Að vinna í hröðu umhverfi er frábært. Við viljum tæknistofnanir flýtt. Hraðari hugbúnaðarafhending þýðir einnig meiri PR-dreifing, forskoðunarumhverfi, frumgerðir og greiningarlausnir. Allt er dreift á Kubernetes. Hver hefur tíma til að hreinsa upp prufudreifingar handvirkt? Það er auðvelt að gleyma því að eyða viku gamalli tilraun. Skýjareikningurinn mun á endanum hækka vegna einhvers sem við gleymdum að loka:

Sparaðu á Kubernetes skýkostnaði á AWS

(Henning Jacobs:
Zhiza:
(tilvitnanir) Corey Quinn:
Goðsögn: AWS reikningurinn þinn er fall af fjölda notenda sem þú hefur.
Staðreynd: AWS stigið þitt er fall af fjölda verkfræðinga sem þú hefur.

Ivan Kurnosov (sem svar):
Raunveruleg staðreynd: AWS stigið þitt er fall af fjölda hluta sem þú gleymdir að slökkva á/eyða.)

Húsvörður Kubernetes (kube-janitor) hjálpar til við að þrífa þyrpinguna þína. Uppsetning húsvarðar er sveigjanleg fyrir bæði alþjóðlega og staðbundna notkun:

  • Reglur um allt klasa geta skilgreint hámarkstíma til að lifa (TTL) fyrir PR/próf dreifing.
  • Hægt er að merkja einstök tilföng með janitor/ttl, til dæmis til að fjarlægja toppinn/frumgerðina sjálfkrafa eftir 7 daga.

Almennar reglur eru skilgreindar í YAML skránni. Leið hennar liggur í gegnum færibreytuna --rules-file í kube-janitor. Hér er dæmi um reglu til að fjarlægja öll nafnrými með -pr- í nafni eftir tvo daga:

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

Eftirfarandi dæmi stjórnar notkun á forritamerkinu á Deployment og StatefulSet belgunum fyrir allar nýjar Deployments/StatefulSets árið 2020, en leyfir á sama tíma framkvæmd prófana án þessa merkimiða í viku:

- 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

Keyrðu tímatakmarkað kynningu í 30 mínútur á klasa sem keyrir kube-janitor:

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

Önnur uppspretta hækkandi kostnaðar er viðvarandi magn (AWS EBS). Að eyða Kubernetes StatefulSet eyðir ekki viðvarandi bindi þess (PVC - PersistentVolumeClaim). Ónotað EBS bindi getur auðveldlega leitt til kostnaðar upp á hundruð dollara á mánuði. Kubernetes Janitor hefur eiginleika til að hreinsa upp ónotað PVC. Til dæmis mun þessi regla fjarlægja öll PVC sem ekki eru sett upp af einingu og sem StatefulSet eða CronJob vísar ekki til:

# удалить все PVC, которые не смонтированы и на которые не ссылаются StatefulSets
- id: remove-unused-pvcs
  resources:
  - persistentvolumeclaims
  jmespath: "_context.pvc_is_not_mounted && _context.pvc_is_not_referenced"
  ttl: 24h

Kubernetes Janitor getur hjálpað þér að halda klasanum þínum hreinum og koma í veg fyrir að kostnaður við tölvuský hlóðst hægt upp. Til að fá leiðbeiningar um uppsetningu og uppsetningu, fylgdu README kube-vaktmaður.

Minnka skala á óvinnutíma

Prófunar- og sviðsetningarkerfi eru venjulega nauðsynleg til að starfa aðeins á vinnutíma. Sum framleiðsluforrit, eins og bakskrifstofa/stjórnunartól, krefjast einnig takmarkaðs framboðs og gæti verið óvirkt á einni nóttu.

Kubernetes Downscaler (kube-downscaler) gerir notendum og rekstraraðilum kleift að minnka kerfið á óvinnutíma. Dreifingar og StatefulSets geta skalað í núll eftirlíkingar. CronJobs gæti verið stöðvað. Kubernetes Downscaler er stilltur fyrir heilan klasa, eitt eða fleiri nafnrými eða einstök tilföng. Þú getur stillt annað hvort „aðgerðalausan tíma“ eða öfugt „vinnutíma“. Til dæmis, til að draga eins mikið og mögulegt er yfir nætur og helgar:

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

Hér er línurit til að skala hnúta starfsmanna klasa um helgar:

Sparaðu á Kubernetes skýkostnaði á AWS

Að lækka úr ~13 í 4 starfsmannahnúta gerir vissulega áberandi mun á AWS reikningnum þínum.

En hvað ef ég þarf að vinna á „niður í miðbæ“ klasa? Hægt er að útiloka ákveðnar dreifingar varanlega frá skala með því að bæta við niðurskala/útiloka: sanna athugasemd. Hægt er að útiloka dreifingar tímabundið með því að nota niðurskala/útiloka-þar til athugasemd með algerum tímastimpli á sniðinu ÁÁÁÁ-MM-DD HH:MM (UTC). Ef nauðsyn krefur er hægt að minnka allan þyrpinguna með því að dreifa belg með skýringunni downscaler/force-uptime, til dæmis, með því að ræsa 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

Horfa á README kube-downscaler, ef þú hefur áhuga á dreifingarleiðbeiningum og viðbótarmöguleikum.

Notaðu lárétta sjálfstýringu

Mörg forrit/þjónusta takast á við kraftmikið hleðslumynstur: stundum eru einingar þeirra aðgerðalausar og stundum virka þær á fullri afköstum. Það er ekki hagkvæmt að reka varanlegan flota fræbelgja til að takast á við hámarks álag. Kubernetes styður lárétta sjálfvirka mælikvarða yfir auðlind HorizontalPodAutoscaler (HPA). Örgjörvanotkun er oft góð vísbending um mælikvarða:

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 hefur búið til íhlut til að tengja á einfaldan hátt sérsniðnar mæligildi fyrir mælikvarða: Kube Metrics millistykki (kube-metrics-adapter) er almennt mæligildi millistykki fyrir Kubernetes sem getur safnað og þjónað sérsniðnum og ytri mælingum fyrir lárétta sjálfvirka mælikvarða á belg. Það styður stigstærð byggt á Prometheus mæligildum, SQS biðröðum og öðrum stillingum. Til dæmis, til að skala dreifinguna þína í sérsniðna mælikvarða sem forritið sjálft táknar sem JSON í /mælingum, notaðu:

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

Að stilla lárétta sjálfvirka mælikvarða með HPA ætti að vera ein af sjálfgefnum aðgerðum til að bæta skilvirkni fyrir ríkisfangslausa þjónustu. Spotify er með kynningu með reynslu sinni og ráðleggingum fyrir HPA: skala dreifinguna þína, ekki veskið þitt.

Draga úr ofbókun auðlinda

Vinnuálag Kubernetes ákvarðar örgjörva/minnisþörf þeirra með „úrræðisbeiðnum“. Örgjörvaauðlindir eru mældar í sýndarkjörnum eða oftar í „millicore“, til dæmis þýðir 500m 50% vCPU. Minnisauðlindir eru mældar í bætum og hægt er að nota algeng viðskeyti eins og 500Mi, sem þýðir 500 megabæti. Auðlindabeiðnir um "læsa" getu á hnútum starfsmanna, sem þýðir að pod með 1000m CPU beiðni á hnút með 4 vCPUs mun skilja aðeins 3 vCPUs eftir tiltæka öðrum fræbelgjum. [1]

Slaki (umfram varasjóður) er munurinn á umbeðnum auðlindum og raunverulegri notkun. Til dæmis, fræbelgur sem biður um 2 GiB af minni en notar aðeins 200 MiB hefur ~1,8 GiB af „umfram“ minni. Ofgnótt kostar peninga. Það má gróflega áætla að 1 GiB af óþarfi minni kosti ~$10 á mánuði. [2]

Kubernetes auðlindaskýrsla (kube-resource-report) sýnir umframforða og getur hjálpað þér að ákvarða sparnaðarmöguleika:

Sparaðu á Kubernetes skýkostnaði á AWS

Kubernetes auðlindaskýrsla sýnir umframmagnið samanlagt með forriti og skipun. Þetta gerir þér kleift að finna staði þar sem hægt er að draga úr auðlindaþörf. HTML skýrslan sem er búin til gefur aðeins mynd af auðlindanotkun. Þú ættir að skoða CPU/minni notkun með tímanum til að ákvarða fullnægjandi auðlindabeiðnir. Hér er Grafana töflu fyrir „venjulega“ CPU-þunga þjónustu: allir belgirnir nota verulega minna en 3 umbeðna örgjörvakjarna:

Sparaðu á Kubernetes skýkostnaði á AWS

Með því að minnka CPU-beiðnina úr 3000m í ~400m losnar fjármagn fyrir annað vinnuálag og gerir klasanum kleift að vera minni.

"Meðal CPU notkun EC2 tilvika sveiflast oft á eins stafa prósentubilinu," skrifar Corey Quinn. Þó fyrir EC2 að áætla rétta stærð gæti verið slæm ákvörðunÞað er auðvelt að breyta nokkrum Kubernetes auðlindafyrirspurnum í YAML skrá og getur leitt til mikillar sparnaðar.

En viljum við virkilega að fólk breyti gildum í YAML skrám? Nei, vélar geta gert það miklu betur! Kubernetes Vertical Pod Autoscaler (VPA) gerir einmitt það: aðlagar auðlindabeiðnir og takmarkanir í samræmi við vinnuálagið. Hér er sýnishorn af Prometheus CPU beiðnir (þunn blá lína) aðlagað af VPA með tímanum:

Sparaðu á Kubernetes skýkostnaði á AWS

Zalando notar VPA í öllum sínum klösum fyrir íhluti innviða. Forrit sem ekki eru mikilvæg geta líka notað VPA.

Goldilocks frá Fairwind er tól sem býr til VPA fyrir hverja dreifingu í nafnrými og birtir síðan VPA meðmæli á mælaborðinu. Það getur hjálpað forriturum að stilla réttar CPU / minni beiðnir fyrir forritin sín:

Sparaðu á Kubernetes skýkostnaði á AWS

Ég skrifaði lítið bloggfærsla um VPA árið 2019 og nýlega í CNCF notendasamfélag ræddi VPA-mál.

Notkun EC2 Spot Instances

Síðast en ekki síst er hægt að lækka AWS EC2 kostnað með því að nota Spot tilvik sem Kubernetes vinnuhnúta [3]. Spottilvik eru fáanleg með allt að 90% afslætti miðað við On-Demand verð. Að keyra Kubernetes á EC2 Spot er góð samsetning: þú þarft að tilgreina nokkrar mismunandi tilviksgerðir fyrir meira framboð, sem þýðir að þú getur fengið stærri hnút fyrir sama eða lægra verð, og aukna afkastagetu er hægt að nota með Kubernetes vinnuálagi í gáma.

Hvernig á að keyra Kubernetes á EC2 Spot? Það eru nokkrir möguleikar: notaðu þriðja aðila þjónustu eins og SpotInst (nú kallað "Spot", ekki spyrja mig hvers vegna), eða einfaldlega bættu Spot AutoScalingGroup (ASG) við þyrpinguna þína. Til dæmis, hér er CloudFormation bút fyrir „getu-bjartsýni“ Spot ASG með mörgum tilvikstegundum:

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"

Nokkrar athugasemdir um notkun Spot með Kubernetes:

  • Þú þarft að sinna Spot uppsögnum, til dæmis með því að sameina hnútinn þegar tilvikið er hætt
  • Zalando notar gaffal opinber þyrping sjálfvirk stærð með forgangsröðun hnútahóps
  • Bletthnútar hægt að þvinga samþykkja „skráningar“ á vinnuálagi til að keyra í Spot

Yfirlit

Ég vona að þér finnist eitthvað af verkfærunum sem kynnt eru gagnleg til að lækka skýjareikninginn þinn. Þú getur líka fundið megnið af innihaldi greinarinnar á erindi mitt á DevOps Gathering 2019 á YouTube og í glærum.

Hver eru bestu starfsvenjur þínar til að spara skýkostnað á Kubernetes? Vinsamlegast láttu mig vita kl Twitter (@reyna_nema_).

[1] Reyndar verða minna en 3 vCPUs áfram nothæfar þar sem afköst hnútsins minnkar með fráteknum kerfisauðlindum. Kubernetes gerir greinarmun á líkamlegri hnútgetu og „útveguðum“ auðlindum (Hægt að úthluta hnút).

[2] Reiknidæmi: eitt m5.stórt tilvik með 8 GiB minni er ~$84 ​​á mánuði (eu-central-1, On-Demand), þ.e. að blokka 1/8 hnút er um það bil ~$10/mánuði.

[3] Það eru margar fleiri leiðir til að lækka EC2 reikninginn þinn, eins og frátekin tilvik, sparnaðaráætlun o.s.frv. - Ég mun ekki fjalla um þessi efni hér, en þú ættir örugglega að skoða þau!

Frekari upplýsingar um námskeiðið.

Heimild: www.habr.com

Bæta við athugasemd