डाटाबेस क्लस्टरहरू प्रबन्ध गर्न Kubernetes मा अपरेटर। भ्लादिस्लाव क्लिमेन्को (अल्टिनिटी, २०१९)

रिपोर्ट Kubernetes मा एक अपरेटर को विकास को व्यावहारिक मुद्दाहरु को लागी समर्पित छ, यसको वास्तुकला र आधारभूत संचालन सिद्धान्तहरु को डिजाइन।

रिपोर्टको पहिलो भागमा हामी विचार गर्नेछौं:

• Kubernetes मा एक अपरेटर के हो र यो किन आवश्यक छ;
• वास्तवमा कसरी अपरेटरले जटिल प्रणालीहरूको व्यवस्थापनलाई सरल बनाउँछ;
• अपरेटरले के गर्न सक्छ र के गर्न सक्दैन।

अर्को, अपरेटरको आन्तरिक संरचनाको बारेमा छलफल गर्न अगाडि बढौं। चरण-दर-चरण अपरेटरको वास्तुकला र सञ्चालनलाई हेरौं। यसलाई विस्तृत रूपमा हेरौं:

• अपरेटर र Kubernetes बीच अन्तरक्रिया;
• अपरेटरले कुन प्रकार्यहरू लिन्छ र कुन प्रकार्यहरू यसले Kubernetes लाई प्रत्यायोजित गर्दछ।

Kubernetes मा शार्डहरू र डाटाबेस प्रतिकृतिहरू प्रबन्ध गर्ने बारे हेरौं।
अर्को, हामी डाटा भण्डारण मुद्दाहरू छलफल गर्नेछौं:

• अपरेटरको दृष्टिकोणबाट कसरी निरन्तर भण्डारणसँग काम गर्ने;
• स्थानीय भण्डारण प्रयोग गर्ने समस्याहरू।

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

भिडियो:

मेरो नाम Vladislav Klimenko हो। आज म अपरेटरको विकास र सञ्चालनमा हाम्रो अनुभवको बारेमा कुरा गर्न चाहन्छु, र यो डाटाबेस क्लस्टरहरू प्रबन्ध गर्नको लागि एक विशेष अपरेटर हो। उदाहरणका लागि हाउस अपरेटर क्लिक गर्नुहोस् ClickHouse क्लस्टर व्यवस्थापन गर्न।

किन हामीसँग अपरेटर र क्लिकहाउसको बारेमा कुरा गर्ने मौका छ?

• हामी क्लिकहाउसलाई समर्थन र विकास गर्छौं।
• यस समयमा, हामी बिस्तारै क्लिकहाउसको विकासमा हाम्रो योगदान दिन प्रयास गर्दैछौं। र क्लिकहाउसमा गरिएका परिवर्तनहरूको मात्राको सन्दर्भमा हामी Yandex पछि दोस्रो छौं।
• हामी ClickHouse इकोसिस्टमका लागि थप परियोजनाहरू सिर्जना गर्ने प्रयास गरिरहेका छौं।

म तपाईंलाई यी मध्ये एक परियोजनाको बारेमा बताउन चाहन्छु। यो Kubernetes को लागि ClickHouse-अपरेटर को बारे मा छ।

मेरो प्रतिवेदनमा म दुईवटा विषयमा छुट्याउन चाहन्छु:

• पहिलो विषय भनेको हाम्रो ClickHouse डाटाबेस व्यवस्थापन अपरेटरले Kubernetes मा कसरी काम गर्दछ।
• दोस्रो विषय भनेको कुनै पनि अपरेटरले कसरी काम गर्छ, अर्थात् यसले Kubernetes सँग कसरी अन्तरक्रिया गर्छ भन्ने हो।

जे होस्, यी दुई प्रश्नहरू मेरो प्रतिवेदनमा प्रतिच्छेदन हुनेछन्।

मैले भन्न खोजेको कुरा सुन्न कसलाई रुचि छ?

• यो अपरेटरहरू सञ्चालन गर्नेहरूलाई सबैभन्दा चासोको विषय हुनेछ।
• वा जसले आन्तरिक रूपमा कसरी काम गर्दछ, अपरेटरले Kubernetes सँग कसरी अन्तरक्रिया गर्छ, र कस्ता समस्याहरू देखा पर्न सक्छन् भनेर बुझ्नको लागि आफ्नो बनाउन चाहनेहरूका लागि।

आज हामीले के छलफल गर्नेछौं भन्ने कुरा राम्ररी बुझ्नको लागि, Kubernetes ले कसरी काम गर्छ भनेर जान्न र केही आधारभूत क्लाउड प्रशिक्षण लिनु राम्रो विचार हो।

ClickHouse के हो? यो विश्लेषणात्मक प्रश्नहरूको अनलाइन प्रशोधनका लागि विशिष्ट सुविधाहरू भएको स्तम्भ डेटाबेस हो। र यो पूर्ण रूपमा खुला स्रोत हो।

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

उहाँलाई त्यहाँ किन आवश्यक छ? किन हामी आफैले यसलाई सञ्चालन गर्न जारी राख्न सक्दैनौं? र जवाफहरू आंशिक रूपमा प्राविधिक र आंशिक रूपमा संगठनात्मक छन्।

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

कति सजिलो वा गाह्रो छ? यो, निस्सन्देह, हात द्वारा गर्न सकिन्छ। तर यो त्यति सरल छैन, किनकि हामीसँग Kubernetes आफैं व्यवस्थापन गर्ने जटिलता थपिएको छ, तर एकै समयमा क्लिकहाउसका विवरणहरू सुपरइम्पोज गरिएका छन्। र यस्तो एकीकरण परिणाम।

र सबै मिलेर यसले प्रविधिहरूको एकदम ठूलो सेट दिन्छ, जुन व्यवस्थापन गर्न एकदमै गाह्रो हुन्छ, किनभने Kubernetes ले आफ्नै दैनिक समस्याहरू सञ्चालनमा ल्याउँछ, र ClickHouse ले दैनिक सञ्चालनमा आफ्नै समस्याहरू ल्याउँछ। विशेष गरी यदि हामीसँग धेरै क्लिकहाउसहरू छन्, र हामीले तिनीहरूसँग निरन्तर केही गर्न आवश्यक छ।

डायनामिक कन्फिगरेसनको साथ, ClickHouse सँग पर्याप्त मात्रामा समस्याहरू छन् जसले DevOps मा स्थिर लोड सिर्जना गर्दछ:

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

यी नियमित कार्यहरू हुन् जुन म वास्तवमै प्रयोग गर्न सजिलो बनाउन चाहन्छु।

