🥇 Kubernetes प्रदर्शन सुधार गर्न नौ सुझावहरू

नमस्ते सबै! मेरो नाम Oleg Sidorenkov हो, म DomClick मा पूर्वाधार टोलीको प्रमुखको रूपमा काम गर्छु। हामीले उत्पादनमा कुबिकलाई तीन वर्षभन्दा बढी समयदेखि प्रयोग गर्दै आएका छौं, र यस समयमा हामीले यससँग धेरै फरक रोचक क्षणहरू अनुभव गरेका छौं। आज म तपाईंलाई बताउनेछु कि कसरी, सही दृष्टिकोणको साथ, तपाईंले आफ्नो क्लस्टरको लागि भेनिला कुबर्नेट्सबाट अझ बढी प्रदर्शन निचोड गर्न सक्नुहुन्छ। तयार स्थिर जानुहोस्!

तपाईं सबैलाई राम्ररी थाहा छ कि Kubernetes कन्टेनर अर्केस्ट्रेसनको लागि स्केलेबल खुला स्रोत प्रणाली हो; राम्रो, वा 5 बाइनरीहरू जसले सर्भर वातावरणमा तपाईंको माइक्रोसर्भिसेसहरूको जीवन चक्र प्रबन्ध गरेर जादुई काम गर्दछ। थप रूपमा, यो एकदम लचिलो उपकरण हो जुन विभिन्न कार्यहरूको लागि अधिकतम अनुकूलनको लागि लेगो जस्तै जम्मा गर्न सकिन्छ।

र सबै कुरा ठीक छ जस्तो देखिन्छ: सर्भरहरूलाई क्लस्टरमा दाउरालाई फायरबक्समा फाल्नुहोस्, र तपाइँलाई कुनै दुःख थाहा छैन। तर यदि तपाईं वातावरणको लागि हुनुहुन्छ भने, तपाईंले सोच्नुहुनेछ: "म कसरी आगो बालेर जंगललाई बचाउन सक्छु?" अर्को शब्दमा, पूर्वाधार सुधार गर्ने र लागत घटाउने उपायहरू कसरी खोज्ने।

1. टोली र अनुप्रयोग स्रोतहरू निगरानी गर्नुहोस्

सबैभन्दा सामान्य, तर प्रभावकारी विधिहरू मध्ये एक अनुरोध/सीमाहरूको परिचय हो। नामस्थानहरूद्वारा अनुप्रयोगहरू विभाजन गर्नुहोस्, र विकास टोलीहरूद्वारा नेमस्पेसहरू। डिप्लोइमेन्ट अघि, प्रोसेसर समय, मेमोरी, र अल्पकालिक भण्डारणको खपतको लागि अनुप्रयोग मानहरू सेट गर्नुहोस्।

resources:
   requests:
     memory: 2Gi
     cpu: 250m
   limits:
     memory: 4Gi
     cpu: 500m

अनुभव मार्फत, हामी निष्कर्षमा पुग्यौं: तपाईंले सीमाबाट अनुरोधहरू दुई पटक भन्दा बढि बढाउनु हुँदैन। क्लस्टरको भोल्युम अनुरोधहरूको आधारमा गणना गरिन्छ, र यदि तपाईंले अनुप्रयोगहरूलाई स्रोतहरूमा भिन्नता दिनुहुन्छ, उदाहरणका लागि, 5-10 पटक, त्यसपछि कल्पना गर्नुहोस् कि तपाईंको नोडलाई के हुन्छ जब यो पोडले भरिन्छ र अचानक लोड हुन्छ। केही राम्रो छैन। न्यूनतम, थ्रॉटलिङ, र अधिकतममा, तपाईंले कार्यकर्तालाई अलविदा भन्नुहुनेछ र पोडहरू सार्न थालेपछि बाँकी नोडहरूमा चक्रीय भार प्राप्त गर्नुहुनेछ।

साथै, मद्दत संग limitranges सुरुमा, तपाइँ कन्टेनरको लागि स्रोत मानहरू सेट गर्न सक्नुहुन्छ - न्यूनतम, अधिकतम र पूर्वनिर्धारित:

➜  ~ kubectl describe limitranges --namespace ops
Name:       limit-range
Namespace:  ops
Type        Resource           Min   Max   Default Request  Default Limit  Max Limit/Request Ratio
----        --------           ---   ---   ---------------  -------------  -----------------------
Container   cpu                50m   10    100m             100m           2
Container   ephemeral-storage  12Mi  8Gi   128Mi            4Gi            -
Container   memory             64Mi  40Gi  128Mi            128Mi          2

नामस्थान स्रोतहरू सीमित गर्न नबिर्सनुहोस् ताकि एउटा टोलीले क्लस्टरका सबै स्रोतहरू लिन सक्दैन:

➜  ~ kubectl describe resourcequotas --namespace ops
Name:                   resource-quota
Namespace:              ops
Resource                Used          Hard
--------                ----          ----
limits.cpu              77250m        80
limits.memory           124814367488  150Gi
pods                    31            45
requests.cpu            53850m        80
requests.memory         75613234944   150Gi
services                26            50
services.loadbalancers  0             0
services.nodeports      0             0

वर्णनबाट देख्न सकिन्छ resourcequotas, यदि ops टोलीले अर्को 10 cpu खपत गर्ने पोडहरू प्रयोग गर्न चाहन्छ भने, अनुसूचकले यसलाई अनुमति दिनेछैन र त्रुटि फ्याँक्नेछ:

Error creating: pods "nginx-proxy-9967d8d78-nh4fs" is forbidden: exceeded quota: resource-quota, requested: limits.cpu=5,requests.cpu=5, used: limits.cpu=77250m,requests.cpu=53850m, limited: limits.cpu=10,requests.cpu=10

यस्तो समस्या समाधान गर्न, तपाईं एक उपकरण लेख्न सक्नुहुन्छ, उदाहरणका लागि, जस्तै यो, भण्डारण गर्न र आदेश स्रोतहरूको राज्य प्रतिबद्ध गर्न सक्षम।

2. इष्टतम फाइल भण्डारण छनौट गर्नुहोस्

यहाँ म निरन्तर भोल्युम र Kubernetes कार्यकर्ता नोडहरूको डिस्क सबसिस्टमको विषयमा छुनुहोस्। मलाई आशा छ कि कसैले उत्पादनमा HDD मा "क्यूब" प्रयोग गर्दैन, तर कहिलेकाहीँ नियमित SSD अब पर्याप्त हुँदैन। हामीले एउटा समस्याको सामना गर्यौं जहाँ लगहरूले I/O अपरेसनहरूको कारणले डिस्कलाई मार्दै थियो, र त्यहाँ धेरै समाधानहरू छैनन्:

उच्च-सम्पादन SSDs प्रयोग गर्नुहोस् वा NVMe मा स्विच गर्नुहोस् (यदि तपाइँ आफ्नै हार्डवेयर व्यवस्थापन गर्नुहुन्छ)।
लगिङ स्तर घटाउनुहोस्।
डिस्कलाई बलात्कार गर्ने पोडहरूको "स्मार्ट" सन्तुलन गर्नुहोस् (podAntiAffinity).

माथिको स्क्रिनले nginx-ingress-controller अन्तर्गत डिस्कमा के हुन्छ देखाउँछ जब access_logs लगिङ सक्षम हुन्छ (~ 12 हजार लग/सेकेन्ड)। यो अवस्था, निस्सन्देह, यस नोडमा सबै अनुप्रयोगहरूको गिरावट हुन सक्छ।

