குபெர்னெட்டஸில் நீண்ட கால இணைப்புகளை ஏற்றி சமநிலைப்படுத்துதல் மற்றும் அளவிடுதல்

குபெர்னெட்ஸில் சுமை சமநிலை எவ்வாறு செயல்படுகிறது, நீண்ட கால இணைப்புகளை அளவிடும்போது என்ன நடக்கும், மற்றும் நீங்கள் HTTP/2, gRPC, RSockets, AMQP அல்லது பிற நீண்ட கால நெறிமுறைகளைப் பயன்படுத்தினால், கிளையன்ட் பக்க சமநிலையை ஏன் கருத்தில் கொள்ள வேண்டும் என்பதைப் புரிந்துகொள்ள இந்தக் கட்டுரை உதவும். . 

குபெர்னெட்ஸில் போக்குவரத்து எவ்வாறு மறுபகிர்வு செய்யப்படுகிறது என்பதைப் பற்றி கொஞ்சம் 

பயன்பாடுகளைப் பயன்படுத்துவதற்கு குபெர்னெட்டஸ் இரண்டு வசதியான சுருக்கங்களை வழங்குகிறது: சேவைகள் மற்றும் வரிசைப்படுத்தல்கள்.

எந்த நேரத்திலும் உங்கள் விண்ணப்பத்தின் எத்தனை பிரதிகள் எவ்வாறு இயங்க வேண்டும் என்பதை வரிசைப்படுத்துதல் விவரிக்கிறது. ஒவ்வொரு பயன்பாடும் ஒரு Pod ஆக வரிசைப்படுத்தப்பட்டு ஒரு IP முகவரி ஒதுக்கப்படும்.

சேவைகள் சுமை பேலன்சரைப் போலவே செயல்படுகின்றன. அவை பல காய்களில் போக்குவரத்தை விநியோகிக்க வடிவமைக்கப்பட்டுள்ளன.

அது எப்படி இருக்கும் என்று பார்ப்போம்.

1. கீழேயுள்ள வரைபடத்தில் ஒரே பயன்பாட்டின் மூன்று நிகழ்வுகளையும் ஒரு சுமை சமநிலையையும் காணலாம்:

   

2. சுமை சமநிலை ஒரு சேவை என்று அழைக்கப்படுகிறது மற்றும் ஒரு IP முகவரி ஒதுக்கப்படுகிறது. உள்வரும் எந்தவொரு கோரிக்கையும் காய்களில் ஒன்றிற்கு திருப்பி விடப்படும்:

   

3. வரிசைப்படுத்தல் காட்சி பயன்பாட்டின் நிகழ்வுகளின் எண்ணிக்கையை தீர்மானிக்கிறது. நீங்கள் ஒருபோதும் நேரடியாக விரிவாக்க வேண்டியதில்லை:

   

4. ஒவ்வொரு பாட்க்கும் அதன் சொந்த ஐபி முகவரி ஒதுக்கப்பட்டுள்ளது:

   

சேவைகளை ஐபி முகவரிகளின் தொகுப்பாகக் கருதுவது பயனுள்ளது. ஒவ்வொரு முறையும் நீங்கள் சேவையை அணுகும்போது, ​​பட்டியலில் இருந்து IP முகவரிகளில் ஒன்று தேர்ந்தெடுக்கப்பட்டு, இலக்கு முகவரியாகப் பயன்படுத்தப்படும்.

இது போல் தெரிகிறது.

1. சேவைக்கு கர்ல் 10.96.45.152 கோரிக்கை பெறப்பட்டது:

   

2. சேவையானது மூன்று பாட் முகவரிகளில் ஒன்றை இலக்காகத் தேர்ந்தெடுக்கிறது:

   

3. ட்ராஃபிக் குறிப்பிட்ட பாட்க்கு திருப்பி விடப்படுகிறது:

   

உங்கள் பயன்பாட்டில் முன்பக்கம் மற்றும் பின்தளம் இருந்தால், ஒவ்வொன்றிற்கும் ஒரு சேவை மற்றும் வரிசைப்படுத்தல் இரண்டும் இருக்கும்.

