कुबेरनेट्स पॉड संसाधनों तक कैसे पहुंचें

तोहद द्वारा पुरस्कार

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

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

टीम Mail.ru से Kubernetes aaS कंटेनर संसाधनों (सीपीयू और एमईएम), अनुरोधों और संसाधन सीमाओं के बारे में एक लेख का अनुवाद किया। आप इन सेटिंग्स के लाभों के बारे में जानेंगे और यदि आप इन्हें सेट नहीं करते हैं तो क्या होगा।

कंप्यूटिंग संसाधन

हमारे पास निम्नलिखित इकाइयों के साथ दो प्रकार के संसाधन हैं:

• सेंट्रल प्रोसेसिंग यूनिट (सीपीयू) - कोर;
• मेमोरी (एमईएम) - बाइट्स।

प्रत्येक कंटेनर के लिए संसाधन निर्दिष्ट हैं। निम्नलिखित पॉड YAML फ़ाइल में, आपको एक संसाधन अनुभाग दिखाई देगा जिसमें अनुरोधित और सीमित संसाधन शामिल हैं:

• अनुरोधित पॉड संसाधन = सभी कंटेनरों के अनुरोधित संसाधनों का योग;
• पॉड संसाधन सीमा = सभी पॉड संसाधन सीमाओं का योग।

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod-name
  labels:
    application: backend
spec:
  containers:
    — name: main-container
      image: my-backend
      tag: v1
      ports:
      — containerPort: 8080
      resources:
        requests:
          cpu: 0.2 # REQUESTED CPU: 200m cores
          memory: "1Gi" # REQUESTED MEM: 1Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi
    — name: other-container
      image: other-app
      tag: v1
      ports:
      — containerPort: 8000
      resources:
        requests:
          cpu: "200m" # REQUESTED CPU: 200m cores
          memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi

अनुरोधित और सीमित संसाधनों का उदाहरण

क्षेत्र resources.requested विनिर्देशन से पॉड उन तत्वों में से एक है जिसका उपयोग वांछित नोड को खोजने के लिए किया जाता है। आप इसके लिए पहले से ही पॉड परिनियोजन की योजना बना सकते हैं। आप एक उपयुक्त नोड कैसे ढूंढते हैं?

कुबेरनेट्स में कई घटक होते हैं, जिनमें एक मास्टर नोड या मास्टर नोड (कुबेरनेट्स कंट्रोल प्लेन) शामिल है। मास्टर नोड में कई प्रक्रियाएँ हैं: क्यूब-एपिसर्वर, क्यूब-कंट्रोलर-मैनेजर और क्यूब-शेड्यूलर।

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

बैंगनी पॉड कहाँ रखा जाएगा?

चित्र में आप देख सकते हैं कि क्यूब-शेड्यूलर को एक नया बैंगनी पॉड शेड्यूल करना चाहिए। कुबेरनेट्स क्लस्टर में दो नोड होते हैं: ए और बी। जैसा कि आप देख सकते हैं, क्यूब-शेड्यूलर नोड ए पर पॉड शेड्यूल नहीं कर सकता है - उपलब्ध (अनिवार्य) संसाधन बैंगनी पॉड के अनुरोधों से मेल नहीं खाते हैं। तो, बैंगनी पॉड द्वारा अनुरोधित 1 जीबी मेमोरी नोड ए पर फिट नहीं होगी, क्योंकि उपलब्ध मेमोरी 0,5 जीबी है। लेकिन नोड बी के पास पर्याप्त संसाधन हैं। परिणामस्वरूप, क्यूब-शेड्यूलर निर्णय लेता है कि बैंगनी पॉड का गंतव्य नोड बी है।

अब हम जानते हैं कि अनुरोधित संसाधन पॉड को चलाने के लिए नोड की पसंद को कैसे प्रभावित करते हैं। लेकिन सीमांत संसाधनों का प्रभाव क्या है?

संसाधन सीमा एक सीमा है जिसे सीपीयू/एमईएम पार नहीं कर सकता है। हालाँकि, सीपीयू संसाधन लचीला है, इसलिए जो कंटेनर अपनी सीपीयू सीमा तक पहुँचते हैं, वे पॉड को बाहर निकलने का कारण नहीं बनेंगे। इसके बजाय, सीपीयू थ्रॉटलिंग शुरू हो जाएगी। यदि एमईएम उपयोग सीमा पूरी हो गई है, तो कंटेनर को ओओएम-किलर के कारण रोक दिया जाएगा और रीस्टार्टपॉलिसी सेटिंग द्वारा अनुमति दिए जाने पर पुनः आरंभ किया जाएगा।

अनुरोधित और अधिकतम संसाधनों के बारे में विस्तार से

डॉकर और कुबेरनेट्स के बीच संसाधन संचार

