क्यूबा में बीमा संसाधन

क्लस्टर संसाधन प्रबंधन हमेशा एक जटिल विषय होता है। उस उपयोगकर्ता के लिए संसाधनों को कॉन्फ़िगर करने की आवश्यकता को कैसे समझा जाए जो अपने अनुप्रयोगों को क्लस्टर में लागू करता है? शायद इसे स्वचालित करना आसान है?

समस्या का वर्णन

कुबेरनेट क्लस्टर प्रशासन के संदर्भ में संसाधन प्रबंधन एक महत्वपूर्ण कार्य है। लेकिन यह महत्वपूर्ण क्यों है अगर कुबेरनेट्स आपके लिए पूरी मेहनत करते हैं? क्योंकि यह नहीं है। कुबेरनेट आपको कई समस्याओं को हल करने के लिए सुविधाजनक उपकरण प्रदान करता है ... यदि आप इन उपकरणों का उपयोग करते हैं। अपने क्लस्टर में प्रत्येक फली के लिए, आप इसके कंटेनरों के लिए आवश्यक संसाधनों को निर्दिष्ट कर सकते हैं। और कुबेरनेट्स इस जानकारी का उपयोग क्लस्टर नोड्स में आपके आवेदन के उदाहरणों को वितरित करने के लिए करेंगे।

कुछ लोग कुबेरनेट पर संसाधन प्रबंधन को गंभीरता से लेते हैं। स्थैतिक अनुप्रयोगों के एक जोड़े के साथ हल्के से भरे क्लस्टर के लिए यह सामान्य है। लेकिन अगर आपके पास बहुत गतिशील क्लस्टर है तो क्या होगा? आवेदन कहाँ आते हैं और कहाँ जाते हैं, हर समय नाम स्थान कहाँ बनाए और मिटाए गए हैं? बड़ी संख्या में उपयोगकर्ताओं के साथ एक क्लस्टर जो अपना नाम स्थान बना सकता है और एप्लिकेशन को तैनात कर सकता है? खैर, इस मामले में, स्थिर और पूर्वानुमानित ऑर्केस्ट्रेशन के बजाय, आपके पास अनुप्रयोगों में यादृच्छिक दुर्घटनाओं का एक गुच्छा होगा, और कभी-कभी कुबेरनेट्स के घटकों में भी!

इस तरह के एक क्लस्टर का एक उदाहरण है:

आप "समाप्ति" स्थिति में 3 हार्ट्स देखते हैं। लेकिन यह आम तौर पर चूल्हों को हटाने के लिए नहीं है - वे इस स्थिति में फंस गए हैं क्योंकि उनके नोड पर कंटेनड डेमन को बहुत ही संसाधन-भूख ​​से मारा गया था।

संसाधनों की कमी को ठीक से संभालकर ऐसी समस्याओं को हल किया जा सकता है, लेकिन यह इस लेख का विषय नहीं है (एक अच्छा लेख है ), साथ ही संसाधनों के साथ सभी मुद्दों को हल करने के लिए चांदी की गोली नहीं।

इस तरह की समस्याओं का मुख्य कारण क्लस्टर में संसाधन प्रबंधन का गलत या अभाव है। और अगर इस तरह की समस्या तैनाती के लिए एक आपदा नहीं है, क्योंकि वे आसानी से एक नया काम कर रहे हैं, तो डेमनसेट जैसी संस्थाओं के लिए, या स्टेटफुलसेट के लिए और भी अधिक, ऐसे फ्रीज़ घातक होंगे और मैन्युअल हस्तक्षेप की आवश्यकता होगी।

आपके पास बहुत सारे सीपीयू और मेमोरी के साथ एक विशाल क्लस्टर हो सकता है। जब आप उचित संसाधन सेटिंग्स के बिना उस पर कई एप्लिकेशन चलाते हैं, तो एक मौका है कि सभी संसाधन-गहन पॉड्स को एक ही नोड पर रखा जाएगा। वे संसाधनों के लिए संघर्ष करेंगे, भले ही क्लस्टर के शेष नोड व्यावहारिक रूप से मुक्त रहें।

