🥇டிண்டர் குபெர்னெட்டஸுக்கு மாற்றம்

குறிப்பு. மொழிபெயர்: உலகப் புகழ்பெற்ற டிண்டர் சேவையின் ஊழியர்கள் சமீபத்தில் குபெர்னெட்டஸுக்கு தங்கள் உள்கட்டமைப்பை மாற்றுவதற்கான சில தொழில்நுட்ப விவரங்களைப் பகிர்ந்து கொண்டனர். இந்த செயல்முறை கிட்டத்தட்ட இரண்டு ஆண்டுகள் எடுத்தது மற்றும் K8s இல் மிகப் பெரிய அளவிலான இயங்குதளத்தை அறிமுகப்படுத்தியது, இதில் 200 ஆயிரம் கொள்கலன்களில் 48 சேவைகள் வழங்கப்படுகின்றன. டிண்டர் பொறியாளர்கள் என்ன சுவாரசியமான சிரமங்களை எதிர்கொண்டார்கள் மற்றும் அவர்கள் என்ன முடிவுகளை அடைந்தார்கள்? இந்த மொழிபெயர்ப்பைப் படியுங்கள்.

ஏன்?

ஏறக்குறைய இரண்டு ஆண்டுகளுக்கு முன்பு, டிண்டர் அதன் தளத்தை குபெர்னெட்டஸுக்கு மாற்ற முடிவு செய்தது. குபெர்னெட்டஸ் டிண்டர் குழுவை மாற்ற முடியாத வரிசைப்படுத்தல் மூலம் குறைந்த முயற்சியுடன் கொள்கலன் செய்து உற்பத்திக்கு செல்ல அனுமதிக்கும் (மாறாத வரிசைப்படுத்தல்). இந்த வழக்கில், பயன்பாடுகளின் அசெம்பிளி, அவற்றின் வரிசைப்படுத்தல் மற்றும் உள்கட்டமைப்பு ஆகியவை குறியீட்டால் தனித்துவமாக வரையறுக்கப்படும்.

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

செயல்முறை கடினமாக மாறியது. 2019 ஆம் ஆண்டின் முற்பகுதியில் எங்கள் இடம்பெயர்வின் போது, குபெர்னெட்டஸ் கிளஸ்டர் முக்கியமான வெகுஜனத்தை அடைந்தது மற்றும் போக்குவரத்து அளவு, கிளஸ்டர் அளவு மற்றும் DNS காரணமாக பல்வேறு பிரச்சனைகளை சந்திக்க ஆரம்பித்தோம். வழியில், 200 சேவைகளை நகர்த்துவது மற்றும் 1000 முனைகள், 15000 காய்கள் மற்றும் 48000 இயங்கும் கொள்கலன்களைக் கொண்ட குபெர்னெட்ஸ் கிளஸ்டரைப் பராமரிப்பது தொடர்பான பல சுவாரஸ்யமான சிக்கல்களைத் தீர்த்தோம்.

எப்படி?

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

குபெர்னெட்ஸிற்கான படங்களை உருவாக்குதல்

குபெர்னெட்ஸ் கிளஸ்டரில் இயங்கும் மைக்ரோ சர்வீஸிற்கான 30 க்கும் மேற்பட்ட மூலக் குறியீடு களஞ்சியங்கள் எங்களிடம் உள்ளன. இந்தக் களஞ்சியங்களில் உள்ள குறியீடு வெவ்வேறு மொழிகளில் (உதாரணமாக, Node.js, Java, Scala, Go) ஒரே மொழிக்கான பல இயக்க நேர சூழல்களுடன் எழுதப்பட்டுள்ளது.

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

படம் 1-1. பில்டர் கொள்கலன் வழியாக தரப்படுத்தப்பட்ட உருவாக்க செயல்முறை

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

அவரது கொள்கலன் செயலாக்கத்திற்கு மேம்பட்ட டோக்கர் நுட்பங்கள் தேவைப்பட்டன. தனிப்பட்ட டிண்டர் களஞ்சியங்களை அணுகுவதற்கு தேவையான உள்ளூர் பயனர் ஐடி மற்றும் ரகசியங்களை (SSH விசை, AWS நற்சான்றிதழ்கள் போன்றவை) பில்டர் பெறுகிறார். இது இயற்கையாகவே உருவாக்க கலைப்பொருட்களை சேமித்து வைக்க ஆதாரங்களைக் கொண்ட உள்ளூர் அடைவுகளை ஏற்றுகிறது. இந்த அணுகுமுறை செயல்திறனை மேம்படுத்துகிறது, ஏனெனில் இது பில்டர் கொள்கலன் மற்றும் ஹோஸ்டுக்கு இடையே உள்ள கலைப்பொருட்களை நகலெடுக்க வேண்டிய தேவையை நீக்குகிறது. கூடுதல் கட்டமைப்பு இல்லாமல் சேமிக்கப்பட்ட கட்டுமான கலைப்பொருட்கள் மீண்டும் பயன்படுத்தப்படலாம்.

