🥇Šetříme na cloudových nákladech Kubernetes na AWS

Překlad článku byl vyhotoven před začátkem kurzu „Infrastrukturní platforma na bázi Kubernetes“.

Jak ušetřit na cloudových nákladech při práci s Kubernetes? Neexistuje jediné správné řešení, ale v tomto článku je popsáno několik nástrojů, které vám pomohou efektivněji spravovat zdroje a snížit náklady na cloudové výpočty.

Tento článek jsem napsal s ohledem na Kubernetes pro AWS, ale bude se (téměř) stejně vztahovat i na jiné cloudové poskytovatele. Předpokládám, že váš cluster(y) již má nastavené automatické škálování (cluster-autoscaler). Odstranění zdrojů a zmenšení rozsahu nasazení povede k úsporám pouze tehdy, pokud také sníží váš park pracovních uzlů (instancí EC2).

V tomto článku budou zvažovány:

čištění nepoužívaných zdrojů (kube-janitor)
snížení škálování mimo pracovní dobu (kube-downscaler)
využití horizontálního automatizovaného škálování (HPA),
snížení nadbytečného rezervování zdrojů (kube-resource-report, VPA)
využití Spot instancí

Úklid nepoužívaných zdrojů

Práce v rychle se měnícím prostředí je skvělá. Chceme, aby technické organizace zrychlovaly. Rychlejší dodání softwaru také znamená více PR nasazení, předběžných prostředí, prototypů a analytických řešení. Všechno je nasazeno na Kubernetes. Kdo má čas ručně uklízet testovací nasazení? Snadno se zapomene na odstranění experimentu starého týden. Účet za cloud nakonec poroste, protože jsme zapomněli uzavřít:

(Henning Jacobs:
Život:
(cituje) Cory Quinn:
Mýtus: Váš AWS účet je funkcí závislosti na počtu vašich uživatelů.
Fakt: Váš AWS účet je funkcí závislosti na počtu vašich inženýrů.

Ivan Kurnosov (v odpovědi):
Skutečný fakt: Váš AWS účet je funkcí závislosti na počtu věcí, které jste zapomněli vypnout/odstranit.)

Kubernetes Janitor (kube-janitor) pomáhá vyčistit váš cluster. Konfigurace janitoru je flexibilní jak pro globální, tak pro lokální použití:

Obecná pravidla pro celý cluster mohou určovat maximální dobu života (TTL – time-to-live) pro PR/testovací nasazení.
Jednotlivé zdroje mohou být anotovány pomocí janitor/ttl, například pro automatické odstranění spike/prototypu po 7 dnech.

Obecná pravidla jsou určena v YAML souboru. Jeho cesta je předána přes parametr --rules-file v kube-janitor. Zde je příklad pravidla pro odstranění všech prostorů názvů s -pr- v názvu za dva dny:

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

Další příklad reguluje použití štítku application na Deployment a StatefulSet podech pro všechny nové Deployments/StatefulSet v roce 2020, ale zároveň umožňuje provádět testy bez tohoto štítku po dobu jednoho týdne:

- id: require-application-label
  # odstranit deployments a statefulsets bez štítku "application"
  resources:
    - deployments
    - statefulsets
  # viz http://jmespath.org/specification.html
  jmespath: "!(spec.template.metadata.labels.application) && metadata.creationTimestamp > '2020-01-01'"
  ttl: 7d

Spuštění časově omezené ukázky po dobu 30 minut v clusteru, kde běží kube-janitor:

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

Dalším zdrojem rostoucích nákladů jsou trvalé svazky (AWS EBS). Při odstraňování Kubernetes StatefulSet se jeho trvalé svazky (PVC — PersistentVolumeClaim) neodstraňují. Nepoužívané objemy EBS mohou snadno vést k nákladům v řádu stovek dolarů měsíčně. Kubernetes Janitor má funkci pro čištění nepoužívaných PVC. Například toto pravidlo odstraní všechna PVC, která nejsou připojena modulem a na která se nevztahuje 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 v "čistotě" a zabránit pomalému hromadění nákladů na cloudové výpočty. Pro pokyny k nasazení a nastavení sledujte v README kube-janitor.

Snížení škálování mimo pracovní dobu

