குபெர்னெட்ஸ்: CPU வரம்புகளை அகற்றுவதன் மூலம் உங்கள் சேவைகளை விரைவுபடுத்துங்கள்

2016 இல் நாங்கள் Buffer இல் திரும்பினோம் குபர்னெட்டஸுக்கு மாறினார், மற்றும் இப்போது சுமார் 60 முனைகள் (AWS இல்) மற்றும் 1500 கொள்கலன்கள் எங்கள் k8s கிளஸ்டரால் நிர்வகிக்கப்படுகின்றன உதை. இருப்பினும், சோதனை மற்றும் பிழை மூலம் மைக்ரோ சர்வீஸுக்கு நகர்ந்தோம், மேலும் பல வருடங்கள் k8s உடன் பணிபுரிந்த பிறகும் நாங்கள் இன்னும் புதிய சிக்கல்களை எதிர்கொள்கிறோம். இந்த இடுகையில் நாம் பேசுவோம் செயலி வரம்புகள்: அவை நல்ல நடைமுறை என்று நாங்கள் ஏன் நினைத்தோம், ஏன் அவை அவ்வளவு சிறப்பாக இல்லை.

செயலி வரம்புகள் மற்றும் த்ரோட்லிங்

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

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

செயலி வரம்புகளை அமைக்கவில்லை என்றால் என்ன நடக்கும்?

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

த்ரோட்லிங் மற்றும் பதிலளிப்பு பிரச்சனையின் வெளிப்பாடு

கொள்கலன் கண்காணிப்புக்கான முக்கிய மெட்ரிக் trottling, உங்கள் கொள்கலன் எத்தனை முறை த்ரோட்டில் செய்யப்பட்டது என்பதைக் காட்டுகிறது. செயலி சுமை அதிகமாக உள்ளதா இல்லையா என்பதைப் பொருட்படுத்தாமல், சில கொள்கலன்களில் த்ரோட்லிங் இருப்பதை ஆர்வத்துடன் கவனித்தோம். உதாரணமாக, எங்கள் முக்கிய APIகளில் ஒன்றைப் பார்ப்போம்:

நீங்கள் கீழே பார்க்க முடியும் என, நாங்கள் வரம்பை அமைத்துள்ளோம் 800m (0.8 அல்லது 80% கோர்), மற்றும் உச்ச மதிப்புகள் சிறந்த அடையும் 200m (20% கோர்). சேவையைத் தொடங்குவதற்கு முன்பு, எங்களிடம் இன்னும் ஏராளமான செயலி சக்தி உள்ளது என்று தோன்றுகிறது, இருப்பினும் ...

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

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

குறைந்த CPU சுமையில் த்ரோட்டிங்கை ஏன் பார்க்கிறோம்? சுருக்கமான பதிப்பு: "லினக்ஸ் கர்னலில் ஒரு பிழை உள்ளது, இது குறிப்பிட்ட செயலி வரம்புகளைக் கொண்ட கொள்கலன்களின் தேவையற்ற த்ரோட்டில்லை ஏற்படுத்துகிறது." சிக்கலின் தன்மையில் நீங்கள் ஆர்வமாக இருந்தால், விளக்கக்காட்சியைப் படிக்கலாம் (видео и உரை விருப்பங்கள்) டேவ் சிலுக் மூலம்.

CPU கட்டுப்பாடுகளை நீக்குதல் (தீவிர எச்சரிக்கையுடன்)

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

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

ஒரு அழுத்தமான பிரச்சினையில் வணிக கடிதங்கள்.

கட்டுப்பாடுகள் நீக்கப்படும் போது உங்கள் முனைகளை எவ்வாறு பாதுகாப்பது?

"கட்டுப்படுத்தப்படாத" சேவைகளை தனிமைப்படுத்துதல்:

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

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

சரியான செயலி மற்றும் நினைவக கோரிக்கையை ஒதுக்குதல்:

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

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

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

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

Результаты

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

எங்கள் முகப்புப் பக்கத்தில் சிறந்த முடிவுகளை அடைந்துள்ளோம் (buffer.com), அங்கு சேவை துரிதப்படுத்தப்பட்டது இருபத்தி இரண்டு முறை!

லினக்ஸ் கர்னல் பிழை சரி செய்யப்பட்டதா?

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

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

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

• டெபியன்: விநியோகத்தின் சமீபத்திய பதிப்பில் ஒருங்கிணைக்கப்பட்ட சரிசெய்தல், பஸ்டர், மற்றும் மிகவும் புதியதாக தெரிகிறது (ஆகஸ்ட் 2020) சில முந்தைய பதிப்புகளும் சரி செய்யப்படலாம்.
• உபுண்டு: சமீபத்திய பதிப்பில் ஒருங்கிணைக்கப்பட்டது உபுண்டு ஃபோகல் ஃபோசா 20.04
• EKS இன்னும் சரி செய்யப்பட்டுள்ளது டிசம்பர் 2019 இல். உங்கள் பதிப்பு இதை விட குறைவாக இருந்தால், நீங்கள் AMI ஐ புதுப்பிக்க வேண்டும்.
• கோப்ஸ்: ஜூன் 2020 முதல் у kops 1.18+ முக்கிய ஹோஸ்ட் படம் உபுண்டு 20.04 ஆக இருக்கும். உங்கள் காப்ஸின் பதிப்பு பழையதாக இருந்தால், அதை சரிசெய்ய நீங்கள் காத்திருக்க வேண்டியிருக்கும். நாமே இப்போது காத்திருக்கிறோம்.
• GKE (Google கிளவுட்): ஒருங்கிணைக்கப்பட்டது சரி ஜனவரி 2020 இல், இருப்பினும் த்ரோட்டிங்கில் சிக்கல்கள் உள்ளன இன்னும் கவனிக்கப்படுகின்றன.

த்ரோட்லிங் சிக்கலை சரிசெய்தால் என்ன செய்வது?

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

முடிவுக்கு

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

இந்த இடுகை உங்கள் கொள்கலன் அமைப்புகளின் செயல்திறனை மேம்படுத்த உதவும் என்று நம்புகிறேன்.

சோசலிஸ்ட் கட்சி இது ஆசிரியர் வாசகர்கள் மற்றும் வர்ணனையாளர்களுடன் ஒத்துப்போகிறார் (ஆங்கிலத்தில்).


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