एक सामान्य स्थिति: आपके पास कई एप्लिकेशन हैं, उनमें से एक का दिन में एक पीक लोड है, और अन्य घंटों में कोई भी इसे एक्सेस नहीं करता है (या इसे एक्सेस किया जाता है, लेकिन शायद ही कभी); जबकि अन्य अनुप्रयोग रात में क्लस्टर पावर का उपयोग कर सकते हैं। ऐसे अनुप्रयोगों के एक उदाहरण के रूप में, हम वेब सेवाओं, कुछ डेटा हैंडलर का हवाला दे सकते हैं।

हमेशा की तरह, क्लस्टर संसाधन पर्याप्त नहीं हैं। आपको संसाधनों के उपयोग को अनुकूलित करने के लिए कुछ करना होगा, और इसके लिए कुबेरनेट्स महान हैं। इसमें एक क्षैतिज पॉड ऑटोस्कोलर है , जो आपको मैट्रिक्स के आधार पर अनुप्रयोगों को स्केल करने की अनुमति देता है।



मेट्रिक्स की आपूर्ति आमतौर पर मीट्रिक सर्वर द्वारा की जाती है। अगला, मैं प्रोमेथियस के साथ मीट्रिक सर्वर को बदलने के बारे में बात करूंगा (क्योंकि प्रोमेथियस उस डेटा को लागू करता है जो मीट्रिक सर्वर प्रदान करता है और हमें एक अतिरिक्त लिंक से छुटकारा मिलता है) और प्रोमेथियस से मीट्रिक के आधार पर कुबेरनेट्स में हमारे अनुप्रयोगों को कैसे स्केल किया जाए।

आरंभ करने के लिए, प्रोमेथियस ऑपरेटर को स्थापित करें। व्यक्तिगत रूप से, मैं तैयार किए गए मैनिफ़ेस्ट का उपयोग करता हूं। आप हेल्म के लिए चार्ट का उपयोग कर सकते हैं (लेकिन मैंने इसके प्रदर्शन की जांच नहीं की थी)। मीट्रिक सर्वर को भी हटा दें, यदि आपके पास एक है। उसके बाद, जांचें कि क्या सब कुछ उसी तरह काम करता है जैसा कि उसे करना चाहिए।

# kubectl get --raw "/apis/metrics.k8s.io/v1beta1/" | jq { "kind": "APIResourceList", "apiVersion": "v1", "groupVersion": "metrics.k8s.io/v1beta1", "resources": [ { "name": "nodes", "singularName": "", "namespaced": false, "kind": "NodeMetrics", "verbs": [ "get", "list" ] }, { "name": "pods", "singularName": "", "namespaced": true, "kind": "PodMetrics", "verbs": [ "get", "list" ] } ] } 

फिर इस निर्देशिका से मैनिफ़ेस्ट लागू करें । यह प्रोमेथियस-एडेप्टर स्थापित करेगा। मुझे एक चार्ट मिला जिसमें ये मैनिफेस्टो हैं, लेकिन इसकी जांच नहीं की। उसके बाद, आपको कमांड को सही ढंग से चलाना चाहिए:

 kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1" | jq 

(एक बहुत बड़ी सूची होगी, इसलिए मैं इसे यहां सूचीबद्ध नहीं करूंगा)

यह समझने के लिए कि क्या metrics.k8s.io और custom.metrics.k8s.io urls का अर्थ है, प्रलेखन आपकी सहायता कर सकता है।

अगर कुछ काम नहीं करता है, तो लॉग में हमेशा की तरह देखो। आप समस्याओं के समाधान के लिए भी देख सकते हैं ।

अब ऑटोसालिंग सेट करें।

मेरे पास एक एप्लिकेशन है जो बहुत सारे प्रोसेसर संसाधनों का उपभोग करता है और कतार में कार्य करता है। जैसे ही कतार का आकार कुछ सीमा से अधिक हो जाता है, मैं कतार में तेज़ी से आने वाले चूल्हों की संख्या को कतार में तेजी से संसाधित करना चाहता हूं। जैसे ही इसका आकार सीमा से कम हो जाता है, क्लस्टर संसाधनों को मुक्त किया जाना चाहिए।

प्रोमेथियस-एडेप्टर के लिए नियम कैसे लिखें, यह समझने के लिए, आपको इस दस्तावेज़ और इसके संबंधित पृष्ठों को ध्यान से पढ़ने की आवश्यकता है। मेरे साथ ऐसा ही दिखता है।

प्रोमेथियस से अनुरोध

 wqueue_tube_total_size{tube="dmload-legacy"} 

यह रिटर्न:

 wqueue_tube_total_size{endpoint="pprof-port",instance="10.116.2.237:8542",job="wqueue-pprof",namespace="default",pod="wqueue-b9fdd9455-66mwm",service="wqueue-pprof",tube="dmload-legacy"} 32 