சில சேவைகளுக்கு, தொகுத்தல் சூழலை இயக்க நேர சூழலுக்கு வரைபடமாக்க மற்றொரு கொள்கலனை உருவாக்க வேண்டியிருந்தது (எடுத்துக்காட்டாக, நிறுவலின் போது Node.js bcrypt நூலகம் இயங்குதளம் சார்ந்த பைனரி கலைப்பொருட்களை உருவாக்குகிறது). தொகுத்தல் செயல்பாட்டின் போது, சேவைகளுக்கு இடையே தேவைகள் மாறுபடலாம், மேலும் இறுதி Dockerfile பறக்கும்போது தொகுக்கப்படும்.

குபெர்னெட்ஸ் கிளஸ்டர் கட்டிடக்கலை மற்றும் இடம்பெயர்வு

கிளஸ்டர் அளவு மேலாண்மை

பயன்படுத்த முடிவு செய்தோம் kube-aws Amazon EC2 நிகழ்வுகளில் தானியங்கு கிளஸ்டர் வரிசைப்படுத்தலுக்கு. ஆரம்பத்தில், அனைத்தும் ஒரு பொதுவான முனைகளில் வேலை செய்தன. வளங்களை மிகவும் திறமையாகப் பயன்படுத்த, பணிச்சுமைகளை அளவு மற்றும் நிகழ்வு வகை மூலம் பிரிக்க வேண்டியதன் அவசியத்தை நாங்கள் விரைவாக உணர்ந்தோம். தர்க்கம் என்னவென்றால், பல ஏற்றப்பட்ட மல்டி-த்ரெட் காய்களை இயக்குவது, அதிக எண்ணிக்கையிலான ஒற்றை-திரிக்கப்பட்ட காய்களுடன் இணைந்திருப்பதை விட செயல்திறனின் அடிப்படையில் மிகவும் யூகிக்கக்கூடியதாக மாறியது.

இறுதியில் நாங்கள் முடிவு செய்தோம்:

மீ 5.4x பெரியது - கண்காணிப்புக்கு (ப்ரோமிதியஸ்);
c5.4x பெரியது - Node.js பணிச்சுமைக்கு (ஒற்றை-திரிக்கப்பட்ட பணிச்சுமை);
c5.2x பெரியது - ஜாவா மற்றும் கோ (மல்டித்ரெட் பணிச்சுமை);
c5.4x பெரியது - கட்டுப்பாட்டு பலகத்திற்கு (3 முனைகள்).

இடம்பெயர்வு

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

ஒவ்வொரு புதிய ELB யையும் சுட்டிக்காட்டும் CNAMEகள் கொண்ட DNS பதிவுகளின் எடையுள்ள செட்களைப் பயன்படுத்தி இந்த இறுதிப்புள்ளிகள் உருவாக்கப்பட்டன. மாற்றுவதற்கு, குபெர்னெட்டஸ் சேவையின் புதிய ELBஐ 0 எடையுடன் சுட்டிக்காட்டும் புதிய உள்ளீட்டைச் சேர்த்துள்ளோம். அதன்பின் டைம் டு லைவ் (TTL)ஐ 0 ஆக அமைத்தோம். இதற்குப் பிறகு, பழைய மற்றும் புதிய எடைகள் மெதுவாக சரிசெய்யப்பட்டு, இறுதியில் 100% சுமை புதிய சேவையகத்திற்கு அனுப்பப்பட்டது. மாறுதல் முடிந்ததும், TTL மதிப்பு மிகவும் போதுமான நிலைக்குத் திரும்பியது.

