குபெர்னெட்டஸில் ஆட்டோஸ்கேலிங் மற்றும் வள மேலாண்மை (கண்ணோட்டம் மற்றும் வீடியோ அறிக்கை)

ஏப்ரல் 27 மாநாட்டில் வேலைநிறுத்தம் 2019, "DevOps" பிரிவின் ஒரு பகுதியாக, "குபெர்னெட்ஸில் ஆட்டோஸ்கேலிங் மற்றும் வள மேலாண்மை" அறிக்கை வழங்கப்பட்டது. உங்கள் பயன்பாடுகள் அதிக அளவில் கிடைப்பதை உறுதி செய்வதற்கும், உச்ச செயல்திறனை உறுதி செய்வதற்கும் K8s ஐ எவ்வாறு பயன்படுத்தலாம் என்பதைப் பற்றி இது பேசுகிறது.

பாரம்பரியமாக, நாங்கள் வழங்குவதில் மகிழ்ச்சி அடைகிறோம் அறிக்கையின் வீடியோ (44 நிமிடங்கள், கட்டுரையை விட அதிக தகவல்) மற்றும் உரை வடிவத்தில் முக்கிய சுருக்கம். போ!

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

Kubernetes

எங்கள் ஹோஸ்டில் டோக்கர் கொள்கலன்கள் உள்ளன என்று வைத்துக்கொள்வோம். எதற்காக? மீண்டும் மீண்டும் செய்யக்கூடிய மற்றும் தனிமைப்படுத்தப்படுவதை உறுதிசெய்ய, இது எளிய மற்றும் நல்ல வரிசைப்படுத்தலை அனுமதிக்கிறது, CI/CD. எங்களிடம் கண்டெய்னர்கள் கொண்ட இதுபோன்ற பல வாகனங்கள் உள்ளன.

இந்த வழக்கில் குபெர்னெட்ஸ் என்ன வழங்குகிறார்?

1. இந்த இயந்திரங்களைப் பற்றி சிந்திப்பதை நிறுத்திவிட்டு, "மேகம்" உடன் வேலை செய்யத் தொடங்குகிறோம். கொள்கலன்களின் கொத்து அல்லது காய்கள் (கொள்கலன்களின் குழுக்கள்).
2. மேலும், நாங்கள் தனிப்பட்ட காய்களைப் பற்றி சிந்திக்கவில்லை, ஆனால் அதிகமாக நிர்வகிக்கிறோம்оபெரிய குழுக்கள். அத்தகைய உயர் நிலை ஆதிகாலங்கள் ஒரு குறிப்பிட்ட பணிச்சுமையை இயக்குவதற்கு ஒரு டெம்ப்ளேட் இருப்பதாகவும், அதை இயக்குவதற்கு தேவையான எண்ணிக்கையிலான நிகழ்வுகள் இங்கே உள்ளன என்றும் கூறலாம். நாம் பின்னர் டெம்ப்ளேட்டை மாற்றினால், எல்லா நிகழ்வுகளும் மாறும்.
3. உதவியுடன் அறிவிப்பு API குறிப்பிட்ட கட்டளைகளின் வரிசையை செயல்படுத்துவதற்குப் பதிலாக, குபெர்னெட்டஸால் உருவாக்கப்பட்ட "உலகின் கட்டமைப்பை" (YAML இல்) விவரிக்கிறோம். மீண்டும்: விளக்கம் மாறும்போது, ​​அதன் உண்மையான காட்சியும் மாறும்.

வள மேலாண்மை

சிபியு

சர்வரில் nginx, php-fpm மற்றும் mysql ஐ இயக்கலாம். இந்த சேவைகள் உண்மையில் இன்னும் கூடுதலான செயல்முறைகளை இயக்கும், ஒவ்வொன்றிற்கும் கணினி ஆதாரங்கள் தேவை:

(ஸ்லைடில் உள்ள எண்கள் "கிளிகள்", கணினி சக்திக்கான ஒவ்வொரு செயல்முறையின் சுருக்கமான தேவை)

இதனுடன் வேலை செய்வதை எளிதாக்க, செயல்முறைகளை குழுக்களாக இணைப்பது தர்க்கரீதியானது (எடுத்துக்காட்டாக, அனைத்து nginx செயல்முறைகளும் ஒரு குழுவாக "nginx"). இதைச் செய்வதற்கான எளிய மற்றும் வெளிப்படையான வழி, ஒவ்வொரு குழுவையும் ஒரு கொள்கலனில் வைப்பதாகும்:

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

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

இந்த செயல்முறைகளுக்கான CPU தேவைகளுக்கு திரும்புவோம், இப்போது செயல்முறைகளின் குழுக்களுக்கு:

(எல்லா எண்களும் ஆதாரங்களின் தேவையின் சுருக்க வெளிப்பாடு என்பதை நான் மீண்டும் சொல்கிறேன்)

அதே நேரத்தில், CPU தானே ஒரு குறிப்பிட்ட வரையறுக்கப்பட்ட வளத்தைக் கொண்டுள்ளது (உதாரணத்தில் இது 1000), அனைவருக்கும் இல்லாதிருக்கலாம் (அனைத்து குழுக்களின் தேவைகளின் கூட்டுத்தொகை 150+850+460=1460). இந்த வழக்கில் என்ன நடக்கும்?

கர்னல் வளங்களை விநியோகிக்கத் தொடங்குகிறது மற்றும் அதை "நியாயமாக" செய்கிறது, ஒவ்வொரு குழுவிற்கும் அதே அளவு வளங்களை வழங்குகிறது. ஆனால் முதல் வழக்கில், அவற்றில் தேவைக்கு அதிகமாக (333>150) உள்ளன, எனவே அதிகப்படியான (333-150=183) இருப்பு உள்ளது, இது மற்ற இரண்டு கொள்கலன்களுக்கு இடையில் சமமாக விநியோகிக்கப்படுகிறது:

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

இரண்டாவது கொள்கலனில் (php-fpm) வளங்கள் இல்லாத வழக்கைப் பார்ப்போம். அனைத்து கொள்கலன் வளங்களும் செயல்முறைகளுக்கு இடையில் சமமாக விநியோகிக்கப்படுகின்றன. இதன் விளைவாக, முதன்மை செயல்முறை நன்றாக வேலை செய்கிறது, ஆனால் அனைத்து தொழிலாளர்களும் மெதுவாக, அவர்களுக்கு தேவையானதில் பாதிக்கும் குறைவாகவே பெறுகிறார்கள்:

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

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

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

லினக்ஸ் கர்னல் மற்றும் CPU உடனான அதன் தொடர்புக்கு திரும்புவோம் - ஒட்டுமொத்த படம் பின்வருமாறு:

cgroup இரண்டு அமைப்புகளைக் கொண்டுள்ளது - அடிப்படையில் இவை இரண்டு எளிய "திருப்பங்கள்" ஆகும், அவை நீங்கள் தீர்மானிக்க அனுமதிக்கின்றன:

1. கொள்கலனுக்கான எடை (கோரிக்கைகள்) ஆகும் பங்குகள்;
2. கொள்கலன் பணிகளில் (வரம்புகள்) வேலை செய்வதற்கான மொத்த CPU நேரத்தின் சதவீதம் ஒதுக்கீடு.

CPU ஐ எவ்வாறு அளவிடுவது?

வெவ்வேறு வழிகள் உள்ளன:

1. என்ன கிளிகள், யாருக்கும் தெரியாது - நீங்கள் ஒவ்வொரு முறையும் பேச்சுவார்த்தை நடத்த வேண்டும்.
2. வட்டி தெளிவானது, ஆனால் தொடர்புடையது: 50 கோர்கள் மற்றும் 4 கோர்கள் கொண்ட சர்வரில் 20% முற்றிலும் வேறுபட்ட விஷயங்கள்.
3. நீங்கள் ஏற்கனவே குறிப்பிட்டுள்ளவற்றைப் பயன்படுத்தலாம் எடை, இது லினக்ஸுக்குத் தெரியும், ஆனால் அவையும் உறவினர்.
4. கணினி வளங்களை அளவிடுவதே மிகவும் போதுமான விருப்பம் வினாடிகள். அந்த. நிகழ் நேரத்தின் வினாடிகளுடன் தொடர்புடைய செயலி நேரத்தின் வினாடிகளில்: 1 உண்மையான வினாடிக்கு 1 வினாடி செயலி நேரம் வழங்கப்பட்டது - இது ஒரு முழு CPU கோர் ஆகும்.

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

3 CPU கோர்கள் கொண்ட சேவையகத்துடன் ஒரு எளிய உதாரணத்தைக் கருத்தில் கொள்வோம், அங்கு மூன்று காய்களுக்கு எடைகள் (500, 1000 மற்றும் 1500) வழங்கப்படும், அவை அவற்றிற்கு ஒதுக்கப்பட்ட கோர்களின் தொடர்புடைய பகுதிகளுக்கு எளிதாக மாற்றப்படும் (0,5, 1 மற்றும் 1,5).

நீங்கள் இரண்டாவது சேவையகத்தை எடுத்துக் கொண்டால், அங்கு இரண்டு மடங்கு கோர்கள் (6) இருக்கும் மற்றும் அதே காய்களை அங்கே வைத்தால், கோர்களின் விநியோகத்தை 2 (முறையே 1, 2 மற்றும் 3, முறையே) பெருக்குவதன் மூலம் எளிதாகக் கணக்கிடலாம். ஆனால் இந்த சேவையகத்தில் நான்காவது பாட் தோன்றும்போது ஒரு முக்கியமான தருணம் ஏற்படுகிறது, அதன் எடை, வசதிக்காக, 3000 ஆக இருக்கும். இது CPU வளங்களின் ஒரு பகுதியை (பாதி கோர்கள்) எடுத்துச் செல்கிறது, மீதமுள்ள காய்களுக்கு அவை மீண்டும் கணக்கிடப்படும் (பாதியாகக் குறைக்கப்பட்டது):

குபெர்னெட்ஸ் மற்றும் CPU ஆதாரங்கள்

குபெர்னெட்ஸில், CPU வளங்கள் பொதுவாக அளவிடப்படுகின்றன மில்லிட்ராக்ஸ், அதாவது 0,001 கோர்கள் அடிப்படை எடையாக எடுத்துக் கொள்ளப்படுகின்றன. (Linux/cgroups டெர்மினாலஜியில் உள்ள அதே விஷயம் CPU பங்கு என்று அழைக்கப்படுகிறது, இருப்பினும், இன்னும் துல்லியமாக, 1000 மில்லிகோர்கள் = 1024 CPU பங்குகள்.) அனைத்து காய்களின் எடையின் கூட்டுத்தொகைக்கு CPU ஆதாரங்கள் இருப்பதை விட, சேவையகத்தில் அதிக காய்களை வைக்காமல் இருப்பதை K8s உறுதி செய்கிறது.

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

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

ஒரு பாட்க்கு நீங்கள் கோரிக்கைகள் (CFS திட்டமிடுபவர்) மற்றும் வரம்புகள் இரண்டையும் குறிப்பிடலாம் (டிராஃபிக் லைட்டை நினைவில் கொள்கிறீர்களா?):

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

நினைவக

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

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

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

CPU இன் QoS வகுப்புகளுக்குத் திரும்பி, காய்களுக்கான நினைவக நுகர்வு முன்னுரிமைகளைத் தீர்மானிக்கும் oom_score_adj மதிப்புகளுடன் ஒப்புமையை வரைவோம்:

• ஒரு காய்க்கான மிகக் குறைந்த oom_score_adj மதிப்பு - -998 - அதாவது அத்தகைய காய் கடைசியாக கொல்லப்பட வேண்டும், இது உத்தரவாதம்.
• அதிகபட்சம் - 1000 - ஆகும் மிகச்சிறந்த முயற்சி, அத்தகைய காய்கள் முதலில் கொல்லப்படுகின்றன.
• மீதமுள்ள மதிப்புகளை கணக்கிட (வெடிக்கக்கூடிய) ஒரு சூத்திரம் உள்ளது, அதன் சாராம்சம், ஒரு நெற்று அதிக ஆதாரங்களைக் கோரினால், அது கொல்லப்படுவதற்கான வாய்ப்பு குறைவு.

இரண்டாவது "திருப்பம்" - வரம்பு_இன்_பைட்டுகள் - வரம்புகளுக்கு. இதன் மூலம், எல்லாம் எளிமையானது: வழங்கப்பட்ட நினைவகத்தின் அதிகபட்ச அளவை நாங்கள் ஒதுக்குகிறோம், இங்கே (CPU போலல்லாமல்) அதை எவ்வாறு அளவிடுவது (நினைவகம்) என்பதில் எந்த கேள்வியும் இல்லை.

மொத்தம்

குபெர்னெட்டஸில் உள்ள ஒவ்வொரு நெற்றும் கொடுக்கப்பட்டுள்ளது requests и limits - CPU மற்றும் நினைவகத்திற்கான இரண்டு அளவுருக்கள்:

1. கோரிக்கைகளின் அடிப்படையில், குபெர்னெட்ஸ் ஷெட்யூலர் வேலை செய்கிறது, இது சேவையகங்களிடையே காய்களை விநியோகிக்கிறது;
2. அனைத்து அளவுருக்களின் அடிப்படையில், பாட்டின் QoS வகுப்பு தீர்மானிக்கப்படுகிறது;
3. CPU கோரிக்கைகளின் அடிப்படையில் உறவினர் எடைகள் கணக்கிடப்படுகின்றன;
4. CFS திட்டமிடல் CPU கோரிக்கைகளின் அடிப்படையில் கட்டமைக்கப்படுகிறது;
5. OOM கொலையாளி நினைவக கோரிக்கைகளின் அடிப்படையில் கட்டமைக்கப்பட்டுள்ளது;
6. CPU வரம்புகளின் அடிப்படையில் "போக்குவரத்து விளக்கு" கட்டமைக்கப்படுகிறது;
7. நினைவக வரம்புகளின் அடிப்படையில், cgroupக்கு ஒரு வரம்பு கட்டமைக்கப்பட்டுள்ளது.

பொதுவாக, குபெர்னெட்ஸில் வள நிர்வாகத்தின் முக்கிய பகுதி எவ்வாறு நிகழ்கிறது என்பது பற்றிய அனைத்து கேள்விகளுக்கும் இந்த படம் பதிலளிக்கிறது.

ஆட்டோஸ்கேலிங்

K8s கிளஸ்டர்-ஆட்டோஸ்கேலர்

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

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

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

வரிசைப்படுத்தலைக் கொண்ட 3 சேவையகங்களின் தொகுப்பைக் கவனியுங்கள். இது 6 காய்களைக் கொண்டுள்ளது: இப்போது ஒவ்வொரு சேவையகத்திற்கும் 2 உள்ளன. சில காரணங்களால் நாங்கள் சேவையகங்களில் ஒன்றை முடக்க விரும்பினோம். இதைச் செய்ய, கட்டளையைப் பயன்படுத்துவோம் kubectl drain, எந்த:

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

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

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

