AWS-də Kubernetes bulud xərclərinə qənaət edin

Məqalənin tərcüməsi kursun başlaması ərəfəsində hazırlanıb "Kubernetes-ə əsaslanan infrastruktur platforması".

Kubernetes ilə işləyərkən bulud xərclərinə necə qənaət etmək olar? Vahid düzgün həll yolu yoxdur, lakin bu məqalə resurslarınızı daha effektiv idarə etməyə və bulud hesablama xərclərini azaltmağa kömək edə biləcək bir neçə aləti təsvir edir.

Mən bu məqaləni AWS üçün Kubernetes ilə yazdım, lakin o (demək olar ki) digər bulud provayderlərinə də eyni şəkildə tətbiq olunacaq. Güman edirəm ki, klaster(lər)inizdə artıq avtomatik miqyas konfiqurasiya olunub (klaster-avtomiqyaslayıcı). Resursların silinməsi və yerləşdirmənin miqyasının azaldılması yalnız işçi qovşaqları parkınızı (EC2 nümunələri) azaldacaqsa, sizə pula qənaət edəcək.

Bu məqalə əhatə edəcək:

• istifadə olunmamış resursların təmizlənməsi (kube darvaza)
• Qeyri-iş saatlarında miqyasını azaldın (kub azaldıcı)
• üfüqi avtomatik ölçmə (HPA) istifadə edərək,
• həddindən artıq resurs ehtiyatının azaldılması (kube-resurs-hesabat, VPA)
• Spot nümunələrindən istifadə etməklə

İstifadə edilməmiş resursların təmizlənməsi

Sürətli bir mühitdə işləmək əladır. Biz texnoloji təşkilatlar istəyirik sürətləndirdi. Proqram təminatının daha sürətli çatdırılması həm də daha çox PR yerləşdirmələri, önizləmə mühitləri, prototiplər və analitik həllər deməkdir. Hər şey Kubernetes-də yerləşdirilib. Kimin sınaq yerləşdirmələrini əl ilə təmizləməyə vaxtı var? Bir həftəlik təcrübəni silməyi unutmaq asandır. Bulud hesabı bağlamağı unutduğumuz bir şeyə görə artacaq:

(Henning Jacobs:
Jiza:
(sitat) Corey Quinn:
Mif: AWS hesabınız sahib olduğunuz istifadəçilərin sayının funksiyasıdır.
Fakt: AWS balınız malik olduğunuz mühəndislərin sayından asılıdır.

İvan Kurnosov (cavabında):
Həqiqi fakt: AWS xalınız söndürməyi/silməyi unutduğunuz şeylərin sayının funksiyasıdır.)

Kubernetes Təmizləyici (kube-canitor) klasterinizi təmizləməyə kömək edir. Qapıçı konfiqurasiyası həm qlobal, həm də yerli istifadə üçün çevikdir:

• Klaster miqyasında qaydalar PR/test yerləşdirmələri üçün maksimum istifadə müddətini (TTL) müəyyən edə bilər.
• Fərdi resurslara janitor/ttl ilə şərh verilə bilər, məsələn 7 gündən sonra sünbül/prototipi avtomatik silmək üçün.

Ümumi qaydalar YAML faylında müəyyən edilmişdir. Onun yolu parametrdən keçir --rules-file kube-darvazada. Bütün ad boşluqlarını silmək üçün nümunə qayda budur -pr- iki gündən sonra adına:

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

Aşağıdakı nümunə 2020-ci ildə bütün yeni Yerləşdirmələr/StatefulSetlər üçün Yerləşdirmə və StatefulSet podlarında tətbiq etiketinin istifadəsini tənzimləyir, lakin eyni zamanda bir həftə ərzində bu etiket olmadan testlərin icrasına imkan verir:

- 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 ilə işləyən bir klasterdə 30 dəqiqə müddətinə məhdud bir demo işə salın:

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

