Kuidas säästa pilvekuludelt Kubernetesel AWS-is

Artikli tõlge on koostatud kursuse alguse eelõhtul Kubernetesi baasil olev infrastruktuuri platvorm.

Kuidas vähendada pilvekasutuse kulusid Kubernetesega töötades? Ühte õiget lahendust ei eksisteeri, kuid käesolevas artiklis on kirjeldatud mitmeid tööriistu, mis aitavad teil tõhusamalt hallata ressursse ja vähendada pilvearvutamise kulusid.

Kirjutasin selle artikli pilguga AWS-i Kubernetesile, kuid see kehtib (peaaegu) täpselt ka teiste pilveteenuse pakkujate puhul. Eeldan, et teie klastril(on) juba määratud automaatne skaleerimine (cluster-autoscaler). Ressursside eemaldamine ja juurutamise skaleerimise vähendamine aitab kokku hoida ainult siis, kui see vähendab ka teie töösõlmede (EC2 instantside) arvu.

Käesolevas artiklis käsitletakse:

• kasutamata ressursside puhastamine (kube-janitor)
• ),väljakutse vähenemine mitte tööajal ()
• kube-downscaler
• ),horisontaalne automaatne skaleerimine (HPA),liigne ressursside reserveerimise vähendamine (
• kube-resource-report

, VPA)

Spot instantside kasutamine Kasutamata ressursside puhastamineTöötamine kiiresti muutuvas keskkonnas on suurepärane. Soovime, et tehnilised organisatsioonid

kiireneksid
. Kiirem tarkvara Edastamine tähendab ka rohkem PR-i juurutusi, eelvaate keskkondi, prototüüpe ja analüütilisi lahendusi. Kõik juurutatakse Kuberneteses. Kes suudab leida aega käsitsi testimist välja puhtaks teha? Eksperimendi eemaldamine nädal tagasi võib lihtsalt ununeda. Pilvekulu tõuseb lõpuks, kuna unustame sulgeda:
(Henning Jacobs:
Tõde:
(tsitaat) Corey Quinn:

Müüt: Teie AWS arve sõltub teie kasutajate arvust.
Tõde: Teie AWS arve sõltub teie inseneride arvust.

Ivan Kurnosov (vastuseks): Tõeline tõde: Teie AWS arve sõltub asjade arvust, mille unustasite välja lülitada/maha võtta.)

• Kubernetes Janitor (kube-janitor) aitab teie klastrit puhastada. Janitori konfiguratsioon on paindlik nii globaalseteks kui ka lokaalseks kasutamiseks:
• Eri ressursid võivad olla märgitud janitor/ttl abil, näiteks spike/prototüübi automaatseks eemaldamiseks 7 päeva pärast.

Üldreeglid on määratletud YAML failis. Selle tee edastatakse parameetri kaudu --rules-file kube-janitorisse. Siin on näide reeglist, mis eemaldab kõik nimesed, millel on -pr- kahe päeva pärast:

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

Järgmine näide reguleerib rakenduse sildi kasutamist Deployment ja StatefulSet podides kõigi uute Deployments/StatefulSet jaoks 2020. aastal, kuid samas võimaldab nädalase testimise ilma selle sildita:

- id: require-application-label
  # eemaldada deployments ja statefulsets ilma "application" sildita
  resources:
    - deployments
    - statefulsets
  # vt http://jmespath.org/specification.html
  jmespath: "!(spec.template.metadata.labels.application) && metadata.creationTimestamp > '2020-01-01'"
  ttl: 7d

Kube-janitoriga töötavas klastris aja piiramine demode käivitamine 30 minutiks:

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

Teine kasvavate kulude allikas on püsivolüümid (AWS EBS). Kubernetesi StatefulSet'i kustutamisel ei kustutata selle püsivolumeid (PVC — PersistentVolumeClaim). Kasutamata EBS-i mahutid võivad kergesti põhjustada sadu dollareid kuus. Kubernetesi Janitoril on funktsioon, mis puhastab kasutamata PVC-sid. Näiteks see reegel eemaldab kõik PVC-d, mida moodul ei ole mountinud ja millega StatefulSet või CronJob ei viita:

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

Kubernetesi Janitor aitab teil hoida oma klastrit 'puhtana' ja vältida aeglaselt kumulatiivsete pilvandmete kulude tekkimist. Juhiste saamiseks juurutamise ja seadistamise kohta järgige README kube-janitor.

Mastaabi vähendamine mitte-tööaegadel

Testimis- ja arendusüsteemid on tavaliselt vajalikud ainult tööaegadel. Mõned tootmisrakendused, nagu back-office/admin tööriistad, vajavad samuti vaid piiratud kättesaadavust ja võivad öösel välja lülitada.