आप अक्सर कम महत्वपूर्ण मामलों को भी देख सकते हैं जहां कुछ एप्लिकेशन अपने पड़ोसियों से प्रभावित होते हैं। यहां तक ​​कि अगर इन "निर्दोष" अनुप्रयोगों के संसाधनों को सही ढंग से कॉन्फ़िगर किया गया था, तो एक भटकना उन्हें आकर मार सकता है। ऐसे परिदृश्य का एक उदाहरण:

1. आपका एप्लिकेशन 4 जीबी मेमोरी का अनुरोध करता है, लेकिन शुरू में केवल 1 जीबी लगता है।
2. संसाधन कॉन्फ़िगरेशन के बिना एक भटकना, उसी नोड को सौंपा गया है।
3. भटकने के तहत सभी उपलब्ध स्मृति का उपभोग करता है।
4. आपका एप्लिकेशन अधिक मेमोरी आवंटित करने और क्रैश करने का प्रयास कर रहा है क्योंकि कोई और अधिक नहीं है।

एक और काफी लोकप्रिय मामला पुनर्मूल्यांकन है। कुछ डेवलपर्स "केवल मामले में" प्रकट होने में बहुत बड़ा अनुरोध करते हैं और इन संसाधनों का उपयोग कभी नहीं करते हैं। परिणाम पैसे की बर्बादी है।

निर्णय सिद्धांत

आतंक! सच?
सौभाग्य से, कुबेरनेट्स डिफ़ॉल्ट संसाधन कॉन्फ़िगरेशन के साथ-साथ न्यूनतम और अधिकतम मूल्यों को निर्दिष्ट करके फली पर कुछ प्रतिबंध लगाने का एक तरीका प्रदान करता है। यह LimitRange ऑब्जेक्ट का उपयोग करके लागू किया गया है। LimitRange एक बहुत ही सुविधाजनक उपकरण है जब आपके पास सीमित संख्या में नामस्थान या उन्हें बनाने की प्रक्रिया पर पूर्ण नियंत्रण होता है। संसाधनों के उचित विन्यास के बिना भी, आपके अनुप्रयोग उनके उपयोग में सीमित होंगे। "निर्दोष", ठीक से ट्यून किए गए चूल्हे हानिकारक पड़ोसियों से सुरक्षित और संरक्षित होंगे। यदि कोई संसाधन कॉन्फ़िगरेशन के बिना लालची एप्लिकेशन को दिखाता है, तो यह एप्लिकेशन डिफ़ॉल्ट मान प्राप्त करेगा और संभवतः क्रैश हो जाएगा। और वह सब है! एप्लिकेशन अब किसी को भी साथ नहीं ले जाएगा।

इस प्रकार, हमारे पास श्रोताओं के लिए संसाधनों के विन्यास को नियंत्रित और बल देने के लिए एक उपकरण है, अब लगता है कि हम सुरक्षित हैं। तो? वास्तव में नहीं। तथ्य यह है कि, जैसा कि हमने पहले बताया था, हमारे नाम स्थान उपयोगकर्ताओं द्वारा बनाए जा सकते हैं, और इसलिए, LimitRange ऐसे नामस्थानों में मौजूद नहीं हो सकता है, क्योंकि इसे प्रत्येक नामस्थान में अलग से बनाया जाना चाहिए। इसलिए, हमें न केवल नामस्थान स्तर पर, बल्कि क्लस्टर स्तर पर भी कुछ चाहिए। लेकिन कुबेरनेट्स में अभी तक ऐसा कोई समारोह नहीं है।

