AWS पर कुबेरनेट्स क्लाउड लागत पर बचत करें

पाठ्यक्रम की शुरुआत की पूर्व संध्या पर लेख का अनुवाद तैयार किया गया था "कुबेरनेट्स पर आधारित बुनियादी ढांचा मंच".

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

मैंने यह लेख AWS के लिए Kubernetes को ध्यान में रखकर लिखा है, लेकिन यह (लगभग) अन्य क्लाउड प्रदाताओं पर बिल्कुल उसी तरह लागू होगा। मैं मान रहा हूं कि आपके क्लस्टर में पहले से ही ऑटोस्केलिंग कॉन्फ़िगर है (क्लस्टर-ऑटोस्केलर). संसाधनों को हटाने और अपनी तैनाती को कम करने से केवल आपके पैसे बचेंगे यदि यह आपके कार्यकर्ता नोड्स (EC2 उदाहरण) के बेड़े को भी कम कर देगा।

यह लेख कवर करेगा:

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

अप्रयुक्त संसाधनों की सफाई

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

(हेनिंग जैकब्स:
झिज़ा:
(उद्धरण) कोरी क्विन:
मिथक: आपका AWS खाता आपके उपयोगकर्ताओं की संख्या का एक कार्य है।
तथ्य: आपका AWS स्कोर आपके पास मौजूद इंजीनियरों की संख्या पर निर्भर करता है।

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

कुबेरनेट्स चौकीदार (क्यूब-जेनिटर) आपके क्लस्टर को साफ करने में मदद करता है। वैश्विक और स्थानीय उपयोग दोनों के लिए चौकीदार विन्यास लचीला है:

• क्लस्टर-व्यापी नियम पीआर/परीक्षण परिनियोजन के लिए अधिकतम जीवन-समय (टीटीएल) को परिभाषित कर सकते हैं।
• व्यक्तिगत संसाधनों को जेनिटर/टीटीएल के साथ एनोटेट किया जा सकता है, उदाहरण के लिए 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

बढ़ती लागत का एक अन्य स्रोत लगातार मात्रा (एडब्ल्यूएस ईबीएस) है। Kubernetes StatefulSet को हटाने से इसके लगातार वॉल्यूम (PVC - PersistentVolumeClaim) नहीं हटते। अप्रयुक्त ईबीएस वॉल्यूम के परिणामस्वरूप आसानी से प्रति माह सैकड़ों डॉलर की लागत आ सकती है। Kubernetes Janitor में अप्रयुक्त पीवीसी को साफ करने की सुविधा है। उदाहरण के लिए, यह नियम उन सभी पीवीसी को हटा देगा जो किसी मॉड्यूल द्वारा माउंट नहीं किए गए हैं और जिन्हें स्टेटफुलसेट या क्रोनजॉब द्वारा संदर्भित नहीं किया गया है:

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

कुबेरनेट्स जेनिटर आपके क्लस्टर को साफ रखने और क्लाउड कंप्यूटिंग लागत को धीरे-धीरे बढ़ने से रोकने में आपकी मदद कर सकता है। परिनियोजन और कॉन्फ़िगरेशन निर्देशों के लिए, अनुसरण करें README क्यूब-चौकीदार.

गैर-कार्य घंटों के दौरान स्केलिंग कम करें

परीक्षण और स्टेजिंग सिस्टम आमतौर पर केवल व्यावसायिक घंटों के दौरान संचालन के लिए आवश्यक होते हैं। कुछ उत्पादन अनुप्रयोगों, जैसे बैक ऑफिस/एडमिन टूल्स को भी केवल सीमित उपलब्धता की आवश्यकता होती है और उन्हें रातोंरात अक्षम किया जा सकता है।

कुबेरनेट्स डाउनस्केलर (क्यूब-डाउनस्केलर) उपयोगकर्ताओं और ऑपरेटरों को गैर-कार्य घंटों के दौरान सिस्टम को छोटा करने की अनुमति देता है। परिनियोजन और स्टेटफुलसेट शून्य प्रतिकृतियों तक स्केल कर सकते हैं। क्रॉनजॉब्स को निलंबित किया जा सकता है. कुबेरनेट्स डाउनस्केलर को संपूर्ण क्लस्टर, एक या अधिक नामस्थान या व्यक्तिगत संसाधनों के लिए कॉन्फ़िगर किया गया है। आप या तो "निष्क्रिय समय" या, इसके विपरीत, "कार्य समय" निर्धारित कर सकते हैं। उदाहरण के लिए, रातों और सप्ताहांतों के दौरान स्केलिंग को यथासंभव कम करने के लिए:

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 क्यूब-डाउनस्केलर, यदि आप परिनियोजन निर्देशों और अतिरिक्त विकल्पों में रुचि रखते हैं।

क्षैतिज ऑटोस्केलिंग का उपयोग करें

कई एप्लिकेशन/सेवाएं गतिशील लोडिंग पैटर्न से निपटती हैं: कभी-कभी उनके मॉड्यूल निष्क्रिय होते हैं, और कभी-कभी वे पूरी क्षमता पर काम करते हैं। अधिकतम पीक लोड से निपटने के लिए पॉड के स्थायी बेड़े का संचालन करना किफायती नहीं है। कुबेरनेट्स एक संसाधन में क्षैतिज ऑटो-स्केलिंग का समर्थन करता है क्षैतिजपॉडऑटोस्केलर (एचपीए)। सीपीयू का उपयोग अक्सर स्केलिंग के लिए एक अच्छा संकेतक होता है:

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

ज़ालैंडो ने स्केलिंग के लिए कस्टम मेट्रिक्स को आसानी से जोड़ने के लिए एक घटक बनाया है: क्यूब मेट्रिक्स एडाप्टर (क्यूब-मेट्रिक्स-एडेप्टर) कुबेरनेट्स के लिए एक सामान्य मेट्रिक्स एडाप्टर है जो पॉड्स के क्षैतिज ऑटोस्केलिंग के लिए कस्टम और बाहरी मेट्रिक्स एकत्र और सेवा कर सकता है। यह प्रोमेथियस मेट्रिक्स, एसक्यूएस कतार और अन्य सेटिंग्स के आधार पर स्केलिंग का समर्थन करता है। उदाहरण के लिए, अपनी तैनाती को एक कस्टम मीट्रिक पर स्केल करने के लिए जिसे एप्लिकेशन द्वारा 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

स्टेटलेस सेवाओं की दक्षता में सुधार के लिए एचपीए के साथ क्षैतिज ऑटोस्केलिंग को कॉन्फ़िगर करना डिफ़ॉल्ट क्रियाओं में से एक होना चाहिए। Spotify के पास HPA के लिए उनके अनुभव और अनुशंसाओं के साथ एक प्रस्तुति है: अपनी तैनाती को मापें, अपने बटुए को नहीं.

संसाधन ओवरबुकिंग कम करें

कुबेरनेट्स वर्कलोड "संसाधन अनुरोधों" के माध्यम से अपनी सीपीयू/मेमोरी आवश्यकताओं को निर्धारित करते हैं। सीपीयू संसाधनों को वर्चुअल कोर या अधिक सामान्यतः "मिलीकोर्स" में मापा जाता है, उदाहरण के लिए 500 मीटर का मतलब 50% वीसीपीयू है। मेमोरी संसाधनों को बाइट्स में मापा जाता है, और सामान्य प्रत्ययों का उपयोग किया जा सकता है, जैसे 500Mi, जिसका अर्थ है 500 मेगाबाइट। संसाधन अनुरोध वर्कर नोड्स पर क्षमता को "लॉक" करते हैं, जिसका अर्थ है कि 1000 वीसीपीयू वाले नोड पर 4 मीटर सीपीयू अनुरोध वाला एक पॉड अन्य पॉड के लिए केवल 3 वीसीपीयू उपलब्ध छोड़ेगा। [1]

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

कुबेरनेट्स संसाधन रिपोर्ट (क्यूब-संसाधन-रिपोर्ट) अतिरिक्त भंडार प्रदर्शित करता है और बचत क्षमता निर्धारित करने में आपकी सहायता कर सकता है:

कुबेरनेट्स संसाधन रिपोर्ट एप्लिकेशन और कमांड द्वारा एकत्र किए गए अतिरिक्त को दर्शाता है। यह आपको ऐसे स्थान ढूंढने की अनुमति देता है जहां संसाधन की मांग को कम किया जा सकता है। जेनरेट की गई HTML रिपोर्ट केवल संसाधन उपयोग का एक स्नैपशॉट प्रदान करती है। पर्याप्त संसाधन अनुरोध निर्धारित करने के लिए आपको समय के साथ सीपीयू/मेमोरी उपयोग को देखना चाहिए। यहां "सामान्य" सीपीयू-भारी सेवा के लिए ग्राफाना चार्ट दिया गया है: सभी पॉड्स 3 अनुरोधित सीपीयू कोर से काफी कम उपयोग कर रहे हैं:

सीपीयू अनुरोध को 3000 मीटर से घटाकर ~400 मीटर करने से अन्य कार्यभार के लिए संसाधन मुक्त हो जाते हैं और क्लस्टर छोटा हो जाता है।

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

लेकिन क्या हम सचमुच चाहते हैं कि लोग YAML फ़ाइलों में मान बदलें? नहीं, मशीनें इसे बहुत बेहतर ढंग से कर सकती हैं! कुबेरनेट्स वर्टिकल पॉड ऑटोस्केलर (वीपीए) बस यही करता है: कार्यभार के अनुसार संसाधन अनुरोधों और बाधाओं को अनुकूलित करता है। समय के साथ वीपीए द्वारा अनुकूलित प्रोमेथियस सीपीयू अनुरोधों (पतली नीली रेखा) का एक उदाहरण ग्राफ यहां दिया गया है:

ज़ालैंडो अपने सभी समूहों में वीपीए का उपयोग करता है बुनियादी ढांचे के घटकों के लिए. गैर-महत्वपूर्ण एप्लिकेशन भी वीपीए का उपयोग कर सकते हैं।

गोल्डीलॉक्स फेयरविंड एक उपकरण है जो नेमस्पेस में प्रत्येक परिनियोजन के लिए एक वीपीए बनाता है और फिर अपने डैशबोर्ड पर एक वीपीए अनुशंसा प्रदर्शित करता है। यह डेवलपर्स को उनके अनुप्रयोगों के लिए सही सीपीयू/मेमोरी अनुरोध सेट करने में मदद कर सकता है:

मैंने एक छोटा सा लिखा वीपीए के बारे में ब्लॉगपोस्ट 2019 में, और हाल ही में सीएनसीएफ अंतिम उपयोगकर्ता समुदाय ने वीपीए मुद्दे पर चर्चा की.

EC2 स्पॉट इंस्टेंस का उपयोग करना

अंतिम लेकिन महत्वपूर्ण बात, कुबेरनेट्स वर्कर नोड्स के रूप में स्पॉट इंस्टेंस का उपयोग करके AWS EC2 लागत को कम किया जा सकता है [3]. ऑन-डिमांड कीमतों की तुलना में स्पॉट इंस्टेंसेस 90% तक की छूट पर उपलब्ध हैं। EC2 स्पॉट पर Kubernetes चलाना एक अच्छा संयोजन है: आपको उच्च उपलब्धता के लिए कई अलग-अलग उदाहरण प्रकार निर्दिष्ट करने की आवश्यकता है, जिसका अर्थ है कि आप समान या कम कीमत के लिए एक बड़ा नोड प्राप्त कर सकते हैं, और बढ़ी हुई क्षमता का उपयोग कंटेनरीकृत Kubernetes वर्कलोड द्वारा किया जा सकता है।

EC2 स्पॉट पर कुबेरनेट्स कैसे चलाएं? कई विकल्प हैं: SpotInst (जिसे अब "Spot" कहा जाता है, मुझसे इसका कारण न पूछें) जैसी तृतीय पक्ष सेवा का उपयोग करें, या बस अपने क्लस्टर में एक Spot AutoScalingGroup (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"

कुबेरनेट्स के साथ स्पॉट का उपयोग करने पर कुछ नोट्स:

• आपको स्पॉट टर्मिनेशन को संभालने की आवश्यकता है, उदाहरण के लिए इंस्टेंस बंद होने पर नोड को मर्ज करके
• ज़ालैंडो उपयोग करता है काँटा नोड पूल प्राथमिकताओं के साथ आधिकारिक क्लस्टर ऑटोस्केलिंग
• स्पॉट नोड्स मजबूर किया जा सकता है स्पॉट में चलाने के लिए कार्यभार का "पंजीकरण" स्वीकार करें

सारांश

मुझे आशा है कि आपको प्रस्तुत किए गए कुछ उपकरण आपके क्लाउड बिल को कम करने में उपयोगी लगेंगे। आप लेख की अधिकांश सामग्री यहां भी पा सकते हैं यूट्यूब और स्लाइड्स पर डेवऑप्स गैदरिंग 2019 में मेरी बातचीत.

कुबेरनेट्स पर क्लाउड लागत बचाने के लिए आपकी सर्वोत्तम प्रथाएँ क्या हैं? कृपया मुझे यहां बताएं ट्विटर (@try_except_).

[1] वास्तव में, 3 से कम वीसीपीयू उपयोग योग्य रहेंगे क्योंकि आरक्षित सिस्टम संसाधनों द्वारा नोड का थ्रूपुट कम हो जाता है। कुबेरनेट्स भौतिक नोड क्षमता और "प्रावधानित" संसाधनों के बीच अंतर करता है (नोड आवंटन योग्य).

[2] गणना उदाहरण: 5 GiB मेमोरी वाला एक m8.बड़ा उदाहरण ~$84 ​​​​प्रति माह (ईयू-सेंट्रल-1, ऑन-डिमांड) है, यानी। 1/8 नोड को ब्लॉक करना लगभग ~$10/माह है।

[3] आपके EC2 बिल को कम करने के और भी कई तरीके हैं, जैसे आरक्षित उदाहरण, बचत योजना, आदि - मैं उन विषयों को यहां कवर नहीं करूंगा, लेकिन आपको निश्चित रूप से उन पर गौर करना चाहिए!

कोर्स के बारे में और जानें।

स्रोत: www.habr.com