कुबेरनेट्स में लोड संतुलन और लंबे समय तक चलने वाले कनेक्शन को स्केल करना

यह आलेख आपको यह समझने में मदद करेगा कि कुबेरनेट्स में लोड संतुलन कैसे काम करता है, लंबे समय तक चलने वाले कनेक्शन को स्केल करते समय क्या होता है, और यदि आप HTTP/2, gRPC, RSockets, AMQP, या अन्य लंबे समय तक चलने वाले प्रोटोकॉल का उपयोग करते हैं तो आपको क्लाइंट-साइड संतुलन पर विचार क्यों करना चाहिए। . 

कुबेरनेट्स में ट्रैफ़िक का पुनर्वितरण कैसे किया जाता है, इसके बारे में थोड़ा 

कुबेरनेट्स अनुप्रयोगों को तैनात करने के लिए दो सुविधाजनक सार प्रदान करता है: सेवाएँ और तैनाती।

परिनियोजन वर्णन करता है कि किसी भी समय आपके एप्लिकेशन की कितनी और कैसे प्रतियां चलनी चाहिए। प्रत्येक एप्लिकेशन को पॉड के रूप में तैनात किया जाता है और उसे एक आईपी पता सौंपा जाता है।

सेवाएँ लोड बैलेंसर के कार्य के समान हैं। वे कई पॉड्स में ट्रैफ़िक वितरित करने के लिए डिज़ाइन किए गए हैं।

आइए देखें कि यह कैसा दिखता है.

1. नीचे दिए गए चित्र में आप एक ही एप्लिकेशन के तीन उदाहरण और एक लोड बैलेंसर देख सकते हैं:

   

2. लोड बैलेंसर को सेवा कहा जाता है और उसे एक आईपी पता सौंपा जाता है। कोई भी आने वाला अनुरोध किसी एक पॉड पर पुनर्निर्देशित किया जाता है:

   

3. परिनियोजन परिदृश्य एप्लिकेशन के उदाहरणों की संख्या निर्धारित करता है। आपको लगभग कभी भी सीधे तौर पर विस्तार नहीं करना पड़ेगा:

   

4. प्रत्येक पॉड को अपना स्वयं का आईपी पता सौंपा गया है:

   

सेवाओं को आईपी पतों के संग्रह के रूप में सोचना उपयोगी है। हर बार जब आप सेवा तक पहुंचते हैं, तो सूची से एक आईपी पते का चयन किया जाता है और गंतव्य पते के रूप में उपयोग किया जाता है।

यह इस तरह दिख रहा है.

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

   

2. सेवा अपने गंतव्य के रूप में तीन पॉड पतों में से एक का चयन करती है:

   

3. ट्रैफ़िक को एक विशिष्ट पॉड पर पुनर्निर्देशित किया जाता है:

   

यदि आपके एप्लिकेशन में फ्रंटएंड और बैकएंड शामिल हैं, तो आपके पास प्रत्येक के लिए एक सेवा और एक तैनाती दोनों होगी।

जब फ्रंटएंड बैकएंड से अनुरोध करता है, तो उसे यह जानने की ज़रूरत नहीं है कि बैकएंड कितने पॉड परोसता है: एक, दस या सौ हो सकते हैं।

इसके अलावा, फ्रंटएंड को बैकएंड की सेवा देने वाले पॉड्स के पते के बारे में कुछ भी पता नहीं है।

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

यहाँ यह कैसे दिखता है.

1. 1 के तहत आंतरिक बैकएंड घटक का अनुरोध करता है। बैकएंड के लिए किसी विशिष्ट को चुनने के बजाय, यह सेवा से अनुरोध करता है:

   

2. सेवा गंतव्य पते के रूप में बैकएंड पॉड्स में से एक का चयन करती है:

   

3. ट्रैफ़िक पॉड 1 से पॉड 5 तक जाता है, सेवा द्वारा चयनित:

   

4. अंडर 1 को ठीक से पता नहीं है कि सेवा के पीछे अंडर 5 जैसे कितने पॉड छिपे हुए हैं:

   

लेकिन सेवा वास्तव में अनुरोधों को कैसे वितरित करती है? ऐसा लगता है जैसे राउंड-रॉबिन संतुलन का उपयोग किया जाता है? आइए इसका पता लगाएं। 

