დაზოგეთ Kubernetes ღრუბლოვანი ხარჯები AWS-ზე

სტატიის თარგმანი მომზადდა კურსის დაწყების წინა დღეს "ინფრასტრუქტურული პლატფორმა Kubernetes-ზე დაფუძნებული".

როგორ დაზოგოთ ღრუბლის ხარჯები Kubernetes-თან მუშაობისას? არ არსებობს ერთი სწორი გამოსავალი, მაგრამ ეს სტატია აღწერს რამდენიმე ინსტრუმენტს, რომელიც დაგეხმარებათ უფრო ეფექტურად მართოთ თქვენი რესურსები და შეამციროთ თქვენი ღრუბლოვანი გამოთვლების ხარჯები.

მე დავწერე ეს სტატია Kubernetes-ისთვის AWS-ის გათვალისწინებით, მაგრამ ის (თითქმის) ზუსტად იგივენაირად იქნება სხვა ღრუბლოვან პროვაიდერებზე. მე ვარაუდობ, რომ თქვენს კლასტერ(ებ)ს უკვე აქვს ავტოსკალირების კონფიგურაცია (კლასტერ-ავტოსკალერი). რესურსების ამოღება და თქვენი განლაგების შემცირება დაზოგავს ფულს მხოლოდ იმ შემთხვევაში, თუ ეს ასევე შეამცირებს მუშათა კვანძების ფლოტს (EC2 შემთხვევები).

ეს სტატია მოიცავს:

• გამოუყენებელი რესურსების გაწმენდა (კუბე-დამლაგებელი)
• შეამცირეთ მასშტაბები არასამუშაო საათებში (კუბე-დამამცირებელი)
• ჰორიზონტალური ავტოსკალირების (HPA) გამოყენებით,
• გადაჭარბებული რესურსების დაჯავშნის შემცირება (kube-resource-report, VPA)
• Spot ინსტანციების გამოყენებით

გამოუყენებელი რესურსების გაწმენდა

სწრაფ გარემოში მუშაობა შესანიშნავია. ჩვენ გვინდა ტექნიკური ორგანიზაციები აჩქარდა. პროგრამული უზრუნველყოფის უფრო სწრაფი მიწოდება ასევე ნიშნავს უფრო მეტ PR განთავსებას, გადახედვის გარემოს, პროტოტიპებს და ანალიტიკური გადაწყვეტილებებს. ყველაფერი განლაგებულია Kubernetes-ზე. ვის აქვს დრო, ხელით გაასუფთავოს სატესტო განლაგება? მარტივია დაივიწყო ერთი კვირის წინანდელი ექსპერიმენტის წაშლა. ღრუბლის გადასახადი გაიზრდება იმის გამო, რაც დაგვავიწყდა დახურვა:

(ჰენინგ ჯეიკობსი:
ჟიზა:
(ციტატები) კორი ქუინი:
მითი: თქვენი AWS ანგარიში არის თქვენი მომხმარებლების რაოდენობის ფუნქცია.
ფაქტი: თქვენი AWS ქულა არის თქვენი ინჟინრების რაოდენობის ფუნქცია.

ივან კურნოსოვი (საპასუხოდ):
რეალური ფაქტი: თქვენი AWS ქულა არის იმ ნივთების რაოდენობის ფუნქცია, რომელთა გამორთვა/წაშლა დაგავიწყდათ.)

კუბერნეტის დამლაგებელი (კუბე-დამლაგებელი) გეხმარებათ თქვენი კლასტერის გასუფთავებაში. დამლაგებლის კონფიგურაცია მოქნილია როგორც გლობალური, ასევე ადგილობრივი გამოყენებისთვის:

• კლასტერის მასშტაბის წესებს შეუძლიათ განსაზღვრონ PR/ტესტი განლაგების მაქსიმალური დრო (TTL).
• ინდივიდუალური რესურსების ანოტაცია შესაძლებელია დამლაგებელი/ttl-ით, მაგალითად, 7 დღის შემდეგ სპიკის/პროტოტიპის ავტომატურად ამოღება.

