Okoa kutokana na gharama za wingu za Kubernetes kwenye AWS

Tafsiri ya kifungu hicho ilitayarishwa usiku wa kuamkia kozi hiyo "Jukwaa la miundombinu kulingana na Kubernetes".

Jinsi ya kuokoa kwa gharama za wingu wakati wa kufanya kazi na Kubernetes? Hakuna suluhisho moja sahihi, lakini makala hii inaelezea zana kadhaa ambazo zinaweza kukusaidia kusimamia rasilimali zako kwa ufanisi zaidi na kupunguza gharama zako za kompyuta ya wingu.

Niliandika nakala hii na Kubernetes kwa AWS akilini, lakini itatumika (karibu) kwa njia sawa kwa watoa huduma wengine wa wingu. Nadhani nguzo zako tayari zina uwekaji picha otomatiki umesanidiwa (nguzo-autoscaler) Kuondoa rasilimali na kupunguza utumaji wako kutakuokoa pesa tu ikiwa pia kunapunguza kundi lako la nodi za wafanyikazi (matukio ya EC2).

Makala hii itashughulikia:

• kusafisha rasilimali ambazo hazijatumika (kube-janitor)
• Kupunguza kiwango wakati wa saa zisizo za kazi (kube-downscaler)
• kutumia usawa wa otomatiki (HPA),
• kupunguza uhifadhi wa rasilimali kupita kiasi (kube-resource-ripoti, VPA)
• kwa kutumia matukio ya Spot

Kusafisha rasilimali zisizotumiwa

Kufanya kazi katika mazingira ya haraka ni nzuri. Tunataka mashirika ya teknolojia iliharakishwa. Uwasilishaji wa haraka wa programu pia unamaanisha uwekaji zaidi wa PR, mazingira ya onyesho la kukagua, prototypes, na suluhu za uchanganuzi. Kila kitu kimewekwa kwenye Kubernetes. Nani ana wakati wa kusafisha mwenyewe uwekaji wa majaribio? Ni rahisi kusahau kuhusu kufuta jaribio la wiki iliyopita. Muswada wa wingu utaisha kwa sababu ya kitu tulichosahau kufunga:

(Henning Jacobs:
Zhiza:
(nukuu) Corey Quinn:
Uwongo: Akaunti yako ya AWS ni kipengele cha kukokotoa idadi ya watumiaji ulio nao.
Ukweli: Alama yako ya AWS ni chaguo la idadi ya wahandisi ulio nao.

Ivan Kurnosov (kwa kujibu):
Ukweli halisi: Alama yako ya AWS ni kipengele cha idadi ya vitu ulivyosahau kuzima/kufuta.)

Kubernetes Janitor (kube-janitor) husaidia kusafisha nguzo yako. Usanidi wa msimamizi unaweza kunyumbulika kwa matumizi ya kimataifa na ya ndani:

• Sheria za kundi zima zinaweza kufafanua muda wa juu zaidi wa kuishi (TTL) kwa uwekaji wa PR/jaribio.
• Nyenzo mahususi zinaweza kufafanuliwa kwa kutumia janitor/ttl, kwa mfano kuondoa kiotomatiki spike/prototype baada ya siku 7.

Sheria za jumla zimefafanuliwa katika faili ya YAML. Njia yake inapitishwa kupitia parameter --rules-file katika kube-janitor. Hapa kuna sheria ya mfano ya kuondoa nafasi zote za majina na -pr- kwa jina baada ya siku mbili:

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

Mfano ufuatao unadhibiti matumizi ya lebo ya programu kwenye Deployment na StatefulSet pods kwa Deployments/StatefulSets zote mpya mwaka wa 2020, lakini wakati huohuo inaruhusu utekelezaji wa majaribio bila lebo hii kwa wiki:

- 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

Tekeleza onyesho la muda mfupi kwa dakika 30 kwenye kundi linaloendesha kube-janitor:

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

