AWS वर Kubernetes क्लाउड खर्चावर बचत करा

लेखाचा अनुवाद अभ्यासक्रम सुरू होण्याच्या आदल्या दिवशी तयार केला होता "कुबर्नेट्सवर आधारित पायाभूत सुविधा मंच".

Kubernetes सह काम करताना क्लाउड खर्चावर बचत कशी करावी? कोणताही एकच योग्य उपाय नाही, परंतु हा लेख अनेक साधनांचे वर्णन करतो जे तुम्हाला तुमची संसाधने अधिक प्रभावीपणे व्यवस्थापित करण्यात आणि तुमचा क्लाउड संगणन खर्च कमी करण्यात मदत करू शकतात.

मी हा लेख AWS साठी Kubernetes सह लिहिला आहे, परंतु तो इतर क्लाउड प्रदात्यांसाठी (जवळजवळ) अगदी त्याच प्रकारे लागू होईल. मी गृहीत धरत आहे की तुमच्या क्लस्टरमध्ये आधीच ऑटोस्केलिंग कॉन्फिगर केलेले आहे (क्लस्टर-ऑटोस्केलर). संसाधने काढून टाकणे आणि तुमची तैनाती कमी केल्याने तुमचे पैसे वाचतील जर ते तुमच्या कामगार नोड्सचा (EC2 उदाहरणे) फ्लीट देखील कमी करेल.

हा लेख कव्हर करेल:

• न वापरलेली संसाधने साफ करणे (कुबे-रक्षक)
• गैर-कामाच्या वेळेत स्केलिंग कमी करा (kube-downscaler)
• क्षैतिज ऑटोस्केलिंग (HPA) वापरणे,
• अत्याधिक संसाधन आरक्षण कमी करणे (kube-resource-report, VPA)
• स्पॉट उदाहरणे वापरणे

न वापरलेली संसाधने साफ करणे

वेगवान वातावरणात काम करणे उत्तम आहे. आम्हाला तंत्रज्ञान संस्था हव्या आहेत प्रवेगक. जलद सॉफ्टवेअर वितरण म्हणजे अधिक PR उपयोजन, पूर्वावलोकन वातावरण, प्रोटोटाइप आणि विश्लेषण उपाय. कुबर्नेट्सवर सर्व काही तैनात केले आहे. चाचणी उपयोजने व्यक्तिचलितपणे साफ करण्यासाठी कोणाकडे वेळ आहे? आठवडाभर जुना प्रयोग हटवण्याबद्दल विसरणे सोपे आहे. क्लाउड बिल आम्ही बंद करण्यास विसरलो आहोत अशा गोष्टीमुळे वाढेल:

(हेनिंग जेकब्स:
झिझा:
(कोट) कोरी क्विन:
गैरसमज: तुमचे AWS खाते हे तुमच्याकडे असलेल्या वापरकर्त्यांच्या संख्येचे कार्य आहे.
वस्तुस्थिती: तुमचा AWS स्कोअर हे तुमच्याकडे असलेल्या अभियंत्यांच्या संख्येचे कार्य आहे.

इव्हान कुर्नोसोव्ह (प्रतिसादात):
वास्तविक वस्तुस्थिती: तुमचा AWS स्कोअर हे तुम्ही अक्षम/हटवायला विसरलेल्या गोष्टींच्या संख्येचे कार्य आहे.)

कुबरनेटेस रखवालदार (कुबे-जॅनिटर) तुमचे क्लस्टर साफ करण्यास मदत करते. रखवालदार कॉन्फिगरेशन जागतिक आणि स्थानिक दोन्ही वापरासाठी लवचिक आहे:

• क्लस्टर-व्यापी नियम PR/चाचणी उपयोजनांसाठी जास्तीत जास्त वेळ-टू-लाइव्ह (TTL) परिभाषित करू शकतात.
• वैयक्तिक संसाधने janitor/ttl सह भाष्य केले जाऊ शकतात, उदाहरणार्थ 7 दिवसांनंतर स्पाइक/प्रोटोटाइप स्वयंचलितपणे काढण्यासाठी.

