Artikli tõlge valmis kursuse alguse eelõhtul .
Kuidas Kubernetesega töötades pilvekuludelt kokku hoida? Pole olemas ühte õiget lahendust, kuid selles artiklis kirjeldatakse mitmeid tööriistu, mis aitavad teil ressursse tõhusamalt hallata ja pilvandmetöötluse kulusid vähendada.
Kirjutasin selle artikli Kubernetes AWS-i jaoks, kuid see kehtib (peaaegu) täpselt samamoodi ka teistele pilveteenuse pakkujatele. Eeldan, et teie klastri(te)l on automaatne skaleerimine juba konfigureeritud (). Ressursside eemaldamine ja juurutamise vähendamine säästab teie raha ainult siis, kui see vähendab ka teie töötajate sõlmede arvu (EC2 eksemplarid).
See artikkel hõlmab järgmist:
- kasutamata ressursside puhastamine ()
- Vähendage skaleerimist töövälisel ajal ()
- kasutades horisontaalset automaatskaleerimist (HPA),
- liigse ressursside reserveerimise vähendamine (, VPA)
- Spot-juhtumite kasutamine
Kasutamata ressursside puhastamine
Kiires keskkonnas töötamine on suurepärane. Me tahame tehnoloogiaorganisatsioone . Kiirem tarkvara tarnimine tähendab ka rohkem PR juurutamist, eelvaatekeskkondi, prototüüpe ja analüüsilahendusi. Kõik on Kubernetesis juurutatud. Kellel on aega testjuurutusi käsitsi puhastada? Nädala vanuse katse kustutamise on lihtne unustada. Pilvearve tõuseb lõpuks millegi tõttu, mille unustasime sulgeda:
(Henning Jacobs:
Zhiza:
(tsitaadid) Corey Quinn:
Müüt: teie AWS-i konto sõltub teie kasutajate arvust.
Fakt: teie AWS-i skoor sõltub teie inseneride arvust.
Ivan Kurnosov (vastuseks):
Tõeline fakt: teie AWS-i skoor sõltub asjade arvust, mille unustasite keelata/kustutada.)
(kube-koristaja) aitab teie klastrit puhastada. Majahoidja konfiguratsioon on paindlik nii globaalseks kui ka kohalikuks kasutamiseks:
- Kogu klastri reeglid võivad määratleda PR/testi juurutamise maksimaalse kasutusaja (TTL).
- Üksikutele ressurssidele saab lisada märkused majahoidja/ttl-iga, näiteks naela/prototüübi automaatseks eemaldamiseks 7 päeva pärast.
Üldreeglid on määratletud YAML-failis. Selle tee läbib parameetri --rules-file kube-kojamehes. Siin on näide kõigi nimeruumide eemaldamiseks -pr- nimel kahe päeva pärast:
- id: cleanup-resources-from-pull-requests
resources:
- namespaces
jmespath: "contains(metadata.name, '-pr-')"
ttl: 2dJärgmine näide reguleerib rakenduse sildi kasutamist juurutus- ja StatefulSet-i kaustades kõigi 2020. aasta uute juurutuste/StatefulSetsi puhul, kuid võimaldab samal ajal katseid läbi viia ilma selle sildita nädala jooksul.
- 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: 7dKäivitage ajapiiranguga demo 30 minutit klastris, kus töötab kube-janitor:
kubectl run nginx-demo --image=nginx
kubectl annotate deploy nginx-demo janitor/ttl=30mTeine kulude suurenemise allikas on püsivad mahud (AWS EBS). Kubernetes StatefulSeti kustutamine ei kustuta selle püsivaid köiteid (PVC – PersistentVolumeClaim). Kasutamata EBS-i mahud võivad kergesti põhjustada sadu dollareid kuus kulusid. Kubernetes Janitoril on funktsioon kasutamata PVC-de puhastamiseks. Näiteks eemaldab see reegel kõik PVC-d, mida moodul ei paigalda ja millele StatefulSet või CronJob ei viita:
# удалить все PVC, которые не смонтированы и на которые не ссылаются StatefulSets
- id: remove-unused-pvcs
resources:
- persistentvolumeclaims
jmespath: "_context.pvc_is_not_mounted && _context.pvc_is_not_referenced"
ttl: 24hKubernetes Janitor aitab teil hoida klastri puhtana ja vältida pilvandmetöötluse kulude aeglast kuhjumist. Juurutamise ja konfigureerimise juhiste saamiseks järgige .
Vähendage skaleerimist töövälisel ajal
Testimis- ja lavastussüsteemid on tavaliselt vajalikud töötamiseks ainult tööajal. Mõned tootmisrakendused, nagu back office / administraatori tööriistad, nõuavad samuti ainult piiratud saadavust ja võivad olla üleöö keelatud.
(kube-downscaler) võimaldab kasutajatel ja operaatoritel süsteemi töövälisel ajal vähendada. Juurutused ja StatefulSets võivad ulatuda nulli koopiateni. CronJobs võidakse peatada. Kubernetes Downscaler on konfigureeritud terve klastri, ühe või mitme nimeruumi või üksikute ressursside jaoks. Saate määrata kas "jõudeaja" või vastupidi "tööaja". Näiteks selleks, et vähendada öistel ja nädalavahetustel katlakivi nii palju kui võimalik:
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-timeSiin on graafik klastri töötajate sõlmede skaleerimiseks nädalavahetustel:
Vähendamine ~13 töötaja sõlmelt 4-le muudab teie AWS-i arvel kindlasti märgatavat erinevust.
Aga mis siis, kui mul on vaja töötada klastri seisaku ajal? Teatud juurutusi saab skaleerimisest jäädavalt välistada, lisades suvandi downscaler/exclude: true annotation. Juurutusi saab ajutiselt välistada, kasutades annotatsiooni alandamise/välistamise-kuni absoluutse ajatempliga vormingus AAAA-KK-PP HH:MM (UTC). Vajadusel saab kogu klastrit vähendada, juurutades annotatsiooniga podi downscaler/force-uptime, näiteks käivitades 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=truenägema , kui olete huvitatud juurutamisjuhistest ja lisavõimalustest.
Kasutage horisontaalset automaatskaleerimist
Paljud rakendused/teenused tegelevad dünaamilise laadimismustriga: mõnikord on nende moodulid jõude ja mõnikord töötavad täisvõimsusel. Püsiva kaunapargi kasutamine maksimaalse tippkoormusega toimetulekuks ei ole ökonoomne. Kubernetes toetab horisontaalset automaatset skaleerimist kogu ressursi ulatuses (HPA). Protsessori kasutus on sageli skaleerimise hea näitaja:
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: UtilizationZalando on loonud komponendi kohandatud mõõdikute hõlpsaks ühendamiseks skaleerimiseks: (kube-metrics-adapter) on Kubernetese üldine mõõdikute adapter, mis suudab koguda ja teenindada kohandatud ja väliseid mõõdikuid kaustade horisontaalseks automaatseks skaleerimiseks. See toetab Prometheuse mõõdikutel, SQS-i järjekordadel ja muudel sätetel põhinevat skaleerimist. Näiteks juurutuse skaleerimiseks kohandatud mõõdikuks, mida rakendus ise esindab JSON-ina jaotises /metrics, kasutage järgmist.
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: AverageValueHorisontaalse automaatse skaleerimise konfigureerimine HPA-ga peaks olema üks vaiketoimingutest olekuta teenuste tõhususe parandamiseks. Spotifyl on esitlus nende kogemuste ja soovitustega HPA kohta: .
Vähendage ressursside ülebroneerimist
Kubernetese töökoormused määravad nende protsessori-/mäluvajadused ressursitaotluste kaudu. Protsessori ressursse mõõdetakse virtuaalsetes tuumades või sagedamini "milituumades", näiteks 500 m tähendab 50% vCPU-d. Mäluressursse mõõdetakse baitides ja kasutada saab tavalisi järelliiteid, näiteks 500Mi, mis tähendab 500 megabaiti. Ressursitaotlused lukustavad töötaja sõlmede võimsuse, mis tähendab, et 1000-meetrise protsessori päringuga moodul 4 vCPU-ga sõlme jätab teistele moodulitele kättesaadavaks ainult 3 vCPU-d.
Lõtk (liigne reserv) on erinevus taotletud ressursside ja tegeliku kasutuse vahel. Näiteks podil, mis nõuab 2 GiB mälu, kuid kasutab ainult 200 MiB, on ~1,8 GiB "liigset" mälu. Ülejääk maksab raha. Ligikaudu võib hinnata, et 1 GiB üleliigset mälu maksab ~10 dollarit kuus.
(kube-resource-report) kuvab liigsed reservid ja aitab teil määrata säästmisvõimalusi:
näitab rakenduse ja käsu järgi koondatud ülejääki. See võimaldab teil leida kohti, kus ressursinõudlust saab vähendada. Loodud HTML-aruanne annab ainult ülevaate ressursikasutusest. Piisavate ressursitaotluste määramiseks peaksite vaatama protsessori/mälu kasutust aja jooksul. Siin on Grafana diagramm "tüüpilise" suure protsessoriga teenuse kohta: kõik kaustad kasutavad oluliselt vähem kui kolm nõutud protsessori südamikku:
CPU päringu vähendamine 3000 meetrilt ~ 400 meetrile vabastab ressursse muude töökoormuste jaoks ja võimaldab klastril olla väiksem.
"EC2 eksemplaride keskmine protsessorikasutus jääb sageli ühekohalise protsendivahemiku vahele," . Kuigi EC2 jaoks Mõne Kubernetese ressursipäringu muutmine YAML-failis on lihtne ja võib tuua tohutut kokkuhoidu.
Kuid kas me tõesti tahame, et inimesed muudaksid YAML-failides väärtusi? Ei, masinad saavad sellega palju paremini hakkama! Kubernetes (VPA) teeb just seda: kohandab ressursitaotlusi ja piiranguid vastavalt töökoormusele. Siin on näide Prometheuse protsessori taotluste graafikust (õhuke sinine joon), mida VPA on aja jooksul kohandanud:
infrastruktuuri komponentide jaoks. VPA-d saavad kasutada ka mittekriitilised rakendused.
Fairwindist on tööriist, mis loob nimeruumis iga juurutuse jaoks VPA ja kuvab seejärel oma armatuurlaual VPA soovituse. See võib aidata arendajatel määrata oma rakenduste jaoks õiged protsessori-/mälupäringud.
Kirjutasin väikese aastal 2019 ja hiljuti aastal .
EC2 punktjuhtumite kasutamine
Viimaseks, kuid mitte vähem tähtsaks, saab AWS EC2 kulusid vähendada, kasutades Kubernetese töötaja sõlmedena Spot-eksemplare . Kohapealsed eksemplarid on saadaval kuni 90% allahindlusega võrreldes tellitavate hindadega. Kubernetese käitamine EC2 Spotis on hea kombinatsioon: suurema kättesaadavuse tagamiseks peate määrama mitu erinevat eksemplari tüüpi, mis tähendab, et saate sama või madalama hinnaga suurema sõlme ja suurenenud mahtu saab kasutada konteineris Kubernetese töökoormuse jaoks.
Kuidas käivitada Kubernetes EC2 Spotis? Võimalusi on mitu: kasutage kolmanda osapoole teenust, nagu SpotInst (praegu nimega "Spot", ärge küsige, miks) või lisage lihtsalt oma klastris Spot AutoScalingGroup (ASG). Näiteks siin on CloudFormationi koodilõik „võimsuse järgi optimeeritud” Spot ASG jaoks, millel on mitu eksemplari tüüpi:
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"Mõned märkused Spoti kasutamise kohta Kubernetesiga:
- Peate käsitlema Spot-lõpetamist, näiteks ühendades sõlme, kui eksemplar on peatatud
- Zalando kasutab ametlik klastri automaatne skaleerimine sõlmekogumi prioriteetidega
- Kohtsõlmed nõustuma töökoormuste registreerimisega Spoti töötamiseks
Kokkuvõte
Loodan, et mõned esitatud tööriistad on teie pilvearvete vähendamisel kasulikud. Suurema osa artikli sisust leiate ka aadressilt .
Millised on teie parimad tavad pilvekulude säästmiseks Kubernetesis? Palun andke mulle teada aadressil .
Tegelikult jääb kasutatavaks vähem kui 3 vCPU-d, kuna sõlme läbilaskevõimet vähendavad reserveeritud süsteemiressursid. Kubernetes teeb vahet füüsilise sõlme võimsuse ja "varustatud" ressursside vahel ().
Arvutusnäide: üks m5.large eksemplar 8 GiB mäluga on ~84$ kuus (eu-central-1, On-Demand), st. 1/8 sõlme blokeerimine on umbes ~10 dollarit kuus.
EC2 arve vähendamiseks on veel palju võimalusi, näiteks reserveeritud eksemplarid, säästuplaan jne – ma ei hakka neid teemasid siin käsitlema, kuid peaksite neid kindlasti uurima!
Allikas: www.habr.com