Kubernetes मध्ये लोड बॅलन्सिंग आणि दीर्घकालीन कनेक्शन स्केलिंग

हा लेख तुम्हाला Kubernetes मध्ये लोड बॅलन्सिंग कसे कार्य करते, दीर्घकालीन कनेक्शन स्केलिंग करताना काय होते आणि तुम्ही HTTP/2, gRPC, RSockets, AMQP किंवा इतर दीर्घकालीन प्रोटोकॉल वापरल्यास क्लायंट-साइड बॅलन्सिंगचा विचार का करावा हे समजून घेण्यात मदत करेल. . 

कुबर्नेट्समध्ये रहदारीचे पुनर्वितरण कसे केले जाते याबद्दल थोडेसे 

Kubernetes अनुप्रयोग उपयोजित करण्यासाठी दोन सोयीस्कर ऍब्स्ट्रॅक्शन प्रदान करते: सेवा आणि उपयोजन.

उपयोजन हे वर्णन करतात की कोणत्याही वेळी तुमच्या अर्जाच्या किती आणि किती प्रती चालू असाव्यात. प्रत्येक अनुप्रयोग पॉड म्हणून तैनात केला जातो आणि त्याला एक IP पत्ता नियुक्त केला जातो.

सेवा लोड बॅलन्सरच्या कार्यामध्ये समान असतात. ते एकाधिक पॉडवर रहदारी वितरीत करण्यासाठी डिझाइन केलेले आहेत.

ते कसे दिसते ते पाहूया.

1. खालील आकृतीमध्ये तुम्ही एकाच ऍप्लिकेशनची तीन उदाहरणे आणि लोड बॅलन्सर पाहू शकता:

   

2. लोड बॅलन्सरला सेवा म्हणतात आणि त्याला IP पत्ता नियुक्त केला जातो. कोणतीही येणारी विनंती पॉडपैकी एकाकडे पुनर्निर्देशित केली जाते:

   

3. उपयोजन परिस्थिती अनुप्रयोगाच्या उदाहरणांची संख्या निर्धारित करते. तुम्हाला जवळजवळ कधीच थेट खाली विस्तारावे लागणार नाही:

   

4. प्रत्येक पॉडला त्याचा स्वतःचा IP पत्ता नियुक्त केला जातो:

   

आयपी पत्त्यांचा संग्रह म्हणून सेवांचा विचार करणे उपयुक्त आहे. प्रत्येक वेळी तुम्ही सेवेमध्ये प्रवेश करता तेव्हा, सूचीमधून एक IP पत्ता निवडला जातो आणि गंतव्य पत्ता म्हणून वापरला जातो.

असे दिसते.

1. सेवेला कर्ल 10.96.45.152 विनंती प्राप्त झाली आहे:

   

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

   

3. रहदारी एका विशिष्ट पॉडवर पुनर्निर्देशित केली जाते:

   

तुमच्या अर्जामध्ये फ्रंटएंड आणि बॅकएंडचा समावेश असल्यास, तुमच्याकडे प्रत्येकासाठी सेवा आणि उपयोजन दोन्ही असेल.

जेव्हा फ्रंटएंड बॅकएंडला विनंती करतो, तेव्हा बॅकएंड किती पॉड्स देतो हे माहित असणे आवश्यक नसते: एक, दहा किंवा शंभर असू शकतात.

तसेच, बॅकएंडला सेवा देणाऱ्या शेंगांच्या पत्त्यांबद्दल फ्रंटएंडला काहीही माहिती नसते.

जेव्हा फ्रंटएंड बॅकएंडला विनंती करतो, तेव्हा तो बॅकएंड सेवेचा IP पत्ता वापरतो, जो बदलत नाही.

हे असे दिसते.

1. अंतर्गत 1 अंतर्गत बॅकएंड घटक विनंती. बॅकएंडसाठी विशिष्ट निवडण्याऐवजी, ते सेवेला विनंती करते:

   

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

   

3. वाहतूक पॉड 1 ते पॉड 5 पर्यंत जाते, सेवेद्वारे निवडलेली:

   

4. सेवेच्या मागे 1 वर्षाखालील सारख्या किती शेंगा लपलेल्या आहेत हे 5 अंतर्गत माहित नाही:

   

पण सेवा विनंत्यांचे वितरण नेमके कसे करते? असे दिसते की राउंड-रॉबिन बॅलन्सिंग वापरले जाते? चला ते बाहेर काढूया. 

Kubernetes सेवांमध्ये संतुलन

