Kubernetes मा लोड सन्तुलन र दीर्घ-जीवन जडानहरू मापन

यो लेखले तपाईंलाई Kubernetes मा लोड ब्यालेन्सिङ कसरी काम गर्छ, लामो समयसम्म चल्ने जडानहरू मापन गर्दा के हुन्छ र तपाईंले HTTP/2, gRPC, RSockets, AMQP, वा अन्य दीर्घकालीन प्रोटोकलहरू प्रयोग गर्नुहुन्छ भने किन क्लाइन्ट-साइड ब्यालेन्सिङलाई विचार गर्नुपर्छ भन्ने कुरा बुझ्न मद्दत गर्नेछ। । 

Kubernetes मा ट्राफिक कसरी पुन: वितरण गरिन्छ भन्ने बारे थोरै 

Kubernetes अनुप्रयोगहरू तैनातीका लागि दुई सुविधाजनक एब्स्ट्र्याक्शनहरू प्रदान गर्दछ: सेवाहरू र तैनातीहरू।

डिप्लोयमेन्टहरूले कुनै पनि समयमा तपाइँको आवेदनको कति र कति प्रतिहरू चल्नु पर्छ भनेर वर्णन गर्दछ। प्रत्येक एप्लिकेसनलाई पोडको रूपमा डिप्लोइ गरिएको छ र आईपी ठेगाना तोकिएको छ।

सेवाहरू लोड ब्यालेन्सरको कार्यमा समान छन्। तिनीहरू धेरै पोडहरूमा ट्राफिक वितरण गर्न डिजाइन गरिएको हो।

हेरौं यो कस्तो देखिन्छ.

1. तलको रेखाचित्रमा तपाईले एउटै एप्लिकेसन र लोड ब्यालेन्सरको तीनवटा उदाहरणहरू देख्न सक्नुहुन्छ:

   

2. लोड ब्यालेन्सरलाई सेवा भनिन्छ र आईपी ठेगाना तोकिएको छ। कुनै पनि आगमन अनुरोध पोडहरू मध्ये एकमा पुन: निर्देशित गरिन्छ:

   

3. परिनियोजन परिदृश्यले अनुप्रयोगको उदाहरणहरूको संख्या निर्धारण गर्दछ। तपाईंले लगभग कहिल्यै सीधा अन्तर्गत विस्तार गर्नु पर्दैन:

   

4. प्रत्येक पोडलाई आफ्नै IP ठेगाना तोकिएको छ:

   

सेवाहरूलाई IP ठेगानाहरूको संग्रहको रूपमा सोच्नु उपयोगी छ। प्रत्येक पटक तपाईंले सेवा पहुँच गर्दा, आईपी ठेगानाहरू मध्ये एउटा सूचीबाट चयन गरिन्छ र गन्तव्य ठेगानाको रूपमा प्रयोग गरिन्छ।

यो यस्तो देखिन्छ.

1. एक कर्ल 10.96.45.152 अनुरोध सेवामा प्राप्त भयो:

   

2. सेवाले आफ्नो गन्तव्यको रूपमा तीन पोड ठेगानाहरू मध्ये एक चयन गर्दछ:

   

3. ट्राफिक एक विशिष्ट पोडमा रिडिरेक्ट गरिएको छ:

   

यदि तपाइँको एप्लिकेसनमा फ्रन्टएन्ड र ब्याकएन्ड समावेश छ भने, तपाइँसँग प्रत्येकको लागि सेवा र डिप्लोयमेन्ट दुवै हुनेछ।

जब फ्रन्टएन्डले ब्याकइन्डलाई अनुरोध गर्दछ, ब्याकइन्डले कति पोडहरू सेवा गर्दछ भनेर ठ्याक्कै जान्न आवश्यक छैन: त्यहाँ एक, दस, वा सय हुन सक्छ।

साथै, फ्रन्टएन्डलाई ब्याकएन्ड सेवा गर्ने पोडहरूको ठेगानाहरूको बारेमा केही थाहा छैन।

