Prihranite pri stroških oblaka Kubernetes na AWS

Prevod članka je bil pripravljen na predvečer začetka tečaja "Infrastrukturna platforma, ki temelji na Kubernetesu".

Kako prihraniti pri stroških v oblaku pri delu s Kubernetesom? Enotne prave rešitve ni, vendar ta članek opisuje več orodij, ki vam lahko pomagajo učinkoviteje upravljati vire in zmanjšati stroške računalništva v oblaku.

Ta članek sem napisal z mislijo na Kubernetes za AWS, vendar bo veljal (skoraj) na popolnoma enak način za druge ponudnike v oblaku. Predvidevam, da imajo vaše gruče že konfigurirano samodejno skaliranje (cluster-autoscaler). Z odstranitvijo virov in zmanjšanjem uvedbe boste denar prihranili le, če boste zmanjšali tudi vašo floto delovnih vozlišč (instance EC2).

Ta članek bo zajemal:

• čiščenje neuporabljenih virov (kube-hišnik)
• Zmanjšajte skaliranje v prostem času (kube-downscaler)
• z uporabo vodoravnega samodejnega skaliranja (HPA),
• zmanjšanje čezmerne rezervacije virov (kube-resource-report, VPA)
• z uporabo primerkov Spot

Čiščenje neuporabljenih virov

Delo v hitrem okolju je super. Želimo tehnološke organizacije pospešeno. Hitrejša dostava programske opreme pomeni tudi več uvedb PR, predoglednih okolij, prototipov in analitičnih rešitev. Vse je razporejeno na Kubernetes. Kdo ima čas za ročno čiščenje testnih uvedb? Na brisanje teden dni starega poskusa je enostavno pozabiti. Račun za oblak se bo na koncu povečal zaradi nečesa, kar smo pozabili zapreti:

(Henning Jacobs:
Zhiza:
(navedki) Corey Quinn:
Mit: Vaš račun AWS je funkcija števila uporabnikov, ki jih imate.
Dejstvo: vaš rezultat AWS je funkcija števila inženirjev, ki jih imate.

Ivan Kurnosov (v odgovor):
Resnično dejstvo: vaš rezultat AWS je funkcija števila stvari, ki ste jih pozabili onemogočiti/izbrisati.)

Kubernetes hišnik (kube-janitor) pomaga očistiti vašo gručo. Konfiguracija hišnika je prilagodljiva za globalno in lokalno uporabo:

• Pravila za celotno gručo lahko definirajo najdaljši čas življenja (TTL) za PR/testne uvedbe.
• Posamezne vire je mogoče označiti z janitor/ttl, na primer za samodejno odstranitev konice/prototipa po 7 dneh.

Splošna pravila so opredeljena v datoteki YAML. Njegova pot je podana skozi parameter --rules-file v kube-hišnik. Tukaj je primer pravila za odstranitev vseh imenskih prostorov -pr- v imenu po dveh dneh:

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

Naslednji primer ureja uporabo oznake aplikacije na sklopih Deployment in StatefulSet za vse nove Deployments/StatefulSets v letu 2020, vendar hkrati dovoljuje izvajanje testov brez te oznake za en teden:

- 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

Zaženite časovno omejeno predstavitev za 30 minut na gruči, v kateri se izvaja kube-janitor:

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

Drug vir naraščajočih stroškov so trajne količine (AWS EBS). Če izbrišete Kubernetes StatefulSet, ne izbrišete njegovih trajnih nosilcev (PVC – PersistentVolumeClaim). Neuporabljene količine EBS lahko zlahka povzročijo stroške v višini več sto dolarjev na mesec. Kubernetes Janitor ima funkcijo za čiščenje neuporabljenih PVC-jev. Na primer, to pravilo bo odstranilo vse PVC-je, ki niso nameščeni z modulom in na katere se ne sklicuje StatefulSet ali CronJob:

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

Kubernetes Janitor vam lahko pomaga ohraniti vašo gručo čisto in preprečiti, da bi se stroški računalništva v oblaku počasi kopičili. Za navodila za uvajanje in konfiguracijo sledite PREBERI ME kube-hišnik.

Zmanjšajte nastanek kamna v prostem času

Testni in uprizoritveni sistemi morajo običajno delovati le med delovnim časom. Nekatere produkcijske aplikacije, kot so zaledna/skrbniška orodja, prav tako zahtevajo le omejeno razpoložljivost in so lahko čez noč onemogočene.