MongoDB முடியும் அதற்கு ஒரு கோரம் தேவை என்பதால் இறக்கவும்: மூன்று நிறுவல்களின் கிளஸ்டருக்கு, குறைந்தது இரண்டு செயல்பட வேண்டும். எனினும், இந்த நடக்கவில்லை - நன்றி PodDisruptionBudget. இந்த அளவுரு வேலை செய்யும் காய்களின் குறைந்தபட்ச தேவையான எண்ணிக்கையை தீர்மானிக்கிறது. MongoDB காய்களில் ஒன்று இனி வேலை செய்யாது என்பதை அறிந்து, PodDisruptionBudget ஆனது MongoDBக்கு அமைக்கப்பட்டுள்ளது minAvailable: 2, குபெர்னெட்ஸ் உங்களை ஒரு பாட் நீக்க அனுமதிக்காது.

கீழே வரி: கிளஸ்டர் வெளியிடப்படும் போது காய்களின் இயக்கம் (உண்மையில், மறு உருவாக்கம்) சரியாக வேலை செய்ய, PodDisruptionBudget ஐ உள்ளமைக்க வேண்டியது அவசியம்.

கிடைமட்ட அளவிடுதல்

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

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

இங்கே முக்கிய கேள்விகள்: சரியாக என்ன அளவிட வேண்டும் и எப்படி விளக்குவது பெறப்பட்ட மதிப்புகள் (காய்களின் எண்ணிக்கையை மாற்றுவதற்கான முடிவை எடுப்பதற்கு). நீங்கள் நிறைய அளவிட முடியும்:

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

உள்ளன முறை பயன்படுத்தவும் (பயன்பாட்டு செறிவு மற்றும் பிழைகள்), இதன் பொருள் பின்வருமாறு. எடுத்துக்காட்டாக, php-fpm ஐ அளவிடுவது எந்த அடிப்படையில் அர்த்தமுள்ளதாக இருக்கிறது? தொழிலாளர்கள் வெளியேறுகிறார்கள் என்ற உண்மையின் அடிப்படையில், இது பயன்பாடு. தொழிலாளர்கள் முடிந்து புதிய இணைப்புகள் ஏற்றுக்கொள்ளப்படாவிட்டால், இது ஏற்கனவே உள்ளது செறிவூட்டல். இந்த இரண்டு அளவுருக்களும் அளவிடப்பட வேண்டும், மேலும் மதிப்புகளைப் பொறுத்து, அளவிடுதல் மேற்கொள்ளப்பட வேண்டும்.

அதற்கு பதிலாக, ஒரு முடிவுக்கும்

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

வீடியோக்கள் மற்றும் ஸ்லைடுகள்

நிகழ்ச்சியின் வீடியோ (44 நிமிடங்கள்):

அறிக்கையின் விளக்கக்காட்சி:

சோசலிஸ்ட் கட்சி

எங்கள் வலைப்பதிவில் Kubernetes பற்றிய பிற அறிக்கைகள்:

• «குபெர்னெட்டஸை விரிவுபடுத்துதல் மற்றும் நிரப்புதல்» (Andrey Polovov; ஏப்ரல் 8, 2019 செயிண்ட் ஹைலோடில்++);
• «தரவுத்தளங்கள் மற்றும் குபெர்னெட்ஸ்» (டிமிட்ரி ஸ்டோலியாரோவ்; நவம்பர் 8, 2018 ஹைலோட்++ இல்);
• «கண்காணிப்பு மற்றும் குபெர்னெட்ஸ்» (Dmitry Stolyarov; மே 28, 2018 RootConf இல்);
• «குபெர்னெட்ஸ் மற்றும் கிட்லேப் உடன் சிஐ/சிடி சிறந்த நடைமுறைகள்» (டிமிட்ரி ஸ்டோலியாரோவ்; நவம்பர் 7, 2017 ஹைலோட்++ இல்);
• «சிறிய திட்டங்களில் குபெர்னெட்டுடனான எங்கள் அனுபவம்» (Dmitry Stolyarov; ஜூன் 6, 2017 RootConf இல்).

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