जब फ्रन्टएन्डले ब्याकएन्डमा अनुरोध गर्दछ, यसले ब्याकएन्ड सेवाको आईपी ठेगाना प्रयोग गर्दछ, जुन परिवर्तन हुँदैन।

यो यस्तो देखिन्छ.

1. 1 अन्तर्गत आन्तरिक ब्याकइन्ड घटक अनुरोध गर्दछ। ब्याकइन्डको लागि एक विशिष्ट चयन गर्नुको सट्टा, यसले सेवालाई अनुरोध गर्दछ:

   

2. सेवाले गन्तव्य ठेगानाको रूपमा ब्याकएन्ड पोडहरू मध्ये एउटा चयन गर्दछ:

   

3. ट्राफिक Pod 1 बाट Pod 5 मा जान्छ, सेवा द्वारा चयन गरिएको:

   

4. 1 मुनिलाई थाहा छैन कि 5 मुनिका जस्तै कति पोडहरू सेवा पछाडि लुकेका छन्:

   

तर सेवाले अनुरोधहरू कसरी वितरण गर्छ? यस्तो देखिन्छ कि राउन्ड-रोबिन सन्तुलन प्रयोग गरिएको छ? यसलाई बाहिर निकालौं। 

Kubernetes सेवाहरूमा सन्तुलन

Kubernetes सेवाहरू अवस्थित छैनन्। आईपी ​​ठेगाना र पोर्ट तोकिएको सेवाको लागि कुनै प्रक्रिया छैन।

तपाईंले क्लस्टरमा कुनै पनि नोडमा लग इन गरेर र netstat -ntlp आदेश चलाएर यसलाई प्रमाणित गर्न सक्नुहुन्छ।

तपाईंले सेवामा आवंटित IP ठेगाना पनि फेला पार्न सक्नुहुने छैन।

सेवाको IP ठेगाना नियन्त्रण तहमा, नियन्त्रकमा अवस्थित छ, र डाटाबेसमा रेकर्ड गरिएको छ - etcd। उही ठेगाना अर्को घटक - kube-proxy द्वारा प्रयोग गरिन्छ।
Kube-proxy ले सबै सेवाहरूको लागि IP ठेगानाहरूको सूची प्राप्त गर्दछ र क्लस्टरमा प्रत्येक नोडमा iptables नियमहरूको सेट उत्पन्न गर्दछ।

यी नियमहरू भन्छन्: "यदि हामीले सेवाको आईपी ठेगाना देख्यौं भने, हामीले अनुरोधको गन्तव्य ठेगाना परिमार्जन गर्न आवश्यक छ र यसलाई कुनै एक पोडमा पठाउनुपर्छ।"

सेवा आईपी ठेगाना प्रविष्टि बिन्दुको रूपमा मात्र प्रयोग गरिन्छ र त्यो आईपी ठेगाना र पोर्ट सुन्ने कुनै प्रक्रियाद्वारा सेवा गरिएको छैन।

यसलाई हेरौं. 

1. तीन नोडहरूको क्लस्टरलाई विचार गर्नुहोस्। प्रत्येक नोडमा पोडहरू छन्:

   

2. बाँधिएको पोड पेन्टेड बेज सेवाको अंश हो। किनभने सेवा प्रक्रियाको रूपमा अवस्थित छैन, यो खैरो रंगमा देखाइएको छ:

   

3. पहिलो पोडले सेवा अनुरोध गर्दछ र सम्बन्धित पोडहरू मध्ये एउटामा जानुपर्छ:

   

4. तर सेवा छैन, प्रक्रिया अवस्थित छैन। यस्ले कसरी काम गर्छ?

   

5. अनुरोधले नोड छोड्नु अघि, यो iptables नियमहरू मार्फत जान्छ:

   

6. iptables नियमहरूलाई थाहा छ कि सेवा अवस्थित छैन र त्यस सेवासँग सम्बन्धित पोडहरूको IP ठेगानाहरू मध्ये एउटासँग यसको IP ठेगाना बदल्नुहोस्:

   