PV को लागि, अफसोस, मैले सबै प्रयास गरेको छैन प्रजाति निरन्तर भोल्युमहरू। तपाईलाई उपयुक्त हुने उत्तम विकल्प प्रयोग गर्नुहोस्। ऐतिहासिक रूपमा, यो हाम्रो देशमा भएको छ कि सेवाहरूको सानो भागलाई RWX भोल्युम चाहिन्छ, र लामो समय पहिले तिनीहरूले यस कार्यको लागि NFS भण्डारण प्रयोग गर्न थाले। सस्तो र पर्याप्त... निस्सन्देह, उसले र मैले बकवास खाए - तपाईलाई आशीर्वाद दिनुहोस्, तर हामीले यसलाई ट्युन गर्न सिकेका छौं, र मेरो टाउको अब दुख्दैन। र यदि सम्भव छ भने, S3 वस्तु भण्डारणमा सार्नुहोस्।

3. अनुकूलित छविहरू सङ्कलन गर्नुहोस्

कन्टेनर-अप्टिमाइज गरिएका छविहरू प्रयोग गर्नु उत्तम हुन्छ ताकि Kubernetes ले तिनीहरूलाई छिटो ल्याउन र तिनीहरूलाई अझ प्रभावकारी रूपमा कार्यान्वयन गर्न सकोस्।

अप्टिमाइज्ड भनेको तस्बिरहरू:

केवल एक अनुप्रयोग समावेश वा केवल एक प्रकार्य प्रदर्शन;
आकारमा सानो, किनकि ठूला तस्बिरहरू नेटवर्कमा नराम्रो रूपमा प्रसारित हुन्छन्;
स्वास्थ्य र तयारीको अन्तिम बिन्दुहरू छन् जसले Kubernetes लाई डाउनटाइमको अवस्थामा कारबाही गर्न अनुमति दिन्छ;
कन्टेनर-अनुकूल अपरेटिङ सिस्टमहरू प्रयोग गर्नुहोस् (जस्तै अल्पाइन वा CoreOS), जो कन्फिगरेसन त्रुटिहरूको लागि अधिक प्रतिरोधी छन्;
बहु-चरण निर्माणहरू प्रयोग गर्नुहोस् ताकि तपाइँ केवल कम्पाइल गरिएका अनुप्रयोगहरू प्रयोग गर्न सक्नुहुन्छ र साथमा स्रोतहरू होइन।

त्यहाँ धेरै उपकरण र सेवाहरू छन् जसले तपाईंलाई उडानमा छविहरू जाँच गर्न र अनुकूलन गर्न अनुमति दिन्छ। तिनीहरूलाई सधैं अद्यावधिक राख्न र सुरक्षाको लागि परीक्षण गर्न महत्त्वपूर्ण छ। नतिजाको रूपमा तपाईले पाउनुहुन्छ:

सम्पूर्ण क्लस्टरमा नेटवर्क लोड कम भयो।
कन्टेनर स्टार्टअप समय घटाउँदै।
तपाईंको सम्पूर्ण डकर रजिस्ट्रीको सानो आकार।

4. DNS क्यास प्रयोग गर्नुहोस्

यदि हामी उच्च भारको बारेमा कुरा गर्छौं भने, क्लस्टरको DNS प्रणाली ट्युन नगरी जीवन एकदमै खराब छ। एक पटक, Kubernetes विकासकर्ताहरूले उनीहरूको kube-dns समाधानलाई समर्थन गरे। यो यहाँ पनि लागू गरिएको थियो, तर यो सफ्टवेयर विशेष रूपमा ट्युन गरिएको थिएन र आवश्यक कार्यसम्पादन उत्पादन गरेन, यद्यपि यो एक साधारण कार्य जस्तो देखिन्छ। त्यसपछि coredns देखा पर्यो, जसमा हामीले स्विच गर्यौं र कुनै दुःख थिएन; यो पछि K8s मा पूर्वनिर्धारित DNS सेवा भयो। केहि बिन्दुमा, हामी DNS प्रणालीमा 40 हजार आरपीएस बढ्यौं, र यो समाधान पनि अपर्याप्त भयो। तर, भाग्यले, Nodelocaldns बाहिर आयो, उर्फ नोड स्थानीय क्यास, उर्फ NodeLocal DNSCache.

