CPU सीमा र Kubernetes मा आक्रामक थ्रॉटलिंग

नोट। अनुवाद।: ओमियोको यो आँखा खोल्ने इतिहास - एक युरोपेली ट्राभल एग्रीगेटर - पाठकहरूलाई आधारभूत सिद्धान्तबाट कुबर्नेट्स कन्फिगरेसनको आकर्षक व्यावहारिक जटिलताहरूमा लैजान्छ। त्यस्ता केसहरूसँग परिचितताले तपाईंको क्षितिज फराकिलो मात्र होइन, गैर-तुच्छ समस्याहरू रोक्न पनि मद्दत गर्दछ।

के तपाइँसँग कहिल्यै एउटा आवेदन ठाउँमा अड्किएको छ, स्वास्थ्य जाँचको जवाफ दिन रोकिएको छ, र किन पत्ता लगाउन सक्षम छैन? एउटा सम्भावित व्याख्या CPU स्रोत कोटा सीमासँग सम्बन्धित छ। यो हामी यस लेखमा कुरा गर्नेछौं।

TL; ड:
यदि तपाइँ CFS कोटा बगको साथ लिनक्स कर्नेलको संस्करण प्रयोग गर्दै हुनुहुन्छ भने हामी Kubernetes (वा Kubelet मा CFS कोटाहरू असक्षम गर्ने) मा CPU सीमाहरू असक्षम गर्न सिफारिस गर्छौं। कोर मा उपलब्ध छ गम्भीर र राम्रोसँग परिचित एउटा बग जसले अत्यधिक थ्रोटलिंग र ढिलाइमा पुर्‍याउँछ.

Omio मा सम्पूर्ण पूर्वाधार Kubernetes द्वारा व्यवस्थित गरिएको छ। हाम्रा सबै स्टेटफुल र स्टेटलेस वर्कलोडहरू विशेष रूपमा Kubernetes मा चल्छन् (हामी Google Kubernetes इन्जिन प्रयोग गर्छौं)। पछिल्लो छ महिनामा, हामीले अनियमित मन्दीहरू अवलोकन गर्न थाल्यौं। एप्लिकेसनहरू फ्रिज हुन्छन् वा स्वास्थ्य जाँचहरूमा प्रतिक्रिया दिन रोक्छन्, नेटवर्कमा जडान गुमाउँछन्, आदि। यो व्यवहारले हामीलाई लामो समयसम्म अचम्मित बनायो, र अन्ततः हामीले समस्यालाई गम्भीर रूपमा लिने निर्णय गर्‍यौं।

लेखको सारांश:

• कन्टेनर र Kubernetes बारेमा केहि शब्दहरू;
• कसरी CPU अनुरोधहरू र सीमाहरू लागू हुन्छन्;
• कसरी CPU सीमा बहु-कोर वातावरणमा काम गर्दछ;
• CPU थ्रोटलिंग कसरी ट्र्याक गर्ने;
• समस्या समाधान र nuances।

कन्टेनर र Kubernetes बारेमा केही शब्दहरू

Kubernetes अनिवार्य रूपमा पूर्वाधार संसारमा आधुनिक मानक हो। यसको मुख्य काम कन्टेनर अर्केस्ट्रेशन हो।

.Ы

विगतमा, हामीले जाभा JARs/WARs, Python Eggs, वा सर्भरहरूमा चलाउनको लागि एक्जिक्युटेबल जस्ता कलाकृतिहरू सिर्जना गर्नुपर्थ्यो। यद्यपि, तिनीहरूलाई कार्य गर्नको लागि, थप कार्यहरू गर्नुपर्थ्यो: रनटाइम वातावरण (जाभा/पाइथन) स्थापना गर्ने, आवश्यक फाइलहरू सही ठाउँहरूमा राख्ने, अपरेटिङ सिस्टमको विशिष्ट संस्करणसँग अनुकूलता सुनिश्चित गर्ने, आदि। अर्को शब्दमा, कन्फिगरेसन व्यवस्थापनमा सावधानीपूर्वक ध्यान दिनुपर्थ्यो (जुन प्रायः विकासकर्ताहरू र प्रणाली प्रशासकहरू बीचको विवादको स्रोत थियो)।