முன்பக்கம் பின்தளத்தில் கோரிக்கை வைக்கும் போது, ​​பின்தளத்தில் எத்தனை காய்கள் சேவை செய்கின்றன என்பதை அது சரியாகத் தெரிந்து கொள்ள வேண்டியதில்லை: ஒன்று, பத்து அல்லது நூறு இருக்கலாம்.

மேலும், பின்தளத்தில் சேவை செய்யும் காய்களின் முகவரிகள் பற்றி முன்பகுதிக்கு எதுவும் தெரியாது.

முன்பக்கம் பின்தளத்தில் கோரிக்கை வைக்கும் போது, ​​அது பின்தள சேவையின் IP முகவரியைப் பயன்படுத்துகிறது, அது மாறாது.

இது எப்படி இருக்கிறது.

1. 1 இன் கீழ் உள்ளக பின்தள கூறுகளைக் கோருகிறது. பின்தளத்திற்கு ஒரு குறிப்பிட்ட ஒன்றைத் தேர்ந்தெடுப்பதற்குப் பதிலாக, இது சேவைக்கு ஒரு கோரிக்கையை செய்கிறது:

   

2. சேவையானது பின்தளத்தில் உள்ள காய்களில் ஒன்றை இலக்கு முகவரியாகத் தேர்ந்தெடுக்கிறது:

   

3. சேவையால் தேர்ந்தெடுக்கப்பட்ட Pod 1 இலிருந்து Pod 5 வரை போக்குவரத்து செல்கிறது:

   

4. 1 வயதிற்குட்பட்டவர்களுக்கு, 5 வயதிற்குட்பட்ட காய்கள் சேவையின் பின்னால் எவ்வளவு காய்கள் மறைக்கப்பட்டுள்ளன என்பது சரியாகத் தெரியாது:

   

ஆனால் சேவை கோரிக்கைகளை எவ்வாறு சரியாக விநியோகிக்கிறது? ரவுண்ட் ராபின் பேலன்சிங் பயன்படுத்தப்பட்டது போல் தெரிகிறதா? அதை கண்டுபிடிக்கலாம். 

குபெர்னெட்ஸ் சேவைகளில் சமநிலைப்படுத்துதல்

குபெர்னெட்ஸ் சேவைகள் இல்லை. IP முகவரி மற்றும் போர்ட் ஒதுக்கப்படும் சேவைக்கு எந்த செயல்முறையும் இல்லை.

கிளஸ்டரில் உள்ள எந்த முனையிலும் உள்நுழைந்து netstat -ntlp கட்டளையை இயக்குவதன் மூலம் இதை நீங்கள் சரிபார்க்கலாம்.

சேவைக்கு ஒதுக்கப்பட்ட ஐபி முகவரியைக் கூட உங்களால் கண்டுபிடிக்க முடியாது.

சேவையின் ஐபி முகவரி கட்டுப்பாட்டு அடுக்கில், கட்டுப்படுத்தியில் அமைந்துள்ளது மற்றும் தரவுத்தளத்தில் பதிவு செய்யப்பட்டுள்ளது - முதலியன. அதே முகவரியை மற்றொரு கூறு பயன்படுத்துகிறது - kube-proxy.
அனைத்து சேவைகளுக்கான IP முகவரிகளின் பட்டியலை Kube-proxy பெறுகிறது மற்றும் கிளஸ்டரில் உள்ள ஒவ்வொரு முனையிலும் iptables விதிகளின் தொகுப்பை உருவாக்குகிறது.

இந்த விதிகள் கூறுகின்றன: "சேவையின் ஐபி முகவரியைக் கண்டால், கோரிக்கையின் இலக்கு முகவரியை மாற்றியமைத்து அதை ஒரு காய்க்கு அனுப்ப வேண்டும்."

சேவை ஐபி முகவரி ஒரு நுழைவுப் புள்ளியாக மட்டுமே பயன்படுத்தப்படுகிறது மற்றும் அந்த ஐபி முகவரி மற்றும் போர்ட்டைக் கேட்கும் எந்தச் செயல்முறையாலும் வழங்கப்படாது.

இதைப் பார்ப்போம். 

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 சீரற்ற விநியோகத்துடன் ஒரு புள்ளியியல் தொகுதியைப் பயன்படுத்துகிறது. எனவே, சமநிலைப்படுத்தும் அல்காரிதம் சீரற்ற தேர்வை அடிப்படையாகக் கொண்டது.