इसीलिए मैंने इस समस्या का समाधान लिखने का फैसला किया। मुझे आप से मिलवाते हैं - लिमिट ऑपरेटर। यह ऑपरेटर SDK ढांचे के आधार पर बनाया गया एक ऑपरेटर है, जो ClusterLimit कस्टम संसाधन का उपयोग करता है और क्लस्टर में सभी "निर्दोष" अनुप्रयोगों को सुरक्षित करने में मदद करता है। इस ऑपरेटर का उपयोग करके, आप न्यूनतम मान कॉन्फ़िगरेशन का उपयोग करके सभी नामस्थानों के लिए डिफ़ॉल्ट मानों और संसाधन सीमाओं को नियंत्रित कर सकते हैं। यह आपको नाम चुनने के लिए कॉन्फ़िगरेशन को लागू करने के लिए वास्तव में चुनने की अनुमति देता है।

apiVersion: limit.myafq.com/v1alpha1 kind: ClusterLimit metadata: name: default-limit spec: namespaceSelector: matchLabels: limit: "limited" limitRange: limits: - type: Container max: cpu: "800m" memory: "1Gi" min: cpu: "100m" memory: "99Mi" default: cpu: "700m" memory: "900Mi" defaultRequest: cpu: "110m" memory: "111Mi" - type: Pod max: cpu: "2" memory: "2Gi" 

इस कॉन्फ़िगरेशन के साथ, ऑपरेटर केवल लेबल limit: limited साथ नामस्थान में एक LimitRange बनाएगा limit: limited । यह नामस्थानों के एक विशिष्ट समूह में अधिक कठोर प्रतिबंध प्रदान करने के लिए उपयोगी होगा। यदि namespaceSelector निर्दिष्ट नहीं है, तो ऑपरेटर सभी नामस्थानों पर LimitRange लागू करेगा। यदि आप किसी विशिष्ट नाम स्थान के लिए मैन्युअल रूप से LimitRange कॉन्फ़िगर करना चाहते हैं, तो आप एनोटेशन "limit.myafq.com/unlimited": true उपयोग कर सकते हैं "limit.myafq.com/unlimited": true यह ऑपरेटर को इस नाम स्थान को छोड़ने और स्वचालित रूप से LimitRange बनाने के लिए नहीं बताएगा।

ऑपरेटर का उपयोग करने के लिए उदाहरण स्क्रिप्ट:

• डिफ़ॉल्ट प्रतिबंधों के साथ और बिना नामस्थान के डिफ़ॉल्ट ClusterLimit बनाएं। चयनकर्ता - यह हर जगह लागू किया जाएगा।
• हल्के अनुप्रयोगों के साथ नामस्थानों के एक सेट के लिए, namespaceSelector के साथ एक अतिरिक्त, अधिक कठोर, क्लस्टर बनाएं। तदनुसार इन नामस्थानों पर लेबल लगाएं।
• बहुत संसाधन-गहन अनुप्रयोगों वाले एक नामस्थान पर, एनोटेशन को "सीमित करें ।yafq.com/unlimited": सही और डिफ़ॉल्ट क्लस्टलिमिट में निर्दिष्ट सीमा से अधिक व्यापक सीमाओं के साथ मैन्युअल रूप से सीमित करें।

एक नाम स्थान में कई LimitRange के बारे में जानने के लिए महत्वपूर्ण बात:
जब एक उप-नाम कई LimitRange के साथ बनाया जाता है, तो सबसे बड़ा चूक अपने संसाधनों को कॉन्फ़िगर करने के लिए लिया जाएगा। लेकिन LimitRange के सख्त के अनुसार अधिकतम और न्यूनतम मान की जाँच की जाएगी।

व्यावहारिक उदाहरण

ऑपरेटर सभी नेमस्पेस, क्लस्टरस्टरलिम्स, चाइल्ड लिमिटट्रंग्स में सभी परिवर्तनों को ट्रैक करेगा और मॉनिटर किए गए ऑब्जेक्ट्स में किसी भी बदलाव के साथ क्लस्टर की स्थिति के समन्वय की शुरुआत करेगा। आइए देखें कि यह व्यवहार में कैसे काम करता है।

