Maqolaning tarjimasi kurs boshlanishi arafasida tayyorlangan .
Kubernetes bilan ishlashda bulutli xarajatlarni qanday tejash mumkin? Yagona toʻgʻri yechim yoʻq, ammo bu maqolada resurslaringizni samaraliroq boshqarish va bulutli hisoblash xarajatlarini kamaytirishga yordam beradigan bir nechta vositalar tasvirlangan.
Men ushbu maqolani AWS uchun Kubernetes bilan yozganman, lekin u (deyarli) boshqa bulut provayderlariga ham xuddi shunday qo'llaniladi. Men sizning klaster(lar)ingizda allaqachon avtomatik o'lchov konfiguratsiya qilingan deb o'ylayman (). Resurslarni olib tashlash va joylashtirishni kichraytirish, agar u ishchi tugunlari parkini (EC2 misollari) kamaytirsagina, pulni tejaydi.
Ushbu maqola quyidagilarni qamrab oladi:
- foydalanilmagan resurslarni tozalash ()
- Ishlamaydigan vaqtlarda masshtabni kamaytiring ()
- Gorizontal autoscaling (HPA) yordamida
- ortiqcha resurs zaxirasini kamaytirish (, VPA)
- Spot misollaridan foydalanish
Foydalanilmayotgan resurslarni tozalash
Tez sur'atda ishlaydigan muhitda ishlash juda yaxshi. Biz texnologik tashkilotlarni xohlaymiz . Tezroq dasturiy ta'minot yetkazib berish ko'proq PR tarqatish, oldindan ko'rish muhitlari, prototiplar va tahliliy echimlarni anglatadi. Hamma narsa Kubernetes-da joylashtirilgan. Sinov o'rnatishni qo'lda tozalash uchun kimning vaqti bor? Bir haftalik tajribani o'chirishni unutish oson. Bulutli hisob biz yopishni unutganimiz sababli ko'tariladi:
(Henning Jeykobs:
Jiza:
(iqtibos) Kori Quinn:
Mif: Sizning AWS hisob qaydnomangiz siz ega bo'lgan foydalanuvchilar soniga bog'liq.
Fakt: Sizning AWS ballingiz siz ega bo'lgan muhandislar soniga bog'liq.
Ivan Kurnosov (javobda):
Haqiqiy fakt: Sizning AWS ballingiz siz o'chirishni/o'chirishni unutgan narsalar soniga bog'liq.)
(kube-janitor) sizning klasteringizni tozalashga yordam beradi. Janitor konfiguratsiyasi global va mahalliy foydalanish uchun moslashuvchan:
- Klaster miqyosidagi qoidalar PR/sinovni joylashtirish uchun maksimal ishlash vaqtini (TTL) belgilashi mumkin.
- Individual resurslarga janitor/ttl bilan izoh berish mumkin, masalan, 7 kundan keyin spike/prototipni avtomatik ravishda olib tashlash uchun.
Umumiy qoidalar YAML faylida belgilangan. Uning yo'li parametr orqali o'tadi --rules-file kube farroshda. Bu erda barcha nom bo'shliqlarini olib tashlash uchun misol qoidasi mavjud -pr- ikki kundan keyin nomiga:
- id: cleanup-resources-from-pull-requests
resources:
- namespaces
jmespath: "contains(metadata.name, '-pr-')"
ttl: 2dQuyidagi misol 2020-yildagi barcha yangi Deployments/StatefulSets uchun Deployment va StatefulSet podslarida ilova yorlig‘idan foydalanishni tartibga soladi, lekin shu bilan birga bir hafta davomida ushbu yorliqsiz testlarni bajarishga imkon beradi:
- 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: 7dKube-janitor bilan ishlaydigan klasterda 30 daqiqa vaqt cheklangan demo-ni ishga tushiring:
kubectl run nginx-demo --image=nginx
kubectl annotate deploy nginx-demo janitor/ttl=30mXarajatlarni oshirishning yana bir manbai - doimiy hajmlar (AWS EBS). Kubernetes StatefulSet-ni o'chirish uning doimiy jildlarini o'chirib tashlamaydi (PVC - PersistentVolumeClaim). Ishlatilmagan EBS hajmlari osongina oyiga yuzlab dollar xarajatlarga olib kelishi mumkin. Kubernetes Janitor ishlatilmagan PVXlarni tozalash xususiyatiga ega. Masalan, ushbu qoida modul tomonidan o'rnatilmagan va StatefulSet yoki CronJob tomonidan havola qilinmagan barcha PVXlarni olib tashlaydi:
# удалить все PVC, которые не смонтированы и на которые не ссылаются StatefulSets
- id: remove-unused-pvcs
resources:
- persistentvolumeclaims
jmespath: "_context.pvc_is_not_mounted && _context.pvc_is_not_referenced"
ttl: 24hKubernetes Janitor klasteringizni toza saqlashga yordam beradi va bulutli hisoblash xarajatlari asta-sekin oshib ketishining oldini oladi. O'rnatish va sozlash bo'yicha ko'rsatmalarga amal qiling .
Ishlamaydigan vaqtlarda masshtabni kamaytiring
Sinov va bosqichma-bosqich tizimlar odatda faqat ish soatlarida ishlash uchun talab qilinadi. Ba'zi ishlab chiqarish ilovalari, masalan, orqa ofis/administrator vositalari, faqat cheklangan mavjudligini talab qiladi va bir kechada o'chirib qo'yilishi mumkin.
(kube-downscaler) foydalanuvchilar va operatorlarga ishlamaydigan vaqtlarda tizimni kichraytirish imkonini beradi. Joylashtirishlar va StatefulSets nol replikagacha o'lchamlari mumkin. CronJobs to'xtatilishi mumkin. Kubernetes Downscaler butun klaster, bir yoki bir nechta nom maydoni yoki alohida resurslar uchun sozlangan. Siz "bo'sh vaqt" yoki aksincha, "ish vaqti" ni belgilashingiz mumkin. Masalan, tunda va dam olish kunlarida o'lchovni imkon qadar kamaytirish uchun:
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-timeDam olish kunlarida klaster ishchilari tugunlarini masshtablash uchun grafik:
~13 dan 4 ishchi tugungacha qisqartirish, albatta, AWS hisobingizda sezilarli farq qiladi.
Ammo klasterning "to'xtash vaqti" vaqtida ishlashim kerak bo'lsa-chi? Ba'zi o'rnatishlarni o'lchovni pasaytirish/chiqib chiqarish: haqiqiy izoh qo'shish orqali butunlay chiqarib tashlash mumkin. O'rnatishlarni vaqtinchalik YYYY-AA-KK SS:MM (UTC) formatidagi mutlaq vaqt tamg'asi bilan pastga tushiruvchi/cheklash-annotatsiya yordamida chiqarib tashlash mumkin. Agar kerak bo'lsa, izohli podni o'rnatish orqali butun klasterni qisqartirish mumkin downscaler/force-uptime, masalan, nginx blankini ishga tushirish orqali:
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=trueQarang , agar siz joylashtirish bo'yicha ko'rsatmalar va qo'shimcha imkoniyatlarga qiziqsangiz.
Gorizontal avtomatik o'lchovdan foydalaning
Ko'pgina ilovalar/xizmatlar dinamik yuklash sxemasi bilan shug'ullanadi: ba'zida ularning modullari bo'sh, ba'zan esa to'liq quvvat bilan ishlaydi. Maksimal cho'qqi yukini engish uchun doimiy podalar parkini ishlatish tejamkor emas. Kubernetes resurs bo'ylab gorizontal avtomatik masshtablashni qo'llab-quvvatlaydi (HPA). Protsessordan foydalanish ko'pincha masshtablash uchun yaxshi ko'rsatkichdir:
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 masshtablash uchun maxsus ko'rsatkichlarni osongina ulash uchun komponent yaratdi: (kube-metrics-adapter) - bu Kubernetes uchun umumiy ko'rsatkichlar adapteri bo'lib, podkastlarni gorizontal avtoshkalalash uchun maxsus va tashqi ko'rsatkichlarni to'plashi va ularga xizmat ko'rsatishi mumkin. U Prometey ko'rsatkichlari, SQS navbatlari va boshqa sozlamalar asosida masshtablashni qo'llab-quvvatlaydi. Masalan, oʻrnatishingizni /metrics ichida JSON sifatida ilovaning oʻzi tomonidan taqdim etilgan maxsus koʻrsatkichga oʻlchash uchun:
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: AverageValueHPA bilan gorizontal avtomatik o'lchovni sozlash fuqaroligi bo'lmagan xizmatlar samaradorligini oshirish uchun standart harakatlardan biri bo'lishi kerak. Spotify o'z tajribasi va HPA bo'yicha tavsiyalari bilan taqdimotga ega: .
Resurslarni ortiqcha bron qilishni kamaytiring
Kubernetes ish yuklari ularning CPU/xotira ehtiyojlarini "resurs so'rovlari" orqali aniqlaydi. CPU resurslari virtual yadrolarda yoki odatda "millicores" da o'lchanadi, masalan, 500m 50% vCPUni nazarda tutadi. Xotira resurslari baytlarda o'lchanadi va umumiy qo'shimchalardan foydalanish mumkin, masalan, 500Mi, ya'ni 500 megabayt. Resurs so‘rovlari ishchi tugunlarida “qulflash” sig‘imi, ya’ni 1000 vCPUli tugundagi 4 m protsessor so‘rovi bo‘lgan podkast boshqa protsessorlar uchun faqat 3 ta vCPUni qoldiradi.
Sustlik (ortiqcha zaxira) so'ralgan resurslar va haqiqiy foydalanish o'rtasidagi farq. Masalan, 2 GiB xotira talab qiladigan, lekin faqat 200 Mb ishlatadigan podkastda ~1,8 Gb “ortiqcha” xotira mavjud. Ortiqcha pul sarflanadi. Taxminan taxmin qilish mumkinki, 1 Gb ortiqcha xotira oyiga ~ 10 dollar turadi.
(kube-resource-report) ortiqcha zaxiralarni ko'rsatadi va tejash potentsialini aniqlashga yordam beradi:
ilova va buyruq bo'yicha yig'ilgan ortiqcha miqdorni ko'rsatadi. Bu sizga resurslarga bo'lgan talabni kamaytirish mumkin bo'lgan joylarni topishga imkon beradi. Yaratilgan HTML hisoboti faqat resurslardan foydalanishning oniy tasvirini beradi. Kerakli resurs so'rovlarini aniqlash uchun vaqt o'tishi bilan CPU/xotiradan foydalanishni ko'rib chiqishingiz kerak. Bu erda "odatiy" protsessorli xizmat uchun Grafana diagrammasi: barcha podlar so'ralgan 3 ta CPU yadrosidan sezilarli darajada kamroq foydalanadi:
CPU so'rovini 3000 m dan ~ 400 m gacha qisqartirish boshqa ish yuklari uchun resurslarni bo'shatadi va klasterni kichikroq qilish imkonini beradi.
"EC2 nusxalarining o'rtacha protsessoridan foydalanish ko'pincha bir raqamli foiz oralig'ida o'zgaradi", . EC2 uchun esa YAML faylidagi ba'zi Kubernetes resurs so'rovlarini o'zgartirish oson va katta tejashga olib kelishi mumkin.
Ammo biz haqiqatan ham odamlar YAML fayllaridagi qiymatlarni o'zgartirishini xohlaymizmi? Yo'q, mashinalar buni ancha yaxshi qila oladi! Kubernetes (VPA) aynan shunday qiladi: resurs so'rovlari va cheklovlarni ish yukiga qarab moslashtiradi. Vaqt o'tishi bilan VPA tomonidan moslashtirilgan Prometey CPU so'rovlarining (nozik ko'k chiziq) misol grafigi:
infratuzilma komponentlari uchun. Muhim bo'lmagan ilovalar ham VPA dan foydalanishi mumkin.
from Fairwind - bu nomlar maydonida har bir joylashtirish uchun VPA yaratadigan va keyin uning asboblar panelida VPA tavsiyasini ko'rsatadigan vosita. Bu ishlab chiquvchilarga o'z ilovalari uchun to'g'ri CPU/xotira so'rovlarini o'rnatishda yordam berishi mumkin:
Men kichik yozdim 2019 yilda va yaqinda .
EC2 Spot misollaridan foydalanish
Va nihoyat, AWS EC2 xarajatlarini Kubernetes ishchi tugunlari sifatida Spot misollaridan foydalanish orqali kamaytirish mumkin. . Spot nusxalari Talab bo'yicha narxlarga nisbatan 90% gacha chegirmada mavjud. EC2 Spot-da Kubernetes-ni ishga tushirish yaxshi kombinatsiyadir: yuqoriroq mavjudlik uchun siz bir nechta turli misol turlarini belgilashingiz kerak, ya'ni siz bir xil yoki arzonroq narxga kattaroq tugunni olishingiz mumkin va oshirilgan sig'imdan konteynerlangan Kubernetes ish yuklari foydalanishi mumkin.
Kubernetes-ni EC2 Spot-da qanday ishlatish mumkin? Bir nechta variant mavjud: SpotInst kabi uchinchi tomon xizmatidan foydalaning (hozir "Spot" deb ataladi, nima uchun mendan so'ramang) yoki shunchaki klasteringizga Spot AutoScalingGroup (ASG) qo'shing. Misol uchun, bu yerda bir nechta misol turlariga ega "sig'imlarga optimallashtirilgan" Spot ASG uchun CloudFormation parchasi:
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"Kubernetes bilan Spot-dan foydalanish bo'yicha ba'zi eslatmalar:
- Spot tugatish bilan ishlashingiz kerak, masalan, misol to'xtatilganda tugunni birlashtirish orqali
- Zalando foydalanadi tugunlar havzasi ustuvorliklari bilan rasmiy klasterni avtomatik o'lchash
- Spot tugunlari Spotda ishlash uchun ish yuklarining "ro'yxatga olishlarini" qabul qiling
Xulosa
Umid qilamanki, sizga taqdim etilgan ba'zi vositalar bulutli hisobingizni kamaytirishda foydali bo'ladi. Maqola mazmunining ko'p qismini quyidagi manzilda ham topishingiz mumkin .
Kubernetes-da bulutli xarajatlarni tejash bo'yicha eng yaxshi amaliyotlaringiz qanday? Iltimos, menga xabar bering .
Aslida, 3 tadan kam vCPU foydalanish mumkin bo'lib qoladi, chunki tugunning o'tkazuvchanligi zaxiralangan tizim resurslari tufayli kamayadi. Kubernetes jismoniy tugun sig'imi va "ta'minlangan" resurslarni farqlaydi ().
Hisoblash misoli: 5 GiB xotiraga ega bitta m8.large nusxasi oyiga ~ $84 (eu-central-1, On-Demand), yaʼni. 1/8 tugunni blokirovka qilish oyiga taxminan ~ $10 ni tashkil qiladi.
EC2 hisobingizni kamaytirishning yana koʻplab usullari mavjud, masalan, Zaxiralangan nusxalar, Savings Plan va boshqalar. – Men bu mavzularni bu yerda yoritmayman, lekin siz ularni albatta koʻrib chiqishingiz kerak!
Manba: www.habr.com