சேவைகள் எவ்வாறு செயல்படுகின்றன என்பதை இப்போது நீங்கள் புரிந்து கொண்டீர்கள், மேலும் சுவாரஸ்யமான சேவை காட்சிகளைப் பார்ப்போம்.

குபெர்னெட்டஸில் உள்ள நீண்ட கால இணைப்புகள் இயல்பாக அளவிடப்படுவதில்லை

ஒவ்வொரு HTTP கோரிக்கையும் முன்பக்கத்திலிருந்து பின்தளத்திற்கு ஒரு தனி TCP இணைப்பு மூலம் வழங்கப்படுகிறது, இது திறக்கப்பட்டு மூடப்படும்.

முன்பக்கம் பின்தளத்திற்கு வினாடிக்கு 100 கோரிக்கைகளை அனுப்பினால், 100 வெவ்வேறு TCP இணைப்புகள் திறக்கப்பட்டு மூடப்படும்.

ஒரு TCP இணைப்பைத் திறந்து, அதைத் தொடர்ந்து வரும் அனைத்து HTTP கோரிக்கைகளுக்கும் பயன்படுத்துவதன் மூலம் கோரிக்கை செயலாக்க நேரத்தையும் ஏற்றுதலையும் குறைக்கலாம்.

HTTP நெறிமுறையில் HTTP Keep-alive அல்லது இணைப்பு மறுபயன்பாடு என்ற அம்சம் உள்ளது. இந்த வழக்கில், பல HTTP கோரிக்கைகள் மற்றும் பதில்களை அனுப்பவும் பெறவும் ஒரு TCP இணைப்பு பயன்படுத்தப்படுகிறது:

இந்த அம்சம் முன்னிருப்பாக இயக்கப்படவில்லை: சர்வர் மற்றும் கிளையன்ட் இரண்டும் அதற்கேற்ப கட்டமைக்கப்பட வேண்டும்.

அமைப்பானது எளிமையானது மற்றும் பெரும்பாலான நிரலாக்க மொழிகள் மற்றும் சூழல்களுக்கு அணுகக்கூடியது.

வெவ்வேறு மொழிகளில் உள்ள எடுத்துக்காட்டுகளுக்கான சில இணைப்புகள் இங்கே:

• Node.js இல் உயிருடன் இருக்கவும்
• ஸ்பிரிங் பூட்டில் உயிருடன் இருக்கவும்
• பைத்தானில் உயிருடன் இருங்கள்
• .NET இல் உயிருடன் இருக்கவும்

குபெர்னெட்ஸ் சேவையில் கீப்-ஆலைவ் பயன்படுத்தினால் என்ன நடக்கும்?
முன்னோட்டம் மற்றும் பின்தளம் இரண்டும் உயிர்வாழ ஆதரிக்கின்றன என்று வைத்துக்கொள்வோம்.

எங்களிடம் முன்பக்கத்தின் ஒரு நகல் மற்றும் பின்தளத்தின் மூன்று பிரதிகள் உள்ளன. முன்பக்கம் முதல் கோரிக்கையை முன்வைக்கிறது மற்றும் பின்தளத்தில் TCP இணைப்பை திறக்கிறது. கோரிக்கை சேவையை சென்றடைகிறது, பின்தளத்தில் ஒன்று இலக்கு முகவரியாக தேர்ந்தெடுக்கப்பட்டது. பின்தளம் ஒரு பதிலை அனுப்புகிறது, மேலும் முன்பக்கம் அதைப் பெறுகிறது.

ஒரு பதிலைப் பெற்ற பிறகு TCP இணைப்பு மூடப்பட்டிருக்கும் வழக்கமான சூழ்நிலையைப் போலல்லாமல், மேலும் HTTP கோரிக்கைகளுக்கு அது இப்போது திறந்து வைக்கப்பட்டுள்ளது.

முன்தளமானது பின்தளத்திற்கு அதிக கோரிக்கைகளை அனுப்பினால் என்ன நடக்கும்?

இந்தக் கோரிக்கைகளை அனுப்ப, திறந்த TCP இணைப்பு பயன்படுத்தப்படும், அனைத்து கோரிக்கைகளும் முதல் கோரிக்கை சென்ற அதே பின்தளத்திற்கு செல்லும்.

