Kubernetes मा स्वत: स्केलिंग र संसाधन व्यवस्थापन (अवलोकन र भिडियो रिपोर्ट)

सम्मेलनमा अप्रिल ८ स्ट्राइक 2019, "DevOps" खण्डको भागको रूपमा, रिपोर्ट "कुबर्नेट्समा स्वत: स्केलिंग र स्रोत व्यवस्थापन" दिइएको थियो। यसले तपाइँको अनुप्रयोगहरूको उच्च उपलब्धता सुनिश्चित गर्न र शिखर प्रदर्शन सुनिश्चित गर्न तपाइँ कसरी K8s प्रयोग गर्न सक्नुहुन्छ भन्ने बारे कुरा गर्दछ।

परम्परा अनुसार, हामी प्रस्तुत गर्न खुसी छौं रिपोर्ट को भिडियो (44 मिनेट, लेख भन्दा धेरै जानकारीमूलक) र पाठ फारममा मुख्य सारांश। जाउ!

प्रतिवेदन शब्दको विषयलाई शब्दद्वारा विश्लेषण गरौं र अन्त्यबाट सुरु गरौं।

कुबर्नेट्स

मानौं हामीसँग हाम्रो होस्टमा डकर कन्टेनरहरू छन्। के को लागि? पुनरावृत्ति र अलगाव सुनिश्चित गर्न, जसले बारीमा सरल र राम्रो परिनियोजनको लागि अनुमति दिन्छ, CI/CD। हामीसँग कन्टेनर भएका यस्ता धेरै सवारीसाधन छन् ।

यस मामला मा Kubernetes के प्रदान गर्दछ?

1. हामी यी मेसिनहरूको बारेमा सोच्न छोड्छौं र "क्लाउड" सँग काम गर्न थाल्छौं। कन्टेनरहरूको समूह वा पोडहरू (कन्टेनरहरूको समूह)।
2. यसबाहेक, हामी व्यक्तिगत पोडहरूको बारेमा सोच्दैनौं, तर थप व्यवस्थापन गर्छौंоठूला समूहहरू। यस्तो उच्च-स्तरीय आदिमहरू हामीलाई भन्न अनुमति दिनुहोस् कि त्यहाँ एक निश्चित कार्यभार चलाउनको लागि टेम्प्लेट छ, र यहाँ यसलाई चलाउनको लागि आवश्यक संख्याहरू छन्। यदि हामीले पछि टेम्प्लेट परिवर्तन गर्छौं भने, सबै उदाहरणहरू परिवर्तन हुनेछन्।
3. सहयोगको साथ घोषणात्मक API विशेष आदेशहरूको अनुक्रम कार्यान्वयन गर्नुको सट्टा, हामी "संसारको संरचना" (YAML मा) को वर्णन गर्छौं, जुन Kubernetes द्वारा सिर्जना गरिएको हो। र फेरि: जब वर्णन परिवर्तन हुन्छ, यसको वास्तविक प्रदर्शन पनि परिवर्तन हुनेछ।

स्रोत व्यवस्थापन

CPU

सर्भरमा nginx, php-fpm र mysql चलाउनुहोस्। यी सेवाहरूमा वास्तवमा अझ बढी प्रक्रियाहरू चल्नेछन्, जसमध्ये प्रत्येकलाई कम्प्युटिङ स्रोतहरू चाहिन्छ:

(स्लाइडमा अंकहरू "तोता" हुन्, कम्प्युटिङ पावरको लागि प्रत्येक प्रक्रियाको सार आवश्यकता)

यससँग काम गर्न सजिलो बनाउनका लागि, प्रक्रियाहरूलाई समूहहरूमा जोड्नु तार्किक छ (उदाहरणका लागि, सबै nginx प्रक्रियाहरूलाई एउटा समूह "nginx" मा)। यो गर्नको लागि एक सरल र स्पष्ट तरिका प्रत्येक समूहलाई कन्टेनरमा राख्नु हो:

जारी राख्न, तपाईंले कन्टेनर के हो भनेर सम्झनु आवश्यक छ (लिनक्समा)। तिनीहरूको उपस्थिति कर्नेलमा तीन मुख्य सुविधाहरूको लागि सम्भव भएको थियो, धेरै लामो समय अघि लागू गरिएको थियो: क्षमताओं, नेमस्पेसहरू и समूहहरु। र थप विकास अन्य प्रविधिहरू (डकर जस्ता सुविधाजनक "शेलहरू" सहित) द्वारा सहज भएको थियो:

रिपोर्टको सन्दर्भमा, हामी केवल चासो राख्छौं समूहहरु, किनभने नियन्त्रण समूहहरू कन्टेनरहरू (डकर, इत्यादि) को कार्यक्षमताको अंश हुन् जसले स्रोत व्यवस्थापन लागू गर्दछ। समूहहरूमा संयुक्त प्रक्रियाहरू, हामीले चाहेको रूपमा, नियन्त्रण समूहहरू हुन्।

यी प्रक्रियाहरूको लागि CPU आवश्यकताहरूमा फर्कौं, र अब प्रक्रियाहरूको समूहहरूको लागि:

(म दोहोर्याउँछु कि सबै संख्याहरू स्रोतहरूको आवश्यकताको अमूर्त अभिव्यक्ति हुन्)

एकै समयमा, CPU आफैमा एक निश्चित सीमित स्रोत छ (उदाहरणमा यो 1000 हो), जसको सबैलाई अभाव हुन सक्छ (सबै समूहहरूको आवश्यकताको योगफल 150+850+460=1460 हो)। यस मामला मा के हुनेछ?

कर्नेलले स्रोतहरू वितरण गर्न थाल्छ र प्रत्येक समूहलाई समान मात्रामा स्रोतहरू दिँदै "निष्पक्ष रूपमा" गर्छ। तर पहिलो अवस्थामा, त्यहाँ आवश्यक भन्दा बढी छन् (333> 150), त्यसैले अतिरिक्त (333-150 = 183) रिजर्भमा रहन्छ, जुन दुई अन्य कन्टेनरहरू बीच पनि समान रूपमा वितरित गरिन्छ:

नतिजाको रूपमा: पहिलो कन्टेनरमा पर्याप्त स्रोतहरू थिए, दोस्रो - यसमा पर्याप्त स्रोतहरू थिएनन्, तेस्रो - यसमा पर्याप्त स्रोतहरू थिएनन्। यो कर्मको परिणाम हो लिनक्समा "इमानदार" अनुसूचक - सीएफएस। यसको सञ्चालन असाइनमेन्ट प्रयोग गरेर समायोजन गर्न सकिन्छ तौल प्रत्येक कन्टेनर। उदाहरण को लागी, यो जस्तै:

दोस्रो कन्टेनर (php-fpm) मा स्रोतहरूको अभावको मामलालाई हेरौं। सबै कन्टेनर स्रोतहरू प्रक्रियाहरू बीच समान रूपमा वितरण गरिन्छ। नतिजाको रूपमा, मास्टर प्रक्रियाले राम्रोसँग काम गर्दछ, तर सबै कामदारहरू ढिलो हुन्छन्, उनीहरूलाई आवश्यक पर्ने आधाभन्दा कम प्राप्त गर्दै:

यसरी CFS अनुसूचक काम गर्दछ। हामीले कन्टेनरहरूलाई तोक्ने वजनहरूलाई हामी थप कल गर्नेछौं अनुरोधहरू। यो किन यस्तो छ - थप हेर्नुहोस्।

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

यो दृष्टिकोण कडा कोटा भनिन्छ (कडा सीमित)। यसलाई सरल रूपमा सम्झौं सीमा। यद्यपि, यदि तपाइँ सबै कन्टेनरहरूमा सीमाहरू वितरण गर्नुहुन्छ भने, एउटा समस्या उत्पन्न हुन्छ: mysql सडकमा ड्राइभ गरिरहेको थियो र कुनै समयमा यसको CPU को आवश्यकता समाप्त भयो, तर अन्य सबै प्रक्रियाहरू CPU सम्म पर्खन बाध्य छन्। निष्क्रिय.

लिनक्स कर्नेल र CPU सँग यसको अन्तरक्रियामा फर्कौं - समग्र चित्र निम्नानुसार छ:

cgroup मा दुई सेटिङहरू छन् - अनिवार्य रूपमा यी दुई सरल "ट्विस्टहरू" हुन् जसले तपाईंलाई निर्धारण गर्न अनुमति दिन्छ:

1. कन्टेनर (अनुरोध) को वजन छ शेयरहरू;
2. कन्टेनर कार्यहरूमा काम गर्ने कुल CPU समयको प्रतिशत (सीमा) हो कोटा.

CPU मापन कसरी गर्ने?

त्यहाँ विभिन्न तरिकाहरू छन्:

1. के तोता, कसैलाई थाहा छैन - तपाईले हरेक पटक वार्ता गर्न आवश्यक छ।
2. ब्याज स्पष्ट, तर सापेक्ष: 50 कोर र 4 कोर भएको सर्भरको 20% पूर्ण रूपमा फरक चीजहरू हुन्।
3. तपाईंले पहिले नै उल्लेख गरिएकाहरू प्रयोग गर्न सक्नुहुन्छ तौल, जुन लिनक्सलाई थाहा छ, तर तिनीहरू पनि सापेक्ष छन्।
4. सबैभन्दा उपयुक्त विकल्प भनेको कम्प्युटिङ स्रोतहरू मापन गर्नु हो सेकेन्ड। ती। वास्तविक समयको सेकेन्डको तुलनामा प्रोसेसर समयको सेकेन्डमा: प्रोसेसर समयको 1 सेकेन्ड प्रति 1 वास्तविक सेकेन्ड दिइएको थियो - यो एक सम्पूर्ण CPU कोर हो।

बोल्न अझ सजिलो बनाउन, तिनीहरूले सीधै मापन गर्न थाले कर्नेलहरू, तिनीहरूको अर्थ वास्तविक समयको तुलनामा उही CPU समय। लिनक्सले तौल बुझेको हुनाले, तर त्यति धेरै CPU समय/कोर होइन, एकबाट अर्कोमा अनुवाद गर्न एउटा संयन्त्र आवश्यक थियो।

३ सीपीयू कोर भएको सर्भरको एउटा साधारण उदाहरणलाई विचार गरौं, जहाँ तीनवटा पोडहरूलाई तौल दिइनेछ (५००, १००० र १५००) जुन उनीहरूलाई आवंटित कोरहरूको सम्बन्धित भागहरूमा सजिलै रूपान्तरण गरिन्छ (०.५, १ र १.५)।

यदि तपाईंले दोस्रो सर्भर लिनुभयो भने, जहाँ दुई गुणा धेरै कोरहरू (6) हुनेछन्, र त्यहाँ उही पोडहरू राख्नुहोस्, कोरहरूको वितरण सजिलैसँग 2 (1, 2 र 3, क्रमशः) ले गुणन गरेर गणना गर्न सकिन्छ। तर एउटा महत्त्वपूर्ण क्षण तब हुन्छ जब चौथो पोड यस सर्भरमा देखा पर्दछ, जसको तौल, सुविधाको लागि, 3000 हुनेछ। यसले CPU स्रोतहरूको अंश (आधा कोर) लिन्छ, र बाँकी पोडहरूको लागि तिनीहरू पुन: गणना गरिन्छ (आधा):

Kubernetes र CPU स्रोतहरू

Kubernetes मा, CPU स्रोतहरू सामान्यतया मा मापन गरिन्छ मिलिड्राक्स, अर्थात् 0,001 कोरलाई आधार वजनको रूपमा लिइन्छ। (Linux/cgroups शब्दावलीमा उही कुरालाई CPU शेयर भनिन्छ, यद्यपि, अझ स्पष्ट रूपमा, 1000 millicores = 1024 CPU शेयरहरू।) K8s ले सुनिश्चित गर्दछ कि यसले सर्भरमा सबै पोडहरूको वजनको योगफलको लागि CPU स्रोतहरू भन्दा बढी पोडहरू राख्दैन।

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

के हुने हो भने छैन अनुरोध निर्दिष्ट गरिएको छ (अर्थात् पोडमा आवश्यक कोरहरूको परिभाषित संख्या छैन)? Kubernetes ले सामान्यतया स्रोतहरू कसरी गणना गर्छ भन्ने कुरा बुझौं।

पोडको लागि तपाईले अनुरोधहरू (CFS अनुसूचक) र सीमाहरू निर्दिष्ट गर्न सक्नुहुन्छ (ट्राफिक लाइट सम्झनुहोस्?):

• यदि तिनीहरू बराबर निर्दिष्ट छन्, तब पोडलाई QoS वर्ग तोकिएको छ ग्यारेन्टी। यो संख्या सधैं उपलब्ध कोर को ग्यारेन्टी छ।
• यदि अनुरोध सीमा भन्दा कम छ भने - QoS वर्ग फुट्न मिल्ने। ती। हामी एक पोड आशा गर्छौं, उदाहरणका लागि, सधैं 1 कोर प्रयोग गर्न, तर यो मान यसको लागि सीमित छैन: कहिलेकाहीं पोडले थप प्रयोग गर्न सक्छ (जब सर्भरमा यसको लागि नि:शुल्क स्रोतहरू छन्)।
• त्यहाँ एक QoS कक्षा पनि छ उत्तम प्रयास - यसले ती धेरै पोडहरू समावेश गर्दछ जसको लागि अनुरोध निर्दिष्ट गरिएको छैन। उनीहरूलाई अन्तिम स्रोत दिइन्छ।