Artan xərclərin başqa bir mənbəyi davamlı həcmlərdir (AWS EBS). Kubernetes StatefulSet-in silinməsi onun davamlı həcmlərini (PVC - PersistentVolumeClaim) silmir. İstifadə edilməmiş EBS həcmləri asanlıqla ayda yüzlərlə dollar xərclə nəticələnə bilər. Kubernetes Janitor istifadə olunmamış PVC-ləri təmizləmək xüsusiyyətinə malikdir. Məsələn, bu qayda modul tərəfindən quraşdırılmayan və StatefulSet və ya CronJob tərəfindən istinad edilməyən bütün PVC-ləri siləcək:

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

Kubernetes Janitor klasterinizi təmiz saxlamağa və bulud hesablama xərclərinin yavaş-yavaş yığılmasının qarşısını almağa kömək edə bilər. Yerləşdirmə və konfiqurasiya təlimatları üçün izləyin README kube təmizləyicisi.

Qeyri-iş saatlarında miqyasını azaldın

Test və quruluş sistemləri adətən yalnız iş saatlarında işləmək üçün tələb olunur. Arxa ofis/admin alətləri kimi bəzi istehsal proqramları da yalnız məhdud əlçatanlıq tələb edir və bir gecədə söndürülə bilər.

Kubernetes Downscaler (kube-downscaler) istifadəçilərə və operatorlara qeyri-iş saatlarında sistemin ölçüsünü azaltmağa imkan verir. Yerləşdirmələr və StatefulSets sıfır replikaya qədər ölçülə bilər. CronJobs dayandırıla bilər. Kubernetes Downscaler bütün klaster, bir və ya daha çox ad məkanı və ya fərdi resurslar üçün konfiqurasiya edilib. Siz ya “boş vaxt” və ya əksinə “iş vaxtı” təyin edə bilərsiniz. Məsələn, gecə və həftə sonları miqyasını mümkün qədər azaltmaq üçün:

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

Budur, həftə sonları klaster işçisi qovşaqlarının miqyasını artırmaq üçün qrafik:

~13-dən 4-ə qədər işçi qovşaqlarının kiçilməsi, şübhəsiz ki, AWS hesabında nəzərəçarpacaq fərq yaradır.

Bəs mən klasterin "faiz vaxtı" zamanı işləməliyəmsə nə etməli? Müəyyən yerləşdirmələr miqyasda azaldıcı/istisna et: həqiqi annotasiya əlavə etməklə miqyasdan həmişəlik xaric edilə bilər. Yerləşdirmələr YYYY-AA-GG SS:MM (UTC) formatında mütləq vaxt möhürü ilə azaldıcı/xarici annotasiyadan istifadə etməklə müvəqqəti olaraq xaric edilə bilər. Lazım gələrsə, annotasiya ilə pod yerləşdirməklə bütün klaster kiçilə bilər downscaler/force-uptimeməsələn, nginx blankını işə salmaqla:

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

Görmək README kub ölçüsünü azaldıcı, yerləşdirmə təlimatları və əlavə seçimlərlə maraqlanırsınızsa.

Üfüqi avtomatik miqyasdan istifadə edin

Bir çox proqram/xidmət dinamik yükləmə nümunəsi ilə məşğul olur: bəzən onların modulları boş qalır, bəzən isə tam gücü ilə işləyir. Maksimum pik yükün öhdəsindən gəlmək üçün daimi pods donanmasını idarə etmək qənaətcil deyil. Kubernetes resurs üzrə üfüqi avtomatik miqyaslaşdırmanı dəstəkləyir HorizontalPodAutoscaler (HPA). CPU istifadəsi tez-tez miqyaslandırma üçün yaxşı bir göstəricidir:

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, miqyaslama üçün xüsusi ölçüləri asanlıqla birləşdirmək üçün bir komponent yaratdı: Kube Metrik Adapteri (kube-metrics-adapter) qovşaqların üfüqi avtomatik miqyaslanması üçün fərdi və xarici ölçüləri toplayıb xidmət edə bilən Kubernetes üçün ümumi ölçü adapteridir. Prometheus ölçüləri, SQS növbələri və digər parametrlər əsasında miqyaslaşdırmanı dəstəkləyir. Məsələn, yerləşdirmənizi proqramın özü tərəfindən JSON kimi /metrics istifadə edərək təmsil olunan fərdi metrikaya qədər genişləndirmək üçün:

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 ilə üfüqi avtomatik ölçmənin konfiqurasiyası vətəndaşlığı olmayan xidmətlər üçün səmərəliliyin artırılması üçün defolt tədbirlərdən biri olmalıdır. Spotify-da HPA üçün təcrübə və tövsiyələri olan təqdimat var: cüzdanınızı deyil, yerləşdirmələrinizi genişləndirin.