iptables போக்குவரத்தை மறுபகிர்வு செய்ய வேண்டாமா?

இந்த விஷயத்தில் இல்லை.

ஒரு TCP இணைப்பு உருவாக்கப்படும் போது, ​​அது iptables விதிகள் வழியாக செல்கிறது, இது போக்குவரத்து செல்லும் ஒரு குறிப்பிட்ட பின்தளத்தைத் தேர்ந்தெடுக்கிறது.

அனைத்து அடுத்தடுத்த கோரிக்கைகளும் ஏற்கனவே திறந்த TCP இணைப்பில் இருப்பதால், iptables விதிகள் இனி அழைக்கப்படாது.

அது எப்படி இருக்கும் என்று பார்ப்போம்.

1. முதல் பாட் சேவைக்கு ஒரு கோரிக்கையை அனுப்புகிறது:

   

2. அடுத்து என்ன நடக்கும் என்பது உங்களுக்கு ஏற்கனவே தெரியும். சேவை இல்லை, ஆனால் கோரிக்கையைச் செயல்படுத்தும் iptables விதிகள் உள்ளன:

   

3. பின்தளத்தில் உள்ள காய்களில் ஒன்று இலக்கு முகவரியாக தேர்ந்தெடுக்கப்படும்:

   

4. கோரிக்கை பட்டியை அடைகிறது. இந்த கட்டத்தில், இரண்டு காய்களுக்கு இடையே ஒரு நிலையான TCP இணைப்பு நிறுவப்படும்:

   

5. முதல் பாடலிலிருந்து வரும் எந்தவொரு கோரிக்கையும் ஏற்கனவே நிறுவப்பட்ட இணைப்பு வழியாகச் செல்லும்:

   

இதன் விளைவாக விரைவான மறுமொழி நேரம் மற்றும் அதிக செயல்திறன் உள்ளது, ஆனால் பின்தளத்தை அளவிடும் திறனை நீங்கள் இழக்கிறீர்கள்.

பின்தளத்தில் இரண்டு காய்கள் இருந்தாலும், நிலையான இணைப்புடன், போக்குவரத்து எப்போதும் அவற்றில் ஒன்றிற்குச் செல்லும்.

இதை சரிசெய்ய முடியுமா?

தொடர்ச்சியான இணைப்புகளை எவ்வாறு சமநிலைப்படுத்துவது என்பது குபெர்னெட்டஸுக்குத் தெரியாததால், இந்தப் பணி உங்களுடையது.

சேவைகள் என்பது IP முகவரிகள் மற்றும் எண்ட் பாயிண்ட்ஸ் எனப்படும் போர்ட்களின் தொகுப்பாகும்.

உங்கள் விண்ணப்பமானது சேவையிலிருந்து இறுதிப் புள்ளிகளின் பட்டியலைப் பெறலாம் மற்றும் அவற்றுக்கிடையே கோரிக்கைகளை எவ்வாறு விநியோகிப்பது என்பதைத் தீர்மானிக்கலாம். ரவுண்ட்-ராபினைப் பயன்படுத்தி இந்த இணைப்புகளுக்கு இடையே ஒவ்வொரு பாட் மற்றும் பேலன்ஸ் கோரிக்கைகளுக்கும் ஒரு தொடர் இணைப்பைத் திறக்கலாம்.

அல்லது அதிகமாக விண்ணப்பிக்கவும் சிக்கலான சமநிலை நெறிமுறைகள்.

சமநிலைக்கு பொறுப்பான கிளையன்ட் பக்க குறியீடு இந்த தர்க்கத்தைப் பின்பற்ற வேண்டும்:

1. சேவையிலிருந்து இறுதிப் புள்ளிகளின் பட்டியலைப் பெறவும்.
2. ஒவ்வொரு முனைப்புள்ளிக்கும் ஒரு தொடர் இணைப்பைத் திறக்கவும்.
3. கோரிக்கை செய்யப்படும்போது, ​​திறந்த இணைப்புகளில் ஒன்றைப் பயன்படுத்தவும்.
4. இறுதிப்புள்ளிகளின் பட்டியலைத் தொடர்ந்து புதுப்பிக்கவும், புதியவற்றை உருவாக்கவும் அல்லது பட்டியல் மாறினால் பழைய தொடர் இணைப்புகளை மூடவும்.

