कुबर्नेट्समध्ये ऑटोस्केलिंग आणि संसाधन व्यवस्थापन (विहंगावलोकन आणि व्हिडिओ अहवाल)

27 एप्रिल रोजी परिषदेत संप 2019, “DevOps” विभागाचा भाग म्हणून, “कुबर्नेट्समधील ऑटोस्केलिंग आणि संसाधन व्यवस्थापन” हा अहवाल देण्यात आला. तुमच्या ऍप्लिकेशन्सची उच्च उपलब्धता सुनिश्चित करण्यासाठी आणि उत्कृष्ट कामगिरी सुनिश्चित करण्यासाठी तुम्ही K8s कसे वापरू शकता याबद्दल ते बोलते.

परंपरेनुसार, आम्हाला सादर करण्यात आनंद होतो अहवालाचा व्हिडिओ (44 मिनिटे, लेखापेक्षा अधिक माहितीपूर्ण) आणि मजकूर स्वरूपात मुख्य सारांश. जा!

चला अहवालाच्या विषयाचे शब्दानुसार विश्लेषण करू आणि शेवटपासून सुरुवात करू.

कुबेरनेट्स

समजा आमच्या होस्टवर आमच्याकडे डॉकर कंटेनर आहेत. कशासाठी? पुनरावृत्तीक्षमता आणि अलगाव सुनिश्चित करण्यासाठी, जे यामधून साधे आणि चांगले उपयोजन, 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. आपण आधीच नमूद केलेले वापरू शकता वजन, जे Linux ला माहित आहे, परंतु ते देखील सापेक्ष आहेत.
4. मध्ये संगणकीय संसाधने मोजणे हा सर्वात योग्य पर्याय आहे सेकंद. त्या. रिअल टाइमच्या सेकंदांच्या सापेक्ष प्रोसेसर वेळेच्या सेकंदांमध्ये: प्रोसेसर वेळेचा 1 सेकंद प्रति 1 रिअल सेकंद दिला गेला - हा एक संपूर्ण CPU कोर आहे.

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

3 CPU कोर असलेल्या सर्व्हरसह एक साधे उदाहरण विचारात घेऊ या, जेथे तीन पॉड्सना वजन (500, 1000 आणि 1500) दिले जाईल जे त्यांना वाटप केलेल्या कोरच्या संबंधित भागांमध्ये (0,5, 1 आणि 1,5) सहजपणे रूपांतरित केले जातील.

तुम्ही दुसरा सर्व्हर घेतल्यास, जेथे दुप्पट कोर (6) असतील आणि त्याच पॉड्स तेथे ठेवल्यास, कोरचे वितरण फक्त 2 (अनुक्रमे 1, 2 आणि 3) ने गुणाकार करून सहज काढता येईल. परंतु एक महत्त्वाचा क्षण येतो जेव्हा या सर्व्हरवर चौथा पॉड दिसून येतो, ज्याचे वजन, सोयीसाठी, 3000 असेल. ते CPU संसाधनांचा काही भाग (अर्धा कोर) काढून घेते आणि उर्वरित पॉडसाठी ते पुन्हा मोजले जातात (अर्धे केले जातात):

Kubernetes आणि CPU संसाधने

Kubernetes मध्ये, CPU संसाधने सहसा मोजली जातात मिलियाड्रॅक्स, म्हणजे 0,001 कोर हे मूळ वजन म्हणून घेतले जातात. (Linux/cgroups च्या शब्दावलीत याच गोष्टीला CPU शेअर म्हणतात, जरी अधिक स्पष्टपणे, 1000 millicores = 1024 CPU शेअर्स.) K8s सर्व पॉड्सच्या वजनाच्या बेरीजसाठी CPU संसाधनांपेक्षा जास्त पॉड सर्व्हरवर ठेवत नाही याची खात्री करते.

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

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

पॉडसाठी तुम्ही दोन्ही विनंत्या (CFS शेड्युलर) आणि मर्यादा (ट्रॅफिक लाइट लक्षात ठेवा?) निर्दिष्ट करू शकता:

• जर ते समान नमूद केले असतील, तर पॉडला QoS वर्ग नियुक्त केला जातो हमी. त्याच्याकडे नेहमी उपलब्ध असलेल्या कोरची ही संख्या हमी आहे.
• विनंती मर्यादेपेक्षा कमी असल्यास - QoS वर्ग फुटण्यायोग्य. त्या. आम्ही पॉडची अपेक्षा करतो, उदाहरणार्थ, नेहमी 1 कोर वापरणे, परंतु हे मूल्य त्यासाठी मर्यादा नाही: कधी कधी पॉड अधिक वापरू शकते (जेव्हा सर्व्हरवर यासाठी विनामूल्य संसाधने असतात).
• एक QoS वर्ग देखील आहे सर्वोत्तम प्रयत्न — ज्यासाठी विनंती निर्दिष्ट केलेली नाही अशा शेंगा समाविष्ट आहेत. त्यांना शेवटचे संसाधन दिले जाते.

स्मृती

स्मृतीसह, परिस्थिती समान आहे, परंतु थोडी वेगळी आहे - सर्व केल्यानंतर, या संसाधनांचे स्वरूप भिन्न आहे. सर्वसाधारणपणे, समानता खालीलप्रमाणे आहे:

मेमरीमध्ये विनंत्या कशा अंमलात आणल्या जातात ते पाहू. पॉड्स सर्व्हरवर राहू द्या, मेमरी वापर बदलत आहे, जोपर्यंत त्यापैकी एक इतका मोठा होत नाही की त्याची मेमरी संपत नाही. या प्रकरणात, OOM किलर दिसून येतो आणि सर्वात मोठी प्रक्रिया नष्ट करतो:

हे नेहमीच आपल्यास अनुरूप नसते, म्हणून कोणत्या प्रक्रिया आपल्यासाठी महत्त्वाच्या आहेत आणि मारल्या जाऊ नयेत याचे नियमन करणे शक्य आहे. हे करण्यासाठी, पॅरामीटर वापरा oom_score_adj.

चला CPU च्या QoS वर्गांकडे परत जाऊया आणि oom_score_adj मूल्यांशी साधर्म्य काढू जे पॉड्ससाठी मेमरी वापराचे प्राधान्यक्रम ठरवतात:

• पॉडसाठी सर्वात कमी oom_score_adj मूल्य - -998 - म्हणजे असा पॉड शेवटचा मारला गेला पाहिजे, हे हमी.
• सर्वोच्च - 1000 - आहे सर्वोत्तम प्रयत्नअशा शेंगा प्रथम मारल्या जातात.
• उर्वरित मूल्यांची गणना करण्यासाठी (फुटण्यायोग्य) एक सूत्र आहे, ज्याचे सार या वस्तुस्थितीवर उकळते की पॉडने जितक्या अधिक संसाधनांची विनंती केली आहे तितकी ती मारली जाण्याची शक्यता कमी आहे.

दुसरा "ट्विस्ट" - limit_in_bytes - मर्यादेसाठी. त्यासह, सर्वकाही सोपे आहे: आम्ही जारी केलेल्या मेमरीची जास्तीत जास्त रक्कम नियुक्त करतो आणि येथे (सीपीयूच्या विपरीत) ते (मेमरी) कसे मोजायचे याचा प्रश्न नाही.

एकूण

कुबर्नेट्समधील प्रत्येक पॉड दिलेला आहे requests и limits - CPU आणि मेमरी दोन्ही पॅरामीटर्स:

1. विनंत्यांच्या आधारावर, कुबर्नेट्स शेड्यूलर कार्य करते, जे सर्व्हरमध्ये पॉड्स वितरीत करते;
2. सर्व पॅरामीटर्सवर आधारित, पॉडचा QoS वर्ग निर्धारित केला जातो;
3. CPU विनंत्यांवर आधारित सापेक्ष वजनांची गणना केली जाते;
4. CFS शेड्युलर CPU विनंत्यांवर आधारित कॉन्फिगर केले आहे;
5. OOM किलर मेमरी विनंत्यांच्या आधारे कॉन्फिगर केले आहे;
6. सीपीयू मर्यादेवर आधारित "ट्रॅफिक लाइट" कॉन्फिगर केले आहे;
7. मेमरी मर्यादांवर आधारित, cgroup साठी मर्यादा कॉन्फिगर केली आहे.

