Uštedite na troškovima oblaka Kubernetes na AWS-u

Prijevod članka pripremljen je uoči početka kursa "Infrastrukturna platforma zasnovana na Kubernetesu".

Kako uštedjeti na troškovima oblaka kada radite sa Kubernetesom? Ne postoji jedno pravo rešenje, ali ovaj članak opisuje nekoliko alata koji vam mogu pomoći da efikasnije upravljate svojim resursima i smanjite troškove računarstva u oblaku.

Napisao sam ovaj članak imajući na umu Kubernetes za AWS, ali će se primijeniti (skoro) na potpuno isti način na druge dobavljače oblaka. Pretpostavljam da vaši klasteri već imaju konfigurisano automatsko skaliranje (cluster-autoscaler). Uklanjanje resursa i smanjenje vaše implementacije će vam uštedjeti novac samo ako također smanjuje vašu flotu radnih čvorova (EC2 instance).

Ovaj članak će pokriti:

• čišćenje neiskorištenih resursa (kube-domar)
• Smanjite skaliranje tokom neradnog vremena (kube-downscaler)
• koristeći horizontalno automatsko skaliranje (HPA),
• smanjenje prekomjerne rezervacije resursa (kube-resource-report, VPA)
• koristeći Spot instance

Čišćenje neiskorištenih resursa

Rad u brzom okruženju je odličan. Želimo tehnološke organizacije ubrzano. Brža isporuka softvera također znači više implementacije PR-a, okruženja za pretpregled, prototipova i analitičkih rješenja. Sve je postavljeno na Kubernetes. Ko ima vremena za ručno čišćenje testnih implementacija? Lako je zaboraviti na brisanje sedmičnog eksperimenta. Račun za oblak će na kraju porasti zbog nečega što smo zaboravili zatvoriti:

(Henning Jacobs:
Zhiza:
(citati) Corey Quinn:
Mit: Vaš AWS nalog je funkcija broja korisnika koje imate.
Činjenica: Vaš AWS rezultat je funkcija broja inženjera koje imate.

Ivan Kurnosov (odgovara):
Stvarna činjenica: Vaš AWS rezultat je funkcija broja stvari koje ste zaboravili da onemogućite/izbrišete.)

Kubernetes Janitor (kube-janitor) pomaže u čišćenju vašeg klastera. Konfiguracija domara je fleksibilna za globalnu i lokalnu upotrebu:

• Pravila za cijeli klaster mogu definirati maksimalno vrijeme života (TTL) za PR/test implementacije.
• Individualni resursi mogu biti označeni sa janitor/ttl, na primjer za automatsko uklanjanje šiljka/prototipa nakon 7 dana.

Opšta pravila su definirana u YAML datoteci. Njegova putanja se propušta kroz parametar --rules-file u kube-domar. Evo primjera pravila za uklanjanje svih imenskih prostora -pr- u ime nakon dva dana:

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

Sljedeći primjer reguliše upotrebu oznake aplikacije na podovima Deployment i StatefulSet za sve nove Deployments/StatefulSetove u 2020. godini, ali istovremeno dozvoljava izvršavanje testova bez ove oznake na tjedan dana:

- 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

Pokrenite vremenski ograničenu demonstraciju u trajanju od 30 minuta na klasteru na kojem radi kube-janitor:

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

Još jedan izvor povećanja troškova su stalne količine (AWS EBS). Brisanjem Kubernetes StatefulSeta ne brišete njegove trajne volumene (PVC - PersistentVolumeClaim). Neiskorištene količine EBS-a mogu lako rezultirati troškovima od stotina dolara mjesečno. Kubernetes Janitor ima funkciju za čišćenje neiskorištenih PVC-a. Na primjer, ovo pravilo će ukloniti sve PVC-ove koji nisu montirani od strane modula i na koje ne upućuje StatefulSet ili 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 može pomoći da održite klaster čistim i spriječite da se troškovi računanja u oblaku polako gomilaju. Za upute za implementaciju i konfiguraciju, slijedite README kube-janitor.

Smanjite skaliranje tokom neradnog vremena

Sistemi za testiranje i postavljanje su obično potrebni za rad samo tokom radnog vremena. Neke proizvodne aplikacije, kao što su back office/admin alati, također zahtijevaju samo ograničenu dostupnost i mogu biti onemogućene preko noći.