Kubernetes Downscaler (kube-downscaler) omogoča uporabnikom in operaterjem, da zmanjšajo sistem v času izven delovnega časa. Razmestitve in StatefulSets se lahko prilagodijo na nič replik. CronJobs je lahko začasno ustavljen. Kubernetes Downscaler je konfiguriran za celotno gručo, enega ali več imenskih prostorov ali posamezne vire. Nastavite lahko "čas mirovanja" ali, nasprotno, "delovni čas". Na primer, da čim bolj zmanjšate skaliranje med nočmi in vikendi:

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

Tukaj je graf za skaliranje delovnih vozlišč gruče ob vikendih:

Zmanjšanje s ~13 na 4 delovna vozlišča zagotovo naredi opazno razliko v vašem računu za AWS.

Kaj pa, če moram delati med "nedelovanjem" gruče? Določene uvedbe je mogoče trajno izključiti iz skaliranja z dodajanjem opombe downscaler/exclude: true. Razmestitve je mogoče začasno izključiti z opombo downscaler/exclude-until z absolutnim časovnim žigom v obliki LLLL-MM-DD HH:MM (UTC). Po potrebi je mogoče celotno gručo pomanjšati z uvedbo sklopa z opombo downscaler/force-uptime, na primer z zagonom 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

Glej PREBERI ME kube-downscaler, če vas zanimajo navodila za uvajanje in dodatne možnosti.

Uporabite vodoravno samodejno skaliranje

Številne aplikacije/storitve se ukvarjajo z dinamičnim vzorcem nalaganja: včasih njihovi moduli mirujejo, včasih pa delujejo s polno zmogljivostjo. Upravljanje stalne flote strokov za obvladovanje največje konične obremenitve ni ekonomično. Kubernetes podpira vodoravno samodejno skaliranje po viru HorizontalPodAutoscaler (HPA). Uporaba procesorja je pogosto dober pokazatelj za skaliranje:

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 je ustvaril komponento za enostavno povezovanje meritev po meri za skaliranje: Adapter Kube Metrics (kube-metrics-adapter) je generični metrični adapter za Kubernetes, ki lahko zbira in streže prilagojene in zunanje metrike za horizontalno samodejno skaliranje podov. Podpira skaliranje na podlagi metrik Prometheus, čakalnih vrst SQS in drugih nastavitev. Na primer, če želite razširiti svojo uvedbo na meritev po meri, ki jo sama aplikacija predstavlja kot JSON v /metrics, uporabite:

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

Konfiguriranje vodoravnega samodejnega skaliranja s HPA bi moralo biti eno od privzetih dejanj za izboljšanje učinkovitosti storitev brez stanja. Spotify ima predstavitev z njihovimi izkušnjami in priporočili za HPA: razširite svoje uvedbe, ne denarnice.

Zmanjšajte prezasedenost virov

Delovne obremenitve Kubernetes določajo njihove potrebe po CPU/pomnilniku prek »zahtev za sredstva«. Sredstva procesorja se merijo v navideznih jedrih ali pogosteje v "milijedrih", na primer 500 m implicira 50 % vCPE. Pomnilniški viri se merijo v bajtih, uporabljajo pa se lahko običajne pripone, na primer 500Mi, kar pomeni 500 megabajtov. Zahteve za vir "zaklenejo" zmogljivost na delovnih vozliščih, kar pomeni, da bo pod z zahtevo 1000 m CPE na vozlišču s 4 vCPU pustil na voljo samo 3 vCPU drugim podom. [1]

Ohlapnost (presežna rezerva) je razlika med zahtevanimi viri in dejansko uporabo. Na primer, pod, ki zahteva 2 GiB pomnilnika, vendar uporablja le 200 MiB, ima ~1,8 GiB "odvečnega" pomnilnika. Presežek stane. Približno lahko ocenimo, da 1 GiB redundantnega pomnilnika stane ~10 USD na mesec. [2]

Poročilo o virih Kubernetes (kube-resource-report) prikazuje presežne rezerve in vam lahko pomaga določiti potencial prihranka:

Poročilo o virih Kubernetes prikazuje presežek, združen po aplikaciji in ukazu. To vam omogoča, da najdete mesta, kjer je mogoče zmanjšati zahteve po virih. Ustvarjeno poročilo HTML zagotavlja le posnetek uporabe virov. Če želite določiti ustrezne zahteve po sredstvih, morate pogledati porabo procesorja/pomnilnika skozi čas. Tukaj je grafikon Grafana za "tipično" storitev, ki je obremenjena s CPE: vsi sklopi uporabljajo bistveno manj kot 3 zahtevana jedra CPE:

Zmanjšanje zahteve CPE s 3000 m na ~ 400 m sprosti vire za druge delovne obremenitve in omogoči, da je gruča manjša.

»Povprečna poraba procesorja instanc EC2 se pogosto giblje v enomestnem razponu odstotkov,« piše Corey Quinn. Medtem ko za EC2 ocenjevanje prave velikosti je lahko slaba odločitevSpreminjanje nekaterih poizvedb virov Kubernetes v datoteki YAML je preprosto in lahko prinese velike prihranke.

Toda ali res želimo, da ljudje spreminjajo vrednosti v datotekah YAML? Ne, stroji zmorejo veliko bolje! Kubernetes Vertical Pod Autoscaler (VPA) naredi prav to: prilagodi zahteve za vire in omejitve glede na delovno obremenitev. Tukaj je primer grafa zahtev CPE Prometheus (tanka modra črta), ki jih je VPA prilagodil skozi čas:

Zalando uporablja VPA v vseh svojih grozdih za komponente infrastrukture. VPA lahko uporabljajo tudi nekritične aplikacije.

Goldilocks podjetja Fairwind je orodje, ki ustvari VPA za vsako uvedbo v imenskem prostoru in nato na svoji nadzorni plošči prikaže priporočilo VPA. Razvijalcem lahko pomaga pri nastavitvi pravilnih zahtev CPU/pomnilnika za njihove aplikacije:

Napisal sem majhno objava v blogu o VPA leta 2019, pred kratkim pa v Skupnost končnih uporabnikov CNCF je razpravljala o vprašanju VPA.

Uporaba točkovnih primerkov EC2

Nenazadnje je mogoče stroške AWS EC2 zmanjšati z uporabo instanc Spot kot delovnih vozlišč Kubernetes [3]. Promptni primerki so na voljo s popustom do 90 % v primerjavi s cenami na zahtevo. Izvajanje Kubernetesa na EC2 Spot je dobra kombinacija: določiti morate več različnih vrst instanc za višjo razpoložljivost, kar pomeni, da lahko dobite večje vozlišče za enako ali nižjo ceno, povečano zmogljivost pa lahko uporabijo kontejnerske delovne obremenitve Kubernetes.

Kako zagnati Kubernetes na EC2 Spot? Obstaja več možnosti: uporabite storitev tretje osebe, kot je SpotInst (zdaj imenovana "Spot", ne sprašujte me zakaj), ali preprosto dodajte skupino Spot AutoScalingGroup (ASG) v vašo gručo. Tukaj je na primer izrezek CloudFormation za "zmogljivo optimiziran" Spot ASG z več vrstami primerkov:

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"

Nekaj ​​opomb o uporabi Spot s Kubernetesom:

• Obravnavati morate zaključke Spot, na primer z združitvijo vozlišča, ko je primerek ustavljen
• Zalando uporablja vilice uradno samodejno skaliranje gruče s prioritetami področja vozlišč
• Spot vozlišča se lahko prisili sprejemajo "registracije" delovnih obremenitev za izvajanje v programu Spot

Povzetek

Upam, da se vam bodo zdela nekatera od predstavljenih orodij koristnih pri zmanjševanju računa za oblak. Večino vsebine članka najdete tudi na moj govor na srečanju DevOps Gathering 2019 na YouTubu in v diapozitivih.

Katere so vaše najboljše prakse za prihranek stroškov v oblaku na Kubernetesu? Prosim, sporočite mi na Twitter (@try_except_).

[1] Pravzaprav bodo ostali uporabni manj kot 3 vCPU-ji, saj se prepustnost vozlišča zmanjša zaradi rezerviranih sistemskih virov. Kubernetes razlikuje med zmogljivostjo fizičnega vozlišča in "zagotovljenimi" viri (Vozlišče, ki ga je mogoče dodeliti).

[2] Primer izračuna: ena instanca m5.large z 8 GiB pomnilnika znaša ~84 $ na mesec (eu-central-1, On-Demand), tj. blokiranje 1/8 vozlišča je približno ~10 USD/mesec.

[3] Obstaja veliko več načinov za znižanje računa EC2, kot so rezervirani primerki, varčevalni načrt itd. – teh tem ne bom obravnaval tukaj, vendar jih morate vsekakor preučiti!

Izvedite več o tečaju.

Vir: www.habr.com