Ang paghubad sa artikulo giandam sa bisperas sa pagsugod sa kurso .
Giunsa ang pagtipig sa mga gasto sa panganod kung nagtrabaho kauban ang Kubernetes? Wala'y usa nga husto nga solusyon, apan kini nga artikulo naghulagway sa daghang mga himan nga makatabang kanimo sa pagdumala sa imong mga kapanguhaan nga mas epektibo ug makunhuran ang imong gasto sa cloud computing.
Gisulat nako kini nga artikulo uban ang Kubernetes alang sa AWS sa hunahuna, apan kini magamit (halos) parehas nga paagi sa ubang mga cloud provider. Nagtuo ko nga ang imong (mga) cluster na-configure na sa autoscaling (). Ang pagtangtang sa mga kahinguhaan ug pagpaus-os sa imong deployment makadaginot ra nimo og kwarta kung mamenosan usab niini ang imong fleet of worker nodes (EC2 instances).
Kini nga artikulo maglakip sa:
- paglimpyo sa wala magamit nga mga kahinguhaan ()
- Bawasan ang scaling sa mga oras nga wala’y trabaho ()
- gamit ang horizontal autoscaling (HPA),
- pagkunhod sa sobra nga pagreserba sa kahinguhaan (, VPA)
- gamit ang mga higayon sa Spot
Paglimpyo sa wala magamit nga mga kapanguhaan
Ang pagtrabaho sa usa ka paspas nga palibot maayo kaayo. Gusto namon ang mga organisasyon sa teknolohiya . Ang mas paspas nga paghatod sa software nagpasabot usab ug daghang PR deployment, preview environment, prototypes, ug analytics solutions. Ang tanan gi-deploy sa Kubernetes. Kinsa ang adunay oras sa paglimpyo sa mga pag-deploy sa pagsulay? Sayon nga kalimtan ang bahin sa pagtangtang sa usa ka semana nga eksperimento. Ang cloud bill mosaka tungod sa usa ka butang nga nakalimtan namong isira:
(Henning Jacobs:
Zhiza:
(mga kinutlo) Corey Quinn:
Mito: Ang imong AWS account kay usa ka function sa gidaghanon sa mga user nga naa nimo.
Kamatuoran: Ang imong AWS score kay function sa gidaghanon sa mga engineer nga naa nimo.
Ivan Kurnosov (agig tubag):
Tinuod nga kamatuoran: Ang imong marka sa AWS usa ka function sa gidaghanon sa mga butang nga imong nakalimtan nga i-disable/delete.)
(kube-janitor) motabang sa paglimpyo sa imong cluster. Ang pagsumpo sa janitor kay flexible para sa global ug lokal nga paggamit:
- Ang mga lagda sa tibuok kumpol mahimong maghubit sa labing taas nga oras-sa-pagkinabuhi (TTL) alang sa PR/test deployment.
- Ang indibidwal nga mga kahinguhaan mahimong i-annotate sa janitor/ttl, pananglitan aron awtomatikong matangtang ang spike/prototype pagkahuman sa 7 ka adlaw.
Kinatibuk-ang mga lagda gihubit sa YAML file. Ang agianan niini gipaagi sa parameter --rules-file sa kube-janitor. Ania ang usa ka pananglitan nga lagda aron matangtang ang tanan nga mga namespace nga adunay -pr- sa ngalan human sa duha ka adlaw:
- id: cleanup-resources-from-pull-requests
resources:
- namespaces
jmespath: "contains(metadata.name, '-pr-')"
ttl: 2dAng mosunod nga pananglitan nag-regulate sa paggamit sa application label sa Deployment ug StatefulSet pods para sa tanang bag-ong Deployments/StatefulSets sa 2020, apan sa samang higayon nagtugot sa pagpatuman sa mga pagsulay nga wala niini nga label sulod sa usa ka semana:
- 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: 7dPagdalag usa ka limitado nga oras nga demo sa 30 minuto sa usa ka cluster nga nagdagan sa kube-janitor:
kubectl run nginx-demo --image=nginx
kubectl annotate deploy nginx-demo janitor/ttl=30mAng laing tinubdan sa nagkataas nga gasto mao ang padayon nga volume (AWS EBS). Ang pagtangtang sa usa ka Kubernetes StatefulSet dili makatangtang sa nagpadayon nga mga volume niini (PVC - PersistentVolumeClaim). Ang wala magamit nga mga volume sa EBS dali nga moresulta sa gasto nga gatusan ka dolyar matag bulan. Ang Kubernetes Janitor adunay bahin sa paglimpyo sa wala magamit nga PVC. Pananglitan, kini nga lagda magtangtang sa tanan nga PVC nga wala gi-mount sa usa ka module ug wala gi-refer sa usa ka StatefulSet o CronJob:
# удалить все PVC, которые не смонтированы и на которые не ссылаются StatefulSets
- id: remove-unused-pvcs
resources:
- persistentvolumeclaims
jmespath: "_context.pvc_is_not_mounted && _context.pvc_is_not_referenced"
ttl: 24hMakatabang kanimo ang Kubernetes Janitor nga magpabiling limpyo ang imong cluster ug mapugngan ang mga gasto sa cloud computing nga hinayhinay nga magpundo. Para sa deployment ug configuration instructions, sunda .
Bawasan ang scaling sa mga oras nga wala’y trabaho
Ang mga sistema sa pagsulay ug dula kasagarang gikinahanglan alang sa operasyon sa mga oras sa negosyo. Ang ubang mga aplikasyon sa produksiyon, sama sa back office/admin tools, nagkinahanglan usab og limitado nga pagkaanaa ug mahimong ma-disable sa tibuok gabii.
(kube-downscaler) nagtugot sa mga tiggamit ug mga operator sa pagpaubos sa sistema sa mga oras nga wala’y trabaho. Ang mga Deployment ug StatefulSets mahimong mag-scale sa zero replicas. Ang CronJobs mahimong masuspinde. Ang Kubernetes Downscaler gi-configure para sa tibuok cluster, usa o daghan pang namespace, o indibidwal nga mga kahinguhaan. Mahimo nimong itakda ang "oras nga walay trabaho" o, sukwahi, "oras sa pagtrabaho". Pananglitan, aron makunhuran ang scaling kutob sa mahimo sa mga gabii ug katapusan sa semana:
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-timeAnia ang usa ka graph alang sa pag-scale sa mga cluster worker node sa katapusan sa semana:
Ang pag-scale gikan sa ~ 13 ngadto sa 4 nga mga worker node siguradong makahimo og usa ka mamatikdan nga kalainan sa imong AWS bill.
Apan unsa man kung kinahanglan nako nga magtrabaho sa panahon sa cluster "downtime"? Ang pipila ka mga deployment mahimong permanenteng iapil sa pag-scale pinaagi sa pagdugang sa downscaler/exclude: tinuod nga anotasyon. Ang mga deployment mahimong temporaryo nga dili iapil gamit ang downscaler/exclude-hangtud annotation nga adunay hingpit nga timestamp sa format nga YYYY-MM-DD HH:MM (UTC). Kung gikinahanglan, ang tibuok cluster mahimong ma-scale balik pinaagi sa pag-deploy og pod nga adunay annotation downscaler/force-uptime, pananglitan, pinaagi sa paglansad sa 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=trueTan-awa , kung interesado ka sa mga panudlo sa pag-deploy ug dugang nga mga kapilian.
Gamita ang horizontal autoscaling
Daghang mga aplikasyon/serbisyo ang nag-atubang sa usa ka dinamikong sumbanan sa pagkarga: usahay ang ilang mga module wala’y mahimo, ug usahay sila nagtrabaho sa tibuuk nga kapasidad. Ang pag-operate ug permanenteng panon sa mga pod aron makasagubang sa kinatas-ang peak load dili ekonomikanhon. Gisuportahan sa Kubernetes ang pinahigda nga auto-scaling sa usa ka kapanguhaan (HPA). Ang paggamit sa CPU kasagaran usa ka maayong timailhan alang sa pag-scale:
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: UtilizationNaghimo si Zalando og component aron daling makonektar ang custom metrics para sa scaling: (kube-metrics-adapter) kay generic metrics adapter para sa mga Kubernetes nga makakolekta ug makaserbisyo ug custom ug external metrics para sa horizontal autoscaling sa mga pod. Gisuportahan niini ang scaling base sa Prometheus metrics, SQS queues, ug uban pang mga setting. Pananglitan, aron i-scale ang imong deployment ngadto sa custom metric nga girepresentahan sa aplikasyon mismo isip JSON sa /metrics nga paggamit:
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: AverageValueAng pag-configure sa pinahigda nga autoscaling gamit ang HPA kinahanglan nga usa sa mga default nga aksyon aron mapauswag ang kahusayan sa mga serbisyo nga walay estado. Ang Spotify adunay presentasyon uban sa ilang kasinatian ug mga rekomendasyon alang sa HPA: .
Bawasan ang overbooking sa kapanguhaan
Ang mga workload sa Kubernetes nagtino sa ilang mga kinahanglanon sa CPU/memorya pinaagi sa "mga hangyo sa kapanguhaan." Ang mga kapanguhaan sa CPU gisukod sa mga virtual core o mas kasagaran sa "millicore", pananglitan ang 500m nagpasabot sa 50% vCPU. Ang mga kahinguhaan sa panumduman gisukod sa mga byte, ug ang kasagarang mga suffix mahimong magamit, sama sa 500Mi, nga nagpasabut nga 500 megabytes. Ang mga hangyo sa kahinguhaan nga "lock" nga kapasidad sa mga worker node, nagpasabut nga ang usa ka pod nga adunay 1000m nga hangyo sa CPU sa usa ka node nga adunay 4 nga vCPU magbilin ra sa 3 ka vCPU nga magamit sa ubang mga pod.
Slack (sobra nga reserba) mao ang kalainan tali sa gipangayo nga mga kapanguhaan ug aktuwal nga paggamit. Pananglitan, ang pod nga nangayo ug 2 GiB nga memorya pero naggamit lang ug 200 MiB adunay ~1,8 GiB nga “sobra” nga memorya. Ang sobra nga gasto sa salapi. Gibanabana sa usa nga ang 1 GiB sa sobra nga memorya nagkantidad ~ $10 matag bulan.
(kube-resource-report) nagpakita sa sobra nga mga reserba ug makatabang kanimo sa pagtino sa potensyal sa pagtipig:
nagpakita sa sobra nga aggregated pinaagi sa aplikasyon ug sugo. Kini nagtugot kanimo sa pagpangita sa mga dapit diin ang mga panginahanglanon sa kahinguhaan mahimong mapakunhod. Ang namugna nga HTML nga report naghatag lamang ug snapshot sa paggamit sa kahinguhaan. Kinahanglan nimong tan-awon ang paggamit sa CPU/memorya sa paglabay sa panahon aron mahibal-an ang igo nga mga hangyo sa kapanguhaan. Ania ang usa ka tsart sa Grafana alang sa usa ka "tipikal" nga serbisyo nga bug-at sa CPU: ang tanan nga mga pod naggamit labi ka gamay kaysa sa 3 nga gihangyo nga mga core sa CPU:
Ang pagkunhod sa hangyo sa CPU gikan sa 3000m ngadto sa ~ 400m nagpagawas sa mga kapanguhaan alang sa ubang mga workloads ug nagtugot sa cluster nga mas gamay.
"Average nga paggamit sa CPU sa EC2 nga mga higayon kanunay nga nag-hover sa usa ka digit nga porsyento nga range," . Samtang alang sa EC2 Ang pagbag-o sa pipila ka mga pangutana sa kapanguhaan sa Kubernetes sa usa ka file nga YAML dali ug mahimo’g magdala og daghang mga tinipigan.
Apan gusto ba gyud namon nga ang mga tawo magbag-o sa mga kantidad sa mga file sa YAML? Dili, ang mga makina makahimo niini nga mas maayo! Kubernetes (VPA) mao ra kana: mopahiangay sa mga hangyo sa kapanguhaan ug mga pagpugong sumala sa kabug-at sa trabaho. Ania ang usa ka pananglitan nga graph sa Prometheus CPU nga mga hangyo (manipis nga asul nga linya) nga gipahiangay sa VPA sa paglabay sa panahon:
alang sa mga sangkap sa imprastraktura. Ang dili kritikal nga mga aplikasyon mahimo usab nga mogamit sa VPA.
gikan sa Fairwind usa ka himan nga nagmugna og VPA alang sa matag deployment sa usa ka namespace ug dayon nagpakita sa rekomendasyon sa VPA sa dashboard niini. Makatabang kini sa mga nag-develop sa pagtakda sa husto nga mga hangyo sa CPU/memorya para sa ilang mga aplikasyon:
Nagsulat ko og gamay sa 2019, ug bag-o lang sa .
Paggamit sa EC2 Spot Instance
Katapusan apan dili labing gamay, ang mga gasto sa AWS EC2 mahimong makunhuran pinaagi sa paggamit sa mga higayon sa Spot ingon mga node sa trabahante sa Kubernetes . Ang mga spot instances anaa sa diskwento hangtod sa 90% kumpara sa On-Demand nga mga presyo. Ang pagpadagan sa Kubernetes sa EC2 Spot usa ka maayong kombinasyon: kinahanglan nimong ipiho ang daghang lain-laing mga tipo sa instance para sa mas taas nga pagkaanaa, nagpasabot nga makakuha ka og mas dako nga node para sa pareho o mas mubu nga presyo, ug ang dugang nga kapasidad mahimong magamit sa mga containerized nga mga workload sa Kubernetes.
Giunsa pagpadagan ang Kubernetes sa EC2 Spot? Adunay daghang mga kapilian: gamita ang serbisyo sa ikatulo nga partido sama sa SpotInst (karon gitawag nga "Spot", ayaw ako pangutana kung ngano), o pagdugang usa ka Spot AutoScalingGroup (ASG) sa imong cluster. Pananglitan, ania ang usa ka CloudFormation snippet para sa usa ka "capacity-optimized" Spot ASG nga adunay daghang mga tipo sa pananglitan:
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"Pipila ka mga nota sa paggamit sa Spot uban sa Kubernetes:
- Kinahanglan nimong dumalahon ang mga pagtapos sa Spot, pananglitan pinaagi sa paghiusa sa node kung gihunong ang higayon
- Gigamit ni Zalando opisyal nga cluster autoscaling nga adunay mga prayoridad sa node pool
- Mga spot node dawata ang "mga rehistro" sa mga workloads nga modagan sa Spot
Sumaryo
Nanghinaut ko nga makit-an nimo ang pipila sa mga himan nga gipresentar nga mapuslanon sa pagkunhod sa imong bayronon sa panganod. Makita usab nimo ang kadaghanan sa mga sulud sa artikulo sa .
Unsa ang imong labing maayo nga mga gawi sa pagtipig sa mga gasto sa panganod sa Kubernetes? Palihug pahibaloa ako sa .
Sa tinuud, wala’y 3 ka vCPU ang magpabilin nga magamit tungod kay ang throughput sa node gipakunhod pinaagi sa gireserba nga mga kapanguhaan sa sistema. Ang mga Kubernetes nagpalahi tali sa pisikal nga kapasidad sa node ug "gihatag" nga mga kapanguhaan ().
Pananglitan sa kalkulasyon: usa ka m5.dako nga pananglitan nga adunay 8 GiB nga memorya mao ang ~$84 kada bulan (eu-central-1, On-Demand), i.e. ang pag-ali sa 1/8 nga node gibana-bana nga ~$10/bulan.
Adunay daghan pa nga mga paagi sa pagpakunhod sa imong EC2 bill, sama sa Reserved Instances, Savings Plan, ug uban pa - Dili nako hisgotan ang mga hilisgutan dinhi, apan kinahanglan nimo nga tan-awon kini!
Source: www.habr.com