स्मृति

मेमोरी संग, स्थिति समान छ, तर थोरै फरक - सबै पछि, यी स्रोतहरूको प्रकृति फरक छ। सामान्यतया, समानता निम्नानुसार छ:

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

यो सँधै हामीलाई उपयुक्त हुँदैन, त्यसैले कुन प्रक्रियाहरू हाम्रा लागि महत्त्वपूर्ण छन् र मार्नु हुँदैन भनेर नियमन गर्न सम्भव छ। यो गर्न, प्यारामिटर प्रयोग गर्नुहोस् oom_score_adj.

CPU को QoS कक्षाहरूमा फर्कौं र oom_score_adj मानहरूसँग समानता कोरौं जसले पोडहरूको लागि मेमोरी खपत प्राथमिकताहरू निर्धारण गर्दछ:

• पोडको लागि सबैभन्दा कम oom_score_adj मान - -998 - भनेको यस्तो पोडलाई अन्तिममा मार्नु पर्छ, यो ग्यारेन्टी.
• उच्चतम - 1000 - छ उत्तम प्रयास, त्यस्ता पोडहरू पहिले मारिन्छन्।
• बाँकी मानहरू गणना गर्न (फुट्न मिल्ने) त्यहाँ एउटा सूत्र छ, जसको सार यस तथ्यमा उबलिन्छ कि पोडले जति धेरै स्रोतहरू अनुरोध गरेको छ, मारिने सम्भावना कम हुन्छ।

दोस्रो "ट्विस्ट" - limit_in_bytes - सीमा को लागी। यसको साथ, सबै कुरा सरल छ: हामी केवल जारी मेमोरीको अधिकतम मात्रा प्रदान गर्दछौं, र यहाँ (CPU को विपरीत) यसलाई कसरी (मेमोरी) मापन गर्ने कुनै प्रश्न छैन।

कुल

Kubernetes मा प्रत्येक पोड दिइएको छ requests и limits - CPU र मेमोरीको लागि दुवै प्यारामिटरहरू:

1. अनुरोधहरूमा आधारित, Kubernetes अनुसूचक काम गर्दछ, जसले सर्भरहरू बीच पोडहरू वितरण गर्दछ;
2. सबै प्यारामिटरहरूमा आधारित, पोडको QoS वर्ग निर्धारण गरिन्छ;
3. सापेक्ष तौल CPU अनुरोधहरूको आधारमा गणना गरिन्छ;
4. CFS अनुसूचक CPU अनुरोधहरूमा आधारित कन्फिगर गरिएको छ;
5. OOM किलर मेमोरी अनुरोधहरूमा आधारित कन्फिगर गरिएको छ;
6. एक "ट्राफिक लाइट" CPU सीमाहरूमा आधारित कन्फिगर गरिएको छ;
7. मेमोरी सीमाहरूमा आधारित, cgroup को लागि सीमा कन्फिगर गरिएको छ।

सामान्यतया, यो तस्विरले Kubernetes मा संसाधन व्यवस्थापनको मुख्य भाग कसरी हुन्छ भन्ने बारे सबै प्रश्नहरूको जवाफ दिन्छ।

स्वतः स्केलिङ

K8s क्लस्टर-अटोस्केलर

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

यो Kubernetes क्लस्टरको स्वत: स्केलिङ हो, जसले राम्रो काम गर्दछ (हाम्रो अनुभवमा)। जे होस्, अन्यत्र जस्तै, यहाँ केही बारीकताहरू छन् ...

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

डिप्लोयमेन्ट भएको ३ सर्भरहरूको क्लस्टरलाई विचार गर्नुहोस्। यसमा 3 पोडहरू छन्: अब त्यहाँ प्रत्येक सर्भरको लागि 6 छन्। केही कारणले हामीले एउटा सर्भर बन्द गर्न चाहेका थियौं। यो गर्नको लागि हामी आदेश प्रयोग गर्नेछौं kubectl drain, जुन:

• यस सर्भरमा नयाँ पोडहरू पठाउन निषेध गर्नेछ;
• सर्भरमा अवस्थित पोडहरू मेटाउनेछ।

चूंकि Kubernetes पोड (6) को संख्या कोयम राख्न को लागी जिम्मेवार छ, यो सरल पुन: निर्माण गर्नेछ तिनीहरूलाई अन्य नोडहरूमा, तर असक्षम गरिएकोमा होइन, किनभने यो पहिले नै नयाँ पोडहरू होस्ट गर्नको लागि अनुपलब्ध भनी चिन्ह लगाइएको छ। यो Kubernetes को लागि एक आधारभूत मेकानिक हो।

