Përkthimi i artikullit është përgatitur në prag të fillimit të kursit .
Si të kurseni në shpenzimet cloud kur punoni me Kubernetes? Nuk ka një zgjidhje të vetme të saktë, por ky artikull përshkruan disa mjete që do t'ju ndihmojnë të menaxhoni burimet më efikas dhe të zvogëloni kostot e computing në cloud.
E shkrova këtë artikull duke pasur parasysh Kubernetes për AWS, por ai do të jetë i aplikueshëm (gati) njësoj edhe për ofruesit e tjerë të cloud. Unë supozoj se klasteri juaj (të) tashmë ka të konfiguruar auto-skalimin (). Shkëputja e burimeve dhe zvogëlimi i shkallës së implementimit do të kursejnë vetëm nëse gjithashtu zvogëlon parqet tuaja të nodave punues (instance të EC2).
Ky artikull do të trajtojë:
- pastrimin e burimeve të pa përdorura ()
- ) zvogëlimin e shkallës në orët e papuna ()
- ) përdorimin e auto-skalimit horizontal (HPA),
- minimizimin e rezervimit të tepruar të burimeve (, VPA)
- përdorimin e instanceve Spot
Pastrimi i burimeve të pa përdorura
Të punosh në një mjedis në ndryshim të shpejtë është e shkëlqyer. Ne duam që organizatat teknike . Një shpërndarje më e shpejtë e softuerit do të thotë gjithashtu më shumë implementime PR, ambiente të parashikimit, prototipa dhe zgjidhje analitike. Të gjitha janë të implementuara në Kubernetes. Kush ka kohë për të pastruar implementimet testuese me dorë? Është e lehtë të harrosh të fshish një eksperiment të kaluar një javë. Fatura e cloud-it në fund do të rritet për shkak se harrojmë të mbyllim:
(Henning Jacobs:
E vërteta:
(citon) Corey Quinn:
Miti: Fatura juaj AWS është një funksion varësie nga numri i përdoruesve tuaj.
Fakti: Fatura juaj AWS është një funksion varësie nga numri i inxhinierëve tuaj.
Ivan Kurnosov (në përgjigje):
Fakti i vërtetë: Fatura juaj AWS është një funksion varësie nga numri i gjërave që keni harruar të ndizni/fshini.)
(kube-janitor) ndihmon në pastrimin e klasterit tuaj. Konfigurimi i janitor është fleksibël si për përdorim global ashtu edhe për ne lokal:
- Rregullat e përgjithshme për të gjithë klasterin mund të përcaktojnë një kohë të maksimumit të jetës (TTL - kohë deri në jetesë) për implementimet PR/testuese.
- Burimet e veçanta mund të annotohen me janitor/ttl, për shembull, për të fshirë automatikisht spike/prototipin pas 7 ditësh.
Rregullat e përgjithshme përcaktohen në një skedë YAML. Rrugën e saj e kaloni përmes parametrave --rules-file në kube-janitor. Ja një shembull rregulli për të fshirë të gjitha hapësirat e emrave me -pr- në emër pas dy ditësh:
- id: cleanup-resources-from-pull-requests
resources:
- namespaces
jmespath: "contains(metadata.name, '-pr-')"
ttl: 2dShembulli tjetër përcakton përdorimin e etiketës application në implementimet dhe StatefulSet për të gjitha implementimet/StatefulSet e reja në vitin 2020, por në të njëjtën kohë lejon ekzekutimin e testeve pa këtë etiketë për një javë:
- id: require-application-label
# fshij implementimet dhe statefulsets pa etiketën "application"
resources:
- deployments
- statefulsets
# shih http://jmespath.org/specification.html
jmespath: "!(spec.template.metadata.labels.application) && metadata.creationTimestamp > '2020-01-01'"
ttl: 7dEkzekutimi i një demo me kohë të kufizuar për 30 minuta në klasterin ku funksionon kube-janitor:
kubectl run nginx-demo --image=nginx
kubectl annotate deploy nginx-demo janitor/ttl=30mNjë burim tjetër i shpenzimeve në rritje janë volumin e përhershëm (AWS EBS). Kur fshihet Kubernetes StatefulSet, volumin e saj të përhershëm (PVC - PersistentVolumeClaim) nuk fshihet. Volume të pa përdorura EBS mund të sjellin shpenzime të lehta në qindra dollarë në muaj. Kubernetes Janitor ka funksion për pastrimin e PVC-ve të pa përdorura. Për shembull, ky rregull do të fshijë të gjithë PVC-të që nuk janë montuar nga moduli dhe që nuk referohen nga StatefulSet ose CronJob:
# удалить все PVC, которые не смонтированы и на которые не ссылаются StatefulSets
- id: remove-unused-pvcs
resources:
- persistentvolumeclaims
jmespath: "_context.pvc_is_not_mounted && _context.pvc_is_not_referenced"
ttl: 24hKubernetes Janitor mund t'ju ndihmojë të mbani klasterin tuaj "të pastër" dhe të parandaloni grumbullimin e shpenzimeve në cloud. Për udhëzime mbi implementimin dhe konfigurimin ndiqni në .
Zvogëlimi i shkallës në orët e papuna
Sistemet testuese dhe ndërmjetës zakonisht kërkohen të funksionojnë vetëm gjatë orëve të punës. Disa aplikacione prodhuese, të tilla si pastrimi / mjetet e administratës, gjithashtu kërkojnë vetëm qasje të kufizuar dhe mund të shuhen natën.
(kube-downscaler) lejon përdoruesit dhe operatoret të zvogëlojnë shkallën e sistemit në orët e papuna. Implementimet dhe StatefulSets mund të zvogëlohen në zeron replikat. CronJobs mund të pezullohen. Kubernetes Downscaler konfigurohet për të gjithë klasterin, një ose disa hapësira emri ose burime të veçanta. Mund të vendosni ose "koha e papunë", ose në të kundërt "koha e punës". Për shembull, për të minimizuar shkallëzimin gjatë natës dhe fundjavës:
image: hjacobs/kube-downscaler:20.4.3
args:
- --interval=30
# mos mos e shkëputni komponentët e infrastrukturës
- --exclude-namespaces=kube-system,infra
# mos shkëputni kube-downscaler dhe gjithashtu lini Postgres Operator, në mënyrë që të mund të menaxhohen bazat e të dhënave të përjashtuara
- --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-timeKëtu është grafiku i shkallëzimit të nyjeve të punës në klaster gjatë fundjavave:
Shkalla e reduktimit nga ~13 në 4 nyje pune padyshim sjell një ndryshim të qartë në faturën e AWS.
Por çfarë nëse duhet të punoj gjatë "koheve të pezullimit" të klasterit? Njësi të caktuara mund të përjashtohen përherë nga shkallëzimi duke shtuar një annotim downscaler/exclude: true. Njësitë mund të përjashtohen përkohësisht me anë të annotimit downscaler/exclude-until me një kohë absolute në formatin GGGG-MM-DD HH:MM (UTC). Nëse është e nevojshme, të gjithë klasteri mund të shkallëzohet përsëri duke implementuar një pod me annotimin downscaler/force-uptime, për shembull, duke ekzekutuar një nginx skellet:
kubectl run scale-up --image=nginx
kubectl annotate deploy scale-up janitor/ttl=1h # fshij deploy-in pas një ore
kubectl annotate pod $(kubectl get pod -l run=scale-up -o jsonpath="{.items[0].metadata.name}") downscaler/force-uptime=trueShikoni , nëse jeni të interesuar për udhëzime për implementim dhe opsione shtesë.
Përdorni shkallëzimin horizontal
Shumë aplikacione/shërbime përballen me një skemë ngarkese dinamike: ndonjëherë modulet e tyre janë inaktive, dhe ndonjëherë ato punojnë në kapacitet të plotë. Të punosh me një park të qëndrueshëm podësh për të përballuar ngarkesën maksimale nuk është efikase. Kubernetes mbështet shkallëzimin automatik horizontal përmes burimit (HPA). Përdorimi i CPU shpesh është një tregues i mirë për shkallëzimin:
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 krijoi një komponent për lidhjen e lehtë të metrikave të personalizuara për shkallëzim: (kube-metrics-adapter) është një adaptues metrikash universale për Kubernetes, i cili mund të mbledhë dhe ofrojë metrika të personalizuara dhe të jashtme për shkallëzimin horizontal të podëve. Ai mbështet shkallëzimin në bazë të metricave të Prometheus, radhëve SQS dhe cilësimeve të tjera. Për shembull, për të shkallëzuar një implementim për një metrikë të personalizuar, të paraqitur nga vetë aplikacioni në formë JSON në /metrics, përdorni:
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: AverageValueKonfigurimi i shkallëzimit horizontal me HPA duhet të jetë një nga veprimet e paracaktuara për të rritur efikasitetin për shërbimet pa marrë parasysh gjendjen. Spotify ka një prezantim me përvojën dhe rekomandimet e tyre për HPA: .
Reduktimi i rezervave të tepërta të burimeve
Ngarkesat e punës në Kubernetes përcaktojnë nevojat e tyre për CPU/memorie përmes “kërkesave të burimeve” (resource requests). Burimet e CPU maten në bërthama virtuale ose më shpesh në “millicores” (millicores), për shembull, 500m nënkupton 50% vCPU. Burimet e memories maten në byte, dhe mund të përdoren sufikse standarde, për shembull, 500Mi, që do të thotë 500 megabajt. Kërkesat e burimeve “bllokojnë” sasinë në nyjet e punës, domethënë një modul me kërkesë CPU prej 1000m në një nyje me 4 vCPU do të lërë vetëm 3 vCPU të disponueshëm për modulet e tjera.
Slack (rezerva e tepërt) — është diferenca midis burimeve të kërkuara dhe përdorimit real. Për shembull, një pod që kërkon 2 GiB memorie, por përdor vetëm 200 MiB, ka ~ 1,8 GiB “rezervë” të tepërt të memories. Rezerva kushton para. Mund të vlerësohet përafërsisht që 1 GiB rezervë kujton ~ 10 dollarë në muaj.
(kube-resource-report) shfaq rezervat e tepërta dhe mund t'ju ndihmojë të përcaktoni potencialin e kursimit:
tregon tepricën, e mbledhur nga aplikacioni dhe ekipi. Kjo lejon të identifikoni vendet ku kërkesat për burime mund të reduktohen. Raporti HTML i gjeneruar ofron vetëm një snapshot të përdorimit të burimeve. Duhet të shihni përdorimin e CPU/memories me kalimin e kohës për të përcaktuar kërkesat e duhura për burime. Ja një diagram Grafana për shërbimin "tipik" me ngarkesë të lartë CPU: të gjitha pod-ët përdorin dukshëm më pak se 3 bërthama CPU të kërkuara:
Reducimi i kërkesës së CPU nga 3000m në ~400m çliron burime për ngarkesa të tjera dhe lejon zvogëlimin e klasit.
"Përdorimi mesatar i CPU i instanceve EC2 shpesh luhatet në gamën e përqindjeve njëshës", . Ndërsa për EC2 , ndryshimi i disa kërkesave për burime Kubernetes në skedarin YAML është i lehtë dhe mund të sjellë një kursim të madh.
Por a duam vërtet që njerëzit të ndryshojnë vlerat në skedarët YAML? Jo, makinat mund ta bëjnë këtë shumë më mirë! Kubernetes (VPA) bën pikërisht këtë: përshtat kërkesat për burime dhe kufizimet sipas ngarkesës. Ja një shembull grafiku të kërkesave të CPU Prometheus (linja e hollë blu), të përshtatura nga VPA me kalimin e kohës:
për komponentët e infrastrukturës. Aplikacionet jo kritike gjithashtu mund të përdorin VPA.
nga Fairwind — është një mjet që krijon VPA për çdo implementim në hapësirën emrit, dhe më pas shfaq rekomandimin VPA në panelin e saj. Mund të ndihmojë zhvilluesit të vendosin kërkesat e duhura për CPU/memorie për aplikacionet e tyre:
Kam shkruar një post të vogël në vitin 2019, dhe së fundmi në .
Përdorimi i instanceve EC2 Spot
Së fundi, çka nuk është më pak e rëndësishme, kostot e AWS EC2 mund të reduktohen duke përdorur instance Spot si nodë të punës Kubernetes. Instance të Spot janë të disponueshme me zbritje deri në 90% krahasuar me çmimet nën kërkesë. Ngritja e Kubernetes në EC2 Spot — është një kombinim i mirë: ju duhet të specifikoni disa lloje të ndryshme instancash për disponueshmëri më të lartë, domethënë mund të merrni një nodë më të madhe për të njëjtën ose një çmim më të ulët, dhe kapaciteti i rritur mund të përdoret nga ngarkesat e punës me konteiner Kubernetes.
Si të ngrini Kubernetes në EC2 Spot? Ka disa mundësi: përdorni një shërbim të tretë, të tillë si SpotInst (tani quhet "Spot", mos më pyesni pse), ose thjesht shtoni Spot AutoScalingGroup (ASG) në klasterin tuaj. Për shembull, ja një fragment CloudFormation për një ASG Spot "të optimizuar për kapacitete" me disa lloje instancash:
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"Disa vërejtje mbi përdorimin e Spot me Kubernetes:
- Duhet të menaxhoni përfundimet e Spot, për shembull duke derdhur nodën gjatë ndalimit të instancës.
- Zalando përdor automatikun zyrtar të shkallëzimit të klasterit me përprioritetet e grupit të nodave.
- Nodët Spot të pranojnë "regjistrime" ngarkesash për t'u ekzekutuar në Spot.
Curriculum Vitae
Shpresoj se do të gjeni disa nga mjetet e paraqitura të dobishme për të ulur faturën tuaj për shërbime cloud. Mund të gjeni shumicën e përmbajtjes së artikullit gjithashtu në .
Cilat janë praktikat tuaja më të mira për kursimin e kostove në cloud për Kubernetes? Ju lutem, na njoftoni në .
Në të vërtetë, më pak se 3 vCPU do të mbesin të përdorshme, pasi kapaciteti i nodës zvogëlohet për shkak të burimeve sistemike të rezervuara. Kubernetes dallon midis kapacitetit fizik të nodës dhe burimeve "të alokuara" ().
Shembulli i llogaritjes: një instancë m5.large me 8 GiB memorie kushton ~84 dollarë në muaj (eu-central-1, On-Demand), pra, bllokimi i 1/8 të nodës i kushton rreth ~10 dollarë në muaj.
Ka shumë mënyra për të reduktuar faturën tuaj EC2, si instancat e rezervuara, plani i kursimeve etj. — nuk do t'i trajtoj këto tema këtu, por patjetër duhet të informoheni për to!
Burimi: habr.com