यह समझाने का सबसे अच्छा तरीका है कि संसाधन अनुरोध और संसाधन सीमाएँ कैसे काम करती हैं, कुबेरनेट्स और डॉकर के बीच संबंध का परिचय देना है। ऊपर की छवि में आप देख सकते हैं कि कुबेरनेट्स फ़ील्ड और डॉकर स्टार्टअप फ़्लैग कैसे संबंधित हैं।

स्मृति: अनुरोध और सीमा

containers:
...
 resources:
   requests:
     memory: "0.5Gi"
   limits:
     memory: "1Gi"

जैसा कि ऊपर बताया गया है, मेमोरी को बाइट्स में मापा जाता है। पर आधारित कुबेरनेट्स प्रलेखन, हम मेमोरी को एक संख्या के रूप में निर्दिष्ट कर सकते हैं। आमतौर पर यह एक पूर्णांक होता है, उदाहरण के लिए 2678 - यानी 2678 बाइट्स। आप प्रत्यय का भी उपयोग कर सकते हैं G и Gi, मुख्य बात यह याद रखना है कि वे समकक्ष नहीं हैं। पहला दशमलव और दूसरा बाइनरी। K8s दस्तावेज़ में उल्लिखित उदाहरण की तरह: 128974848, 129e6, 129M, 123Mi - वे व्यावहारिक रूप से समकक्ष हैं।

कुबेरनेट्स विकल्प limits.memory झंडे से मेल खाता है --memory डॉकर से. के मामले में request.memory डॉकर के लिए कोई तीर नहीं है क्योंकि डॉकर इस फ़ील्ड का उपयोग नहीं करता है। आप पूछ सकते हैं, क्या यह आवश्यक भी है? हाँ जरूरत है. जैसा कि मैंने पहले कहा, कुबेरनेट्स के लिए क्षेत्र मायने रखता है। इससे प्राप्त जानकारी के आधार पर, क्यूब-शेड्यूलर यह निर्णय लेता है कि पॉड को किस नोड पर शेड्यूल करना है।

यदि आप किसी अनुरोध के लिए अपर्याप्त मेमोरी सेट करते हैं तो क्या होता है?

यदि कंटेनर अनुरोधित मेमोरी की सीमा तक पहुंच गया है, तो पॉड को पॉड्स के एक समूह में रखा जाता है जो नोड में पर्याप्त मेमोरी नहीं होने पर रुक जाता है।

यदि आप मेमोरी सीमा बहुत कम सेट करते हैं तो क्या होगा?

यदि कंटेनर मेमोरी सीमा से अधिक हो जाता है, तो इसे OOM-Killed के कारण समाप्त कर दिया जाएगा। और यदि संभव हो तो RestartPolicy के आधार पर पुनः आरंभ किया जाएगा जहां डिफ़ॉल्ट मान है Always.

यदि आप अनुरोधित मेमोरी निर्दिष्ट नहीं करते हैं तो क्या होगा?

कुबेरनेट्स सीमा मान लेगा और इसे डिफ़ॉल्ट मान के रूप में सेट करेगा।

यदि आप स्मृति सीमा निर्दिष्ट नहीं करते हैं तो क्या हो सकता है?

कंटेनर पर कोई प्रतिबंध नहीं है; यह जितनी चाहे उतनी मेमोरी का उपयोग कर सकता है। यदि वह नोड की सभी उपलब्ध मेमोरी का उपयोग करना शुरू कर देता है, तो OOM उसे मार देगा। यदि संभव हो तो RestartPolicy के आधार पर कंटेनर को पुनः आरंभ किया जाएगा।

यदि आप स्मृति सीमाएँ निर्दिष्ट नहीं करते हैं तो क्या होगा?

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

यदि अनुरोधित मेमोरी नोड की पेशकश से अधिक है, तो पॉड शेड्यूल नहीं किया जाएगा। यह याद रखना महत्वपूर्ण है Requests.memory - न्यूनतम मूल्य नहीं. यह कंटेनर को लगातार चालू रखने के लिए पर्याप्त मेमोरी की मात्रा का विवरण है।

आमतौर पर इसके लिए समान मान निर्धारित करने की अनुशंसा की जाती है request.memory и limit.memory. यह सुनिश्चित करता है कि कुबेरनेट्स किसी नोड पर पॉड शेड्यूल नहीं करेगा जिसमें पॉड को चलाने के लिए पर्याप्त मेमोरी है लेकिन इसे चलाने के लिए पर्याप्त नहीं है। ध्यान रखें: कुबेरनेट्स पॉड योजना केवल ध्यान में रखती है requests.memoryऔर limits.memory ध्यान में नहीं रखता.

सीपीयू: अनुरोध और सीमा

containers:
...
 resources:
   requests:
     cpu: 1
   limits:
     cpu: "1200m"

