Kuberneetese pilvekulude kokkuhoid AWS-is

Artikli tõlge on ettevalmistatud kursuse alguseks Kubernetese põhine infrastruktuuri platvorm.

Kuidas säästa pilvekulusid Kubernetese kasutamisel? Ühte õiget lahendust ei ole, kuid selles artiklis on kirjeldatud mitmeid tööriistu, mis aitavad teil tõhusamalt hallata ressursse ja vähendada pilvearvutamise kulusid.

Selle artikli olen kirjutannut silmas pidades Kubernetese AWS-is, kuid see kehtib (peaaegu) samamoodi ka teiste pilveteenuste pakkujate jaoks. Eeldan, et teie kluster(ite)l on juba seadistatud automaatne skaleerimine (cluster-autoscaler). Ressursside eemaldamine ja juurutamise suuruse vähendamine aitab säästa ainult siis, kui see samuti vähendab teie töökohti (EC2 instantsid).

Selles artiklis käsitletakse:

• mittetäiendavate ressursside puhastamine (kube-janitor)
• koormuse vähendamine mitte tööajal (kube-downscaler)
• horisontaalse automaatse skaleerimise (HPA) kasutamine,
• üleliigse ressursi reservi vähendamine (kube-resource-report, VPA)
• Spot instantside kasutamine

Mittekasutatavate ressursside puhastamine

Töötamine kiiresti muutuvas keskkonnas on suurepärane. Soovime, et tehnilised organisatsioonid kiireneksid.. Kiirelema tarkvara tarnimine tähendab ka rohkem PR-deploy'e, vaheversioone, prototüüpe ja analüütilisi lahendusi. Kõik on juurutatud Kuberneteses. Kes tahab aega kulutada, et käsitsi testijuhtimisi puhastada? On kerge unustada eemaldada nädalatevanune eksperiment. Pilveteenuse arve hakkab lõpuks kasvama, kuna unustame sulgeda:

(Henning Jacobs:
Elu:
(tsitaat) Cory Quinn:
Müüt: Teie AWS arve sõltub teie kasutajate arvust.
Tõde: Teie AWS arve sõltub teie inseneride arvust.

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

Kubernetes Janitor (kube-janitor) aitab teie klastrit puhastada. Janitori konfiguratsioon on paindlik nii globaalse kui ka kohaliku kasutuse jaoks:

• Kogu klastrile kehtivad üldised reeglid, mis võivad määrata maksimaalse eluea (TTL - time-to-live) PR/testijuhtimiste jaoks.
• Erinevaid ressursse saab annoteerida janitor/ttl abil, näiteks spike/prototüübi automaatseks eemaldamiseks 7 päeva pärast.

Üldreeglid määratakse YAML-failis. Selle teekond edastatakse parameetri kaudu --rules-file kube-janitorile. Siin on näide reeglist, et eemaldada kõik nimed, mis sisaldavad -pr- nimes kahe päeva pärast:

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

Järgmine näide määratleb application märgi kasutamise Deployment ja StatefulSet pod'ides kõigi uute Deploymentide/StatefulSet'ide jaoks aastast 2020, kuid samal ajal võimaldab testide sooritamist ilma selle märgita nädala jooksul:

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

Ajaliselt piiratud demoversioon 30 minutiks kasti, kus töötab kube-janitor:

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

Üks tõusvate kulude allikaid on püsivolumeid (AWS EBS). Kui Kubernetes StatefulSet'i eemaldatakse, ei eemaldata selle püsivalt (PVC — PersistentVolumeClaim). Kasutamata EBS mahud võivad kergesti põhjustada sadu dollareid kulusid kuus. Kubernetes Janitoril on funktsioon kasutamata PVC-de puhastamiseks. Näiteks see reegel eemaldab kõik PVC-d, mis ei ole üles seatud mooduliga ja millele ei viita StatefulSet või CronJob:

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

Kubernetes Janitor võib aidata teil hoida oma klastrit „puhtana” ja vältida aeglaselt kogunevaid pilvearvutamise kulusid. Üksikasjade jaoks juurutamise ja seadistamise kohta järgige README kube-janitor.

Maha suurendamine mitte tööajal

Testimis- ja vahepealsed süsteemid vajavad tavaliselt tööd ainult tööajal. Mõned tootmisrakendused, nagu back-office / haldustööriistad, vajavad samuti ainult piiratud kättesaadavust ja võivad öösel välja lülitada.

Kubernetes Downscaler (kube-downscaler) võimaldab kasutajatel ja operaatoritel vähendada süsteemi suurust mitte tootmisajal. Deployments ja StatefulSets saab skaleerida null-replikaatidele. CronJobs võivad olla peatatud. Kubernetes Downscaler seadistatakse kogu klastrile, ühele või mitmele nimekontrollile või üksikutele ressurssidele. Saate seadistada kas „seisakuaja“ või vastupidi „töötamise aja“. Näiteks, et maksimaalselt vähendada skaleerimist öösel ja nädalavahetustel:

image: hjacobs/kube-downscaler:20.4.3
args:
  - --interval=30
  # ärge keelake infrastruktuuri komponente
  - --exclude-namespaces=kube-system,infra
  # ärge keelake kube-downscalerit ja jätke Postgres Operator, et välistatud andmebaase saaks hallata
  - --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 graafik klastrite töötavate sõlmede skaleerimise kohta nädalavahetustel:

Skaleerimine ~13-lt 4 töökohtadele annab kindlasti tunda erinevust AWS arvel.

Aga mis siis, kui pean töötama klastris "seisaku ajal"? Teatud juurutamised saab igaveseks mõõtmisest välja jätta, lisades annotatsiooni downscaler/exclude: true. Juurutamisi saab ajaliselt välja jätta annotatsiooni downscaler/exclude-until abil, mille absoluutne ajamärk on formaadis AAAA-KK-PP TT:MM (UTC). Vajadusel saab kogu klastri tagasi mõõta, juurutades poodi koos annotatsiooniga downscaler/force-uptime, näiteks käivitades nginx mudeli:

kubectl run scale-up --image=nginx
kubectl annotate deploy scale-up janitor/ttl=1h # kustuta juurutamine 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 teid huvitab juurutamise juhend ja täiendavad valikud.

Kasutage horisontaalset automaatskaalumist

Paljud rakendused/teenused tegelevad dünaamilise koormusgraafikuga: mõnikord on nende moodulid seisakus ja mõnikord töötavad nad täievõimsusega. Püsiva podide pargi hoidmine maksimaalse tippkoormuse haldamiseks ei ole majanduslik. Kubernetes toetab horisontaalset automaatset kaalumist 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 on loonud komponendi, mis lihtsustab kasutajamõõtmete ühendamist skaleerimiseks: Kube Metrics Adaptori (kube-metrics-adapter) on universaalne mõõtmete adapter Kubernetes jaoks, mis suudab koguda ja teenindada kasutaja- ja välist mõõtmeid pod'ide horisontaalse automaatse skaleerimise jaoks. See toetab skaleerimist Prometheuse, SQS järjekordade ja muude seadistuste põhiselt. Näiteks, et skaleerida rakenduse poolt esitatud kasutajamõõdiku põhjal, mis on JSON kujul aadressil /metrics, kasutage:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
  annotations:
    # metric-config.../
    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

Horisontaalse automaasistumise seadistamine HPA abil peaks olema üks vaikeseade, et suurendada teenuste efektiivsust olekust sõltumatult. Spotify-l on esitluses oma kogemused ja soovitused HPA kohta: skaalake oma rakendusi, mitte oma rahakotti.

ressursside ülevarustamise vähendamine

Kubernetesi töökohustused määravad oma CPU/mälu vajadused "ressursside taotluste" (resource requests) kaudu. CPU ressursid mõõdetakse virtuaalsete tuumade või sagedamini "millicores" (millikernad) kaudu, näiteks 500m tähendab 50% vCPU-st. Mälu ressursid mõõdetakse baitides ning saab kasutada tavalisi sufikseid, näiteks 500Mi, mis tähendab 500 MB. Ressursside taotlused "broneerivad" mahtu töötlusõlmedes, see tähendab, et moodul, mille CPU taotlus on 1000m, jääb 4 virtuaalse CPU-ga sõlmes, jätab ainult 3 virtuaalset CPU-d teistele moodulitele. [1]

Slack (ülejääk) — on vahe taotletud ressursside ja tegeliku kasutamise vahel. Näiteks pod, mis taotleb 2 GiB mälu, kuid kasutab ainult 200 MiB, omab ~ 1,8 GiB "ülejääki" mälu. Ülejääk maksab raha. Üks pelgalt hinnang on, et 1 GiB üleliigset mälu maksab ~ 10 dollarit kuus. [2]

Kubernetesi ressursside aruanne (kube-resource-report) kuvab liigsed varud ja võib aidata teil määrata võimalikku kokkuhoidu:

Kubernetesi ressursside aruanne näitab ülemäärasid, mille rakendus ja meeskond on kokku kogunud. See aitab leida kohti, kus ressursipäringut saab vähendada. Generitud HTML-raport annab ainult hetkepildi ressursi kasutamisest. Peaksite vaatama protsessori/mälu kasutamist ajas, et määrata sobivad ressursipäringud. Siin on Grafana diagramm „tüüpilise” kõrgelt koormatud teenuse jaoks: kõik podid kasutavad oluliselt vähem kui 3 nõutud protsessorituuma.

Protsessoripäringu vähendamine 3000m-lt ~400m-le vabastab ressursse teiste töökoormuste jaoks ja võimaldab klastrit vähendada.

„EC2 instantside keskmine protsessorikasutus kõigub sageli ühesigitistes protsentides,” kirjutab Cory Quinn. Samal ajal kui EC2 õige suuruse määramine võib olla halb otsus, muudatused mõnedes Kubernetes'e ressursipäringutes YAML-failis on lihtsad ja võivad tuua tohutu kokkuhoiu.

Aga kas me tõeliselt tahame, et inimesed muudaksid väärtusi YAML-failides? Ei, masinad saavad seda palju paremini teha! Kubernetes Vertikaalne Pod Autoscaler (VPA) tegeleb just sellega: kohandab ressursipäringuid ja piiranguid vastavalt töökoormusele. Siin on näide Prometheuse CPU päringute graafikust (peen sinine joon), mida on kohandatud VPA aja jooksul:

Zalando kasutab VPA kõigis oma klastrites infrastruktuuri komponente jaoks. Mitte-kriitilised rakendused saavad samuti VPA-d kasutada.

Goldilocks Fairwindilt — see on tööriist, mis loob VPA iga nimede ruumi juuresoleku jaoks ja seejärel kuvab VPA soovituse oma juhtpaneelil. See aitab arendajatel seada õiged CPU/mälu päringud oma rakendustele:

Kirjutasin väikesest blogipostitusest VPA-st 2019. aastal ja hiljuti arutati CNCF lõppkasutaja komitees VPA küsimust.

EC2 Spot instantside kasutamine

Lõpuks, mis ei ole vähem oluline, saab AWS EC2 kulusid vähendada, kasutades Spot instantside kui Kubernetes tööõliseid [3]. Spot instantsi on saadaval kuni 90% soodsamalt võrreldes nõudmisest tulenevate hindadega. Kubernetes käivitamine EC2 Spotil on hea kombinatsioon: peate määrama mitu erinevat instantsitüüpi kõrgema saadavuse tagamiseks, st saate sama või madalama hinna eest suurema sõlme ning suurenenud mahtu saab kasutada Kubernetes'i konteineritöökoormustes.

Kuidas käivitada Kubernetes EC2 Spotal? On mitmeid võimalusi: kasutada kolmanda osapoole teenust, nagu SpotInst (nüüd tuntud kui „Spot”, ära küsi, miks), või lihtsalt lisada Spot AutoScalingGroup (ASG) oma klastrisse. Näiteks siin on CloudFormation'i fragment „mahtude optimeeritud” Spot ASG jaoks mitme eksemplari 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ärkmed Spot'i kasutamise kohta Kubernetes'ega:

• peate haldama Spot'i lõpetamisi, näiteks sõlme massimise kaudu instantsi seiskamisel
• Zalando kasutab forki ametlikku klastrite automaatset skaleerimist sõlmede basseinide prioriteetidega
• Spot'i sõlmed võib nõuda töötavate koormuste "registreeringute" vastuvõtmist Spot'is

Kokkuvõte

Loodan, et leiate mõned esitatud tööriistad kasulikuks oma pilvearvutuse arve vähendamiseks. Suurema osa artikli sisust leiate ka minu esitlusest DevOps Gathering 2019 YouTube'is ja slaidide kujul.

Millised on teie parimad praktikud Kubernetes'e pilvekulude kokkuhoiuks? Andke kindlasti teada Twitter (@try_except_).

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

[2] Näide arvutusest: üks m5.large instants 8 GiB mäluga maksab umbes 84 USA dollarit kuus (eu-central-1, On-Demand), st 1/8 sõlme lukustamine maksab umbes 10 USA dollarit kuus.

[3] On veel palju viise, kuidas oma EC2 arvet vähendada, näiteks reserveeritud instantsid, säästuplaan jne — ma ei kavatse neid teemasid siin käsitleda, kuid peaksite kindlasti uurima!

Uuri kursuse kohta lähemalt.

Allikas: habr.com