இப்படித்தான் இருக்கும்.

1. சேவைக்கு கோரிக்கையை அனுப்பும் முதல் பாட் பதிலாக, கிளையன்ட் பக்கத்தில் உள்ள கோரிக்கைகளை நீங்கள் சமநிலைப்படுத்தலாம்:

   

2. எந்த காய்கள் சேவையின் ஒரு பகுதியாகும் என்று கேட்கும் குறியீட்டை நீங்கள் எழுத வேண்டும்:

   

3. நீங்கள் பட்டியலைப் பெற்றவுடன், அதை கிளையன்ட் பக்கத்தில் சேமித்து, காய்களுடன் இணைக்க அதைப் பயன்படுத்தவும்:

   

4. சுமை சமநிலைப்படுத்தும் அல்காரிதத்திற்கு நீங்கள் பொறுப்பு:

   

இப்போது கேள்வி எழுகிறது: இந்தச் சிக்கல் HTTP-ஐ உயிருடன் வைத்திருக்க மட்டும் பொருந்துமா?

வாடிக்கையாளர் பக்க சுமை சமநிலை

நிலையான TCP இணைப்புகளைப் பயன்படுத்தக்கூடிய ஒரே நெறிமுறை HTTP அல்ல.

உங்கள் பயன்பாடு ஒரு தரவுத்தளத்தைப் பயன்படுத்தினால், ஒவ்வொரு முறையும் நீங்கள் கோரிக்கை வைக்க அல்லது தரவுத்தளத்திலிருந்து ஆவணத்தை மீட்டெடுக்கும் போது 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

இந்த நெறிமுறைகளில் பெரும்பாலானவற்றை நீங்கள் ஏற்கனவே அறிந்திருக்க வேண்டும்.

ஆனால் இந்த நெறிமுறைகள் மிகவும் பிரபலமாக இருந்தால், ஏன் தரப்படுத்தப்பட்ட சமநிலை தீர்வு இல்லை? வாடிக்கையாளர் தர்க்கம் ஏன் மாற வேண்டும்? பூர்வீக குபெர்னெட்ஸ் தீர்வு உள்ளதா?

Kube-proxy மற்றும் iptables ஆகியவை Kubernetes க்கு பயன்படுத்தப்படும் போது மிகவும் பொதுவான பயன்பாட்டு நிகழ்வுகளை உள்ளடக்கும் வகையில் வடிவமைக்கப்பட்டுள்ளன. இது வசதிக்காக.

நீங்கள் REST API ஐ வெளிப்படுத்தும் இணையச் சேவையைப் பயன்படுத்துகிறீர்கள் என்றால், நீங்கள் அதிர்ஷ்டசாலி - இந்த விஷயத்தில், நிலையான TCP இணைப்புகள் பயன்படுத்தப்படாது, நீங்கள் எந்த Kubernetes சேவையையும் பயன்படுத்தலாம்.

ஆனால் நீங்கள் தொடர்ந்து TCP இணைப்புகளைப் பயன்படுத்தத் தொடங்கினால், பின்தளங்களில் சுமையை எவ்வாறு சமமாக விநியோகிப்பது என்பதை நீங்கள் கண்டுபிடிக்க வேண்டும். இந்த வழக்குக்கான ஆயத்த தீர்வுகளை Kubernetes கொண்டிருக்கவில்லை.

இருப்பினும், நிச்சயமாக உதவக்கூடிய விருப்பங்கள் உள்ளன.

குபெர்னெட்டஸில் நீண்ட கால இணைப்புகளை சமநிலைப்படுத்துதல்

குபெர்னெட்ஸில் நான்கு வகையான சேவைகள் உள்ளன:

1. ClusterIP
2. நோட்போர்ட்
3. லோட் பேலன்சர்
4. தலை இல்லாத

முதல் மூன்று சேவைகளும் மெய்நிகர் ஐபி முகவரியின் அடிப்படையில் இயங்குகின்றன, இது iptables விதிகளை உருவாக்க kube-proxy ஆல் பயன்படுத்தப்படுகிறது. ஆனால் அனைத்து சேவைகளின் அடிப்படை அடிப்படையானது தலையில்லாத சேவையாகும்.

