Përkthimi i artikullit u përgatit në prag të fillimit të kursit .
Si të kurseni në kostot e cloud kur punoni me Kubernetes? Nuk ka asnjë zgjidhje të vetme të duhur, por ky artikull përshkruan disa mjete që mund t'ju ndihmojnë të menaxhoni burimet tuaja në mënyrë më efektive dhe të zvogëloni kostot tuaja të kompjuterit cloud.
E shkrova këtë artikull me Kubernetes për AWS në mendje, por ai do të zbatohet (pothuajse) saktësisht në të njëjtën mënyrë për ofruesit e tjerë të cloud. Unë po supozoj se grupi(t) tuaj tashmë kanë konfiguruar shkallëzimin automatik (). Heqja e burimeve dhe zvogëlimi i vendosjes suaj do t'ju kursejë para vetëm nëse zvogëlon flotën tuaj të nyjeve të punëtorëve (rastet EC2).
Ky artikull do të mbulojë:
- pastrimi i burimeve të papërdorura ()
- Zvogëloni shkallëzimin gjatë orëve jo pune ()
- duke përdorur shkallëzimin automatik horizontal (HPA),
- reduktimi i rezervimit të tepërt të burimeve (, VPA)
- duke përdorur rastet Spot
Pastrimi i burimeve të papërdorura
Të punosh në një mjedis me ritme të shpejta është fantastike. Ne duam organizata teknologjike . Ofrimi më i shpejtë i softuerit nënkupton gjithashtu më shumë vendosje PR, mjedise paraprake, prototipa dhe zgjidhje analitike. Gjithçka është vendosur në Kubernetes. Kush ka kohë për të pastruar manualisht vendosjet e provës? Është e lehtë të harrosh fshirjen e një eksperimenti javor. Fatura e resë kompjuterike do të përfundojë në rritje për shkak të diçkaje që kemi harruar ta mbyllim:
(Henning Jacobs:
Zhiza:
(citimet) Corey Quinn:
Miti: Llogaria juaj AWS është një funksion i numrit të përdoruesve që keni.
Fakt: Rezultati juaj AWS është një funksion i numrit të inxhinierëve që keni.
Ivan Kurnosov (në përgjigje):
Fakti i vërtetë: Rezultati juaj AWS është një funksion i numrit të gjërave që keni harruar të çaktivizoni/fshini.)
(kube-janitor) ndihmon në pastrimin e grupit tuaj. Konfigurimi i portierit është fleksibël për përdorim global dhe lokal:
- Rregullat në të gjithë grupin mund të përcaktojnë kohën maksimale për të jetuar (TTL) për vendosjet PR/test.
- Burimet individuale mund të shënohen me portier/ttl, për shembull për të hequr automatikisht majën/prototipin pas 7 ditësh.
Rregullat e përgjithshme përcaktohen në skedarin YAML. Rruga e tij kalon përmes parametrit --rules-file në kube-portier. Këtu është një rregull shembull për të hequr të gjitha hapësirat e emrave -pr- në emër pas dy ditësh:
- id: cleanup-resources-from-pull-requests
resources:
- namespaces
jmespath: "contains(metadata.name, '-pr-')"
ttl: 2dShembulli i mëposhtëm rregullon përdorimin e etiketës së aplikacionit në pods Deployment dhe StatefulSet për të gjitha Deployments/StatefulSet të reja në 2020, por në të njëjtën kohë lejon ekzekutimin e testeve pa këtë etiketë për një javë:
- 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: 7dEkzekutoni një demonstrim të kufizuar me kohë për 30 minuta në një grup ku funksionon kube-janitor:
kubectl run nginx-demo --image=nginx
kubectl annotate deploy nginx-demo janitor/ttl=30mNjë burim tjetër i rritjes së kostove janë vëllimet e vazhdueshme (AWS EBS). Fshirja e një Kubernetes StatefulSet nuk fshin vëllimet e tij të vazhdueshme (PVC - PersistentVolumeClaim). Vëllimet e papërdorura të EBS mund të rezultojnë lehtësisht në kosto prej qindra dollarësh në muaj. Kubernetes Janitor ka një veçori për të pastruar PVC-të e papërdorura. Për shembull, ky rregull do të heqë të gjitha PVC-të që nuk janë montuar nga një modul dhe që nuk referohen nga një 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 grupin tuaj të pastër dhe të parandaloni që kostot e kompjuterit cloud të grumbullohen ngadalë. Për udhëzimet e vendosjes dhe konfigurimit, ndiqni .
Zvogëloni shkallëzimin gjatë orëve jo pune
Sistemet e testimit dhe vendosjes zakonisht kërkohet të funksionojnë vetëm gjatë orarit të punës. Disa aplikacione prodhimi, të tilla si mjetet e zyrës së pasme/administratorit, gjithashtu kërkojnë disponueshmëri të kufizuar dhe mund të çaktivizohen brenda natës.
(kube-downscaler) lejon përdoruesit dhe operatorët të zvogëlojnë sistemin gjatë orëve jo pune. Vendosjet dhe StatefulSets mund të shkallëzohen në zero kopje. CronJobs mund të pezullohet. Kubernetes Downscaler është konfiguruar për një grup të tërë, një ose më shumë hapësira emrash ose burime individuale. Mund të vendosni ose "kohën e papunë" ose, anasjelltas, "kohën e punës". Për shembull, për të reduktuar shkallëzimin sa më shumë që të jetë e mundur gjatë netëve dhe fundjavave:
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-timeKëtu është një grafik për shkallëzimin e nyjeve të punëtorëve të grupimeve gjatë fundjavave:
Zvogëlimi nga ~ 13 në 4 nyje punëtore sigurisht që bën një ndryshim të dukshëm në faturën tuaj AWS.
Por, çka nëse më duhet të punoj gjatë "kohës së ndërprerjes" së grupit? Disa vendosje mund të përjashtohen përgjithmonë nga shkallëzimi duke shtuar zvogëlimin/përjashtimin: shënimin e vërtetë. Vendosjet mund të përjashtohen përkohësisht duke përdorur zvogëlimin/përjashtimin-deri në shënim me një vulë kohore absolute në formatin VVVV-MM-DD HH:MM (UTC). Nëse është e nevojshme, i gjithë grupi mund të zvogëlohet duke vendosur një pod me shënimin downscaler/force-uptime, për shembull, duke nisur nginx bosh:
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=trueShoh , nëse jeni të interesuar për udhëzimet e vendosjes dhe opsionet shtesë.
Përdorni shkallëzimin automatik horizontal
Shumë aplikacione/shërbime kanë të bëjnë me një model ngarkimi dinamik: ndonjëherë modulet e tyre janë të papunë dhe ndonjëherë ato punojnë me kapacitet të plotë. Përdorimi i një flote të përhershme me bishtaja për të përballuar ngarkesën maksimale nuk është ekonomike. Kubernetes mbështet shkallëzimin automatik horizontal nëpër një burim (HPA). Përdorimi i CPU-së është shpesh 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 ka krijuar një komponent për të lidhur me lehtësi metrikat e personalizuara për shkallëzim: (kube-metrics-adapter) është një përshtatës i përgjithshëm metrikë për Kubernetes që mund të mbledhë dhe të shërbejë metrika të personalizuara dhe të jashtme për shkallëzimin automatik horizontal të pods. Ai mbështet shkallëzimin bazuar në metrikat e Prometheus, radhët SQS dhe cilësime të tjera. Për shembull, për të shkallëzuar vendosjen tuaj në një metrikë të personalizuar të përfaqësuar nga vetë aplikacioni si JSON në /metrics përdorni:
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: AverageValueKonfigurimi i shkallëzimit automatik horizontal me HPA duhet të jetë një nga veprimet e paracaktuara për të përmirësuar efikasitetin për shërbimet pa shtetësi. Spotify ka një prezantim me përvojën dhe rekomandimet e tyre për HPA: .
Reduktoni rezervimin e tepërt të burimeve
Ngarkesat e punës së Kubernetes përcaktojnë nevojat e tyre për CPU/memorie përmes "kërkesave për burime". Burimet e CPU-së maten në bërthama virtuale ose më shpesh në "millicore", për shembull 500m nënkupton 50% vCPU. Burimet e memories maten në bajt dhe mund të përdoren prapashtesa të zakonshme, të tilla si 500Mi, që do të thotë 500 megabajt. Kërkesat e burimeve "kyçen" kapacitetin në nyjet e punës, që do të thotë se një pod me një kërkesë CPU 1000 m në një nyje me 4 vCPU do të lërë vetëm 3 vCPU të disponueshme për podet e tjera.
Plogështi (rezervë e tepërt) është ndryshimi midis burimeve të kërkuara dhe përdorimit aktual. Për shembull, një pod që kërkon 2 GiB memorie, por përdor vetëm 200 MiB, ka ~1,8 GiB memorie "të tepërt". Teprica kushton para. Mund të vlerësohet përafërsisht se 1 GiB memorie të tepërt kushton ~ 10 dollarë në muaj.
(kube-resource-raport) shfaq rezerva të tepërta dhe mund t'ju ndihmojë të përcaktoni potencialin e kursimeve:
tregon tepricën e grumbulluar sipas aplikimit dhe komandës. Kjo ju lejon të gjeni vende ku kërkesat për burime mund të reduktohen. Raporti i krijuar HTML ofron vetëm një pamje të përdorimit të burimit. Duhet të shikoni përdorimin e CPU/memorjes me kalimin e kohës për të përcaktuar kërkesat e duhura për burime. Këtu është një grafik Grafana për një shërbim "tipik" të rëndë nga CPU: të gjitha podet përdorin shumë më pak se 3 bërthamat e kërkuara të CPU:
Reduktimi i kërkesës së CPU-së nga 3000m në ~400m çliron burimet për ngarkesa të tjera pune dhe lejon që grupi të jetë më i vogël.
"Përdorimi mesatar i CPU-së i rasteve EC2 shpesh qëndron pezull në intervalin e përqindjes njëshifrore," . Ndërsa për EC2 Ndryshimi i disa pyetjeve të burimeve të Kubernetes në një skedar YAML është i lehtë dhe mund të sjellë kursime të mëdha.
Por a duam vërtet që njerëzit të ndryshojnë vlerat në skedarët YAML? Jo, makinat mund ta bëjnë shumë më mirë! Kubernetes (VPA) bën pikërisht këtë: përshtat kërkesat dhe kufizimet për burime sipas ngarkesës së punës. Këtu është një grafik shembull i kërkesave të CPU-së Prometheus (vijë e hollë blu) e përshtatur nga VPA me kalimin e kohës:
për komponentët e infrastrukturës. Aplikacionet jo kritike mund të përdorin gjithashtu VPA.
nga Fairwind është një mjet që krijon një VPA për çdo vendosje në një hapësirë emri dhe më pas shfaq një rekomandim VPA në pultin e tij. Mund të ndihmojë zhvilluesit të vendosin kërkesat e sakta të CPU/memorjes për aplikacionet e tyre:
Kam shkruar një të vogël në 2019, dhe së fundmi në .
Përdorimi i rasteve EC2 Spot
E fundit, por jo më pak e rëndësishme, kostot e AWS EC2 mund të reduktohen duke përdorur instancat Spot si nyje punonjëse të Kubernetes . Instancat Spot ofrohen me një zbritje deri në 90% në krahasim me çmimet sipas kërkesës. Ekzekutimi i 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ë, që do të thotë se mund të merrni një nyje më të madhe për të njëjtin çmim ose më të ulët, dhe kapaciteti i rritur mund të përdoret nga ngarkesat e punës të Kubernetes me kontejnerë.
Si të ekzekutoni Kubernetes në EC2 Spot? Ka disa opsione: përdorni një shërbim të palës së tretë si SpotInst (tani i quajtur "Spot", mos më pyesni pse), ose thjesht shtoni një Spot AutoScalingGroup (ASG) në grupin tuaj. Për shembull, këtu është një fragment i CloudFormation për një Spot ASG "të optimizuar nga kapaciteti" me lloje të shumëfishta shembujsh:
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 shënime për përdorimin e Spot me Kubernetes:
- Ju duhet të trajtoni përfundimet Spot, për shembull duke bashkuar nyjen kur instanca ndalet
- Zalando përdor shkallëzimi automatik i grupimit zyrtar me prioritete të grupit të nyjeve
- Nyjet e pikave pranoni "regjistrimet" e ngarkesave të punës për të ekzekutuar në Spot
Përmbledhje
Shpresoj që disa nga mjetet e paraqitura t'i gjeni të dobishme për të reduktuar faturën tuaj në renë kompjuterike. Ju gjithashtu mund të gjeni shumicën e përmbajtjeve të artikullit në .
Cilat janë praktikat tuaja më të mira për të kursyer kostot e cloud në Kubernetes? Ju lutem më njoftoni në .
Në fakt, më pak se 3 vCPU do të mbeten të përdorshme pasi xhiroja e nyjes zvogëlohet nga burimet e rezervuara të sistemit. Kubernetes bën dallimin midis kapacitetit fizik të nyjës dhe burimeve "të siguruara" ().
Shembull i llogaritjes: një shembull m5.large me 8 GiB memorie është ~84$ në muaj (eu-central-1, On-Demand), d.m.th. bllokimi i nyjes 1/8 është afërsisht 10$/muaj.
Ka shumë mënyra të tjera për të reduktuar faturën tuaj EC2, të tilla si Rastet e Rezervuara, Plani i Kursimeve, etj.
Burimi: www.habr.com