CPU मर्यादा आणि Kubernetes मध्ये आक्रमक थ्रॉटलिंग

नोंद. अनुवाद: ओमिओचा हा डोळा उघडणारा इतिहास—एक युरोपियन ट्रॅव्हल एग्रीगेटर—वाचकांना मूलभूत सिद्धांतापासून कुबर्नेट्स कॉन्फिगरेशनच्या आकर्षक व्यावहारिक गुंतागुंतींपर्यंत घेऊन जातो. अशा प्रकरणांची ओळख केवळ तुमची क्षितिजेच विस्तृत करत नाही तर क्षुल्लक समस्या टाळण्यास देखील मदत करते.

तुमच्याकडे कधी अर्ज अडकला आहे, आरोग्य तपासण्यांना प्रतिसाद देणे थांबले आहे आणि का ते समजू शकले नाही? एक संभाव्य स्पष्टीकरण CPU संसाधन कोटा मर्यादांशी संबंधित आहे. या लेखात आपण याबद्दल बोलणार आहोत.

TL; डॉ:
आपण CFS कोटा बगसह लिनक्स कर्नलची आवृत्ती वापरत असल्यास Kubernetes (किंवा Kubelet मध्ये CFS कोटा अक्षम करणे) मध्ये CPU मर्यादा अक्षम करण्याची आम्ही जोरदार शिफारस करतो. गाभ्यामध्ये उपलब्ध आहे गंभीर आणि सुप्रसिद्ध एक बग ज्यामुळे जास्त थ्रॉटलिंग आणि विलंब होतो.

Omio मध्ये संपूर्ण पायाभूत सुविधा Kubernetes द्वारे व्यवस्थापित केल्या जातात. आमचे सर्व स्टेटफुल आणि स्टेटलेस वर्कलोड केवळ कुबर्नेट्सवर चालतात (आम्ही Google Kubernetes इंजिन वापरतो). गेल्या सहा महिन्यांत, आम्ही यादृच्छिक मंदीचे निरीक्षण करू लागलो. अनुप्रयोग गोठवतात किंवा आरोग्य तपासणीस प्रतिसाद देणे थांबवतात, नेटवर्कशी कनेक्शन गमावतात इ. या वर्तनाने आम्हाला बराच काळ गोंधळात टाकले आणि शेवटी आम्ही समस्या गंभीरपणे घेण्याचे ठरवले.

लेखाचा सारांश:

• कंटेनर आणि कुबर्नेट्स बद्दल काही शब्द;
• CPU विनंत्या आणि मर्यादा कशा लागू केल्या जातात;
• मल्टी-कोर वातावरणात CPU मर्यादा कशी कार्य करते;
• CPU थ्रॉटलिंगचा मागोवा कसा घ्यावा;
• समस्येचे निराकरण आणि बारकावे.

कंटेनर आणि कुबर्नेट्स बद्दल काही शब्द

कुबर्नेट्स हे मूलभूतपणे पायाभूत सुविधांच्या जगात आधुनिक मानक आहे. कंटेनर ऑर्केस्ट्रेशन हे त्याचे मुख्य कार्य आहे.

कंटेनर

पूर्वी, आम्हाला सर्व्हरवर चालण्यासाठी Java JARs/WARs, Python Eggs किंवा executables सारख्या कलाकृती तयार कराव्या लागल्या. तथापि, त्यांना कार्य करण्यासाठी, अतिरिक्त काम करावे लागेल: रनटाइम वातावरण (जावा/पायथन) स्थापित करणे, आवश्यक फाइल्स योग्य ठिकाणी ठेवणे, ऑपरेटिंग सिस्टमच्या विशिष्ट आवृत्तीसह सुसंगतता सुनिश्चित करणे इ. दुसऱ्या शब्दांत, कॉन्फिगरेशन व्यवस्थापनाकडे (जे अनेकदा विकासक आणि सिस्टम प्रशासक यांच्यातील वादाचे कारण होते) काळजीपूर्वक लक्ष देणे आवश्यक होते.

कंटेनरने सर्वकाही बदलले. आता कलाकृती एक कंटेनर प्रतिमा आहे. हे एक प्रकारची विस्तारित एक्झिक्युटेबल फाइल म्हणून प्रस्तुत केले जाऊ शकते ज्यामध्ये केवळ प्रोग्रामच नाही तर पूर्ण अंमलबजावणी वातावरण (जावा/पायथन/...), तसेच आवश्यक फाइल्स/पॅकेज, पूर्व-स्थापित आणि तयार आहेत. धावणे कंटेनर तैनात केले जाऊ शकतात आणि कोणत्याही अतिरिक्त चरणांशिवाय वेगवेगळ्या सर्व्हरवर चालवले जाऊ शकतात.