Kubernetes Downscaler (kube-downscaler) võimaldab kasutajatel ja operaatoritel vähendada süsteemi mahtu mitteaktiivsete perioodide jooksul. Deployments ja StatefulSets saab skaleerida null replikani. CronJobs saab peatada. Kubernetes Downscaler seadistatakse kogu klastrile, ühele või mitmele nimeruumi või eraldi ressursside jaoks. Saab seadistada kas „seisakuaja” või vastupidi „tööaja”. Näiteks, et minimeerida skaleerimist öösel ja nädalavahetustel:

image: hjacobs/kube-downscaler:20.4.3
args:
  - --interval=30
  # ei keelata infrastruktuuri komponente
  - --exclude-namespaces=kube-system,infra
  # jätab keelamata kube-downscaleri ning jätab Postgres operaatori, et haldada välistatud andmebaase
  - --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

Siin on klastrite töövõrkude skaleerimise graafik nädalavahetustel:

Skaalate vähendamine ~13-lt 4-le töövõrgule toob kindlasti suured erinevused AWS arvel.

Aga mida teha, kui mul on vaja töötada klastrite „seisakuajal”? Teatud deploymente saab igaveseks välja jätta skaleerimisest, lisades annotatsiooni downscaler/exclude: true. Deploymente saab ajaliselt välja jätta annotatsiooniga downscaler/exclude-until, kusjuures kuupäev ja kellaaeg peavad olema absoluutsetes ajatempos formadis YYYY-MM-DD HH:MM (UTC). Kui vajalik, saab kogu klastrit uuesti skaleerida, käivitades puu annotatsiooniga downscaler/force-uptime, näiteks Nginx'i malliga:

kubectl run scale-up --image=nginx
kubectl annotate deploy scale-up janitor/ttl=1h # kustuta deployment tunni pärast
kubectl annotate pod $(kubectl get pod -l run=scale-up -o jsonpath="{.items[0].metadata.name}") downscaler/force-uptime=true

Vaata README kube-downscaler, kui sind huvitab, kuidas rakendada ning lisavõimalusi.

Kasutage horisontaalset automaatskalaarimist

Paljud rakendused/teenused tegelevad dünaamilise koormuse mustriga: mõnikord nende moodulid seisavad ning mõnikord töötavad nad täisvõimsusel. Pideva puudepargi haldamine maksimumkoormuse korral ei ole majanduslik. Kubernetes toetab horisontaalset automaatset skaleerimist läbi ressursi HorizontalPodAutoscaler (HPA). CPU kasutamine on sageli hea näitaja skaleerimiseks:

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 lõi komponente, et lihtsustada kohandatud mõõdikute integreerimist skaleerimise jaoks: Kube Metrics Adapter (kube-metrics-adapter) on universaalne mõõdikuadapter Kubernetes'e jaoks, mis suudab koguda ja teenindada kohandatud ja väliseid mõõdikuid horisontaalsete podide automaatseks skaleerimiseks. See toetab skaleerimist Prometheuse, SQS järjekordade ja teiste seadistuste alusel. Näiteks, et skaleerida rakenduse poolt esitatud kohandatud mõõdikut JSON formaadis /metrics, kasutage:

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 kaudu horisontaalse automaatse skaleerimise seadistamine peaks olema üks vaikimisi toimingutest teenuste tõhususe suurendamiseks oleku arvestamata. Spotify'l on esitluses nende kogemus ja soovitused HPA jaoks: skaalige oma rakendusi, mitte oma rahakotti.

Ülemäärase ressursireservi vähenemine

Kubernetes'e töökoormused määravad nende vajadused CPU/mälu osas "ressursi taotlemise" kaudu. CPU ressursse mõõdetakse virtuaalsete tuumade või sagedamini "millicores"'ides, näiteks 500m tähendab 50% vCPU-d. Mäluresursse mõõdetakse baitides ja tavapäraseid suffikseid saab kasutada, näiteks 500Mi, mis tähendab 500 megabaiti. Ressursi taotlused „lukustavad“ mahu tööjaamadele, st 1000m CPU taotlusega moodul 4 virtuaalse CPU-ga sõlmes jätab ainult 3 virtuaalset CPU-d teistele moodulitele. [1]

Slack (ülemäärane reserveerimine) — see on erinevus nõutud ressursside ja tegeliku kasutamise vahel. Näiteks pood, mis nõuab 2 GiB mälu, kuid kasutab ainult 200 MiB, omab ~ 1,8 GiB "ülejääki". Ülejääk maksab raha. Ligikaudne hinnang on, et 1 GiB ülejäägi hind on ~ 10 dollarit kuus. [2]

Kubernetes'i Ressursside Aruanne (kube-resource-report) kuvab liigsed reservid ja võib aidata teil leida säästmise potentsiaali:

