AWSдеги Kubernetes булуттук чыгымдарын үнөмдөңүз

Макаланын котормосу курстун башталышынын алдында даярдалган "Кубернетеске негизделген инфраструктуралык платформа".

Kubernetes менен иштөөдө булут чыгымдарын кантип үнөмдөөгө болот? Эч бир туура чечим жок, бирок бул макалада ресурстарыңызды натыйжалуураак башкарууга жана булуттагы эсептөө чыгымдарыңызды кыскартууга жардам бере турган бир нече куралдар сүрөттөлөт.

Мен бул макаланы AWS үчүн Kubernetes менен жаздым, бирок ал (дээрлик) башка булут провайдерлерине да дал ушундай колдонулат. Мен сиздин кластериңизде(лериңизде) мурунтан эле автоматтык масштабдоо конфигурацияланган деп ойлойм (кластер-автошкалагыч). Ресурстарды жок кылуу жана жайылтуууңуздун масштабын азайтуу, эгерде ал жумушчу түйүндөрүңүздүн паркын азайтса гана акчаңызды үнөмдөйт (EC2 инстанциялары).

Бул макалада төмөнкүлөр камтылат:

• пайдаланылбаган ресурстарды тазалоо (кубе-даражачы)
• Жумуштан тышкаркы убакта масштабды азайтуу (кубду төмөндөтүүчү)
• горизонталдык автоскалоону (HPA) колдонуу
• ашыкча ресурстарды резервдештирүү (кубе-ресурс-отчет, VPA)
• Spot инстанцияларын колдонуу

Колдонулбаган ресурстарды тазалоо

Ыкчам чөйрөдө иштөө сонун. Биз технологиялык уюмдарды каалайбыз тездетилген. Тезирээк программалык камсыздоо, ошондой эле көбүрөөк PR жайылтууларды, алдын ала көрүү чөйрөлөрүн, прототиптерди жана аналитикалык чечимдерди билдирет. Баары Kubernetesте орнотулган. Сыноолорду кол менен тазалоого кимдин убактысы бар? Бир жумалык экспериментти жок кылууну унутуу оңой. Булуттун эсеби жабылганды унутуп калгандыктан улам көтөрүлөт:

(Хеннинг Джейкобс:
Жиза:
(цитаталар) Кори Куинн:
Миф: Сиздин AWS каттоо эсебиңиз сизде бар колдонуучулардын санынын функциясы.
Факт: Сиздин AWS баллыңыз сизде инженерлердин санына жараша болот.

Иван Курносов (жооп катары):
Чыныгы факт: Сиздин AWS упайыңыз сиз өчүрүүнү/жок кылууну унутуп калган нерселердин санынын функциясы.)

Kubernetes Janitor (кубе-дворник) кластериңизди тазалоого жардам берет. Дворник конфигурациясы глобалдык жана жергиликтүү колдонуу үчүн ийкемдүү:

• Жалпы кластерлик эрежелер PR/сынак жайылтуулары үчүн максималдуу жашоо убактысын (TTL) аныктай алат.
• Жеке ресурстарга дворник/ttl менен түшүндүрмө берсе болот, мисалы 7 күндөн кийин спикти/прототипти автоматтык түрдө алып салуу.

Жалпы эрежелер YAML файлында аныкталган. Анын жолу параметр аркылуу өтөт --rules-file кубе-жаначыда. Бул жерде бардык аттар мейкиндиктерин алып салуу үчүн үлгү эреже болуп саналат -pr- эки күндөн кийин атына:

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

Төмөнкү мисал 2020-жылы бардык жаңы Deployment/StatefulSet үчүн Deployment жана StatefulSet подколорундагы тиркеме энбелгисин колдонууну жөнгө салат, бирок ошол эле учурда бул энбелгисиз сыноолорду бир жума бою аткарууга мүмкүндүк берет:

- 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

Kube-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 пайдаланылбаган PVCs тазалоо үчүн өзгөчөлүгү бар. Мисалы, бул эреже модулда орнотулбаган жана StatefulSet же CronJob тарабынан шилтеме кылынбаган бардык PVC'лерди жок кылат:

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

Kubernetes Janitor кластериңизди таза сактоого жана булуттагы эсептөө чыгымдарынын акырындап көбөйүшүнө жол бербөөгө жардам берет. Жайгаштыруу жана конфигурациялоо көрсөтмөлөрү үчүн, ээрчиңиз README кубе-жаначы.