बिना किसी प्रतिबंध के शुरू करने के लिए:

 ❯() kubectl run --generator=run-pod/v1 --image=bash bash pod/bash created ❯() kubectl get pod bash -o yaml apiVersion: v1 kind: Pod metadata: labels: run: bash name: bash namespace: default spec: containers: - image: bash name: bash resources: {} 

जैसा कि आप देख सकते हैं, "संसाधन" फ़ील्ड खाली है, जिसका अर्थ है कि यह उप कहीं भी लॉन्च किया जा सकता है।
अब हम पूरी तरह से उदार मूल्यों के साथ पूरे क्लस्टर के लिए डिफ़ॉल्ट क्लस्टर क्लस्टर बनायेंगे:

 apiVersion: limit.myafq.com/v1alpha1 kind: ClusterLimit metadata: name: default-limit spec: limitRange: limits: - type: Container max: cpu: "4" memory: "5Gi" default: cpu: "700m" memory: "900Mi" defaultRequest: cpu: "500m" memory: "512Mi" 

और नामस्थानों के सबसेट के लिए और भी कड़े:

 apiVersion: limit.myafq.com/v1alpha1 kind: ClusterLimit metadata: name: restrictive-limit spec: namespaceSelector: matchLabels: limit: "restrictive" limitRange: limits: - type: Container max: cpu: "800m" memory: "1Gi" default: cpu: "100m" memory: "128Mi" defaultRequest: cpu: "50m" memory: "64Mi" - type: Pod max: cpu: "2" memory: "2Gi" 

फिर उनमें नेमस्पेस और पॉड बनाएं कि यह कैसे काम करता है।
सामान्य प्रतिबंध के साथ सामान्य नाम स्थान:

 apiVersion: v1 kind: Namespace metadata: name: regular 

और थोड़ा अधिक सीमित नाम स्थान, कथा के अनुसार - हल्के अनुप्रयोगों के लिए:

 apiVersion: v1 kind: Namespace metadata: labels: limit: "restrictive" name: lightweight 

यदि आप नाम स्थान बनाने के तुरंत बाद ऑपरेटर के लॉग को देखते हैं, तो आप स्पॉइलर के नीचे कुछ ऐसा पा सकते हैं:

 {...,"msg":"Reconciling ClusterLimit","Triggered by":"/regular"} {...,"msg":"Creating new namespace LimitRange.","Namespace":"regular","LimitRange":"default-limit"} {...,"msg":"Updating namespace LimitRange.","Namespace":"regular","Name":"default-limit"} {...,"msg":"Reconciling ClusterLimit","Triggered by":"/lightweight"} {...,"msg":"Creating new namespace LimitRange.","Namespace":"lightweight","LimitRange":"default-limit"} {...,"msg":"Updating namespace LimitRange.","Namespace":"lightweight","Name":"default-limit"} {...,"msg":"Creating new namespace LimitRange.","Namespace":"lightweight","LimitRange":"restrictive-limit"} {...,"msg":"Updating namespace LimitRange.","Namespace":"lightweight","Name":"restrictive-limit"} 

जैसा कि आप देख सकते हैं, प्रत्येक नामस्थान के निर्माण ने नई LimitRange का निर्माण शुरू किया। एक अधिक सीमित नाम स्थान को दो सीमा-डिफ़ॉल्ट और अधिक सख्त मिले।

अब इन नामस्थानों में एक जोड़ी चूल्हा बनाने की कोशिश करते हैं।

 ❯() kubectl run --generator=run-pod/v1 --image=bash bash -n regular pod/bash created ❯() kubectl get pod bash -o yaml -n regular apiVersion: v1 kind: Pod metadata: annotations: kubernetes.io/limit-ranger: 'LimitRanger plugin set: cpu, memory request for container bash; cpu, memory limit for container bash' labels: run: bash name: bash namespace: regular spec: containers: - image: bash name: bash resources: limits: cpu: 700m memory: 900Mi requests: cpu: 500m memory: 512Mi 