Chanzo kingine cha kuongezeka kwa gharama ni viwango vinavyoendelea (AWS EBS). Kufuta Kubernetes StatefulSet hakufuti majuzuu yake yanayoendelea (PVC - PersistentVolumeClaim). Kiasi cha EBS ambacho hakijatumika kinaweza kusababisha gharama ya mamia ya dola kwa mwezi kwa urahisi. Kubernetes Janitor ina kipengele cha kusafisha PVC ambazo hazijatumika. Kwa mfano, sheria hii itaondoa PVC zote ambazo hazijawekwa na moduli na ambazo hazijarejelewa na StatefulSet au CronJob:

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

Kubernetes Janitor inaweza kukusaidia kuweka nguzo yako safi na kuzuia gharama za kompyuta ya wingu zisirundikane polepole. Kwa maagizo ya kupeleka na usanidi, fuata SOMA kube-janitor.

Kupunguza kiwango wakati wa saa zisizo za kazi

Mifumo ya majaribio na hatua kwa kawaida huhitajika kwa uendeshaji tu wakati wa saa za kazi. Baadhi ya programu za uzalishaji, kama vile zana za nyuma za ofisi/msimamizi, pia zinahitaji upatikanaji mdogo tu na zinaweza kuzimwa mara moja.

Kubernetes Downscaler (kube-downscaler) huruhusu watumiaji na waendeshaji kupunguza mfumo wakati wa saa zisizo za kazi. Utumiaji na StatefulSets zinaweza kufikia nakala sifuri. CronJobs inaweza kusimamishwa. Kubernetes Downscaler imesanidiwa kwa ajili ya kundi zima, nafasi moja au zaidi ya majina, au rasilimali ya mtu binafsi. Unaweza kuweka ama "wakati wa kufanya kazi" au, kinyume chake, "wakati wa kazi". Kwa mfano, ili kupunguza kiwango iwezekanavyo wakati wa usiku na wikendi:

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

Hapa kuna grafu ya kuongeza nodi za wafanyikazi wa nguzo wikendi:

Kupunguza kutoka nodi ~ 13 hadi 4 za wafanyikazi hakika hufanya tofauti inayoonekana katika muswada wako wa AWS.

Lakini vipi ikiwa ninahitaji kufanya kazi wakati wa "wakati wa kupumzika" wa nguzo? Usambazaji fulani unaweza kutengwa kabisa kutoka kwa kuongeza kiwango kwa kuongeza kipunguza/kutojumuisha: ufafanuzi wa kweli. Usambazaji unaweza kutengwa kwa muda kwa kutumia kipunguza kasi/kutenga-mpaka kidokezo chenye muhuri kamili wa muda katika umbizo la YYYY-MM-DD HH:MM (UTC). Ikibidi, nguzo nzima inaweza kupunguzwa nyuma kwa kupeleka ganda lenye kidokezo downscaler/force-uptime, kwa mfano, kwa kuzindua nginx tupu:

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

Kuona SOMA kuwa-downscaler, ikiwa una nia ya maelekezo ya kupeleka na chaguzi za ziada.

Tumia kipimo kiotomatiki cha mlalo

Programu/huduma nyingi hushughulika na muundo unaobadilika wa upakiaji: wakati mwingine moduli zao hazina kazi, na wakati mwingine zinafanya kazi kwa uwezo kamili. Kuendesha kundi la kudumu la maganda ili kukabiliana na kiwango cha juu cha mzigo sio kiuchumi. Kubernetes inasaidia kuongeza kiotomatiki kiotomatiki kwenye rasilimali HorizontalPodAutoscaler (HPA). Matumizi ya CPU mara nyingi ni kiashiria kizuri cha kuongeza:

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 imeunda kijenzi cha kuunganisha kwa urahisi vipimo maalum vya kuongeza ukubwa: Adapta ya Kube Metrics (kube-metrics-adapta) ni adapta ya vipimo vya jumla ya Kubernetes inayoweza kukusanya na kutoa vipimo maalum na vya nje kwa ajili ya kupima maganda kiotomatiki. Inaauni kuongeza alama kulingana na vipimo vya Prometheus, foleni za SQS na mipangilio mingineyo. Kwa mfano, kuongeza utumaji wako kwa kipimo maalum kinachowakilishwa na programu yenyewe kama JSON katika /matumizi ya metriki:

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