और मैं प्रोमेथियस-एडेप्टर के लिए निम्नलिखित नियम लिखता हूं:

 - seriesQuery: wqueue_tube_total_size{tube="dmload-legacy"} resources: overrides: namespace: resource: namespace tube: resource: service name: {as: "wqueue_tube_total_size_dmload_legacy"} metricsQuery: wqueue_tube_total_size{tube="dmload-legacy"} 

यह ध्यान दिया जाना चाहिए कि मुझे service में tube पैरामीटर को मैप करना है, फिर विवरण में एचपीए का उपयोग करना है।

हेपा विन्यास:

 --- kind: HorizontalPodAutoscaler apiVersion: autoscaling/v2beta1 metadata: name: dmload-v3-legacy namespace: default spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: dmload-v3-legacy minReplicas: 2 maxReplicas: 20 metrics: - type: Object object: metricName: wqueue_tube_total_size_dmload_legacy target: apiVersion: v1 kind: Service name: dmload-legacy targetValue: 30 

यहां मैं wqueue_tube_total_size_dmload_legacy हूं कि जैसे ही wqueue_tube_total_size_dmload_legacy कतार में नौकरियों की संख्या 30 से अधिक हो जाती है, तब तक फली जोड़ें, जब तक कि 20 न हों, और अगर targetValue 30 से नीचे गिरता है, तो 2 तक कम करें।

हम लागू होते हैं और देखते हैं कि क्या होता है। मेरा सिस्टम कई दिनों तक काम करता है और फिलहाल यह सिर्फ चूल्हों की संख्या को कम करता है:

 # kubectl describe hpa dmload-v3-legacy Name: dmload-v3-legacy Namespace: default Labels: <none> Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"autoscaling/v2beta1","kind":"HorizontalPodAutoscaler","metadata":{"annotations":{},"name":"dmload-v3-legacy","namespace":"d... CreationTimestamp: Thu, 24 Jan 2019 16:16:43 +0300 Reference: Deployment/dmload-v3-legacy Metrics: ( current / target ) "wqueue_tube_total_size_dmload_legacy" on Service/dmload-legacy: 14 / 30 Min replicas: 2 Max replicas: 20 Deployment pods: 15 current / 14 desired Conditions: Type Status Reason Message ---- ------ ------ ------- AbleToScale True SucceededRescale the HPA controller was able to update the target scale to 14 ScalingActive True ValidMetricFound the HPA was able to successfully calculate a replica count from Service metric wqueue_tube_total_size_dmload_legacy ScalingLimited False DesiredWithinRange the desired count is within the acceptable range Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulRescale 59m (x14 over 40h) horizontal-pod-autoscaler New size: 13; reason: All metrics below target Normal SuccessfulRescale 59m (x13 over 40h) horizontal-pod-autoscaler New size: 12; reason: All metrics below target Normal SuccessfulRescale 57m (x14 over 40h) horizontal-pod-autoscaler New size: 11; reason: All metrics below target Normal SuccessfulRescale 56m (x14 over 40h) horizontal-pod-autoscaler New size: 10; reason: All metrics below target Normal SuccessfulRescale 56m (x11 over 38h) horizontal-pod-autoscaler New size: 8; reason: All metrics below target Normal SuccessfulRescale 55m (x6 over 36h) horizontal-pod-autoscaler New size: 7; reason: All metrics below target Normal SuccessfulRescale 47m (x103 over 40h) horizontal-pod-autoscaler (combined from similar events): New size: 20; reason: Service metric wqueue_tube_total_size_dmload_legacy above target Normal SuccessfulRescale 3m38s (x19 over 41h) horizontal-pod-autoscaler New size: 17; reason: All metrics below target Normal SuccessfulRescale 2m8s (x23 over 41h) horizontal-pod-autoscaler New size: 16; reason: All metrics below target Normal SuccessfulRescale 98s (x20 over 40h) horizontal-pod-autoscaler New size: 15; reason: All metrics below target Normal SuccessfulRescale 7s (x18 over 40h) horizontal-pod-autoscaler New size: 14; reason: All metrics below target 

वर्णित सब कुछ कुबेरनेट्स 1.13.2 पर किया गया था।

निष्कर्ष

इस संक्षिप्त लेख में, मैंने दिखाया कि प्रोमेथियस से मैट्रिक्स का उपयोग करके कुबेरनेट्स क्लस्टर में स्वचालित रूप से अनुप्रयोगों को कैसे स्केल किया जाए।

प्रोमेथियस-ऑपरेटर घटक कॉन्फ़िगर किए गए थे और आवश्यक मैनिफ़ेस्ट बनाए गए थे।

परिणामस्वरूप, कतार के आकार पर प्रोमेथियस से मीट्रिक के आधार पर, इस कतार को संसाधित करने वाली फली की संख्या को बढ़ाने या घटाने के लिए निकला।


(ग्राफ दिखाता है कि कैसे कतार के आकार के आधार पर श्रवणों की संख्या भिन्न होती है)

आपका ध्यान के लिए धन्यवाद!