Takarítson meg Kubernetes felhőköltségeit az AWS-en

A cikk fordítása a tanfolyam kezdetének előestéjén készült "Kubernetes alapú infrastruktúra-platform".

Hogyan takaríthat meg felhőköltségeket a Kubernetes-el való munka során? Nincs egyetlen helyes megoldás, de ez a cikk számos olyan eszközt ismertet, amelyek segítségével hatékonyabban kezelheti erőforrásait, és csökkentheti a számítási felhő költségeit.

Ezt a cikket a Kubernetes for AWS szem előtt tartásával írtam, de (majdnem) pontosan ugyanúgy fog vonatkozni más felhőszolgáltatókra is. Feltételezem, hogy a fürt(ek)ben már be van állítva az automatikus skálázás (cluster-autoscaler). Az erőforrások eltávolítása és a telepítés kicsinyítése csak akkor takarít meg pénzt, ha csökkenti a dolgozói csomópontok flottáját (EC2 példányok).

Ez a cikk a következőkre terjed ki:

• a fel nem használt erőforrások megtisztítása (kube-házmester)
• Csökkentse a méretezést munkaidőn kívül (kube-downscaler)
• vízszintes automatikus skálázás (HPA) használatával,
• a túlzott erőforrás-foglalás csökkentése (kube-resource-report, VPA)
• Spot példányok használatával

A fel nem használt erőforrások megtisztítása

Felgyorsult környezetben dolgozni nagyszerű. Technikai szervezeteket akarunk felgyorsult. A gyorsabb szoftverszállítás több PR-telepítést, előnézeti környezeteket, prototípusokat és elemzési megoldásokat is jelent. Minden telepítve van a Kubernetesen. Kinek van ideje manuálisan megtisztítani a teszttelepítéseket? Könnyű elfelejteni egy hetes kísérlet törlését. A felhőszámla végül növekedni fog valami miatt, amit elfelejtettünk bezárni:

(Henning Jacobs:
Zhiza:
(idézetek) Corey Quinn:
Tévhit: Az AWS-fiókja a felhasználói szám függvénye.
Tény: Az AWS-pontszám a mérnökei számának függvénye.

Ivan Kurnosov (válaszként):
Valós tény: Az AWS-pontszám azon dolgok számától függ, amelyeket elfelejtett letiltani/törölni.)

Kubernetes házmester (kube-janitor) segít megtisztítani a klasztert. A portás konfiguráció rugalmas mind globális, mind helyi használatra:

• A fürtszintű szabályok meghatározhatják a PR/teszttelepítések maximális élettartamát (TTL).
• Az egyes erőforrásokhoz a janitor/ttl segítségével lehet megjegyzéseket fűzni, például a spike/prototípus automatikus eltávolításához 7 nap után.

Az általános szabályokat a YAML fájl határozza meg. Útja áthalad a paraméteren --rules-file kube-házmesterben. Íme egy példaszabály az összes névtér eltávolításához -pr- a névben két nap után:

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

A következő példa szabályozza az alkalmazáscímke használatát a Deployment és StatefulSet podokon minden új telepítés/StatefulSet esetében 2020-ban, ugyanakkor lehetővé teszi a tesztek végrehajtását e címke nélkül egy hétig:

- 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

Futtasson egy korlátozott ideig tartó demót 30 percig a kube-janitort futtató fürtön:

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

A növekvő költségek másik forrása a tartós volumen (AWS EBS). A Kubernetes StatefulSet törlése nem törli annak állandó köteteit (PVC – PersistentVolumeClaim). A fel nem használt EBS-kötetek könnyen több száz dolláros költséggel járhatnak havonta. A Kubernetes Janitor funkcióval rendelkezik a fel nem használt PVC-k tisztítására. Ez a szabály például eltávolítja az összes olyan PVC-t, amelyet nem egy modul szerel fel, és amelyekre nem hivatkozik a StatefulSet vagy a CronJob:

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

A Kubernetes Janitor segíthet a fürt tisztán tartásában, és megakadályozhatja, hogy a felhőalapú számítástechnikai költségek lassan felhalmozódjanak. A telepítési és konfigurációs utasításokért kövesse a következőt README kube-janitor.

Csökkentse a méretezést munkaidőn kívül

Teszt- és állomásozórendszerekre jellemzően csak munkaidőben történő működéshez van szükség. Egyes éles alkalmazások, például a háttérirodai/adminisztrátori eszközök, szintén csak korlátozott rendelkezésre állást igényelnek, és egyik napról a másikra letilthatók.

