కుబెర్నెట్స్‌లో లోడ్ బ్యాలెన్సింగ్ ఎలా పని చేస్తుందో, దీర్ఘకాలిక కనెక్షన్‌లను స్కేలింగ్ చేసినప్పుడు ఏమి జరుగుతుంది మరియు మీరు HTTP/2, gRPC, RSockets, AMQP లేదా ఇతర దీర్ఘకాల ప్రోటోకాల్‌లను ఉపయోగిస్తే క్లయింట్-సైడ్ బ్యాలెన్సింగ్‌ను ఎందుకు పరిగణించాలో అర్థం చేసుకోవడానికి ఈ కథనం మీకు సహాయం చేస్తుంది. .
కుబెర్నెట్స్‌లో ట్రాఫిక్ ఎలా పునఃపంపిణీ చేయబడుతుందనే దాని గురించి కొంచెం
అప్లికేషన్‌లను అమలు చేయడానికి కుబెర్నెటెస్ రెండు అనుకూలమైన సంగ్రహాలను అందిస్తుంది: సేవలు మరియు విస్తరణలు.
మీ అప్లికేషన్ యొక్క కాపీలు ఏ సమయంలో ఎలా మరియు ఎన్ని అమలులో ఉండాలో విస్తరణలు వివరిస్తాయి. ప్రతి అప్లికేషన్ పాడ్‌గా అమలు చేయబడుతుంది మరియు ఒక IP చిరునామా కేటాయించబడుతుంది.
సేవలు లోడ్ బ్యాలెన్సర్‌తో సమానంగా ఉంటాయి. అవి బహుళ పాడ్‌లలో ట్రాఫిక్‌ను పంపిణీ చేయడానికి రూపొందించబడ్డాయి.
అది ఎలా ఉంటుందో చూద్దాం.
- దిగువ రేఖాచిత్రంలో మీరు ఒకే అప్లికేషన్ మరియు లోడ్ బ్యాలెన్సర్‌కు సంబంధించిన మూడు సందర్భాలను చూడవచ్చు:
- లోడ్ బ్యాలెన్సర్‌ను సర్వీస్ అని పిలుస్తారు మరియు IP చిరునామా కేటాయించబడుతుంది. ఏదైనా ఇన్‌కమింగ్ అభ్యర్థన పాడ్‌లలో ఒకదానికి దారి మళ్లించబడుతుంది:
- విస్తరణ దృశ్యం అప్లికేషన్ యొక్క ఉదాహరణల సంఖ్యను నిర్ణయిస్తుంది. మీరు దాదాపు ఎప్పటికీ దీని కింద నేరుగా విస్తరించాల్సిన అవసరం లేదు:
- ప్రతి పాడ్ దాని స్వంత IP చిరునామాను కేటాయించింది:
సేవలను IP చిరునామాల సమాహారంగా భావించడం ఉపయోగకరంగా ఉంటుంది. మీరు సేవను యాక్సెస్ చేసిన ప్రతిసారి, జాబితా నుండి IP చిరునామాలలో ఒకటి ఎంపిక చేయబడుతుంది మరియు గమ్యం చిరునామాగా ఉపయోగించబడుతుంది.
ఇది ఇలా కనిపిస్తుంది.
- సేవకు కర్ల్ 10.96.45.152 అభ్యర్థన స్వీకరించబడింది:
- సేవ మూడు పాడ్ చిరునామాలలో ఒకదాన్ని గమ్యస్థానంగా ఎంచుకుంటుంది:
- ట్రాఫిక్ నిర్దిష్ట పాడ్‌కు దారి మళ్లించబడింది:
మీ అప్లికేషన్‌లో ఫ్రంటెండ్ మరియు బ్యాకెండ్ ఉంటే, మీరు ప్రతిదానికి ఒక సేవ మరియు విస్తరణ రెండింటినీ కలిగి ఉంటారు.
ఫ్రంటెండ్ బ్యాకెండ్‌కు అభ్యర్థన చేసినప్పుడు, బ్యాకెండ్ ఎన్ని పాడ్‌లను అందిస్తుందో ఖచ్చితంగా తెలుసుకోవాల్సిన అవసరం లేదు: ఒకటి, పది లేదా వంద ఉండవచ్చు.
అలాగే, బ్యాకెండ్‌కు అందిస్తున్న పాడ్‌ల చిరునామాల గురించి ఫ్రంటెండ్‌కు ఏమీ తెలియదు.
ఫ్రంటెండ్ బ్యాకెండ్‌కు అభ్యర్థన చేసినప్పుడు, అది బ్యాకెండ్ సేవ యొక్క IP చిరునామాను ఉపయోగిస్తుంది, అది మారదు.
ఈ విధంగా కనిపిస్తుంది.
- 1 కింద అంతర్గత బ్యాకెండ్ భాగాన్ని అభ్యర్థిస్తుంది. బ్యాకెండ్ కోసం నిర్దిష్టమైనదాన్ని ఎంచుకోవడానికి బదులుగా, ఇది సేవకు అభ్యర్థన చేస్తుంది:
- సేవ బ్యాకెండ్ పాడ్‌లలో ఒకదానిని గమ్యస్థాన చిరునామాగా ఎంచుకుంటుంది:
- సేవ ద్వారా ఎంపిక చేయబడిన పాడ్ 1 నుండి పాడ్ 5కి ట్రాఫిక్ వెళుతుంది:
- 1 ఏళ్లలోపు వారికి సర్వీస్ వెనుక 5 ఏళ్లలోపు వంటి ఎన్ని పాడ్‌లు దాగి ఉన్నాయో ఖచ్చితంగా తెలియదు:
కానీ సేవ ఖచ్చితంగా అభ్యర్థనలను ఎలా పంపిణీ చేస్తుంది? రౌండ్-రాబిన్ బ్యాలెన్సింగ్ ఉపయోగించినట్లు కనిపిస్తోంది? దాన్ని గుర్తించండి.
కుబెర్నెటెస్ సేవల్లో బ్యాలెన్సింగ్
కుబెర్నెట్స్ సేవలు లేవు. IP చిరునామా మరియు పోర్ట్‌ను కేటాయించిన సేవ కోసం ఎటువంటి ప్రక్రియ లేదు.
క్లస్టర్‌లోని ఏదైనా నోడ్‌లోకి లాగిన్ చేసి, netstat -ntlp ఆదేశాన్ని అమలు చేయడం ద్వారా మీరు దీన్ని ధృవీకరించవచ్చు.
మీరు సేవకు కేటాయించిన IP చిరునామాను కూడా కనుగొనలేరు.
సేవ యొక్క IP చిరునామా నియంత్రణ లేయర్‌లో, కంట్రోలర్‌లో ఉంది మరియు డేటాబేస్ - etcdలో రికార్డ్ చేయబడింది. అదే చిరునామా మరొక భాగం ద్వారా ఉపయోగించబడుతుంది - kube-proxy.
Kube-proxy అన్ని సేవల కోసం IP చిరునామాల జాబితాను అందుకుంటుంది మరియు క్లస్టర్‌లోని ప్రతి నోడ్‌లో iptables నియమాల సమితిని రూపొందిస్తుంది.
ఈ నియమాలు ఇలా చెబుతున్నాయి: "మేము సేవ యొక్క IP చిరునామాను చూసినట్లయితే, మేము అభ్యర్థన యొక్క గమ్యస్థాన చిరునామాను సవరించాలి మరియు దానిని పాడ్‌లలో ఒకదానికి పంపాలి."
సేవ IP చిరునామా కేవలం ఎంట్రీ పాయింట్‌గా మాత్రమే ఉపయోగించబడుతుంది మరియు ఆ IP చిరునామా మరియు పోర్ట్‌ని వినే ఏ ప్రక్రియ ద్వారా అందించబడదు.
దీనిని చూద్దాం.
- మూడు నోడ్‌ల క్లస్టర్‌ను పరిగణించండి. ప్రతి నోడ్‌లో పాడ్‌లు ఉంటాయి:
- లేత గోధుమరంగు పెయింట్ చేయబడిన టైడ్ పాడ్‌లు సేవలో భాగం. సేవ ఒక ప్రక్రియగా ఉనికిలో లేనందున, ఇది బూడిద రంగులో చూపబడింది:
- మొదటి పాడ్ సేవను అభ్యర్థిస్తుంది మరియు తప్పనిసరిగా అనుబంధిత పాడ్‌లలో ఒకదానికి వెళ్లాలి:
- కానీ సేవ ఉనికిలో లేదు, ప్రక్రియ ఉనికిలో లేదు. ఇది ఎలా పని చేస్తుంది?
- అభ్యర్థన నోడ్ నుండి నిష్క్రమించే ముందు, ఇది iptables నియమాల ద్వారా వెళుతుంది:
- iptables నియమాలకు సేవ ఉనికిలో లేదని తెలుసు మరియు దాని IP చిరునామాను ఆ సేవతో అనుబంధించబడిన పాడ్‌ల యొక్క IP చిరునామాలలో ఒకదానితో భర్తీ చేస్తుంది:
- అభ్యర్థన గమ్యస్థాన చిరునామాగా చెల్లుబాటు అయ్యే IP చిరునామాను పొందుతుంది మరియు సాధారణంగా ప్రాసెస్ చేయబడుతుంది:
- నెట్‌వర్క్ టోపోలాజీపై ఆధారపడి, అభ్యర్థన చివరికి పాడ్‌కు చేరుకుంటుంది:
iptables బ్యాలెన్స్‌ను లోడ్ చేయగలదా?
లేదు, iptables ఫిల్టరింగ్ కోసం ఉపయోగించబడతాయి మరియు బ్యాలెన్సింగ్ కోసం రూపొందించబడలేదు.
అయితే, పని చేసే నియమాల సమితిని వ్రాయడం సాధ్యమవుతుంది .
మరియు ఇది ఖచ్చితంగా కుబెర్నెట్స్‌లో అమలు చేయబడుతుంది.
మీకు మూడు పాడ్‌లు ఉంటే, kube-proxy కింది నియమాలను వ్రాస్తుంది:
- 33% సంభావ్యతతో మొదటి సబ్‌ని ఎంచుకోండి, లేకుంటే తదుపరి నియమానికి వెళ్లండి.
- 50% సంభావ్యతతో రెండవదాన్ని ఎంచుకోండి, లేకుంటే తదుపరి నియమానికి వెళ్లండి.
- కింద మూడవదాన్ని ఎంచుకోండి.
ఈ సిస్టమ్ ఫలితంగా ప్రతి పాడ్ 33% సంభావ్యతతో ఎంపిక చేయబడుతుంది.
మరియు పాడ్ 2 తర్వాత పాడ్ 1 ఎంపిక చేయబడుతుందనే గ్యారెంటీ లేదు.
వ్యాఖ్య: iptables యాదృచ్ఛిక పంపిణీతో గణాంక మాడ్యూల్‌ను ఉపయోగిస్తుంది. అందువలన, బ్యాలెన్సింగ్ అల్గోరిథం యాదృచ్ఛిక ఎంపికపై ఆధారపడి ఉంటుంది.
సేవలు ఎలా పని చేస్తాయో ఇప్పుడు మీరు అర్థం చేసుకున్నారు, మరిన్ని ఆసక్తికరమైన సేవా దృశ్యాలను చూద్దాం.
కుబెర్నెటెస్‌లో దీర్ఘకాల కనెక్షన్‌లు డిఫాల్ట్‌గా స్కేల్ చేయబడవు
ఫ్రంటెండ్ నుండి బ్యాకెండ్ వరకు ప్రతి HTTP అభ్యర్థన ప్రత్యేక TCP కనెక్షన్ ద్వారా అందించబడుతుంది, ఇది తెరవబడి మూసివేయబడుతుంది.
ఫ్రంటెండ్ బ్యాకెండ్‌కు సెకనుకు 100 అభ్యర్థనలను పంపితే, 100 వేర్వేరు TCP కనెక్షన్‌లు తెరవబడి మూసివేయబడతాయి.
మీరు ఒక TCP కనెక్షన్‌ని తెరిచి, తదుపరి అన్ని HTTP అభ్యర్థనల కోసం ఉపయోగించడం ద్వారా అభ్యర్థన ప్రాసెసింగ్ సమయాన్ని మరియు లోడ్‌ను తగ్గించవచ్చు.
HTTP ప్రోటోకాల్‌లో HTTP కీప్-ఎలైవ్ లేదా కనెక్షన్ రీయూజ్ అనే ఫీచర్ ఉంది. ఈ సందర్భంలో, బహుళ HTTP అభ్యర్థనలు మరియు ప్రతిస్పందనలను పంపడానికి మరియు స్వీకరించడానికి ఒకే TCP కనెక్షన్ ఉపయోగించబడుతుంది:
ఈ ఫీచర్ డిఫాల్ట్‌గా ప్రారంభించబడలేదు: సర్వర్ మరియు క్లయింట్ రెండూ తదనుగుణంగా కాన్ఫిగర్ చేయబడాలి.
సెటప్ చాలా సరళమైనది మరియు చాలా ప్రోగ్రామింగ్ భాషలు మరియు పరిసరాలకు అందుబాటులో ఉంటుంది.
వివిధ భాషలలోని ఉదాహరణలకు ఇక్కడ కొన్ని లింక్‌లు ఉన్నాయి:
మేము Kubernetes సేవలో కీప్-ఎలైవ్ ఉపయోగిస్తే ఏమి జరుగుతుంది?
ఫ్రంటెండ్ మరియు బ్యాకెండ్ రెండూ సజీవంగా ఉంచడానికి మద్దతు ఇస్తాయని అనుకుందాం.
మా దగ్గర ఫ్రంటెండ్ యొక్క ఒక కాపీ మరియు బ్యాకెండ్ యొక్క మూడు కాపీలు ఉన్నాయి. ఫ్రంటెండ్ మొదటి అభ్యర్థనను చేస్తుంది మరియు బ్యాకెండ్‌కు TCP కనెక్షన్‌ను తెరుస్తుంది. అభ్యర్థన సేవకు చేరుకుంటుంది, బ్యాకెండ్ పాడ్‌లలో ఒకటి గమ్యస్థాన చిరునామాగా ఎంపిక చేయబడింది. బ్యాకెండ్ ప్రతిస్పందనను పంపుతుంది మరియు ఫ్రంటెండ్ దానిని అందుకుంటుంది.
ప్రతిస్పందనను స్వీకరించిన తర్వాత TCP కనెక్షన్ మూసివేయబడిన సాధారణ పరిస్థితి వలె కాకుండా, ఇది ఇప్పుడు తదుపరి HTTP అభ్యర్థనల కోసం తెరిచి ఉంచబడుతుంది.
ఫ్రంటెండ్ బ్యాకెండ్‌కి మరిన్ని అభ్యర్థనలను పంపితే ఏమి జరుగుతుంది?
ఈ అభ్యర్థనలను ఫార్వార్డ్ చేయడానికి, ఓపెన్ TCP కనెక్షన్ ఉపయోగించబడుతుంది, అన్ని అభ్యర్థనలు మొదటి అభ్యర్థన వెళ్లిన అదే బ్యాకెండ్‌కు వెళ్తాయి.
iptables ట్రాఫిక్‌ను పునఃపంపిణీ చేయకూడదా?
ఈ సందర్భంలో కాదు.
TCP కనెక్షన్ సృష్టించబడినప్పుడు, అది iptables నియమాల ద్వారా వెళుతుంది, ఇది ట్రాఫిక్ ఎక్కడికి వెళ్లాలనే నిర్దిష్ట బ్యాకెండ్‌ను ఎంచుకుంటుంది.
అన్ని తదుపరి అభ్యర్థనలు ఇప్పటికే తెరిచిన TCP కనెక్షన్‌లో ఉన్నందున, iptables నియమాలు ఇకపై పిలవబడవు.
అది ఎలా ఉంటుందో చూద్దాం.
- మొదటి పాడ్ సేవకు అభ్యర్థనను పంపుతుంది:
- తరువాత ఏమి జరుగుతుందో మీకు ఇప్పటికే తెలుసు. సేవ ఉనికిలో లేదు, కానీ అభ్యర్థనను ప్రాసెస్ చేసే iptables నియమాలు ఉన్నాయి:
- బ్యాకెండ్ పాడ్‌లలో ఒకటి గమ్యస్థాన చిరునామాగా ఎంపిక చేయబడుతుంది:
- అభ్యర్థన పాడ్‌కు చేరుకుంది. ఈ సమయంలో, రెండు పాడ్‌ల మధ్య నిరంతర TCP కనెక్షన్ ఏర్పాటు చేయబడుతుంది:
- మొదటి పాడ్ నుండి ఏదైనా తదుపరి అభ్యర్థన ఇప్పటికే ఏర్పాటు చేసిన కనెక్షన్ ద్వారా వెళుతుంది:
ఫలితంగా వేగవంతమైన ప్రతిస్పందన సమయం మరియు అధిక నిర్గమాంశ, కానీ మీరు బ్యాకెండ్‌ను స్కేల్ చేసే సామర్థ్యాన్ని కోల్పోతారు.
మీరు బ్యాకెండ్‌లో రెండు పాడ్‌లను కలిగి ఉన్నప్పటికీ, స్థిరమైన కనెక్షన్‌తో, ట్రాఫిక్ ఎల్లప్పుడూ వాటిలో ఒకదానికి వెళ్తుంది.
దీనిని పరిష్కరించగలరా?
నిరంతర కనెక్షన్‌లను ఎలా బ్యాలెన్స్ చేయాలో కుబెర్నెటెస్‌కి తెలియదు కాబట్టి, ఈ పని మీపై పడుతుంది.
సేవలు IP చిరునామాలు మరియు ఎండ్ పాయింట్స్ అని పిలువబడే పోర్ట్‌ల సమాహారం.
మీ అప్లికేషన్ సేవ నుండి ముగింపు పాయింట్ల జాబితాను పొందవచ్చు మరియు వాటి మధ్య అభ్యర్థనలను ఎలా పంపిణీ చేయాలో నిర్ణయించుకోవచ్చు. మీరు ప్రతి పాడ్‌కు నిరంతర కనెక్షన్‌ని తెరవవచ్చు మరియు రౌండ్-రాబిన్ ఉపయోగించి ఈ కనెక్షన్‌ల మధ్య అభ్యర్థనలను బ్యాలెన్స్ చేయవచ్చు.
లేదా మరింత దరఖాస్తు చేసుకోండి .
బ్యాలెన్సింగ్‌కు బాధ్యత వహించే క్లయింట్-సైడ్ కోడ్ ఈ లాజిక్‌ను అనుసరించాలి:
- సేవ నుండి ముగింపు పాయింట్ల జాబితాను పొందండి.
- ప్రతి ఎండ్ పాయింట్ కోసం ఒక నిరంతర కనెక్షన్‌ని తెరవండి.
- అభ్యర్థన చేయవలసి వచ్చినప్పుడు, ఓపెన్ కనెక్షన్లలో ఒకదాన్ని ఉపయోగించండి.
- ఎండ్‌పాయింట్‌ల జాబితాను క్రమం తప్పకుండా నవీకరించండి, కొత్త వాటిని సృష్టించండి లేదా జాబితా మారితే పాత నిరంతర కనెక్షన్‌లను మూసివేయండి.
ఇది ఇలా ఉంటుంది.
- సేవకు అభ్యర్థనను పంపే మొదటి పాడ్ బదులుగా, మీరు క్లయింట్ వైపు అభ్యర్థనలను బ్యాలెన్స్ చేయవచ్చు:
- సేవలో ఏ పాడ్‌లు భాగమని అడిగే కోడ్‌ను మీరు వ్రాయాలి:
- మీరు జాబితాను కలిగి ఉన్న తర్వాత, దానిని క్లయింట్ వైపు సేవ్ చేసి, పాడ్‌లకు కనెక్ట్ చేయడానికి దాన్ని ఉపయోగించండి:
- లోడ్ బ్యాలెన్సింగ్ అల్గారిథమ్‌కు మీరు బాధ్యత వహిస్తారు:
ఇప్పుడు ప్రశ్న తలెత్తుతుంది: ఈ సమస్య HTTP కీప్-సజీవంగా మాత్రమే వర్తిస్తుందా?
క్లయింట్ వైపు లోడ్ బ్యాలెన్సింగ్
HTTP అనేది నిరంతర TCP కనెక్షన్‌లను ఉపయోగించగల ఏకైక ప్రోటోకాల్ కాదు.
మీ అప్లికేషన్ డేటాబేస్‌ని ఉపయోగిస్తుంటే, మీరు డేటాబేస్ నుండి అభ్యర్థన చేయడానికి లేదా పత్రాన్ని తిరిగి పొందాల్సిన ప్రతిసారీ TCP కనెక్షన్ తెరవబడదు.
బదులుగా, డేటాబేస్కు నిరంతర TCP కనెక్షన్ తెరవబడుతుంది మరియు ఉపయోగించబడుతుంది.
మీ డేటాబేస్ కుబెర్నెట్స్‌లో అమలు చేయబడి, యాక్సెస్ సేవగా అందించబడితే, మీరు మునుపటి విభాగంలో వివరించిన అదే సమస్యలను ఎదుర్కొంటారు.
ఒక డేటాబేస్ ప్రతిరూపం ఇతర వాటి కంటే ఎక్కువగా లోడ్ అవుతుంది. 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 కుబెర్నెటెస్‌కు అమలు చేస్తున్నప్పుడు అత్యంత సాధారణ వినియోగ సందర్భాలను కవర్ చేయడానికి రూపొందించబడ్డాయి. ఇది సౌలభ్యం కోసం.
మీరు REST APIని బహిర్గతం చేసే వెబ్ సేవను ఉపయోగిస్తుంటే, మీరు అదృష్టవంతులు - ఈ సందర్భంలో, నిరంతర TCP కనెక్షన్‌లు ఉపయోగించబడవు, మీరు ఏదైనా Kubernetes సేవను ఉపయోగించవచ్చు.
కానీ మీరు నిరంతర TCP కనెక్షన్‌లను ఉపయోగించడం ప్రారంభించిన తర్వాత, బ్యాకెండ్‌లలో లోడ్‌ను సమానంగా ఎలా పంపిణీ చేయాలో మీరు గుర్తించాలి. Kubernetes ఈ కేసు కోసం రెడీమేడ్ పరిష్కారాలను కలిగి లేదు.
అయితే, ఖచ్చితంగా సహాయపడే ఎంపికలు ఉన్నాయి.
కుబెర్నెటెస్‌లో దీర్ఘకాల కనెక్షన్‌లను బ్యాలెన్స్ చేయడం
కుబెర్నెట్స్‌లో నాలుగు రకాల సేవలు ఉన్నాయి:
- ClusterIP
- నోడ్పోర్ట్
- లోడ్ బ్యాలన్సర్
- హెడ్లెస్
మొదటి మూడు సేవలు వర్చువల్ IP చిరునామాపై ఆధారపడి పనిచేస్తాయి, ఇది iptables నియమాలను రూపొందించడానికి kube-proxy ద్వారా ఉపయోగించబడుతుంది. కానీ అన్ని సేవలకు ప్రాథమిక ఆధారం తల లేని సేవ.
హెడ్లెస్ సర్వీస్ దానితో అనుబంధించబడిన ఏ IP చిరునామాను కలిగి ఉండదు మరియు దానితో అనుబంధించబడిన పాడ్‌ల (ఎండ్‌పాయింట్‌లు) యొక్క IP చిరునామాలు మరియు పోర్ట్‌ల జాబితాను తిరిగి పొందడం కోసం మాత్రమే మెకానిజమ్‌ను అందిస్తుంది.
అన్ని సేవలు తల లేని సేవపై ఆధారపడి ఉంటాయి.
ClusterIP సేవ కొన్ని చేర్పులతో కూడిన హెడ్లెస్ సేవ:
- నిర్వహణ లేయర్ దీనికి IP చిరునామాను కేటాయిస్తుంది.
- Kube-proxy అవసరమైన iptables నియమాలను రూపొందిస్తుంది.
ఈ విధంగా మీరు kube-proxyని విస్మరించవచ్చు మరియు మీ అప్లికేషన్‌ను బ్యాలెన్స్ చేయడానికి హెడ్లెస్ సర్వీస్ నుండి పొందిన ఎండ్ పాయింట్ల జాబితాను నేరుగా ఉపయోగించవచ్చు.
అయితే క్లస్టర్‌లో అమలు చేయబడిన అన్ని అప్లికేషన్‌లకు ఒకే విధమైన లాజిక్‌ను ఎలా జోడించవచ్చు?
మీ అప్లికేషన్ ఇప్పటికే అమలు చేయబడి ఉంటే, ఈ పని అసాధ్యం అనిపించవచ్చు. అయితే, ప్రత్యామ్నాయ ఎంపిక ఉంది.
సర్వీస్ మెష్ మీకు సహాయం చేస్తుంది
క్లయింట్-సైడ్ లోడ్ బ్యాలెన్సింగ్ వ్యూహం చాలా ప్రామాణికమైనదని మీరు ఇప్పటికే గమనించి ఉండవచ్చు.
అప్లికేషన్ ప్రారంభించినప్పుడు, ఇది:
- సేవ నుండి IP చిరునామాల జాబితాను పొందుతుంది.
- కనెక్షన్ పూల్‌ను తెరుస్తుంది మరియు నిర్వహిస్తుంది.
- ఎండ్‌పాయింట్‌లను జోడించడం లేదా తీసివేయడం ద్వారా పూల్‌ను కాలానుగుణంగా అప్‌డేట్ చేస్తుంది.
అప్లికేషన్ అభ్యర్థన చేయాలనుకుంటే, అది:
- కొంత లాజిక్‌ని ఉపయోగించి అందుబాటులో ఉన్న కనెక్షన్‌ని ఎంచుకుంటుంది (ఉదా. రౌండ్-రాబిన్).
- అభ్యర్థనను అమలు చేస్తుంది.
ఈ దశలు WebSockets, gRPC మరియు AMQP కనెక్షన్‌లు రెండింటికీ పని చేస్తాయి.
మీరు ఈ లాజిక్‌ను ప్రత్యేక లైబ్రరీగా విభజించి, మీ అప్లికేషన్‌లలో ఉపయోగించవచ్చు.
అయితే, మీరు బదులుగా Istio లేదా Linkerd వంటి సర్వీస్ మెష్‌లను ఉపయోగించవచ్చు.
సర్వీస్ మెష్ మీ అప్లికేషన్‌ను ఈ ప్రక్రియతో పెంచుతుంది:
- సేవా IP చిరునామాల కోసం స్వయంచాలకంగా శోధిస్తుంది.
- WebSockets మరియు gRPC వంటి కనెక్షన్‌లను పరీక్షిస్తుంది.
- సరైన ప్రోటోకాల్ ఉపయోగించి అభ్యర్థనలను బ్యాలెన్స్ చేస్తుంది.
సర్వీస్ మెష్ క్లస్టర్‌లో ట్రాఫిక్‌ని నిర్వహించడంలో సహాయపడుతుంది, అయితే ఇది చాలా వనరులతో కూడుకున్నది. ఇతర ఎంపికలు నెట్‌ఫ్లిక్స్ రిబ్బన్ వంటి థర్డ్-పార్టీ లైబ్రరీలను లేదా ఎన్వోయ్ వంటి ప్రోగ్రామబుల్ ప్రాక్సీలను ఉపయోగిస్తున్నాయి.
మీరు బ్యాలెన్సింగ్ సమస్యలను విస్మరిస్తే ఏమి జరుగుతుంది?
మీరు లోడ్ బ్యాలెన్సింగ్‌ని ఉపయోగించకూడదని ఎంచుకోవచ్చు మరియు ఇప్పటికీ ఎటువంటి మార్పులను గమనించలేరు. కొన్ని పని దృశ్యాలను చూద్దాం.
మీకు సర్వర్‌ల కంటే ఎక్కువ క్లయింట్లు ఉంటే, ఇది అంత పెద్ద సమస్య కాదు.
రెండు సర్వర్‌లకు కనెక్ట్ అయ్యే ఐదు క్లయింట్లు ఉన్నాయని అనుకుందాం. బ్యాలెన్సింగ్ లేనప్పటికీ, రెండు సర్వర్లు ఉపయోగించబడతాయి:
కనెక్షన్‌లు సమానంగా పంపిణీ చేయబడకపోవచ్చు: బహుశా నలుగురు క్లయింట్లు ఒకే సర్వర్‌కు కనెక్ట్ చేయబడి ఉండవచ్చు, కానీ రెండు సర్వర్లు ఉపయోగించబడే మంచి అవకాశం ఉంది.
వ్యతిరేక దృశ్యం మరింత సమస్యాత్మకమైనది.
మీకు తక్కువ క్లయింట్లు మరియు ఎక్కువ సర్వర్లు ఉంటే, మీ వనరులు తక్కువగా ఉపయోగించబడవచ్చు మరియు సంభావ్య అడ్డంకి కనిపిస్తుంది.
ఇద్దరు క్లయింట్లు మరియు ఐదు సర్వర్లు ఉన్నాయని అనుకుందాం. ఉత్తమ సందర్భంలో, ఐదు సర్వర్‌లలో రెండు సర్వర్‌లకు రెండు శాశ్వత కనెక్షన్‌లు ఉంటాయి.
మిగిలిన సర్వర్లు నిష్క్రియంగా ఉంటాయి:
ఈ రెండు సర్వర్లు క్లయింట్ అభ్యర్థనలను నిర్వహించలేకపోతే, క్షితిజ సమాంతర స్కేలింగ్ సహాయం చేయదు.
తీర్మానం
Kubernetes సేవలు చాలా ప్రామాణిక వెబ్ అప్లికేషన్ దృశ్యాలలో పని చేయడానికి రూపొందించబడ్డాయి.
అయితే, మీరు డేటాబేస్‌లు, gRPC లేదా WebSockets వంటి నిరంతర TCP కనెక్షన్‌లను ఉపయోగించే అప్లికేషన్ ప్రోటోకాల్‌లతో పని చేయడం ప్రారంభించిన తర్వాత, సేవలు ఇకపై తగినవి కావు. కుబెర్నెటెస్ నిరంతర TCP కనెక్షన్‌లను బ్యాలెన్స్ చేయడానికి అంతర్గత మెకానిజమ్‌లను అందించదు.
అంటే మీరు తప్పనిసరిగా క్లయింట్-సైడ్ బ్యాలెన్సింగ్‌ను దృష్టిలో ఉంచుకుని అప్లికేషన్‌లను వ్రాయాలి.
బృందం తయారు చేసిన అనువాదం .
అంశంపై ఇంకా ఏమి చదవాలి:
- .
- .
- .
మూలం: www.habr.com