AWS मा Kubernetes क्लाउड लागतहरूमा बचत गर्नुहोस्

लेखको अनुवाद पाठ्यक्रमको सुरुवातको पूर्वसन्ध्यामा तयार गरिएको थियो "कुबेरनेटमा आधारित पूर्वाधार प्लेटफार्म".

Kubernetes सँग काम गर्दा क्लाउड लागतमा कसरी बचत गर्ने? त्यहाँ कुनै एकल सही समाधान छैन, तर यस लेखले धेरै उपकरणहरू वर्णन गर्दछ जसले तपाईंलाई तपाईंको स्रोतहरू अझ प्रभावकारी रूपमा व्यवस्थापन गर्न र तपाईंको क्लाउड कम्प्युटिङ लागतहरू कम गर्न मद्दत गर्न सक्छ।

मैले यो लेख AWS को लागि Kubernetes को साथ दिमागमा लेखेको छु, तर यो (लगभग) अन्य क्लाउड प्रदायकहरूमा ठ्याक्कै उस्तै तरिकाले लागू हुनेछ। म तपाईको क्लस्टर(हरू) मा पहिले नै अटोस्केलिंग कन्फिगर गरिएको छ भनी मान्दै छु (क्लस्टर-अटोस्केलर)। श्रोतहरू हटाउने र तपाईंको डिप्लोयमेन्ट घटाउनाले तपाईंको पैसा बचत गर्छ यदि यसले तपाईंको कार्यकर्ता नोडहरू (EC2 उदाहरणहरू) को फ्लीट पनि घटाउँछ भने।

यस लेखले कभर गर्नेछ:

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

अप्रयुक्त स्रोतहरू सफा गर्दै

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

(हेनिङ जेकब्स:
Zhiza:
(उद्धरणहरू) कोरी क्विन:
मिथक: तपाईको AWS खाता तपाईसँग भएका प्रयोगकर्ताहरूको संख्याको कार्य हो।
तथ्य: तपाईंको AWS स्कोर तपाईंसँग भएका इन्जिनियरहरूको संख्याको कार्य हो।

इवान कुर्नोसोभ (प्रतिक्रियामा):
वास्तविक तथ्य: तपाईको AWS स्कोर तपाईले असक्षम/मेटाउन बिर्सनु भएको चीजहरूको संख्याको प्रकार्य हो।)

Kubernetes चौकीदार (kube-janitor) ले तपाइँको क्लस्टर सफा गर्न मद्दत गर्दछ। चौकीदार कन्फिगरेसन दुबै विश्वव्यापी र स्थानीय प्रयोगको लागि लचिलो छ:

• क्लस्टर-वाइड नियमहरूले PR/परीक्षण डिप्लोयमेन्टहरूको लागि अधिकतम समय-टु-लाइभ (TTL) परिभाषित गर्न सक्छ।
• व्यक्तिगत स्रोतहरू चौकीदार/ttl सँग एनोटेट गर्न सकिन्छ, उदाहरणका लागि 7 दिन पछि स्वतः स्पाइक/प्रोटोटाइप हटाउन।

सामान्य नियमहरू YAML फाइलमा परिभाषित छन्। यसको मार्ग प्यारामिटर मार्फत पारित गरिएको छ --rules-file कुबे चौकीदारमा। यहाँ सबै नेमस्पेसहरू हटाउनको लागि एउटा उदाहरण नियम छ -pr- दुई दिन पछि नाम मा:

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

निम्न उदाहरणले २०२० मा सबै नयाँ डिप्लोयमेन्ट/स्टेटफुलसेटहरूका लागि डिप्लोयमेन्ट र स्टेटफुलसेट पोडहरूमा एप्लिकेसन लेबलको प्रयोगलाई नियमन गर्दछ, तर एकै समयमा यो लेबल बिना एक हप्ताको लागि परीक्षणहरू कार्यान्वयन गर्न अनुमति दिन्छ:

- 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

कुबे-जनिटर चलिरहेको क्लस्टरमा ३० मिनेटको लागि समय-सीमित डेमो चलाउनुहोस्:

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