Kubernetes Downscaler (kube-downscaler) lehetővé teszi a felhasználóknak és a kezelőknek, hogy a munkaidőn kívüli idő alatt lekicsinyítsék a rendszert. A telepítések és a StatefulSets nulla replikára méretezhetők. A CronJobs felfüggeszthető. A Kubernetes Downscaler egy teljes fürthöz, egy vagy több névtérhez vagy egyedi erőforrásokhoz van konfigurálva. Beállíthatja az „üresjárati időt”, vagy fordítva, a „munkaidőt”. Például a méretezés csökkentése érdekében éjszaka és hétvégén:

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

Íme egy grafikon a fürt dolgozói csomópontok hétvégi skálázásához:

A ~13-ról 4-re kicsinyítés minden bizonnyal észrevehető különbséget jelent az AWS-számlában.

De mi van akkor, ha a fürt „leállása” alatt kell dolgoznom? Egyes telepítések véglegesen kizárhatók a méretezésből a downscaler/exclude: true annotation hozzáadásával. Az üzembe helyezések ideiglenesen kizárhatók a leskálázó/kizárásig megjegyzés használatával, abszolút időbélyeggel, ÉÉÉÉ-HH-NN ÓÓ:PP (UTC). Ha szükséges, a teljes fürt visszaméretezhető a megjegyzéssel ellátott pod telepítésével downscaler/force-uptimepéldául az nginx blank elindításával:

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

Lát README kube-downscaler, ha érdeklik a telepítési utasítások és a további lehetőségek.

Használjon vízszintes automatikus skálázást

Sok alkalmazás/szolgáltatás dinamikus betöltési mintával foglalkozik: néha tétlenek a moduljaik, néha teljes kapacitással működnek. A maximális csúcsterheléssel való megbirkózás érdekében nem gazdaságos egy állandó tokflotta működtetése. A Kubernetes támogatja a vízszintes automatikus skálázást egy erőforráson keresztül HorizontalPodAutoscaler (HPA). A CPU-használat gyakran jó mutató a méretezéshez:

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

A Zalando létrehozott egy komponenst, amellyel egyszerűen csatlakoztathatók az egyéni mutatók a méretezéshez: Kube Metrics Adapter (kube-metrics-adapter) egy általános metrika-adapter a Kubernetes számára, amely egyéni és külső metrikákat gyűjthet és szolgálhat ki a sorba rendezések vízszintes automatikus skálázásához. Támogatja a Prometheus-metrikákon, az SQS-sorokon és egyéb beállításokon alapuló skálázást. Ha például a telepítést egy egyéni mérőszámra kívánja méretezni, amelyet maga az alkalmazás JSON-ként képvisel a /metrics mappában, használja a következőket:

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

A vízszintes automatikus skálázás HPA-val történő konfigurálása az egyik alapértelmezett művelet az állapot nélküli szolgáltatások hatékonyságának javítása érdekében. A Spotify bemutatót tart a HPA-val kapcsolatos tapasztalataikkal és ajánlásaikkal: méretezheti a telepítéseket, nem a pénztárcáját.

Az erőforrások túlfoglalásának csökkentése

A Kubernetes munkaterhelései az „erőforrás-kérések” révén határozzák meg a CPU-/memóriaigényeiket. A CPU erőforrásait virtuális magokban vagy gyakrabban „millicore”-ban mérik, például az 500 m 50%-os vCPU-t jelent. A memória erőforrásait bájtokban mérik, és általános utótagok is használhatók, például 500Mi, ami 500 megabájtot jelent. Az erőforráskérések „zárolják” a dolgozói csomópontok kapacitását, ami azt jelenti, hogy egy 1000 m-es CPU-kéréssel rendelkező pod egy 4 vCPU-val rendelkező csomóponton csak 3 vCPU-t hagy más pod-ok rendelkezésére. [1]

Laza (többlettartalék) a kért erőforrások és a tényleges felhasználás közötti különbség. Például egy pod, amely 2 GiB memóriát igényel, de csak 200 MiB-ot használ, ~1,8 GiB „felesleges” memóriával rendelkezik. A többlet pénzbe kerül. Nagyjából megbecsülhető, hogy 1 GiB redundáns memória havonta ~10 dollárba kerül. [2]

Kubernetes erőforrásjelentés (kube-resource-report) megjeleníti a felesleges tartalékokat, és segíthet meghatározni a megtakarítási lehetőségeket:

Kubernetes erőforrásjelentés a többletet mutatja alkalmazásonként és parancsonként összesítve. Ez lehetővé teszi, hogy olyan helyeket találjon, ahol az erőforrásigény csökkenthető. Az előállított HTML-jelentés csak pillanatképet ad az erőforrás-használatról. Meg kell vizsgálnia a CPU/memóriahasználatot az idő múlásával a megfelelő erőforrásigények meghatározásához. Íme egy Grafana diagram egy "tipikus" CPU-igényes szolgáltatáshoz: minden pod sokkal kevesebbet használ, mint a 3 kért CPU mag:

A CPU-igény 3000 méterről ~400 méterre való csökkentése erőforrásokat szabadít fel más munkaterhelések számára, és lehetővé teszi a fürt kisebb méretét.

„Az EC2 példányok átlagos CPU-használata gyakran az egyszámjegyű százalékos tartományban mozog” írja Corey Quinn. Míg az EC2-re a megfelelő méret megbecslése rossz döntés lehetEgyes Kubernetes-erőforrás-lekérdezések megváltoztatása egy YAML-fájlban egyszerű, és hatalmas megtakarításokat eredményezhet.

De tényleg azt akarjuk, hogy az emberek megváltoztatják a YAML-fájlok értékeit? Nem, a gépek sokkal jobban meg tudják csinálni! Kubernetes Vertical Pod Autoscaler (VPA) éppen ezt teszi: a munkaterheléshez igazítja az erőforráskéréseket és a megszorításokat. Íme egy példadiagram a Prometheus CPU-kéréseiről (vékony kék vonal), amelyet a VPA idővel adaptált:

A Zalando minden klaszterében VPA-t használ infrastruktúra-elemek esetében. A nem kritikus alkalmazások is használhatják a VPA-t.

Boglárka A Fairwind egy olyan eszköz, amely VPA-t hoz létre minden egyes telepítéshez egy névtérben, majd megjelenít egy VPA-ajánlást az irányítópulton. Segíthet a fejlesztőknek beállítani a megfelelő CPU/memóriakérelmeket alkalmazásaikhoz:

Kicsit írtam blogbejegyzés a VPA-ról 2019-ben és nemrégiben A CNCF végfelhasználói közössége megvitatta a VPA problémáját.

EC2 spot példányok használata

Végül, de nem utolsósorban, az AWS EC2 költségei csökkenthetők, ha a Spot példányokat Kubernetes munkavégző csomópontként használjuk [3]. A helyszíni példányok akár 90%-os kedvezménnyel kaphatók az On-Demand árakhoz képest. A Kubernetes futtatása EC2 Spot-on jó kombináció: több különböző példánytípust kell megadni a magasabb rendelkezésre állás érdekében, vagyis azonos vagy alacsonyabb áron kaphatunk nagyobb csomópontot, a megnövekedett kapacitást pedig konténeres Kubernetes-munkaterhelések használhatják.

Hogyan kell futtatni a Kubernetes-et az EC2 Spot-on? Több lehetőség is van: használjon harmadik féltől származó szolgáltatást, például a SpotInst-et (most neve "Spot", ne kérdezze, miért), vagy egyszerűen adjon hozzá egy Spot AutoScalingGroup-ot (ASG) a fürthöz. Például itt van egy CloudFormation kódrészlet egy „kapacitás-optimalizált” Spot ASG-hez több példánytípussal:

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"

Néhány megjegyzés a Spot Kubernetes használatával kapcsolatban:

• A Spot-lezárásokat kezelnie kell, például a csomópont egyesítésével, amikor a példány leáll
• Zalando használ Villa hivatalos fürt automatikus skálázás csomópontkészlet prioritásokkal
• Spot csomópontok kényszeríthető elfogadja a munkaterhelések „regisztrációit” a Spotban történő futtatáshoz

Összegzés

Remélem, hasznosnak talál néhány bemutatott eszközt a felhőalapú számlák csökkentésében. A cikk tartalmának nagy részét a címen is megtalálja előadásom a DevOps Gathering 2019-en a YouTube-on és a diákban.

Melyek a legjobb gyakorlatok a Kubernetes felhőköltségeinek megtakarítására? Kérem jelezze a címen Twitter (@try_except_).

[1] Valójában kevesebb mint 3 vCPU marad használható, mivel a csomópont átviteli sebességét csökkentik a fenntartott rendszererőforrások. A Kubernetes különbséget tesz a fizikai csomóponti kapacitás és a "kiosztott" erőforrások között (Csomópont allokálható).

[2] Számítási példa: egy m5.large példány 8 GiB memóriával ~84 USD havonta (eu-central-1, On-Demand), azaz. az 1/8 csomópont blokkolása körülbelül ~10 USD/hó.

[3] Az EC2-számla csökkentésének még sok más módja van, mint például lefoglalt példányok, megtakarítási terv stb. – itt nem térek ki ezekre a témákra, de mindenképpen utána kell nézni!

Tudjon meg többet a tanfolyamról.

Forrás: will.com