कन्टेनरहरूले सबै परिवर्तन गरे। अब कलाकृति कन्टेनर छवि हो। यसलाई एक प्रकारको विस्तारित कार्यान्वयनयोग्य फाइलको रूपमा प्रतिनिधित्व गर्न सकिन्छ जसमा कार्यक्रम मात्र होइन, तर पूर्ण कार्यान्वयन वातावरण (जाभा/पाइथन/...), साथै आवश्यक फाइलहरू/प्याकेजहरू, पूर्व-स्थापित र तयार छन्। दौडनु कन्टेनरहरू तैनाथ गर्न सकिन्छ र कुनै अतिरिक्त चरणहरू बिना विभिन्न सर्भरहरूमा चलाउन सकिन्छ।

थप रूपमा, कन्टेनरहरू आफ्नै स्यान्डबक्स वातावरणमा काम गर्छन्। तिनीहरूको आफ्नै भर्चुअल नेटवर्क एडाप्टर, सीमित पहुँचको साथ तिनीहरूको आफ्नै फाइल प्रणाली, प्रक्रियाहरूको आफ्नै पदानुक्रम, CPU र मेमोरीमा तिनीहरूको आफ्नै सीमितताहरू, इत्यादि छन्। यी सबै लिनक्स कर्नेल - नेमस्पेसको विशेष उपप्रणालीलाई धन्यवाद कार्यान्वयन गरिएको छ।

कुबर्नेट्स

पहिले नै भनिएझैं, Kubernetes एक कन्टेनर अर्केस्ट्रेटर हो। यसले यसरी काम गर्छ: तपाईंले यसलाई मेसिनहरूको पोखरी दिनुहोस्, र त्यसपछि भन्नुहोस्: "हे, कुबर्नेट्स, 2 प्रोसेसर र 3 GB मेमोरी प्रत्येकको साथ मेरो कन्टेनरको दसवटा उदाहरणहरू लन्च गरौं, र तिनीहरूलाई चलिरहनुहोस्!" कुबेरनेटले बाँकीको हेरचाह गर्नेछ। यसले नि:शुल्क क्षमता फेला पार्नेछ, कन्टेनरहरू लन्च गर्नेछ र आवश्यक भएमा तिनीहरूलाई पुन: सुरु गर्नेछ, संस्करणहरू परिवर्तन गर्दा अपडेट रोल आउट गर्नुहोस्, आदि। अनिवार्य रूपमा, Kubernetes ले तपाईलाई हार्डवेयर कम्पोनेन्ट सार्ने अनुमति दिन्छ र अनुप्रयोगहरू प्रयोग गर्न र चलाउनको लागि उपयुक्त प्रणालीहरूको विस्तृत विविधता बनाउँछ।

कुबेरनेटहरू आम मानिसको दृष्टिकोणबाट

Kubernetes मा अनुरोध र सीमाहरू के हुन्

ठीक छ, हामीले कन्टेनरहरू र कुबर्नेट्स कभर गरेका छौं। हामीलाई यो पनि थाहा छ कि धेरै कन्टेनरहरू एउटै मेसिनमा बस्न सक्छन्।

एक साम्प्रदायिक अपार्टमेन्ट संग एक समानता कोर्न सकिन्छ। एउटा विशाल परिसर (मेसिन/इकाइहरू) लिइन्छ र धेरै भाडामा लिनेहरू (कन्टेनरहरू) लाई भाडामा दिइन्छ। Kubernetes एक रियाल्टर रूपमा कार्य गर्दछ। प्रश्न उठ्छ, भाडामा लिनेहरूलाई कसरी एकअर्कासँग द्वन्द्वबाट जोगाउने? के हुन्छ यदि तिनीहरू मध्ये एकले, आधा दिनको लागि बाथरूम उधारो लिने निर्णय गर्छ भने?

