La traducció de l'article es va preparar la vigília de l'inici del curs .
Com estalviar en costos al núvol quan es treballa amb Kubernetes? No hi ha una solució adequada, però aquest article descriu diverses eines que us poden ajudar a gestionar els vostres recursos de manera més eficaç i reduir els costos de computació en núvol.
He escrit aquest article tenint en compte Kubernetes per a AWS, però s'aplicarà (gairebé) exactament de la mateixa manera a altres proveïdors de núvol. Suposo que els vostres clústers ja tenen l'escala automàtica configurada (). Eliminar recursos i reduir el desplegament només us estalviarà diners si també reduïu la vostra flota de nodes de treball (instàncies EC2).
Aquest article tractarà:
- netejar els recursos no utilitzats ()
- Reduir l'escala durant les hores no laborals ()
- utilitzant l'escalat automàtic horitzontal (HPA),
- reducció de la reserva excessiva de recursos (, VPA)
- utilitzant instàncies Spot
Neteja de recursos no utilitzats
Treballar en un entorn de ritme ràpid és fantàstic. Volem organitzacions tecnològiques . L'entrega de programari més ràpida també significa més desplegaments de relacions públiques, entorns de previsualització, prototips i solucions d'anàlisi. Tot es desplega a Kubernetes. Qui té temps per netejar manualment els desplegaments de prova? És fàcil oblidar-se de suprimir un experiment d'una setmana. La factura del núvol acabarà augmentant a causa d'alguna cosa que vam oblidar de tancar:
(Henning Jacobs:
Zhiza:
(cites) Corey Quinn:
Mite: el vostre compte d'AWS és una funció del nombre d'usuaris que teniu.
Fet: la vostra puntuació d'AWS és una funció del nombre d'enginyers que teniu.
Ivan Kurnosov (en resposta):
Fet real: la vostra puntuació d'AWS és una funció del nombre de coses que heu oblidat de desactivar/suprimir.)
(kube-janitor) ajuda a netejar el vostre clúster. La configuració del conserge és flexible tant per a ús global com local:
- Les regles de tot el clúster poden definir el temps de vida màxim (TTL) per als desplegaments de PR/prova.
- Els recursos individuals es poden anotar amb janitor/ttl, per exemple per eliminar automàticament l'espiga/prototip després de 7 dies.
Les regles generals es defineixen al fitxer YAML. El seu camí passa pel paràmetre --rules-file en kube-conserge. Aquí hi ha un exemple de regla per eliminar tots els espais de noms -pr- al nom després de dos dies:
- id: cleanup-resources-from-pull-requests
resources:
- namespaces
jmespath: "contains(metadata.name, '-pr-')"
ttl: 2dL'exemple següent regula l'ús de l'etiqueta de l'aplicació als pods Deployment i StatefulSet per a tots els nous Deployments/StatefulSets el 2020, però alhora permet l'execució de proves sense aquesta etiqueta durant una setmana:
- 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: 7dExecuteu una demostració de temps limitat durant 30 minuts en un clúster amb kube-janitor:
kubectl run nginx-demo --image=nginx
kubectl annotate deploy nginx-demo janitor/ttl=30mUna altra font d'augment de costos són els volums persistents (AWS EBS). La supressió d'un Kubernetes StatefulSet no suprimeix els seus volums persistents (PVC - PersistentVolumeClaim). Els volums d'EBS no utilitzats poden provocar fàcilment costos de centenars de dòlars al mes. Kubernetes Janitor té una funció per netejar els PVC no utilitzats. Per exemple, aquesta regla eliminarà tots els PVC que no estan muntats per un mòdul i als quals no fa referència un StatefulSet o CronJob:
# удалить все PVC, которые не смонтированы и на которые не ссылаются StatefulSets
- id: remove-unused-pvcs
resources:
- persistentvolumeclaims
jmespath: "_context.pvc_is_not_mounted && _context.pvc_is_not_referenced"
ttl: 24hKubernetes Janitor us pot ajudar a mantenir net el vostre clúster i evitar que els costos de computació en núvol s'acumulin lentament. Per obtenir instruccions de desplegament i configuració, seguiu .
Reduir l'escala durant les hores no laborals
Normalment, els sistemes de prova i escenificació només es requereixen per funcionar durant l'horari comercial. Algunes aplicacions de producció, com ara les eines de back office/administració, també requereixen una disponibilitat limitada i es poden desactivar durant la nit.
(kube-downscaler) permet als usuaris i operadors reduir el sistema durant les hores no laborals. Els desplegaments i StatefulSets poden escalar fins a zero rèpliques. CronJobs es pot suspendre. Kubernetes Downscaler es configura per a un clúster sencer, un o més espais de noms o recursos individuals. Podeu configurar el "temps d'inactivitat" o, al contrari, el "temps de treball". Per exemple, per reduir l'escala tant com sigui possible durant les nits i els caps de setmana:
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-timeAquí teniu un gràfic per escalar els nodes de treball del clúster els caps de setmana:
Reduir de ~ 13 a 4 nodes de treball sens dubte fa una diferència notable en la vostra factura d'AWS.
Però, què passa si he de treballar durant el "temps d'inactivitat" del clúster? Alguns desplegaments es poden excloure permanentment de l'escala afegint l'anotació reducció/exclusió: veritable. Els desplegaments es poden excloure temporalment mitjançant l'anotació de reducció/exclusió fins a una marca de temps absoluta en el format AAAA-MM-DD HH:MM (UTC). Si cal, es pot redimensionar tot el clúster desplegant un pod amb l'anotació downscaler/force-uptime, per exemple, llançant 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=trueVeure , si esteu interessats en instruccions de desplegament i opcions addicionals.
Utilitzeu l'autoescala horitzontal
Moltes aplicacions/serveis tracten amb un patró de càrrega dinàmica: de vegades els seus mòduls estan inactius i de vegades funcionen a plena capacitat. Operar una flota permanent de beines per fer front a la càrrega màxima màxima no és econòmic. Kubernetes admet l'escalat automàtic horitzontal a través d'un recurs (HPA). L'ús de la CPU és sovint un bon indicador per escalar:
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 ha creat un component per connectar fàcilment mètriques personalitzades per escalar: (kube-metrics-adapter) és un adaptador de mètriques genèrics per a Kubernetes que pot recopilar i publicar mètriques personalitzades i externes per a l'escalat automàtic horitzontal dels pods. Admet l'escalat basat en mètriques de Prometheus, cues SQS i altres configuracions. Per exemple, per escalar el desplegament a una mètrica personalitzada representada per l'aplicació com a JSON a /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: AverageValueLa configuració de l'escala automàtica horitzontal amb HPA hauria de ser una de les accions predeterminades per millorar l'eficiència dels serveis sense estat. Spotify té una presentació amb la seva experiència i recomanacions per a HPA: .
Reduir l'excés de reserva de recursos
Les càrregues de treball de Kubernetes determinen les seves necessitats de memòria i CPU mitjançant "sol·licituds de recursos". Els recursos de la CPU es mesuren en nuclis virtuals o més habitualment en "millicores", per exemple, 500 m implica un 50% de vCPU. Els recursos de memòria es mesuren en bytes i es poden utilitzar sufixos comuns, com ara 500Mi, que significa 500 megabytes. Les sol·licituds de recursos "bloquegen" la capacitat als nodes de treball, és a dir, un pod amb una sol·licitud de CPU de 1000 m en un node amb 4 vCPU només deixarà 3 vCPU disponibles per a altres pods.
Slack (excés de reserva) és la diferència entre els recursos sol·licitats i l'ús real. Per exemple, un pod que sol·licita 2 GiB de memòria però només utilitza 200 MiB té ~ 1,8 GiB de memòria "excés". L'excés costa diners. Es pot estimar aproximadament que 1 GiB de memòria redundant costa ~ 10 dòlars al mes.
(kube-resource-report) mostra l'excés de reserves i us pot ajudar a determinar el potencial d'estalvi:
mostra l'excés agregat per aplicació i comanda. Això us permet trobar llocs on es pugui reduir la demanda de recursos. L'informe HTML generat només proporciona una instantània de l'ús dels recursos. Hauríeu de mirar l'ús de la CPU/memòria al llarg del temps per determinar les sol·licituds de recursos adequades. Aquí teniu un gràfic de Grafana per a un servei "típic" amb una gran quantitat de CPU: tots els pods utilitzen molt menys que els 3 nuclis de CPU sol·licitats:
La reducció de la sol·licitud de CPU de 3000 m a ~ 400 m allibera recursos per a altres càrregues de treball i permet que el clúster sigui més petit.
"L'ús mitjà de la CPU de les instàncies EC2 sovint se situa en l'interval percentual d'un sol dígit", . Mentre que per EC2 Canviar algunes consultes de recursos de Kubernetes en un fitxer YAML és fàcil i pot suposar un gran estalvi.
Però realment volem que la gent canviï els valors dels fitxers YAML? No, les màquines ho poden fer molt millor! Kubernetes (VPA) fa exactament això: adapta les sol·licituds de recursos i les limitacions segons la càrrega de treball. Aquí teniu un gràfic d'exemple de sol·licituds de CPU Prometheus (línia blava fina) adaptades per VPA al llarg del temps:
per als components de la infraestructura. Les aplicacions no crítiques també poden utilitzar VPA.
de Fairwind és una eina que crea un VPA per a cada desplegament en un espai de noms i després mostra una recomanació VPA al seu tauler. Pot ajudar els desenvolupadors a establir les sol·licituds correctes de CPU/memoria per a les seves aplicacions:
Vaig escriure un petit el 2019, i recentment a .
Ús d'instàncies EC2 Spot
Finalment, però no menys important, els costos d'AWS EC2 es poden reduir utilitzant instàncies Spot com a nodes de treball de Kubernetes . Les instàncies puntuals estan disponibles amb un descompte de fins a un 90% en comparació amb els preus a la carta. L'execució de Kubernetes a EC2 Spot és una bona combinació: heu d'especificar diversos tipus d'instàncies diferents per a una major disponibilitat, el que significa que podeu obtenir un node més gran pel mateix preu o per un preu més baix, i la capacitat augmentada es pot utilitzar per càrregues de treball de Kubernetes en contenidors.
Com executar Kubernetes a EC2 Spot? Hi ha diverses opcions: utilitzar un servei de tercers com SpotInst (ara anomenat "Spot", no em pregunteu per què) o simplement afegir un Spot AutoScalingGroup (ASG) al vostre clúster. Per exemple, aquí hi ha un fragment de CloudFormation per a un Spot ASG "optimitzat per la capacitat" amb diversos tipus d'instàncies:
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"Algunes notes sobre l'ús de Spot amb Kubernetes:
- Heu de gestionar les terminacions puntuals, per exemple, fusionant el node quan la instància s'atura
- Zalando utilitza Escalat automàtic del clúster oficial amb prioritats del grup de nodes
- Nodes puntuals acceptar "registres" de càrregues de treball per executar-se a Spot
Resum
Espero que trobeu útils algunes de les eines presentades per reduir la vostra factura al núvol. També podeu trobar la majoria del contingut de l'article a .
Quines són les vostres pràctiques recomanades per estalviar costos del núvol a Kubernetes? Si us plau, feu-m'ho saber a .
De fet, es mantindran utilitzables menys de 3 vCPU, ja que el rendiment del node es redueix amb els recursos reservats del sistema. Kubernetes distingeix entre la capacitat del node físic i els recursos "provisionats" ().
Exemple de càlcul: una instància m5.large amb 8 GiB de memòria és de ~ $ 84 per mes (eu-central-1, On-Demand), és a dir. bloquejar el node 1/8 és d'aproximadament 10 dòlars al mes.
Hi ha moltes més maneres de reduir la vostra factura EC2, com ara Instàncies reservades, Pla d'estalvi, etc. No tractaré aquests temes aquí, però definitivament hauríeu de mirar-los!
Font: www.habr.com