कुबेरनेट्स सेवाओं में संतुलन

कुबेरनेट्स सेवाएँ मौजूद नहीं हैं। उस सेवा के लिए कोई प्रक्रिया नहीं है जिसे आईपी पता और पोर्ट सौंपा गया हो।

आप क्लस्टर में किसी भी नोड में लॉग इन करके और नेटस्टैट -एनटीएलपी कमांड चलाकर इसे सत्यापित कर सकते हैं।

आप सेवा के लिए आवंटित आईपी पता भी नहीं ढूंढ पाएंगे।

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

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

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

आइए इस पर नजर डालें. 

1. तीन नोड्स के एक समूह पर विचार करें। प्रत्येक नोड में पॉड हैं:

   

2. बेज रंग से रंगे हुए बंधे हुए पॉड्स सेवा का हिस्सा हैं। क्योंकि सेवा एक प्रक्रिया के रूप में मौजूद नहीं है, इसे ग्रे रंग में दिखाया गया है:

   

3. पहला पॉड एक सेवा का अनुरोध करता है और उसे संबंधित पॉड में से किसी एक पर जाना होगा:

   

4. लेकिन सेवा मौजूद नहीं है, प्रक्रिया मौजूद नहीं है। यह कैसे काम करता है?

   

5. अनुरोध नोड छोड़ने से पहले, यह iptables नियमों से गुजरता है:

   

6. आईपीटेबल्स नियम जानते हैं कि सेवा मौजूद नहीं है और उसके आईपी पते को उस सेवा से जुड़े पॉड्स के आईपी पते में से एक से बदल देते हैं:

   

7. अनुरोध को गंतव्य पते के रूप में एक वैध आईपी पता प्राप्त होता है और सामान्य रूप से संसाधित किया जाता है:

   

8. नेटवर्क टोपोलॉजी के आधार पर, अनुरोध अंततः पॉड तक पहुंचता है:

   

क्या iptables संतुलन लोड कर सकता है?

नहीं, iptables का उपयोग फ़िल्टरिंग के लिए किया जाता है और संतुलन के लिए डिज़ाइन नहीं किया गया है।

हालाँकि, नियमों का एक सेट लिखना संभव है जो इस तरह काम करता है छद्म-संतुलनकर्ता.

और यह बिल्कुल वही है जो कुबेरनेट्स में लागू किया गया है।

यदि आपके पास तीन पॉड हैं, तो क्यूब-प्रॉक्सी निम्नलिखित नियम लिखेगा:

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

इस प्रणाली के परिणामस्वरूप प्रत्येक पॉड को 33% की संभावना के साथ चुना जाता है।

और इस बात की कोई गारंटी नहीं है कि पॉड 2 के बाद पॉड 1 को चुना जाएगा।

नोट: iptables यादृच्छिक वितरण के साथ एक सांख्यिकीय मॉड्यूल का उपयोग करता है। इस प्रकार, संतुलन एल्गोरिथ्म यादृच्छिक चयन पर आधारित है।

अब जब आप समझ गए हैं कि सेवाएँ कैसे काम करती हैं, तो आइए अधिक दिलचस्प सेवा परिदृश्यों पर नज़र डालें।

कुबेरनेट्स में लंबे समय तक रहने वाले कनेक्शन डिफ़ॉल्ट रूप से स्केल नहीं होते हैं

फ्रंटएंड से बैकएंड तक प्रत्येक HTTP अनुरोध को एक अलग टीसीपी कनेक्शन द्वारा परोसा जाता है, जो खोला और बंद किया जाता है।

यदि फ्रंटएंड बैकएंड को प्रति सेकंड 100 अनुरोध भेजता है, तो 100 अलग-अलग टीसीपी कनेक्शन खोले और बंद किए जाते हैं।

आप एक टीसीपी कनेक्शन खोलकर और बाद के सभी HTTP अनुरोधों के लिए इसका उपयोग करके अनुरोध प्रसंस्करण समय और लोड को कम कर सकते हैं।

HTTP प्रोटोकॉल में HTTP कीप-अलाइव, या कनेक्शन पुन: उपयोग नामक एक सुविधा है। इस मामले में, एक एकल टीसीपी कनेक्शन का उपयोग कई HTTP अनुरोधों और प्रतिक्रियाओं को भेजने और प्राप्त करने के लिए किया जाता है:

यह सुविधा डिफ़ॉल्ट रूप से सक्षम नहीं है: सर्वर और क्लाइंट दोनों को तदनुसार कॉन्फ़िगर किया जाना चाहिए।

अधिकांश प्रोग्रामिंग भाषाओं और परिवेशों के लिए सेटअप स्वयं सरल और सुलभ है।

यहां विभिन्न भाषाओं में उदाहरणों के कुछ लिंक दिए गए हैं:

• Node.js में जीवित रखें
• स्प्रिंग बूट में जीवित रखें
• पायथन में जीवित रखें
• .NET में जीवित रखें

यदि हम कुबेरनेट्स सेवा में कीप-अलाइव का उपयोग करते हैं तो क्या होता है?
आइए मान लें कि फ्रंटएंड और बैकएंड दोनों समर्थन जीवित रहते हैं।

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

सामान्य स्थिति के विपरीत जहां प्रतिक्रिया प्राप्त करने के बाद टीसीपी कनेक्शन बंद हो जाता है, अब इसे आगे के HTTP अनुरोधों के लिए खुला रखा जाता है।

यदि फ्रंटएंड बैकएंड को अधिक अनुरोध भेजता है तो क्या होगा?

इन अनुरोधों को अग्रेषित करने के लिए, एक खुले टीसीपी कनेक्शन का उपयोग किया जाएगा, सभी अनुरोध उसी बैकएंड पर जाएंगे जहां पहला अनुरोध गया था।

क्या iptables को ट्रैफ़िक का पुनर्वितरण नहीं करना चाहिए?

इस मामले में नहीं।

जब एक टीसीपी कनेक्शन बनाया जाता है, तो यह iptables नियमों से गुजरता है, जो एक विशिष्ट बैकएंड का चयन करता है जहां ट्रैफ़िक जाएगा।

चूँकि बाद के सभी अनुरोध पहले से ही खुले टीसीपी कनेक्शन पर हैं, इसलिए iptables नियम अब कॉल नहीं किए जाते हैं।

आइए देखें कि यह कैसा दिखता है.

1. पहला पॉड सेवा को एक अनुरोध भेजता है:

   

2. आप पहले से ही जानते हैं कि आगे क्या होगा. सेवा मौजूद नहीं है, लेकिन iptables नियम हैं जो अनुरोध पर कार्रवाई करेंगे:

   

3. बैकएंड पॉड में से एक को गंतव्य पते के रूप में चुना जाएगा:

   

4. अनुरोध पॉड तक पहुंचता है. इस बिंदु पर, दो पॉड्स के बीच एक सतत टीसीपी कनेक्शन स्थापित किया जाएगा:

   

5. पहले पॉड से कोई भी अगला अनुरोध पहले से स्थापित कनेक्शन के माध्यम से जाएगा:

   

परिणाम तेज़ प्रतिक्रिया समय और उच्च थ्रूपुट है, लेकिन आप बैकएंड को स्केल करने की क्षमता खो देते हैं।

भले ही आपके पास बैकएंड में दो पॉड हों, निरंतर कनेक्शन के साथ, ट्रैफ़िक हमेशा उनमें से एक पर जाएगा।

क्या इसे ठीक किया जा सकता है?

चूँकि कुबेरनेट्स को यह नहीं पता कि लगातार कनेक्शनों को कैसे संतुलित किया जाए, इसलिए यह कार्य आपके ऊपर आता है।

सेवाएँ आईपी पते और पोर्ट का एक संग्रह हैं जिन्हें एंडपॉइंट कहा जाता है।

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

या अधिक आवेदन करें जटिल संतुलन एल्गोरिदम.

क्लाइंट-साइड कोड जो संतुलन के लिए ज़िम्मेदार है, उसे इस तर्क का पालन करना चाहिए:

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

यह इस तरह दिखेगा.

1. सेवा के लिए अनुरोध भेजने वाले पहले पॉड के बजाय, आप क्लाइंट पक्ष पर अनुरोधों को संतुलित कर सकते हैं:

   

2. आपको वह कोड लिखना होगा जो पूछता है कि कौन से पॉड सेवा का हिस्सा हैं:

   