Resursun həddən artıq sifarişini azaldın

Kubernetes iş yükləri onların CPU/yaddaş ehtiyaclarını “resurs sorğuları” vasitəsilə müəyyən edir. CPU resursları virtual nüvələrdə və ya daha çox "millicores" ilə ölçülür, məsələn, 500m 50% vCPU deməkdir. Yaddaş resursları baytlarla ölçülür və ümumi şəkilçilərdən istifadə edilə bilər, məsələn, 500Mi, bu da 500 meqabayt deməkdir. Resurs sorğuları işçi qovşaqlarında tutumun "kilidlənməsi" deməkdir, yəni 1000 vCPU-lu qovşaqda 4 m CPU sorğusu olan pod digər podlar üçün əlçatan yalnız 3 vCPU buraxacaq. [1]

Slack (artıq ehtiyat) tələb olunan resurslarla faktiki istifadə arasındakı fərqdir. Məsələn, 2 GiB yaddaş tələb edən, lakin yalnız 200 MiB istifadə edən podda ~1,8 GiB "artıq" yaddaş var. Həddindən artıq pul xərcləyir. Təxminən təxmin etmək olar ki, 1 GiB lazımsız yaddaş ayda ~10 dollara başa gəlir. [2]

Kubernetes Resurs Hesabatı (kube-resource-report) artıq ehtiyatları göstərir və qənaət potensialını müəyyən etməyə kömək edə bilər:

Kubernetes Resurs Hesabatı proqram və əmrlə yığılmış artıqlığı göstərir. Bu, resurs tələblərinin azaldıla biləcəyi yerləri tapmağa imkan verir. Yaradılmış HTML hesabatı yalnız resursdan istifadənin şəklini təqdim edir. Adekvat resurs sorğularını müəyyən etmək üçün zamanla CPU/yaddaş istifadəsinə baxmalısınız. Budur "tipik" CPU-ağır xidmət üçün Grafana diaqramı: bütün podlar tələb olunan 3 CPU nüvəsindən əhəmiyyətli dərəcədə az istifadə edir:

CPU tələbinin 3000m-dən ~400m-ə qədər azaldılması digər iş yükləri üçün resursları boşaldır və klasterin daha kiçik olmasına imkan verir.

"EC2 nümunələrinin orta CPU istifadəsi tez-tez birrəqəmli faiz diapazonunda dəyişir" Corey Quinn yazır. EC2 üçün isə düzgün ölçüsün qiymətləndirilməsi pis bir qərar ola bilərYAML faylında bəzi Kubernetes resurs sorğularını dəyişdirmək asandır və böyük qənaət gətirə bilər.

Ancaq həqiqətən insanların YAML fayllarında dəyərləri dəyişdirməsini istəyirik? Xeyr, maşınlar bunu daha yaxşı edə bilər! Kubernetes Şaquli Pod Autoscaler (VPA) məhz bunu edir: iş yükünə uyğun olaraq resurs sorğularını və məhdudiyyətləri uyğunlaşdırır. Zamanla VPA tərəfindən uyğunlaşdırılmış Prometheus CPU sorğularının (nazik mavi xətt) nümunə qrafiki:

Zalando bütün qruplarında VPA-dan istifadə edir infrastruktur komponentləri üçün. Kritik olmayan tətbiqlər də VPA-dan istifadə edə bilər.

Goldilocks from Fairwind, ad məkanında hər yerləşdirmə üçün VPA yaradan və sonra idarə panelində VPA tövsiyəsini göstərən bir vasitədir. O, tərtibatçılara tətbiqləri üçün düzgün CPU/yaddaş sorğularını təyin etməyə kömək edə bilər:

kiçik yazdım VPA haqqında blogpost 2019-cu ildə və bu yaxınlarda CNCF Son İstifadəçi İcması VPA məsələsini müzakirə etdi.

EC2 Spot Nümunələrindən istifadə

Nəhayət, AWS EC2 xərcləri Kubernetes işçi qovşaqları kimi Spot nümunələrindən istifadə etməklə azaldıla bilər. [3]. Spot nümunələri On-Demand qiymətləri ilə müqayisədə 90%-ə qədər endirimlə əldə etmək mümkündür. EC2 Spot-da Kubernetes-in işlədilməsi yaxşı kombinasiyadır: daha yüksək əlçatanlıq üçün bir neçə fərqli nümunə növünü təyin etməlisiniz, yəni eyni və ya daha aşağı qiymətə daha böyük node əldə edə bilərsiniz və artan tutum konteynerləşdirilmiş Kubernetes iş yükləri tərəfindən istifadə edilə bilər.

Kubernetes-i EC2 Spot-da necə işə salmaq olar? Bir neçə variant var: SpotInst kimi üçüncü tərəf xidmətindən istifadə edin (indi "Spot" adlanır, səbəbini soruşmayın) və ya sadəcə olaraq klasterinizə Spot AutoScalingGroup (ASG) əlavə edin. Məsələn, burada çoxsaylı nümunə növləri ilə "tutum üçün optimallaşdırılmış" Spot ASG üçün CloudFormation fraqmenti var:

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 ilə Spot istifadəsinə dair bəzi qeydlər:

• Nöqtə sonlandırmalarını idarə etməlisiniz, məsələn, nümunə dayandırıldıqda qovşağı birləşdirərək
• Zalando istifadə edir çəngəl node hovuz prioritetləri ilə rəsmi klaster avtomatik miqyası
• Spot qovşaqları məcbur edilə bilər Spot-da işləmək üçün iş yüklərinin “qeydiyyatını” qəbul edin

Xülasə

Ümid edirəm ki, təqdim olunan alətlərdən bəzilərini bulud hesabınızı azaltmaq üçün faydalı tapacaqsınız. Məqalənin məzmununun çoxunu burada da tapa bilərsiniz YouTube-da və slaydlarda DevOps Gathering 2019-da çıxışım.

Kubernetes-də bulud xərclərinə qənaət etmək üçün ən yaxşı təcrübələriniz hansılardır? Zəhmət olmasa mənə bildirin Twitter (@try_except_).

[1] Əslində, 3-dən az vCPU istifadəyə yararlı qalacaq, çünki qovşağın ötürmə qabiliyyəti qorunan sistem resursları hesabına azalır. Kubernetes fiziki qovşaq tutumu ilə "təmin edilmiş" resursları fərqləndirir (Ayrılan Node).

[2] Hesablama nümunəsi: 5 GiB yaddaşa malik bir m8.large instansiya ayda ~84$ təşkil edir (eu-central-1, On-Demand), yəni. 1/8 qovşağının bloklanması ayda təxminən ~ $10 təşkil edir.

[3] EC2 qanun layihəsini azaltmağın daha bir çox yolu var, məsələn, Qorunan Nümunələr, Əmanət Planı və s. - Mən burada bu mövzuları əhatə etməyəcəyəm, lakin siz onlara mütləq nəzər salmalısınız!

Kurs haqqında ətraflı məlumat əldə edin.

Mənbə: www.habr.com