Bespaar op Kubernetes-wolkkoste op AWS

Die vertaling van die artikel is voorberei op die vooraand van die aanvang van die kursus "Infrastruktuurplatform gebaseer op Kubernetes".

Bespaar op Kubernetes-wolkkoste op AWS

Hoe om op wolkkoste te bespaar wanneer u met Kubernetes werk? Daar is geen enkele regte oplossing nie, maar hierdie artikel beskryf verskeie instrumente wat jou kan help om jou hulpbronne meer effektief te bestuur en jou wolkrekenaarkoste te verminder.

Ek het hierdie artikel geskryf met Kubernetes vir AWS in gedagte, maar dit sal (byna) presies dieselfde op ander wolkverskaffers van toepassing wees. Ek neem aan jou groepering(s) het reeds outoskaal opgestel (cluster-outoskaaler). Deur hulpbronne te verwyder en jou ontplooiing af te skaal, sal jy net geld spaar as dit ook jou vloot werkersnodusse (EC2-gevalle) verminder.

Hierdie artikel sal dek:

  • skoonmaak van ongebruikte hulpbronne (kube-oppasser)
  • Verminder skaal tydens nie-werksure (kube-afskaaler)
  • met behulp van horisontale outoskaal (HPA),
  • vermindering van oormatige hulpbronreservering (kube-hulpbron-verslag, VPA)
  • met behulp van Spot-gevalle

Skoonmaak van ongebruikte hulpbronne

Dit is wonderlik om in 'n vinnige omgewing te werk. Ons wil tegniese organisasies hê versnel. Vinniger sagteware-aflewering beteken ook meer PR-ontplooiings, voorskouomgewings, prototipes en analitiese oplossings. Alles word op Kubernetes ontplooi. Wie het die tyd om toetsontplooiings handmatig skoon te maak? Dit is maklik om te vergeet om 'n week-oue eksperiment uit te vee. Die wolkrekening sal uiteindelik styg as gevolg van iets wat ons vergeet het om te sluit:

Bespaar op Kubernetes-wolkkoste op AWS