हामी यो किन प्रयोग गर्छौं? लिनक्स कर्नेलमा एउटा बग छ जुन UDP मा कन्ट्र्याक NAT मार्फत धेरै कलहरू गर्दा, कन्ट्र्याक तालिकाहरूमा प्रविष्टिहरूको लागि दौड अवस्था निम्त्याउँछ, र NAT मार्फत ट्राफिकको केही अंश हराउँछ (सेवा मार्फत प्रत्येक यात्रा NAT हो)। Nodelocaldns ले NAT बाट छुटकारा पाएर र TCP लाई अपस्ट्रिम DNS मा जडान अपग्रेड गरेर, साथै स्थानीय रूपमा अपस्ट्रीम DNS प्रश्नहरू (छोटो 5-सेकेन्ड नकारात्मक क्यास सहित) क्यास गरेर यो समस्या समाधान गर्दछ।

5. पोडहरू तेर्सो र ठाडो रूपमा स्वचालित रूपमा स्केल गर्नुहोस्

के तपाईं विश्वस्तताका साथ भन्न सक्नुहुन्छ कि तपाईंका सबै माइक्रोसर्भिसेसहरू लोडमा दुई देखि तीन गुणा वृद्धिको लागि तयार छन्? तपाईंको अनुप्रयोगहरूमा स्रोतहरू कसरी ठीकसँग आवंटित गर्ने? कार्यभार भन्दा बाहिर चलिरहेको केही पोडहरू राख्नु अनावश्यक हुन सक्छ, तर तिनीहरूलाई पछाडि पछाडि राख्दा सेवामा ट्राफिकमा अचानक वृद्धिबाट डाउनटाइमको जोखिम चल्छ। सेवाहरू जस्तै तेर्सो पोड अटोस्केलर и ठाडो पोड अटोस्केलर.

VPA तपाईंलाई वास्तविक उपयोगको आधारमा पोडमा तपाईंको कन्टेनरहरूको अनुरोधहरू/सीमाहरू स्वचालित रूपमा बढाउन अनुमति दिन्छ। यो कसरी उपयोगी हुन सक्छ? यदि तपाइँसँग पोडहरू छन् जुन कुनै कारणले तेर्सो रूपमा मापन गर्न सकिँदैन (जुन पूर्ण रूपमा भरपर्दो छैन), त्यसपछि तपाइँ VPA लाई यसको स्रोतहरूमा परिवर्तनहरू सुम्पने प्रयास गर्न सक्नुहुन्छ। यसको विशेषता मेट्रिक-सर्भरबाट ऐतिहासिक र हालको डेटामा आधारित सिफारिस प्रणाली हो, त्यसैले यदि तपाइँ स्वचालित रूपमा अनुरोध/सीमाहरू परिवर्तन गर्न चाहनुहुन्न भने, तपाइँ तपाइँका कन्टेनरहरूको लागि सिफारिस गरिएका स्रोतहरू अनुगमन गर्न सक्नुहुन्छ र सीपीयू बचत गर्न सेटिङहरूलाई अनुकूलन गर्न सक्नुहुन्छ। क्लस्टर मा मेमोरी।

https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 बाट लिइएको छवि

Kubernetes मा अनुसूचक सधैं अनुरोध मा आधारित छ। जुनसुकै मान तपाईले त्यहाँ राख्नुहुन्छ, अनुसूचकले यसको आधारमा उपयुक्त नोड खोज्नेछ। क्यूबलेटले पोडलाई कहिले थ्रोटल गर्ने वा मार्ने भनेर बुझ्नको लागि सीमा मानहरू आवश्यक हुन्छ। र एक मात्र महत्त्वपूर्ण प्यारामिटर अनुरोध मान हो, VPA यसको साथ काम गर्नेछ। जब तपाइँ ठाडो रूपमा एप्लिकेसन मापन गर्नुहुन्छ, तपाइँ अनुरोधहरू के हुनुपर्छ भनेर परिभाषित गर्नुहुन्छ। त्यसपछि सीमामा के हुने हो ? यो प्यारामिटर पनि समानुपातिक मापन गरिनेछ।