सीपीयू के साथ सब कुछ थोड़ा अधिक जटिल है। कुबेरनेट्स और डॉकर के बीच संबंधों की तस्वीर पर लौटते हुए, आप उसे देख सकते हैं request.cpu से मेल खाती है --cpu-sharesजबकि limit.cpu झंडे से मेल खाता है cpus डॉकर में.

कुबेरनेट्स जिस सीपीयू का अनुरोध करता है उसे सीपीयू चक्रों के अनुपात, 1024 से गुणा किया जाता है। यदि आप 1 पूर्ण कोर का अनुरोध करना चाहते हैं, तो आपको जोड़ना होगा cpu: 1जैसा कि उपर दिखाया गया है।

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

सीपीयू अनुरोध - सिंगल कोर सिस्टम

आइए कल्पना करें कि आपके पास सिंगल-कोर होस्ट सिस्टम चलाने वाले कंटेनर हैं। माँ (कुबेरनेट्स) ने एक पाई (सीपीयू) बनाई और इसे बच्चों (कंटेनरों) के बीच बांटना चाहती है। तीन बच्चे पूरी पाई चाहते हैं (अनुपात = 1024), दूसरा बच्चा आधी पाई चाहता है (512)। माँ निष्पक्ष रहना चाहती हैं और एक सरल गणना करती हैं।

# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%

गणना के आधार पर, तीन बच्चों को कोर का 28% मिलेगा, न कि संपूर्ण कोर। चौथे बच्चे को पूरी गिरी का 14% मिलेगा, आधा नहीं। लेकिन अगर आपके पास मल्टी-कोर सिस्टम है तो चीजें अलग होंगी।

सीपीयू अनुरोध - मल्टी-कोर (4) सिस्टम

ऊपर की छवि में आप देख सकते हैं कि तीन बच्चे पूरी पाई चाहते हैं, और एक आधी पाई चाहता है। चूँकि माँ ने चार पाई बनाईं, इसलिए उनके प्रत्येक बच्चे को जितनी चाहें उतनी मिलेंगी। मल्टी-कोर सिस्टम में, प्रोसेसर संसाधन सभी उपलब्ध प्रोसेसर कोर में वितरित किए जाते हैं। यदि कोई कंटेनर एक पूर्ण सीपीयू कोर से कम तक सीमित है, तो भी वह इसे 100% पर उपयोग कर सकता है।

उपरोक्त गणनाओं को यह समझने के लिए सरल बनाया गया है कि सीपीयू को कंटेनरों के बीच कैसे वितरित किया जाता है। बेशक, कंटेनरों के अलावा, अन्य प्रक्रियाएं भी हैं जो सीपीयू संसाधनों का भी उपयोग करती हैं। जब एक कंटेनर में प्रक्रियाएं निष्क्रिय होती हैं, तो अन्य लोग इसके संसाधन का उपयोग कर सकते हैं। CPU: "200m" से मेल खाती है CPU: 0,2, जिसका अर्थ है एक कोर का लगभग 20%।

अब बात करते हैं limit.cpu. कुबेरनेट्स द्वारा सीमित सीपीयू को 100 से गुणा किया जाता है। परिणाम यह होता है कि कंटेनर प्रत्येक 100 μs का उपयोग कर सकता है (cpu-period).

limit.cpu डॉकर ध्वज से मेल खाता है --cpus. यह पुराने का नया संयोजन है --cpu-period и --cpu-quota. इसे सेट करके, हम इंगित करते हैं कि थ्रॉटलिंग शुरू होने से पहले कंटेनर कितने उपलब्ध सीपीयू संसाधनों का अधिकतम उपयोग कर सकता है:

• CPUs - संयोजन cpu-period и cpu-quota. cpus = 1.5 सेटिंग के बराबर cpu-period = 100000 и cpu-quota = 150000;
• सीपीयू-अवधि - अवधि सीपीयू सीएफएस अनुसूचक, डिफ़ॉल्ट 100 माइक्रोसेकंड;
• सीपीयू-कोटा - अंदर माइक्रोसेकंड की संख्या cpu-period, जो कंटेनर से घिरा हुआ है।

यदि आप अपर्याप्त अनुरोधित सीपीयू स्थापित करते हैं तो क्या होगा?

यदि कंटेनर को स्थापित से अधिक की आवश्यकता है, तो यह अन्य प्रक्रियाओं से सीपीयू चुरा लेगा।

यदि आप सीपीयू सीमा बहुत कम निर्धारित करते हैं तो क्या होगा?

चूंकि सीपीयू संसाधन समायोज्य है, थ्रॉटलिंग चालू हो जाएगी।

यदि आप सीपीयू अनुरोध निर्दिष्ट नहीं करते हैं तो क्या होगा?

मेमोरी की तरह, अनुरोध मान सीमा के बराबर है।