7. अनुरोधले गन्तव्य ठेगानाको रूपमा मान्य IP ठेगाना प्राप्त गर्दछ र सामान्य रूपमा प्रशोधन गरिन्छ:

   

8. नेटवर्क टोपोलोजीमा निर्भर गर्दै, अनुरोध अन्ततः पोडमा पुग्छ:

   

के iptables ले ब्यालेन्स लोड गर्न सक्छ?

होइन, iptables फिल्टरिङको लागि प्रयोग गरिन्छ र सन्तुलनको लागि डिजाइन गरिएको थिएन।

यद्यपि, यो काम गर्ने नियमहरूको सेट लेख्न सम्भव छ स्यूडो-ब्यालेन्सर.

र यो कुबेरनेटमा लागू गरिएको कुरा हो।

यदि तपाईंसँग तीनवटा पोडहरू छन् भने, kube-proxy ले निम्न नियमहरू लेख्नेछ:

1. 33% को सम्भाव्यताको साथ पहिलो उप चयन गर्नुहोस्, अन्यथा अर्को नियममा जानुहोस्।
2. ५०% को सम्भावना भएको दोस्रो रोज्नुहोस्, अन्यथा अर्को नियममा जानुहोस्।
3. अन्तर्गत तेस्रो चयन गर्नुहोस्।

यस प्रणालीले प्रत्येक पोडलाई 33% को सम्भाव्यताको साथ चयन गरेको परिणाम हो।

र त्यहाँ कुनै ग्यारेन्टी छैन कि पोड 2 पोड 1 पछि अर्को छनौट हुनेछ।

भन्नु: iptables अनियमित वितरण संग एक सांख्यिकीय मोड्युल प्रयोग गर्दछ। यसैले, सन्तुलन एल्गोरिथ्म अनियमित चयन मा आधारित छ।

अब तपाईंले सेवाहरूले कसरी काम गर्छ भनी बुझ्नुभयो, थप रोचक सेवा परिदृश्यहरू हेरौं।

Kubernetes मा लामो समयसम्म जडानहरू पूर्वनिर्धारित रूपमा मापन गर्दैनन्

फ्रन्टएन्डबाट ब्याकइन्डमा प्रत्येक HTTP अनुरोधलाई छुट्टै TCP जडानद्वारा सेवा गरिन्छ, जुन खोलिएको र बन्द हुन्छ।

यदि फ्रन्टएन्डले ब्याकइन्डमा प्रति सेकेन्ड 100 अनुरोधहरू पठाउँछ भने, त्यसपछि 100 विभिन्न TCP जडानहरू खोलिन्छन् र बन्द हुन्छन्।

तपाईंले एउटा TCP जडान खोलेर र त्यसपछिका सबै HTTP अनुरोधहरूको लागि प्रयोग गरेर अनुरोध प्रशोधन समय र लोड घटाउन सक्नुहुन्छ।

HTTP प्रोटोकलमा HTTP किप-लाइभ, वा जडान पुन: प्रयोग भनिने सुविधा छ। यस अवस्थामा, एकल TCP जडान धेरै HTTP अनुरोधहरू र प्रतिक्रियाहरू पठाउन र प्राप्त गर्न प्रयोग गरिन्छ:

यो सुविधा पूर्वनिर्धारित रूपमा सक्षम गरिएको छैन: सर्भर र क्लाइन्ट दुवै तदनुसार कन्फिगर हुनुपर्छ।

सेटअप आफैंमा धेरै प्रोग्रामिङ भाषाहरू र वातावरणहरूको लागि सरल र पहुँचयोग्य छ।

यहाँ विभिन्न भाषाहरूमा उदाहरणका लागि केही लिङ्कहरू छन्:

• Node.js मा जीवित राख्नुहोस्
• वसन्त बुटमा जीवित राख्नुहोस्
• पाइथनमा जीवित राख्नुहोस्
• .NET मा जीवित राख्नुहोस्

