कुबर्नेट्स पॉड संसाधनांमध्ये प्रवेश कसा करायचा

तोहाड यांनी दिलेला पुरस्कार

Kubernetes सह प्रारंभ करताना, कंटेनर संसाधने सेट करणे विसरणे सामान्य आहे. या टप्प्यावर, डॉकर प्रतिमा कार्य करते आणि कुबर्नेट्स क्लस्टरमध्ये तैनात केली जाऊ शकते याची खात्री करणे पुरेसे आहे.

परंतु नंतर अनुप्रयोगास इतर अनुप्रयोगांसह उत्पादन क्लस्टरमध्ये तैनात करणे आवश्यक आहे. हे करण्यासाठी, तुम्हाला कंटेनरसाठी संसाधने वाटप करणे आवश्यक आहे आणि अनुप्रयोग सुरू आणि चालू करण्यासाठी ते पुरेसे आहेत याची खात्री करा आणि इतर चालू असलेल्या अनुप्रयोगांना समस्या येणार नाहीत.

संघ Mail.ru वरून Kubernetes aaS कंटेनर संसाधने (CPU आणि MEM), विनंत्या आणि संसाधन मर्यादांबद्दल लेख अनुवादित केला. तुम्ही या सेटिंग्जचे फायदे जाणून घ्याल आणि तुम्ही त्या सेट न केल्यास काय होते.

संगणकीय संसाधने

आमच्याकडे खालील युनिट्ससह दोन प्रकारची संसाधने आहेत:

• सेंट्रल प्रोसेसिंग युनिट (CPU) - कोर;
• मेमरी (MEM) - बाइट्स.

प्रत्येक कंटेनरसाठी संसाधने निर्दिष्ट केली आहेत. खालील Pod 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 स्पेसिफिकेशनमधून पॉड हा घटकांपैकी एक आहे जो इच्छित नोड शोधण्यासाठी वापरला जातो. त्यासाठी तुम्ही आधीच पॉड डिप्लॉयमेंटची योजना करू शकता. तुम्हाला योग्य नोड कसा मिळेल?

कुबर्नेट्समध्ये मास्टर नोड किंवा मास्टर नोड (कुबर्नेट्स कंट्रोल प्लेन) सह अनेक घटक असतात. मास्टर नोडमध्ये अनेक प्रक्रिया आहेत: kube-apiserver, kube-controller-manager आणि kube-scheduler.

कुबे-शेड्यूलर प्रक्रिया नवीन तयार केलेल्या पॉड्सचे पुनरावलोकन करण्यासाठी आणि विनंती केलेल्या संसाधनांच्या संख्येसह सर्व पॉड विनंत्यांशी जुळणारे संभाव्य कामगार नोड्स शोधण्यासाठी जबाबदार आहे. कुबे-शेड्युलरद्वारे सापडलेल्या नोड्सची यादी क्रमवारीत आहे. पॉड सर्वोच्च स्कोअरसह नोडवर शेड्यूल केलेले आहे.

जांभळा शेंगा कुठे ठेवणार?

चित्रात तुम्ही पाहू शकता की कुबे-शेड्युलरने नवीन जांभळा पॉड शेड्यूल केला पाहिजे. Kubernetes क्लस्टरमध्ये दोन नोड आहेत: A आणि B. तुम्ही बघू शकता, kube-scheduler नोड A वर पॉड शेड्यूल करू शकत नाही - उपलब्ध (विनंती न केलेले) संसाधने जांभळ्या पॉडच्या विनंतीशी जुळत नाहीत. त्यामुळे, जांभळ्या पॉडने विनंती केलेली 1 GB मेमरी नोड A वर बसणार नाही, कारण उपलब्ध मेमरी 0,5 GB आहे. परंतु नोड बी कडे पुरेशी संसाधने आहेत. परिणामी, कुबे-शेड्युलर ठरवतो की जांभळ्या पॉडचे गंतव्य नोड बी आहे.

आता आम्हाला माहित आहे की विनंती केलेली संसाधने पॉड चालविण्यासाठी नोडच्या निवडीवर कसा परिणाम करतात. पण किरकोळ संसाधनांवर काय परिणाम होतो?

संसाधन मर्यादा ही एक सीमा आहे जी CPU/MEM ओलांडू शकत नाही. तथापि, CPU संसाधन लवचिक आहे, त्यामुळे कंटेनर जे त्यांच्या CPU मर्यादेपर्यंत पोहोचतात ते Pod बाहेर पडू देणार नाहीत. त्याऐवजी, CPU थ्रॉटलिंग सुरू होईल. MEM वापर मर्यादा गाठली असल्यास, OOM-Killer मुळे कंटेनर थांबवला जाईल आणि RestartPolicy सेटिंगद्वारे परवानगी दिल्यास रीस्टार्ट होईल.