ზოგადი წესები განსაზღვრულია YAML ფაილში. მისი გზა გადის პარამეტრზე --rules-file კუბე-დამლაგებელში. აქ არის წესის მაგალითი, რომლითაც წაშალეთ ყველა სახელთა სივრცე -pr- სახელით ორი დღის შემდეგ:

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

შემდეგი მაგალითი არეგულირებს აპლიკაციის ლეიბლის გამოყენებას Deployment და 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-ების გაწმენდის ფუნქცია. მაგალითად, ეს წესი წაშლის ყველა PVC-ს, რომელიც არ არის დამონტაჟებული მოდულით და რომლებიც არ არის მითითებული 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 დაგეხმარებათ შეინარჩუნოთ თქვენი კლასტერი სისუფთავე და თავიდან აიცილოთ ღრუბლოვანი გამოთვლის ხარჯების ნელა დაგროვება. განლაგებისა და კონფიგურაციის ინსტრუქციებისთვის მიჰყევით წაიკითხეთ კუბე-დამლაგებელი.

შეამცირეთ სკალირება არასამუშაო საათებში

ტესტირებისა და დადგმის სისტემები, როგორც წესი, საჭიროა მხოლოდ სამუშაო საათების განმავლობაში. ზოგიერთი საწარმოო აპლიკაცია, როგორიცაა back office/admin ინსტრუმენტები, ასევე მოითხოვს მხოლოდ შეზღუდულ ხელმისაწვდომობას და შეიძლება გამორთული იყოს ღამით.

Kubernetes Downscaler (kube-downscaler) მომხმარებლებს და ოპერატორებს საშუალებას აძლევს შეამცირონ სისტემა არასამუშაო საათებში. Deployments და 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 კანონპროექტში.

მაგრამ რა მოხდება, თუ მჭირდება მუშაობა კლასტერული "შეუსვენებლობის" დროს? ზოგიერთი განლაგება შეიძლება სამუდამოდ გამოირიცხოს სკალირებისგან, შემცირების/გამორიცხვის: ნამდვილი ანოტაციის დამატებით. დანერგვა შეიძლება დროებით გამოირიცხოს შემცირების/გამორიცხვის ანოტაციის გამოყენებით აბსოლუტური დროის შტამპით ფორმატში წწწ-თმ-დდ HH:MM (UTC). საჭიროების შემთხვევაში, მთელი კლასტერი შეიძლება შემცირდეს ანოტაციის მქონე პოდის განლაგებით downscaler/force-uptimeმაგალითად, nginx ცარიელის გაშვებით:

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-მ შექმნა კომპონენტი, რომელიც მარტივად დააკავშირებს პერსონალურ მეტრიკას სკალირების მიზნით: Kube Metrics ადაპტერი (kube-metrics-adapter) არის ზოგადი მეტრიკის ადაპტერი Kubernetes-ისთვის, რომელსაც შეუძლია შეაგროვოს და გამოიყენოს მორგებული და გარე მეტრიკა პოდების ჰორიზონტალური ავტოსკალირებისთვის. იგი მხარს უჭერს სკალირებას პრომეთეს მეტრიკის, 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 რესურსები იზომება ვირტუალურ ბირთვებში ან უფრო ხშირად "მილიკორებში", მაგალითად 500m გულისხმობს 50% vCPU. მეხსიერების რესურსები იზომება ბაიტებში და შეიძლება გამოყენებულ იქნას ჩვეულებრივი სუფიქსები, როგორიცაა 500Mi, რაც ნიშნავს 500 მეგაბაიტს. რესურსი ითხოვს "დაბლოკვის" ტევადობას მუშა კვანძებზე, რაც ნიშნავს, რომ კვანძი 1000 მ CPU მოთხოვნით კვანძზე 4 vCPU-ით დატოვებს მხოლოდ 3 vCPU-ს ხელმისაწვდომს სხვა პოდებისთვის. [1]

