Ušetřete na cloudových nákladech Kubernetes na AWS

Překlad článku byl připraven v předvečer zahájení kurzu "Infrastrukturní platforma založená na Kubernetes".

Jak ušetřit na nákladech na cloud při práci s Kubernetes? Neexistuje jediné správné řešení, ale tento článek popisuje několik nástrojů, které vám mohou pomoci efektivněji spravovat vaše zdroje a snížit náklady na cloud computing.

Tento článek jsem napsal s ohledem na Kubernetes pro AWS, ale bude platit (téměř) úplně stejně pro ostatní poskytovatele cloudu. Předpokládám, že vaše clustery již mají nakonfigurované automatické škálování (cluster-autoscaler). Odebrání zdrojů a zmenšení vašeho nasazení vám ušetří peníze pouze v případě, že také sníží vaši flotilu pracovních uzlů (instance EC2).

Tento článek se bude týkat:

• vyčištění nevyužitých zdrojů (kube školník)
• Omezte škálování mimo pracovní dobu (kube-downscaler)
• pomocí horizontálního automatického škálování (HPA),
• snížení nadměrné rezervace zdrojů (kube-resource-report, VPA)
• pomocí instancí Spot

Čištění nevyužitých zdrojů

Práce v rychlém prostředí je skvělá. Chceme technologické organizace zrychlený. Rychlejší dodání softwaru také znamená více nasazení PR, náhledových prostředí, prototypů a analytických řešení. Vše je nasazeno na Kubernetes. Kdo má čas ručně čistit testovací nasazení? Je snadné zapomenout na smazání týden starého experimentu. Účet za cloud nakonec stoupne kvůli něčemu, co jsme zapomněli uzavřít:

(Henning Jacobs:
Zhiza:
(citáty) Corey Quinn:
Mýtus: Váš účet AWS je funkcí počtu uživatelů, které máte.
Fakt: Vaše skóre AWS je funkcí počtu inženýrů, které máte.

Ivan Kurnosov (v reakci):
Skutečná skutečnost: Vaše skóre AWS je funkcí počtu věcí, které jste zapomněli zakázat/smazat.)

Kubernetes Janitor (kube-janitor) pomáhá vyčistit váš cluster. Konfigurace správce je flexibilní pro globální i místní použití:

• Pravidla pro celý klastr mohou definovat maximální dobu životnosti (TTL) pro PR/testovací nasazení.
• Jednotlivé zdroje mohou být anotovány pomocí správce/ttl, například pro automatické odstranění hrotu/prototypu po 7 dnech.

Obecná pravidla jsou definována v souboru YAML. Jeho cesta je předána přes parametr --rules-file v kube-domovník. Zde je příklad pravidla pro odstranění všech jmenných prostorů -pr- jménem po dvou dnech:

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

Následující příklad upravuje použití štítku aplikace na modulech Deployment a StatefulSet pro všechna nová nasazení/StatefulSets v roce 2020, ale zároveň umožňuje provádění testů bez tohoto štítku po dobu jednoho týdne:

- 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

Spusťte časově omezené demo po dobu 30 minut na clusteru, na kterém běží kube-janitor:

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

Dalším zdrojem zvyšujících se nákladů jsou trvalé objemy (AWS EBS). Odstranění Kubernetes StatefulSet neodstraní jeho trvalé svazky (PVC - PersistentVolumeClaim). Nevyužité objemy EBS mohou snadno vést k nákladům ve výši stovek dolarů měsíčně. Kubernetes Janitor má funkci pro vyčištění nepoužívaných PVC. Toto pravidlo například odstraní všechny PVC, které nejsou namontovány modulem a na které se neodkazuje StatefulSet nebo 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 pomoci udržet váš cluster čistý a zabránit pomalému hromadění nákladů na cloud computing. Pokyny k nasazení a konfiguraci naleznete podle pokynů README kube-správce.

Omezte škálování mimo pracovní dobu

Obvykle se vyžaduje, aby testovací a přípravné systémy fungovaly pouze během pracovní doby. Některé produkční aplikace, jako jsou nástroje back office/admin, také vyžadují pouze omezenou dostupnost a mohou být přes noc deaktivovány.