तपशीलवार विनंती केलेली आणि जास्तीत जास्त संसाधने

डॉकर आणि कुबर्नेट्स दरम्यान संसाधन संप्रेषण

संसाधन विनंत्या आणि संसाधन मर्यादा कशा कार्य करतात हे स्पष्ट करण्याचा सर्वोत्तम मार्ग म्हणजे कुबर्नेट्स आणि डॉकर यांच्यातील संबंधांचा परिचय करून देणे. वरील इमेजमध्ये तुम्ही कुबर्नेट्स फील्ड आणि डॉकर स्टार्टअप फ्लॅग कसे संबंधित आहेत ते पाहू शकता.

मेमरी: विनंती आणि मर्यादा

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

वर नमूद केल्याप्रमाणे, मेमरी बाइट्समध्ये मोजली जाते. आधारीत Kubernetes दस्तऐवजीकरण, आपण संख्या म्हणून मेमरी निर्दिष्ट करू शकतो. सहसा ते पूर्णांक असते, उदाहरणार्थ 2678 - म्हणजेच 2678 बाइट्स. आपण प्रत्यय देखील वापरू शकता G и Gi, मुख्य गोष्ट लक्षात ठेवा की ते समतुल्य नाहीत. पहिला दशांश आहे आणि दुसरा बायनरी आहे. k8s दस्तऐवजीकरणात नमूद केलेल्या उदाहरणाप्रमाणे: 128974848, 129e6, 129M, 123Mi - ते व्यावहारिकदृष्ट्या समतुल्य आहेत.

Kubernetes पर्याय limits.memory ध्वजाशी जुळते --memory डॉकर कडून. बाबतीत request.memory डॉकरसाठी कोणताही बाण नाही कारण डॉकर हे फील्ड वापरत नाही. तुम्ही विचाराल, हे अगदी आवश्यक आहे का? होय गरज आहे. मी आधी म्हटल्याप्रमाणे, कुबर्नेट्ससाठी फील्ड महत्त्वाचे आहे. त्यातून मिळालेल्या माहितीच्या आधारे, कुबे-शेड्युलर कोणत्या नोडवर पॉड शेड्यूल करायचे ते ठरवतात.

तुम्ही विनंतीसाठी अपुरी मेमरी सेट केल्यास काय होईल?

जर कंटेनर विनंती केलेल्या मेमरीच्या मर्यादेपर्यंत पोहोचला असेल, तर पॉड पॉड्सच्या गटामध्ये ठेवला जातो जो नोडमध्ये पुरेशी मेमरी नसताना थांबतो.

तुम्ही मेमरी मर्यादा खूप कमी सेट केल्यास काय होईल?

कंटेनरने मेमरी मर्यादा ओलांडल्यास, ते OOM-Killed मुळे बंद केले जाईल. आणि जेथे डीफॉल्ट मूल्य असेल तेथे RestartPolicy वर आधारित शक्य असल्यास रीस्टार्ट होईल Always.

तुम्ही विनंती केलेली मेमरी निर्दिष्ट न केल्यास काय होईल?

Kubernetes मर्यादा मूल्य घेईल आणि ते डीफॉल्ट मूल्य म्हणून सेट करेल.

आपण मेमरी मर्यादा निर्दिष्ट न केल्यास काय होऊ शकते?

कंटेनरला कोणतेही बंधन नाही; तो पाहिजे तितकी मेमरी वापरू शकतो. जर त्याने नोडची सर्व उपलब्ध मेमरी वापरण्यास सुरुवात केली, तर OOM त्याला मारून टाकेल. रीस्टार्ट पॉलिसीच्या आधारे शक्य असल्यास कंटेनर पुन्हा सुरू केला जाईल.

तुम्ही मेमरी मर्यादा निर्दिष्ट न केल्यास काय होईल?

ही सर्वात वाईट परिस्थिती आहे: शेड्युलरला कंटेनरला किती संसाधने आवश्यक आहेत हे माहित नाही आणि यामुळे नोडवर गंभीर समस्या उद्भवू शकतात. या प्रकरणात, नेमस्पेसवर (LimitRange द्वारे सेट) डीफॉल्ट मर्यादा असणे चांगले होईल. कोणतीही डीफॉल्ट मर्यादा नाहीत - पॉडला कोणतीही मर्यादा नाही, ती पाहिजे तितकी मेमरी वापरू शकते.

विनंती केलेली मेमरी नोड देऊ शकत असलेल्यापेक्षा जास्त असल्यास, पॉड शेड्यूल केला जाणार नाही. हे लक्षात ठेवणे महत्त्वाचे आहे Requests.memory - किमान मूल्य नाही. हे कंटेनर सतत चालू ठेवण्यासाठी पुरेशा मेमरीचे वर्णन आहे.