उदाहरणका लागि, यहाँ सामान्य पोड सेटिङहरू छन्:

resources:
   requests:
     memory: 250Mi
     cpu: 200m
   limits:
     memory: 500Mi
     cpu: 350m

सिफारिस इन्जिनले निर्धारण गर्छ कि तपाईको अनुप्रयोगलाई 300m CPU र 500Mi राम्रोसँग चल्न आवश्यक छ। तपाईंले निम्न सेटिङहरू प्राप्त गर्नुहुनेछ:

resources:
   requests:
     memory: 500Mi
     cpu: 300m
   limits:
     memory: 1000Mi
     cpu: 525m

माथि उल्लेख गरिए अनुसार, यो म्यानिफेस्टमा अनुरोध/सीमा अनुपातमा आधारित समानुपातिक मापन हो:

CPU: 200m → 300m: अनुपात 1:1.75;
मेमोरी: 250Mi → 500Mi: अनुपात 1:2।

यसको सन्दर्भमा HPA, त्यसपछि सञ्चालन को संयन्त्र अधिक पारदर्शी छ। CPU र मेमोरी जस्ता मेट्रिकहरू थ्रेसहोल्ड गरिएका छन्, र यदि सबै प्रतिकृतिहरूको औसत थ्रेसहोल्ड नाघेको छ भने, मूल्य थ्रेसहोल्डभन्दा तल नआएसम्म वा प्रतिकृतिहरूको अधिकतम संख्या नपुग्दासम्म अनुप्रयोगलाई +1 उप द्वारा मापन गरिन्छ।

https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 बाट लिइएको छवि

सामान्य मेट्रिक्स जस्तै CPU र मेमोरीको अतिरिक्त, तपाईंले Prometheus बाट आफ्नो अनुकूलन मेट्रिक्समा थ्रेसहोल्डहरू सेट गर्न सक्नुहुन्छ र यदि तपाइँ सोच्नुहुन्छ कि तपाइँको आवेदन कहिले मापन गर्ने सबैभन्दा सही संकेत हो भने। एकपटक एप्लिकेसन तोकिएको मेट्रिक थ्रेसहोल्डभन्दा तल स्थिर भएपछि, HPA ले पोडहरूलाई प्रतिकृतिहरूको न्यूनतम संख्यामा वा लोडले तोकिएको थ्रेसहोल्ड पूरा नगरेसम्म मापन गर्न थाल्छ।

6. नोड एफिनिटी र पोड एफिनिटी बारे नबिर्सनुहोस्

सबै नोडहरू एउटै हार्डवेयरमा चल्दैनन्, र सबै पोडहरूले गणना-गहन अनुप्रयोगहरू चलाउन आवश्यक पर्दैन। Kubernetes ले तपाइँलाई प्रयोग गरेर नोडहरू र पोडहरूको विशेषज्ञता सेट गर्न अनुमति दिन्छ नोड आत्मीयता и पोड आत्मीयता.

यदि तपाइँसँग नोडहरू छन् जुन कम्प्युट-गहन अपरेसनहरूको लागि उपयुक्त छन् भने, त्यसपछि अधिकतम दक्षताको लागि अनुप्रयोगहरूलाई सम्बन्धित नोडहरूमा बाँध्नु राम्रो हुन्छ। यो प्रयोग गर्न को लागी nodeSelector नोड लेबल संग।

मानौं तपाईंसँग दुईवटा नोडहरू छन्: एउटासँग CPUType=HIGHFREQ र द्रुत कोरहरूको ठूलो संख्या, अर्कोसँग MemoryType=HIGHMEMORY अधिक मेमोरी र छिटो प्रदर्शन। नोडमा डिप्लोइमेन्ट असाइन गर्नु सबैभन्दा सजिलो तरिका हो HIGHFREQखण्डमा थपेर spec यस प्रकार चयनकर्ता:

…
nodeSelector:
	CPUType: HIGHFREQ