ஹெட்லெஸ் சேவையானது அதனுடன் தொடர்புடைய எந்த ஐபி முகவரியும் கொண்டிருக்கவில்லை மற்றும் அதனுடன் தொடர்புடைய காய்களின் (இறுதிப்புள்ளிகள்) ஐபி முகவரிகள் மற்றும் போர்ட்களின் பட்டியலை மீட்டெடுப்பதற்கான ஒரு பொறிமுறையை மட்டுமே வழங்குகிறது.

அனைத்து சேவைகளும் தலையில்லாத சேவையை அடிப்படையாகக் கொண்டவை.

ClusterIP சேவையானது சில சேர்த்தல்களுடன் கூடிய தலையில்லாத சேவையாகும்: 

1. மேலாண்மை அடுக்கு அதற்கு ஒரு ஐபி முகவரியை வழங்குகிறது.
2. Kube-proxy தேவையான iptables விதிகளை உருவாக்குகிறது.

இந்த வழியில் நீங்கள் kube-proxy ஐப் புறக்கணிக்கலாம் மற்றும் உங்கள் விண்ணப்பத்தை சமநிலைப்படுத்த, ஹெட்லெஸ் சேவையிலிருந்து பெறப்பட்ட இறுதிப்புள்ளிகளின் பட்டியலை நேரடியாகப் பயன்படுத்தலாம்.

ஆனால் க்ளஸ்டரில் உள்ள அனைத்து பயன்பாடுகளுக்கும் ஒரே மாதிரியான தர்க்கத்தை எவ்வாறு சேர்க்கலாம்?

உங்கள் விண்ணப்பம் ஏற்கனவே பயன்படுத்தப்பட்டிருந்தால், இந்த பணி சாத்தியமற்றதாகத் தோன்றலாம். இருப்பினும், ஒரு மாற்று விருப்பம் உள்ளது.

சேவை மெஷ் உங்களுக்கு உதவும்

கிளையன்ட் பக்க சுமை சமநிலை உத்தி மிகவும் நிலையானது என்பதை நீங்கள் ஏற்கனவே கவனித்திருக்கலாம்.

பயன்பாடு தொடங்கும் போது, ​​அது:

1. சேவையிலிருந்து ஐபி முகவரிகளின் பட்டியலைப் பெறுகிறது.
2. இணைப்புக் குளத்தைத் திறந்து பராமரிக்கிறது.
3. இறுதிப்புள்ளிகளைச் சேர்ப்பதன் மூலம் அல்லது அகற்றுவதன் மூலம் குளத்தை அவ்வப்போது புதுப்பிக்கிறது.

விண்ணப்பம் ஒரு கோரிக்கையைச் செய்ய விரும்பினால், அது:

1. சில தர்க்கத்தைப் பயன்படுத்தி கிடைக்கக்கூடிய இணைப்பைத் தேர்ந்தெடுக்கிறது (எ.கா. ரவுண்ட்-ராபின்).
2. கோரிக்கையை நிறைவேற்றுகிறது.

இந்த படிகள் WebSockets, gRPC மற்றும் AMQP இணைப்புகள் இரண்டிற்கும் வேலை செய்கின்றன.

இந்த தர்க்கத்தை தனி நூலகமாக பிரித்து உங்கள் பயன்பாடுகளில் பயன்படுத்தலாம்.

இருப்பினும், அதற்கு பதிலாக இஸ்டியோ அல்லது லிங்கர்ட் போன்ற சேவை மெஷ்களைப் பயன்படுத்தலாம்.

சேவை மெஷ் உங்கள் விண்ணப்பத்தை ஒரு செயல்முறையுடன் அதிகரிக்கிறது:

1. சேவை ஐபி முகவரிகளைத் தானாகத் தேடுகிறது.
2. WebSockets மற்றும் gRPC போன்ற இணைப்புகளை சோதிக்கிறது.
3. சரியான நெறிமுறையைப் பயன்படுத்தி கோரிக்கைகளை சமநிலைப்படுத்துகிறது.

சர்வீஸ் மெஷ் க்ளஸ்டருக்குள் போக்குவரத்தை நிர்வகிக்க உதவுகிறது, ஆனால் இது மிகவும் வளம் மிகுந்ததாகும். மற்ற விருப்பங்கள் Netflix Ribbon போன்ற மூன்றாம் தரப்பு நூலகங்கள் அல்லது Envoy போன்ற நிரல்படுத்தக்கூடிய ப்ராக்ஸிகளைப் பயன்படுத்துகின்றன.