எங்களிடம் இருந்த ஜாவா தொகுதிகள் குறைந்த TTL DNS ஐ சமாளிக்க முடியும், ஆனால் நோட் பயன்பாடுகளால் முடியவில்லை. பொறியாளர்களில் ஒருவர் இணைப்புக் குழுக் குறியீட்டின் ஒரு பகுதியை மீண்டும் எழுதி, ஒவ்வொரு 60 வினாடிகளுக்கும் குளங்களை மேம்படுத்தும் மேலாளரில் அதைச் சுற்றினார். தேர்ந்தெடுக்கப்பட்ட அணுகுமுறை மிகவும் நன்றாக வேலை செய்தது மற்றும் குறிப்பிடத்தக்க செயல்திறன் சிதைவு இல்லாமல்.

பாடங்கள்

நெட்வொர்க் ஃபேப்ரிக் வரம்புகள்

ஜனவரி 8, 2019 அதிகாலையில், டிண்டர் தளம் எதிர்பாராதவிதமாக விபத்துக்குள்ளானது. அன்று காலை பிளாட்பார்ம் தாமதத்தின் தொடர்பற்ற அதிகரிப்புக்கு பதிலளிக்கும் விதமாக, கொத்துகளில் உள்ள காய்கள் மற்றும் முனைகளின் எண்ணிக்கை அதிகரித்தது. இது எங்கள் எல்லா முனைகளிலும் ARP கேச் தீர்ந்துவிட்டது.

ARP கேச் தொடர்பான மூன்று லினக்ஸ் விருப்பங்கள் உள்ளன:

(மூல)

gc_thresh3 - இது ஒரு கடினமான வரம்பு. பதிவில் "நெய்பர் டேபிள் ஓவர்ஃப்ளோ" உள்ளீடுகளின் தோற்றம் ஒத்திசைவான குப்பை சேகரிப்புக்கு (GC) பிறகும், ARP தற்காலிக சேமிப்பில் அண்டை உள்ளீட்டை சேமிக்க போதுமான இடம் இல்லை. இந்த வழக்கில், கர்னல் வெறுமனே பாக்கெட்டை முழுவதுமாக நிராகரித்தது.

நாம் பயன்படுத்த flannel குபெர்னெட்டஸில் ஒரு பிணைய துணியாக. பாக்கெட்டுகள் VXLAN வழியாக அனுப்பப்படுகின்றன. VXLAN என்பது L2 நெட்வொர்க்கின் மேல் எழுப்பப்பட்ட L3 சுரங்கப்பாதை ஆகும். தொழில்நுட்பமானது MAC-in-UDP (MAC அட்ரஸ்-இன்-யூசர் டேட்டாகிராம் புரோட்டோகால்) என்காப்சுலேஷனைப் பயன்படுத்துகிறது மற்றும் லேயர் 2 நெட்வொர்க் பிரிவுகளை விரிவாக்க அனுமதிக்கிறது. இயற்பியல் தரவு மைய நெட்வொர்க்கில் உள்ள போக்குவரத்து நெறிமுறை IP மற்றும் UDP ஆகும்.

படம் 2-1. ஃபிளானல் வரைபடம் (மூல)

படம் 2-2. VXLAN தொகுப்பு (மூல)

ஒவ்வொரு Kubernetes பணியாளரின் முனையும் ஒரு பெரிய /24 தொகுதியிலிருந்து /9 முகமூடியுடன் ஒரு மெய்நிகர் முகவரி இடத்தை ஒதுக்குகிறது. ஒவ்வொரு முனைக்கும் இது வழிமுறையாக ரூட்டிங் டேபிளில் ஒரு நுழைவு, ARP டேபிளில் ஒரு நுழைவு (ஃபிளானல்.1 இடைமுகத்தில்), மற்றும் ஸ்விட்சிங் டேபிளில் ஒரு நுழைவு (FDB). முதல் முறை ஒரு தொழிலாளி முனை தொடங்கும் போது அல்லது ஒவ்வொரு முறையும் ஒரு புதிய முனை கண்டுபிடிக்கப்படும் போது அவை சேர்க்கப்படும்.

கூடுதலாக, நோட்-பாட் (அல்லது பாட்-பாட்) தொடர்பு இறுதியில் இடைமுகம் வழியாக செல்கிறது eth0 (மேலே உள்ள Flannel வரைபடத்தில் காட்டப்பட்டுள்ளபடி). இது ஒவ்வொரு தொடர்புடைய மூலத்திற்கும் இலக்கு ஹோஸ்டுக்கும் ARP அட்டவணையில் கூடுதல் உள்ளீட்டை ஏற்படுத்துகிறது.