Testovací a interimní systémy obvykle potřebují fungovat pouze během pracovní doby. Některé výrobní aplikace, jako je back-office/nástroje pro správu, vyžadují také pouze omezenou dostupnost a mohou být večer vypnuty.

Kubernetes Downscaler (kube-downscaler) umožňuje uživatelům a operátorům snižovat měřítko systému během nepracovního času. Nasazení a StatefulSets mohou být škálována až na nulové repliky. CronJobs mohou být pozastaveny. Kubernetes Downscaler se nastavuje pro celý cluster, jedno nebo více jmenných prostorů nebo jednotlivé zdroje. Lze nastavit buď „čas nečinnosti“, nebo „čas provozu“. Například pro maximální snížení škálování v noci a o víkendech:

image: hjacobs/kube-downscaler:20.4.3
args:
  - --interval=30
  # neodpojujte komponenty infrastruktury
  - --exclude-namespaces=kube-system,infra
  # neodpojujte kube-downscaler, a také nechte Postgres Operator, aby bylo možné spravovat vyloučené DB
  - --exclude-deployments=kube-downscaler,postgres-operator
  - --default-uptime=Po-Pá 08:00-20:00 Evropa/Berlín
  - --include-resources=deployments,statefulsets,stacks,cronjobs
  - --deployment-time-annotation=deployment-time

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

Snížení měřítka z ~13 na 4 pracovní uzly zjevně znamená významný rozdíl v účtu AWS.

Ale co když potřebuji pracovat během „času nečinnosti“ clusteru? Některá nasazení mohou být trvale vyloučena ze škálování přidáním anotace downscaler/exclude: true. Nasazení mohou být dočasně vyloučena pomocí anotace downscaler/exclude-until s absolutním časovým razítkem ve formátu RRRR-MM-DD HH:MM (UTC). Pokud je to nutné, může být celý cluster znovu škálován nasazením podu s anotací downscaler/force-uptime, například spuštěním nginx šablony:

kubectl run scale-up --image=nginx
kubectl annotate deploy scale-up janitor/ttl=1h # odstranit nasazení za hodinu
kubectl annotate pod $(kubectl get pod -l run=scale-up -o jsonpath="{.items[0].metadata.name}") downscaler/force-uptime=true

Viz README kube-downscaler, pokud máte zájem o instrukce k nasazení a další možnosti.

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

Mnoho aplikací/služeb se vypořádává s dynamickým vzorem zatížení: někdy jejich moduly nepracují, a někdy pracují na plný výkon. Práce s trvalým parkem podů, aby se vyrovnala s maximálním špičkovým zatížením, není úsporná. Kubernetes podporuje horizontální automatické škálování prostřednictvím zdroje HorizontalPodAutoscaler (HPA). Použití CPU je často dobrým ukazatelem 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řil komponentu pro jednoduché připojení uživatelských metrik pro škálování: Kube Metrics Adapter (kube-metrics-adapter) je univerzální adaptér metrik pro Kubernetes, který může shromažďovat a zpřístupňovat uživatelské 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í. Například pro škálování nasazení podle uživatelské metriky, kterou aplikace poskytuje ve formátu JSON na /metrics, použijte:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
  annotations:
    # metric-config.../
    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

Nastavení horizontálního automatického škálování pomocí HPA by mělo být jedním z výchozích kroků pro zvýšení efektivity pro služby bez ohledu na stav. Spotify má prezentaci se svými zkušenostmi a doporučeními pro HPA: škálujte svá nasazení, nikoli peněženku.

Snížení nadbytečného rezervování zdrojů

Pracovní zátěže Kubernetes určují své potřeby na CPU/paměť pomocí „požadavků na zdroje“ (resource requests). Zdroje CPU se měří ve virtuálních jádrech nebo častěji v „milikoře“ (millicores), například 500m znamená 50% vCPU. Zdroje paměti se měří v bajtech a lze používat běžné přípony, například 500Mi, což znamená 500 megabajtů. Požadavky na zdroje „uzamykají“ objem na pracovních uzlech, tj. modul s požadavkem CPU 1000m na uzlu se 4 virtuálními CPU nechá pouze 3 virtuální CPU k dispozici pro jiné moduly. [1]