Kubernetes'i Ressursside Aruanne näitab ülejääki, mille on agreggeerinud rakendus ja meeskond. See aitab leida kohti, kus ressursi nõudmisi võib vähendada. Genereeritud HTML aruanne pakub ainult ressursi kasutamise hetkeseisu. Te peaksid vaatama protsessori/mälu kasutamist ajas, et määrata adekvaatsed ressursi nõudmised. Siin on Grafana diagramm "tüüpilise" teenuse jaoks, millel on suur koormus protsessorile: kõik podid kasutavad oluliselt vähem kui 3 nõutud tuuma:

Protsessori nõudmise vähendamine 3000m kuni ~400m vabastab ressursid teiste koormuste jaoks ja võimaldab klastrit vähendada.

"Keskmine EC2 instantside protsessori kasutamine kõigub sageli ühesõnalistes protsentides," kirjutab Cory Quinn.. Kuigi EC2 õige suuruse hindamine võib olla kehv otsus, siis mõned Kubernetes'e ressursi nõudmiste muutmine YAML failis toimub lihtsalt ja võib tuua tohutut kokkuhoidu.

Aga kas me tõeliselt tahame, et inimesed muudaksid väärtusi YAML failides? Ei, masinad saavad seda palju paremini teha! Kubernetes Vertical Pod Autoscaler (VPA) tegeleb sellega: kohandab ressursi nõudmisi ja piiranguid vastavalt koormusele. Siin on näide Prometheuse protsessori nõudmiste graafikust (õhuke sinine joon), mille VPA on kohandanud ajas:

Zalando kasutab VPA kõigis oma klastrites infrastruktuuri komponente. Mitte-kriitilised rakendused võivad samuti kasutada VPA.

Goldilocks Fairwindilt on tööriist, mis loob iga juurutamise jaoks VPA nimetusruumis ja seejärel kuvab soovituse VPA oma armatuurlaud.

Olen kirjutanud väikese blogipostituse VPA-st 2019. aastal ja hiljuti CNCF lõppkasutaja kogukonnas arutati VPA teemat.

EC2 Spot instantside kasutamine.

Lõpuks, mis ei ole vähem oluline, on AWS EC2 kulusid võimalik vähendada, kasutades Spot-instance'e Kubernetes'i töövõrkudena. [3]. Spot-instance'id on saadaval kuni 90% soodsamalt võrreldes nõudmise hindadega. Kubernetes'i käivitamine EC2 Spot'il on hea kombinatsioon: peate määrama mitu erinevat instance'i tüüpi kõrgema saadavuse tagamiseks, see tähendab, et saate suurema node'i sama või madalama hinna eest ning suurenenud mahtu saab kasutada Kubernetes'i konteineritöökoormuste jaoks.

Kuidas käivitada Kubernetes EC2 Spot'il? On mitu võimalust: kasutada kolmanda osapoole teenust nagu SpotInst (nüüd nimetatakse lihtsalt 'Spot', mitte küsi, miks), või lihtsalt lisada Spot AutoScalingGroup (ASG) oma klastrisse. Näiteks siin on CloudFormation'i fragment 'kapatsiteed optimeeritud' Spot ASG jaoks mitme instance'i tüübiga:

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"

Mõned märkused Spot'i kasutamise kohta Kubernetes'ega:

• Peate tegelema Spot'i lõpetamistega, näiteks node'i mahapanemise kaudu, kui instance'i peatatakse.
• Zalando kasutab fork ametlikku klastrite automaatset skaleerimist, kus on node'i basseinide prioriteedid.
• Spot node'id saab sundida aktsepteerima töökoormuste 'registreerimisi' Spot'is käivitamiseks.

Elulookirjeldus

Loodan, et leiate mõned esitatud tööriistad kasulikuks oma pilveteenuste arve vähendamiseks. Enamik artikli sisust on saadaval ka minu esitluses DevOps Gathering 2019 YouTube'is ja slaidide kujul. Millised on teie parimad praktikad pilvekulude kokkuhoiuks Kubernetes'es? Andke teada.

Twitteris (@try_except_) Twitter (@try_except_).

[1] Tegelikult jääb kasutamiseks sobivaks vähem kui 3 virtuaalset CPU-d, kuna sõlme läbilaskevõime väheneb reserveeritud süsteemiressursside tõttu. Kubernetes eristab füüsilist sõlme mahtu ja "eraldatud" ressursse (Sõlme eraldatav).

[2] Näide arvutusest: üks m5.large eksemplar, millel on 8 GiB mälu, maksab ~84 USA dollarit kuus (eu-central-1, On-Demand), st 1/8 sõlme kinni hoidmine maksab umbes ~10 USA dollarit kuus.

[3] On veel palju võimalusi oma EC2 arvet vähendada, näiteks reserveeritud eksemplarid, säästuplaanid jt – ma ei hakka neid teemasid siin käsitlema, kuid kindlasti peaksite neist uurima!

Tutvu kursusega lähemalt.

Allikas: habr.com