சமநிலை சிக்கல்களை நீங்கள் புறக்கணித்தால் என்ன நடக்கும்?

சுமை சமநிலையைப் பயன்படுத்த வேண்டாம் என்று நீங்கள் தேர்வு செய்யலாம், இன்னும் எந்த மாற்றத்தையும் கவனிக்க முடியாது. ஒரு சில வேலை காட்சிகளைப் பார்ப்போம்.

நீங்கள் சர்வர்களை விட அதிகமான வாடிக்கையாளர்களைக் கொண்டிருந்தால், இது அவ்வளவு பெரிய பிரச்சனை அல்ல.

இரண்டு சேவையகங்களுடன் இணைக்கும் ஐந்து கிளையண்டுகள் உள்ளன என்று வைத்துக்கொள்வோம். சமநிலை இல்லாவிட்டாலும், இரண்டு சேவையகங்களும் பயன்படுத்தப்படும்:

இணைப்புகள் சமமாக விநியோகிக்கப்படாமல் இருக்கலாம்: ஒருவேளை நான்கு கிளையண்டுகள் ஒரே சேவையகத்துடன் இணைக்கப்பட்டிருக்கலாம், ஆனால் இரண்டு சேவையகங்களும் பயன்படுத்தப்படுவதற்கான நல்ல வாய்ப்பு உள்ளது.

இதற்கு நேர்மாறான சூழ்நிலைதான் மிகவும் சிக்கலானது.

உங்களிடம் குறைவான கிளையண்டுகள் மற்றும் அதிக சேவையகங்கள் இருந்தால், உங்கள் வளங்கள் குறைவாகப் பயன்படுத்தப்படலாம் மற்றும் சாத்தியமான இடையூறு தோன்றும்.

இரண்டு கிளையண்டுகள் மற்றும் ஐந்து சேவையகங்கள் உள்ளன என்று வைத்துக்கொள்வோம். சிறந்த நிலையில், ஐந்தில் இரண்டு சேவையகங்களுக்கு இரண்டு நிரந்தர இணைப்புகள் இருக்கும்.

மீதமுள்ள சேவையகங்கள் செயலற்ற நிலையில் இருக்கும்:

இந்த இரண்டு சேவையகங்களால் கிளையன்ட் கோரிக்கைகளைக் கையாள முடியாவிட்டால், கிடைமட்ட அளவிடுதல் உதவாது.

முடிவுக்கு

குபெர்னெட்ஸ் சேவைகள் பெரும்பாலான நிலையான இணைய பயன்பாட்டுக் காட்சிகளில் வேலை செய்ய வடிவமைக்கப்பட்டுள்ளன.

இருப்பினும், தரவுத்தளங்கள், gRPC அல்லது WebSockets போன்ற நிலையான TCP இணைப்புகளைப் பயன்படுத்தும் பயன்பாட்டு நெறிமுறைகளுடன் நீங்கள் பணிபுரியத் தொடங்கினால், சேவைகள் இனி பொருந்தாது. தொடர்ச்சியான TCP இணைப்புகளை சமநிலைப்படுத்துவதற்கான உள் வழிமுறைகளை குபெர்னெட்ஸ் வழங்கவில்லை.

இதன் பொருள் நீங்கள் வாடிக்கையாளர் பக்க சமநிலையை மனதில் கொண்டு பயன்பாடுகளை எழுத வேண்டும்.

குழு தயாரித்த மொழிபெயர்ப்பு Mail.ru இலிருந்து Kubernetes aaS.

தலைப்பில் வேறு என்ன படிக்க வேண்டும்:

1. குபெர்னெட்ஸில் ஆட்டோஸ்கேலிங் மூன்று நிலைகள் மற்றும் அவற்றை எவ்வாறு திறம்பட பயன்படுத்துவது. 
2. செயல்படுத்துவதற்கான டெம்ப்ளேட்டுடன் திருட்டு உணர்வில் குபெர்னெட்ஸ்.
3. டிஜிட்டல் மாற்றம் பற்றிய எங்கள் டெலிகிராம் சேனல்.

ஆதாரம்: www.habr.com