Kubernetes आफैले सञ्चालनमा राम्रोसँग मद्दत गर्दछ, तर आधारभूत प्रणाली चीजहरूमा।

Kubernetes चीजहरू सुविधा र स्वचालित रूपमा राम्रो छ:

• पुन: प्राप्ति।
• फेरि शुरु गर्नु।
• भण्डारण प्रणाली व्यवस्थापन।

त्यो राम्रो छ, त्यो सही दिशा हो, तर डाटाबेस क्लस्टर कसरी सञ्चालन गर्ने भन्ने बारे उहाँ पूर्णतया अनभिज्ञ हुनुहुन्छ।

हामी थप चाहन्छौं, हामी सम्पूर्ण डाटाबेस Kubernetes मा काम गर्न चाहन्छौं।

म तपाईंले थिच्नुहुने एउटा ठूलो एउटा जादुई रातो बटन जस्तो केहि प्राप्त गर्न चाहन्छु र दैनिक कार्यहरू समाधान गर्न आवश्यक पर्ने क्लस्टरलाई यसको सम्पूर्ण जीवन चक्रमा तैनाथ र कायम राखिएको छ। Kubernetes मा ClickHouse क्लस्टर।

र हामीले एक समाधान गर्ने प्रयास गर्यौं जसले कामलाई सजिलो बनाउन मद्दत गर्दछ। यो Altinity बाट Kubernetes को लागि ClickHouse-अपरेटर हो।

एक अपरेटर एक कार्यक्रम हो जसको मुख्य कार्य अन्य कार्यक्रमहरू व्यवस्थापन गर्नु हो, अर्थात् यो एक प्रबन्धक हो।

र यसले व्यवहारको ढाँचाहरू समावेश गर्दछ। तपाईले विषय क्षेत्रको बारेमा यो कोडिफाइड ज्ञान भन्न सक्नुहुन्छ।

र उनको मुख्य कार्य DevOps को जीवनलाई सजिलो बनाउन र माइक्रोप्रबन्धनलाई कम गर्नु हो, ताकि उसले (DevOps) पहिले नै उच्च-स्तरका सर्तहरूमा सोच्दछ, अर्थात्, ताकि उहाँ (DevOps) माइक्रोप्रबन्धनमा संलग्न हुनुहुन्न, ताकि उसले कन्फिगर गर्दैन। सबै विवरणहरू म्यानुअल रूपमा।

र केवल अपरेटर एक रोबोट सहायक हो जसले माइक्रोटास्कहरूसँग व्यवहार गर्दछ र DevOps लाई मद्दत गर्दछ।

तपाईलाई किन अपरेटर चाहिन्छ? उसले विशेष गरी दुई क्षेत्रमा राम्रो प्रदर्शन गर्दछ:

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

यो या त भर्खरै आफ्नो यात्रा सुरु गर्नेहरूलाई, वा धेरै स्वचालन गर्न आवश्यक भएकाहरूलाई आवश्यक छ।

कसरी अपरेटर-आधारित दृष्टिकोण अन्य प्रणालीहरू भन्दा फरक छ? हेलम छ। यसले क्लिकहाउस स्थापना गर्न पनि मद्दत गर्दछ; तपाइँ हेल्म चार्टहरू कोर्न सक्नुहुन्छ, जसले सम्पूर्ण क्लिकहाउस क्लस्टर स्थापना गर्दछ। त्यसोभए अपरेटर र उही, उदाहरणका लागि, हेल्म बीचको भिन्नता के हो?

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

त्यो परिचयात्मक भाग थियो, अगाडि बढौं।

हामीले हाम्रो अपरेटर कसरी बनाउने? हामी क्लिकहाउस क्लस्टरलाई एकल स्रोतको रूपमा व्यवस्थापन गर्न मुद्दामा पुग्ने प्रयास गरिरहेका छौं।

यहाँ हामीसँग तस्वीरको बायाँ छेउमा इनपुट डाटा छ। यो क्लस्टर स्पेसिफिकेशन भएको YAML हो, जुन kubectl मार्फत क्लासिक तरिकामा Kubernetes लाई पास गरिन्छ। त्यहाँ हाम्रो अपरेटरले यसलाई उठाउँछ र आफ्नो जादू गर्छ। र आउटपुटमा हामीले निम्न योजना पाउँछौं। यो Kubernetes मा ClickHouse को कार्यान्वयन हो।

र त्यसपछि हामी बिस्तारै अपरेटरले कसरी काम गर्छ, कुन सामान्य कार्यहरू समाधान गर्न सकिन्छ भनेर हेर्नेछौं। हामीसँग सीमित समय भएकाले हामी सामान्य कार्यहरू मात्र विचार गर्नेछौं। र अपरेटरले निर्णय गर्न सक्ने सबै कुराहरू छलफल गरिनेछैन।

अभ्यासबाट सुरु गरौं। हाम्रो परियोजना पूर्ण रूपमा खुला स्रोत हो, त्यसैले तपाईंले GitHub मा यसले कसरी काम गर्छ भनेर हेर्न सक्नुहुन्छ। र तपाइँ विचारहरूबाट अगाडि बढ्न सक्नुहुन्छ कि यदि तपाइँ यसलाई सुरु गर्न चाहानुहुन्छ भने, तपाइँ द्रुत सुरुवात गाइडको साथ सुरु गर्न सक्नुहुन्छ।

यदि तपाइँ विस्तृत रूपमा बुझ्न चाहनुहुन्छ भने, हामी कागजातलाई कम वा कम सभ्य रूपमा कायम राख्न प्रयास गर्छौं।

एक व्यावहारिक समस्या संग सुरु गरौं। पहिलो कार्य, जहाँ हामी सबै सुरु गर्न चाहन्छौं, कुनै न कुनै रूपमा पहिलो उदाहरण चलाउनु हो। म कसरी अपरेटर प्रयोग गरेर ClickHouse सुरु गर्न सक्छु, यद्यपि मलाई यो कसरी काम गर्छ भन्ने थाहा छैन? हामी घोषणापत्र लेख्दैछौं, किनकि... k8s सँग सबै संचार manifests मार्फत संचार हो।

यो यस्तो जटिल घोषणापत्र हो। हामीले रातोमा हाइलाइट गरेका छौं के हामीले ध्यान केन्द्रित गर्न आवश्यक छ। हामी अपरेटरलाई डेमो नामक क्लस्टर बनाउन अनुरोध गर्छौं।