Kubernetes सेवा अस्तित्वात नाही. IP पत्ता आणि पोर्ट नियुक्त केलेल्या सेवेसाठी कोणतीही प्रक्रिया नाही.

तुम्ही क्लस्टरमधील कोणत्याही नोडमध्ये लॉग इन करून आणि netstat -ntlp कमांड चालवून याची पडताळणी करू शकता.

तुम्ही सेवेला वाटप केलेला IP पत्ता देखील शोधू शकणार नाही.

सेवेचा IP पत्ता कंट्रोलरमध्ये, कंट्रोलरमध्ये स्थित आहे आणि डेटाबेसमध्ये रेकॉर्ड केला आहे - इ.डी. समान पत्ता दुसर्या घटकाद्वारे वापरला जातो - kube-proxy.
कुबे-प्रॉक्सी सर्व सेवांसाठी IP पत्त्यांची सूची प्राप्त करते आणि क्लस्टरमधील प्रत्येक नोडवर iptables नियमांचा संच तयार करते.

हे नियम म्हणतात: "आम्हाला सेवेचा IP पत्ता दिसल्यास, आम्हाला विनंतीचा गंतव्य पत्ता सुधारित करावा लागेल आणि तो एका पॉडवर पाठवावा लागेल."

सेवा IP पत्ता फक्त एंट्री पॉइंट म्हणून वापरला जातो आणि तो IP पत्ता आणि पोर्ट ऐकण्याच्या कोणत्याही प्रक्रियेद्वारे दिला जात नाही.

हे बघूया. 

1. तीन नोड्सच्या क्लस्टरचा विचार करा. प्रत्येक नोडमध्ये शेंगा असतात:

   

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

   

3. प्रथम पॉड सेवेची विनंती करतो आणि संबंधित पॉडपैकी एकावर जाणे आवश्यक आहे:

   

4. पण सेवा अस्तित्वात नाही, प्रक्रिया अस्तित्वात नाही. हे कस काम करत?

   

5. विनंती नोड सोडण्यापूर्वी, ते iptables नियमांद्वारे जाते:

   

6. iptables नियमांना माहित आहे की सेवा अस्तित्वात नाही आणि त्याचा IP पत्ता त्या सेवेशी संबंधित पॉड्सच्या IP पत्त्यांपैकी एकाने बदलतो:

   

7. विनंतीला गंतव्य पत्ता म्हणून वैध IP पत्ता प्राप्त होतो आणि सामान्यपणे प्रक्रिया केली जाते:

   

8. नेटवर्क टोपोलॉजीवर अवलंबून, विनंती शेवटी पॉडपर्यंत पोहोचते:

   

iptables शिल्लक लोड करू शकतात?

नाही, iptables चा वापर फिल्टरिंगसाठी केला जातो आणि समतोल साधण्यासाठी डिझाइन केलेले नव्हते.

तथापि, जसे कार्य करतात अशा नियमांचा संच लिहिणे शक्य आहे स्यूडो-बॅलन्सर.

आणि कुबर्नेट्समध्ये नेमके हेच लागू केले आहे.

तुमच्याकडे तीन शेंगा असल्यास, kube-proxy खालील नियम लिहील:

1. 33% च्या संभाव्यतेसह पहिला उप निवडा, अन्यथा पुढील नियमावर जा.
2. 50% च्या संभाव्यतेसह दुसरा निवडा, अन्यथा पुढील नियमावर जा.
3. त्याखालील तिसरा निवडा.

या प्रणालीचा परिणाम 33% संभाव्यतेसह प्रत्येक पॉड निवडला जातो.

आणि Pod 2 नंतर Pod 1 निवडला जाईल याची शाश्वती नाही.

शेरा: iptables यादृच्छिक वितरणासह सांख्यिकीय मॉड्यूल वापरते. अशा प्रकारे, संतुलित अल्गोरिदम यादृच्छिक निवडीवर आधारित आहे.

आता सेवा कशी कार्य करते हे तुम्हाला समजले आहे, चला अधिक मनोरंजक सेवा परिस्थिती पाहू.

Kubernetes मधील दीर्घकालीन कनेक्शन डीफॉल्टनुसार मोजले जात नाहीत

फ्रंटएंडपासून बॅकएंडपर्यंत प्रत्येक HTTP विनंती स्वतंत्र TCP कनेक्शनद्वारे दिली जाते, जी उघडली आणि बंद केली जाते.

जर फ्रंटएंड बॅकएंडला प्रति सेकंद 100 विनंत्या पाठवत असेल, तर 100 भिन्न TCP कनेक्शन उघडले आणि बंद केले जातात.