YAML फाइलमध्ये सामान्य नियम परिभाषित केले आहेत. त्याचा मार्ग पॅरामीटरमधून जातो --rules-file कुबे-रक्षक मध्ये. सर्व नेमस्पेसेस काढून टाकण्यासाठी येथे एक उदाहरण नियम आहे -pr- दोन दिवसांनंतर नावाने:

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

पुढील उदाहरण 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 मिनिटांसाठी मर्यादित डेमो चालवा:

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

वाढत्या खर्चाचा आणखी एक स्रोत म्हणजे पर्सिस्टंट व्हॉल्यूम (AWS EBS). Kubernetes StatefulSet हटवल्याने त्याचे पर्सिस्टंट व्हॉल्यूम (PVC - PersistentVolumeClaim) हटत नाहीत. न वापरलेले EBS व्हॉल्यूम सहजपणे दरमहा शेकडो डॉलर्सच्या खर्चास कारणीभूत ठरू शकते. कुबर्नेट्स जॅनिटरमध्ये न वापरलेले पीव्हीसी साफ करण्याचे वैशिष्ट्य आहे. उदाहरणार्थ, हा नियम सर्व 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 कुबे-रक्षक.

गैर-कामाच्या वेळेत स्केलिंग कमी करा

चाचणी आणि स्टेजिंग सिस्टम सामान्यत: फक्त व्यवसायाच्या वेळेत ऑपरेट करणे आवश्यक आहे. काही उत्पादन ऍप्लिकेशन्स, जसे की बॅक ऑफिस/अॅडमिन टूल्स, त्यांना फक्त मर्यादित उपलब्धता आवश्यक असते आणि ती रात्रभर अक्षम केली जाऊ शकतात.

कुबर्नेट्स डाउनस्केलर (kube-downscaler) वापरकर्त्यांना आणि ऑपरेटरना कामाच्या नसलेल्या तासांमध्ये सिस्टम कमी करण्यास अनुमती देते. डिप्लॉयमेंट्स आणि स्टेटफुलसेट्स शून्य प्रतिकृतीपर्यंत स्केल करू शकतात. 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) फॉरमॅटमध्ये परिपूर्ण टाइमस्टॅम्पसह डाउनस्केलर/वगळू-पर्यंत भाष्य वापरून उपयोजन तात्पुरते वगळले जाऊ शकतात. आवश्यक असल्यास, भाष्यासह पॉड उपयोजित करून संपूर्ण क्लस्टर परत मोजले जाऊ शकते 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-adapter) कुबर्नेट्ससाठी एक सामान्य मेट्रिक्स अॅडॉप्टर आहे जो पॉड्सच्या क्षैतिज ऑटोस्केलिंगसाठी कस्टम आणि बाह्य मेट्रिक्स एकत्रित आणि सर्व्ह करू शकतो. हे प्रोमिथियस मेट्रिक्स, 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: AverageValue

स्टेटलेस सेवांसाठी कार्यक्षमता सुधारण्यासाठी HPA सह क्षैतिज ऑटोस्केलिंग कॉन्फिगर करणे ही डीफॉल्ट क्रियांपैकी एक असावी. Spotify कडे त्यांच्या अनुभवासह आणि HPA साठी शिफारसी असलेले सादरीकरण आहे: तुमचे डिप्लॉयमेंट मोजा, ​​तुमचे वॉलेट नाही.

संसाधन ओव्हरबुकिंग कमी करा