यी अहिलेका लागि आधारभूत उदाहरणहरू हुन्। भण्डारण अझै वर्णन गरिएको छैन, तर हामी केहि समय पछि भण्डारणमा फर्कनेछौं। अहिलेको लागि, हामी क्लस्टरको विकासको गतिशीलता अवलोकन गर्नेछौं।

हामीले यो घोषणापत्र बनाएका छौं। हामी यसलाई हाम्रो अपरेटरलाई खुवाउँछौं। उहाँले काम गर्नुभयो, उहाँले जादू गर्नुभयो।

हामी कन्सोल हेर्छौं। तीन कम्पोनेन्टहरू चासोका छन्: एक पोड, दुई सेवाहरू, र स्टेटफुलसेट।

अपरेटरले काम गरेको छ, र हामी देख्न सक्छौं कि उहाँले वास्तवमा के सिर्जना गर्नुभयो।

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

सेवाहरू केन्द्रीय लोड ब्यालेन्सर सेवा हुन् र प्रत्येक प्रतिकृतिको लागि, प्रत्येक शार्डको लागि पनि प्रयोग गर्न सकिन्छ।

हाम्रो आधारभूत क्लस्टर यस्तो देखिन्छ। यो एक एकल नोड बाट छ।

अगाडि बढौं र चीजहरू जटिल गरौं। हामीले क्लस्टरलाई सेयर गर्न आवश्यक छ।

हाम्रा कार्यहरू बढ्दै छन्, गतिशीलता सुरु हुँदैछ। हामी शर्ड थप्न चाहन्छौं। हामी विकासलाई पछ्याउँछौं। हामी हाम्रो स्पेसिफिकेशन परिवर्तन गर्दैछौं। हामी संकेत गर्छौं कि हामी दुई शर्डहरू चाहन्छौं।

यो एउटै फाइल हो जुन गतिशील रूपमा प्रणालीको विकास संग विकसित हुन्छ। भण्डारण नम्बर, भण्डारण थप छलफल गरिनेछ, यो एक अलग विषय हो।

हामी YAML अपरेटरलाई खुवाउँछौं र के हुन्छ हेर्छौं।

अपरेटरले सोच्यो र निम्न संस्थाहरू बनायो। हामीसँग पहिले नै दुई पोडहरू छन्, तीन सेवाहरू र, अचानक, 2 स्टेटफुल सेटहरू। किन २ स्टेटफुल सेटहरू?

रेखाचित्रमा यो यस्तो थियो - यो हाम्रो प्रारम्भिक अवस्था हो, जब हामीसँग एउटा पोड थियो।

यस्तो भयो । अहिलेसम्म सबै कुरा सरल छ, यो नक्कल गरिएको छ।

र किन दुई स्टेटफुल सेट भए? यहाँ हामीले कुबर्नेट्समा पोडहरू कसरी व्यवस्थापन गरिन्छ भन्ने प्रश्नलाई डिग्रेसन र छलफल गर्न आवश्यक छ।

त्यहाँ स्टेटफुलसेट भनिने वस्तु छ जसले तपाईंलाई टेम्प्लेटबाट पोडहरूको सेट सिर्जना गर्न अनुमति दिन्छ। यहाँ मुख्य कारक टेम्प्लेट हो। र तपाईले एउटा स्टेटफुलसेटमा एउटा टेम्प्लेट प्रयोग गरेर धेरै पोडहरू सुरु गर्न सक्नुहुन्छ। र यहाँ मुख्य वाक्यांश "एउटा टेम्प्लेटको लागि धेरै पोडहरू" हो।

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

तर यदि हामीले कार्य एक्स्ट्रापोलेट गर्छौं र भन्यौं कि हामी पूर्ण रूपमा विषम क्लस्टर बनाउन चाहन्छौं र हामी रोलिङ अपडेट प्रयोग गरेर पुरानो संस्करणबाट नयाँ संस्करणमा परिवर्तन गर्न चाहँदैनौं, तर हामी दुवै सर्तहरूमा एक विषम क्लस्टर सिर्जना गर्न चाहन्छौं। ClickHouse को विभिन्न संस्करणहरू र विभिन्न भण्डारणको सन्दर्भमा। हामी चाहन्छौं, उदाहरणका लागि, केही प्रतिकृतिहरू छुट्टै डिस्कहरूमा बनाउन, ढिलोमा, सामान्यतया, पूर्ण रूपमा एक विषम क्लस्टर निर्माण गर्न। र तथ्यको कारणले कि StatefulSet ले एउटा टेम्प्लेटबाट मानकीकृत समाधान बनाउँछ, त्यहाँ यो गर्ने कुनै तरिका छैन।

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

व्यवहारिक समस्याहरूमा फर्कौं। हाम्रो क्लस्टरमा हामीले प्रयोगकर्ताहरूलाई कन्फिगर गर्न आवश्यक छ, अर्थात्। तपाईंले Kubernetes मा ClickHouse को केहि कन्फिगरेसन गर्न आवश्यक छ। अपरेटरले यसका लागि सबै सम्भावनाहरू प्रदान गर्दछ।

हामीले चाहेको कुरा सिधै YAML मा लेख्न सक्छौं। सबै कन्फिगरेसन विकल्पहरू यस YAML बाट क्लिकहाउस कन्फिगरेसनहरूमा सिधै म्याप गरिएका छन्, जुन त्यसपछि क्लस्टरमा वितरण गरिन्छ।

तपाईं यसलाई यसरी लेख्न सक्नुहुन्छ। यो उदाहरण को लागी हो। पासवर्ड इन्क्रिप्ट गर्न सकिन्छ। बिल्कुल सबै क्लिकहाउस कन्फिगरेसन विकल्पहरू समर्थित छन्। यहाँ एउटा उदाहरण मात्र हो।

क्लस्टर कन्फिगरेसन कन्फिगम्यापको रूपमा वितरण गरिएको छ। अभ्यासमा, कन्फिगम्याप अपडेट तुरुन्तै देखा पर्दैन, त्यसैले यदि क्लस्टर ठूलो छ भने, कन्फिगरेसन पुश गर्ने प्रक्रियाले केही समय लिन्छ। तर यो सबै प्रयोग गर्न धेरै सुविधाजनक छ।

कामलाई जटिल बनाऔं। क्लस्टर विकास हुँदैछ। हामी डेटा नक्कल गर्न चाहन्छौं। त्यो हो, हामीसँग पहिले नै दुईवटा शार्डहरू छन्, प्रत्येक एक प्रतिकृति, र प्रयोगकर्ताहरू कन्फिगर गरिएका छन्। हामी बढ्दैछौं र प्रतिकृति गर्न चाहन्छौं।