நம் சூழலில், இந்த வகையான தொடர்பு மிகவும் பொதுவானது. குபெர்னெட்டஸில் உள்ள சேவைப் பொருட்களுக்கு, ஒரு ELB உருவாக்கப்பட்டு, குபெர்னெட்ஸ் ஒவ்வொரு முனையையும் ELB உடன் பதிவு செய்கிறது. ELBக்கு காய்களைப் பற்றி எதுவும் தெரியாது மற்றும் தேர்ந்தெடுக்கப்பட்ட முனை பாக்கெட்டின் இறுதி இலக்காக இருக்காது. முக்கிய விஷயம் என்னவென்றால், ஒரு முனை ELB இலிருந்து ஒரு பாக்கெட்டைப் பெறும்போது, அது விதிகளை கணக்கில் எடுத்துக்கொள்வதாகக் கருதுகிறது. இப்போது iptables ஒரு குறிப்பிட்ட சேவைக்கு மற்றும் தோராயமாக மற்றொரு முனையில் ஒரு பாட் தேர்ந்தெடுக்கிறது.

தோல்வியின் போது, கிளஸ்டரில் 605 முனைகள் இருந்தன. மேலே கூறப்பட்ட காரணங்களுக்காக, முக்கியத்துவத்தை கடக்க இது போதுமானதாக இருந்தது gc_thresh3, இது இயல்புநிலை. இது நிகழும்போது, பாக்கெட்டுகள் கைவிடப்படுவது மட்டுமல்லாமல், /24 முகமூடியுடன் கூடிய முழு Flannel மெய்நிகர் முகவரி இடமும் ARP அட்டவணையில் இருந்து மறைந்துவிடும். நோட்-பாட் தொடர்பு மற்றும் டிஎன்எஸ் வினவல்கள் தடைபட்டுள்ளன (டிஎன்எஸ் ஒரு கிளஸ்டரில் ஹோஸ்ட் செய்யப்பட்டுள்ளது; விவரங்களுக்கு இந்தக் கட்டுரையில் பின்னர் படிக்கவும்).

இந்த சிக்கலை தீர்க்க, நீங்கள் மதிப்புகளை அதிகரிக்க வேண்டும் gc_thresh1, gc_thresh2 и gc_thresh3 மற்றும் காணாமல் போன நெட்வொர்க்குகளை மீண்டும் பதிவு செய்ய Flannel ஐ மறுதொடக்கம் செய்யவும்.

எதிர்பாராத DNS அளவிடுதல்

இடம்பெயர்வுச் செயல்பாட்டின் போது, போக்குவரத்தை நிர்வகிக்கவும், பழைய உள்கட்டமைப்பில் இருந்து படிப்படியாக சேவைகளை குபெர்னெட்டஸுக்கு மாற்றவும் டிஎன்எஸ்ஸை தீவிரமாகப் பயன்படுத்தினோம். Route53 இல் தொடர்புடைய RecordSetsக்கு ஒப்பீட்டளவில் குறைந்த TTL மதிப்புகளை அமைத்துள்ளோம். பழைய உள்கட்டமைப்பு EC2 நிகழ்வுகளில் இயங்கும் போது, எங்கள் தீர்வு உள்ளமைவு Amazon DNS ஐ சுட்டிக்காட்டியது. இதை நாங்கள் சாதாரணமாக எடுத்துக் கொண்டோம், எங்கள் சேவைகள் மற்றும் அமேசான் சேவைகளில் (டைனமோடிபி போன்றவை) குறைந்த TTL-ன் தாக்கம் பெரிய அளவில் கவனிக்கப்படாமல் போய்விட்டது.

நாங்கள் Kubernetes க்கு சேவைகளை மாற்றியபோது, DNS ஆனது ஒரு வினாடிக்கு 250 ஆயிரம் கோரிக்கைகளை செயலாக்குகிறது என்பதைக் கண்டறிந்தோம். இதன் விளைவாக, பயன்பாடுகள் DNS வினவல்களுக்கான நிலையான மற்றும் தீவிரமான காலக்கெடுவை அனுபவிக்கத் தொடங்கின. DNS வழங்குநரை CoreDNS க்கு மேம்படுத்துவதற்கும் மாற்றுவதற்கும் நம்பமுடியாத முயற்சிகள் இருந்தபோதிலும் இது நடந்தது (இது உச்ச சுமையில் 1000 கோர்களில் இயங்கும் 120 காய்களை எட்டியது).