साठी समान मूल्य सेट करण्याची शिफारस केली जाते request.memory и limit.memory. हे सुनिश्चित करते की कुबर्नेट्स नोडवर पॉड शेड्यूल करणार नाही ज्यात पॉड चालविण्यासाठी पुरेशी मेमरी आहे परंतु ती चालविण्यासाठी पुरेशी नाही. लक्षात ठेवा: कुबर्नेट्स पॉड नियोजन केवळ विचारात घेते requests.memoryआणि limits.memory विचारात घेत नाही.

CPU: विनंती आणि मर्यादा

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

CPU सह सर्व काही थोडे अधिक क्लिष्ट आहे. कुबर्नेट्स आणि डॉकर यांच्यातील संबंधांच्या चित्राकडे परत आल्यावर, आपण ते पाहू शकता request.cpu च्याशी संबंधित आहे --cpu-shares, तर limit.cpu ध्वजाशी जुळते cpus डॉकर मध्ये.

कुबर्नेट्सने विनंती केलेल्या CPU चा 1024 ने गुणाकार केला जातो, CPU सायकलचे प्रमाण. तुम्हाला 1 पूर्ण कोरची विनंती करायची असल्यास, तुम्ही जोडणे आवश्यक आहे cpu: 1वर दाखवल्याप्रमाणे.

पूर्ण कर्नल (प्रोपोर्शन = 1024) ची विनंती करणे म्हणजे तुमच्या कंटेनरला ते मिळेल असे नाही. जर तुमच्या होस्ट मशीनमध्ये फक्त एक कोर असेल आणि तुम्ही एकापेक्षा जास्त कंटेनर चालवत असाल, तर सर्व कंटेनरने त्यांच्यामध्ये उपलब्ध CPU शेअर करणे आवश्यक आहे. हे कसे घडते? चला चित्र बघूया.

CPU विनंती - सिंगल कोर सिस्टम