यदि हामीले Kubernetes सेवामा Keep-alive प्रयोग गर्छौं भने के हुन्छ?
मानौं कि दुबै फ्रन्टएन्ड र ब्याकएन्ड समर्थन जीवित रहन्छ।

हामीसँग फ्रन्टएन्डको एक प्रतिलिपि र ब्याकएन्डको तीन प्रतिलिपिहरू छन्। फ्रन्टएन्डले पहिलो अनुरोध गर्दछ र ब्याकइन्डमा TCP जडान खोल्छ। अनुरोध सेवामा पुग्छ, ब्याकएन्ड पोडहरू मध्ये एउटा गन्तव्य ठेगानाको रूपमा चयन गरिएको छ। ब्याकइन्डले प्रतिक्रिया पठाउँछ, र फ्रन्टएन्डले यसलाई प्राप्त गर्दछ।

प्रतिक्रिया प्राप्त गरेपछि TCP जडान बन्द भएको सामान्य अवस्थाको विपरीत, यसलाई अब थप HTTP अनुरोधहरूको लागि खुला राखिएको छ।

यदि फ्रन्टएन्डले ब्याकइन्डमा थप अनुरोधहरू पठाउँछ भने के हुन्छ?

यी अनुरोधहरू फर्वार्ड गर्न, खुला TCP जडान प्रयोग गरिनेछ, सबै अनुरोधहरू उही ब्याकइन्डमा जानेछन् जहाँ पहिलो अनुरोध गएको थियो।

iptables ले ट्राफिक पुन: वितरण गर्नु हुँदैन?

यस मामला मा छैन।

जब TCP जडान बनाइन्छ, यो iptables नियमहरू मार्फत जान्छ, जसले ट्राफिक जाने ठाउँमा एक विशिष्ट ब्याकइन्ड चयन गर्दछ।

सबै पछिका अनुरोधहरू पहिले नै खुला TCP जडानमा भएकाले, iptables नियमहरू अब बोलाइँदैन।

हेरौं यो कस्तो देखिन्छ.

1. पहिलो पोडले सेवामा अनुरोध पठाउँछ:

   

2. तपाईलाई पहिले नै थाहा छ अब के हुनेछ। सेवा अवस्थित छैन, तर त्यहाँ iptables नियमहरू छन् जसले अनुरोधलाई प्रक्रिया गर्नेछ:

   

3. ब्याकएन्ड पोडहरू मध्ये एउटा गन्तव्य ठेगानाको रूपमा चयन गरिनेछ:

   

4. अनुरोध पोडमा पुग्छ। यस बिन्दुमा, दुई पोडहरू बीच एक निरन्तर TCP जडान स्थापित हुनेछ:

   

5. पहिलो पोडबाट कुनै पनि पछिको अनुरोध पहिले नै स्थापित जडान मार्फत जान्छ:

   

परिणाम छिटो प्रतिक्रिया समय र उच्च थ्रुपुट हो, तर तपाइँ ब्याकएन्ड मापन गर्ने क्षमता गुमाउनुहुन्छ।

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

के यो तय गर्न सकिन्छ?

Kubernetes लाई निरन्तर जडानहरू कसरी सन्तुलित गर्ने भनेर थाहा छैन, यो कार्य तपाईंमा आउँछ।

सेवाहरू IP ठेगानाहरू र पोर्टहरूको सङ्ग्रह हो जसलाई endpoints भनिन्छ।

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

वा थप आवेदन दिनुहोस् जटिल सन्तुलन एल्गोरिदम.

सन्तुलनको लागि जिम्मेवार ग्राहक-साइड कोडले यो तर्क पालना गर्नुपर्छ:

1. सेवाबाट अन्तिम बिन्दुहरूको सूची प्राप्त गर्नुहोस्।
2. प्रत्येक अन्तिम बिन्दुको लागि निरन्तर जडान खोल्नुहोस्।
3. जब अनुरोध गर्न आवश्यक छ, खुला जडानहरू मध्ये एक प्रयोग गर्नुहोस्।
4. अन्तिम बिन्दुहरूको सूची नियमित रूपमा अद्यावधिक गर्नुहोस्, नयाँ सिर्जना गर्नुहोस् वा सूची परिवर्तन भएमा पुरानो निरन्तर जडानहरू बन्द गर्नुहोस्।

यो कस्तो देखिने छ.

1. सेवामा अनुरोध पठाउने पहिलो पोडको सट्टा, तपाइँ ग्राहक पक्षमा अनुरोधहरू सन्तुलन गर्न सक्नुहुन्छ:

   

2. तपाईले कोड लेख्नु पर्छ जुन कुन पोडहरू सेवाको अंश हो भनेर सोध्छ:

   

3. एकचोटि तपाइँसँग सूची भएपछि, यसलाई ग्राहक पक्षमा बचत गर्नुहोस् र पोडहरूमा जडान गर्न प्रयोग गर्नुहोस्:

   

4. तपाईं लोड सन्तुलन एल्गोरिथ्मको लागि जिम्मेवार हुनुहुन्छ:

   

अब प्रश्न उठ्छ: के यो समस्या HTTP किप-लाइभमा मात्र लागू हुन्छ?

ग्राहक-साइड लोड सन्तुलन

HTTP एक मात्र प्रोटोकल होइन जसले निरन्तर TCP जडानहरू प्रयोग गर्न सक्छ।

यदि तपाइँको एप्लिकेसनले डाटाबेस प्रयोग गर्दछ भने, तपाइँले प्रत्येक पटक अनुरोध गर्न वा डाटाबेसबाट कागजात पुन: प्राप्त गर्न आवश्यक हुँदा TCP जडान खोलिएको छैन। 

यसको सट्टा, डाटाबेसमा निरन्तर TCP जडान खोलिन्छ र प्रयोग गरिन्छ।

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

एउटा डाटाबेस प्रतिकृति अन्य भन्दा बढी लोड हुनेछ। Kube-proxy र Kubernetes सन्तुलन जडानहरू मद्दत गर्दैन। तपाईंले आफ्नो डाटाबेसमा प्रश्नहरू सन्तुलन गर्न ख्याल गर्नुपर्छ।

तपाईले डेटाबेसमा जडान गर्न कुन पुस्तकालय प्रयोग गर्नुहुन्छ भन्ने आधारमा, तपाईसँग यो समस्या समाधान गर्नका लागि विभिन्न विकल्पहरू हुन सक्छन्।

तल Node.js बाट MySQL डाटाबेस क्लस्टर पहुँच गर्ने एउटा उदाहरण छ:

var mysql = require('mysql');
var poolCluster = mysql.createPoolCluster();

var endpoints = /* retrieve endpoints from the Service */

for (var [index, endpoint] of endpoints) {
  poolCluster.add(`mysql-replica-${index}`, endpoint);
}

// Make queries to the clustered MySQL database

त्यहाँ धेरै अन्य प्रोटोकलहरू छन् जसले निरन्तर TCP जडानहरू प्रयोग गर्दछ:

• WebSockets र सुरक्षित WebSockets
• HTTP / 2
• gRPC
• RSockets
• AMQP

तपाइँ पहिले नै यी धेरै प्रोटोकलहरूसँग परिचित हुनुपर्छ।

तर यदि यी प्रोटोकलहरू धेरै लोकप्रिय छन् भने, किन त्यहाँ एक मानक सन्तुलन समाधान छैन? किन ग्राहक तर्क परिवर्तन गर्न आवश्यक छ? त्यहाँ एक देशी Kubernetes समाधान छ?

Kube-proxy र iptables Kubernetes मा डिप्लोइ गर्दा धेरै सामान्य प्रयोग केसहरू कभर गर्न डिजाइन गरिएको हो। यो सुविधाको लागि हो।