Kuweka mipangilio ya kupima kiotomatiki kwa kutumia HPA inapaswa kuwa mojawapo ya hatua chaguomsingi za kuboresha ufanisi wa huduma zisizo na uraia. Spotify ina wasilisho na uzoefu wao na mapendekezo kwa HPA: punguza usambazaji wako, sio mkoba wako.

Punguza uhifadhi wa rasilimali kupita kiasi

Uzito wa kazi wa Kubernetes huamua mahitaji yao ya CPU/kumbukumbu kupitia "maombi ya rasilimali." Rasilimali za CPU hupimwa kwa kore dhahania au kwa kawaida zaidi katika "millicores", kwa mfano 500m inamaanisha 50% vCPU. Rasilimali za kumbukumbu hupimwa kwa baiti, na viambishi tamati vya kawaida vinaweza kutumika, kama vile 500Mi, ambayo inamaanisha megabaiti 500. Rasilimali inaomba uwezo wa "kufunga" kwenye nodi za wafanyikazi, kumaanisha ganda lenye ombi la CPU ya mita 1000 kwenye nodi yenye vCPU 4 litaacha vCPU 3 pekee zipatikane kwa maganda mengine. [1]

Slack (hifadhi ya ziada) ni tofauti kati ya rasilimali zilizoombwa na matumizi halisi. Kwa mfano, ganda ambalo linaomba 2 GiB ya kumbukumbu lakini linatumia 200 MiB pekee lina ~ 1,8 GiB ya kumbukumbu "ziada". Ziada hugharimu pesa. Mtu anaweza kukadiria kuwa 1 GiB ya kumbukumbu isiyohitajika inagharimu ~$10 kwa mwezi. [2]

Ripoti ya Rasilimali ya Kubernetes (kube-resource-report) huonyesha akiba ya ziada na inaweza kukusaidia kubainisha uwezekano wa kuokoa:

Ripoti ya Rasilimali ya Kubernetes inaonyesha ziada iliyojumlishwa na programu na amri. Hii hukuruhusu kupata mahali ambapo mahitaji ya rasilimali yanaweza kupunguzwa. Ripoti ya HTML iliyotolewa hutoa tu picha ya matumizi ya rasilimali. Unapaswa kuangalia matumizi ya CPU/kumbukumbu kwa muda ili kubaini maombi ya rasilimali ya kutosha. Hii hapa ni chati ya Grafana ya huduma "kawaida" nzito ya CPU: maganda yote yanatumia chini ya viini 3 vya CPU vilivyoombwa:

Kupunguza ombi la CPU kutoka mita 3000 hadi ~ 400m hufungua rasilimali kwa mizigo mingine ya kazi na kuruhusu nguzo kuwa ndogo.

"Wastani wa matumizi ya CPU ya matukio ya EC2 mara nyingi huelea katika safu ya asilimia ya tarakimu moja," anaandika Corey Quinn. Wakati kwa EC2 kukadiria saizi inayofaa inaweza kuwa uamuzi mbayaKubadilisha baadhi ya hoja za nyenzo za Kubernetes katika faili ya YAML ni rahisi na kunaweza kuleta uokoaji mkubwa.

Lakini je, tunataka kweli watu kubadilisha maadili katika faili za YAML? Hapana, mashine zinaweza kuifanya vizuri zaidi! Kubernetes Wima Pod Autoscaler (VPA) hufanya hivyo tu: hurekebisha maombi ya rasilimali na vikwazo kulingana na mzigo wa kazi. Hapa kuna mfano wa grafu ya maombi ya Prometheus CPU (mstari mwembamba wa samawati) iliyorekebishwa na VPA kwa wakati:

Zalando inatumia VPA katika makundi yake yote kwa vipengele vya miundombinu. Programu zisizo muhimu pia zinaweza kutumia VPA.

Dhahabu kutoka Fairwind ni zana ambayo huunda VPA kwa kila utumaji katika nafasi ya majina na kisha kuonyesha pendekezo la VPA kwenye dashibodi yake. Inaweza kusaidia wasanidi kuweka CPU/maombi sahihi ya kumbukumbu kwa programu zao:

Niliandika ndogo chapisho la blogi kuhusu VPA mwaka 2019, na hivi karibuni Jumuiya ya Watumiaji wa CNCF ilijadili suala la VPA.

Kwa kutumia EC2 Spot Matukio

Mwisho kabisa, gharama za AWS EC2 zinaweza kupunguzwa kwa kutumia hali za Spot kama nodi za wafanyikazi wa Kubernetes. [3]. Matukio ya moja kwa moja yanapatikana kwa punguzo la hadi 90% ikilinganishwa na bei Zinazohitajika. Kuendesha Kubernetes kwenye EC2 Spot ni mchanganyiko mzuri: unahitaji kubainisha aina kadhaa tofauti za mifano kwa upatikanaji wa juu zaidi, kumaanisha kuwa unaweza kupata nodi kubwa kwa bei sawa au ya chini, na uwezo ulioongezeka unaweza kutumiwa na mizigo ya kazi ya Kubernetes iliyo katika kontena.

Jinsi ya kuendesha Kubernetes kwenye EC2 Spot? Kuna chaguo kadhaa: tumia huduma ya mtu mwingine kama SpotInst (sasa inaitwa "Spot", usiniulize kwa nini), au ongeza tu Spot AutoScalingGroup (ASG) kwenye nguzo yako. Kwa mfano, hapa kuna kijisehemu cha CloudFormation cha Spot ASG "iliyoboreshwa kwa uwezo" na aina nyingi za mifano:

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"

Vidokezo kadhaa juu ya kutumia Spot na Kubernetes:

• Unahitaji kushughulikia usitishaji wa Spot, kwa mfano kwa kuunganisha nodi wakati mfano umesimamishwa
• Zalando anatumia uma Uwekaji otomatiki wa nguzo rasmi na vipaumbele vya bwawa la nodi
• Nodi za doa inaweza kulazimishwa ukubali "usajili" wa mzigo wa kazi ili kuendeshwa katika Spot

Muhtasari

Natumai utapata baadhi ya zana zilizowasilishwa kuwa muhimu katika kupunguza bili yako ya wingu. Unaweza kupata maudhui mengi ya makala pia kwa mazungumzo yangu katika DevOps Gathering 2019 kwenye YouTube na kwenye slaidi.

Je, ni mbinu gani bora za kuokoa gharama za wingu kwenye Kubernetes? Tafadhali nijulishe kwa Twitter (@try_isipokuwa_).

[1] Kwa kweli, chini ya vCPU 3 zitasalia kutumika kwani upitishaji wa nodi unapunguzwa na rasilimali za mfumo zilizohifadhiwa. Kubernetes hutofautisha kati ya uwezo wa nodi za kimwili na rasilimali "zinazotolewa" (Nodi Inayoweza Kugawiwa).

[2] Mfano wa kukokotoa: mfano mmoja wa m5.large wenye 8 GiB ya kumbukumbu ni ~$84″ kwa mwezi (eu-central-1, On-Demand), i.e. kuzuia nodi 1/8 ni takriban ~$10/mwezi.

[3] Kuna njia nyingi zaidi za kupunguza bili yako ya EC2, kama vile Hali Zilizohifadhiwa, Mpango wa Akiba, n.k. - Sitaangazia mada hizo hapa, lakini unapaswa kuzichunguza kwa hakika!

Jifunze zaidi kuhusu kozi.

Chanzo: mapenzi.com