3. एक बार जब आपके पास सूची हो, तो इसे क्लाइंट साइड पर सहेजें और पॉड्स से कनेक्ट करने के लिए इसका उपयोग करें:

   

4. आप लोड संतुलन एल्गोरिदम के लिए ज़िम्मेदार हैं:

   

अब सवाल उठता है: क्या यह समस्या केवल HTTP कीप-अलाइव पर लागू होती है?

क्लाइंट-साइड लोड संतुलन

HTTP एकमात्र प्रोटोकॉल नहीं है जो लगातार टीसीपी कनेक्शन का उपयोग कर सकता है।

यदि आपका एप्लिकेशन डेटाबेस का उपयोग करता है, तो हर बार जब आपको अनुरोध करने या डेटाबेस से दस्तावेज़ पुनर्प्राप्त करने की आवश्यकता होती है तो एक टीसीपी कनेक्शन नहीं खोला जाता है। 

इसके बजाय, डेटाबेस के लिए एक सतत टीसीपी कनेक्शन खोला और उपयोग किया जाता है।

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

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

डेटाबेस से कनेक्ट करने के लिए आप किस लाइब्रेरी का उपयोग करते हैं, इसके आधार पर आपके पास इस समस्या को हल करने के लिए अलग-अलग विकल्प हो सकते हैं।

नीचे 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

ऐसे कई अन्य प्रोटोकॉल हैं जो लगातार टीसीपी कनेक्शन का उपयोग करते हैं:

• वेबसॉकेट और सुरक्षित वेबसॉकेट
• HTTP / 2
• जी.आर.पीसी.
• आरसॉकेट
• एएमक्यूपी

आपको इनमें से अधिकांश प्रोटोकॉल से पहले से ही परिचित होना चाहिए।

लेकिन अगर ये प्रोटोकॉल इतने लोकप्रिय हैं, तो कोई मानकीकृत संतुलन समाधान क्यों नहीं है? क्लाइंट तर्क को बदलने की आवश्यकता क्यों है? क्या कोई देशी कुबेरनेट्स समाधान है?

क्यूब-प्रॉक्सी और आईपीटेबल्स को कुबेरनेट्स पर तैनात करते समय सबसे आम उपयोग के मामलों को कवर करने के लिए डिज़ाइन किया गया है। यह सुविधा के लिए है.

यदि आप एक ऐसी वेब सेवा का उपयोग कर रहे हैं जो REST API को उजागर करती है, तो आप भाग्यशाली हैं - इस मामले में, लगातार टीसीपी कनेक्शन का उपयोग नहीं किया जाता है, आप किसी भी कुबेरनेट्स सेवा का उपयोग कर सकते हैं।

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

हालाँकि, निश्चित रूप से ऐसे विकल्प हैं जो मदद कर सकते हैं।

कुबेरनेट्स में दीर्घकालिक कनेक्शन को संतुलित करना

कुबेरनेट्स में चार प्रकार की सेवाएँ हैं:

1. क्लस्टरआईपी
2. नोडपोर्ट
3. भार संतुलन
4. नेतृत्वहीन

पहली तीन सेवाएँ वर्चुअल आईपी पते पर आधारित होती हैं, जिसका उपयोग क्यूब-प्रॉक्सी द्वारा iptables नियम बनाने के लिए किया जाता है। लेकिन सभी सेवाओं का मूल आधार नेतृत्वहीन सेवा है।

हेडलेस सेवा के साथ कोई आईपी पता जुड़ा नहीं है और केवल आईपी पते और इससे जुड़े पॉड्स (एंडपॉइंट) के पोर्ट की सूची प्राप्त करने के लिए एक तंत्र प्रदान करता है।

सभी सेवाएँ नेतृत्वहीन सेवा पर आधारित हैं।

क्लस्टरआईपी सेवा कुछ अतिरिक्त सुविधाओं के साथ एक हेडलेस सेवा है: 

1. प्रबंधन परत इसे एक आईपी पता निर्दिष्ट करती है।
2. क्यूब-प्रॉक्सी आवश्यक iptables नियम उत्पन्न करता है।

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

लेकिन हम क्लस्टर में तैनात सभी अनुप्रयोगों में समान तर्क कैसे जोड़ सकते हैं?