सर्वसाधारणपणे, हे चित्र कुबर्नेट्समध्ये मोठ्या प्रमाणात संसाधन व्यवस्थापन कसे होते याविषयी सर्व प्रश्नांची उत्तरे देते.

ऑटोस्केलिंग

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

चला कल्पना करूया की संपूर्ण क्लस्टर आधीच व्यापलेला आहे आणि एक नवीन पॉड तयार करणे आवश्यक आहे. पॉड दिसू शकत नसला तरी तो स्थितीत लटकतो प्रलंबित. ते दिसण्यासाठी, आम्ही क्लस्टरशी नवीन सर्व्हर कनेक्ट करू शकतो किंवा... क्लस्टर-ऑटोस्केलर स्थापित करू शकतो, जे ते आमच्यासाठी करेल: क्लाउड प्रदात्याकडून व्हर्च्युअल मशीन ऑर्डर करा (एपीआय विनंती वापरून) आणि क्लस्टरशी कनेक्ट करा , ज्यानंतर पॉड जोडला जाईल.

हे Kubernetes क्लस्टरचे ऑटोस्केलिंग आहे, जे उत्तम काम करते (आमच्या अनुभवात). तथापि, इतरत्र प्रमाणे, येथे काही बारकावे आहेत...

जोपर्यंत आम्ही क्लस्टरचा आकार वाढवला तोपर्यंत सर्व काही ठीक होते, परंतु क्लस्टर झाल्यावर काय होते स्वत:ला मोकळे करायला सुरुवात केली? समस्या अशी आहे की पॉड्स स्थलांतरित करणे (यजमानांना मोकळे करण्यासाठी) तांत्रिकदृष्ट्या खूप कठीण आणि संसाधनांच्या दृष्टीने महाग आहे. Kubernetes पूर्णपणे भिन्न दृष्टीकोन वापरते.

डिप्लॉयमेंट असलेल्या 3 सर्व्हरच्या क्लस्टरचा विचार करा. यात 6 शेंगा आहेत: आता प्रत्येक सर्व्हरसाठी 2 आहेत. काही कारणास्तव आम्हाला एक सर्व्हर बंद करायचा होता. हे करण्यासाठी आपण कमांड वापरू kubectl drain, जे:

• या सर्व्हरवर नवीन पॉड पाठविण्यास मनाई करेल;
• सर्व्हरवरील विद्यमान पॉड हटवेल.

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

तथापि, येथे देखील एक सूक्ष्मता आहे. तत्सम परिस्थितीत, स्टेटफुलसेटसाठी (डिप्लॉयमेंटऐवजी), क्रिया वेगळ्या असतील. आता आमच्याकडे आधीच एक स्टेटफुल ऍप्लिकेशन आहे - उदाहरणार्थ, मोंगोडीबीसह तीन पॉड्स, ज्यापैकी एकामध्ये काही समस्या आहे (डेटा दूषित झाला आहे किंवा पॉड योग्यरित्या सुरू होण्यापासून रोखणारी दुसरी त्रुटी). आणि आम्ही पुन्हा एक सर्व्हर अक्षम करण्याचा निर्णय घेतला. काय होईल?

MongoDB करू शकलो die कारण त्याला कोरमची गरज आहे: तीन इंस्टॉलेशन्सच्या क्लस्टरसाठी, किमान दोन कार्य करणे आवश्यक आहे. तथापि, हे होत नाही - ना धन्यवाद PodDisruptionBudget. हे पॅरामीटर कार्यरत शेंगांची किमान आवश्यक संख्या निर्धारित करते. मोंगोडीबी पॉड्सपैकी एक यापुढे काम करत नाही हे जाणून घेणे आणि मोंगोडीबीसाठी PodDisruptionBudget सेट केलेले पाहून minAvailable: 2, Kubernetes तुम्हाला पॉड हटवण्याची परवानगी देणार नाही.