மற்ற சாத்தியமான காரணங்கள் மற்றும் தீர்வுகளை ஆராயும் போது, நாங்கள் கண்டுபிடித்தோம் ஒரு கட்டுரை, பாக்கெட் வடிகட்டுதல் கட்டமைப்பை பாதிக்கும் பந்தய நிலைமைகளை விவரிக்கிறது இல் netfilter லினக்ஸில். நாங்கள் கவனித்த காலக்கெடு, அதிகரித்து வரும் கவுண்டருடன் இணைந்தது insert_failed Flannel இடைமுகத்தில் கட்டுரையின் கண்டுபிடிப்புகளுடன் ஒத்துப்போனது.

மூல மற்றும் இலக்கு நெட்வொர்க் முகவரி மொழிபெயர்ப்பின் (SNAT மற்றும் DNAT) கட்டத்தில் சிக்கல் ஏற்படுகிறது மற்றும் அட்டவணையில் அடுத்தடுத்த நுழைவு தொடர்பு. உள்நாட்டில் விவாதிக்கப்பட்ட மற்றும் சமூகத்தால் பரிந்துரைக்கப்பட்ட தீர்வுகளில் ஒன்று DNS ஐ தொழிலாளர் முனைக்கு நகர்த்துவதாகும். இந்த வழக்கில்:

SNAT தேவைப்படாது, ஏனெனில் போக்குவரத்து முனைக்குள் இருக்கும். இது இடைமுகம் வழியாக அனுப்ப வேண்டிய அவசியமில்லை eth0.
டிஎன்ஏடி தேவைப்படாது, ஏனெனில் இலக்கு ஐபி முனையில் உள்ளமையாகும், விதிகளின்படி தோராயமாக தேர்ந்தெடுக்கப்பட்ட பாட் அல்ல இப்போது iptables.

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

இருப்பினும், பாக்கெட் இழப்பு மற்றும் கவுண்டரில் அதிகரிப்பு ஆகியவற்றை நாங்கள் இன்னும் கண்டோம் insert_failed Flannel இடைமுகத்தில். டிஎன்எஸ் ட்ராஃபிக்கிற்கு மட்டும் SNAT மற்றும்/அல்லது DNATயை எங்களால் அகற்ற முடிந்தது. மற்ற வகை போக்குவரத்திற்காக பந்தய நிலைமைகள் பாதுகாக்கப்பட்டன. அதிர்ஷ்டவசமாக, எங்கள் பாக்கெட்டுகளில் பெரும்பாலானவை TCP ஆகும், மேலும் சிக்கல் ஏற்பட்டால் அவை மீண்டும் அனுப்பப்படும். அனைத்து வகையான போக்குவரத்திற்கும் பொருத்தமான தீர்வைக் கண்டறிய நாங்கள் இன்னும் முயற்சித்து வருகிறோம்.

சிறந்த சுமை சமநிலைக்கு தூதுவரைப் பயன்படுத்துதல்

நாங்கள் பின்தள சேவைகளை குபெர்னெட்டஸுக்கு மாற்றியதால், காய்களுக்கு இடையே சமநிலையற்ற சுமையால் நாங்கள் பாதிக்கப்பட ஆரம்பித்தோம். HTTP Keepalive ஆனது ELB இணைப்புகளை ஒவ்வொரு வரிசைப்படுத்துதலின் முதல் தயாராக உள்ள காய்களிலும் செயலிழக்கச் செய்ததைக் கண்டறிந்தோம். இதனால், குறைந்த சதவீத காய்கள் வழியாகவே போக்குவரத்து பெருமளவு சென்றது. நாங்கள் சோதித்த முதல் தீர்வு, மோசமான சூழ்நிலைகளுக்கான புதிய வரிசைப்படுத்தல்களில் MaxSurge ஐ 100% ஆக அமைப்பதாகும். பெரிய வரிசைப்படுத்தல்களின் அடிப்படையில் விளைவு முக்கியமற்றதாகவும் சமரசமற்றதாகவும் மாறியது.

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