यदि तपाइँ वेब सेवा प्रयोग गर्दै हुनुहुन्छ जसले REST API लाई उजागर गर्दछ, तपाइँ भाग्यमा हुनुहुन्छ - यस अवस्थामा, निरन्तर TCP जडानहरू प्रयोग गरिँदैन, तपाइँ कुनै पनि Kubernetes सेवा प्रयोग गर्न सक्नुहुन्छ।

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

यद्यपि, त्यहाँ पक्कै पनि विकल्पहरू छन् जसले मद्दत गर्न सक्छ।

Kubernetes मा दीर्घकालीन जडानहरू सन्तुलन

Kubernetes मा चार प्रकारका सेवाहरू छन्:

1. क्लस्टरआईपी
2. नोडपोर्ट
3. लोड ब्यालेन्सर
4. टाउको रहित

पहिलो तीन सेवाहरू भर्चुअल आईपी ठेगानामा आधारित छन्, जुन iptables नियमहरू निर्माण गर्न kube-proxy द्वारा प्रयोग गरिन्छ। तर सबै सेवाको आधारभूत आधार टाउकोविहीन सेवा हो।

हेडलेस सेवासँग सम्बन्धित कुनै आईपी ठेगाना छैन र यसले आईपी ठेगानाहरूको सूची र यससँग सम्बन्धित पोडहरू (अन्तबिन्दुहरू) को पोर्टहरू पुन: प्राप्त गर्नको लागि मात्र एक संयन्त्र प्रदान गर्दछ।

सबै सेवाहरू हेडलेस सेवामा आधारित छन्।

ClusterIP सेवा केही थपको साथ हेडलेस सेवा हो: 

1. व्यवस्थापन तहले यसलाई IP ठेगाना प्रदान गर्दछ।
2. Kube-proxy ले आवश्यक iptables नियमहरू उत्पन्न गर्दछ।

यस तरिकाले तपाइँ kube-proxy लाई बेवास्ता गर्न सक्नुहुन्छ र तपाइँको आवेदन ब्यालेन्स लोड गर्न हेडलेस सेवाबाट प्राप्त अन्तिम बिन्दुहरूको सूची सीधै प्रयोग गर्न सक्नुहुन्छ।

तर हामी कसरी क्लस्टरमा तैनात सबै अनुप्रयोगहरूमा समान तर्क थप्न सक्छौं?

यदि तपाइँको अनुप्रयोग पहिले नै तैनाथ गरिएको छ भने, यो कार्य असम्भव देखिन सक्छ। यद्यपि, त्यहाँ एक वैकल्पिक विकल्प छ।

सेवा मेषले तपाईंलाई मद्दत गर्नेछ

तपाईंले सायद पहिले नै ध्यान दिनुभएको छ कि क्लाइन्ट-साइड लोड ब्यालेन्सिङ रणनीति एकदम मानक छ।

जब अनुप्रयोग सुरु हुन्छ, यो:

1. सेवाबाट IP ठेगानाहरूको सूची प्राप्त गर्दछ।
2. जडान पूल खोल्छ र मर्मत गर्दछ।
3. समय समयमा अन्तिम बिन्दुहरू थपेर वा हटाएर पूल अद्यावधिक गर्दछ।

एक पटक अनुप्रयोगले अनुरोध गर्न चाहन्छ, यो:

1. केही तर्क प्रयोग गरेर उपलब्ध जडान चयन गर्दछ (जस्तै राउन्ड-रोबिन)।
2. अनुरोध कार्यान्वयन गर्दछ।

यी चरणहरू दुवै WebSockets, gRPC, र AMQP जडानहरूको लागि काम गर्दछ।

तपाईं यो तर्कलाई छुट्टै पुस्तकालयमा अलग गर्न सक्नुहुन्छ र यसलाई आफ्नो अनुप्रयोगहरूमा प्रयोग गर्न सक्नुहुन्छ।

यद्यपि, तपाईं यसको सट्टा Istio वा Linkerd जस्ता सेवा मेसहरू प्रयोग गर्न सक्नुहुन्छ।