बढ्दो लागतको अर्को स्रोत निरन्तर मात्रा (AWS EBS) हो। Kubernetes StatefulSet मेटाउनाले यसको निरन्तर भोल्युमहरू (PVC - PersistentVolumeClaim) मेटाउँदैन। अप्रयुक्त EBS भोल्युमहरू सजिलै प्रति महिना सयौं डलरको लागतमा परिणाम हुन सक्छ। Kubernetes Janitor सँग प्रयोग नगरिएका PVCs सफा गर्ने सुविधा छ। उदाहरणको लागि, यो नियमले सबै 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) ले प्रयोगकर्ता र अपरेटरहरूलाई गैर-कामका घण्टाहरूमा प्रणालीलाई मापन गर्न अनुमति दिन्छ। डिप्लोयमेन्टहरू र स्टेटफुलसेटहरूले शून्य प्रतिकृतिहरूमा मापन गर्न सक्छन्। 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) मा निरपेक्ष टाइमस्ट्याम्पको साथ डाउनस्केलर/exclude-until एनोटेसन प्रयोग गरेर अस्थायी रूपमा बहिष्कृत गर्न सकिन्छ। आवश्यक भएमा, एनोटेसनको साथ पोड डिप्लोय गरेर सम्पूर्ण क्लस्टरलाई फिर्ता मापन गर्न सकिन्छ 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) Kubernetes को लागि एक सामान्य मेट्रिक्स एडाप्टर हो जसले पोडहरूको तेर्सो अटोस्केलिंगको लागि अनुकूलन र बाह्य मेट्रिकहरू सङ्कलन गर्न र सेवा गर्न सक्छ। यसले प्रोमेथियस मेट्रिक्स, SQS लामहरू, र अन्य सेटिङहरूमा आधारित स्केलिंग समर्थन गर्दछ। उदाहरण को लागी, /metrics को प्रयोग मा 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 vCPU हरू मात्र छोड्नेछ। [1]

ढिलो (अतिरिक्त आरक्षित) अनुरोध गरिएको स्रोत र वास्तविक उपयोग बीचको भिन्नता हो। उदाहरणका लागि, 2 GiB मेमोरी अनुरोध गर्ने तर 200 MiB मात्र प्रयोग गर्ने पोडमा ~ 1,8 GiB "अतिरिक्त" मेमोरी हुन्छ। अतिरिक्त पैसा खर्च हुन्छ। एकले अनुमान गर्न सक्छ कि 1 GiB अनावश्यक मेमोरीको लागत प्रति महिना ~$10 हुन्छ। [2]

Kubernetes संसाधन रिपोर्ट (kube-resource-report) ले अतिरिक्त रिजर्भहरू देखाउँछ र तपाईंलाई बचत क्षमता निर्धारण गर्न मद्दत गर्न सक्छ:

Kubernetes संसाधन रिपोर्ट एप्लिकेसन र कमाण्ड द्वारा एकत्रित अतिरिक्त देखाउँछ। यसले तपाईंलाई स्थानहरू फेला पार्न अनुमति दिन्छ जहाँ स्रोत मागहरू कम गर्न सकिन्छ। उत्पन्न HTML प्रतिवेदनले स्रोतको प्रयोगको स्न्यापसट मात्र प्रदान गर्दछ। तपाईंले पर्याप्त स्रोत अनुरोधहरू निर्धारण गर्न समयको साथ CPU/मेमोरी प्रयोगलाई हेर्नु पर्छ। यहाँ "विशिष्ट" CPU-भारी सेवाको लागि Grafana चार्ट छ: सबै पोडहरूले 3 अनुरोधित CPU कोरहरू भन्दा कम प्रयोग गरिरहेका छन्:

CPU अनुरोधलाई 3000m बाट ~ 400m मा घटाउनुले अन्य कार्यभारहरूको लागि स्रोतहरू खाली गर्छ र क्लस्टरलाई सानो हुन अनुमति दिन्छ।

"EC2 उदाहरणहरूको औसत CPU उपयोग प्रायः एकल-अङ्कको प्रतिशत दायरामा होवर हुन्छ," कोरी क्विन लेख्छन्। जबकि EC2 को लागी सही साइज अनुमान गर्नु खराब निर्णय हुन सक्छYAML फाइलमा केही Kubernetes स्रोत प्रश्नहरू परिवर्तन गर्न सजिलो छ र ठूलो बचत ल्याउन सक्छ।

तर के हामी वास्तवमै मानिसहरूले YAML फाइलहरूमा मानहरू परिवर्तन गर्न चाहन्छौं? होइन, मेसिनहरूले यो धेरै राम्रो गर्न सक्छन्! Kubernetes ठाडो पोड अटोस्केलर (VPA) ले त्यो मात्र गर्छ: कामको भार अनुसार संसाधन अनुरोधहरू र अवरोधहरू अनुकूलन गर्दछ। यहाँ Prometheus CPU अनुरोधहरूको उदाहरण ग्राफ (पातलो नीलो रेखा) VPA द्वारा समयसँगै अनुकूलित गरिएको छ:

Zalando ले यसको सबै क्लस्टरहरूमा VPA प्रयोग गर्दछ पूर्वाधार घटकहरूको लागि। गैर-महत्वपूर्ण अनुप्रयोगहरूले पनि VPA प्रयोग गर्न सक्छन्।

Goldilocks फेयरविन्डबाट एउटा उपकरण हो जसले नेमस्पेसमा प्रत्येक परिनियोजनको लागि VPA सिर्जना गर्दछ र त्यसपछि यसको ड्यासबोर्डमा VPA सिफारिस प्रदर्शन गर्दछ। यसले विकासकर्ताहरूलाई उनीहरूको अनुप्रयोगहरूको लागि सही CPU/मेमोरी अनुरोधहरू सेट गर्न मद्दत गर्न सक्छ:

मैले सानो लेखेँ VPA बारे ब्लगपोस्ट 2019 मा, र हालै मा CNCF अन्तिम प्रयोगकर्ता समुदायले VPA मुद्दा छलफल गर्यो.

EC2 स्पट उदाहरणहरू प्रयोग गर्दै

अन्तिम तर कम्तिमा होइन, AWS EC2 लागतहरू स्पट उदाहरणहरू Kubernetes कार्यकर्ता नोडहरूको रूपमा प्रयोग गरेर घटाउन सकिन्छ। [3]। अन-डिमांड मूल्यहरूको तुलनामा स्पट उदाहरणहरू 90% सम्म छुटमा उपलब्ध छन्। EC2 Spot मा Kubernetes चलाउनु राम्रो संयोजन हो: तपाईंले उच्च उपलब्धताका लागि धेरै फरक उदाहरण प्रकारहरू निर्दिष्ट गर्न आवश्यक छ, यसको मतलब तपाईंले समान वा कम मूल्यमा ठूलो नोड प्राप्त गर्न सक्नुहुन्छ, र बढेको क्षमता कन्टेनराइज्ड Kubernetes कार्यभारहरूद्वारा प्रयोग गर्न सकिन्छ।

EC2 स्पट मा Kubernetes कसरी चलाउने? त्यहाँ धेरै विकल्पहरू छन्: तेस्रो पक्ष सेवा प्रयोग गर्नुहोस् जस्तै SpotInst (अहिले "स्पट" भनिन्छ", मलाई किन न सोध्नुहोस्), वा तपाइँको क्लस्टरमा स्पट अटोस्केलिंग ग्रुप (ASG) थप्नुहोस्। उदाहरणका लागि, यहाँ एक "क्षमता-अनुकूलित" स्पट 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"

Kubernetes को साथ स्पट प्रयोग गर्ने केही नोटहरू:

• तपाईंले स्पट समाप्तिहरू ह्यान्डल गर्न आवश्यक छ, उदाहरणका लागि नोड मर्ज गरेर जब उदाहरण रोकिन्छ
• Zalando प्रयोग गर्दछ काँटा नोड पूल प्राथमिकताहरूसँग आधिकारिक क्लस्टर स्वत: स्केलिङ
• स्पट नोडहरू जबरजस्ती गर्न सकिन्छ स्पटमा चलाउनको लागि कार्यभारहरूको "दर्ताहरू" स्वीकार गर्नुहोस्

सारांश

मलाई आशा छ कि तपाईंले आफ्नो क्लाउड बिल घटाउनमा प्रस्तुत गरिएका केही उपकरणहरू उपयोगी पाउनुभयो। तपाईले धेरै जसो लेखका सामग्रीहरू पनि फेला पार्न सक्नुहुन्छ युट्युब र स्लाइडहरूमा DevOps Gathering 2019 मा मेरो कुराकानी.

Kubernetes मा क्लाउड लागत बचत गर्न को लागी तपाइँको उत्कृष्ट अभ्यासहरु के हो? कृपया मलाई थाहा दिनुहोस् ट्विटर (@try_except_).

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

[2] गणना उदाहरण: 5 GiB मेमोरी भएको एउटा m8.large उदाहरण ~$84 ​​प्रति महिना (eu-central-1, On-demand), अर्थात्। 1/8 नोड अवरुद्ध लगभग ~$10/महिना हो।

[3] तपाईंको EC2 बिल घटाउने धेरै तरिकाहरू छन्, जस्तै आरक्षित उदाहरणहरू, बचत योजना, इत्यादि। - म ती विषयहरू यहाँ समेट्ने छैन, तर तपाईंले निश्चित रूपमा तिनीहरूलाई हेर्नुपर्छ!

पाठ्यक्रम बारे थप जान्नुहोस्।

स्रोत: www.habr.com