Ikastaroa hasi bezperan prestatu zen artikuluaren itzulpena .
Nola aurreztu hodeiko kostuetan Kubernetesekin lan egiten duzunean? Ez dago irtenbide egoki bakarra, baina artikulu honek zure baliabideak modu eraginkorragoan kudeatzen eta hodeiko informatika kostuak murrizten lagunduko dizuten hainbat tresna deskribatzen ditu.
Artikulu hau idatzi nuen Kubernetes AWSrako kontuan hartuta, baina (ia) berdin aplikatuko da hodeiko beste hornitzaile batzuei. Suposatzen dut zure kluster(k) dagoeneko autoeskala konfiguratuta dutela (). Baliabideak kentzeak eta inplementazioa txikitzeak dirua aurreztuko dizu zure langile-nodoen flota ere murrizten badu (EC2 instantzia).
Artikulu honek:
- erabili gabeko baliabideak garbitzea ()
- Murriztu eskalatzea lanik gabeko orduetan ()
- Autoscaling horizontala (HPA) erabiliz
- gehiegizko baliabideen erreserba murriztea (, VPA)
- Spot instantziak erabiliz
Erabiltzen ez diren baliabideak garbitzea
Erritmo bizkorreko ingurune batean lan egitea bikaina da. Erakunde teknologikoak nahi ditugu . Softwarearen entrega azkarragoak PR inplementazio, aurrebista-ingurune, prototipo eta soluzio analitiko gehiago ere esan nahi du. Dena Kubernetesen zabaltzen da. Nork du denbora proba-inplementazioak eskuz garbitzeko? Erraza da astebeteko esperimentu bat ezabatzeaz ahaztea. Hodeiaren faktura igotzen amaituko da ixtea ahaztu zaigun zerbaitengatik:
(Henning Jacobs:
Zhiza:
(aipuak) Corey Quinn:
Mitoa: Zure AWS kontua duzun erabiltzaile kopuruaren funtzioa da.
Izan ere: zure AWS puntuazioa duzun ingeniari kopuruaren funtzioa da.
Ivan Kurnosov (erantzun gisa):
Egia da: zure AWS puntuazioa desgaitu/ezabatzea ahaztu duzun gauza kopuruaren funtzioa da.)
(kube-janitor) zure clusterra garbitzen laguntzen du. Atezainaren konfigurazioa malgua da erabilera global eta lokalerako:
- Kluster osoko arauek PR/proba inplementazioetarako gehienezko bizi-denbora (TTL) defini dezakete.
- Banakako baliabideak janitor/ttl-rekin oharta daitezke, adibidez 7 egunen buruan punta/prototipoa automatikoki kentzeko.
Arau orokorrak YAML fitxategian definitzen dira. Bere bidea parametrotik pasatzen da --rules-file kube-janitor in. Hona hemen izen-espazio guztiak kentzeko arau adibide bat -pr- bi egunen buruan izenean:
- id: cleanup-resources-from-pull-requests
resources:
- namespaces
jmespath: "contains(metadata.name, '-pr-')"
ttl: 2dOndorengo adibide honek Deployment eta StatefulSet pod-en aplikazioaren etiketaren erabilera arautzen du 2020ko Inplementazio/StatefulSet berri guztietarako, baina aldi berean etiketa hori gabe probak egiteko aukera ematen du astebetez:
- 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: 7dExekutatu denbora mugatuko demo bat 30 minutuz kube-janitor exekutatzen duen kluster batean:
kubectl run nginx-demo --image=nginx
kubectl annotate deploy nginx-demo janitor/ttl=30mKostuak handitzeko beste iturri bat bolumen iraunkorrak (AWS EBS) dira. Kubernetes StatefulSet bat ezabatzeak ez ditu bere bolumen iraunkorrak ezabatzen (PVC - PersistentVolumeClaim). Erabiltzen ez diren EBS bolumenek hilero ehunka dolar kostuak erraz ditzakete. Kubernetes Janitorrek erabili gabeko PVCak garbitzeko eginbide bat du. Adibidez, arau honek modulu batek muntatzen ez dituen eta StatefulSet edo CronJob-ek erreferentziarik ez duten PVC guztiak kenduko ditu:
# удалить все PVC, которые не смонтированы и на которые не ссылаются StatefulSets
- id: remove-unused-pvcs
resources:
- persistentvolumeclaims
jmespath: "_context.pvc_is_not_mounted && _context.pvc_is_not_referenced"
ttl: 24hKubernetes Janitor-ek zure clusterra garbi mantentzen lagunduko dizu eta hodeiko informatikako kostuak poliki-poliki pilatzea ekiditen. Inplementazio eta konfigurazio argibideak lortzeko, jarraitu .
Murriztu eskalatzea lanik gabeko orduetan
Proba eta eszenatze sistemak normalean lanorduetan soilik funtzionatzeko behar dira. Produkzio-aplikazio batzuek, hala nola back office/administrazio-tresnek, erabilgarritasun mugatua baino ez dute behar eta baliteke egun batetik bestera desgaitzea.
(kube-downscaler) erabiltzaileei eta operadoreei sistema eskalatzeko aukera ematen die lanorduz kanpoko orduetan. Inplementazioak eta StatefulSets zero erreplika eskala daitezke. CronJobs eten daiteke. Kubernetes Downscaler kluster oso baterako, izen-espazio baterako edo gehiagorako edo baliabide indibidual baterako konfiguratuta dago. "Inaktibo-denbora" edo, alderantziz, "lan-denbora" ezar dezakezu. Adibidez, gau eta asteburuetan eskalatzea ahalik eta gehien murrizteko:
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-timeHona hemen asteburuetan cluster-eko langile-nodoak eskalatzeko grafiko bat:
~ 13 langile-nodotik 4ra jaistea, zalantzarik gabe, alde nabarmena da zure AWS fakturan.
Baina zer gertatzen da klusterraren "geldialdi" garaian lan egin behar badut? Zenbait inplementazio eskalatzetik behin betiko baztertu daitezke beheranzko eskalatzailea/baztertu: egiazko oharpena gehituz. Inplementazioak aldi baterako baztertu daitezke beheranzko eskalatzailea/exclude-until ohartarazpena erabiliz, denbora-zigilu absolutu batekin, YYYY-MM-DD HH:MM (UTC) formatuan. Beharrezkoa izanez gero, kluster osoa eskala daiteke oharpenarekin pod bat zabalduz downscaler/force-uptime, adibidez, nginx blank abiaraziz:
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=trueIkusi , zabaltzeko argibideak eta aukera osagarriak interesatzen bazaizkizu.
Erabili autoeskala horizontala
Aplikazio/zerbitzu askok karga-eredu dinamiko bati aurre egiten diote: batzuetan haien moduluak inaktibo daude, eta beste batzuetan gaitasun osoz funtzionatzen dute. Lekaren flota iraunkor bat ustiatzea ez da ekonomikoa gehieneko kargari aurre egiteko. Kubernetes-ek eskalatze automatiko horizontala onartzen du baliabide batean zehar (HPA). PUZaren erabilera eskalatzeko adierazle ona da sarritan:
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: UtilizationZalandok osagai bat sortu du eskalatzeko neurri pertsonalizatuak erraz konektatzeko: (kube-metrics-adapter) Kubernetesentzako neurketa-egokitzaile generiko bat da, eta sistema pertsonalizatuak eta kanpoko neurriak bildu eta horni ditzake, lekak horizontalki eskalatzeko. Prometheus-en metriketan, SQS ilaretan eta beste ezarpen batzuetan oinarritutako eskalatzea onartzen du. Adibidez, zure inplementazioa aplikazioak berak JSON gisa adierazten duen metrika pertsonalizatu batera eskalatzeko /metrics use:
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: AverageValueHPArekin autoeskala horizontala konfiguratzea estaturik gabeko zerbitzuen eraginkortasuna hobetzeko ekintza lehenetsietako bat izan beharko litzateke. Spotify-k HPArako duten esperientzia eta gomendioekin aurkezpen bat egin du: .
Murriztu baliabideen gehiegizko erreserba
Kubernetesen lan-kargak beren CPU/memoria beharrak zehazten dituzte "baliabide-eskaeren" bidez. CPU baliabideak nukleo birtualetan neurtzen dira edo normalean "milikoreetan" neurtzen dira, adibidez, 500m-k %50eko vCPU dakar. Memoria-baliabideak bytetan neurtzen dira, eta atzizki arruntak erabil daitezke, adibidez, 500Mi, hau da, 500 megabyte. Baliabideen eskaerak langile-nodoetan gaitasuna "blokeatu" egiten du, hau da, 1000 m-ko CPU eskaera duen pod batek 4 vCPU dituen nodo batean 3 vCPU baino ez ditu erabilgarri utziko beste podentzat.
Slack (gehiegizko erreserba) eskatutako baliabideen eta benetako erabileraren arteko aldea da. Adibidez, 2 GiB memoria eskatzen duen baina 200 MiB soilik erabiltzen dituen pod batek ~ 1,8 GiB "gehiegizko" memoria du. Gehiegizkoak dirua kostatzen du. Gutxi gorabehera kalkula daiteke 1 GiB memoria erredundanteak ~ $ 10 hilean balio duela.
(kube-resource-report) gehiegizko erreserbak erakusten ditu eta aurrezteko potentziala zehazten lagun zaitzake:
aplikazioaren eta komandoen arabera gehitutako soberakina erakusten du. Horri esker, baliabideen eskaerak murrizteko tokiak aurki ditzakezu. Sortutako HTML txostenak baliabideen erabileraren argazkia baino ez du ematen. PUZaren/memoriaren erabilera denboran zehar aztertu beharko zenuke baliabideen eskaera egokiak zehazteko. Hona hemen Grafana grafiko bat CPU-astuneko zerbitzu "ohiko" baterako: pod guztiek eskatutako 3 CPU nukleoak baino nabarmen gutxiago erabiltzen dituzte:
PUZaren eskaera 3000m-tik ~ 400m-ra murrizteak beste lan-karga batzuetarako baliabideak askatzen ditu eta clusterra txikiagoa izatea ahalbidetzen du.
"EC2 instantzien PUZaren batez besteko erabilera zifra bakarreko ehuneko-tartean pasa ohi da" . EC2rako berriz YAML fitxategi batean Kubernetes baliabideen kontsulta batzuk aldatzea erraza da eta aurrezpen handiak ekar ditzake.
Baina benetan nahi al dugu jendeak YAML fitxategietan balioak aldatzea? Ez, makinek askoz hobeto egin dezakete! Kubernetes (VPA) horixe egiten du: baliabideen eskaerak eta mugak lan-kargaren arabera egokitzen ditu. Hona hemen VPAk denboran zehar egokitutako Prometheus CPU eskaeren (lerro urdin mehea) grafiko adibide bat:
azpiegitura osagaietarako. Kritikoak ez diren aplikazioek VPA ere erabil dezakete.
Fairwind-ek izen-espazio batean inplementazio bakoitzerako VPA bat sortzen duen tresna da eta, ondoren, VPA gomendio bat bistaratzen du bere panelean. Garatzaileei beren aplikazioetarako CPU/memoria eskaera zuzenak ezartzen lagun diezaieke:
txiki bat idatzi nuen 2019an, eta duela gutxi urtean .
EC2 Spot Instantziak erabiltzea
Azkenik, AWS EC2 kostuak murriztu daitezke Spot instantziak Kubernetesen langile-nodo gisa erabiliz. . Lekuko instantziak % 90erainoko deskontuarekin eskuragarri daude Eskaera Onartutako prezioekin alderatuta. Kubernetes EC2 Spot-en exekutatzen konbinazio ona da: hainbat instantzia mota desberdin zehaztu behar dituzu erabilgarritasun handiagoa izateko, hau da, nodo handiagoa lor dezakezu prezio berdinean edo baxuagoan, eta edukiontzi handitu Kubernetes lan-kargak erabil dezakete.
Nola exekutatu Kubernetes EC2 Spot-en? Hainbat aukera daude: erabili SpotInst bezalako hirugarrenen zerbitzu bat (gaur egun "Spot" izenekoa, ez galdetu zergatik), edo, besterik gabe, gehitu Spot AutoScalingGroup (ASG) zure klusterrean. Adibidez, hona hemen CloudFormation zati bat "edukiera optimizatutako" Spot ASG baterako hainbat instantzia mota dituena:
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"Spot Kubernetes-ekin erabiltzeari buruzko ohar batzuk:
- Spot amaierak kudeatu behar dituzu, adibidez, instantzia gelditzen denean nodoa batuz
- Zalandok erabiltzen du klusterren autoeskalatze ofiziala nodoen multzoko lehentasunekin
- Spot nodoak onartu Spot-en exekutatzeko lan-kargaren "erregistroak".
Laburpena
Aurkeztutako tresna batzuk zure hodeiko faktura murrizteko erabilgarriak izatea espero dut. Artikuluaren eduki gehienak hemen ere aurki ditzakezu .
Zeintzuk dira Kubernetes-en hodeiko kostuak aurrezteko praktika onenak? Mesedez, jakinarazi iezadazu helbidean .
Izan ere, 3 vCPU baino gutxiago erabilgarri jarraituko dute nodoaren erreserba sistemaren baliabideek murriztu egiten baitute. Kubernetes-ek nodo fisikoen gaitasuna eta "hornitutako" baliabideak bereizten ditu ().
Kalkulu-adibidea: 5 GiB-ko memoria duen m8.instantzia handi bat hilean ~ $ 84 da (eu-central-1, On-Demand), hau da. 1/8 nodo blokeatzea ~ $ 10 hilean da gutxi gorabehera.
EC2 faktura murrizteko beste modu asko daude, hala nola Erreserbatutako Instantziak, Aurrezki Plana, etab. - Ez ditut gai horiek landuko hemen, baina aztertu beharko zenituzke zalantzarik gabe!
Iturria: www.habr.com