यो गर्न को लागी एक अधिक महँगो र विशिष्ट तरिका प्रयोग गर्नु हो nodeAffinity क्षेत्र मा affinity ।। spec। त्यहाँ दुई विकल्पहरू छन्:

requiredDuringSchedulingIgnoredDuringExecution: हार्ड सेटिङ (अनुसूचकले पोडहरू विशेष नोडहरूमा मात्र प्रयोग गर्नेछ (र कतै पनि));
preferredDuringSchedulingIgnoredDuringExecution: सफ्ट सेटिङ (अनुसूचकले निश्चित नोडहरूमा तैनाती गर्ने प्रयास गर्नेछ, र यदि त्यो असफल भयो भने, यसले अर्को उपलब्ध नोडमा डिप्लोय गर्ने प्रयास गर्नेछ)।

तपाईंले नोड लेबलहरू प्रबन्ध गर्नको लागि एक विशिष्ट वाक्यविन्यास निर्दिष्ट गर्न सक्नुहुन्छ, जस्तै In, NotIn, Exists, DoesNotExist, Gt वा Lt। यद्यपि, याद गर्नुहोस् कि लेबलहरूको लामो सूचीमा जटिल विधिहरूले महत्वपूर्ण परिस्थितिहरूमा निर्णय गर्ने क्षमतालाई ढिलो गर्नेछ। अर्को शब्दमा, यसलाई सरल राख्नुहोस्।

माथि उल्लेख गरिए अनुसार, Kubernetes ले तपाइँलाई हालको पोडहरूको आत्मीयता सेट गर्न अनुमति दिन्छ। त्यो हो, तपाइँ निश्चित पोडहरू समान उपलब्धता क्षेत्र (क्लाउडहरूका लागि सान्दर्भिक) वा नोडहरूमा अन्य पोडहरूसँग मिलेर काम गर्छन् भनेर निश्चित गर्न सक्नुहुन्छ।

В podAffinity क्षेत्रहरु affinity ।। spec को अवस्थामा जस्तै समान क्षेत्रहरू उपलब्ध छन् nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution। फरक यति मात्रै हो matchExpressions पोडहरूलाई नोडमा बाँध्नेछ जुन पहिले नै त्यो लेबलको साथ पोड चलिरहेको छ।

Kubernetes पनि एक क्षेत्र प्रदान गर्दछ podAntiAffinity, जसले, यसको विपरित, पोडलाई विशिष्ट पोडहरूसँग नोडमा बाँध्दैन।

अभिव्यक्तिको बारेमा nodeAffinity एउटै सल्लाह दिन सकिन्छ: नियमहरू सरल र तार्किक राख्न प्रयास गर्नुहोस्, नियमहरूको जटिल सेटको साथ पोड विशिष्टता ओभरलोड गर्ने प्रयास नगर्नुहोस्। क्लस्टरका सर्तहरूसँग मेल खाँदैन, शेड्युलरमा अनावश्यक भार सिर्जना गर्ने र समग्र कार्यसम्पादन घटाउने नियम सिर्जना गर्न यो धेरै सजिलो छ।

7. दाग र सहिष्णुता

अनुसूचक व्यवस्थापन गर्न अर्को तरिका छ। यदि तपाईंसँग सयौं नोडहरू र हजारौं माइक्रोसर्भिसेसहरू भएको ठूलो क्लस्टर छ भने, निश्चित नोडहरूमा केही पोडहरूलाई होस्ट गर्न अनुमति दिन धेरै गाह्रो हुन्छ।

दागको संयन्त्र-प्रतिबन्धित नियमहरू-यसको लागि मद्दत गर्दछ। उदाहरण को लागी, केहि परिदृश्यहरु मा तपाईले केहि नोडहरु चलिरहेको पोडहरु लाई निषेध गर्न सक्नुहुन्छ। एक विशिष्ट नोडमा दाग लागू गर्न तपाईंले विकल्प प्रयोग गर्न आवश्यक छ taint kubectl मा। कुञ्जी र मान निर्दिष्ट गर्नुहोस् र त्यसपछि जस्तै दाग गर्नुहोस् NoSchedule वा NoExecute:

$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoSchedule

यो पनि ध्यान दिन लायक छ कि दाग संयन्त्रले तीन मुख्य प्रभावहरूलाई समर्थन गर्दछ: NoSchedule, NoExecute и PreferNoSchedule.

NoSchedule यसको मतलब अहिलेको लागि पोड स्पेसिफिकेशनमा कुनै सम्बन्धित प्रविष्टि हुनेछैन tolerations, यो नोडमा तैनात गर्न सक्षम हुनेछैन (यस उदाहरणमा node10).
PreferNoSchedule - सरलीकृत संस्करण NoSchedule। यस अवस्थामा, अनुसूचकले मिल्दो प्रविष्टि नभएको पोडहरू आवंटित नगर्ने प्रयास गर्नेछ tolerations प्रति नोड, तर यो कडा सीमा होइन। यदि क्लस्टरमा कुनै स्रोतहरू छैनन् भने, त्यसपछि पोडहरू यो नोडमा तैनात गर्न सुरु हुनेछ।
NoExecute - यो प्रभावले पोडहरूको तत्काल निकासीलाई ट्रिगर गर्दछ जुनसँग सम्बन्धित प्रविष्टि छैन tolerations.

चाखलाग्दो कुरा के छ भने, यो व्यवहार सहनशीलता संयन्त्र प्रयोग गरेर रद्द गर्न सकिन्छ। यो सुविधाजनक छ जब त्यहाँ एक "निषिद्ध" नोड छ र तपाईंले यसमा पूर्वाधार सेवाहरू मात्र राख्न आवश्यक छ। यो कसरी गर्ने? केवल ती पोडहरूलाई अनुमति दिनुहोस् जसको लागि उपयुक्त सहिष्णुता छ।

यहाँ पोड विशिष्टता कस्तो देखिन्छ:

spec:
   tolerations:
     - key: "node-role.kubernetes.io/ingress"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"

यसको मतलब यो होइन कि अर्को रिडिप्लोय यो विशेष नोडमा पर्नेछ, यो नोड एफिनिटी मेकानिजम होइन र nodeSelector। तर धेरै सुविधाहरू संयोजन गरेर, तपाईं धेरै लचिलो अनुसूचक सेटिङहरू प्राप्त गर्न सक्नुहुन्छ।

8. पोड डिप्लोइमेन्ट प्राथमिकता सेट गर्नुहोस्

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

Kubernetes Pod प्राथमिकता र Preemption कन्फिगर गर्न विभिन्न तरिकाहरू प्रदान गर्दछ। सेटिङमा धेरै भागहरू हुन्छन्: वस्तु PriorityClass र क्षेत्र विवरण priorityClassName पोड विशिष्टता मा। एउटा उदाहरण हेरौं:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 99999
globalDefault: false
description: "This priority class should be used for very important pods only"

हामी सिर्जना गर्छौं PriorityClass, यसलाई नाम, वर्णन र मूल्य दिनुहोस्। उच्च value, उच्च प्राथमिकता। मान कुनै पनि 32-बिट पूर्णांक 1 भन्दा कम वा बराबर हुन सक्छ। उच्च मानहरू मिशन-क्रिटिकल प्रणाली पोडहरूका लागि आरक्षित छन् जुन सामान्यतया प्रीम्प्ट गर्न सकिँदैन। विस्थापन तब मात्र हुन्छ जब उच्च-प्राथमिकताको पोडमा घुम्ने ठाउँ छैन, त्यसपछि निश्चित नोडबाट केही पोडहरू खाली गरिनेछ। यदि यो संयन्त्र तपाईंको लागि धेरै कठोर छ भने, तपाईं विकल्प थप्न सक्नुहुन्छ preemptionPolicy: Never, र त्यसपछि त्यहाँ कुनै पूर्वाग्रह हुनेछैन, पोड लाममा पहिले उभिनेछ र अनुसूचकलाई यसको लागि निःशुल्क स्रोतहरू फेला पार्न पर्खनेछ।