სუსტი (ჭარბი რეზერვი) არის განსხვავება მოთხოვნილ რესურსებსა და რეალურ გამოყენებას შორის. მაგალითად, პოდს, რომელიც ითხოვს 2 გიბ მეხსიერებას, მაგრამ იყენებს მხოლოდ 200 მიბაიტს, აქვს ~1,8 გიბაიტი "ჭარბი" მეხსიერება. ჭარბი ფული ღირს. უხეშად შეიძლება შეფასდეს, რომ ზედმეტი მეხსიერების 1 გიბაიტი თვეში 10$ ღირს. [2]

Kubernetes რესურსების ანგარიში (kube-resource-report) აჩვენებს ზედმეტ რეზერვებს და დაგეხმარებათ დაზოგოთ დაზოგვის პოტენციალი:

Kubernetes რესურსების ანგარიში გვიჩვენებს აპლიკაციისა და ბრძანების მიერ აგრეგირებული ჭარბი რაოდენობას. ეს საშუალებას გაძლევთ იპოვოთ ადგილები, სადაც რესურსების მოთხოვნა შეიძლება შემცირდეს. გენერირებული HTML ანგარიში იძლევა მხოლოდ რესურსის გამოყენების სურათს. თქვენ უნდა გადახედოთ CPU/მეხსიერების გამოყენებას დროთა განმავლობაში, რათა დადგინდეს ადეკვატური რესურსის მოთხოვნები. აქ არის Grafana დიაგრამა "ტიპიური" CPU-ზე მძიმე სერვისისთვის: ყველა pods იყენებს მნიშვნელოვნად ნაკლებს, ვიდრე 3 მოთხოვნილი CPU ბირთვი:

CPU მოთხოვნის შემცირება 3000 მ-დან ~400 მ-მდე ათავისუფლებს რესურსებს სხვა დატვირთვისთვის და საშუალებას აძლევს კლასტერს იყოს უფრო მცირე.

"EC2 ინსტანციების CPU-ს საშუალო გამოყენება ხშირად ერთნიშნა პროცენტულ დიაპაზონშია." წერს კორი ქუინი. ხოლო EC2-ისთვის სწორი ზომის შეფასება შეიძლება ცუდი გადაწყვეტილება იყოსYAML ფაილში Kubernetes-ის რესურსის ზოგიერთი მოთხოვნის შეცვლა მარტივია და შეუძლია უზარმაზარი დანაზოგის მოტანა.

მაგრამ ჩვენ ნამდვილად გვინდა, რომ ადამიანებმა შეცვალონ მნიშვნელობები YAML ფაილებში? არა, მანქანებს ეს ბევრად უკეთ შეუძლიათ! კუბერნეტები ვერტიკალური პოდის ავტოსკალერი (VPA) სწორედ ამას აკეთებს: ადაპტირებს რესურსების მოთხოვნებს და შეზღუდვებს სამუშაო დატვირთვის მიხედვით. აქ არის პრომეთეს CPU მოთხოვნების მაგალითი გრაფიკი (თხელი ლურჯი ხაზი), რომელიც ადაპტირებულია VPA-ს მიერ დროთა განმავლობაში:

Zalando იყენებს VPA-ს ყველა თავის კლასტერში ინფრასტრუქტურის კომპონენტებისთვის. არაკრიტიკულ აპლიკაციებს ასევე შეუძლიათ გამოიყენონ VPA.

Goldilocks Fairwind-ისგან არის ინსტრუმენტი, რომელიც ქმნის VPA-ს თითოეული განლაგებისთვის სახელების სივრცეში და შემდეგ აჩვენებს VPA რეკომენდაციას მის დაფაზე. მას შეუძლია დაეხმაროს დეველოპერებს დააყენონ სწორი CPU/მეხსიერების მოთხოვნები თავიანთი აპლიკაციებისთვის:

პატარა დავწერე ბლოგპოსტი VPA-ს შესახებ 2019 წელს და ცოტა ხნის წინ CNCF საბოლოო მომხმარებლის საზოგადოებამ განიხილა VPA საკითხი.