Kubernetes Downscaler (kube-downscaler) umožňuje uživatelům a operátorům zmenšovat systém mimo pracovní dobu. Nasazení a StatefulSets lze škálovat na nulové repliky. CronJobs může být pozastaven. Kubernetes Downscaler je nakonfigurován pro celý cluster, jeden nebo více oborů názvů nebo jednotlivé prostředky. Můžete nastavit buď „dobu nečinnosti“ nebo naopak „dobu práce“. Chcete-li například co nejvíce omezit škálování během nocí a víkendů:

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

Zde je graf pro škálování pracovních uzlů clusteru o víkendech:

Zmenšení z ~ 13 na 4 pracovní uzly jistě způsobí znatelný rozdíl ve vašem účtu za AWS.

Ale co když potřebuji pracovat během „prostoje“ clusteru? Některá nasazení lze trvale vyloučit ze škálování přidáním anotace downscaler/exclude: true. Nasazení lze dočasně vyloučit pomocí anotace downscaler/exclude-until s absolutním časovým razítkem ve formátu RRRR-MM-DD HH:MM (UTC). V případě potřeby lze celý cluster zmenšit nasazením modulu s anotací downscaler/force-uptime, například spuštění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

vidět README kube-downscaler, pokud máte zájem o pokyny k nasazení a další možnosti.

Použijte horizontální automatické škálování

Mnoho aplikací/služeb se zabývá dynamickým vzorem načítání: někdy jsou jejich moduly nečinné a někdy pracují na plnou kapacitu. Provozování stálé flotily modulů pro zvládnutí maximálního špičkového zatížení není ekonomické. Kubernetes podporuje horizontální automatické škálování napříč prostředkem HorizontalPodAutoscaler (HPA). Využití CPU je často dobrým indikátorem pro škálování:

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 vytvořilo komponentu pro snadné připojení vlastních metrik pro škálování: Adaptér Kube Metrics Adapter (kube-metrics-adapter) je obecný adaptér metrik pro Kubernetes, který může shromažďovat a poskytovat vlastní a externí metriky pro horizontální automatické škálování podů. Podporuje škálování na základě metrik Prometheus, front SQS a dalších nastavení. Chcete-li například škálovat nasazení na vlastní metriku reprezentovanou samotnou aplikací jako JSON v /metrics, použijte:

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

Konfigurace horizontálního automatického škálování pomocí HPA by měla být jednou z výchozích akcí pro zlepšení efektivity bezstavových služeb. Spotify má prezentaci se svými zkušenostmi a doporučeními pro HPA: škálovat vaše nasazení, ne vaši peněženku.

Snižte nadměrné rezervace zdrojů

Pracovní zátěže Kubernetes určují jejich potřeby CPU/paměti prostřednictvím „žádostí o zdroje“. Zdroje CPU se měří ve virtuálních jádrech nebo častěji v „milijádrech“, například 500 m znamená 50 % vCPU. Paměťové zdroje se měří v bajtech a lze použít běžné přípony, například 500Mi, což znamená 500 megabajtů. Požadavky na zdroje „uzamknou“ kapacitu na pracovních uzlech, což znamená, že pod s požadavkem na 1000 m CPU na uzlu se 4 vCPU ponechá ostatním podům k dispozici pouze 3 vCPU. [1]

Slack (nadměrná rezerva) je rozdíl mezi požadovanými zdroji a skutečným využitím. Například modul, který požaduje 2 GiB paměti, ale využívá pouze 200 MiB, má ~1,8 GiB „nadbytečné“ paměti. Přebytek stojí peníze. Lze zhruba odhadnout, že 1 GiB redundantní paměti stojí ~ 10 $ měsíčně. [2]

Zpráva o zdrojích Kubernetes (kube-resource-report) zobrazuje přebytečné rezervy a může vám pomoci určit potenciál úspor:

Zpráva o zdrojích Kubernetes zobrazuje přebytek agregovaný podle aplikace a příkazu. To vám umožní najít místa, kde lze snížit nároky na zdroje. Vygenerovaná zpráva HTML poskytuje pouze snímek využití zdrojů. Měli byste se podívat na využití CPU/paměti v průběhu času, abyste určili adekvátní požadavky na prostředky. Zde je graf Grafana pro „typickou“ službu s velkým zatížením CPU: všechny moduly využívají výrazně méně než 3 požadovaná jádra CPU:

Snížením požadavku CPU z 3000 400 m na ~ XNUMX m se uvolní zdroje pro další pracovní zátěže a cluster bude menší.

"Průměrné využití CPU instancí EC2 se často pohybuje v jednociferném procentuálním rozsahu," píše Corey Quinn. Zatímco pro EC2 odhad správné velikosti může být špatným rozhodnutímZměna některých dotazů na prostředky Kubernetes v souboru YAML je snadná a může přinést obrovské úspory.

Ale opravdu chceme, aby lidé měnili hodnoty v souborech YAML? Ne, stroje to umí mnohem lépe! Kubernetes Vertikální stojan Autoscaler (VPA) dělá právě to: přizpůsobuje požadavky na zdroje a omezení podle pracovní zátěže. Zde je příklad grafu požadavků CPU Prometheus (tenká modrá čára) upravených VPA v průběhu času:

Zalando používá VPA ve všech svých klastrech pro komponenty infrastruktury. VPA mohou používat i nekritické aplikace.

Goldilocks od Fairwind je nástroj, který vytvoří VPA pro každé nasazení ve jmenném prostoru a poté zobrazí doporučení VPA na svém řídicím panelu. Může vývojářům pomoci nastavit správné požadavky na CPU/paměť pro jejich aplikace:

Napsal jsem malý blogový příspěvek o VPA v roce 2019 a nedávno v Komunita koncových uživatelů CNCF diskutovala o problému VPA.

Použití instancí EC2 Spot

V neposlední řadě lze náklady na AWS EC2 snížit použitím instancí Spot jako pracovních uzlů Kubernetes [3]. Spot instance jsou k dispozici až s 90% slevou ve srovnání s cenami na vyžádání. Spuštění Kubernetes na EC2 Spot je dobrá kombinace: musíte zadat několik různých typů instancí pro vyšší dostupnost, což znamená, že můžete získat větší uzel za stejnou nebo nižší cenu a zvýšenou kapacitu mohou využít kontejnerizované úlohy Kubernetes.

Jak spustit Kubernetes na EC2 Spot? Existuje několik možností: použijte službu třetí strany, jako je SpotInst (nyní se nazývá „Spot“, neptejte se mě proč), nebo jednoduše přidejte do svého clusteru Spot AutoScalingGroup (ASG). Zde je například fragment CloudFormation pro „kapacitně optimalizovaný“ Spot ASG s více typy instancí:

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ěkolik poznámek k používání Spotu s Kubernetes:

• Musíte zvládnout bodová ukončení, například sloučením uzlu, když je instance zastavena
• Zalando používá Vidlička oficiální automatické škálování clusteru s prioritami fondu uzlů
• Bodové uzly lze vynutit přijměte „registrace“ pracovních zátěží pro spuštění ve Spotu

Shrnutí

Doufám, že některé z prezentovaných nástrojů shledáte užitečnými při snižování vašich účtů za cloud. Většinu obsahu článku najdete také na moje přednáška na DevOps Gathering 2019 na YouTube a ve snímcích.

Jaké jsou vaše osvědčené postupy pro úsporu nákladů na cloud na Kubernetes? Dejte mi prosím vědět na Twitter (@try_except_).

[1] Ve skutečnosti zůstanou použitelné méně než 3 vCPU, protože propustnost uzlu je snížena o rezervované systémové zdroje. Kubernetes rozlišuje mezi fyzickou kapacitou uzlu a „poskytnutými“ zdroji (Uzel Přidělitelný).

[2] Příklad výpočtu: jedna instance m5.large s 8 GiB paměti je ~84 $ měsíčně (eu-central-1, On-Demand), tzn. blokování 1/8 uzlu je přibližně ~10 $/měsíc.

[3] Existuje mnoho dalších způsobů, jak snížit svůj účet za EC2, jako jsou vyhrazené instance, plán úspor atd. – nebudu se zde těmito tématy zabývat, ale rozhodně byste se na ně měli podívat!

Zjistěte více o kurzu.

Zdroj: www.habr.com