Жумуштан тышкаркы убакта масштабды азайтыңыз

Сыноо жана коюу системалары, адатта, иш сааттарында гана иштеши талап кылынат. Кээ бир өндүрүш колдонмолору, мисалы, бэк-офис/администратор куралдары да чектелген жеткиликтүүлүктү талап кылат жана түн ичинде өчүрүлүшү мүмкүн.

Kubernetes Downscaler (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 эсебиңизде байкаларлык айырманы түзөт.

Бирок мен кластердин "токтоо убактысында" иштешим керек болсочу? Кээ бир жайылтууларды масштабдоодон биротоло чыгарып салууга болот: ылдыйлатуучу/чыгаруу: чыныгы аннотация. Жайгаштырууларды ЖЖЖЖ-АА-КК СЖ:АА (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 кубду төмөндөтүүчү, эгер сизди жайылтуу нускамалары жана кошумча параметрлер кызыктырса.

Горизонталдуу автомасштабды колдонуңуз

Көптөгөн тиркемелер/кызматтар динамикалык жүктөө үлгүсү менен иштешет: кээде алардын модулдары бош турат, кээде алар толук кубаттуулукта иштешет. Максималдуу эң жогорку жүктөмдү көтөрүү үчүн туруктуу погондор паркын иштетүү үнөмдүү эмес. 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 масштабдоо үчүн ыңгайлаштырылган метрикаларды оңой туташтыруу үчүн компонентти түздү: Kube метрикалык адаптер (kube-metrics-adapter) - бул Kubernetes үчүн жалпы метрикалык адаптер, ал подкасттарды горизонталдуу автоскалдаштыруу үчүн ыңгайлаштырылган жана тышкы метрикаларды чогултуп, тейлей алат. Бул Prometheus метрикасынын, SQS кезектеринин жана башка орнотуулардын негизинде масштабдоону колдойт. Мисалы, колдонмонун өзү тарабынан 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 ресурстары виртуалдык өзөктөр менен өлчөнөт же көбүнчө “милликорлор” менен өлчөнөт, мисалы 500м 50% vCPU дегенди билдирет. Эстутум ресурстары байт менен өлчөнөт жана жалпы суффикстерди колдонсо болот, мисалы 500Mi, бул 500 мегабайт дегенди билдирет. Ресурс суроо-талаптары жумушчу түйүндөрдөгү "кулпулоо" сыйымдуулугу, башкача айтканда 1000 vCPU бар түйүндө 4 м CPU сурамы бар подвод башка подколор үчүн 3 гана vCPU калтырат. [1]

Шашылыш (ашыкча резерв) суралган ресурстар менен иш жүзүндө колдонуунун ортосундагы айырма болуп саналат. Мисалы, 2 ГБ эстутумду талап кылган, бирок 200 МБ гана колдонгон поддондун ~1,8 ГБ "ашыкча" эс тутуму бар. Ашыкча акча кетет. Болжол менен 1 ГБ ашыкча эстутум айына ~ 10 доллар турат деп болжолдоого болот. [2]

Kubernetes Resource Report (kube-resource-report) ашыкча резервдерди көрсөтөт жана үнөмдөө потенциалын аныктоого жардам берет:

Kubernetes Resource Report колдонмо жана буйрук менен топтолгон ашыкчаны көрсөтөт. Бул ресурстук суроо-талаптарды азайта турган жерлерди табууга мүмкүндүк берет. Түзүлгөн HTML отчету ресурсту колдонуунун сүрөтүн гана берет. Адекваттуу ресурстук суроо-талаптарды аныктоо үчүн CPU/эстутумдун колдонулушун убакыттын өтүшү менен карап чыгышыңыз керек. Бул жерде "типтүү" CPU оор кызмат үчүн Grafana диаграммасы келтирилген: бардык подколор суралган 3 CPU өзөктөрүнөн кыйла азыраак колдонуп жатышат:

CPU суроо-талабын 3000мден ~400мге чейин кыскартуу башка жумуш жүктөрү үчүн ресурстарды бошотуп, кластердин кичирейишине мүмкүндүк берет.

"EC2 инстанцияларынын орточо CPU колдонулушу көбүнчө бир орундуу пайыздык диапазондо жүрөт" деп жазат Кори Куинн. EC2 үчүн туура өлчөмүн баалоо жаман чечим болушу мүмкүнYAML файлындагы кээ бир Kubernetes ресурстук сурамдарын өзгөртүү оңой жана чоң үнөмдөөгө алып келиши мүмкүн.

Бирок биз адамдардын YAML файлдарындагы баалуулуктарды өзгөртүшүн каалайбызбы? Жок, машиналар муну алда канча жакшыраак кыла алат! Kubernetes Vertical Pod Autoscaler (VPA) дал ушундай кылат: ресурстук суроо-талаптарды жана чектөөлөрдү жумуштун жүгүнө ылайык ыңгайлаштырат. Бул жерде убакыттын өтүшү менен VPA тарабынан ылайыкташтырылган Prometheus CPU сурамдарынын (ичке көк сызык) мисалы:

Zalando бардык кластерлеринде VPA колдонот инфраструктура компоненттери үчүн. Критикалык эмес тиркемелер VPA колдоно алышат.

Артык & From Fairwind бул аттар мейкиндигинде ар бир жайгаштыруу үчүн VPA түзүп, андан кийин анын башкаруу панелинде VPA сунушун көрсөткөн курал. Бул иштеп чыгуучуларга алардын тиркемелери үчүн туура CPU/эстутум сурамдарын коюуга жардам берет:

Мен кичинекей жаздым VPA жөнүндө блог 2019-жылы жана жакында эле CNCF Акыркы Колдонуучу Коомчулугу VPA маселесин талкуулады.

EC2 Spot Instances колдонуу

Акыры, бирок эң аз дегенде, Spot инстанцияларын Kubernetes жумушчу түйүндөрү катары колдонуу менен AWS EC2 чыгымдарын кыскартууга болот [3]. Spot инстанциялары Талап боюнча баага салыштырмалуу 90% арзандатуу менен жеткиликтүү. Kubernetes'ти EC2 Spot'та иштетүү - бул жакшы айкалыштыруу: көбүрөөк жеткиликтүүлүк үчүн бир нече ар кандай үлгү түрлөрүн көрсөтүшүңүз керек, башкача айтканда, чоңураак түйүндү бирдей же төмөн баага ала аласыз жана жогорулатылган кубаттуулукту Кубернетестин контейнердик жүктөрү колдонсо болот.

Kubernetesти EC2 Spotто кантип иштетүү керек? Бир нече варианттар бар: үчүнчү тараптын 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 аяктоолорун иштетүү керек, мисалы, инстанция токтогондо түйүндү бириктирүү аркылуу
• Zalando колдонот айры түйүн пулунун артыкчылыктары менен расмий кластердик масштабдоо
• Spot түйүндөр мажбурлоого болот Spotто иштөө үчүн жүктөмдөрдүн “каттоолорун” кабыл алыңыз

на

Сунушталган куралдардын кээ бирлери булут эсебиңизди азайтуу үчүн пайдалуу болот деп үмүттөнөм. Макаланын көпчүлүк мазмунун бул жерден таба аласыз YouTube жана слайддардагы DevOps Gathering 2019дагы баяндамам.

Kubernetes'те булут чыгымдарын үнөмдөө боюнча кандай мыкты тажрыйбаларыңыз бар? Сураныч, мага кабарлаңыз Twitter (@try_except_).

[1] Чынында, 3төн аз vCPU колдонууга жарактуу бойдон калат, анткени түйүндүн өткөрүү жөндөмдүүлүгү сакталган тутум ресурстары менен кыскарган. Kubernetes физикалык түйүн дараметин жана "камсыздалган" ресурстарды айырмалайт (Бөлүнүүчү түйүн).

[2] Эсептөө мисалы: 5 ГБ эс тутуму бар бир m8.large инстанциясы айына ~ 84 долларды түзөт (eu-central-1, Талап боюнча), б.а. 1/8 түйүн бөгөттөө болжол менен айына ~ $10.

[3] EC2 эсебиңизди кыскартуунун дагы көптөгөн жолдору бар, мисалы, камдалган инстанциялар, үнөмдөө планы ж.

Курс жөнүндө көбүрөөк билүү.

Source: www.habr.com