अर्को, हामी एउटा पोड सिर्जना गर्छौं जसमा हामी नाम संकेत गर्छौं priorityClassName:

apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    role: myrole
 spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
  priorityClassName: high-priority

तपाईंले आफूलाई मनपर्ने धेरै प्राथमिकता कक्षाहरू सिर्जना गर्न सक्नुहुन्छ, यद्यपि यसबाट टाढा नपर्न सिफारिस गरिन्छ (भन्नुहोस्, आफूलाई निम्न, मध्यम र उच्च प्राथमिकतामा सीमित गर्नुहोस्)।

तसर्थ, यदि आवश्यक छ भने, तपाईंले nginx-ingress-controller, coredns, आदि जस्ता महत्वपूर्ण सेवाहरू प्रयोग गर्ने दक्षता बढाउन सक्नुहुन्छ।

9. ETCD क्लस्टर अप्टिमाइज गर्नुहोस्

ETCD लाई सम्पूर्ण क्लस्टरको मस्तिष्क भन्न सकिन्छ। यो डाटाबेसको सञ्चालन उच्च स्तरमा कायम राख्न धेरै महत्त्वपूर्ण छ, किनकि क्यूबमा सञ्चालनको गति यसमा निर्भर गर्दछ। एक उचित मानक, र एकै समयमा, राम्रो समाधान मास्टर नोडहरूमा ETCD क्लस्टर राख्न को लागी kube-apiserver मा न्यूनतम ढिलाइ गर्न को लागी हुनेछ। यदि तपाइँ यो गर्न सक्नुहुन्न भने, ETCD लाई सकेसम्म नजिक राख्नुहोस्, सहभागीहरू बीच राम्रो ब्यान्डविथको साथ। ETCD बाट कतिवटा नोडहरू क्लस्टरलाई हानि नगरी बाहिर जान सक्छन् भन्ने कुरामा पनि ध्यान दिनुहोस्

ध्यान राख्नुहोस् कि क्लस्टरमा सदस्यहरूको संख्या अत्यधिक बढाउँदा कार्यसम्पादनको खर्चमा गल्ती सहिष्णुता बढाउन सक्छ, सबै कुरा मध्यस्थतामा हुनुपर्छ।

यदि हामी सेवा सेटअप गर्ने बारे कुरा गर्छौं भने, त्यहाँ केही सिफारिसहरू छन्:

क्लस्टरको साइजमा आधारित राम्रो हार्डवेयर छ (तपाईले पढ्न सक्नुहुन्छ यहाँ).
यदि तपाईंले DCs को एक जोडी वा तपाईंको नेटवर्क र डिस्कहरू बीचमा क्लस्टर फैलाउनुभएको छ भने केही प्यारामिटरहरू ट्वीक गर्नुहोस् (तपाईंले पढ्न सक्नुहुन्छ। यहाँ).

निष्कर्षमा

यस लेखले हाम्रो टोलीले पालना गर्ने प्रयास गर्ने बुँदाहरू वर्णन गर्दछ। यो कार्यहरूको चरण-दर-चरण विवरण होइन, तर विकल्पहरू जुन क्लस्टर ओभरहेड अनुकूलन गर्न उपयोगी हुन सक्छ। यो स्पष्ट छ कि प्रत्येक क्लस्टर आफ्नै तरिकामा अद्वितीय छ, र कन्फिगरेसन समाधानहरू धेरै फरक हुन सक्छ, त्यसैले तपाइँ तपाइँको Kubernetes क्लस्टर कसरी निगरानी गर्नुहुन्छ र तपाइँ कसरी यसको कार्यसम्पादन सुधार गर्नुहुन्छ भन्ने बारे तपाइँको प्रतिक्रिया प्राप्त गर्न रोचक हुनेछ। टिप्पणीहरूमा आफ्नो अनुभव साझा गर्नुहोस्, यो जान्न रोचक हुनेछ।

स्रोत: www.habr.com

नौ Kubernetes प्रदर्शन सुझावहरू