EC2 Spot ინსტანციების გამოყენება

დაბოლოს, რაც არანაკლებ მნიშვნელოვანია, AWS EC2 ხარჯები შეიძლება შემცირდეს Spot ინსტანციების გამოყენებით Kubernetes-ის მუშა კვანძებად [3]. ადგილზე ინსტანციები ხელმისაწვდომია 90%-მდე ფასდაკლებით მოთხოვნის ფასებთან შედარებით. Kubernetes-ის გაშვება EC2 Spot-ზე კარგი კომბინაციაა: თქვენ უნდა მიუთითოთ რამდენიმე სხვადასხვა ტიპის ინსტანცია უფრო მაღალი ხელმისაწვდომობისთვის, რაც იმას ნიშნავს, რომ შეგიძლიათ მიიღოთ უფრო დიდი კვანძი იმავე ან დაბალ ფასად, ხოლო გაზრდილი სიმძლავრე შეიძლება გამოყენებულ იქნას კონტეინერირებული Kubernetes დატვირთვით.

როგორ გავუშვათ Kubernetes EC2 Spot-ზე? არსებობს რამდენიმე ვარიანტი: გამოიყენეთ მესამე მხარის სერვისი, როგორიცაა SpotInst (ახლა ეწოდება "Spot", არ მკითხოთ რატომ), ან უბრალოდ დაამატეთ Spot AutoScalingGroup (ASG) თქვენს კლასტერში. მაგალითად, აქ არის CloudFormation სნიპეტი "ტევადობის ოპტიმიზებული" 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-ის გამოყენების შესახებ:

• თქვენ უნდა გაუმკლავდეთ Spot ტერმინალებს, მაგალითად, კვანძის შერწყმა, როდესაც ინსტანცია შეჩერებულია
• Zalando იყენებს ჩანგალი ოფიციალური კლასტერული ავტოსკალირება კვანძების აუზის პრიორიტეტებით
• წერტილოვანი კვანძები შეიძლება აიძულოს მიიღეთ სამუშაო დატვირთვების „რეგისტრაცია“ Spot-ში გასაშვებად

რეზიუმე

იმედი მაქვს, რომ თქვენთვის წარმოდგენილი რამდენიმე ინსტრუმენტი სასარგებლო იქნება თქვენი ღრუბლოვანი გადასახადის შესამცირებლად. თქვენ შეგიძლიათ იპოვოთ სტატიის შინაარსის უმეტესი ნაწილი ასევე აქ ჩემი საუბარი DevOps Gathering 2019-ზე YouTube-ზე და სლაიდებში.

რა არის თქვენი საუკეთესო პრაქტიკა Kubernetes-ზე ღრუბლის ხარჯების დაზოგვისთვის? გთხოვთ შემატყობინოთ მისამართზე Twitter (@try_except_).

[1] სინამდვილეში, 3-ზე ნაკლები vCPU დარჩება გამოსაყენებელი, რადგან კვანძის გამტარუნარიანობა მცირდება რეზერვირებული სისტემის რესურსებით. Kubernetes განასხვავებს ფიზიკურ კვანძის სიმძლავრესა და "მოწოდებულ" რესურსებს (კვანძის გამოყოფა).

[2] გაანგარიშების მაგალითი: ერთი m5.large ინსტანცია 8 გიბ მეხსიერებით არის ~$84 ​​თვეში (eu-central-1, On-Demand), ე.ი. 1/8 კვანძის დაბლოკვა დაახლოებით 10$/თვეშია.

[3] კიდევ ბევრი გზა არსებობს თქვენი EC2 გადასახადის შესამცირებლად, როგორიცაა რეზერვირებული ინსტანციები, შემნახველი გეგმა და ა.შ. - ამ თემებს აქ არ გავაშუქებ, მაგრამ თქვენ აუცილებლად უნდა გაითვალისწინოთ ისინი!

შეიტყვეთ მეტი კურსის შესახებ.

წყარო: www.habr.com