याव्यतिरिक्त, कंटेनर त्यांच्या स्वत: च्या सँडबॉक्स वातावरणात कार्य करतात. त्यांच्याकडे स्वतःचे व्हर्च्युअल नेटवर्क ॲडॉप्टर, मर्यादित प्रवेश असलेली त्यांची स्वतःची फाइल सिस्टम, प्रक्रियांची स्वतःची पदानुक्रम, CPU आणि मेमरीवरील त्यांच्या स्वतःच्या मर्यादा, इ. हे सर्व Linux कर्नलच्या विशेष उपप्रणालीमुळे लागू केले जाते - नेमस्पेसेस.

कुबेरनेट्स

आधी सांगितल्याप्रमाणे, कुबर्नेट्स हा कंटेनर ऑर्केस्ट्रेटर आहे. हे असे कार्य करते: तुम्ही याला मशिन्सचा एक पूल द्या आणि नंतर म्हणा: “अरे, कुबर्नेट्स, चला माझ्या कंटेनरची दहा उदाहरणे 2 प्रोसेसर आणि प्रत्येकी 3 GB मेमरीसह लाँच करू आणि त्यांना चालू ठेवू!” बाकीची काळजी कुबर्नेट्स घेतील. हे विनामूल्य क्षमता शोधेल, कंटेनर लाँच करेल आणि आवश्यक असल्यास ते रीस्टार्ट करेल, आवृत्ती बदलताना अपडेट रोल आउट करेल इ. मूलत:, Kubernetes तुम्हाला हार्डवेअर घटक काढून टाकण्याची परवानगी देतो आणि उपयोजित आणि चालविण्याकरिता विविध प्रकारच्या प्रणाली योग्य बनवतो.

सामान्य माणसाच्या दृष्टिकोनातून कुबर्नेट्स

Kubernetes मध्ये विनंत्या आणि मर्यादा काय आहेत

ठीक आहे, आम्ही कंटेनर आणि कुबर्नेट्स कव्हर केले आहेत. आम्हाला हे देखील माहित आहे की एकाच मशीनवर अनेक कंटेनर राहू शकतात.

सांप्रदायिक अपार्टमेंटसह एक समानता काढली जाऊ शकते. एक प्रशस्त परिसर (मशीन/युनिट्स) घेतला जातो आणि अनेक भाडेकरूंना (कंटेनर) भाड्याने दिला जातो. कुबर्नेट्स रिअल्टर म्हणून काम करतात. प्रश्न उद्भवतो, भाडेकरूंना एकमेकांशी भांडणांपासून कसे ठेवायचे? जर त्यांच्यापैकी एकाने अर्ध्या दिवसासाठी स्नानगृह उधार घेण्याचे ठरवले तर?

इथेच विनंत्या आणि मर्यादा येतात. सीपीयू विनंती केवळ नियोजन हेतूंसाठी आवश्यक आहे. हे कंटेनरच्या "इच्छा सूची" सारखे आहे आणि ते सर्वात योग्य नोड निवडण्यासाठी वापरले जाते. त्याच वेळी CPU मर्यादा भाडे कराराशी तुलना केली जाऊ शकते - आम्ही कंटेनरसाठी एक युनिट निवडताच, द करू शकत नाही स्थापित मर्यादेपलीकडे जा. आणि इथेच समस्या निर्माण होते...

Kubernetes मध्ये विनंत्या आणि मर्यादा कशा लागू केल्या जातात

CPU मर्यादा लागू करण्यासाठी Kubernetes कर्नलमध्ये तयार केलेली थ्रॉटलिंग यंत्रणा (घड्याळाची चक्रे वगळणे) वापरते. जर एखाद्या अनुप्रयोगाने मर्यादा ओलांडली तर, थ्रॉटलिंग सक्षम केले जाते (म्हणजे त्याला कमी CPU चक्र प्राप्त होतात). स्मरणशक्तीसाठी विनंत्या आणि मर्यादा वेगळ्या पद्धतीने आयोजित केल्या आहेत, त्यामुळे ते शोधणे सोपे आहे. हे करण्यासाठी, पॉडची शेवटची रीस्टार्ट स्थिती तपासा: ती “OOMKilled” आहे की नाही. CPU थ्रॉटलिंग इतके सोपे नाही, कारण K8s फक्त वापरानुसार मेट्रिक्स उपलब्ध करते, cgroups द्वारे नाही.