हामीलाई प्रतिकृतिको लागि के चाहिन्छ?

हामीलाई ZooKeeper चाहिन्छ। ClickHouse मा, ZooKeeper को प्रयोग गरेर प्रतिकृति बनाइन्छ। ZooKeeper आवश्यक छ ताकि विभिन्न क्लिकहाउस प्रतिकृतिहरू कुन क्लिकहाउसमा कुन डाटा ब्लकहरू छन् भन्ने कुरामा सहमति छ।

ZooKeeper जो कोही द्वारा प्रयोग गर्न सकिन्छ। यदि उद्यमसँग बाह्य ZooKeeper छ भने, यसलाई प्रयोग गर्न सकिन्छ। यदि होइन भने, तपाइँ यसलाई हाम्रो भण्डारबाट स्थापना गर्न सक्नुहुन्छ। त्यहाँ एक स्थापनाकर्ता छ जसले यो सबै कुरालाई सजिलो बनाउँछ।

र सम्पूर्ण प्रणालीको अन्तरक्रिया रेखाचित्र यसरी बाहिर निस्कन्छ। हामीसँग प्लेटफर्मको रूपमा Kubernetes छ। यसले ClickHouse अपरेटरलाई कार्यान्वयन गर्छ। मैले यहाँ ZooKeeper को चित्रण गरें। र अपरेटरले ClickHouse र ZooKeeper दुवैसँग अन्तरक्रिया गर्दछ। अर्थात्, अन्तरक्रिया परिणामहरू।

र K8s मा डाटा सफलतापूर्वक नक्कल गर्न ClickHouse को लागि यो सबै आवश्यक छ।

अब कार्य आफैलाई हेरौं, प्रतिकृतिको लागि प्रकट कस्तो देखिन्छ।

हामीले हाम्रो घोषणापत्रमा दुई खण्डहरू थप्दैछौं। पहिलो हो जहाँ ZooKeeper प्राप्त गर्ने, जुन या त Kubernetes भित्र वा बाहिरी हुन सक्छ। यो केवल एक विवरण हो। र हामी प्रतिकृतिहरू अर्डर गर्छौं। ती। हामी दुई प्रतिकृतिहरू चाहन्छौं। कुलमा, हामीसँग आउटपुटमा 4 पोडहरू हुनुपर्छ। हामी भण्डारणको बारेमा सम्झन्छौं, यो केहि पछि फिर्ता आउनेछ। भण्डारण एउटा छुट्टै कथा हो।

यो यस्तै थियो।

यस्तो बन्छ। प्रतिकृतिहरू थपिएका छन्। चौथो एक फिट भएन, हामी विश्वास गर्छौं कि त्यहाँ धेरै हुन सक्छ। र ZooKeeper छेउमा थपिएको छ। योजनाहरु जटिल बन्दै गएका छन् ।

र यो अर्को कार्य थप्ने समय हो। हामी निरन्तर भण्डारण थप्नेछौं।

निरन्तर भण्डारणको लागि हामीसँग विभिन्न विकल्पहरू छन्।

यदि हामी क्लाउड प्रदायकमा चलिरहेका छौं, उदाहरणका लागि, अमेजन, गुगल प्रयोग गर्दै, तब क्लाउड भण्डारण प्रयोग गर्ने ठूलो प्रलोभन छ। यो धेरै सुविधाजनक छ, यो राम्रो छ।

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

क्लाउड भण्डारणको बारेमा हामीसँग के छ हेरौं।

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

र त्यहाँ एक कमजोरी छ। केहि को लागी, यो एक गैर-महत्वपूर्ण कमजोरी हो। निस्सन्देह, त्यहाँ केही प्रदर्शन मुद्दाहरू हुनेछ। यो प्रयोग गर्न धेरै सुविधाजनक र भरपर्दो छ, तर त्यहाँ केही सम्भावित प्रदर्शन कमजोरीहरू छन्।

र किनभने क्लिकहाउसले विशेष गरी उत्पादकत्वमा ध्यान केन्द्रित गर्दछ, कसैले यो पनि भन्न सक्छ कि यसले गर्न सक्ने सबै चीजहरू निचोड्छ, त्यसैले धेरै ग्राहकहरूले अधिकतम उत्पादकता निचोड गर्ने प्रयास गर्छन्।

र यसको अधिकतम लाभ लिन, हामीलाई स्थानीय भण्डारण चाहिन्छ।

Kubernetes ले Kubernetes मा स्थानीय भण्डारण प्रयोग गर्नका लागि तीन सारहरू प्रदान गर्दछ। यो:

• EmptyDir
• HostPath।
• स्थानीय

तिनीहरू कसरी फरक छन् र तिनीहरू कसरी समान छन् हेरौं।

पहिलो, सबै तीन दृष्टिकोणहरूमा हामीसँग भण्डारण छ - यी स्थानीय डिस्कहरू हुन् जुन समान भौतिक k8s नोडमा अवस्थित छन्। तर तिनीहरूसँग केही भिन्नताहरू छन्।

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

अभ्यासमा, डकरले आफ्नो मार्गमा कतै अस्थायी फोल्डर सिर्जना गर्दछ र यसलाई लामो ह्यास भन्छ। र यसलाई पहुँच गर्न एक इन्टरफेस प्रदान गर्दछ।

यो कार्यसम्पादन अनुसार कसरी हुनेछ? यसले स्थानीय डिस्क गतिमा काम गर्नेछ, अर्थात्। यो तपाईंको स्क्रूमा पूर्ण पहुँच हो।

तर यो मामला यसको कमजोरी छ। यस मामिलामा पर्सिस्टेन्ट एकदमै शंकास्पद छ। पहिलो पटक डकर कन्टेनरहरूसँग सर्छ, पर्सिस्टेन्ट हराएको छ। यदि Kubernetes ले यो पोडलाई कुनै कारणले अर्को डिस्कमा सार्न चाहन्छ भने, डाटा हराउनेछ।

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

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

यो विधिको फाइदाहरू छन्। यो पहिले नै एक वास्तविक स्थायी छ, र त्यसमा एक क्लासिक। हामीसँग केहि ठेगानामा डिस्कमा डाटा रेकर्ड हुनेछ।

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

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

तर हामी मात्र होइन जसलाई यो आवश्यकता चाहिन्छ, त्यसैले कुबेरनेटका सज्जनहरूले पनि बुझ्छन् कि मानिसहरू भौतिक डिस्कहरूमा पहुँच गर्न चाहन्छन्, त्यसैले उनीहरूले तेस्रो तह प्रदान गर्छन्।