जैसा कि आप देख सकते हैं, इस तथ्य के बावजूद कि हमने पॉड बनाने के तरीके को नहीं बदला है, संसाधन क्षेत्र अब भर गया है। आप LimitRanger द्वारा बनाई गई एनोटेशन को स्वचालित रूप से देख सकते हैं।

अब एक हल्के नामस्थान में बनाएँ:

 ❯() kubectl run --generator=run-pod/v1 --image=bash bash -n lightweight pod/bash created ❯() kubectl get pods -n lightweight bash -o yaml apiVersion: v1 kind: Pod metadata: annotations: kubernetes.io/limit-ranger: 'LimitRanger plugin set: cpu, memory request for container bash; cpu, memory limit for container bash' labels: run: bash name: bash namespace: lightweight spec: containers: - image: bash name: bash resources: limits: cpu: 700m memory: 900Mi requests: cpu: 500m memory: 512Mi 

कृपया ध्यान दें कि चूल्हा में संसाधन पिछले उदाहरण के समान हैं। ऐसा इसलिए है क्योंकि कई LimitRange के मामले में, पॉड बनाते समय कम सख्त डिफ़ॉल्ट मान का उपयोग किया जाएगा। लेकिन फिर हमें एक अधिक सीमित सीमा की आवश्यकता क्यों है? इसका उपयोग संसाधनों के अधिकतम और न्यूनतम मूल्यों की जांच के लिए किया जाएगा। प्रदर्शित करने के लिए, हम अपने सीमित क्लस्टर सूची को और अधिक सीमित बनाएंगे:

 apiVersion: limit.myafq.com/v1alpha1 kind: ClusterLimit metadata: name: restrictive-limit spec: namespaceSelector: matchLabels: limit: "restrictive" limitRange: limits: - type: Container max: cpu: "200m" memory: "250Mi" default: cpu: "100m" memory: "128Mi" defaultRequest: cpu: "50m" memory: "64Mi" - type: Pod max: cpu: "2" memory: "2Gi" 

अनुभाग पर ध्यान दें:

 - type: Container max: cpu: "200m" memory: "250Mi" 

अब हमने 200 मी सीपीयू और 250 मी मेमोरी को कंटेनर में अधिकतम के लिए चूल्हा में सेट किया है। और अब फिर से, के तहत बनाने की कोशिश:

 ❯() kubectl run --generator=run-pod/v1 --image=bash bash -n lightweight Error from server (Forbidden): pods "bash" is forbidden: [maximum cpu usage per Container is 200m, but limit is 700m., maximum memory usage per Container is 250Mi, but limit is 900Mi.] 

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

यह लिमिट ऑपरेटर का उपयोग करने का एक उदाहरण था। इसे स्वयं आज़माएँ और अपने स्थानीय कुबेरनेट उदाहरण में क्लस्टरस्टरलिमिट के साथ खेलें।

गिटहब लिमिट ऑपरेटर रिपॉजिटरी में, आप ऑपरेटर की तैनाती के लिए, साथ ही स्रोत कोड के लिए प्रकट पा सकते हैं। यदि आप ऑपरेटर की कार्यक्षमता का विस्तार करना चाहते हैं, तो पुल-क्वैस्ट और सुविधा-quests का स्वागत है!

निष्कर्ष

कुबेरनेट्स में संसाधन प्रबंधन आपके अनुप्रयोगों की स्थिरता और विश्वसनीयता के लिए महत्वपूर्ण है। जब भी संभव हो अपने चूल्हा संसाधनों को अनुकूलित करें। और जब संभव न हो तो मामलों के विरुद्ध बीमा करने के लिए LimitRange का उपयोग करें। लिमिट ऑपरेटर के उपयोग से LimitRange के निर्माण को स्वचालित करें।

इन युक्तियों का पालन करें, और आपके क्लस्टर हमेशा आवारा चूल्हों के पुनर्जीवन अराजकता से सुरक्षित रहेंगे।