यद्यपि, यहाँ पनि एक nuance छ। उस्तै अवस्थामा, स्टेटफुलसेटको लागि (डिप्लोइमेन्टको सट्टा), कार्यहरू फरक हुनेछन्। अब हामीसँग पहिले नै स्टेटफुल एप्लिकेसन छ - उदाहरणका लागि, MongoDB सँग तीनवटा पोडहरू, जसमध्ये एउटामा कुनै प्रकारको समस्या छ (डेटा भ्रष्ट भएको छ वा अर्को त्रुटि जसले पोडलाई सही रूपमा सुरु हुनबाट रोक्छ)। र हामी फेरि एउटा सर्भर असक्षम गर्ने निर्णय गर्छौं। के हुनेछ?

MongoDB सक्छ मर्नुहोस् किनभने यसलाई कोरम चाहिन्छ: तीन स्थापनाहरूको क्लस्टरको लागि, कम्तिमा दुई कार्य गर्नुपर्दछ। यद्यपि, यो भइरहेको छैन - धन्यवाद PodDisruptionBudget। यो प्यारामिटरले काम गर्ने पोडहरूको न्यूनतम आवश्यक संख्या निर्धारण गर्दछ। MongoDB पोडहरू मध्ये एउटा अब काम गरिरहेको छैन भन्ने थाहा पाउँदा, र MongoDB को लागि PodDisruptionBudget सेट गरिएको देखेर minAvailable: 2, Kubernetes ले तपाईंलाई पोड मेटाउन अनुमति दिँदैन।

तल्लो रेखा: क्लस्टर रिलिज हुँदा पोडहरूको आन्दोलन (र वास्तवमा पुन: निर्माण) को लागि सही तरिकाले काम गर्न, यो PodDisruptionBudget कन्फिगर गर्न आवश्यक छ।

तेर्सो स्केलिंग

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

आज Kubernetes मा यो म्यानुअल रूपमा गर्न आवश्यक छैन: पोडहरूको संख्यामा स्वचालित वृद्धि/घटना मापन गरिएको लोड सूचकहरूको मानहरूको आधारमा कन्फिगर गरिएको छ।

यहाँ मुख्य प्रश्नहरू छन्: वास्तवमा के मापन गर्न и कसरी व्याख्या गर्ने प्राप्त मानहरू (पोडहरूको संख्या परिवर्तन गर्ने निर्णयको लागि)। तपाईं धेरै मापन गर्न सक्नुहुन्छ:

प्राविधिक रूपमा यो कसरी गर्ने - मेट्रिक्स, आदि सङ्कलन गर्नुहोस्। - मैले प्रतिवेदनमा विस्तृत रूपमा बोलेको छु निगरानी र Kubernetes। र इष्टतम प्यारामिटरहरू छनौट गर्नको लागि मुख्य सल्लाह हो परिक्षण!

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

बरु एक निष्कर्षमा को

रिपोर्टको निरन्तरता छ: ठाडो मापन र सही स्रोतहरू कसरी चयन गर्ने बारे। म यस बारे भविष्यका भिडियोहरूमा कुरा गर्नेछु हाम्रो YouTube - सदस्यता लिनुहोस् ताकि तपाईंले नछुटाउनुहुनेछ!

भिडियो र स्लाइडहरू

प्रदर्शनबाट भिडियो (४४ मिनेट):

प्रतिवेदन प्रस्तुति:

PS

हाम्रो ब्लगमा Kubernetes को बारेमा अन्य रिपोर्टहरू:

• «Kubernetes विस्तार र पूरक» (Andrey Polovov; अप्रिल 8, 2019 सेन्ट हाईलोड++ मा);
• «डाटाबेस र Kubernetes» (दिमित्री स्टोल्यारोभ; नोभेम्बर 8, 2018 HighLoad++ मा);
• «निगरानी र Kubernetes» (दिमित्री स्टोल्यारोभ; मे २८, २०१८ रूटकन्फमा);
• «Kubernetes र GitLab संग CI/CD उत्तम अभ्यासहरू» (दिमित्री स्टोल्यारोभ; नोभेम्बर 7, 2017 HighLoad++ मा);
• «साना परियोजनाहरूमा Kubernetes संग हाम्रो अनुभव» (दिमित्री Stolyarov; जुन 6, 2017 RootConf मा).

स्रोत: www.habr.com