यसलाई स्थानीय भनिन्छ। अघिल्लो स्लाइडबाट व्यावहारिक रूपमा कुनै भिन्नता छैन। हामीले यी पोडहरू नोडबाट नोडमा स्थानान्तरण गर्न नसक्ने कुरा म्यानुअल रूपमा पुष्टि गर्नु अघि मात्र आवश्यक थियो, किनकि तिनीहरू स्थानीय भौतिक डिस्कमा केही मार्गमा जोडिएको हुनुपर्छ, तर अब यो सबै ज्ञान कुबेरनेटमा नै समेटिएको छ। र यो कन्फिगर गर्न धेरै सजिलो हुन जान्छ।

हाम्रो व्यावहारिक समस्यामा फर्कौं। YAML टेम्प्लेटमा फर्कौं। यहाँ हामीसँग वास्तविक भण्डारण छ। हामी यसमा फर्केका छौं। हामीले k8s मा जस्तै क्लासिक VolumeClaim टेम्प्लेट सेट गर्यौं। र हामी कस्तो प्रकारको भण्डारण चाहन्छौं भनेर वर्णन गर्छौं।

यस पछि, k8s भण्डारण अनुरोध गर्नेछ। हामीलाई स्टेटफुलसेटमा आवंटित गर्नेछ। र अन्तमा यो ClickHouse को निपटान मा हुनेछ।

हामीसँग यो योजना थियो। हाम्रो निरन्तर भण्डारण रातो थियो, जसले यो गर्न आवश्यक छ भनेर संकेत गरेको देखिन्छ।

अनि हरियो बन्छ। अब k8s क्लस्टर योजनामा ​​ClickHouse पूर्ण रूपमा फाइनल भएको छ। हामीसँग शार्डहरू, प्रतिकृतिहरू, चिडियाखानाहरू छन्, हामीसँग वास्तविक पर्सिस्टेन्ट छ, जुन कुनै न कुनै रूपमा लागू हुन्छ। योजना पहिले नै पूर्ण रूपमा सञ्चालनमा छ।

हामी बाँच्न जारी छ। हाम्रो क्लस्टर विकास भइरहेको छ। र एलेक्सी प्रयास गर्दछ, र क्लिकहाउसको नयाँ संस्करण जारी गर्दछ।

एउटा व्यावहारिक कार्य उठ्छ - हाम्रो क्लस्टरमा ClickHouse को नयाँ संस्करण परीक्षण गर्न। र, स्वाभाविक रूपमा, तपाईं यो सबै रोल आउट गर्न चाहनुहुन्न; तपाईं टाढाको कुनामा कतै एउटा प्रतिकृतिमा नयाँ संस्करण राख्न चाहानुहुन्छ, र हुनसक्छ एउटा नयाँ संस्करण होइन, तर एकैचोटि दुई, किनभने तिनीहरू प्राय: बाहिर आउँछन्।

हामी यस बारे के भन्न सक्छौं?

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

अलि गहिरो भित्र जाऔं। यस अघि, हामीले क्लिकहाउस-अपरेटरले क्लिकहाउसको विशिष्टताको सम्बन्धमा कसरी काम गर्छ भन्ने बारे कुरा गर्यौं।

अब म कुनै पनि अपरेटरले सामान्य रूपमा कसरी काम गर्छ, साथै यसले K8s सँग कसरी अन्तरक्रिया गर्छ भन्ने बारेमा केही शब्दहरू भन्न चाहन्छु।

पहिले K8s संग अन्तरक्रिया हेरौं। हामीले kubectl लागू गर्दा के हुन्छ? हाम्रा वस्तुहरू API मार्फत etcd मा देखा पर्छन्।

उदाहरण को लागी, आधारभूत Kubernetes वस्तुहरु: pod, StatefulSet, सेवा, र यति तल सूची।

एकै समयमा, भौतिक केहि पनि छैन। यी वस्तुहरू क्लस्टरमा भौतिक बनाइनुपर्छ।

यस उद्देश्यको लागि, एक नियन्त्रक देखा पर्दछ। नियन्त्रक एक विशेष k8s कम्पोनेन्ट हो जसले यी विवरणहरूलाई साकार पार्न सक्छ। शारीरिक रूपमा कसरी र के गर्ने भनेर उहाँ जान्नुहुन्छ। उसलाई थाहा छ कसरी कन्टेनरहरू चलाउने, सर्भरले काम गर्नको लागि त्यहाँ के कन्फिगर गर्न आवश्यक छ।

र यसले K8s मा हाम्रा वस्तुहरूलाई भौतिक बनाउँछ।

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

तर K8s सँग निम्न राम्रो कुरा छ। हामी यो जटिल संस्था जस्तो कतै होस् भन्ने चाहन्छौं जसमा हाम्रो क्लस्टर पोडहरू र स्टेटफुलसेटबाट भेला हुनेछन्।

र यसको लागि के गर्न आवश्यक छ? पहिले, अनुकूलन संसाधन परिभाषा तस्वीरमा आउँछ। यो के हो? यो K8s को लागि एक विवरण हो, कि तपाइँसँग एक थप डेटा प्रकार हुनेछ, कि हामी पोड, StatefulSet मा अनुकूलन स्रोत थप्न चाहन्छौं, जुन भित्र जटिल हुनेछ। यो डाटा संरचना को एक विवरण हो।

हामी त्यहाँ kubectl apply मार्फत पनि पठाउँछौं। Kubernetes खुसीसाथ लिए।

र अब हाम्रो भण्डारणमा, etcd मा रहेको वस्तुले ClickHouseInstallation भनिने कस्टम स्रोत रेकर्ड गर्ने अवसर छ।

तर अहिलेको लागि थप केही हुने छैन। त्यो हो, यदि हामीले अब YAML फाइल सिर्जना गर्यौं जुन हामीले शार्डहरू र प्रतिकृतिहरू वर्णन गरेर हेरेका थियौं र "kubectl लागू" भन्यौं, तब Kubernetes ले यसलाई स्वीकार गर्नेछ, etcd मा राख्नेछ र भन्नेछ: "राम्रो, तर मलाई के गर्ने थाहा छैन। यसको साथ। मलाई ClickHouseInstallation कसरी कायम गर्ने थाहा छैन।"

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