Kubernetes वर्कलोड त्यांच्या CPU/मेमरी गरजा "संसाधन विनंत्या" द्वारे निर्धारित करतात. CPU संसाधने व्हर्च्युअल कोरमध्ये मोजली जातात किंवा अधिक सामान्यतः "मिलीकोअर" मध्ये मोजली जातात, उदाहरणार्थ 500m म्हणजे 50% vCPU. मेमरी संसाधने बाइट्समध्ये मोजली जातात आणि सामान्य प्रत्यय वापरले जाऊ शकतात, जसे की 500Mi, म्हणजे 500 मेगाबाइट्स. संसाधन विनंत्या कामगार नोड्सवर "लॉक" क्षमता, म्हणजे 1000 vCPU सह नोडवर 4m CPU विनंतीसह पॉड इतर पॉडसाठी फक्त 3 vCPUs उपलब्ध ठेवतील. [1]

स्लॅक (अतिरिक्त राखीव) विनंती केलेली संसाधने आणि वास्तविक वापर यातील फरक आहे. उदाहरणार्थ, एक पॉड जी 2 GiB मेमरीची विनंती करते परंतु केवळ 200 MiB वापरते ~ 1,8 GiB "अतिरिक्त" मेमरी असते. जादा पैसा खर्च होतो. एखादा अंदाजे अंदाज लावू शकतो की 1 GiB निरर्थक मेमरीची किंमत दरमहा ~$10 आहे. [2]

Kubernetes संसाधन अहवाल (kube-resource-report) अतिरिक्त साठा दाखवतो आणि बचत क्षमता निर्धारित करण्यात मदत करू शकतो:

Kubernetes संसाधन अहवाल ऍप्लिकेशन आणि कमांडद्वारे एकत्रित केलेले जादा दाखवते. हे तुम्हाला अशी ठिकाणे शोधण्याची परवानगी देते जिथे संसाधनांची मागणी कमी केली जाऊ शकते. व्युत्पन्न केलेला HTML अहवाल केवळ संसाधनाच्या वापराचा स्नॅपशॉट प्रदान करतो. पुरेशा संसाधन विनंत्या निर्धारित करण्यासाठी तुम्ही कालांतराने CPU/मेमरी वापर पहा. येथे "नमुनेदार" CPU-हेवी सेवेसाठी ग्राफाना चार्ट आहे: सर्व पॉड्स विनंती केलेल्या 3 CPU कोर पेक्षा लक्षणीयरीत्या कमी वापरत आहेत:

CPU विनंती 3000m वरून ~400m पर्यंत कमी केल्याने इतर वर्कलोड्ससाठी संसाधने मुक्त होतात आणि क्लस्टर लहान होऊ शकतात.

"EC2 उदाहरणांचा सरासरी CPU वापर अनेकदा एकल-अंकी टक्केवारी श्रेणीमध्ये फिरतो," कोरी क्विन लिहितात. EC2 साठी असताना योग्य आकाराचा अंदाज लावणे हा चुकीचा निर्णय असू शकतोYAML फाइलमध्ये काही कुबर्नेट्स रिसोर्स क्वेरी बदलणे सोपे आहे आणि मोठ्या प्रमाणात बचत करू शकते.

परंतु आम्हाला खरोखर लोकांनी YAML फायलींमध्ये मूल्ये बदलण्याची इच्छा आहे का? नाही, यंत्रे ते अधिक चांगले करू शकतात! कुबर्नेट्स अनुलंब पॉड ऑटोस्केलर (VPA) तेच करते: संसाधन विनंत्या आणि वर्कलोडनुसार मर्यादा स्वीकारते. VPA द्वारे कालांतराने रुपांतरित केलेल्या Prometheus CPU विनंत्यांचा (पातळ निळी रेषा) उदाहरण आलेख येथे आहे:

Zalando त्याच्या सर्व क्लस्टर्समध्ये VPA वापरते पायाभूत सुविधांच्या घटकांसाठी. नॉन-क्रिटिकल अॅप्लिकेशन्स देखील VPA वापरू शकतात.

गोल्डीलॉक्स फ्रॉम फेअरविंड हे एक साधन आहे जे नेमस्पेसमध्ये प्रत्येक उपयोजनासाठी VPA तयार करते आणि नंतर त्याच्या डॅशबोर्डवर VPA शिफारस प्रदर्शित करते. हे विकासकांना त्यांच्या अनुप्रयोगांसाठी योग्य CPU/मेमरी विनंत्या सेट करण्यात मदत करू शकते:

मी एक छोटेसे लिहिले VPA बद्दल ब्लॉगपोस्ट 2019 मध्ये आणि अलीकडे CNCF अंतिम वापरकर्ता समुदायाने VPA समस्येवर चर्चा केली.

EC2 स्पॉट उदाहरणे वापरणे

शेवटचे परंतु किमान नाही, कुबर्नेट्स वर्कर नोड्स म्हणून स्पॉट उदाहरणे वापरून AWS EC2 खर्च कमी केला जाऊ शकतो [3]. ऑन-डिमांड किमतींच्या तुलनेत स्पॉट उदाहरणे 90% पर्यंत सवलतीत उपलब्ध आहेत. EC2 Spot वर Kubernetes चालवणे हे एक चांगले संयोजन आहे: उच्च उपलब्धतेसाठी तुम्हाला अनेक भिन्न उदाहरण प्रकार निर्दिष्ट करावे लागतील, म्हणजे तुम्हाला समान किंवा कमी किमतीत मोठा नोड मिळू शकेल आणि वाढीव क्षमता कंटेनरीकृत Kubernetes वर्कलोड्सद्वारे वापरली जाऊ शकते.

EC2 Spot वर Kubernetes कसे चालवायचे? अनेक पर्याय आहेत: SpotInst सारखी तृतीय पक्ष सेवा वापरा (आता "स्पॉट" असे म्हणतात, मला का विचारू नका), किंवा तुमच्या क्लस्टरमध्ये फक्त एक Spot AutoScalingGroup (ASG) जोडा. उदाहरणार्थ, एकाधिक उदाहरण प्रकारांसह "क्षमता-अनुकूलित" स्पॉट 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 टर्मिनेशन हाताळण्‍याची आवश्‍यकता आहे, उदाहरणार्थ इंस्‍टंस थांबवल्‍यावर नोड विलीन करून
• Zalando वापरते काटा नोड पूल प्राधान्यांसह अधिकृत क्लस्टर ऑटोस्केलिंग
• स्पॉट नोड्स सक्ती केली जाऊ शकते स्पॉटमध्ये चालण्यासाठी वर्कलोडची "नोंदणी" स्वीकारा

सारांश

मला आशा आहे की तुमचे क्लाउड बिल कमी करण्यासाठी सादर केलेली काही साधने तुम्हाला उपयुक्त वाटतील. तुम्हाला लेखातील बहुतांश सामग्री येथे देखील मिळू शकते DevOps Gathering 2019 मधील माझे YouTube वर आणि स्लाईड्समध्ये बोलणे.

Kubernetes वर क्लाउड खर्च वाचवण्यासाठी तुमच्या सर्वोत्तम पद्धती कोणत्या आहेत? कृपया मला कळवा Twitter (@try_except_).

[1] खरेतर, 3 पेक्षा कमी vCPU वापरण्यायोग्य राहतील कारण नोडचे थ्रुपुट आरक्षित सिस्टम संसाधनाद्वारे कमी केले जाते. कुबर्नेट्स भौतिक नोड क्षमता आणि "तरतुदी" संसाधनांमध्ये फरक करतात (नोड वाटप करण्यायोग्य).

[2] गणना उदाहरण: 5 GiB मेमरी असलेले एक m8. मोठे उदाहरण ~$84 ​​प्रति महिना आहे (eu-central-1, ऑन-डिमांड), उदा. 1/8 नोड अवरोधित करणे अंदाजे ~$10/महिना आहे.

[3] तुमचे EC2 बिल कमी करण्याचे आणखी बरेच मार्ग आहेत, जसे की राखीव उदाहरणे, बचत योजना इ. - मी ते विषय येथे कव्हर करणार नाही, परंतु तुम्ही त्यामध्ये नक्कीच लक्ष द्यावे!

कोर्सबद्दल अधिक जाणून घ्या.

स्त्रोत: www.habr.com