Kubernetes Pod स्रोतहरू कसरी पहुँच गर्ने

Tohad द्वारा पुरस्कार

Kubernetes को साथ सुरु गर्दा, कन्टेनर स्रोतहरू सेटअप गर्न बिर्सनु सामान्य छ। यस बिन्दुमा, यो सुनिश्चित गर्न पर्याप्त छ कि डकर छवि काम गर्दछ र Kubernetes क्लस्टरमा तैनात गर्न सकिन्छ।

तर पछि अनुप्रयोगलाई अन्य अनुप्रयोगहरूसँग उत्पादन क्लस्टरमा तैनाथ गर्न आवश्यक छ। यो गर्नको लागि, तपाईंले कन्टेनरको लागि स्रोतहरू आवंटित गर्न आवश्यक छ र सुनिश्चित गर्नुहोस् कि त्यहाँ अनुप्रयोगहरू प्राप्त गर्न र चलाउन पर्याप्त छन्, र अन्य चलिरहेको अनुप्रयोगहरूले समस्याहरू अनुभव गर्दैनन्।

टोली Kubernetes aaS Mail.ru बाट कन्टेनर स्रोतहरू (CPU र MEM), अनुरोधहरू र स्रोत सीमितताहरूको बारेमा एउटा लेख अनुवाद गरियो। तपाईंले यी सेटिङहरूका फाइदाहरू सिक्नुहुनेछ र यदि तपाईंले तिनीहरूलाई सेट गर्नुभएन भने के हुन्छ।

कम्प्युटिङ स्रोतहरू

हामीसँग निम्न एकाइहरूसँग दुई प्रकारका स्रोतहरू छन्:

• केन्द्रीय प्रशोधन इकाई (CPU) - कोर;
• मेमोरी (MEM) - बाइट्स।

प्रत्येक कन्टेनरको लागि स्रोतहरू निर्दिष्ट गरिएका छन्। निम्न Pod YAML फाइलमा, तपाईंले अनुरोध गरिएको र सीमित स्रोतहरू समावेश गर्ने संसाधन खण्ड देख्नुहुनेछ:

• अनुरोध गरिएको पोड संसाधन = सबै कन्टेनरहरूको अनुरोध गरिएको स्रोतहरूको योग;
• Pod Resource Limit = सबै Pod Resource Limits को योगफल।

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 स्पेसिफिकेशनबाट Pod एक तत्व हो जुन इच्छित नोड फेला पार्न प्रयोग गरिन्छ। तपाईं पहिले नै यसको लागि पोड तैनाती योजना गर्न सक्नुहुन्छ। तपाईं कसरी उपयुक्त नोड फेला पार्न सक्नुहुन्छ?

Kubernetes मा मास्टर नोड वा मास्टर नोड (Kubernetes नियन्त्रण विमान) सहित धेरै कम्पोनेन्टहरू हुन्छन्। मास्टर नोडमा धेरै प्रक्रियाहरू छन्: kube-apiserver, kube-controller-manager र kube-scheduler।

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

बैजनी पोड कहाँ राखिनेछ?

तस्विरमा तपाईले देख्न सक्नुहुन्छ कि kube-scheduler ले नयाँ बैजनी पोड अनुसूचित गर्नुपर्छ। Kubernetes क्लस्टरले दुईवटा नोडहरू समावेश गर्दछ: A र B। तपाईंले देख्न सक्नुहुन्छ, kube-scheduler ले नोड A मा Pod शेड्यूल गर्न सक्दैन - उपलब्ध (अनुरोध नगरिएको) स्रोतहरू बैजनी पोडका अनुरोधहरूसँग मेल खाँदैन। त्यसोभए, बैजनी पोड द्वारा अनुरोध गरिएको 1 GB मेमोरी नोड A मा फिट हुने छैन, किनकि उपलब्ध मेमोरी 0,5 GB छ। तर नोड बीसँग पर्याप्त स्रोतहरू छन्। नतिजाको रूपमा, kube-scheduler ले निर्णय गर्छ कि बैजनी पोडको गन्तव्य नोड B हो।

अब हामीलाई थाहा छ कि कसरी अनुरोध गरिएका स्रोतहरूले पोड चलाउन नोडको छनोटलाई असर गर्छ। तर सीमान्त स्रोतको प्रभाव के हो?

