Нийтлэлийн орчуулгыг курс эхлэхийн өмнөх өдөр бэлтгэсэн .
Kubernetes-тэй ажиллахдаа үүлний зардлыг хэрхэн хэмнэх вэ? Ганц зөв шийдэл байхгүй ч энэ нийтлэлд нөөцөө илүү үр дүнтэй удирдах, үүлэн тооцооллын зардлыг бууруулахад туслах хэд хэдэн хэрэгслийг тайлбарласан болно.
Би энэ нийтлэлийг Kubernetes for AWS-д зориулж бичсэн боловч энэ нь бусад үүл үйлчилгээ үзүүлэгчдэд яг адилхан (бараг) хэрэгжих болно. Таны кластер(ууд) аль хэдийн автомат масштабаар тохируулагдсан байна гэж би бодож байна (). Нөөцийг устгаж, байршуулалтыг багасгах нь таны ажилчдын зангилааны флотыг (EC2 тохиолдлууд) багасгах тохиолдолд л мөнгө хэмнэх болно.
Энэ нийтлэлд:
- ашиглагдаагүй нөөцийг цэвэрлэх ()
- Ажлын бус цагаар масштабыг багасгах ()
- хэвтээ автомат масштабыг ашиглах (HPA),
- хэт их нөөцийн нөөцийг бууруулах (, VPA)
- Spot тохиолдлуудыг ашиглах
Ашиглагдаагүй нөөцийг цэвэрлэх
Хурдан хэмнэлтэй орчинд ажиллах нь гайхалтай. Бид технологийн байгууллагуудыг хүсч байна . Програм хангамжийг хурдан хүргэх нь илүү олон PR байршуулалт, урьдчилан харах орчин, прототип, аналитик шийдлүүд гэсэн үг юм. Бүх зүйлийг Kubernetes дээр байрлуулсан. Туршилтын байршуулалтыг гараар цэвэрлэх цаг хэнд байна вэ? Долоо хоногийн турш хийсэн туршилтыг устгах тухай мартах нь амархан. Бидний хаахаа мартсан зүйлээс болж үүлний төлбөр нэмэгдэх болно:
(Хеннинг Жейкобс:
Жиза:
(ишлэл) Кори Куинн:
Төөрөгдөл: Таны AWS акаунт нь таны хэрэглэгчдийн тооноос хамаардаг.
Баримт: Таны AWS оноо нь танд байгаа инженерүүдийн тооноос хамаарна.
Иван Курносов (хариултаар):
Бодит баримт: Таны AWS оноо нь таны идэвхгүй болгох/устгахаа мартсан зүйлсийн тооны функц юм.)
(kube-janitor) таны кластерыг цэвэрлэхэд тусалдаг. Цэвэрлэгчийн тохиргоо нь дэлхийн болон орон нутгийн хэрэглээнд уян хатан байдаг:
- Кластер даяарх дүрмүүд нь PR/туршилтын ашиглалтын хамгийн дээд хугацааг (TTL) тодорхойлж болно.
- Хувь хүний нөөцийг janitor/ttl-ээр тэмдэглэж болно, жишээ нь 7 хоногийн дараа спик/прототипийг автоматаар устгах боломжтой.
Ерөнхий дүрмийг YAML файлд тодорхойлсон. Түүний зам нь параметрээр дамждаг --rules-file kube-саажинд. Энд бүх нэрийн зайг арилгах жишээ дүрм байна -pr- хоёр өдрийн дараа нэр дээр:
- id: cleanup-resources-from-pull-requests
resources:
- namespaces
jmespath: "contains(metadata.name, '-pr-')"
ttl: 2dДараах жишээ нь 2020 оны бүх шинэ Deployment/StatefulSet-д Deployment болон StatefulSet pods дээрх програмын шошгыг ашиглахыг зохицуулсан боловч үүнтэй зэрэгцэн долоо хоногийн турш энэ шошгогүйгээр туршилтыг гүйцэтгэхийг зөвшөөрдөг:
- 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 ажиллуулж буй кластер дээр 30 минутын турш хязгаарлагдмал хугацаатай демо ажиллуулна уу:
kubectl run nginx-demo --image=nginx
kubectl annotate deploy nginx-demo janitor/ttl=30mЗардлыг нэмэгдүүлэх өөр нэг эх үүсвэр бол байнгын хэмжээ (AWS EBS) юм. Kubernetes StatefulSet-г устгах нь түүний байнгын эзлэхүүнийг (PVC - PersistentVolumeClaim) устгахгүй. Ашиглагдаагүй EBS хэмжээ нь сард хэдэн зуун долларын зардал гаргахад хялбар байдаг. Kubernetes Janitor нь ашиглагдаагүй PVC-ийг цэвэрлэх онцлогтой. Жишээлбэл, энэ дүрэм нь модульд суурилуулагдаагүй, StatefulSet эсвэл CronJob-д иш татаагүй бүх PVC-ийг устгах болно:
# удалить все PVC, которые не смонтированы и на которые не ссылаются StatefulSets
- id: remove-unused-pvcs
resources:
- persistentvolumeclaims
jmespath: "_context.pvc_is_not_mounted && _context.pvc_is_not_referenced"
ttl: 24hKubernetes Janitor нь кластераа цэвэр байлгахад тусалж, үүлэн тооцооллын зардал аажмаар нэмэгдэхээс сэргийлж чадна. Байршуулах болон тохируулах зааврыг дагана уу .
Ажлын бус цагаар масштабыг багасгах
Туршилтын болон үе шатны систем нь ихэвчлэн зөвхөн ажлын цагаар ажиллах шаардлагатай байдаг. Зарим үйлдвэрлэлийн програмууд, тухайлбал арын алба/админ хэрэгсэл нь зөвхөн хязгаарлагдмал хүртээмжтэй байхыг шаарддаг бөгөөд нэг шөнийн дотор идэвхгүй болно.
(kube-downscaler) нь хэрэглэгчид болон операторуудад ажлын бус цагаар системийн хэмжээг багасгах боломжийг олгодог. Байрлуулалт болон StatefulSets нь хуулбарыг тэг болгож масштаблах боломжтой. CronJobs-ыг түдгэлзүүлж магадгүй. Kubernetes Downscaler нь бүхэл бүтэн кластер, нэг буюу хэд хэдэн нэрийн орон зай эсвэл бие даасан нөөцөд зориулж тохируулагдсан. Та "сул зогсолт" эсвэл эсрэгээр "ажлын цаг"-ыг тохируулж болно. Жишээлбэл, шөнийн болон амралтын өдрүүдэд масштабыг аль болох багасгахын тулд:
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Амралтын өдрүүдэд кластерын ажилчдын зангилааг масштаблах график энд байна:
~13-аас 4 ажилчны зангилааг багасгах нь таны AWS тооцоонд мэдэгдэхүйц өөрчлөлт авчрах нь дамжиггүй.
Гэхдээ би кластерын "сул зогсолт" үед ажиллах шаардлагатай бол яах вэ? Хэмжээг багасгах/хасах: үнэн тайлбарыг нэмснээр тодорхой байршуулалтыг масштабаас бүрмөсөн хасч болно. YYYY-MM-DD HH:MM (UTC) форматтай үнэмлэхүй цагийн тэмдэг бүхий бууруулагч/хасах-хүртэл тайлбарыг ашиглан байршуулалтыг түр хасаж болно. Шаардлагатай бол тайлбар бүхий pod байрлуулснаар кластерыг бүхэлд нь багасгаж болно downscaler/force-uptimeЖишээ нь, 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Үзнэ үү , хэрэв та байршуулах заавар болон нэмэлт сонголтуудыг сонирхож байгаа бол.
Хэвтээ автомат масштабыг ашиглана уу
Олон програмууд/үйлчилгээнүүд нь динамик ачааллын загвартай ажилладаг: заримдаа тэдний модулиуд идэвхгүй, заримдаа бүрэн хүчин чадлаараа ажилладаг. Хамгийн их ачааллыг даван туулахын тулд байнгын флотыг ажиллуулах нь хэмнэлттэй биш юм. Kubernetes нь нөөцийн хэмжээнд хэвтээ автомат масштабыг дэмждэг (HPA). CPU-ийн хэрэглээ нь ихэвчлэн масштабыг нэмэгдүүлэх сайн үзүүлэлт болдог:
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Заландо нь хувийн хэмжүүрүүдийг хялбархан холбох бүрэлдэхүүн хэсгийг бүтээжээ. (kube-metrics-adapter) нь Kubernetes-д зориулсан ерөнхий хэмжүүрийн адаптер бөгөөд pods-ыг хэвтээ автоматаар масштаблахад зориулсан захиалгат болон гадаад хэмжигдэхүүнүүдийг цуглуулж, үйлчлэх боломжтой. Энэ нь Prometheus хэмжигдэхүүн, SQS дараалал болон бусад тохиргоонд суурилсан масштабыг дэмждэг. Жишээ нь, /хэмжээнд JSON хэлбэрээр хэрэглүүрээр илэрхийлэгдэх захиалгат хэмжигдэхүүн болгон байршуулалтаа масштаблахын тулд:
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 ашиглан хэвтээ автомат масштабыг тохируулах нь харьяалалгүй үйлчилгээний үр ашгийг дээшлүүлэх үндсэн үйлдлүүдийн нэг байх ёстой. Spotify нь HPA-д зориулсан туршлага, зөвлөмжийг агуулсан танилцуулгатай: .
Нөөцийн хэт их захиалгыг багасгах
Kubernetes-ийн ажлын ачаалал нь CPU/санах ойн хэрэгцээгээ "нөөцийн хүсэлт"-ээр тодорхойлдог. CPU-ийн нөөцийг виртуал цөмөөр эсвэл ихэвчлэн "милликороор" хэмждэг, жишээлбэл 500м нь 50% vCPU гэсэн үг. Санах ойн нөөцийг байтаар хэмждэг бөгөөд 500Mi гэх мэт нийтлэг дагаваруудыг ашиглаж болно, энэ нь 500 мегабайт гэсэн үг. Нөөцийн хүсэлтийг ажилчдын зангилаанууд дээр "түгжих" хүчин чадалтай, өөрөөр хэлбэл 1000 vCPU-тай зангилаа дээрх 4м CPU-ийн хүсэлт бүхий pod нь бусад pod-д зөвхөн 3 vCPU ашиглах боломжтой болно.
Сул (илүүдэл нөөц) нь хүссэн нөөц ба бодит ашиглалтын хоорондох ялгаа юм. Жишээлбэл, 2 ГБ санах ой шаарддаг боловч зөвхөн 200 МБ ашигладаг pod нь ~1,8 ГБ "илүүдэл" санах ойтой байдаг. Илүүдэл нь мөнгө шаарддаг. Ойролцоогоор 1 гиб нэмэлт санах ой нь сард ~ 10 долларын үнэтэй гэж тооцоолж болно.
(kube-resource-report) нь илүүдэл нөөцийг харуулдаг бөгөөд танд хадгаламжийн боломжуудыг тодорхойлоход тусална:
програм болон тушаалаар нэгтгэсэн илүүдлийг харуулна. Энэ нь нөөцийн эрэлтийг бууруулах боломжтой газруудыг олох боломжийг танд олгоно. Үүсгэсэн HTML тайлан нь зөвхөн нөөц ашиглалтын агшин зуурын агшинг өгдөг. Та хангалттай нөөцийн хүсэлтийг тодорхойлохын тулд CPU/санах ойн ашиглалтыг цаг хугацааны явцад харах хэрэгтэй. "Ердийн" CPU ачаалал ихтэй үйлчилгээний Графана диаграмыг энд үзүүлэв: бүх pods нь хүссэн 3 CPU цөмөөс хамаагүй бага ашиглаж байна:
CPU-ийн хүсэлтийг 3000м-ээс ~400м болгон бууруулснаар бусад ажлын ачааллын нөөцийг чөлөөлж, кластерыг жижиг болгох боломжийг олгодог.
"EC2 инстансуудын CPU-ийн дундаж хэрэглээ нь ихэвчлэн нэг оронтой тооны хувийн мужид шилждэг." . EC2-ийн хувьд YAML файл дахь Kubernetes нөөцийн зарим асуулгыг өөрчлөх нь хялбар бөгөөд асар их хэмнэлт авчрах болно.
Гэхдээ бид хүмүүсийг YAML файл дахь утгыг өөрчлөхийг үнэхээр хүсч байна уу? Үгүй ээ, машинууд үүнийг илүү сайн хийж чадна! Кубернетес (VPA) яг үүнийг хийдэг: ажлын ачааллын дагуу нөөцийн хүсэлт, хязгаарлалтыг тохируулдаг. Цаг хугацааны явцад VPA-ийн тохируулсан Prometheus CPU-ийн хүсэлтийн жишээ график (нимгэн цэнхэр шугам) энд байна:
дэд бүтцийн бүрэлдэхүүн хэсгүүдийн хувьд. Чухал бус програмууд нь VPA ашиглах боломжтой.
Fairwind нь нэрийн талбарт байршуулалт бүрт VPA үүсгэж, дараа нь хяналтын самбар дээрээ VPA зөвлөмжийг харуулдаг хэрэгсэл юм. Энэ нь хөгжүүлэгчдэд өөрсдийн програмын CPU/санах ойн хүсэлтийг зөв тохируулахад тусална.
Би жижиг бичсэн 2019 онд, саяхан .
EC2 Spot Instances ашиглах
Эцэст нь хэлэхэд, Spot instance-ийг Kubernetes-ийн ажилчны зангилаа болгон ашигласнаар AWS EC2-ийн зардлыг бууруулж болно. . Спот инстансуудыг эрэлт хэрэгцээний үнээс 90% хүртэл хямдралтай үнээр авах боломжтой. EC2 Spot дээр Kubernetes-ийг ажиллуулах нь маш сайн хослол юм: илүү их хүртээмжтэй байхын тулд та хэд хэдэн өөр төрлийн жишээг зааж өгөх хэрэгтэй, өөрөөр хэлбэл та ижил эсвэл хямд үнээр илүү том зангилаа авах боломжтой бөгөөд нэмэгдсэн хүчин чадлыг Кубернетын ажлын ачаалалд ашиглах боломжтой.
EC2 Spot дээр Kubernetes-ийг хэрхэн ажиллуулах вэ? Хэд хэдэн сонголт бий: SpotInst гэх мэт гуравдагч талын үйлчилгээг ашиглах (одоо "Spot" гэж нэрлэдэг, яагаад гэдгийг надаас бүү асуу) эсвэл зүгээр л өөрийн кластерт Spot AutoScalingGroup (ASG) нэмнэ үү. Жишээлбэл, энд олон төрлийн инстанц бүхий "чадавхийг оновчтой болгосон" Spot ASG-д зориулсан CloudFormation-ийн хэсэг байна:
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-тэй ашиглах талаархи зарим тэмдэглэл:
- Жишээ нь зогссон үед зангилааг нэгтгэх гэх мэт Spot төгсгөлийг зохицуулах хэрэгтэй
- Заландо ашигладаг зангилааны сангийн тэргүүлэх чиглэл бүхий албан ёсны кластерын автомат масштаблалт
- Толбо зангилаа Spot дээр ажиллуулах ажлын ачааллын "бүртгэл"-ийг хүлээн авна уу
Хураангуй
Үзүүлсэн зарим хэрэглүүрийг үүлэн төлбөрөө бууруулахад тань хэрэг болно гэж найдаж байна. Та мөн нийтлэлийн ихэнх агуулгыг эндээс олж болно .
Kubernetes дээр үүлэн зардлыг хэмнэх хамгийн сайн туршлага юу вэ? хаягаар мэдэгдэнэ үү .
Үнэн хэрэгтээ 3-аас бага vCPU ашиглах боломжтой хэвээр байх болно, учир нь зангилааны нэвтрүүлэх чадвар нь нөөцлөгдсөн системийн нөөцөөр багасдаг. Кубернетес физик зангилааны хүчин чадал болон "болгосон" нөөцийг ялгадаг ().
Тооцооллын жишээ: 5 ГБ санах ойтой нэг m8.large жишээ нь сард ~84$ (eu-central-1, On-Demand), i.e. 1/8 зангилаа хаах нь ойролцоогоор ~$10/сар юм.
Нөөцлөгдсөн тохиолдлууд, Хадгаламжийн төлөвлөгөө гэх мэт EC2 төлбөрөө бууруулах өөр олон арга бий. - Би энд эдгээр сэдвүүдийг хөндөхгүй, гэхдээ та заавал судалж үзэх хэрэгтэй!
Эх сурвалж: www.habr.com