चला कल्पना करूया की तुमच्याकडे सिंगल-कोर होस्ट सिस्टीम चालवणारे कंटेनर आहेत. आई (कुबरनेटेस) पाई (सीपीयू) बेक करते आणि ते मुलांमध्ये (कंटेनर) विभाजित करू इच्छिते. तीन मुलांना संपूर्ण पाई (प्रमाण = 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% मिळतील, अर्धा नाही. परंतु आपल्याकडे मल्टी-कोर सिस्टम असल्यास गोष्टी वेगळ्या असतील.

CPU विनंती - मल्टी-कोर (4) प्रणाली

वरील प्रतिमेत तुम्ही पाहू शकता की तीन मुलांना पूर्ण पाई हवी आहे आणि एकाला अर्धी हवी आहे. आईने चार पाई बेक केल्यामुळे, तिच्या प्रत्येक मुलाला पाहिजे तितके मिळतील. मल्टी-कोर सिस्टममध्ये, प्रोसेसर संसाधने सर्व उपलब्ध प्रोसेसर कोरमध्ये वितरीत केली जातात. कंटेनर एकापेक्षा कमी पूर्ण CPU कोरपर्यंत मर्यादित असल्यास, तो अजूनही 100% वर वापरू शकतो.

कंटेनरमध्ये CPU कसे वितरित केले जाते हे समजून घेण्यासाठी वरील गणना सरलीकृत केली आहे. अर्थात, स्वतः कंटेनर्स व्यतिरिक्त, इतर प्रक्रिया देखील आहेत ज्या CPU संसाधने देखील वापरतात. जेव्हा एका कंटेनरमधील प्रक्रिया निष्क्रिय असतात, तेव्हा इतर त्याचे संसाधन वापरू शकतात. CPU: "200m" च्याशी संबंधित आहे CPU: 0,2, याचा अर्थ एका कोरच्या अंदाजे 20%.

आता याबद्दल बोलूया limit.cpu. कुबर्नेटेस ज्या CPU ला मर्यादा घालते ते 100 ने गुणले जाते. परिणाम म्हणजे कंटेनर प्रत्येक 100 µs (cpu-period).

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

• cpus - संयोजन cpu-period и cpu-quota. cpus = 1.5 सेटिंग समतुल्य cpu-period = 100000 и cpu-quota = 150000;
• CPU-कालावधी - कालावधी CPU CFS शेड्युलर, डीफॉल्ट 100 मायक्रोसेकंद;
• cpu-कोटा - आत मायक्रोसेकंदांची संख्या cpu-period, जे कंटेनरने बांधलेले आहे.

तुम्ही अपुरा विनंती केलेला CPU इंस्टॉल केल्यास काय होईल?

कंटेनरला स्थापित केलेल्यापेक्षा जास्त गरज असल्यास, ते इतर प्रक्रियांमधून CPU चोरेल.

तुम्ही CPU मर्यादा खूप कमी सेट केल्यास काय होईल?

CPU संसाधन समायोजित करण्यायोग्य असल्याने, थ्रॉटलिंग चालू होईल.

तुम्ही CPU विनंती निर्दिष्ट न केल्यास काय होईल?

मेमरीप्रमाणे, विनंती मूल्य मर्यादेइतके आहे.

तुम्ही CPU मर्यादा निर्दिष्ट न केल्यास काय होईल?

कंटेनर आवश्यक तेवढा CPU वापरेल. डिफॉल्ट CPU धोरण (LimitRange) नेमस्पेसमध्ये परिभाषित केले असल्यास, ही मर्यादा कंटेनरसाठी देखील वापरली जाते.

तुम्ही विनंती किंवा CPU मर्यादा निर्दिष्ट न केल्यास काय होईल?

स्मृतीप्रमाणे, ही सर्वात वाईट परिस्थिती आहे. शेड्युलरला आपल्या कंटेनरला किती संसाधनांची आवश्यकता आहे हे माहित नाही आणि यामुळे नोडवर गंभीर समस्या उद्भवू शकतात. हे टाळण्यासाठी, तुम्हाला नेमस्पेसेससाठी (LimitRange) डीफॉल्ट मर्यादा सेट करणे आवश्यक आहे.

लक्षात ठेवा: तुम्ही नोड्स देऊ शकतील त्यापेक्षा जास्त CPU ची विनंती केल्यास, Pod शेड्यूल केला जाणार नाही. Requests.cpu - किमान मूल्य नाही, परंतु पॉड सुरू करण्यासाठी आणि अपयशाशिवाय कार्य करण्यासाठी पुरेसे मूल्य. अनुप्रयोग जटिल गणना करत नसल्यास, सर्वोत्तम पर्याय स्थापित करणे आहे request.cpu <= 1 आणि आवश्यक तितक्या प्रतिकृती लाँच करा.

विनंती केलेल्या संसाधनांची आदर्श रक्कम किंवा संसाधन मर्यादा

आम्ही संगणकीय संसाधनांच्या मर्यादांबद्दल शिकलो. आता या प्रश्नाचे उत्तर देण्याची वेळ आली आहे: “माझ्या पॉडला कोणत्याही समस्यांशिवाय अनुप्रयोग चालविण्यासाठी किती संसाधने आवश्यक आहेत? आदर्श रक्कम काय आहे?

दुर्दैवाने, या प्रश्नांची कोणतीही स्पष्ट उत्तरे नाहीत. तुमचा अॅप्लिकेशन कसा काम करतो किंवा किती CPU किंवा मेमरी आवश्यक आहे हे तुम्हाला माहीत नसल्यास, अॅप्लिकेशनला भरपूर मेमरी आणि CPU देणे आणि नंतर परफॉर्मन्स चाचण्या चालवणे हा सर्वोत्तम पर्याय आहे.

कार्यप्रदर्शन चाचण्यांव्यतिरिक्त, एका आठवड्यासाठी मॉनिटरिंगमध्ये अनुप्रयोगाच्या वर्तनाचे परीक्षण करा. जर आलेख सूचित करतात की तुमचा अनुप्रयोग तुम्ही विनंती केलेल्या पेक्षा कमी संसाधने वापरत आहे, तर तुम्ही विनंती केलेल्या CPU किंवा मेमरीचे प्रमाण कमी करू शकता.

उदाहरण म्हणून हे पहा ग्राफना डॅशबोर्ड. हे विनंती केलेली संसाधने किंवा संसाधन मर्यादा आणि वर्तमान संसाधन वापर यांच्यातील फरक प्रदर्शित करते.

निष्कर्ष

संसाधनांची विनंती करणे आणि मर्यादित करणे हे तुमचे कुबर्नेट्स क्लस्टर निरोगी ठेवण्यास मदत करते. योग्य मर्यादा कॉन्फिगरेशनमुळे खर्च कमी होतो आणि अनुप्रयोग नेहमी चालू राहतात.

थोडक्यात, लक्षात ठेवण्यासारख्या काही गोष्टी आहेत:

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

मला आशा आहे की हा लेख तुम्हाला संसाधन मर्यादेची मूलभूत संकल्पना समजून घेण्यास मदत करेल. आणि हे ज्ञान तुम्ही तुमच्या कामात लागू करू शकाल.

रिझर्व्हर्व्हर ... पुन्हा!

आणखी काय वाचायचे:

1. SRE निरीक्षणक्षमता: नेमस्पेसेस आणि मेट्रिक स्ट्रक्चर.
2. Kubernetes साठी 90+ उपयुक्त साधने: उपयोजन, व्यवस्थापन, देखरेख, सुरक्षा आणि बरेच काही.
3. आमचे चॅनेल अराउंड कुबरनेटेस टेलीग्राममध्ये.

स्त्रोत: www.habr.com