Kubernetes Downscaler (kube-downscaler) omogućava korisnicima i operaterima da smanje sistem tokom neradnog vremena. Implementacije i StatefulSets mogu se skalirati na nulu replika. CronJobs mogu biti suspendovani. Kubernetes Downscaler je konfiguriran za cijeli klaster, jedan ili više imenskih prostora ili pojedinačne resurse. Možete podesiti ili "vrijeme mirovanja" ili, obrnuto, "vrijeme rada". Na primjer, da smanjite skaliranje što je više moguće tokom noći i vikenda:

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

Evo grafikona za skaliranje čvorova radnika klastera vikendom:

Smanjenje sa ~13 na 4 radna čvora svakako čini primjetnu razliku u vašem AWS računu.

Ali šta ako trebam raditi za vrijeme "zastoja" klastera? Određene implementacije se mogu trajno isključiti iz skaliranja dodavanjem napomene downscaler/exclude: true. Implementacije se mogu privremeno isključiti korištenjem napomene downscaler/exclude-until s apsolutnom vremenskom oznakom u formatu GGGG-MM-DD HH:MM (UTC). Ako je potrebno, cijeli klaster se može smanjiti postavljanjem modula s napomenom downscaler/force-uptime, na primjer, pokretanjem nginx blanka:

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

Vidite README kube-downscaler, ako vas zanimaju upute za implementaciju i dodatne opcije.

Koristite horizontalno automatsko skaliranje

Mnoge aplikacije/usluge rade sa dinamičkim obrascem učitavanja: ponekad su njihovi moduli neaktivni, a ponekad rade punim kapacitetom. Upravljanje stalnom flotom mahuna da se nosi s maksimalnim vršnim opterećenjem nije ekonomično. Kubernetes podržava horizontalno automatsko skaliranje preko resursa HorizontalPodAutoscaler (HPA). Upotreba CPU-a je često dobar 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 kreirao komponentu za jednostavno povezivanje prilagođenih metrika za skaliranje: Kube metrički adapter (kube-metrics-adapter) je generički adapter metrike za Kubernetes koji može prikupljati i posluživati ​​prilagođene i eksterne metrike za horizontalno automatsko skaliranje podova. Podržava skaliranje zasnovano na Prometheus metrikama, SQS redovima i drugim postavkama. Na primjer, da biste skalirali svoju implementaciju na prilagođenu metriku koju sama aplikacija predstavlja kao JSON u /metrics koristite:

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 horizontalnog automatskog skaliranja pomoću HPA trebala bi biti jedna od zadanih radnji za poboljšanje efikasnosti za usluge bez statusa. Spotify ima prezentaciju sa svojim iskustvom i preporukama za HPA: skalirajte svoje implementacije, a ne svoj novčanik.

Smanjite prebukiranje resursa

Kubernetes radna opterećenja određuju njihove potrebe za procesorom/memorijom kroz "zahtjeve za resurse". Resursi CPU-a se mjere u virtuelnim jezgrama ili češće u „milikorima“, na primjer 500m podrazumijeva 50% vCPU-a. Memorijski resursi se mjere u bajtovima, a mogu se koristiti uobičajeni sufiksi, kao što je 500Mi, što znači 500 megabajta. Zahtjevi za resurse "zaključavaju" kapacitet na radničkim čvorovima, što znači da će pod sa CPU zahtjevom od 1000m na ​​čvoru sa 4 vCPU-a ostaviti samo 3 vCPU-a na raspolaganju drugim podovima. [1]

Slack (višak rezerve) je razlika između traženih resursa i stvarne upotrebe. Na primjer, pod koji zahtijeva 2 GiB memorije, ali koristi samo 200 MiB ima ~1,8 GiB “viška” memorije. Višak košta. Može se grubo procijeniti da 1 GiB redundantne memorije košta ~10 dolara mjesečno. [2]

Izvještaj o Kubernetes resursima (kube-resource-report) prikazuje višak rezervi i može vam pomoći da odredite potencijal uštede:

Izvještaj o Kubernetes resursima prikazuje višak agregiran aplikacijom i komandom. Ovo vam omogućava da pronađete mjesta gdje se zahtjevi za resursima mogu smanjiti. Generisani HTML izveštaj daje samo snimak korišćenja resursa. Trebali biste pogledati korištenje CPU/memorije tokom vremena da odredite adekvatne zahtjeve za resursima. Evo Grafana grafikona za "tipičan" CPU-teški servis: svi podovi koriste znatno manje od 3 tražena CPU jezgra:

Smanjenje CPU zahtjeva sa 3000m na ​​~400m oslobađa resurse za druga radna opterećenja i omogućava da klaster bude manji.

“Prosječna upotreba CPU-a EC2 instanci često lebdi u jednocifrenom procentualnom rasponu,” piše Corey Quinn. Dok za EC2 procjena prave veličine može biti loša odlukaPromjena nekih Kubernetes upita resursa u YAML datoteci je jednostavna i može donijeti ogromne uštede.

Ali da li zaista želimo da ljudi mijenjaju vrijednosti u YAML datotekama? Ne, mašine to mogu mnogo bolje! Kubernetes Vertical Pod Autoscaler (VPA) radi upravo to: prilagođava zahtjeve za resurse i ograničenja prema radnom opterećenju. Evo primjera grafikona Prometheus CPU zahtjeva (tanka plava linija) koje je VPA prilagodio tokom vremena:

Zalando koristi VPA u svim svojim klasterima za infrastrukturne komponente. Nekritične aplikacije također mogu koristiti VPA.

zlatokosa od Fairwind-a je alat koji kreira VPA za svaku implementaciju u imenskom prostoru, a zatim prikazuje VPA preporuku na svojoj kontrolnoj tabli. Može pomoći programerima da postave ispravne CPU/memorijske zahtjeve za svoje aplikacije:

Napisao sam mali blog post o VPA 2019. godine, a nedavno u CNCF Zajednica krajnjih korisnika raspravljala je o pitanju VPA.

Korištenje EC2 Spot instanci

Na kraju, ali ne i najmanje važno, troškovi AWS EC2 mogu se smanjiti korištenjem Spot instanci kao Kubernetes radnih čvorova [3]. Spot instance su dostupne uz popust do 90% u odnosu na cijene na zahtjev. Pokretanje Kubernetes-a na EC2 Spot-u je dobra kombinacija: morate navesti nekoliko različitih tipova instanci za veću dostupnost, što znači da možete dobiti veći čvor za istu ili nižu cijenu, a povećani kapacitet može se koristiti za kontejnerizirana Kubernetes radna opterećenja.

Kako pokrenuti Kubernetes na EC2 Spot? Postoji nekoliko opcija: koristite uslugu treće strane kao što je SpotInst (sada se zove "Spot", ne pitajte me zašto) ili jednostavno dodajte Spot AutoScalingGroup (ASG) svom klasteru. Na primjer, evo CloudFormation isječka za "optimizirani kapacitet" Spot ASG s više tipova instanci:

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"

Neke napomene o korištenju Spot-a sa Kubernetesom:

• Morate rukovati Spot terminima, na primjer spajanjem čvora kada je instanca zaustavljena
• Zalando koristi viljuška službeno automatsko skaliranje klastera s prioritetima skupa čvorova
• Spot čvorovi može biti prisiljen prihvatite “registracije” radnih opterećenja za pokretanje u Spot-u

Rezime

Nadam se da će vam neki od predstavljenih alata biti korisni za smanjenje vašeg računa u oblaku. Većinu sadržaja članka možete pronaći i na moj govor na DevOps Gathering 2019 na YouTube-u i u slajdovima.

Koje su vaše najbolje prakse za uštedu troškova oblaka na Kubernetesu? Obavijestite me na Twitter (@try_except_).

[1] U stvari, manje od 3 vCPU-a će ostati upotrebljivo jer je propusnost čvora smanjena rezervisanim sistemskim resursima. Kubernetes pravi razliku između kapaciteta fizičkog čvora i "omogućenih" resursa (Node Allocatable).

[2] Primjer izračuna: jedna m5.large instanca sa 8 GiB memorije je ~84$ mjesečno (eu-central-1, On-Demand), tj. blokiranje 1/8 čvora je otprilike ~10$ mjesečno.

[3] Postoji mnogo više načina da smanjite svoj EC2 račun, kao što su rezervisane instance, štedni plan, itd. - Neću se baviti tim temama ovdje, ali svakako ih trebate pogledati!

Saznajte više o kursu.

izvor: www.habr.com