🥇Ngirit biaya awan Kubernetes ing AWS

Terjemahan artikel disiapake ing wayah wengi wiwitan kursus "Platform infrastruktur adhedhasar Kubernetes".

Kepiye cara ngirit biaya awan nalika nggarap Kubernetes? Ora ana solusi sing bener, nanging artikel iki nerangake sawetara alat sing bisa mbantu sampeyan ngatur sumber daya kanthi luwih efektif lan nyuda biaya komputasi awan.

Aku nulis artikel iki karo Kubernetes kanggo AWS, nanging bakal ditrapake (meh) kanthi cara sing padha karo panyedhiya maya liyane. Aku nganggep kluster sampeyan wis duwe autoscaling dikonfigurasi (cluster-autoscaler). Mbusak sumber daya lan nyuda panyebaran sampeyan mung bakal ngirit dhuwit yen uga nyuda armada node pekerja (kasus EC2).

Artikel iki bakal nyakup:

ngresiki sumber daya sing ora digunakake (kube-janitor)
Ngurangi skala sajrone jam kerja (kube-downscaler)
nggunakake horizontal autoscaling (HPA),
ngurangi reservasi sumber daya sing berlebihan (kube-resource-report, VPA)
nggunakake kedadean Spot

Ngresiki sumber daya sing ora digunakake

Makarya ing lingkungan sing cepet banget. Kita pengin organisasi teknologi digawe cepet. Pangiriman piranti lunak sing luwih cepet uga tegese luwih akeh panyebaran PR, lingkungan pratinjau, prototipe, lan solusi analitik. Kabeh wis disebarake ing Kubernetes. Sapa sing duwe wektu kanggo ngresiki penyebaran tes kanthi manual? Gampang lali babagan mbusak eksperimen sing lawas seminggu. Tagihan awan bakal mundhak amarga ana sing lali ditutup:

(Henning Jacobs:
Zhiza:
(kutipan) Corey Quinn:
Mitos: Akun AWS sampeyan minangka fungsi saka jumlah pangguna sing sampeyan duwe.
Kasunyatan: Skor AWS sampeyan minangka fungsi saka jumlah insinyur sing sampeyan duwe.

Ivan Kurnosov (minangka wangsulan):
Kasunyatan nyata: Skor AWS sampeyan minangka fungsi saka jumlah perkara sing sampeyan kelalen mateni / mbusak.)

Kubernetes Janitor (kube-janitor) mbantu ngresiki cluster sampeyan. Konfigurasi janitor fleksibel kanggo panggunaan global lan lokal:

Aturan cluster-wide bisa nemtokake wektu-kanggo-urip maksimum (TTL) kanggo PR / panyebaran test.
Sumber daya individu bisa dianotasi karo janitor/ttl, contone kanggo mbusak spike / prototipe kanthi otomatis sawise 7 dina.

Aturan umum ditetepake ing file YAML. Path kasebut dilewati liwat parameter --rules-file ing kube-janitor. Punika conto aturan kanggo mbusak kabeh namespaces karo -pr- ing jeneng sawise rong dina:

- id: cleanup-resources-from-pull-requests
  resources:
    - namespaces
  jmespath: "contains(metadata.name, '-pr-')"
  ttl: 2d

Conto ing ngisor iki ngatur panggunaan label aplikasi ing pod Deployment lan StatefulSet kanggo kabeh Deployments/StatefulSet anyar ing 2020, nanging ing wektu sing padha ngidini eksekusi tes tanpa label iki sajrone seminggu:

- 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: 7d

Jalanake demo winates wektu sajrone 30 menit ing kluster sing mlaku kube-janitor:

kubectl run nginx-demo --image=nginx
kubectl annotate deploy nginx-demo janitor/ttl=30m

Sumber liyane sing nambah biaya yaiku volume terus-terusan (AWS EBS). Mbusak Kubernetes StatefulSet ora mbusak volume terus-terusan (PVC - PersistentVolumeClaim). Volume EBS sing ora digunakake kanthi gampang bisa nyebabake biaya atusan dolar saben wulan. Kubernetes Janitor nduweni fitur kanggo ngresiki PVC sing ora digunakake. Contone, aturan iki bakal mbusak kabeh PVC sing ora dipasang dening modul lan ora dirujuk dening StatefulSet utawa CronJob:

# удалить все PVC, которые не смонтированы и на которые не ссылаются StatefulSets
- id: remove-unused-pvcs
  resources:
  - persistentvolumeclaims
  jmespath: "_context.pvc_is_not_mounted && _context.pvc_is_not_referenced"
  ttl: 24h

Kubernetes Janitor bisa mbantu supaya kluster tetep resik lan nyegah biaya komputasi awan supaya ora numpuk. Kanggo panyebaran lan instruksi konfigurasi, tindakake README kube-janitor.