यदि आपका एप्लिकेशन पहले से ही तैनात है, तो यह कार्य असंभव लग सकता है। हालाँकि, एक वैकल्पिक विकल्प भी है।

सर्विस मेश आपकी मदद करेगा

आपने शायद पहले ही देखा होगा कि क्लाइंट-साइड लोड संतुलन रणनीति काफी मानक है।

जब एप्लिकेशन प्रारंभ होता है, तो यह:

1. सेवा से आईपी पतों की एक सूची प्राप्त होती है।
2. एक कनेक्शन पूल खोलता है और उसका रखरखाव करता है।
3. समय-समय पर एंडपॉइंट्स को जोड़कर या हटाकर पूल को अपडेट किया जाता है।

एक बार जब एप्लिकेशन अनुरोध करना चाहता है, तो यह:

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

ये चरण WebSockets, gRPC और AMQP कनेक्शन दोनों के लिए काम करते हैं।

आप इस तर्क को एक अलग लाइब्रेरी में अलग कर सकते हैं और इसे अपने अनुप्रयोगों में उपयोग कर सकते हैं।

हालाँकि, आप इसके बजाय इस्तियो या लिंकरड जैसे सर्विस मेश का उपयोग कर सकते हैं।

सर्विस मेश आपके एप्लिकेशन को एक प्रक्रिया के साथ संवर्धित करता है:

1. स्वचालित रूप से सेवा आईपी पते की खोज करता है।
2. WebSockets और gRPC जैसे कनेक्शन का परीक्षण करता है।
3. सही प्रोटोकॉल का उपयोग करके अनुरोधों को संतुलित करें।

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

यदि आप संतुलन संबंधी मुद्दों को नज़रअंदाज कर दें तो क्या होगा?

आप लोड संतुलन का उपयोग न करने का विकल्प चुन सकते हैं और फिर भी कोई परिवर्तन नज़र नहीं आएगा। आइए कुछ कार्य परिदृश्यों पर नजर डालें।

यदि आपके पास सर्वर से अधिक क्लाइंट हैं, तो यह इतनी बड़ी समस्या नहीं है।

मान लीजिए कि पांच क्लाइंट हैं जो दो सर्वर से जुड़ते हैं। यदि कोई संतुलन नहीं है, तो भी दोनों सर्वरों का उपयोग किया जाएगा:

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

इससे भी अधिक समस्याग्रस्त स्थिति विपरीत है।

यदि आपके पास कम ग्राहक और अधिक सर्वर हैं, तो आपके संसाधनों का कम उपयोग हो सकता है और एक संभावित बाधा उत्पन्न होगी।

मान लीजिए कि दो क्लाइंट और पांच सर्वर हैं। सर्वोत्तम स्थिति में, पाँच में से दो सर्वरों के लिए दो स्थायी कनेक्शन होंगे।

शेष सर्वर निष्क्रिय रहेंगे:

यदि ये दोनों सर्वर क्लाइंट अनुरोधों को संभाल नहीं सकते हैं, तो क्षैतिज स्केलिंग मदद नहीं करेगी।

निष्कर्ष

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

हालाँकि, एक बार जब आप एप्लिकेशन प्रोटोकॉल के साथ काम करना शुरू कर देते हैं जो लगातार टीसीपी कनेक्शन, जैसे डेटाबेस, जीआरपीसी या वेबसॉकेट का उपयोग करते हैं, तो सेवाएं उपयुक्त नहीं रह जाती हैं। कुबेरनेट्स लगातार टीसीपी कनेक्शन को संतुलित करने के लिए आंतरिक तंत्र प्रदान नहीं करता है।

इसका मतलब है कि आपको क्लाइंट-साइड बैलेंसिंग को ध्यान में रखते हुए एप्लिकेशन लिखना होगा।

अनुवाद टीम द्वारा तैयार किया गया Mail.ru से Kubernetes aaS.

विषय पर और क्या पढ़ना है:

1. कुबेरनेट्स में ऑटोस्केलिंग के तीन स्तर और उनका प्रभावी ढंग से उपयोग कैसे करें. 
2. कार्यान्वयन के लिए एक टेम्पलेट के साथ पायरेसी की भावना में कुबेरनेट्स.
3. डिजिटल परिवर्तन के बारे में हमारा टेलीग्राम चैनल.

स्रोत: www.habr.com