நான் குபே ஈகிளை உருவாக்கினேன் - ஒரு ப்ரோமிதியஸ் ஏற்றுமதியாளர். சிறிய மற்றும் நடுத்தர அளவிலான கிளஸ்டர்களின் வளங்களை நன்கு புரிந்துகொள்ள உதவும் ஒரு சிறந்த விஷயமாக இது மாறியது. இறுதியில், நான் நூற்றுக்கணக்கான டாலர்களைச் சேமித்தேன், ஏனெனில் நான் சரியான இயந்திர வகைகளைத் தேர்ந்தெடுத்தேன் மற்றும் பணிச்சுமைகளுக்கான பயன்பாட்டு வள வரம்புகளை உள்ளமைத்தேன்.
நன்மைகளைப் பற்றி நான் உங்களுக்குச் சொல்கிறேன் , ஆனால் முதலில் நான் வம்புக்கு என்ன காரணம் என்பதையும் உயர்தர கண்காணிப்பு ஏன் தேவை என்பதையும் விளக்குகிறேன்.
நான் 4-50 முனைகளின் பல கிளஸ்டர்களை நிர்வகித்தேன். ஒவ்வொரு கிளஸ்டரிலும் 200 மைக்ரோ சர்வீஸ்கள் மற்றும் பயன்பாடுகள் வரை இருக்கும். ஏற்கனவே உள்ள வன்பொருளை சிறப்பாகப் பயன்படுத்த, பெரும்பாலான வரிசைப்படுத்தல்கள் வெடிக்கக்கூடிய ரேம் மற்றும் CPU ஆதாரங்களுடன் கட்டமைக்கப்பட்டுள்ளன. இந்த வழியில், காய்கள் தேவைப்பட்டால் கிடைக்கக்கூடிய ஆதாரங்களை எடுத்துக் கொள்ளலாம், அதே நேரத்தில் இந்த முனையில் உள்ள பிற பயன்பாடுகளில் தலையிட வேண்டாம். சரி, நன்றாக இல்லையா?
கிளஸ்டர் ஒப்பீட்டளவில் சிறிய CPU (8%) மற்றும் RAM (40%) ஆகியவற்றை உட்கொண்டாலும், முனையில் கிடைக்கும் நினைவகத்தை விட அதிக நினைவகத்தை ஒதுக்க முயலும் போது, காய்களை முன்கூட்டியே மாற்றுவதில் எங்களுக்கு தொடர்ந்து சிக்கல்கள் இருந்தன. அப்போது எங்களிடம் குபெர்னெட்ஸ் வளங்களைக் கண்காணிக்க ஒரே ஒரு டாஷ்போர்டு மட்டுமே இருந்தது. இது போன்ற:
cAdvisor அளவீடுகள் மட்டும் கொண்ட Grafana டாஷ்போர்டு
அத்தகைய குழுவுடன், அதிக நினைவகம் மற்றும் CPU ஐ உண்ணும் முனைகளைப் பார்ப்பது ஒரு பிரச்சனையல்ல. காரணம் என்ன என்பதைக் கண்டுபிடிப்பதுதான் பிரச்சனை. காய்களை வைக்க, நிச்சயமாக அனைத்து காய்களிலும் உத்தரவாதமான ஆதாரங்களை அமைக்கலாம் (வரம்புக்கு சமமான ஆதாரங்கள் கோரப்படும்). ஆனால் இது வன்பொருளின் புத்திசாலித்தனமான பயன்பாடு அல்ல. கிளஸ்டரில் பல நூறு ஜிகாபைட் நினைவகம் இருந்தது, சில கணுக்கள் பட்டினியால் வாடுகின்றன, மற்றவை 4-10 ஜிபி கையிருப்பில் இருந்தன.
கிடைக்கக்கூடிய ஆதாரங்களில் குபெர்னெட்டஸ் திட்டமிடுபவர் பணிச்சுமையை சமமற்ற முறையில் விநியோகித்ததாக அது மாறிவிடும். Kubernetes திட்டமிடுபவர் வெவ்வேறு உள்ளமைவுகளை கணக்கில் எடுத்துக்கொள்கிறார்: தொடர்பு, கறைகள் மற்றும் சகிப்புத்தன்மை விதிகள், கிடைக்கக்கூடிய முனைகளை கட்டுப்படுத்தக்கூடிய முனை தேர்வாளர்கள். ஆனால் என் விஷயத்தில் அப்படி எதுவும் இல்லை, மேலும் ஒவ்வொரு முனையிலும் கோரப்பட்ட ஆதாரங்களைப் பொறுத்து காய்கள் திட்டமிடப்பட்டன.
மிகவும் இலவச ஆதாரங்களைக் கொண்ட மற்றும் கோரிக்கை நிபந்தனைகளை பூர்த்தி செய்யும் முனை பாட்க்கு தேர்ந்தெடுக்கப்பட்டது. முனைகளில் கோரப்பட்ட ஆதாரங்கள் உண்மையான பயன்பாட்டுடன் பொருந்தவில்லை என்பதைக் கண்டறிந்தோம், மேலும் இங்குதான் குபே ஈகிள் மற்றும் அதன் வள கண்காணிப்பு திறன்கள் மீட்புக்கு வந்தன.
நான் கிட்டத்தட்ட அனைத்து குபெர்னெட்ஸ் கிளஸ்டர்களையும் மட்டுமே கண்காணிக்கிறேன் и . நோட் எக்ஸ்போர்ட்டர் I/O மற்றும் டிஸ்க், CPU மற்றும் RAM பயன்பாடு பற்றிய புள்ளிவிவரங்களை வழங்குகிறது, அதே நேரத்தில் Kube State Metrics கோரிக்கைகள் மற்றும் CPU மற்றும் நினைவக வள வரம்புகள் போன்ற Kubernetes ஆப்ஜெக்ட் அளவீடுகளைக் காட்டுகிறது.
கிராஃபனாவில் உள்ள கோரிக்கைகள் மற்றும் வரம்பு அளவீடுகளுடன் பயன்பாட்டு அளவீடுகளை இணைக்க வேண்டும், பின்னர் சிக்கலைப் பற்றிய அனைத்து தகவல்களையும் பெறுவோம். இது எளிமையானதாகத் தெரிகிறது, ஆனால் இரண்டு கருவிகளும் உண்மையில் லேபிள்களை வித்தியாசமாகப் பெயரிடுகின்றன, மேலும் சில அளவீடுகளில் மெட்டாடேட்டா லேபிள்கள் எதுவும் இல்லை. குபே ஈகிள் எல்லாவற்றையும் தானே செய்கிறது மற்றும் குழு இதுபோல் தெரிகிறது:
வளங்கள் மற்றும் உபகரணங்களைச் சேமிப்பதில் பல சிக்கல்களைத் தீர்க்க முடிந்தது:
- மைக்ரோ சர்வீஸுக்கு எத்தனை ஆதாரங்கள் தேவை என்று சில டெவலப்பர்களுக்குத் தெரியாது (அல்லது கவலைப்படவில்லை). ஆதாரங்களுக்கான தவறான கோரிக்கைகளைக் கண்டறிய எங்களுக்கு எந்த வழியும் இல்லை - இதற்கு நுகர்வு மற்றும் கோரிக்கைகள் மற்றும் வரம்புகளை நாம் அறிந்து கொள்ள வேண்டும். இப்போது அவர்கள் ப்ரோமிதியஸ் அளவீடுகளைப் பார்க்கிறார்கள், உண்மையான பயன்பாட்டைக் கண்காணிக்கிறார்கள் மற்றும் கோரிக்கைகள் மற்றும் வரம்புகளைச் சரிசெய்கிறார்கள்.
- JVM அப்ளிகேஷன்கள் எவ்வளவு ரேமைக் கையாள முடியுமோ அவ்வளவு ரேம் எடுக்கும். குப்பை சேகரிப்பான் 75% க்கும் அதிகமாக பயன்படுத்தப்படும் போது மட்டுமே நினைவகத்தை வெளியிடுகிறது. மேலும் பெரும்பாலான சேவைகளில் வெடிக்கும் நினைவகம் இருப்பதால், அது எப்போதும் JVM ஆல் ஆக்கிரமிக்கப்பட்டது. எனவே, இந்த ஜாவா சேவைகள் அனைத்தும் எதிர்பார்த்ததை விட அதிக ரேமை உண்கின்றன.
- சில பயன்பாடுகள் அதிக நினைவகத்தைக் கோரியுள்ளன, மேலும் குபெர்னெட்ஸ் திட்டமிடுபவர் இந்த முனைகளை மற்ற பயன்பாடுகளுக்கு வழங்கவில்லை, உண்மையில் அவை மற்ற முனைகளை விட சுதந்திரமாக இருந்தாலும். ஒரு டெவலப்பர் தற்செயலாக கோரிக்கையில் கூடுதல் இலக்கத்தைச் சேர்த்து, பெரிய அளவிலான ரேமைப் பிடித்தார்: 20க்கு பதிலாக 2 ஜிபி. யாரும் கவனிக்கவில்லை. பயன்பாட்டில் 3 பிரதிகள் இருந்தன, அதனால் 3 முனைகள் பாதிக்கப்பட்டன.
- நாங்கள் வள வரம்புகளை அறிமுகப்படுத்தினோம், சரியான கோரிக்கைகளுடன் மீண்டும் திட்டமிடப்பட்ட பாட்களை அறிமுகப்படுத்தினோம், மேலும் அனைத்து முனைகளிலும் வன்பொருள் பயன்பாட்டின் சிறந்த சமநிலையைப் பெற்றுள்ளோம். ஓரிரு முனைகள் முழுவதுமாக மூடப்பட்டிருக்கலாம். எங்களிடம் தவறான இயந்திரங்கள் இருப்பதைக் கண்டோம் (CPU சார்ந்தது, நினைவகம் சார்ந்தது அல்ல). நாங்கள் வகையை மாற்றி மேலும் பல முனைகளை நீக்கிவிட்டோம்.
முடிவுகளை
கிளஸ்டரில் வெடிக்கக்கூடிய ஆதாரங்களுடன், நீங்கள் கிடைக்கக்கூடிய வன்பொருளை மிகவும் திறமையாகப் பயன்படுத்துகிறீர்கள், ஆனால் குபெர்னெட்டஸ் திட்டமிடுபவர் வளங்களுக்கான கோரிக்கைகளின் அடிப்படையில் பாட்களை திட்டமிடுகிறார், மேலும் இது நிறைந்ததாக இருக்கிறது. ஒரே கல்லில் இரண்டு பறவைகளைக் கொல்ல: சிக்கல்களைத் தவிர்க்கவும், வளங்களை முழுமையாகப் பயன்படுத்தவும், உங்களுக்கு நல்ல கண்காணிப்பு தேவை. இதனால்தான் இது பயனுள்ளதாக இருக்கும் (Prometheus ஏற்றுமதியாளர் மற்றும் Grafana டாஷ்போர்டு).
ஆதாரம்: www.habr.com