Ngurangi skala sajrone jam kerja

Sistem tes lan pementasan biasane dibutuhake kanggo operasi mung sajrone jam kerja. Sawetara aplikasi produksi, kayata alat back office/admin, uga mbutuhake kasedhiyan winates lan bisa dipateni sewengi.

Kubernetes Downscaler (kube-downscaler) ngidini pangguna lan operator nyuda sistem sajrone jam ora kerja. Deployments lan StatefulSets bisa skala kanggo replika nol. CronJobs bisa ditundha. Kubernetes Downscaler dikonfigurasi kanggo kabeh kluster, siji utawa luwih spasi jeneng, utawa sumber daya individu. Sampeyan bisa nyetel "wektu nganggur" utawa, kosok balene, "wektu kerja". Contone, kanggo nyuda skala sabisane ing wayah wengi lan akhir minggu:

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-time

Iki minangka grafik kanggo skala simpul pekerja kluster ing akhir minggu:

Scaling mudhun saka ~ 13 kanggo 4 node buruh mesthi ndadekake prabédan ngelingke ing tagihan AWS Panjenengan.

Nanging kepiye yen aku kudu kerja sajrone "downtime" kluster? Penyebaran tartamtu bisa diilangi kanthi permanen saka skala kanthi nambahake downscaler/exclude: true annotation. Panyebaran bisa diilangi sementara nggunakake anotasi downscaler / exclude-nganti kanthi cap wektu absolut ing format YYYY-MM-DD HH: MM (UTC). Yen perlu, kabeh kluster bisa dikurangi kanthi nggunakake pod kanthi anotasi downscaler/force-uptime, contone, kanthi mbukak 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=true

Deleng README kube-downscaler, yen sampeyan kasengsem ing instruksi panyebaran lan opsi tambahan.

Gunakake autoscaling horisontal

Akeh aplikasi/layanan sing ngurusi pola loading dinamis: kadhangkala modul-module ora aktif, lan kadhangkala bisa digunakake kanthi kapasitas penuh. Ngoperasikake armada pods permanen kanggo ngatasi beban puncak maksimal ora ekonomis. Kubernetes ndhukung skala otomatis horisontal ing sumber daya HorizontalPodAutoscaler (HPA). Panggunaan CPU asring minangka indikator sing apik kanggo skala:

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: Utilization

Zalando wis nggawe komponen kanggo nyambungake metrik khusus kanthi gampang kanggo skala: Adaptor Metrik Kube (kube-metrics-adapter) minangka adaptor metrik umum kanggo Kubernetes sing bisa ngumpulake lan ngladeni metrik khusus lan eksternal kanggo skala otomatis horisontal saka pods. Ndhukung skala adhedhasar metrik Prometheus, antrian SQS, lan setelan liyane. Contone, kanggo skala penyebaran sampeyan menyang metrik khusus sing diwakili dening aplikasi kasebut dhewe minangka JSON ing /metrics nggunakake:

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: AverageValue

Konfigurasi autoscaling horisontal karo HPA kudu dadi salah siji saka tumindak standar kanggo nambah efisiensi kanggo layanan stateless. Spotify duwe presentasi karo pengalaman lan rekomendasi kanggo HPA: skala penyebaran sampeyan, dudu dompet sampeyan.

Ngurangi overbooking sumber

Beban kerja Kubernetes nemtokake kabutuhan CPU/memori liwat "panyuwunan sumber daya." Sumber daya CPU diukur ing inti virtual utawa luwih umum ing "milicore", contone 500m tegese 50% vCPU. Sumber daya memori diukur ing bita, lan suffix umum bisa digunakake, kayata 500Mi, sing tegese 500 megabyte. Sumber daya njaluk kapasitas "kunci" ing kelenjar buruh, tegese pod karo panjalukan CPU 1000m ing simpul karo 4 vCPU bakal ninggalake mung 3 vCPU kasedhiya kanggo pods liyane. [1]

Slack (keluwihan cadangan) yaiku prabédan antarane sumber daya sing dijaluk lan panggunaan nyata. Contone, pod sing njaluk 2 GiB memori nanging mung nggunakake 200 MiB duwe ~1,8 GiB memori "keluwihan". Keluwihan biaya dhuwit. Siji kira-kira bisa ngira yen 1 GiB memori keluwih biaya ~ $10 saben wulan. [2]

Laporan Sumber Daya Kubernetes (kube-resource-report) nampilake keluwihan cadangan lan bisa mbantu nemtokake potensial tabungan:

Laporan Sumber Daya Kubernetes nuduhake keluwihan dikumpulake dening aplikasi lan printah. Iki ngidini sampeyan nemokake panggonan ing ngendi panjaluk sumber daya bisa dikurangi. Laporan HTML sing digawe mung nyedhiyakake snapshot babagan panggunaan sumber daya. Sampeyan kudu ndeleng panggunaan CPU / memori liwat wektu kanggo nemtokake panjalukan sumber daya sing nyukupi. Mangkene grafik Grafana kanggo layanan "khas" CPU sing abot: kabeh pod nggunakake kurang saka 3 intine CPU sing dijaluk:

Ngurangi panjalukan CPU saka 3000m dadi ~ 400m mbebasake sumber daya kanggo beban kerja liyane lan ngidini kluster dadi luwih cilik.

"Panganggone CPU rata-rata saka instans EC2 asring ana ing kisaran persentase siji-digit," nyerat Corey Quinn. Nalika kanggo EC2 ngira ukuran sing tepat bisa dadi keputusan sing alaNgganti sawetara pitakon sumber daya Kubernetes ing file YAML gampang lan bisa ngirit banget.

Nanging apa kita pengin wong ngganti nilai ing file YAML? Ora, mesin bisa nindakake luwih apik! Kubernetes Vertikal Pod Autoscaler (VPA) nindakake mung: nyesuekake panjalukan lan kendala sumber daya miturut beban kerja. Iki minangka conto grafik panjalukan CPU Prometheus (garis biru tipis) sing diadaptasi dening VPA saka wektu:

Zalando nggunakake VPA ing kabeh klompok kanggo komponen infrastruktur. Aplikasi non-kritis uga bisa nggunakake VPA.

goldilocks saka Fairwind minangka alat sing nggawe VPA kanggo saben panyebaran ing ruang jeneng banjur nampilake rekomendasi VPA ing dashboard. Bisa mbantu pangembang nyetel panjalukan CPU/memori sing bener kanggo aplikasi:

Aku nulis cilik blogpost babagan VPA ing 2019, lan bubar ing CNCF End User Community ngrembug masalah VPA.

Nggunakake EC2 Spot Instances

Paling ora, biaya AWS EC2 bisa dikurangi kanthi nggunakake instance Spot minangka node pekerja Kubernetes [3]. Instance spot kasedhiya kanthi diskon nganti 90% dibandhingake karo rega On-Demand. Mlaku Kubernetes ing EC2 Spot minangka kombinasi sing apik: sampeyan kudu nemtokake sawetara jinis conto sing beda kanggo kasedhiyan sing luwih dhuwur, tegese sampeyan bisa entuk simpul sing luwih gedhe kanthi rega sing padha utawa luwih murah, lan kapasitas sing tambah bisa digunakake dening beban kerja Kubernetes sing dikontainer.

Kepiye cara mbukak Kubernetes ing EC2 Spot? Ana sawetara opsi: gunakake layanan pihak katelu kaya SpotInst (saiki diarani "Spot", aja takon apa sebabe), utawa mung nambah Spot AutoScalingGroup (ASG) menyang kluster sampeyan. Contone, iki cuplikan CloudFormation kanggo Spot ASG sing "dioptimalake kapasitas" kanthi macem-macem jinis conto:

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"

Sawetara cathetan babagan nggunakake Spot karo Kubernetes:

Sampeyan kudu nangani terminasi Spot, contone kanthi nggabungake simpul nalika instance mandheg
Zalando migunakake garpu autoscaling kluster resmi kanthi prioritas blumbang simpul
Titik titik bisa dipeksa nampa "registrasi" saka workloads kanggo mbukak ing Spot

Ringkesan

Muga-muga sampeyan nemokake sawetara alat sing kasedhiya kanggo nyuda tagihan awan. Sampeyan bisa nemokake umume isi artikel uga ing omonganku ing DevOps Gathering 2019 ing YouTube lan ing slide.

Apa praktik paling apik kanggo ngirit biaya awan ing Kubernetes? Mangga mugi kula ngerti ing Twitter (@try_except_).

[1] Nyatane, kurang saka 3 vCPU bakal tetep bisa digunakake minangka throughput simpul suda dening sumber daya sistem reserved. Kubernetes mbedakake antarane kapasitas simpul fisik lan sumber daya "disediakake" (Node dialokasikan).

[2] Conto pitungan: siji m5.large Kayata karo 8 GiB memori punika ~$84 saben sasi (eu-central-1, On-Demand), i.e. mblokir 1/8 simpul kira-kira ~ $ 10 / sasi.

[3] Ana akeh cara liyane kanggo nyuda tagihan EC2, kayata Instans Reserved, Rencana Tabungan, lan sapiturute - Aku ora bakal nutupi topik kasebut ing kene, nanging sampeyan kudu mriksa!

Sinau luwih lengkap babagan kursus kasebut.

Source: www.habr.com

Ngirit biaya awan Kubernetes ing AWS