तळ ओळ: क्लस्टर रिलीज झाल्यावर पॉड्सची हालचाल (आणि खरं तर, पुनर्निर्मिती) योग्यरित्या कार्य करण्यासाठी, PodDisruptionBudget कॉन्फिगर करणे आवश्यक आहे.

क्षैतिज स्केलिंग

चला आणखी एका परिस्थितीचा विचार करूया. Kubernetes मध्ये उपयोजन म्हणून कार्यरत आहे. वापरकर्ता ट्रॅफिक त्याच्या पॉड्सवर येतो (उदाहरणार्थ, त्यापैकी तीन आहेत), आणि आम्ही त्यामध्ये एक विशिष्ट निर्देशक मोजतो (म्हणा, CPU लोड). जेव्हा लोड वाढते, तेव्हा आम्ही ते शेड्यूलवर रेकॉर्ड करतो आणि विनंत्या वितरित करण्यासाठी पॉड्सची संख्या वाढवतो.

आज कुबर्नेट्समध्ये हे व्यक्तिचलितपणे करण्याची आवश्यकता नाही: पॉड्सच्या संख्येत स्वयंचलित वाढ/कमी मोजलेल्या लोड निर्देशकांच्या मूल्यांवर अवलंबून कॉन्फिगर केले जाते.

येथे मुख्य प्रश्न आहेत: नक्की काय मोजायचे и कसे अर्थ लावायचे प्राप्त मूल्ये (शेंगांची संख्या बदलण्याचा निर्णय घेण्यासाठी). आपण बरेच मोजू शकता:

हे तांत्रिकदृष्ट्या कसे करायचे - मेट्रिक्स इ. गोळा करा. — मी अहवालात तपशीलवार बोललो देखरेख आणि Kubernetes. आणि इष्टतम पॅरामीटर्स निवडण्यासाठी मुख्य सल्ला आहे प्रयोग!

आहेत पद्धत वापरा (उपयोग संपृक्तता आणि त्रुटी), ज्याचा अर्थ खालीलप्रमाणे आहे. कोणत्या आधारावर स्केल करण्यात अर्थ आहे, उदाहरणार्थ, php-fpm? कामगार संपत आहेत या वस्तुस्थितीवर आधारित, हे आहे उपयोग. आणि जर कामगार संपले आणि नवीन कनेक्शन स्वीकारले गेले नाहीत तर हे आधीच आहे संपृक्तता. या दोन्ही पॅरामीटर्सचे मोजमाप करणे आवश्यक आहे आणि मूल्यांवर अवलंबून, स्केलिंग करणे आवश्यक आहे.

त्याऐवजी एक निष्कर्ष

अहवालात एक निरंतरता आहे: अनुलंब स्केलिंग आणि योग्य संसाधने कशी निवडावी याबद्दल. मी भविष्यातील व्हिडिओंमध्ये याबद्दल बोलेन आमचे YouTube - सदस्यता घ्या जेणेकरून तुम्ही चुकणार नाही!

व्हिडिओ आणि स्लाइड्स

कामगिरीमधील व्हिडिओ (44 मिनिटे):

अहवालाचे सादरीकरण:

PS

आमच्या ब्लॉगवर कुबर्नेट्स बद्दल इतर अहवाल:

• «कुबर्नेट्सचा विस्तार आणि पूरक» (Andrey Polovov; सेंट हायलोड++ वर 8 एप्रिल 2019);
• «डेटाबेस आणि कुबर्नेट्स» (दिमित्री स्टोल्यारोव्ह; 8 नोव्हेंबर, 2018 HighLoad++ वर);
• «देखरेख आणि Kubernetes» (दिमित्री स्टोल्यारोव्ह; रूटकॉन्फ येथे 28 मे 2018);
• «कुबर्नेट्स आणि गिटलॅबसह CI/CD सर्वोत्तम पद्धती» (दिमित्री स्टोल्यारोव्ह; 7 नोव्हेंबर, 2017 HighLoad++ वर);
• «लहान प्रकल्पांमध्ये कुबर्नेट्ससोबतचा आमचा अनुभव» (दिमित्री स्टोल्यारोव्ह; रूटकॉन्फ येथे 6 जून 2017).

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