स्रोत सीमा भनेको CPU/MEM ले पार गर्न नसक्ने सीमा हो। जे होस्, CPU स्रोत लचिलो छ, त्यसैले कन्टेनरहरू जुन तिनीहरूको CPU सीमामा पुग्छन् पोडलाई बाहिर निस्कन दिँदैन। यसको सट्टा, CPU थ्रोटलिङ सुरु हुनेछ। यदि MEM उपयोग सीमा पुग्यो भने, कन्टेनर OOM-Killer को कारण रोकिनेछ र RestartPolicy सेटिङले अनुमति दिएमा पुन: सुरु हुनेछ।

विस्तृत रूपमा अनुरोध गरिएको र अधिकतम स्रोतहरू

Docker र Kubernetes बीच संसाधन संचार

स्रोत अनुरोधहरू र स्रोत सीमाहरू कसरी काम गर्छन् भनेर व्याख्या गर्ने सबैभन्दा राम्रो तरिका कुबर्नेट्स र डकर बीचको सम्बन्ध परिचय गराउनु हो। माथिको छविमा तपाईले कुबर्नेट्स फिल्डहरू र डकर स्टार्टअप फ्ल्यागहरू कसरी सम्बन्धित छन् भनेर देख्न सक्नुहुन्छ।

मेमोरी: अनुरोध र सीमा

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 को साथ सबै कुरा अलि बढी जटिल छ। Kubernetes र Docker बीचको सम्बन्धको तस्वीरमा फर्केर, तपाइँ त्यो देख्न सक्नुहुन्छ request.cpu यससँग सम्बन्धित छ --cpu-sharesजबकि, limit.cpu झण्डासँग मेल खान्छ cpus डकरमा।

Kubernetes ले अनुरोध गरेको 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 - न्यूनतम मान होइन, तर Pod सुरु गर्न र विफलता बिना काम गर्न पर्याप्त मान। यदि अनुप्रयोगले जटिल गणनाहरू प्रदर्शन गर्दैन भने, उत्तम विकल्प स्थापना गर्न हो request.cpu <= 1 र आवश्यकता अनुसार धेरै प्रतिकृतिहरू सुरू गर्नुहोस्।

अनुरोध गरिएको स्रोत वा स्रोत सीमाको आदर्श मात्रा

हामीले कम्प्युटिङ स्रोतहरूको सीमितताको बारेमा सिकेका छौं। अब यो प्रश्नको जवाफ दिने समय हो: "मेरो पोडलाई कुनै पनि समस्या बिना अनुप्रयोग चलाउन कति स्रोतहरू चाहिन्छ? आदर्श रकम के हो?

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

प्रदर्शन परीक्षणको अतिरिक्त, एक हप्ताको लागि अनुगमनमा अनुप्रयोगको व्यवहार निगरानी गर्नुहोस्। यदि ग्राफहरूले संकेत गर्दछ कि तपाइँको अनुप्रयोगले तपाइँले अनुरोध गरेको भन्दा कम स्रोतहरू खपत गरिरहेको छ, तपाइँ अनुरोध गरिएको CPU वा मेमोरीको मात्रा घटाउन सक्नुहुन्छ।

उदाहरणको रूपमा यो हेर्नुहोस् Grafana ड्यासबोर्ड। यसले अनुरोध गरिएको स्रोत वा स्रोत सीमा र हालको स्रोत उपयोग बीचको भिन्नता देखाउँछ।

निष्कर्षमा

अनुरोध र स्रोतहरू सीमित गर्नाले तपाईंको Kubernetes क्लस्टरलाई स्वस्थ राख्न मद्दत गर्दछ। उचित सीमा कन्फिगरेसनले लागतलाई कम गर्छ र अनुप्रयोगहरूलाई सधैं चलिरहन्छ।

छोटकरीमा, दिमागमा राख्न केहि चीजहरू छन्:

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

मलाई आशा छ कि यस लेखले तपाईंलाई स्रोत सीमितताको आधारभूत अवधारणा बुझ्न मद्दत गर्दछ। र तपाईं आफ्नो काम मा यो ज्ञान लागू गर्न सक्षम हुनेछ।

शुभकामना!

अरु के पढ्ने:

1. SRE अवलोकन योग्यता: नेमस्पेस र मेट्रिक संरचना.
2. Kubernetes को लागि 90+ उपयोगी उपकरणहरू: तैनाती, व्यवस्थापन, निगरानी, ​​सुरक्षा र थप.
3. Telegram मा Kubernetes को आसपास हाम्रो च्यानल.

स्रोत: www.habr.com