यदि आप सीपीयू सीमा निर्दिष्ट नहीं करते हैं तो क्या होगा?

कंटेनर उतने ही CPU का उपयोग करेगा जितनी उसे आवश्यकता होगी। यदि नेमस्पेस में एक डिफ़ॉल्ट सीपीयू नीति (लिमिटरेंज) परिभाषित की गई है, तो इस सीमा का उपयोग कंटेनर के लिए भी किया जाता है।

यदि आप अनुरोध या सीपीयू सीमा निर्दिष्ट नहीं करते हैं तो क्या होगा?

स्मृति की तरह, यह सबसे खराब स्थिति है। शेड्यूलर को यह नहीं पता होता है कि आपके कंटेनर को कितने संसाधनों की आवश्यकता है, और इससे नोड पर गंभीर समस्याएं पैदा हो सकती हैं। इससे बचने के लिए, आपको नेमस्पेस (लिमिटरेंज) के लिए डिफ़ॉल्ट सीमाएँ निर्धारित करने की आवश्यकता है।

याद रखें: यदि आप नोड्स द्वारा प्रदान किए जा सकने वाले सीपीयू से अधिक का अनुरोध करते हैं, तो पॉड शेड्यूल नहीं किया जाएगा। Requests.cpu - न्यूनतम मूल्य नहीं, बल्कि पॉड शुरू करने और विफलताओं के बिना काम करने के लिए पर्याप्त मूल्य। यदि एप्लिकेशन जटिल गणना नहीं करता है, तो सबसे अच्छा विकल्प इंस्टॉल करना है request.cpu <= 1 और जितनी आवश्यक हो उतनी प्रतिकृतियां लॉन्च करें।

अनुरोधित संसाधनों की आदर्श मात्रा या संसाधन सीमा

हमने कंप्यूटिंग संसाधनों की सीमा के बारे में सीखा। अब इस प्रश्न का उत्तर देने का समय आ गया है: "मेरे पॉड को बिना किसी समस्या के एप्लिकेशन चलाने के लिए कितने संसाधनों की आवश्यकता है?" आदर्श राशि क्या है?

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

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

उदाहरण के तौर पर इसे देखें ग्राफाना डैशबोर्ड. यह अनुरोधित संसाधनों या संसाधन सीमा और वर्तमान संसाधन उपयोग के बीच अंतर प्रदर्शित करता है।

निष्कर्ष

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

संक्षेप में, ध्यान रखने योग्य कुछ बातें हैं:

1. अनुरोधित संसाधन एक कॉन्फ़िगरेशन है जिसे स्टार्टअप समय पर ध्यान में रखा जाता है (जब कुबेरनेट्स एप्लिकेशन को होस्ट करने की योजना बनाता है)। इसके विपरीत, रनटाइम पर संसाधनों को सीमित करना महत्वपूर्ण है - जब एप्लिकेशन पहले से ही नोड पर चल रहा हो।
2. मेमोरी की तुलना में, सीपीयू एक विनियमित संसाधन है। यदि पर्याप्त सीपीयू नहीं है, तो आपका पॉड बंद नहीं होगा और थ्रॉटलिंग तंत्र चालू हो जाएगा।
3. अनुरोधित संसाधन और संसाधन सीमा न्यूनतम और अधिकतम मान नहीं हैं! अनुरोधित संसाधनों को परिभाषित करके, आप यह सुनिश्चित करते हैं कि एप्लिकेशन बिना किसी समस्या के चलेगा।
4. मेमोरी अनुरोध को मेमोरी सीमा के बराबर सेट करना एक अच्छा अभ्यास है।
5. ठीक है इंस्टॉल का अनुरोध किया गया CPU <=1, यदि एप्लिकेशन जटिल गणना नहीं करता है।
6. यदि आप किसी नोड पर उपलब्ध संसाधनों से अधिक संसाधनों का अनुरोध करते हैं, तो पॉड उस नोड पर कभी भी शेड्यूल नहीं किया जाएगा।
7. अनुरोधित संसाधनों/संसाधन सीमाओं की सही मात्रा निर्धारित करने के लिए, लोड परीक्षण और निगरानी का उपयोग करें।

मुझे आशा है कि यह लेख आपको संसाधन सीमा की मूल अवधारणा को समझने में मदद करेगा। और आप इस ज्ञान को अपने काम में लागू कर पाएंगे।

सौभाग्य!

और क्या पढ़ें:

1. एसआरई अवलोकनशीलता: नामस्थान और मीट्रिक संरचना.
2. कुबेरनेट्स के लिए 90+ उपयोगी उपकरण: परिनियोजन, प्रबंधन, निगरानी, ​​​​सुरक्षा और बहुत कुछ.
3. टेलीग्राम में हमारा चैनल अराउंड कुबेरनेट्स.

स्रोत: www.habr.com