ປະຫຍັດຄ່າໃຊ້ຈ່າຍ Kubernetes cloud ໃນ AWS

ການ​ແປ​ພາ​ສາ​ຂອງ​ບົດ​ຄວາມ​ໄດ້​ຖືກ​ກະ​ກຽມ​ໃນ​ສະ​ມາດ​ສະ​ມາດ​ຂອງ​ການ​ເລີ່ມ​ຕົ້ນ​ຂອງ​ວິ​ຊາ​ການ "ເວທີພື້ນຖານໂຄງລ່າງທີ່ອີງໃສ່ Kubernetes".

ວິທີການປະຫຍັດຄ່າໃຊ້ຈ່າຍໃນຄລາວໃນເວລາທີ່ເຮັດວຽກກັບ Kubernetes? ບໍ່ມີການແກ້ໄຂທີ່ຖືກຕ້ອງດຽວ, ແຕ່ບົດຄວາມນີ້ອະທິບາຍເຄື່ອງມືຈໍານວນຫນຶ່ງທີ່ສາມາດຊ່ວຍໃຫ້ທ່ານຄຸ້ມຄອງຊັບພະຍາກອນຂອງທ່ານຢ່າງມີປະສິດທິພາບແລະຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍໃນຄອມພິວເຕີ້ຟັງຂອງທ່ານ.

ຂ້ອຍຂຽນບົດຄວາມນີ້ກັບ Kubernetes ສໍາລັບ AWS ໃນໃຈ, ແຕ່ມັນຈະນໍາໃຊ້ (ເກືອບ) ຄືກັນກັບຜູ້ໃຫ້ບໍລິການຟັງອື່ນໆ. ຂ້ອຍສົມມຸດວ່າກຸ່ມຂອງເຈົ້າໄດ້ມີການປັບຂະໜາດອັດຕະໂນມັດແລ້ວ (cluster-autoscaler). ການເອົາຊັບພະຍາກອນອອກ ແລະປັບຂະໜາດການໃຊ້ງານຂອງເຈົ້າຈະປະຢັດເງິນໄດ້ເທົ່ານັ້ນ ຖ້າມັນຍັງຫຼຸດການສົ່ງຄົນງານຂອງເຈົ້າ (ຕົວຢ່າງ EC2).

ບົດຄວາມນີ້ຈະກວມເອົາ:

• ທໍາ​ຄວາມ​ສະ​ອາດ​ຊັບ​ພະ​ຍາ​ກອນ​ທີ່​ບໍ່​ໄດ້​ນໍາ​ໃຊ້ (kube-janitor)
• ຫຼຸດການປັບຂະໜາດໃນເວລາບໍ່ເຮັດວຽກ (kube-downscaler)
• ການ​ນໍາ​ໃຊ້​ການ​ປັບ​ຂະ​ຫນາດ​ອັດ​ຕະ​ໂນ​ມັດ​ຕາມ​ລວງ​ນອນ (HPA​)​,
• ການຫຼຸດຜ່ອນການຈອງຊັບພະຍາກອນຫຼາຍເກີນໄປ (kube-resource-report, VPA)
• ການ​ນໍາ​ໃຊ້ Spot ຕົວ​ຢ່າງ​

ເຮັດຄວາມສະອາດຊັບພະຍາກອນທີ່ບໍ່ໄດ້ໃຊ້

ການເຮັດວຽກໃນສະພາບແວດລ້ອມທີ່ມີຄວາມໄວແມ່ນດີຫຼາຍ. ພວກເຮົາຕ້ອງການອົງການຈັດຕັ້ງເຕັກໂນໂລຢີ ເລັ່ງ. ການຈັດສົ່ງຊໍແວທີ່ໄວຂຶ້ນຍັງຫມາຍເຖິງການໃຊ້ PR ຫຼາຍຂຶ້ນ, ສະພາບແວດລ້ອມການເບິ່ງຕົວຢ່າງ, ຕົວແບບ, ແລະການແກ້ໄຂການວິເຄາະ. ທຸກຢ່າງຖືກນຳໃຊ້ຢູ່ໃນ Kubernetes. ໃຜມີເວລາທີ່ຈະທໍາຄວາມສະອາດການທົດສອບການຕິດຕັ້ງດ້ວຍຕົນເອງ? ມັນງ່າຍທີ່ຈະລືມກ່ຽວກັບການລຶບການທົດລອງທີ່ມີອາຍຸຫນຶ່ງອາທິດ. ບັນຊີລາຍການຄລາວຈະສິ້ນສຸດລົງຍ້ອນບາງສິ່ງບາງຢ່າງທີ່ພວກເຮົາລືມປິດ:

(Henning Jacobs:
Zhiza:
Corey Quinn:
Myth: ບັນຊີ AWS ຂອງທ່ານແມ່ນຫນ້າທີ່ຂອງຈໍານວນຜູ້ໃຊ້ທີ່ທ່ານມີ.
ຄວາມຈິງ: ຄະແນນ AWS ຂອງທ່ານແມ່ນຫນ້າທີ່ຂອງຈໍານວນວິສະວະກອນທີ່ທ່ານມີ.

Ivan Kurnosov (ຕອບໂຕ້):
ຄວາມ​ຈິງ​ທີ່​ແທ້​ຈິງ​: ຄະ​ແນນ AWS ຂອງ​ທ່ານ​ແມ່ນ​ການ​ທໍາ​ງານ​ຂອງ​ຈໍາ​ນວນ​ຂອງ​ສິ່ງ​ທີ່​ທ່ານ​ລືມ​ປິດ​ການ​ທໍາ​ງານ / ລຶບ​.

Kubernetes Janitor (kube-janitor) ຊ່ວຍເຮັດຄວາມສະອາດກຸ່ມຂອງທ່ານ. ການຕັ້ງຄ່າ janitor ແມ່ນມີຄວາມຍືດຫຍຸ່ນສໍາລັບການນໍາໃຊ້ທົ່ວໂລກແລະທ້ອງຖິ່ນ:

• ກົດລະບຽບຂອງກຸ່ມສາມາດກໍານົດເວລາສູງສຸດຕໍ່ຊີວິດ (TTL) ສໍາລັບການປະຕິບັດ PR/test.
• ຊັບພະຍາກອນສ່ວນບຸກຄົນສາມາດຖືກອະທິບາຍດ້ວຍ janitor/ttl, ຕົວຢ່າງເພື່ອເອົາ spike/prototype ອັດຕະໂນມັດຫຼັງຈາກ 7 ມື້.

ກົດລະບຽບທົ່ວໄປຖືກກໍານົດໄວ້ໃນໄຟລ໌ YAML. ເສັ້ນທາງຂອງມັນແມ່ນຜ່ານຕົວກໍານົດການ --rules-file ໃນ kube-janitor. ນີ້ແມ່ນກົດລະບຽບຕົວຢ່າງທີ່ຈະເອົາ namespaces ທັງຫມົດອອກດ້ວຍ -pr- ໃນ​ຊື່​ຫຼັງ​ຈາກ​ສອງ​ມື້​:

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

ຕົວຢ່າງຕໍ່ໄປນີ້ຄວບຄຸມການໃຊ້ປ້າຍກຳກັບຂອງແອັບພລິເຄຊັ່ນເທິງ Deployment and StatefulSet pods ສຳລັບ Deployments/StatefulSets ໃໝ່ທັງໝົດໃນປີ 2020, ແຕ່ໃນເວລາດຽວກັນອະນຸຍາດໃຫ້ປະຕິບັດການທົດສອບໂດຍບໍ່ມີປ້າຍກຳກັບນີ້ເປັນເວລາໜຶ່ງອາທິດ:

- 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

ເປີດໃຊ້ການສາທິດແບບຈຳກັດເວລາ 30 ນາທີໃນກຸ່ມທີ່ແລ່ນ kube-janitor:

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

ແຫຼ່ງຂອງຄ່າໃຊ້ຈ່າຍທີ່ເພີ່ມຂຶ້ນອີກອັນຫນຶ່ງແມ່ນປະລິມານຢ່າງຕໍ່ເນື່ອງ (AWS EBS). ການລຶບ Kubernetes StatefulSet ບໍ່ໄດ້ລຶບປະລິມານທີ່ຄົງຄ້າງຂອງມັນ (PVC - PersistentVolumeClaim). ປະລິມານ EBS ທີ່ບໍ່ໄດ້ໃຊ້ສາມາດເຮັດໃຫ້ຄ່າໃຊ້ຈ່າຍຫຼາຍຮ້ອຍໂດລາຕໍ່ເດືອນໄດ້ຢ່າງງ່າຍດາຍ. Kubernetes Janitor ມີຄຸນສົມບັດໃນການເຮັດຄວາມສະອາດ PVC ທີ່ບໍ່ໄດ້ໃຊ້. ຕົວຢ່າງ, ກົດລະບຽບນີ້ຈະເອົາ PVCs ທັງຫມົດທີ່ບໍ່ໄດ້ຕິດຕັ້ງໂດຍໂມດູນແລະທີ່ບໍ່ໄດ້ອ້າງອີງໂດຍ StatefulSet ຫຼື CronJob:

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

Kubernetes Janitor ສາມາດຊ່ວຍທ່ານຮັກສາກຸ່ມຂອງທ່ານໃຫ້ສະອາດ ແລະປ້ອງກັນບໍ່ໃຫ້ຄ່າໃຊ້ຈ່າຍຂອງຄອມພິວເຕີ້ຄລາວມີຂຶ້ນຢ່າງຊ້າໆ. ສໍາລັບຄໍາແນະນໍາໃນການນໍາໃຊ້ແລະການຕັ້ງຄ່າ, ປະຕິບັດຕາມ README kube-janitor.

ຫຼຸດການປັບຂະໜາດໃນເວລາບໍ່ເຮັດວຽກ

ໂດຍທົ່ວໄປແລ້ວລະບົບການທົດສອບ ແລະຂັ້ນຕອນແມ່ນຕ້ອງການເພື່ອເຮັດວຽກໃນເວລາເຮັດວຽກເທົ່ານັ້ນ. ບາງຄໍາຮ້ອງສະຫມັກການຜະລິດ, ເຊັ່ນ: ເຄື່ອງມືກັບຄືນໄປບ່ອນຫ້ອງການ / admin, ຍັງຕ້ອງການພຽງແຕ່ມີຈໍາກັດແລະອາດຈະຖືກປິດການໃຊ້ງານໃນຕອນກາງຄືນ.

Kubernetes Downscaler (kube-downscaler) ອະນຸຍາດໃຫ້ຜູ້ໃຊ້ ແລະຜູ້ປະກອບການສາມາດປັບຂະໜາດລະບົບລົງໃນລະຫວ່າງຊົ່ວໂມງທີ່ບໍ່ເຮັດວຽກ. ການນຳໃຊ້ ແລະ StatefulSets ສາມາດປັບຂະໜາດໄດ້ເຖິງສູນ replicas. 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 nodes ພະນັກງານແນ່ນອນເຮັດໃຫ້ຄວາມແຕກຕ່າງທີ່ສັງເກດເຫັນໃນບັນຊີລາຍການ AWS ຂອງທ່ານ.

ແຕ່ຈະເປັນແນວໃດຖ້າຂ້ອຍຕ້ອງເຮັດວຽກໃນລະຫວ່າງກຸ່ມ "downtime"? ການນຳໃຊ້ບາງອັນສາມາດຖືກຍົກເວັ້ນຢ່າງຖາວອນຈາກການປັບຂະ ໜາດ ໂດຍການເພີ່ມຕົວຫຼຸດ/ຍົກເວັ້ນ: ຄຳອະທິບາຍທີ່ແທ້ຈິງ. ການນຳໃຊ້ສາມາດຖືກຍົກເວັ້ນຊົ່ວຄາວໂດຍການໃຊ້ຕົວຫຍໍ້/exclude-ຈົນກ່ວາ annotation ດ້ວຍການສະແຕມເວລາຢ່າງແທ້ຈິງໃນຮູບແບບ YYYY-MM-DD HH:MM (UTC). ຖ້າຈໍາເປັນ, ກຸ່ມທັງຫມົດສາມາດຖືກປັບຂະຫນາດຄືນໄດ້ໂດຍການນໍາໃຊ້ຝັກທີ່ມີຄໍາບັນຍາຍ 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

ເບິ່ງ README kube-downscaler, ຖ້າຫາກວ່າທ່ານມີຄວາມສົນໃຈໃນຄໍາແນະນໍາການນໍາໃຊ້ແລະທາງເລືອກເພີ່ມເຕີມ.

ໃຊ້ການປັບຂະໜາດອັດຕະໂນມັດຕາມແນວນອນ

ຄໍາຮ້ອງສະຫມັກ / ບໍລິການຈໍານວນຫຼາຍຈັດການກັບຮູບແບບການໂຫຼດແບບເຄື່ອນໄຫວ: ບາງຄັ້ງໂມດູນຂອງພວກເຂົາບໍ່ເຮັດວຽກ, ແລະບາງຄັ້ງພວກມັນເຮັດວຽກເຕັມທີ່. ການດໍາເນີນງານຂອງເຮືອຖາວອນຂອງຝັກເພື່ອຮັບມືກັບການໂຫຼດສູງສຸດແມ່ນບໍ່ປະຫຍັດ. Kubernetes ຮອງຮັບການປັບຂະໜາດອັດຕະໂນມັດຕາມລວງນອນໃນທົ່ວຊັບພະຍາກອນ HorizontalPodAutoscaler (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

Zalando ໄດ້ສ້າງອົງປະກອບເພື່ອເຊື່ອມຕໍ່ metrics ແບບກໍານົດເອງໄດ້ຢ່າງງ່າຍດາຍສໍາລັບການປັບຂະຫນາດ: ອະແດບເຕີ Kube Metrics (kube-metrics-adapter) ເປັນອະແດບເຕີວັດແທກທົ່ວໄປສຳລັບ Kubernetes ທີ່ສາມາດເກັບກຳ ແລະຮັບໃຊ້ການວັດແທກແບບກຳນົດເອງ ແລະພາຍນອກສຳລັບການປັບຂະໜາດອອກຕາມລວງນອນຂອງຝັກ. ມັນສະຫນັບສະຫນູນການຂະຫຍາຍໂດຍອີງໃສ່ metrics Prometheus, ແຖວ SQS, ແລະການຕັ້ງຄ່າອື່ນໆ. ຕົວຢ່າງ, ເພື່ອຂະຫຍາຍການໃຊ້ງານຂອງທ່ານໃຫ້ເປັນ metric ແບບກຳນົດເອງທີ່ເປັນຕົວແທນໂດຍແອັບພລິເຄຊັນເອງເປັນ JSON ໃນ /metrics ໃຊ້:

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

ການຕັ້ງຄ່າການປັບຂະໜາດອັດຕະໂນມັດຕາມລວງນອນດ້ວຍ HPA ຄວນເປັນໜຶ່ງໃນການປະຕິບັດເລີ່ມຕົ້ນເພື່ອປັບປຸງປະສິດທິພາບສໍາລັບການບໍລິການທີ່ບໍ່ມີລັດ. Spotify ມີ​ການ​ນໍາ​ສະ​ເຫນີ​ທີ່​ມີ​ປະ​ສົບ​ການ​ແລະ​ຄໍາ​ແນະ​ນໍາ​ຂອງ​ເຂົາ​ເຈົ້າ​ສໍາ​ລັບ HPA​: ປັບຂະໜາດການໃຊ້ງານຂອງເຈົ້າ, ບໍ່ແມ່ນກະເປົາເງິນຂອງເຈົ້າ.

ຫຼຸດຜ່ອນການຈອງຊັບພະຍາກອນຫຼາຍເກີນໄປ

ປະລິມານວຽກ Kubernetes ກໍານົດຄວາມຕ້ອງການ CPU / ຫນ່ວຍຄວາມຈໍາຂອງເຂົາເຈົ້າໂດຍຜ່ານ "ການຮ້ອງຂໍຊັບພະຍາກອນ." ຊັບພະຍາກອນ CPU ແມ່ນຖືກວັດແທກເປັນແກນ virtual ຫຼືຫຼາຍກວ່າທົ່ວໄປໃນ "millicores", ຕົວຢ່າງ 500m ຫມາຍເຖິງ 50% vCPU. ຊັບພະຍາກອນຄວາມຊົງຈໍາຖືກວັດແທກເປັນ bytes, ແລະຄໍາຕໍ່ທ້າຍທົ່ວໄປສາມາດນໍາໃຊ້ໄດ້, ເຊັ່ນ: 500Mi, ຊຶ່ງຫມາຍຄວາມວ່າ 500 megabytes. ການຮ້ອງຂໍຊັບພະຍາກອນ "lock" ຄວາມອາດສາມາດໃນ nodes ພະນັກງານ, ຊຶ່ງຫມາຍຄວາມວ່າ pod ທີ່ມີການຮ້ອງຂໍ CPU 1000m ໃນ node ທີ່ມີ 4 vCPUs ຈະປ່ອຍໃຫ້ພຽງແຕ່ 3 vCPUs ສາມາດໃຊ້ໄດ້ກັບ pods ອື່ນໆ. [1]

Slack (ສະຫງວນເກີນ) ແມ່ນຄວາມແຕກຕ່າງລະຫວ່າງຊັບພະຍາກອນທີ່ຮ້ອງຂໍແລະການນໍາໃຊ້ຕົວຈິງ. ຕົວຢ່າງ, ຝັກທີ່ຮ້ອງຂໍ 2 GiB ຂອງຫນ່ວຍຄວາມຈໍາແຕ່ໃຊ້ພຽງແຕ່ 200 MiB ມີ ~ 1,8 GiB ຂອງຫນ່ວຍຄວາມຈໍາ "ເກີນ". ເງິນເກີນຄ່າໃຊ້ຈ່າຍ. ຫນຶ່ງສາມາດຄາດຄະເນໄດ້ປະມານວ່າ 1 GiB ຂອງຫນ່ວຍຄວາມຈໍາຊໍ້າຊ້ອນມີຄ່າໃຊ້ຈ່າຍ ~ $10 ຕໍ່ເດືອນ. [2]

ລາຍງານຊັບພະຍາກອນ Kubernetes (kube-resource-report) ສະ​ແດງ​ການ​ສະ​ຫງວນ​ເກີນ​ແລະ​ສາ​ມາດ​ຊ່ວຍ​ໃຫ້​ທ່ານ​ກໍາ​ນົດ​ທ່າ​ແຮງ​ການ​ປະ​ຢັດ​:

ລາຍງານຊັບພະຍາກອນ Kubernetes ສະ​ແດງ​ໃຫ້​ເຫັນ​ສ່ວນ​ເກີນ​ລວມ​ໂດຍ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ແລະ​ຄໍາ​ສັ່ງ​. ນີ້ອະນຸຍາດໃຫ້ທ່ານຊອກຫາສະຖານທີ່ທີ່ຄວາມຕ້ອງການຊັບພະຍາກອນສາມາດຫຼຸດລົງ. ບົດລາຍງານ HTML ທີ່ສ້າງຂຶ້ນພຽງແຕ່ສະຫນອງພາບລວມຂອງການນໍາໃຊ້ຊັບພະຍາກອນ. ທ່ານຄວນເບິ່ງການນໍາໃຊ້ CPU / ຫນ່ວຍຄວາມຈໍາໃນໄລຍະເວລາເພື່ອກໍານົດການຮ້ອງຂໍຊັບພະຍາກອນທີ່ພຽງພໍ. ນີ້ແມ່ນຕາຕະລາງ Grafana ສໍາລັບການບໍລິການ CPU ຫນັກ "ປົກກະຕິ": ຝັກທັງຫມົດແມ່ນໃຊ້ຫນ້ອຍກວ່າ 3 CPU cores ທີ່ຮ້ອງຂໍຢ່າງຫຼວງຫຼາຍ:

ການຫຼຸດຜ່ອນການຮ້ອງຂໍ CPU ຈາກ 3000m ຫາ ~ 400m ປົດປ່ອຍຊັບພະຍາກອນສໍາລັບວຽກອື່ນໆແລະອະນຸຍາດໃຫ້ກຸ່ມຂະຫນາດນ້ອຍກວ່າ.

"ການໃຊ້ CPU ໂດຍສະເລ່ຍຂອງຕົວຢ່າງ EC2 ມັກຈະຢູ່ໃນຂອບເຂດອັດຕາສ່ວນຕົວເລກດຽວ," ຂຽນ Corey Quinn. ໃນຂະນະທີ່ສໍາລັບ EC2 ການປະເມີນຂະຫນາດທີ່ເຫມາະສົມອາດຈະເປັນການຕັດສິນໃຈທີ່ບໍ່ດີການປ່ຽນແປງບາງຄໍາຖາມຊັບພະຍາກອນ Kubernetes ໃນໄຟລ໌ YAML ແມ່ນງ່າຍ ແລະສາມາດນໍາເອົາການປະຫຍັດຢ່າງຫຼວງຫຼາຍ.

ແຕ່ພວກເຮົາຕ້ອງການໃຫ້ຄົນປ່ຽນແປງຄ່າໃນໄຟລ໌ YAML ແທ້ໆບໍ? ບໍ່, ເຄື່ອງຈັກສາມາດເຮັດໄດ້ດີກວ່າຫຼາຍ! Kubernetes Vertical Pod Autoscaler (VPA) ເຮັດແນວນັ້ນຄື: ປັບການຮ້ອງຂໍຊັບພະຍາກອນ ແລະຂໍ້ຈຳກັດຕາມວຽກ. ນີ້ແມ່ນເສັ້ນສະແດງຕົວຢ່າງຂອງການຮ້ອງຂໍ Prometheus CPU (ເສັ້ນສີຟ້າບາງໆ) ດັດແປງໂດຍ VPA ໃນໄລຍະເວລາ:

Zalando ໃຊ້ VPA ໃນທຸກກຸ່ມຂອງມັນ ສໍາລັບອົງປະກອບພື້ນຖານໂຄງລ່າງ. ແອັບພລິເຄຊັນທີ່ບໍ່ສໍາຄັນຍັງສາມາດໃຊ້ VPA ໄດ້.

ຄຳ ແພງ ຈາກ Fairwind ແມ່ນເຄື່ອງມືທີ່ສ້າງ VPA ສໍາລັບແຕ່ລະການຕິດຕັ້ງໃນ namespace ແລະຫຼັງຈາກນັ້ນສະແດງຄໍາແນະນໍາ VPA ໃນ dashboard ຂອງມັນ. ມັນສາມາດຊ່ວຍຜູ້ພັດທະນາກໍານົດການຮ້ອງຂໍ CPU / ຫນ່ວຍຄວາມຈໍາທີ່ຖືກຕ້ອງສໍາລັບຄໍາຮ້ອງສະຫມັກຂອງເຂົາເຈົ້າ:

ຂ້ອຍຂຽນນ້ອຍໆ blogpost ກ່ຽວກັບ VPA ໃນ​ປີ 2019, ແລະ​ເມື່ອ​ບໍ່​ດົນ​ມາ​ນີ້ ຊຸມຊົນຜູ້ໃຊ້ສຸດທ້າຍ CNCF ໄດ້ປຶກສາຫາລືກ່ຽວກັບບັນຫາ VPA.

ການໃຊ້ EC2 Spot Instances

ສຸດທ້າຍແຕ່ບໍ່ໄດ້ຢ່າງຫນ້ອຍ, ຄ່າໃຊ້ຈ່າຍ AWS EC2 ສາມາດຫຼຸດລົງໄດ້ໂດຍການໃຊ້ Spot instances ເປັນ Kubernetes worker nodes [3]. Spot instances ມີຢູ່ໃນສ່ວນຫຼຸດສູງສຸດ 90% ເມື່ອທຽບກັບລາຄາຕາມຄວາມຕ້ອງການ. ການແລ່ນ Kubernetes ໃນ EC2 Spot ແມ່ນການປະສົມປະສານທີ່ດີ: ທ່ານຈໍາເປັນຕ້ອງລະບຸປະເພດຕົວຢ່າງທີ່ແຕກຕ່າງກັນຫຼາຍສໍາລັບຄວາມພ້ອມທີ່ສູງຂຶ້ນ, ຊຶ່ງຫມາຍຄວາມວ່າທ່ານສາມາດໄດ້ຮັບ node ທີ່ໃຫຍ່ກວ່າສໍາລັບລາຄາດຽວກັນຫຼືຕ່ໍາກວ່າ, ແລະຄວາມອາດສາມາດທີ່ເພີ່ມຂຶ້ນສາມາດຖືກນໍາໃຊ້ໂດຍບັນຈຸຂອງວຽກ Kubernetes.

ວິທີການແລ່ນ Kubernetes ໃນ EC2 Spot? ມີຫລາຍທາງເລືອກ: ໃຊ້ບໍລິການພາກສ່ວນທີສາມເຊັ່ນ SpotInst (ປະຈຸບັນເອີ້ນວ່າ "Spot", ຢ່າຖາມຂ້ອຍວ່າເປັນຫຍັງ), ຫຼືພຽງແຕ່ເພີ່ມ Spot AutoScalingGroup (ASG) ເຂົ້າໃນກຸ່ມຂອງທ່ານ. ຕົວຢ່າງ, ນີ້ແມ່ນ CloudFormation snippet ສໍາລັບ "capacity-optimized" Spot ASG ທີ່ມີຫຼາຍປະເພດຕົວຢ່າງ:

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 terminations, ຕົວຢ່າງໂດຍການລວມ node ເມື່ອ instance ຖືກຢຸດ
• Zalando ໃຊ້ ສ້ອມ autoscaling cluster ຢ່າງເປັນທາງການກັບ node pool ບູລິມະສິດ
• ຈຸດຈຸດ ສາມາດບັງຄັບ ຍອມຮັບ "ການລົງທະບຽນ" ຂອງວຽກທີ່ຈະດໍາເນີນການໃນ Spot

Summary

ຂ້ອຍຫວັງວ່າເຈົ້າຈະພົບເຫັນບາງເຄື່ອງມືທີ່ນໍາສະເຫນີທີ່ເປັນປະໂຫຍດໃນການຫຼຸດຜ່ອນບັນຊີລາຍການຟັງຂອງເຈົ້າ. ທ່ານສາມາດຊອກຫາເນື້ອໃນຂອງບົດຄວາມສ່ວນໃຫຍ່ໄດ້ຢູ່ ການສົນທະນາຂອງຂ້ອຍຢູ່ທີ່ DevOps Gathering 2019 ໃນ YouTube ແລະໃນສະໄລ້.

ການປະຕິບັດທີ່ດີທີ່ສຸດຂອງທ່ານສໍາລັບການປະຫຍັດຄ່າໃຊ້ຈ່າຍໃນຄລາວຢູ່ໃນ Kubernetes ແມ່ນຫຍັງ? ກະລຸນາແຈ້ງໃຫ້ຂ້ອຍທາບທີ່ Twitter (@try_except_).

[1] ໃນຄວາມເປັນຈິງ, vCPU ຫນ້ອຍກວ່າ 3 ຈະຍັງຄົງສາມາດໃຊ້ໄດ້ຍ້ອນວ່າການສົ່ງຜ່ານຂອງ node ຖືກຫຼຸດລົງໂດຍຊັບພະຍາກອນຂອງລະບົບທີ່ສະຫງວນໄວ້. Kubernetes ຈໍາແນກລະຫວ່າງຄວາມອາດສາມາດຂອງໂຫນດທາງກາຍະພາບ ແລະຊັບພະຍາກອນ "ສະໜອງໃຫ້" (Node Allocatable).

[2] ຕົວຢ່າງການຄິດໄລ່: one m5.large instance with 8 GiB of memory is ~$84 ​​​​ຕໍ່ເດືອນ (eu-central-1, On-Demand), i.e. ການບລັອກ 1/8 node ແມ່ນປະມານ ~ $10/ເດືອນ.

[3] ມີຫຼາຍວິທີໃນການຫຼຸດໃບເກັບເງິນ EC2 ຂອງທ່ານ, ເຊັ່ນ: Reserved Instances, Savings Plan, ແລະອື່ນໆ - ຂ້ອຍຈະບໍ່ກວມເອົາຫົວຂໍ້ເຫຼົ່ານັ້ນຢູ່ນີ້, ແຕ່ເຈົ້າຄວນເບິ່ງມັນຢ່າງແນ່ນອນ!

ຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບຫຼັກສູດ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com