तुम्ही एक TCP कनेक्शन उघडून आणि त्यानंतरच्या सर्व HTTP विनंत्यांसाठी वापरून विनंती प्रक्रिया वेळ आणि लोड कमी करू शकता.

HTTP प्रोटोकॉलमध्ये HTTP कीप-लाइव्ह किंवा कनेक्शन पुनर्वापर नावाचे वैशिष्ट्य आहे. या प्रकरणात, एकाधिक HTTP विनंत्या आणि प्रतिसाद पाठविण्यासाठी आणि प्राप्त करण्यासाठी एकल TCP कनेक्शन वापरले जाते:

हे वैशिष्ट्य डीफॉल्टनुसार सक्षम केलेले नाही: सर्व्हर आणि क्लायंट दोन्ही त्यानुसार कॉन्फिगर केले जाणे आवश्यक आहे.

बहुतेक प्रोग्रामिंग भाषा आणि वातावरणांसाठी सेटअप स्वतःच सोपे आणि प्रवेशयोग्य आहे.

वेगवेगळ्या भाषांमधील उदाहरणांचे काही दुवे येथे आहेत:

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

कुबर्नेट्स सेवेमध्ये कीप-अलाइव्ह वापरल्यास काय होईल?
असे गृहीत धरू की फ्रंटएंड आणि बॅकएंड दोन्ही सपोर्ट जिवंत राहतात.

आमच्याकडे फ्रंटएंडची एक प्रत आणि बॅकएंडच्या तीन प्रती आहेत. फ्रंटएंड प्रथम विनंती करतो आणि बॅकएंडला TCP कनेक्शन उघडतो. विनंती सेवेपर्यंत पोहोचते, बॅकएंड पॉडपैकी एक गंतव्य पत्ता म्हणून निवडला जातो. बॅकएंड प्रतिसाद पाठवतो आणि फ्रंटएंडला तो मिळतो.

नेहमीच्या परिस्थितीच्या विपरीत जेथे प्रतिसाद मिळाल्यानंतर TCP कनेक्शन बंद केले जाते, ते आता पुढील HTTP विनंत्यांसाठी खुले ठेवले आहे.

फ्रंटएंडने बॅकएंडला अधिक विनंत्या पाठविल्यास काय होईल?

या विनंत्या फॉरवर्ड करण्यासाठी, ओपन टीसीपी कनेक्शन वापरले जाईल, सर्व विनंत्या त्याच बॅकएंडवर जातील जिथे पहिली विनंती गेली होती.

iptables ने रहदारीचे पुनर्वितरण करू नये?

या प्रकरणात नाही.

जेव्हा TCP कनेक्शन तयार केले जाते, तेव्हा ते iptables नियमांद्वारे जाते, जे विशिष्ट बॅकएंड निवडतात जेथे रहदारी जाईल.

त्यानंतरच्या सर्व विनंत्या आधीच उघडलेल्या TCP कनेक्शनवर असल्याने, iptables नियम यापुढे कॉल केले जाणार नाहीत.

ते कसे दिसते ते पाहूया.

1. पहिला पॉड सेवेला विनंती पाठवतो:

   

2. पुढे काय होणार हे तुम्हाला आधीच माहीत आहे. सेवा अस्तित्वात नाही, परंतु iptables नियम आहेत जे विनंतीवर प्रक्रिया करतील:

   

3. बॅकएंड पॉड्सपैकी एक गंतव्य पत्ता म्हणून निवडला जाईल:

   

4. विनंती पॉडपर्यंत पोहोचते. या टप्प्यावर, दोन शेंगा दरम्यान एक सतत TCP कनेक्शन स्थापित केले जाईल:

   

5. पहिल्या पॉडकडून कोणतीही त्यानंतरची विनंती आधीच स्थापित कनेक्शनद्वारे जाईल:

   

परिणाम जलद प्रतिसाद वेळ आणि उच्च थ्रूपुट आहे, परंतु तुम्ही बॅकएंड स्केल करण्याची क्षमता गमावता.

जरी तुमच्याकडे बॅकएंडमध्ये दोन पॉड असतील, सतत कनेक्शनसह, रहदारी नेहमीच त्यापैकी एकाकडे जाईल.

हे निश्चित करता येईल का?

कुबर्नेट्सला सतत कनेक्शन कसे संतुलित करावे हे माहित नसल्यामुळे, हे कार्य तुमच्यावर येते.