यो जहाँ अनुरोध र सीमाहरू खेलमा आउँछन्। सि.पी. यु अनुरोध योजना उद्देश्यका लागि मात्र आवश्यक छ। यो कन्टेनरको "इच्छा सूची" जस्तै हो, र यो सबैभन्दा उपयुक्त नोड चयन गर्न प्रयोग गरिन्छ। एकै समयमा CPU सिमा भाडा सम्झौतासँग तुलना गर्न सकिन्छ - हामीले कन्टेनरको लागि एकाइ चयन गर्ने बित्तिकै, सकदिन स्थापित सीमा भन्दा बाहिर जानुहोस्। र समस्या यहीँबाट उत्पन्न हुन्छ...

Kubernetes मा कसरी अनुरोध र सीमाहरू लागू गरिन्छ

Kubernetes ले CPU सीमाहरू लागू गर्न कर्नेलमा निर्मित थ्रॉटलिङ मेकानिजम (घडी चक्र स्किपिङ) प्रयोग गर्दछ। यदि एप्लिकेसनले सीमा नाघ्यो भने, थ्रॉटलिंग सक्षम पारिएको छ (अर्थात् यसले कम 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, र तिनीहरू, बारीमा, तिनीहरूका सन्तानहरू, इत्यादिसँग पनि त्यस्तै गर्छन्। सामान्य कुबर्नेट्स नोडमा, मूल cgroup मा तीन बच्चाहरू छन्: system.slice, user.slice и kubepods। पहिलो दुई उपसमूह K8s बाहिर महत्वपूर्ण प्रणाली लोड र प्रयोगकर्ता कार्यक्रमहरू बीच स्रोतहरू वितरण गर्न प्रयोग गरिन्छ। पछिल्लो एक - kubepods - पोडहरू बीच स्रोतहरू वितरण गर्न Kubernetes द्वारा सिर्जना गरिएको।

माथिको रेखाचित्रले पहिलो र दोस्रो उपसमूह प्रत्येक प्राप्त गरेको देखाउँछ 1024 सेयरहरू, kuberpod उपसमूह आवंटित संग 4096 शेयरहरू यो कसरी सम्भव छ: सबै पछि, रूट समूह मात्र पहुँच छ 4096 शेयरहरू, र तिनका सन्तानहरूको सेयरको योगले यो संख्यालाई उल्लेखनीय रूपमा बढाउँछ (6144)? बिन्दु यो हो कि मानले तार्किक अर्थ बनाउँछ, त्यसैले लिनक्स अनुसूचक (CFS) ले यसलाई समानुपातिक रूपमा CPU स्रोतहरू आवंटित गर्न प्रयोग गर्दछ। हाम्रो मामला मा, पहिलो दुई समूह प्राप्त 680 वास्तविक शेयर (४०९६ को १६.६%), र कुबेपोडले बाँकी प्राप्त गर्दछ 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 मा यो मान परिवर्तन गर्ने विकल्प छ, तर यो अहिलेको लागि अल्फामा मात्र उपलब्ध छ। अनुसूचकले प्रयोग गरिएको कोटाहरू पुन: सुरु गर्न epoch प्रयोग गर्दछ। दोस्रो फाइल cfs_quota_us, प्रत्येक युगमा उपलब्ध समय (कोटा) निर्दिष्ट गर्दछ। ध्यान दिनुहोस् कि यो माइक्रोसेकेन्डमा पनि निर्दिष्ट गरिएको छ। कोटा युगको लम्बाइ भन्दा बढी हुन सक्छ; अर्को शब्दमा, यो 100 ms भन्दा बढी हुन सक्छ।

16-कोर मेसिनहरूमा दुई परिदृश्यहरू हेरौं (ओमियोमा हामीसँग भएको सबैभन्दा सामान्य प्रकारको कम्प्युटर):

परिदृश्य 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 औं प्रतिशत

सञ्चालन लागत

बिताएका उदाहरण घण्टाको संख्या

पकड के हो?

लेखको सुरुमा भनेझैं:

एक साम्प्रदायिक अपार्टमेन्ट संग एक समानता कोर्न सकिन्छ ... Kubernetes एक रियाल्टर को रूप मा काम गर्दछ। तर भाडामा लिनेहरूलाई कसरी एकअर्कासँग द्वन्द्वबाट जोगाउने? के हुन्छ यदि तिनीहरू मध्ये एकले, आधा दिनको लागि बाथरूम उधारो लिने निर्णय गर्छ भने?

यहाँ क्याच छ। एउटा लापरवाह कन्टेनरले मेसिनमा उपलब्ध सबै CPU स्रोतहरू खान सक्छ। यदि तपाइँसँग स्मार्ट एप्लिकेसन स्ट्याक छ (उदाहरणका लागि, JVM, Go, Node VM ठीकसँग कन्फिगर गरिएको छ), तब यो कुनै समस्या होइन: तपाइँ लामो समयसम्म यस्तो अवस्थामा काम गर्न सक्नुहुन्छ। तर यदि एप्लिकेसनहरू खराब रूपमा अप्टिमाइज गरिएका छन् वा पूर्ण रूपमा अनुकूलित छैनन् (FROM java:latest) स्थिति नियन्त्रण बाहिर जान सक्छ। Omio मा हामीसँग प्रमुख भाषा स्ट्याकको लागि पर्याप्त पूर्वनिर्धारित सेटिङहरूसँग स्वचालित आधार डकरफाइलहरू छन्, त्यसैले यो समस्या अवस्थित थिएन।

हामी मेट्रिक्स अनुगमन गर्न सिफारिस गर्छौं प्रयोग (प्रयोग, संतृप्ति र त्रुटिहरू), API ढिलाइ र त्रुटि दरहरू। सुनिश्चित गर्नुहोस् कि परिणामहरू अपेक्षाहरू पूरा गर्छन्।

सन्दर्भ

यो हाम्रो कथा हो। निम्न सामग्रीहरूले के भइरहेको थियो भनेर बुझ्न मद्दत गर्‍यो:

• kernel.org → CFS शेड्युलर;
• kernel.org → CFS ब्यान्डविथ नियन्त्रण;
• लिनक्स कन्टेनर अनुसूची बुझ्दै;
• लिनक्स कन्टेनरहरू, भाग I: लिनक्स नियन्त्रण समूह र प्रक्रिया अलगावको बारेमा तपाईलाई जान्न आवश्यक सबै कुरा;
• Kubernetes असफलता कथाहरू - "cpu थ्रॉटलिंग" खोज्नुहोस्।

Kubernetes बग रिपोर्टहरू:

• #51135: ग्यारेन्टी पोडहरूको लागि CPU सीमाहरू सेट नगर्नुहोस्;
• #67577: CFS कोटाले अनावश्यक थ्रोटलिंग निम्त्याउन सक्छ;
• अत्यधिक आक्रामक CFS.

के तपाईंले आफ्नो अभ्यासमा यस्तै समस्याहरू सामना गर्नुभएको छ वा कन्टेनराइज्ड उत्पादन वातावरणमा थ्रोटलिंगसँग सम्बन्धित अनुभव छ? टिप्पणीहरूमा आफ्नो कथा साझा गर्नुहोस्!

अनुवादकबाट PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «Kubernetes मा स्वत: स्केलिंग र संसाधन व्यवस्थापन (अवलोकन र भिडियो रिपोर्ट)»;
• «कसरी CPU प्रबन्धक Kubernetes मा काम गर्दछ»;
• «कुबेरनेटमा के हुन्छ जब तपाइँ कुबेक्टल रन चलाउनुहुन्छ? भाग 2"।

स्रोत: www.habr.com