र अर्को तरिकामा यसलाई अपरेटर भनिन्छ। मैले यसलाई विशेष रूपमा यहाँ Kubernetes को रूपमा समावेश गरेको छु, किनभने यो K8s बाहिर पनि कार्यान्वयन गर्न सकिन्छ। प्रायजसो, निस्सन्देह, सबै अपरेटरहरू Kubernetes मा निष्पादित हुन्छन्, तर यसलाई बाहिर खडा हुनबाट केही पनि रोक्दैन, त्यसैले यहाँ विशेष रूपमा बाहिर सारियो।

र बदलामा, अनुकूलन नियन्त्रक, अपरेटर पनि भनिन्छ, API मार्फत Kubernetes सँग अन्तरक्रिया गर्दछ। यसलाई पहिले नै थाहा छ कि कसरी API सँग अन्तरक्रिया गर्ने। र उसलाई पहिले नै थाहा छ कि हामीले कस्टम स्रोतबाट बनाउन चाहने जटिल सर्किटलाई कसरी साकार गर्ने। यो ठ्याक्कै अपरेटर के गर्छ।

अपरेटरले कसरी काम गर्छ? उसले यो कसरी गर्छ भनेर हेर्नको लागि दायाँ तिर हेरौं। अपरेटरले यी सबैलाई कसरी साकार गर्छ र K8s सँग थप अन्तरक्रिया कसरी हुन्छ भन्ने कुरा पत्ता लगाउनुहोस्।

एक अपरेटर एक कार्यक्रम हो। उनी घटना उन्मुख छिन् । अपरेटरले Kubernetes API प्रयोग गरेर घटनाहरूको सदस्यता लिन्छ। Kubernetes API मा प्रविष्टि बिन्दुहरू छन् जहाँ तपाइँ घटनाहरूको सदस्यता लिन सक्नुहुन्छ। र यदि K8s मा केहि परिवर्तन हुन्छ, तब Kubernetes ले सबैलाई घटनाहरू पठाउँछ, अर्थात्। यस API पोइन्टको सदस्यता लिने जो कोहीले सूचनाहरू प्राप्त गर्नेछन्।

अपरेटरले घटनाहरूको सदस्यता लिन्छ र केही प्रकारको प्रतिक्रिया गर्नुपर्दछ। यसको कार्य उदीयमान घटनाहरूको जवाफ दिनु हो।

घटनाहरू निश्चित अद्यावधिकहरूद्वारा उत्पन्न हुन्छन्। ClickHouseInstallation को विवरण सहित हाम्रो YAML फाइल आइपुग्छ। उनी क्युबेक्टल आवेदन मार्फत etcd गए। त्यहाँ एउटा घटना सुरु भयो, र परिणाम स्वरूप यो घटना ClickHouse-operator मा आयो। अपरेटरले यो विवरण प्राप्त गर्यो। र उसले केहि गर्नु पर्छ। यदि ClickHouseInstallation वस्तुको लागि अद्यावधिक आइपुगेको छ भने, तपाईंले क्लस्टर अद्यावधिक गर्न आवश्यक छ। र अपरेटरको काम क्लस्टर अपडेट गर्नु हो।

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

यस योजना अनुसार, उसले पोडहरू, सेवाहरू, अर्थात् वास्तविक बनाउनको लागि यो संरचना भित्र पकाउन थाल्छ। उसको मुख्य काम के हो। Kubernetes मा ClickHouse क्लस्टर बनाउने तरिका यो हो।

अब यस्तो रोचक कुरा छुनुहोस्। यो Kubernetes र अपरेटर बीच जिम्मेवारी को विभाजन हो, अर्थात्। Kubernetes के गर्छ, अपरेटरले के गर्छ, र उनीहरूले एकअर्कासँग कसरी अन्तरक्रिया गर्छन्।

Kubernetes प्रणाली चीजहरूको लागि जिम्मेवार छ, अर्थात्। प्रणाली-स्कोपको रूपमा व्याख्या गर्न सकिने वस्तुहरूको आधारभूत सेटको लागि। Kubernetes लाई पोडहरू कसरी सुरु गर्ने, कन्टेनरहरू कसरी पुन: सुरु गर्ने, भोल्युमहरू कसरी माउन्ट गर्ने, कन्फिगम्यापसँग कसरी काम गर्ने भन्ने थाहा छ। सबै कुरा जसलाई प्रणाली भन्न सकिन्छ।

अपरेटरहरूले डोमेनहरूमा काम गर्छन्। प्रत्येक अपरेटर आफ्नै विषय क्षेत्र को लागी बनाइएको छ। हामीले यो क्लिकहाउसको लागि गर्यौं।

र अपरेटरले विषय क्षेत्रको सन्दर्भमा ठ्याक्कै अन्तरक्रिया गर्दछ, जस्तै प्रतिकृति थप्ने, रेखाचित्र बनाउने, अनुगमन सेटअप गर्ने। यसले विभाजनको परिणाम दिन्छ।

जब हामी प्रतिकृति कार्य थप्छौं तब जिम्मेवारीको यो विभाजन कसरी हुन्छ भन्ने व्यावहारिक उदाहरण हेरौं।

अपरेटरले कार्य प्राप्त गर्दछ - प्रतिकृति थप्नको लागि। अपरेटरले के गर्छ? अपरेटरले गणना गर्नेछ कि नयाँ स्टेटफुलसेट सिर्जना गर्न आवश्यक छ, जसमा त्यस्ता र त्यस्ता टेम्प्लेटहरू, भोल्युम दाबी, वर्णन गरिनुपर्छ।

उसले यो सबै तयार पार्छ र K8s मा पठाउँछ। उनी भन्छन् कि उसलाई कन्फिगम्याप, स्टेटफुलसेट, भोल्युम चाहिन्छ। Kubernetes काम गर्दै हुनुहुन्छ। उसले सञ्चालन गर्ने आधारभूत एकाइहरूलाई भौतिक बनाउँछ।

र त्यसपछि क्लिकहाउस-अपरेटर फेरि खेलमा आउँछ। उहाँसँग पहिले नै भौतिक पोड छ जसमा उसले पहिले नै केहि गर्न सक्छ। र क्लिकहाउस-अपरेटरले फेरि डोमेन सर्तहरूमा काम गर्दछ। ती। विशेष रूपमा क्लिकहाउस, क्लस्टरमा प्रतिकृति समावेश गर्नको लागि, तपाईंले पहिले, यो क्लस्टरमा अवस्थित डाटा स्किमा कन्फिगर गर्नुपर्छ। र, दोस्रो, यो प्रतिकृति अनुगमनमा समावेश हुनुपर्छ ताकि यो स्पष्ट रूपमा पत्ता लगाउन सकिन्छ। अपरेटरले पहिले नै यो कन्फिगर गरेको छ।