सेवा म्हणजे IP पत्ते आणि पोर्ट यांचा संग्रह आहे ज्यांना एंडपॉइंट म्हणतात.

तुमचा अर्ज सेवेकडून एंडपॉइंट्सची सूची मिळवू शकतो आणि त्यांच्यामध्ये विनंत्या कशा वितरित करायच्या हे ठरवू शकतो. राऊंड-रॉबिन वापरून तुम्ही प्रत्येक पॉडशी एक पर्सिस्टंट कनेक्शन उघडू शकता आणि या कनेक्शनमधील विनंत्या शिल्लक ठेवू शकता.

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

समतोल साधण्यासाठी जबाबदार असलेल्या क्लायंट-साइड कोडने या तर्काचे पालन केले पाहिजे:

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
• एमक्यूपी

तुम्हाला यापैकी बहुतेक प्रोटोकॉल आधीपासूनच परिचित असले पाहिजेत.

परंतु जर हे प्रोटोकॉल इतके लोकप्रिय आहेत, तर तेथे प्रमाणित समतोल उपाय का नाही? क्लायंट लॉजिक बदलण्याची गरज का आहे? कुबर्नेट्सचे मूळ उपाय आहे का?

Kube-proxy आणि iptables हे Kubernetes वर तैनात करताना सर्वात सामान्य वापर प्रकरणे कव्हर करण्यासाठी डिझाइन केलेले आहेत. हे सोयीसाठी आहे.

जर तुम्ही REST API उघड करणारी वेब सेवा वापरत असाल, तर तुम्ही नशीबवान आहात - या प्रकरणात, सतत TCP कनेक्शन वापरले जात नाहीत, तुम्ही कोणतीही Kubernetes सेवा वापरू शकता.

परंतु एकदा तुम्ही सक्तीचे TCP कनेक्शन वापरणे सुरू केले की, तुम्हाला बॅकएंड्सवर लोडचे समान वितरण कसे करावे हे शोधून काढावे लागेल. कुबर्नेट्समध्ये या केससाठी तयार-तयार उपाय नाहीत.

तथापि, असे पर्याय नक्कीच आहेत जे मदत करू शकतात.

Kubernetes मध्ये दीर्घकालीन कनेक्शन संतुलित करणे

कुबर्नेट्समध्ये चार प्रकारच्या सेवा आहेत:

1. क्लस्टरआयपी
2. नोडपोर्ट
3. लोड बॅलन्सर
4. मस्तक नसलेला

पहिल्या तीन सेवा वर्च्युअल IP पत्त्यावर आधारित आहेत, ज्याचा उपयोग iptables नियम तयार करण्यासाठी kube-proxy द्वारे केला जातो. परंतु सर्व सेवांचा मुलभूत आधार हा प्रमुख नसलेली सेवा आहे.

हेडलेस सेवेला त्याच्याशी संबंधित कोणताही IP पत्ता नसतो आणि केवळ IP पत्त्यांची सूची आणि त्याच्याशी संबंधित पॉड्स (एंडपॉइंट्स) च्या पोर्टची पुनर्प्राप्त करण्यासाठी एक यंत्रणा प्रदान करते.

सर्व सेवा हेडलेस सेवेवर आधारित आहेत.

क्लस्टरआयपी सेवा ही काही जोडण्यांसह हेडलेस सेवा आहे: 

1. व्यवस्थापन स्तर त्याला IP पत्ता नियुक्त करते.
2. कुबे-प्रॉक्सी आवश्यक iptables नियम व्युत्पन्न करते.

अशा प्रकारे तुम्ही kube-proxy कडे दुर्लक्ष करू शकता आणि तुमचा अॅप्लिकेशन शिल्लक लोड करण्यासाठी हेडलेस सेवेतून मिळवलेल्या एंडपॉइंट्सची सूची थेट वापरू शकता.

परंतु क्लस्टरमध्ये तैनात केलेल्या सर्व ऍप्लिकेशन्समध्ये आम्ही समान तर्क कसे जोडू शकतो?

तुमचा अर्ज आधीच उपयोजित असल्यास, हे कार्य अशक्य वाटू शकते. तथापि, एक पर्यायी पर्याय आहे.

सेवा जाळी तुम्हाला मदत करेल

तुम्ही कदाचित आधीच लक्षात घेतले असेल की क्लायंट-साइड लोड बॅलेंसिंग धोरण अगदी मानक आहे.

अनुप्रयोग सुरू झाल्यावर, ते:

1. सेवेकडून आयपी पत्त्यांची यादी मिळते.
2. कनेक्शन पूल उघडतो आणि देखरेख करतो.
3. एंडपॉइंट जोडून किंवा काढून टाकून वेळोवेळी पूल अपडेट करते.

एकदा अर्जाला विनंती करायची असल्यास, ते:

1. काही तर्क वापरून उपलब्ध कनेक्शन निवडते (उदा. राउंड-रॉबिन).
2. विनंती अंमलात आणते.

या पायऱ्या WebSockets, gRPC आणि AMQP कनेक्शनसाठी काम करतात.

तुम्ही हे लॉजिक वेगळ्या लायब्ररीमध्ये वेगळे करू शकता आणि ते तुमच्या ऍप्लिकेशन्समध्ये वापरू शकता.

तथापि, तुम्ही त्याऐवजी Istio किंवा Linkerd सारख्या सेवा जाळ्या वापरू शकता.

सेवा जाळी एका प्रक्रियेसह तुमचा अर्ज वाढवते:

1. सेवा IP पत्ते स्वयंचलितपणे शोधते.
2. WebSockets आणि gRPC सारख्या कनेक्शनची चाचणी करते.
3. योग्य प्रोटोकॉल वापरून विनंती संतुलित करते.

सर्व्हिस मेश क्लस्टरमधील रहदारी व्यवस्थापित करण्यात मदत करते, परंतु ते खूप संसाधन-केंद्रित आहे. इतर पर्याय नेटफ्लिक्स रिबन सारख्या तृतीय-पक्ष लायब्ररी किंवा एन्वॉय सारख्या प्रोग्राम करण्यायोग्य प्रॉक्सी वापरत आहेत.

तुम्ही समतोल राखण्याच्या समस्यांकडे दुर्लक्ष केल्यास काय होईल?

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

तुमच्याकडे सर्व्हरपेक्षा जास्त क्लायंट असल्यास, ही इतकी मोठी समस्या नाही.

समजा असे पाच क्लायंट आहेत जे दोन सर्व्हरला जोडतात. समतोल नसला तरीही, दोन्ही सर्व्हर वापरले जातील:

कनेक्शन समान रीतीने वितरीत केले जाऊ शकत नाहीत: कदाचित चार क्लायंट एकाच सर्व्हरशी कनेक्ट केलेले आहेत, परंतु दोन्ही सर्व्हर वापरण्याची चांगली संधी आहे.

काय अधिक समस्याप्रधान आहे उलट परिस्थिती.

तुमच्याकडे कमी क्लायंट आणि जास्त सर्व्हर असल्यास, तुमची संसाधने कमी वापरली जाऊ शकतात आणि संभाव्य अडथळे दिसून येतील.

समजा दोन क्लायंट आणि पाच सर्व्हर आहेत. सर्वोत्तम बाबतीत, पाच पैकी दोन सर्व्हरवर दोन कायमस्वरूपी कनेक्शन असतील.

उर्वरित सर्व्हर निष्क्रिय असतील:

हे दोन सर्व्हर क्लायंटच्या विनंत्या हाताळू शकत नसल्यास, क्षैतिज स्केलिंग मदत करणार नाही.

निष्कर्ष

Kubernetes सेवा बहुतेक मानक वेब अनुप्रयोग परिस्थितींमध्ये कार्य करण्यासाठी डिझाइन केल्या आहेत.

तथापि, एकदा तुम्ही डेटाबेस, gRPC किंवा WebSockets सारख्या सतत TCP कनेक्शन वापरणार्‍या ऍप्लिकेशन प्रोटोकॉलसह कार्य करण्यास सुरुवात केल्यानंतर, सेवा यापुढे योग्य राहणार नाहीत. Kubernetes सतत TCP कनेक्शन संतुलित करण्यासाठी अंतर्गत यंत्रणा प्रदान करत नाही.

याचा अर्थ तुम्ही क्लायंट-साइड समतोल लक्षात घेऊन अनुप्रयोग लिहावेत.

संघाने तयार केलेला अनुवाद Mail.ru वरून Kubernetes aaS.

विषयावर अजून काय वाचायचे:

1. कुबर्नेट्समधील ऑटोस्केलिंगचे तीन स्तर आणि ते प्रभावीपणे कसे वापरायचे. 
2. अंमलबजावणीसाठी टेम्पलेटसह चाचेगिरीच्या भावनेत कुबर्नेट्स.
3. डिजिटल परिवर्तनाबद्दल आमचे टेलिग्राम चॅनेल.

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