CPU विनंती

CPU विनंती कशी लागू केली जाते

साधेपणासाठी, उदाहरण म्हणून 4-कोर CPU सह मशीन वापरून प्रक्रिया पाहू.

संसाधनांचे (मेमरी आणि प्रोसेसर) वाटप नियंत्रित करण्यासाठी K8s नियंत्रण गट यंत्रणा (cgroups) वापरते. त्यासाठी एक श्रेणीबद्ध मॉडेल उपलब्ध आहे: मुलाला पालक गटाच्या मर्यादा वारशाने मिळतात. वितरण तपशील आभासी फाइल प्रणालीमध्ये संग्रहित केले जातात (/sys/fs/cgroup). प्रोसेसरच्या बाबतीत हे आहे /sys/fs/cgroup/cpu,cpuacct/*.

K8s फाइल वापरते cpu.share प्रोसेसर संसाधने वाटप करण्यासाठी. आमच्या बाबतीत, रूट cgroup ला CPU संसाधनांचे 4096 शेअर्स मिळतात - उपलब्ध प्रोसेसर पॉवरच्या 100% (1 कोर = 1024; हे एक निश्चित मूल्य आहे). मूळ गट नोंदणीकृत वंशजांच्या शेअर्सवर अवलंबून संसाधने प्रमाणानुसार वितरित करतो cpu.share, आणि ते, यामधून, त्यांच्या वंशजांसह तेच करतात, इ. सामान्य कुबर्नेट्स नोडवर, रूट सीग्रुपला तीन मुले आहेत: system.slice, user.slice и kubepods. पहिले दोन उपसमूह K8s च्या बाहेरील क्रिटिकल सिस्टम लोड आणि वापरकर्ता प्रोग्राम्स दरम्यान संसाधने वितरीत करण्यासाठी वापरले जातात. शेवटचा - kubepods - पॉड्समध्ये संसाधने वितरीत करण्यासाठी कुबर्नेट्सने तयार केले.

वरील आकृती दर्शविते की प्रथम आणि द्वितीय उपसमूहांना प्रत्येकी प्राप्त झाले 1024 वाटप केलेल्या kuberpod उपसमूहासह समभाग 4096 शेअर्स हे कसे शक्य आहे: सर्व केल्यानंतर, रूट गटाला फक्त प्रवेश आहे 4096 शेअर्स आणि तिच्या वंशजांच्या शेअर्सची बेरीज ही संख्या लक्षणीयरीत्या ओलांडते (6144)? मुद्दा असा आहे की मूल्याला तार्किक अर्थ प्राप्त होतो, म्हणून लिनक्स शेड्युलर (CFS) ते CPU संसाधनांचे प्रमाणबद्ध वाटप करण्यासाठी वापरतो. आमच्या बाबतीत, पहिले दोन गट प्राप्त करतात 680 वास्तविक शेअर्स (16,6 पैकी 4096%), आणि कुबेपॉड उर्वरित प्राप्त करतात 2736 शेअर्स डाउनटाइमच्या बाबतीत, पहिले दोन गट वाटप केलेली संसाधने वापरणार नाहीत.

सुदैवाने, शेड्युलरकडे न वापरलेली CPU संसाधने वाया जाऊ नयेत यासाठी एक यंत्रणा आहे. हे "निष्क्रिय" क्षमता जागतिक पूलमध्ये हस्तांतरित करते, ज्यामधून ते अतिरिक्त प्रोसेसर पॉवर आवश्यक असलेल्या गटांमध्ये वितरित केले जाते (गोलाकार नुकसान टाळण्यासाठी बॅचेसमध्ये हस्तांतरण होते). वंशजांच्या सर्व वंशजांना समान पद्धत लागू केली जाते.

ही यंत्रणा प्रोसेसर पॉवरचे योग्य वितरण सुनिश्चित करते आणि कोणीही इतरांकडून संसाधने "चोरी" करत नाही याची खात्री करते.

CPU मर्यादा

K8 मधील मर्यादा आणि विनंत्यांचे कॉन्फिगरेशन समान दिसत असूनही, त्यांची अंमलबजावणी पूर्णपणे भिन्न आहे: सर्वात दिशाभूल करणारे आणि सर्वात कमी दस्तऐवजीकरण केलेला भाग.

K8s व्यस्त आहे CFS कोटा यंत्रणा मर्यादा लागू करण्यासाठी. त्यांच्या सेटिंग्ज फायलींमध्ये निर्दिष्ट केल्या आहेत cfs_period_us и cfs_quota_us cgroup निर्देशिकेत (फाइल देखील तेथे स्थित आहे cpu.share).

विपरीत cpu.share, कोटा आधारित आहे कालावधी, आणि उपलब्ध प्रोसेसर पॉवरवर नाही. cfs_period_us कालावधी (युग) निर्दिष्ट करते - तो नेहमी 100000 μs (100 ms) असतो. K8s मध्ये हे मूल्य बदलण्याचा पर्याय आहे, परंतु आत्ता ते केवळ अल्फामध्ये उपलब्ध आहे. शेड्युलर वापरलेले कोटा रीस्टार्ट करण्यासाठी युगाचा वापर करतो. दुसरी फाईल cfs_quota_us, प्रत्येक युगामध्ये उपलब्ध वेळ (कोटा) निर्दिष्ट करते. लक्षात घ्या की ते मायक्रोसेकंदमध्ये देखील निर्दिष्ट केले आहे. कोटा युगाच्या लांबीपेक्षा जास्त असू शकतो; दुसऱ्या शब्दांत, ते 100 ms पेक्षा जास्त असू शकते.

चला 16-कोर मशीन्सवर दोन परिस्थिती पाहू (आपल्याकडे Omio मधील संगणकाचा सर्वात सामान्य प्रकार):

परिस्थिती 1: 2 थ्रेड आणि 200 ms मर्यादा. थ्रॉटलिंग नाही

परिस्थिती 2: 10 थ्रेड आणि 200 ms मर्यादा. थ्रॉटलिंग 20 ms नंतर सुरू होते, प्रोसेसर संसाधनांमध्ये प्रवेश आणखी 80 ms नंतर पुन्हा सुरू केला जातो

समजा तुम्ही CPU मर्यादा सेट केली आहे 2 कर्नल; Kubernetes हे मूल्य 200 ms मध्ये भाषांतरित करेल. याचा अर्थ कंटेनर थ्रॉटलिंगशिवाय जास्तीत जास्त 200ms CPU वेळ वापरू शकतो.

आणि इथेच मजा सुरू होते. वर नमूद केल्याप्रमाणे, उपलब्ध कोटा 200 ms आहे. जर तुम्ही समांतर काम करत असाल दहा 12-कोर मशीनवरील थ्रेड्स (परिदृश्य 2 साठी उदाहरण पहा), इतर सर्व पॉड्स निष्क्रिय असताना, कोटा फक्त 20 ms मध्ये संपेल (10 * 20 ms = 200 ms पासून), आणि या पॉडचे सर्व थ्रेड लटकतील » (गळ घालणे) पुढील 80 ms साठी आधीच नमूद केले आहे शेड्यूलर बग, ज्यामुळे जास्त थ्रॉटलिंग होते आणि कंटेनर सध्याचा कोटा देखील पूर्ण करू शकत नाही.

शेंगांमध्ये थ्रॉटलिंगचे मूल्यांकन कसे करावे?

फक्त पॉडवर लॉगिन करा आणि कार्यान्वित करा cat /sys/fs/cgroup/cpu/cpu.stat.

• nr_periods - शेड्यूलर कालावधीची एकूण संख्या;
• nr_throttled — रचना मध्ये थ्रोटल कालावधीची संख्या nr_periods;
• throttled_time — नॅनोसेकंदांमध्ये एकत्रित थ्रोटल वेळ.

खरोखर काय चालले आहे?

परिणामी, आम्हाला सर्व अनुप्रयोगांमध्ये उच्च थ्रॉटलिंग मिळते. कधी कधी तो आत असतो दीड वेळा गणनापेक्षा मजबूत!

यामुळे विविध त्रुटी उद्भवतात - तयारी तपासणी अयशस्वी होणे, कंटेनर फ्रीझ होणे, नेटवर्क कनेक्शन खंडित होणे, सेवा कॉलमध्ये कालबाह्य होणे. याचा परिणाम शेवटी वाढलेला विलंब आणि उच्च त्रुटी दरांमध्ये होतो.

निर्णय आणि परिणाम

येथे सर्व काही सोपे आहे. आम्ही CPU मर्यादा सोडून दिली आणि क्लस्टर्समध्ये OS कर्नल नवीनतम आवृत्तीमध्ये अद्यतनित करणे सुरू केले, ज्यामध्ये दोष निश्चित केला गेला. आमच्या सेवांमधील त्रुटींची संख्या (HTTP 5xx) ताबडतोब लक्षणीयरीत्या कमी झाली:

HTTP 5xx त्रुटी

एका गंभीर सेवेसाठी HTTP 5xx त्रुटी

प्रतिसाद वेळ p95

गंभीर सेवा विनंती विलंबता, 95 व्या टक्केवारी

ऑपरेटिंग खर्च

खर्च केलेल्या उदाहरणांच्या तासांची संख्या

पकड म्हणजे काय?

लेखाच्या सुरुवातीला म्हटल्याप्रमाणे:

सांप्रदायिक अपार्टमेंटसह एक साधर्म्य रेखाटले जाऊ शकते... कुबर्नेट्स रिअल्टर म्हणून काम करतात. पण भाडेकरूंना एकमेकांशी भांडण कसे ठेवायचे? जर त्यांच्यापैकी एकाने अर्ध्या दिवसासाठी स्नानगृह उधार घेण्याचे ठरवले तर?

येथे झेल आहे. एक निष्काळजी कंटेनर मशीनवर उपलब्ध सर्व CPU संसाधने खाऊ शकतो. तुमच्याकडे स्मार्ट ॲप्लिकेशन स्टॅक असल्यास (उदाहरणार्थ, JVM, Go, Node VM योग्यरित्या कॉन्फिगर केलेले), तर ही समस्या नाही: तुम्ही अशा परिस्थितीत दीर्घकाळ काम करू शकता. परंतु जर अनुप्रयोग खराबपणे ऑप्टिमाइझ केलेले असतील किंवा अजिबात ऑप्टिमाइझ केलेले नाहीत (FROM java:latest) परिस्थिती नियंत्रणाबाहेर जाऊ शकते. ओमिओमध्ये आमच्याकडे प्रमुख भाषा स्टॅकसाठी पुरेशा डीफॉल्ट सेटिंग्जसह स्वयंचलित बेस डॉकरफाइल्स आहेत, त्यामुळे ही समस्या अस्तित्वात नव्हती.

आम्ही मेट्रिक्सचे निरीक्षण करण्याची शिफारस करतो वापरा (वापर, संपृक्तता आणि त्रुटी), API विलंब आणि त्रुटी दर. परिणाम अपेक्षा पूर्ण करतात याची खात्री करा.

संदर्भ

ही आमची कहाणी आहे. काय घडत आहे हे समजून घेण्यासाठी खालील सामग्रीने खूप मदत केली:

• kernel.org → CFS शेड्युलर;
• kernel.org → CFS बँडविड्थ नियंत्रण;
• लिनक्स कंटेनर शेड्यूलिंग समजून घेणे;
• लिनक्स कंटेनर्स, भाग I बद्दल आपल्याला माहित असणे आवश्यक असलेली प्रत्येक गोष्ट: लिनक्स नियंत्रण गट आणि प्रक्रिया अलगाव;
• कुबर्नेट्स अयशस्वी कथा - "cpu थ्रॉटलिंग" शोधा.

Kubernetes बग अहवाल:

• #51135: गॅरंटीड पॉड्ससाठी CPU मर्यादा सेट करणे टाळा;
• #67577: CFS कोट्यामुळे अनावश्यक थ्रॉटलिंग होऊ शकते;
• अति आक्रमक CFS.

तुम्हाला तुमच्या सरावात अशाच समस्या आल्या आहेत किंवा तुम्हाला कंटेनराइज्ड उत्पादन वातावरणात थ्रॉटलिंगशी संबंधित अनुभव आहे का? टिप्पण्यांमध्ये आपली कथा सामायिक करा!

अनुवादकाकडून पुनश्च

आमच्या ब्लॉगवर देखील वाचा:

• «कुबर्नेट्समध्ये ऑटोस्केलिंग आणि संसाधन व्यवस्थापन (विहंगावलोकन आणि व्हिडिओ अहवाल)";
• «कुबर्नेट्समध्ये CPU व्यवस्थापक कसे कार्य करते";
• «तुम्ही kubectl रन चालवता तेव्हा Kubernetes मध्ये काय होते? भाग 2».

स्त्रोत: www.habr.com