र त्यस पछि मात्र क्लिकहाउस आफै खेलमा आउँछ, अर्थात्। अर्को उच्च स्तरको संस्था। यो पहिले नै डाटाबेस हो। यसको आफ्नै उदाहरण छ, अर्को कन्फिगर गरिएको प्रतिकृति जुन क्लस्टरमा सामेल हुन तयार छ।

यो बाहिर जान्छ कि प्रतिकृति थप्दा कार्यान्वयन र जिम्मेवारी विभाजन को एक श्रृंखला धेरै लामो छ।

हामी हाम्रा व्यावहारिक कार्यहरू जारी राख्छौं। यदि तपाइँसँग पहिले नै क्लस्टर छ भने, तपाइँ कन्फिगरेसन माइग्रेट गर्न सक्नुहुन्छ।

हामीले यसलाई अवस्थित xml मा टाँस्न सक्ने गरी बनाएका छौं, जुन क्लिकहाउसले बुझ्दछ।

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

अर्को व्यावहारिक कार्य अनुगमन हो।

यदि हाम्रो क्लस्टर परिवर्तन भयो भने, हामीले आवधिक रूपमा अनुगमन कन्फिगर गर्न आवश्यक छ।

रेखाचित्र हेरौं। हामीले पहिले नै यहाँ हरियो तीरहरू हेरेका छौं। अब रातो तीरहरू हेरौं। यसरी हामी हाम्रो क्लस्टरलाई निगरानी गर्न चाहन्छौं। कसरी क्लिकहाउस क्लस्टरबाट मेट्रिक्स प्रोमेथियसमा पुग्छ, र त्यसपछि ग्राफानामा।

अनुगमन गर्न कठिनाइ के छ? किन यसलाई एक प्रकारको उपलब्धिको रूपमा प्रस्तुत गरिएको छ? कठिनाई गतिशीलता मा निहित छ। जब हामीसँग एउटा क्लस्टर छ र यो स्थिर छ, तब हामी एक पटक अनुगमन सेट अप गर्न सक्छौं र अब चिन्ता नगर्ने।

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

हाम्रो क्लस्टर कसरी विकास भयो? सुरुमा उनी यस्तै थिए ।

त्यसपछि उहाँ यस्तो हुनुहुन्थ्यो।

अन्तत: ऊ यस्तो भयो।

र अनुगमन स्वचालित रूपमा अपरेटर द्वारा गरिन्छ। प्रवेशको एकल बिन्दु।

र बाहिर निस्कँदा हामी Grafana ड्यासबोर्डमा हेर्छौं कि हाम्रो क्लस्टरको जीवन भित्र कसरी उम्लिरहेको छ।

वैसे, Grafana ड्यासबोर्ड पनि हाम्रो अपरेटरसँग सीधै स्रोत कोडमा वितरण गरिएको छ। तपाईं जडान र प्रयोग गर्न सक्नुहुन्छ। हाम्रो DevOps ले मलाई यो स्क्रिनसट दिनुभयो।

हामी अर्को कहाँ जान चाहन्छौं? यो:

• परीक्षण स्वचालन विकास गर्नुहोस्। मुख्य कार्य नयाँ संस्करणहरूको स्वचालित परीक्षण हो।
• हामी पनि साँच्चै ZooKeeper संग एकीकरण स्वचालित गर्न चाहन्छौं। र त्यहाँ ZooKeeper-operator संग एकीकृत गर्ने योजनाहरू छन्। ती। ZooKeeper को लागी एक अपरेटर लेखिएको छ र यो तार्किक छ कि दुई अपरेटरहरु एक अधिक सुविधाजनक समाधान निर्माण गर्न एकीकृत गर्न सुरु हुन्छ।
• हामी थप जटिल महत्त्वपूर्ण संकेतहरू गर्न चाहन्छौं।
• मैले हरियोमा हाइलाइट गरें कि हामी टेम्प्लेटहरूको विरासतमा पुग्दैछौं - DONE, अर्थात् अपरेटरको अर्को रिलीजको साथ हामीसँग टेम्प्लेटहरूको इनहेरिटेन्स हुनेछ। यो एक शक्तिशाली उपकरण हो जसले तपाईंलाई टुक्राहरूबाट जटिल कन्फिगरेसनहरू निर्माण गर्न अनुमति दिन्छ।
• र हामी जटिल कार्यहरूको स्वचालन चाहन्छौं। मुख्य भनेको रि-सार्डिङ हो।

केही मध्यवर्ती परिणामहरू हेरौं।

हामीले परिणामको रूपमा के पाउँछौं? र यो गर्न लायक छ कि छैन? डाटाबेसलाई Kubernetes मा तान्नु र सामान्य रूपमा अपरेटर र विशेष रूपमा Alitnity अपरेटर प्रयोग गर्ने प्रयास गर्न आवश्यक छ?

आउटपुटमा हामीले पाउँछौं:

• कन्फिगरेसन, डिप्लोइमेन्ट, र मर्मतसम्भारको महत्त्वपूर्ण सरलीकरण र स्वचालन।
• तुरुन्तै निर्मित अनुगमन।
• र जटिल परिस्थितिहरूको लागि प्रयोग गर्न तयार कोडिफाइड टेम्प्लेटहरू। प्रतिकृति थप्ने जस्ता कार्य म्यानुअल रूपमा गर्न आवश्यक छैन। अपरेटरले यो गर्छ।

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

जवाफ सबै ठीक छ! म विस्तृतमा जानेछैन, यो छुट्टै प्रतिवेदनको विषय हो।

तर TSBS जस्ता परियोजना छ। यसको मुख्य कार्य के हो? यो डाटाबेस प्रदर्शन परीक्षण हो। यो न्यानोसँग न्यानो, नरमलाई नरमसँग तुलना गर्ने प्रयास हो।

उसले कसरी काम गर्छ? एउटा डाटा सेट उत्पन्न हुन्छ। त्यसपछि डाटाको यो सेट परीक्षणको एउटै सेट प्रयोग गरेर विभिन्न डेटाबेसहरूमा चलाइन्छ। र प्रत्येक डाटाबेसले एक समस्या समाधान गर्छ जसरी यसलाई थाहा छ। र त्यसपछि तपाईं परिणाम तुलना गर्न सक्नुहुन्छ।

यसले पहिले नै डाटाबेसको ठूलो गुच्छा समर्थन गर्दछ। मैले तीनवटा मुख्य पहिचान गरेको छु। यो:

• TimescaleDB।
• InfluxDB।
• क्लिक हाउस।

अर्को समान समाधानसँग तुलना पनि गरिएको थियो। RedShift संग तुलना। तुलना Amazon मा गरिएको थियो। क्लिकहाउस पनि यस मामिलामा सबै भन्दा अगाडि छ।

मैले भनेको कुराबाट के निष्कर्ष निकाल्न सकिन्छ?

• Kubernetes मा DB सम्भव छ। सायद कुनै पनि सम्भव छ, तर समग्रमा यो सम्भव छ जस्तो देखिन्छ। Kubernetes मा ClickHouse निश्चित रूपमा हाम्रो अपरेटरको सहयोगमा सम्भव छ।
• अपरेटरले स्वचालित प्रक्रियाहरूलाई मद्दत गर्दछ र वास्तवमै जीवनलाई सजिलो बनाउँदछ।
• प्रदर्शन सामान्य छ।
• र यो हामीलाई लाग्छ कि यो प्रयोग गर्न सकिन्छ र हुनुपर्छ।

खुला स्रोत - हामीसँग सामेल हुनुहोस्!

मैले पहिले नै भनेझैं, अपरेटर पूर्ण रूपमा खुला स्रोत उत्पादन हो, त्यसैले यो धेरै राम्रो हुनेछ यदि अधिकतम संख्यामा मानिसहरूले यसलाई प्रयोग गरे। हामीसँग सामेल हुनुहोस्! हामी तपाईं सबैको लागि पर्खिरहेका छौं!

धन्यवाद सबै!

तपाईंका प्रश्नहरू

रिपोर्ट को लागी धन्यवाद! मेरो नाम एन्टोन हो। म SEMrush बाट हुँ। लगिङ गर्दा के भयो भनेर सोचिरहेको छु। हामीले निगरानीको बारेमा सुन्छौं, तर लगिङको बारेमा केही छैन, यदि हामी सम्पूर्ण क्लस्टरको बारेमा कुरा गर्छौं। उदाहरणका लागि, हामीले हार्डवेयरमा क्लस्टर खडा गरेका छौं। र हामी केन्द्रीकृत लगिङ प्रयोग गर्छौं, तिनीहरूलाई मानक माध्यमहरू प्रयोग गरेर साझा ढेरमा सङ्कलन गर्छौं। र त्यसपछि त्यहाँबाट हामी डेटा पाउँछौं जुन हामीलाई रुचि छ।

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

नमस्ते! रिपोर्ट को लागी धन्यवाद! मसँग निरन्तर भोल्युमहरूसँग सम्बन्धित मानक प्रश्न छ। जब हामीले यो अपरेटरसँग कन्फिगरेसन सिर्जना गर्छौं, अपरेटरले कुन नोडमा हामीसँग विशेष डिस्क वा फोल्डर जोडिएको छ भनेर कसरी निर्धारण गर्छ? हामीले पहिले उहाँलाई बुझाउनु पर्छ कि कृपया हाम्रो क्लिकहाउसलाई डिस्क भएका यी नोडहरूमा राख्नुहोस्?

जहाँसम्म मैले बुझेको छु, यो प्रश्न स्थानीय भण्डारणको निरन्तरता हो, विशेष गरी यसको होस्टपाथ भाग। यो सम्पूर्ण प्रणालीलाई व्याख्या गर्नु जस्तै हो कि पोडलाई यस्तो र यस्तो नोडमा सुरू गर्न आवश्यक छ, जसमा हामीसँग भौतिक रूपमा जडान गरिएको डिस्क छ, जुन त्यस्ता र त्यस्ता मार्गमा माउन्ट गरिएको छ। यो एक पूरै खण्ड हो जुन मैले धेरै सतही रूपमा छुयो किनभने त्यहाँ उत्तर एकदम ठूलो छ।

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

र यो तेस्रो विकल्प हो, स्थानीय, जसले यसलाई अलि सजिलो बनाउन मद्दत गर्दछ। मैले पहिले नै जोड दिएझैं, यो ट्युनिङमा मेहनती काम हो, जसले अन्ततः अधिकतम प्रदर्शन प्राप्त गर्न मद्दत गर्दछ।

मसँग यससँग सम्बन्धित दोस्रो प्रश्न छ। Kubernetes यस तरिकाले डिजाइन गरिएको थियो कि हामीले नोड गुमाए वा नगरे पनि यसले हामीलाई फरक पार्दैन। यदि हामीले हाम्रो शार्ड झुण्डिएको नोड गुमायौं भने हामीले के गर्नुपर्छ?

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

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

परिणाम स्वरूप के हो? डाटा हराएको छैन भनेर सुनिश्चित गर्न DevOps जिम्मेवार छ। उसले प्रतिकृति सही रूपमा सेट अप गर्नुपर्छ र प्रतिकृति चलिरहेको छ भनेर सुनिश्चित गर्नुपर्छ। ClickHouse स्तरको प्रतिकृतिमा डुप्लिकेट डाटा हुनुपर्छ। यो अपरेटरले समाधान गर्ने समस्या होइन। र कुबर्नेट्स आफैले समाधान गर्ने समस्या होइन। यो ClickHouse स्तरमा छ।

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

रिपोर्ट को लागी धन्यवाद! जब सबै प्रकारका नराम्रा चीजहरू हुन्छन्, अपरेटर क्र्यास हुन्छ र पुन: सुरु हुन्छ, र त्यस क्षणमा घटनाहरू आइपुग्छन्, के तपाइँ यसलाई कुनै न कुनै रूपमा ह्यान्डल गर्नुहुन्छ?

के हुन्छ यदि अपरेटर क्र्यास भयो र पुन: सुरु भयो, हैन?

हो। र त्यो क्षण घटनाहरू आइपुगे।

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

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

के तपाईं Ingress को कुरा गर्दै हुनुहुन्छ?

हो, इन्ग्रेसलाई ह्याप्रोक्सीसँग बदल्नुहोस्। haproxy मा तपाईंले क्लस्टरको टोपोलोजी निर्दिष्ट गर्न सक्नुहुन्छ जहाँ यसको प्रतिकृतिहरू छन्।

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

पहिले नै छ।

राम्रो। हामी कुनै पनि सुझाव को लागी खुला छ। र haproxy todo सूचीमा थपिएको छ। Todo सूची बढ्दै छ, अझै संकुचित छैन। तर यो राम्रो छ, यसको मतलब उत्पादन माग छ।

स्रोत: www.habr.com