(Henning Jacobs:
Zhiza:
(aanhalings) Corey Quinn:
Mite: Jou AWS-rekening is 'n funksie van die aantal gebruikers wat jy het.
Feit: Jou AWS-telling is 'n funksie van die aantal ingenieurs wat jy het.

Ivan Kurnosov (in reaksie):
Werklike feit: Jou AWS-telling is 'n funksie van die aantal dinge wat jy vergeet het om te deaktiveer/vee.)

Kubernetes Janitor (kube-janitor) help om jou cluster skoon te maak. Die portierkonfigurasie is buigsaam vir beide globale en plaaslike gebruik:

  • Klusterwye reëls kan die maksimum tyd-tot-lewe (TTL) vir PR/toets-ontplooiings definieer.
  • Individuele hulpbronne kan geannoteer word met janitor/ttl, byvoorbeeld om die spike/prototipe outomaties na 7 dae te verwyder.

Algemene reëls word in die YAML-lêer gedefinieer. Sy pad word deur die parameter gevoer --rules-file in kube-oppasser. Hier is 'n voorbeeldreël om alle naamruimtes mee te verwyder -pr- in die naam na twee dae:

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

Die volgende voorbeeld reguleer die gebruik van die toepassingetiket op die Deployment- en StatefulSet-peule vir alle nuwe Deployments/StatefulSets in 2020, maar laat terselfdertyd die uitvoering van toetse sonder hierdie etiket vir 'n week toe:

- 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

Begin 'n tydbeperkte demonstrasie vir 30 minute op 'n groep wat kube-janitor loop:

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

Nog 'n bron van stygende koste is aanhoudende volumes (AWS EBS). Deur 'n Kubernetes StatefulSet uit te vee, vee nie sy aanhoudende volumes (PVC - PersistentVolumeClaim) uit nie. Ongebruikte EBS-volumes kan maklik koste van honderde dollars per maand tot gevolg hê. Kubernetes Janitor het 'n kenmerk om ongebruikte PVC's skoon te maak. Byvoorbeeld, hierdie reël sal alle PVC's verwyder wat nie deur 'n module gemonteer is nie en wat nie deur 'n StatefulSet of CronJob verwys word nie:

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

Kubernetes Janitor kan jou help om jou groep skoon te hou en te voorkom dat wolkrekenaarkoste stadig ophoop. Vir ontplooiing en konfigurasie instruksies, volg LEES MY kube-oppasser.

Verminder skaalvorming gedurende nie-werksure

Toets- en opstelstelsels word gewoonlik slegs gedurende besigheidsure benodig vir werking. Sommige produksietoepassings, soos back office/admin-nutsgoed, vereis ook slegs beperkte beskikbaarheid en kan oornag gedeaktiveer word.

Kubernetes Downscaler (kube-downscaler) laat gebruikers en operateurs toe om die stelsel af te skaal gedurende nie-werksure. Ontplooiings en StatefulSets kan skaal tot nul replikas. CronJobs kan geskors word. Kubernetes Downscaler is opgestel vir 'n hele groepering, een of meer naamruimtes of individuele hulpbronne. Jy kan óf "ledige tyd" of, omgekeerd, "werk tyd" stel. Byvoorbeeld, om skaalvorming soveel as moontlik gedurende nagte en naweke te verminder:

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

Hier is 'n grafiek vir die skaal van groepwerkernodusse oor naweke:

Bespaar op Kubernetes-wolkkoste op AWS

Afskaal van ~13 tot 4 werkernodusse maak beslis 'n merkbare verskil in jou AWS-rekening.

Maar wat as ek moet werk tydens die "stilstand" van die groep? Sekere ontplooiings kan permanent van skaal uitgesluit word deur die afskaaler/uitsluit: ware aantekening by te voeg. Ontplooiings kan tydelik uitgesluit word deur die afskaaler/uitsluit-tot-aantekening met 'n absolute tydstempel in die formaat JJJJ-MM-DD UU:MM (UTC) te gebruik. Indien nodig, kan die hele groep teruggeskaal word deur 'n peul met die aantekening te ontplooi downscaler/force-uptime, byvoorbeeld, deur nginx blank te begin:

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

Sien LEES MY kube-downscaler, as jy belangstel in ontplooiingsinstruksies en bykomende opsies.

Gebruik horisontale outoskaal

Baie toepassings/dienste hanteer 'n dinamiese laaipatroon: soms is hul modules ledig, en soms werk hulle op volle kapasiteit. Om 'n permanente vloot peule te bedryf om maksimum pieklading te hanteer, is nie ekonomies nie. Kubernetes ondersteun horisontale outo-skaal oor 'n hulpbron HorizontalPodAutoscaler (HPA). SVE-gebruik is dikwels 'n goeie aanwyser vir skaal:

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 het 'n komponent geskep om maklik pasgemaakte maatstawwe vir skaal te verbind: Kube Metrics Adapter (kube-metrics-adapter) is 'n generiese metrieke adapter vir Kubernetes wat pasgemaakte en eksterne metrieke vir horisontale outoskaal van peule kan versamel en bedien. Dit ondersteun skaal gebaseer op Prometheus-statistieke, SQS-rye en ander instellings. Byvoorbeeld, om jou ontplooiing te skaal na 'n pasgemaakte maatstaf wat deur die toepassing self as JSON in /metrics verteenwoordig word, gebruik:

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

Die opstel van horisontale outoskaling met HPA behoort een van die verstekaksies te wees om doeltreffendheid vir staatlose dienste te verbeter. Spotify het 'n aanbieding met hul ervaring en aanbevelings vir HPA: skaal jou ontplooiings, nie jou beursie nie.

Verminder hulpbronoorbespreking

Kubernetes-werkladings bepaal hul SVE/geheuebehoeftes deur middel van "hulpbronversoeke." SVE-hulpbronne word gemeet in virtuele kerns of meer algemeen in "millicores", byvoorbeeld 500m impliseer 50% vCPU. Geheuehulpbronne word in grepe gemeet, en algemene agtervoegsels kan gebruik word, soos 500Mi, wat 500 megagrepe beteken. Hulpbronversoeke "sluit" kapasiteit op werker nodusse, wat beteken dat 'n peul met 'n 1000m SVE versoek op 'n nodus met 4 vCPU's slegs 3 vCPU's beskikbaar sal laat vir ander peule. [1]

Slak (oortollige reserwe) is die verskil tussen aangevraagde hulpbronne en werklike gebruik. Byvoorbeeld, 'n peul wat 2 GiB geheue versoek, maar slegs 200 MiB gebruik, het ~1,8 GiB se "oortollige" geheue. Oormaat kos geld. Mens kan rofweg skat dat 1 GiB se oortollige geheue ~$10 per maand kos. [2]

Kubernetes Hulpbronverslag (kube-resource-report) vertoon oortollige reserwes en kan jou help om besparingspotensiaal te bepaal:

Bespaar op Kubernetes-wolkkoste op AWS

Kubernetes Hulpbronverslag toon die oormaat saamgevoeg deur toepassing en opdrag. Dit laat jou toe om plekke te vind waar hulpbroneise verminder kan word. Die gegenereerde HTML-verslag verskaf slegs 'n momentopname van hulpbrongebruik. Jy moet kyk na SVE/geheue gebruik oor tyd om voldoende hulpbronversoeke te bepaal. Hier is 'n Grafana-grafiek vir 'n "tipiese" SVE-swaar diens: alle peule gebruik aansienlik minder as die 3 gevraagde SVE-kerne:

Bespaar op Kubernetes-wolkkoste op AWS

Die vermindering van die SVE-versoek van 3000m tot ~400m maak hulpbronne vir ander werkladings vry en laat die groep kleiner wees.

"Gemiddelde SVE-gebruik van EC2-gevalle beweeg dikwels in die enkelsyfer-persentasiereeks," skryf Corey Quinn. Terwyl vir EC2 om die regte grootte te skat, kan 'n slegte besluit weesOm sommige Kubernetes-hulpbronnavrae in 'n YAML-lêer te verander, is maklik en kan groot besparings meebring.

Maar wil ons regtig hê dat mense waardes in YAML-lêers verander? Nee, masjiene kan dit baie beter doen! Kubernetes Vertical Pod Autoscaler (VPA) doen presies dit: pas hulpbronversoeke en -beperkings aan volgens die werklading. Hier is 'n voorbeeldgrafiek van Prometheus CPU-versoeke (dun blou lyn) wat mettertyd deur VPA aangepas is:

Bespaar op Kubernetes-wolkkoste op AWS

Zalando gebruik VPA in al sy groepe vir infrastruktuurkomponente. Nie-kritiese toepassings kan ook VPA gebruik.

Gouelokkies van Fairwind is 'n instrument wat 'n VPA vir elke ontplooiing in 'n naamruimte skep en dan 'n VPA-aanbeveling op sy dashboard vertoon. Dit kan ontwikkelaars help om die korrekte SVE/geheueversoeke vir hul toepassings in te stel:

Bespaar op Kubernetes-wolkkoste op AWS

Ek het 'n klein blogpos oor VPA in 2019, en onlangs in CNCF Eindgebruikersgemeenskap het VPA-kwessie bespreek.

Gebruik EC2 Spot Instances

Laastens, maar nie die minste nie, kan AWS EC2-koste verminder word deur Spot-gevalle as Kubernetes-werkknooppunte te gebruik [3]. Spotgevalle is beskikbaar teen 'n afslag van tot 90% in vergelyking met pryse op aanvraag. Om Kubernetes op EC2 Spot te laat loop is 'n goeie kombinasie: jy moet verskeie verskillende instansiestipes spesifiseer vir hoër beskikbaarheid, wat beteken dat jy 'n groter nodus vir dieselfde of laer prys kan kry, en die verhoogde kapasiteit kan gebruik word deur Kubernetes-werkladings in containers.

Hoe om Kubernetes op EC2 Spot te laat loop? Daar is verskeie opsies: gebruik 'n derdepartydiens soos SpotInst (nou genoem "Spot", moenie my vra hoekom nie), of voeg eenvoudig 'n Spot AutoScalingGroup (ASG) by jou groepering. Hier is byvoorbeeld 'n CloudFormation-brokkie vir 'n "kapasiteit-geoptimaliseerde" Spot ASG met verskeie instansietipes:

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"

Sommige notas oor die gebruik van Spot met Kubernetes:

  • Jy moet Spot-beëindigings hanteer, byvoorbeeld deur die nodus saam te voeg wanneer die instansie gestop word
  • Zalando gebruik vurk amptelike groep outoskaling met noduspoel-prioriteite
  • Spot nodusse gedwing kan word aanvaar "registrasies" van werkladings om in Spot uit te voer

Opsomming

Ek hoop dat u sommige van die instrumente wat aangebied word nuttig vind om u wolkrekening te verminder. Jy kan die meeste van die artikel se inhoud ook vind by my praatjie by DevOps Gathering 2019 op YouTube en in skyfies.

Wat is jou beste praktyke om wolkkoste op Kubernetes te bespaar? Laat weet my asseblief by Twitter (@probeer_behalwe_).

[1] Trouens, minder as 3 vCPU's sal bruikbaar bly aangesien die nodus se deurset deur gereserveerde stelselhulpbronne verminder word. Kubernetes onderskei tussen fisiese nodus kapasiteit en "voorsiene" hulpbronne (Node toekenbaar).

[2] Berekeningsvoorbeeld: een m5.groot instansie met 8 GiB geheue is ~$84 ​​​​per maand (eu-central-1, On-Demand), d.w.s. blokkering van 1/8 nodus is ongeveer ~$10/maand.

[3] Daar is baie meer maniere om jou EC2-rekening te verminder, soos Gereserveerde Gevalle, Spaarplan, ens. - Ek sal nie daardie onderwerpe hier dek nie, maar jy moet beslis daarna kyk!

Kom meer te wete oor die kursus.

Bron: will.com

Voeg 'n opmerking