Ušetrite na nákladoch na cloud Kubernetes na AWS

Preklad článku bol pripravený v predstihu pred začiatkom kurzu "Platforma infraštruktúry založená na Kubernetes".

Ako ušetriť na nákladoch na cloud pri práci s Kubernetes? Neexistuje jediné správne riešenie, ale tento článok popisuje niekoľko nástrojov, ktoré vám môžu pomôcť efektívnejšie spravovať vaše zdroje a znížiť náklady na cloud computing.

Tento článok som napísal s ohľadom na Kubernetes pre AWS, ale bude platiť (takmer) úplne rovnako pre iných poskytovateľov cloudu. Predpokladám, že vaše klastre už majú nakonfigurované automatické škálovanie (cluster-autoscaler). Odstránenie zdrojov a zmenšenie vášho nasadenia vám ušetrí peniaze len vtedy, ak zníži aj vašu flotilu pracovných uzlov (inštancie EC2).

Tento článok sa bude týkať:

• čistenie nevyužitých zdrojov (kube-správca)
• Znížte škálovanie počas mimopracovných hodín (kube-downscaler)
• pomocou horizontálneho automatického škálovania (HPA),
• zníženie nadmernej rezervácie zdrojov (kube-resource-report, VPA)
• pomocou inštancií Spot

Čistenie nevyužitých zdrojov

Práca v rýchlom prostredí je skvelá. Chceme technologické organizácie zrýchlené. Rýchlejšie dodanie softvéru tiež znamená viac nasadení PR, ukážkových prostredí, prototypov a analytických riešení. Všetko je nasadené na Kubernetes. Kto má čas manuálne čistiť testovacie nasadenia? Je ľahké zabudnúť na vymazanie týždeň starého experimentu. Účet za cloud nakoniec stúpne kvôli niečomu, čo sme zabudli uzavrieť:

(Henning Jacobs:
Zhiza:
(citáty) Corey Quinn:
Mýtus: Váš účet AWS závisí od počtu používateľov, ktorých máte.
Fakt: Vaše skóre AWS je funkciou počtu inžinierov, ktorých máte.

Ivan Kurnosov (v reakcii):
Skutočná skutočnosť: Vaše skóre AWS je funkciou počtu vecí, ktoré ste zabudli zakázať/vymazať.)

Kubernetes Janitor (kube-janitor) pomáha vyčistiť váš klaster. Konfigurácia správcu je flexibilná pre globálne aj lokálne použitie:

• Pravidlá pre celý klaster môžu definovať maximálny čas životnosti (TTL) pre PR/testovacie nasadenia.
• Jednotlivé zdroje môžu byť anotované správcom/ttl, napríklad na automatické odstránenie hrotu/prototypu po 7 dňoch.

Všeobecné pravidlá sú definované v súbore YAML. Jeho cesta prechádza cez parameter --rules-file v kube- školník. Tu je príklad pravidla na odstránenie všetkých menných priestorov -pr- v mene po dvoch dňoch:

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

Nasledujúci príklad upravuje používanie označenia aplikácie na moduloch Deployment a StatefulSet pre všetky nové nasadenia/StatefulSets v roku 2020, no zároveň umožňuje vykonávanie testov bez tohto označenia na týždeň:

- 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

Spustite časovo obmedzenú ukážku na 30 minút na klastri so systémom kube-janitor:

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

Ďalším zdrojom zvyšovania nákladov sú trvalé objemy (AWS EBS). Odstránením Kubernetes StatefulSet sa neodstránia jeho trvalé zväzky (PVC - PersistentVolumeClaim). Nevyužité objemy EBS môžu ľahko viesť k nákladom v stovkách dolárov mesačne. Kubernetes Janitor má funkciu na čistenie nepoužívaných PVC. Toto pravidlo napríklad odstráni všetky PVC, ktoré nie sú namontované modulom a na ktoré sa neodkazuje StatefulSet alebo 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ám môže pomôcť udržať váš klaster čistý a zabrániť pomalému hromadeniu nákladov na cloud computing. Pokyny na nasadenie a konfiguráciu nájdete podľa pokynov README kube-správca.

Znížte tvorbu vodného kameňa počas mimopracovných hodín

Skúšobné a prípravné systémy sú zvyčajne potrebné na prevádzku iba počas pracovných hodín. Niektoré produkčné aplikácie, ako napríklad nástroje back office/admin, tiež vyžadujú len obmedzenú dostupnosť a môžu byť cez noc deaktivované.