सेवा जालले तपाइँको आवेदनलाई प्रक्रियाको साथ बढाउँछ जुन:

1. स्वचालित रूपमा सेवा IP ठेगानाहरूको लागि खोजी गर्दछ।
2. WebSockets र gRPC जस्ता जडानहरू परीक्षण गर्दछ।
3. सही प्रोटोकल प्रयोग गरी सन्तुलन अनुरोधहरू।

सेवा जालले क्लस्टर भित्र ट्राफिक व्यवस्थापन गर्न मद्दत गर्दछ, तर यो धेरै संसाधन-गहन छ। अन्य विकल्पहरूले तेस्रो-पक्ष पुस्तकालयहरू जस्तै Netflix रिबन वा दूत जस्तै प्रोग्रामेबल प्रोक्सीहरू प्रयोग गर्दैछन्।

यदि तपाईंले सन्तुलनका मुद्दाहरूलाई बेवास्ता गर्नुभयो भने के हुन्छ?

तपाईं लोड ब्यालेन्सिङ प्रयोग नगर्ने छनौट गर्न सक्नुहुन्छ र अझै पनि कुनै परिवर्तनहरू याद गर्नुहुन्न। केही काम परिदृश्यहरू हेरौं।

यदि तपाइँसँग सर्भर भन्दा बढी ग्राहकहरू छन् भने, यो त्यस्तो ठूलो समस्या होइन।

मानौं त्यहाँ पाँच क्लाइन्टहरू छन् जुन दुई सर्भरहरूमा जडान हुन्छन्। यदि त्यहाँ कुनै सन्तुलन छैन भने, दुबै सर्भरहरू प्रयोग गरिनेछन्:

जडानहरू समान रूपमा वितरण नहुन सक्छ: सायद चार ग्राहकहरू एउटै सर्भरमा जडान भएका छन्, तर त्यहाँ दुवै सर्भरहरू प्रयोग हुने राम्रो मौका छ।

यो भन्दा बढी समस्या भनेको विपरीत परिदृश्य हो।

यदि तपाइँसँग कम ग्राहकहरू र धेरै सर्भरहरू छन् भने, तपाइँका स्रोतहरू कम उपयोग हुन सक्छ र एक सम्भावित बाधा देखा पर्नेछ।

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

बाँकी सर्भरहरू निष्क्रिय हुनेछन्:

यदि यी दुई सर्भरहरूले ग्राहक अनुरोधहरू ह्यान्डल गर्न सक्दैनन् भने, तेर्सो स्केलिंगले मद्दत गर्दैन।

निष्कर्षमा

Kubernetes सेवाहरू धेरै मानक वेब अनुप्रयोग परिदृश्यहरूमा काम गर्न डिजाइन गरिएको हो।

यद्यपि, एकपटक तपाईले एप्लिकेसन प्रोटोकलहरूसँग काम गर्न थाल्नुभयो जसले निरन्तर TCP जडानहरू प्रयोग गर्दछ, जस्तै डाटाबेस, gRPC वा WebSockets, सेवाहरू अब उपयुक्त हुँदैनन्। Kubernetes ले लगातार TCP जडानहरू सन्तुलन गर्न आन्तरिक संयन्त्र प्रदान गर्दैन।

यसको मतलब तपाईंले क्लाइन्ट-साइड सन्तुलनलाई ध्यानमा राखेर अनुप्रयोगहरू लेख्नुपर्छ।

टोलीले तयार पारेको अनुवाद Kubernetes aaS Mail.ru बाट.

बिषयमा अरु के पढ्नु होला:

1. Kubernetes मा स्वत: स्केलिङ को तीन स्तर र कसरी प्रभावकारी रूपमा प्रयोग गर्ने. 
2. कार्यान्वयनको लागि टेम्प्लेटको साथ पाइरेसीको भावनामा Kubernetes.
3. डिजिटल रूपान्तरण बारे हाम्रो टेलिग्राम च्यानल.

स्रोत: www.habr.com