Slack (nadbytek rezervy) — je to rozdíl mezi požadovanými zdroji a skutečným využitím. Například pod, který požaduje 2 GiB paměti, ale používá pouze 200 MiB, má ~ 1,8 GiB „nadbytečné“ paměti. Nadbytek něco stojí. Lze hrubě odhadnout, že 1 GiB nadbytečné paměti stojí ~ 10 dolarů měsíčně. [2]

Kubernetes Resource Report (kube-resource-report) zobrazuje nadbytečné rezervy a může vám pomoci určit potenciální úspory:

Kubernetes Resource Report ukazuje nadbytek agregovaný podle aplikace a týmu. To umožňuje najít místa, kde mohou být požadavky na zdroje sníženy. Vygenerovaná HTML zpráva poskytuje pouze snímek využití zdroje. Měli byste sledovat využití CPU/paměti v průběhu času, aby se určily adekvátní požadavky na zdroje. Zde je graf Grafana pro „typickou“ službu s vysokou zátěží na CPU: všechny pody používají výrazně méně než 3 požadovaná jádra CPU:

Snížení požadavku CPU z 3000m na ~400m uvolňuje zdroje pro jiné pracovní zátěže a umožňuje zmenšení clusteru.

„Průměrné využití CPU instancí EC2 se často pohybuje v rozmezí jednociferných procent,“ — píše Cory Quinn. Zatímco pro EC2 odhad správné velikosti může být špatné rozhodnutí, změna některých požadavků na zdroje Kubernetes v YAML souboru se provádí snadno a může přinést obrovské úspory.

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

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

Goldilocks od Fairwind — je nástroj, který vytváří VPA pro každé nasazení v prostoru názvů a poté zobrazuje doporučení VPA na své nástěnce. Může pomoci vývojářům 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 na CNCF End User Community se diskutovalo o VPA.

Použití instancí EC2 Spot

Nakonec, což není méně důležité, náklady AWS EC2 lze snížit použitím Spot instancí jako pracovních uzlů Kubernetes. [3]. Spot instance jsou k dispozici se slevou až 90 % oproti cenám na vyžádání. Spuštění Kubernetes na EC2 Spot je skvělá kombinace: musíte specifikovat více 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ýšená kapacita může být využita kontejnery Kubernetes.

Jak spustit Kubernetes na EC2 Spot? Existuje několik možností: použít třetí stranu, jako je SpotInst (nyní se jmenuje „Spot“, neptáte se mě proč), nebo jednoduše přidat Spot AutoScalingGroup (ASG) do vašeho clusteru. Například zde je kousek CloudFormation pro „kapacitně optimalizovanou“ Spot ASG s několika 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ěkteré poznámky k používání Spot s Kubernetes:

Musíte zpracovávat ukončení Spot, například odebráním uzlu při zastavení instance.
Zalando používá fork oficiální automatizaci škálování clusteru s prioritami uzlového poolu.
Uzly Spot mohou být přinuceny přijímat “registrace” pracovních zátěží pro spuštění v Spot.

Shrnutí

Doufám, že některé z uvedených nástrojů najdete užitečné pro snížení vašich nákladů na cloudové služby. Většinu obsahu článku můžete také najít v mém vystoupení na DevOps Gathering 2019 na YouTube a ve formě slidů..

Jaké jsou vaše nejlepší praktiky pro úsporu nákladů na cloud na Kubernetes? Prosím, dejte vědět na Twitteru (@try_except_).

[1] Ve skutečnosti zbývají méně než 3 virtuální CPU, které budou použitelné, protože šířka pásma uzlu klesá v důsledku rezervovaných systémových zdrojů. Kubernetes rozlišuje mezi fyzickou kapacitou uzlu a „alokovanými“ zdroji (Node Allocatable).

[2] Příklad výpočtu: jeden příklad m5.large s 8 GiB paměti stojí přibližně 84 USD měsíčně (eu-central-1, On-Demand), což znamená, že blokování 1/8 uzlu stojí přibližně 10 USD měsíčně.

[3] Existuje také mnoho dalších způsobů, jak snížit váš EC2 účet, například rezervované instance, plán úspor atd. — o těchto tématech se zde nebudu rozepisovat, ale určitě byste se o nich měli dozvědět!

Zjistit více o kurzu.

Zdroj: habr.com