Kubernetes Downscaler (kube-downscaler) umožňuje používateľom a operátorom zmenšiť systém počas mimopracovných hodín. Nasadenia a stavové sady sa môžu škálovať na nulové repliky. CronJobs môže byť pozastavený. Kubernetes Downscaler je nakonfigurovaný pre celý klaster, jeden alebo viacero menných priestorov alebo jednotlivé zdroje. Môžete nastaviť buď „čas nečinnosti“ alebo naopak „čas práce“. Napríklad, aby ste čo najviac obmedzili tvorbu vodného kameňa počas nocí a víkendov:

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

Tu je graf pre škálovanie pracovných uzlov klastra cez víkendy:

Zmenšenie z ~13 na 4 pracovné uzly určite spôsobí výrazný rozdiel vo vašom účte za AWS.

Ale čo ak potrebujem pracovať počas „prestoja“ klastra? Určité nasadenia možno natrvalo vylúčiť zo škálovania pridaním anotácie downscaler/exclude: true. Nasadenia je možné dočasne vylúčiť pomocou anotácie downscaler/exclude-until s absolútnou časovou pečiatkou vo formáte RRRR-MM-DD HH:MM (UTC). V prípade potreby je možné celý klaster zmenšiť nasadením modulu s anotáciou downscaler/force-uptime, napríklad spustením 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

Vidieť README kube-downscaler, ak máte záujem o návod na nasadenie a ďalšie možnosti.

Použite horizontálne automatické škálovanie

Mnoho aplikácií/služieb sa zaoberá dynamickým vzorom načítania: niekedy sú ich moduly nečinné a niekedy pracujú na plnú kapacitu. Prevádzka stálej flotily modulov na zvládnutie maximálneho špičkového zaťaženia nie je hospodárna. Kubernetes podporuje horizontálne automatické škálovanie naprieč zdrojom HorizontalPodAutoscaler (HPA). Využitie CPU je často dobrým indikátorom pre škálovanie:

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 vytvorilo komponent na jednoduché prepojenie vlastných metrík na škálovanie: Adaptér Kube Metrics Adapter (kube-metrics-adapter) je všeobecný adaptér metrík pre Kubernetes, ktorý dokáže zhromažďovať a poskytovať vlastné a externé metriky na horizontálne automatické škálovanie modulov. Podporuje škálovanie na základe metrík Prometheus, frontov SQS a ďalších nastavení. Napríklad, ak chcete škálovať svoje nasadenie na vlastnú metriku reprezentovanú samotnou aplikáciou ako JSON v /metrics, použite:

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

Konfigurácia horizontálneho automatického škálovania pomocou HPA by mala byť jednou z predvolených akcií na zlepšenie efektívnosti služieb bez stavu. Spotify má prezentáciu s ich skúsenosťami a odporúčaniami pre HPA: škálovať svoje nasadenia, nie peňaženku.

Znížte nadmernú rezerváciu zdrojov

Pracovné zaťaženie Kubernetes určuje ich potreby CPU/pamäte prostredníctvom „žiadostí o zdroje“. Zdroje CPU sa merajú vo virtuálnych jadrách alebo častejšie v „milijadrách“, napríklad 500 m znamená 50 % vCPU. Pamäťové zdroje sa merajú v bajtoch a možno použiť bežné prípony, ako napríklad 500Mi, čo znamená 500 megabajtov. Požiadavky na zdroje „uzamknú“ kapacitu na pracovných uzloch, čo znamená, že modul s požiadavkou CPU na 1000 m na uzle so 4 vCPU ponechá ostatným modulom k dispozícii iba 3 vCPU. [1]

Slack (nadmerná rezerva) je rozdiel medzi požadovanými zdrojmi a skutočným využitím. Napríklad modul, ktorý požaduje 2 GiB pamäte, ale využíva iba 200 MiB, má ~1,8 GiB „nadbytočnej“ pamäte. Prebytok stojí peniaze. Dá sa zhruba odhadnúť, že 1 GiB redundantnej pamäte stojí ~ 10 dolárov mesačne. [2]

Správa o zdrojoch Kubernetes (kube-resource-report) zobrazuje prebytočné rezervy a môže vám pomôcť určiť potenciál úspor:

Správa o zdrojoch Kubernetes zobrazuje prebytok agregovaný podľa aplikácie a príkazu. To vám umožní nájsť miesta, kde je možné znížiť nároky na zdroje. Vygenerovaná správa HTML poskytuje iba prehľad využitia zdrojov. Mali by ste sa pozrieť na využitie CPU/pamäte v priebehu času, aby ste určili adekvátne požiadavky na prostriedky. Tu je graf Grafana pre „typickú“ službu s veľkým množstvom CPU: všetky moduly využívajú podstatne menej ako 3 požadované jadrá CPU:

Zníženie požiadavky CPU z 3000 400 m na ~ XNUMX m uvoľňuje zdroje pre iné pracovné zaťaženie a umožňuje, aby bol klaster menší.

„Priemerné využitie CPU inštancií EC2 sa často pohybuje v jednocifernom percentuálnom rozsahu,“ píše Corey Quinn. Zatiaľ čo pre EC2 odhadnúť správnu veľkosť môže byť zlé rozhodnutieZmena niektorých dotazov na zdroje Kubernetes v súbore YAML je jednoduchá a môže priniesť obrovské úspory.

Ale naozaj chceme, aby ľudia menili hodnoty v súboroch YAML? Nie, stroje to dokážu oveľa lepšie! Kubernetes Vertikálny stojan Autoscaler (VPA) robí práve to: prispôsobuje požiadavky na zdroje a obmedzenia podľa pracovného zaťaženia. Tu je príklad grafu požiadaviek CPU Prometheus (tenká modrá čiara) prispôsobených VPA v priebehu času:

Zalando používa VPA vo všetkých svojich klastroch pre komponenty infraštruktúry. VPA môžu používať aj nekritické aplikácie.

Zlatovláska od Fairwind je nástroj, ktorý vytvorí VPA pre každé nasadenie v mennom priestore a potom zobrazí odporúčanie VPA na svojom dashboarde. Môže to pomôcť vývojárom nastaviť správne požiadavky na CPU/pamäť pre ich aplikácie:

Napísal som malý blogový príspevok o VPA v roku 2019 a nedávno v Komunita koncových používateľov CNCF diskutovala o probléme VPA.

Použitie bodových inštancií EC2

V neposlednom rade je možné znížiť náklady na AWS EC2 použitím inštancií Spot ako pracovných uzlov Kubernetes [3]. Spotové inštancie sú k dispozícii so zľavou až 90 % v porovnaní s cenami na požiadanie. Spustenie Kubernetes na EC2 Spot je dobrá kombinácia: musíte špecifikovať niekoľko rôznych typov inštancií pre vyššiu dostupnosť, čo znamená, že môžete získať väčší uzol za rovnakú alebo nižšiu cenu a zvýšenú kapacitu môžu využiť kontajnerizované pracovné zaťaženia Kubernetes.

Ako spustiť Kubernetes na EC2 Spot? Existuje niekoľko možností: použite službu tretej strany, ako je SpotInst (teraz nazývaná „Spot“, nepýtajte sa ma prečo), alebo jednoducho pridajte Spot AutoScalingGroup (ASG) do svojho klastra. Tu je napríklad úryvok CloudFormation pre „kapacitne optimalizovaný“ Spot ASG s viacerými typmi inštancií:

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"

Niekoľko poznámok k používaniu Spotu s Kubernetes:

• Musíte zvládnuť ukončenia Spot, napríklad zlúčením uzla, keď je inštancia zastavená
• Zalando používa vidlička oficiálne automatické škálovanie klastrov s prioritami oblasti uzlov
• Bodové uzly môže byť nútený akceptujte „registrácie“ pracovných zaťažení na spustenie v službe Spot

Zhrnutie

Dúfam, že niektoré z prezentovaných nástrojov považujete za užitočné pri znižovaní účtu za cloud. Väčšinu obsahu článku nájdete aj na moja prednáška na DevOps Gathering 2019 na YouTube a v snímkach.

Aké sú vaše osvedčené postupy na šetrenie nákladov na cloud na Kubernetes? Dajte mi prosím vedieť na Twitter (@try_except_).

[1] V skutočnosti zostanú použiteľné menej ako 3 vCPU, pretože priepustnosť uzla je znížená o rezervované systémové prostriedky. Kubernetes rozlišuje medzi fyzickou kapacitou uzla a „poskytnutými“ zdrojmi (Prideliteľný uzol).

[2] Príklad výpočtu: jedna m5.veľká inštancia s 8 GiB pamäte je ~84 $ mesačne (eu-central-1, On-Demand), t.j. blokovanie 1/8 uzla je približne ~10 USD mesačne.

[3] Existuje mnoho ďalších spôsobov, ako znížiť váš účet za EC2, ako sú rezervované inštancie, plán sporenia atď. – nebudem sa tu zaoberať týmito témami, ale určite by ste sa na ne mali pozrieť!

Zistite viac o kurze.

Zdroj: hab.com