நாங்கள் நீண்ட காலமாக முழுமையாக பாராட்ட விரும்புகிறோம் தூதுவர். தற்போதைய சூழ்நிலையானது, அதை மிகக் குறைந்த அளவில் பயன்படுத்தவும், உடனடி முடிவுகளைப் பெறவும் எங்களுக்கு அனுமதித்தது. Envoy என்பது பெரிய SOA பயன்பாடுகளுக்காக வடிவமைக்கப்பட்ட உயர் செயல்திறன், திறந்த மூல, லேயர்-XNUMX ப்ராக்ஸி ஆகும். தானியங்கி மறு முயற்சிகள், சர்க்யூட் பிரேக்கர்கள் மற்றும் உலகளாவிய விகிதக் கட்டுப்பாடு உள்ளிட்ட மேம்பட்ட சுமை சமநிலை நுட்பங்களை இது செயல்படுத்த முடியும். (குறிப்பு. மொழிபெயர்: இதைப் பற்றி நீங்கள் மேலும் படிக்கலாம் இந்த கட்டுரையில் இஸ்தியோவைப் பற்றி, இது தூதரை அடிப்படையாகக் கொண்டது.)

நாங்கள் பின்வரும் உள்ளமைவைக் கொண்டு வந்துள்ளோம்: ஒவ்வொரு பாட் மற்றும் ஒரு வழித்தடத்திற்கும் ஒரு தூதர் சைட்கார் மற்றும் போர்ட் வழியாக உள்ளூரில் உள்ள கொள்கலனுடன் கிளஸ்டரை இணைக்கவும். சாத்தியமான கேஸ்கேடிங்கைக் குறைக்கவும், ஒரு சிறிய வெற்றி ஆரத்தை பராமரிக்கவும், ஒவ்வொரு சேவைக்கும் கிடைக்கும் மண்டலத்திற்கு ஒன்று (AZ) என்வாய் ஃப்ரண்ட்-ப்ராக்ஸி பாட்களை நாங்கள் பயன்படுத்தினோம். எங்கள் பொறியாளர்களில் ஒருவரால் எழுதப்பட்ட ஒரு எளிய சேவை கண்டுபிடிப்பு இயந்திரத்தை அவர்கள் நம்பியிருந்தனர், அது கொடுக்கப்பட்ட சேவைக்காக ஒவ்வொரு AZ லும் உள்ள காய்களின் பட்டியலை வழங்கியது.

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

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

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

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

படம் 3-1. தூதுவராக மாறும்போது ஒரு சேவையின் CPU ஒருங்கிணைப்பு

இறுதி முடிவு

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

பழைய உள்கட்டமைப்பில் கூடுதல் திறனுக்கான தேவை ஏற்பட்டபோது, புதிய EC2 நிகழ்வுகள் தொடங்குவதற்கு நாங்கள் பல நிமிடங்கள் காத்திருக்க வேண்டியிருந்தது. இப்போது கொள்கலன்கள் இயங்கத் தொடங்கி நிமிடங்களுக்குப் பதிலாக சில நொடிகளில் போக்குவரத்தைச் செயலாக்கத் தொடங்குகின்றன. ஒரு EC2 நிகழ்வில் பல கொள்கலன்களை திட்டமிடுவது மேம்பட்ட கிடைமட்ட செறிவை வழங்குகிறது. இதன் விளைவாக, கடந்த ஆண்டை விட 2019 இல் EC2 செலவுகளில் குறிப்பிடத்தக்க குறைப்பு இருக்கும் என்று கணித்துள்ளோம்.

இடம்பெயர்வு கிட்டத்தட்ட இரண்டு ஆண்டுகள் ஆனது, ஆனால் நாங்கள் அதை மார்ச் 2019 இல் முடித்தோம். தற்போது, டிண்டர் இயங்குதளமானது 200 சேவைகள், 1000 முனைகள், 15 காய்கள் மற்றும் 000 இயங்கும் கொள்கலன்களைக் கொண்ட குபெர்னெட்ஸ் கிளஸ்டரில் பிரத்தியேகமாக இயங்குகிறது. உள்கட்டமைப்பு என்பது செயல்பாட்டுக் குழுக்களின் ஒரே களமாக இருக்காது. எங்கள் பொறியாளர்கள் அனைவரும் இந்தப் பொறுப்பைப் பகிர்ந்து கொள்கிறார்கள் மற்றும் குறியீட்டைப் பயன்படுத்தி தங்கள் பயன்பாடுகளை உருவாக்கி வரிசைப்படுத்துவதைக் கட்டுப்படுத்துகிறார்கள்.

மொழிபெயர்ப்பாளரிடமிருந்து பி.எஸ்

எங்கள் வலைப்பதிவில் தொடர் கட்டுரைகளையும் படிக்கவும்:

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

குபெர்னெட்டஸுக்கு டிண்டர் மாற்றம்