Kubernetes मा काफ्का राम्रो छ?

अभिवादन, Habr!

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

परिचय

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

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

केही मानिसहरूलाई लाग्छ कि यदि तपाईंले Kubernetes लाई स्टेटफुल वर्कलोडमा रोल गर्नुभयो भने, यो RDS लाई प्रतिद्वन्द्वी गर्ने पूर्ण रूपमा व्यवस्थित डाटाबेस बन्छ। यो गलत हो। हुनसक्छ, यदि तपाईंले पर्याप्त मेहनत गर्नुभयो भने, थप कम्पोनेन्टहरू थप्नुभयो र SRE इन्जिनियरहरूको टोलीलाई आकर्षित गर्नुभयो भने, तपाईंले Kubernetes को शीर्षमा RDS निर्माण गर्न सक्षम हुनुहुनेछ।

Kubernetes मा स्टेटफुल वर्कलोडहरू चलाउँदा सबैले अत्यधिक सावधानी अपनाउन म सधैं सिफारिस गर्छु। "म Kubernetes मा स्टेटफुल वर्कलोड चलाउन सक्छु" भनेर सोध्ने धेरैजसो व्यक्तिहरूसँग Kubernetes सँग पर्याप्त अनुभव हुँदैन, र प्रायः उनीहरूले सोध्ने कामको बोझको साथ।

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

पूरा हुने समय

आधारभूत कुराको बारेमा कुरा गरौं - रनटाइम वातावरण नै

प्रक्रिया

काफ्का दलालहरू CPU अनुकूल छन्। TLS ले केही ओभरहेड परिचय गराउन सक्छ। यद्यपि, काफ्का क्लाइन्टहरू इन्क्रिप्शन प्रयोग गर्दा बढी CPU गहन हुन सक्छन्, तर यसले दलालहरूलाई असर गर्दैन।

स्मृति

काफ्का दलालहरूले स्मृति खाए। JVM हिप साइज सामान्यतया 4-5 GB मा सीमित हुन्छ, तर काफ्काले पृष्ठ क्यास धेरै धेरै प्रयोग गरेको हुनाले तपाईंलाई धेरै प्रणाली मेमोरी चाहिन्छ। Kubernetes मा, कन्टेनर स्रोत सेट गर्नुहोस् र तदनुसार सीमा अनुरोध गर्नुहोस्।

डाटा स्टोर

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

यसकारण तपाईले लामो अवधिको डाटा भण्डारण प्रयोग गर्नुपर्छ। यसलाई XFS फाइल प्रणाली वा, अझ स्पष्ट रूपमा, ext4 सँग गैर-स्थानीय दीर्घकालीन भण्डारण हुन दिनुहोस्। NFS प्रयोग नगर्नुहोस्। मैले तिमीलाई चेतावनी दिएँ। NFS संस्करण v3 वा v4 काम गर्दैन। छोटकरीमा, काफ्का ब्रोकरले NFS मा "स्टुपिड रिनेम" समस्याको कारण डाटा डाइरेक्टरी मेटाउन सकेन भने क्र्यास हुनेछ। यदि मैले तपाईलाई अझै विश्वस्त गरेको छैन भने, धेरै सावधानीपूर्वक यो लेख पढ्नुहोस्। डाटा स्टोर गैर-स्थानीय हुनुपर्छ ताकि Kubernetes ले पुन: सुरु वा स्थानान्तरण पछि थप लचिलो रूपमा नयाँ नोड छनौट गर्न सक्छ।

सञ्जाल

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

कन्फिगरेसन

नियमित घोषणापत्रहरू

Kubernetes वेबसाइट छ धेरै राम्रो गाइड manifests प्रयोग गरेर ZooKeeper कसरी कन्फिगर गर्ने बारे। ZooKeeper काफ्काको अंश भएको हुनाले, यहाँ Kubernetes को अवधारणाहरू लागू हुने बारे परिचित हुनको लागि यो राम्रो ठाउँ हो। एकचोटि तपाईंले यो बुझ्नुभयो भने, तपाईंले काफ्का क्लस्टरसँग समान अवधारणाहरू प्रयोग गर्न सक्नुहुन्छ।

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

मा योलियन Kubernetes मा Kafka संग सुरु गर्न मद्दत गर्न manifests को एक व्यापक सेट प्रदान गर्दछ।

हेलम चार्टहरू

हेल्म कुबेरनेटका लागि प्याकेज प्रबन्धक हो जसलाई ओएस प्याकेज प्रबन्धकहरू जस्तै yum, apt, Homebrew वा Chocolatey सँग तुलना गर्न सकिन्छ। यसले हेल्म चार्टहरूमा वर्णन गरिएको पूर्वनिर्धारित सफ्टवेयर प्याकेजहरू स्थापना गर्न सजिलो बनाउँछ। राम्रोसँग चयन गरिएको हेल्म चार्टले Kubernetes मा काफ्का प्रयोग गर्नका लागि सबै प्यारामिटरहरू कसरी ठीकसँग कन्फिगर गर्ने भन्ने कठिन कार्यलाई सजिलो बनाउँछ। त्यहाँ धेरै काफ्का रेखाचित्रहरू छन्: आधिकारिक एक अवस्थित छ इन्क्यूबेटर अवस्थामा, त्यहाँबाट एक छ मिश्रित, एक थप - बाट Bitnami.

अपरेटरहरू

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

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

उत्पादकता

तपाईंको काफ्का उदाहरण बेन्चमार्क गरेर प्रदर्शन परीक्षण गर्न महत्त्वपूर्ण छ। त्यस्ता परीक्षणहरूले तपाईंलाई समस्याहरू आउनु अघि सम्भावित बाधाहरू फेला पार्न मद्दत गर्नेछ। सौभाग्य देखि, काफ्काले पहिले नै दुई प्रदर्शन परीक्षण उपकरणहरू प्रदान गर्दछ: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh। तिनीहरूलाई सक्रिय प्रयोग गर्नुहोस्। सन्दर्भको लागि, तपाइँ मा वर्णन गरिएका परिणामहरू सन्दर्भ गर्न सक्नुहुन्छ यो पोस्ट जे क्रेप्स, वा फोकस गर्नुहोस् यो समीक्षा स्टेफन मारेक द्वारा अमेजन MSK।

सञ्चालनहरू

निगरानी गर्दै

प्रणालीमा पारदर्शिता धेरै महत्त्वपूर्ण छ - अन्यथा तपाईले बुझ्न सक्नुहुन्न कि यसमा के भइरहेको छ। आज क्लाउड नेटिभ स्टाइलमा मेट्रिक्स-आधारित निगरानी प्रदान गर्ने ठोस टूलकिट छ। यस उद्देश्यका लागि दुई लोकप्रिय उपकरणहरू प्रोमेथियस र ग्राफाना हुन्। Prometheus ले सबै जाभा प्रक्रियाहरु (Kafka, Zookeeper, Kafka Connect) बाट JMX निर्यातक प्रयोग गरेर मेट्रिक्स संकलन गर्न सक्छ - सरल तरिकामा। यदि तपाईंले cAdvisor मेट्रिकहरू थप्नुभयो भने, तपाईंले Kubernetes मा स्रोतहरू कसरी प्रयोग गरिन्छ भनेर अझ राम्ररी बुझ्न सक्नुहुन्छ।

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

स्रोत: streamzi.io/docs/master/#kafka_dashboard

यो सबै ग्राहक अनुगमन (उपभोक्ता र उत्पादकहरूमा मेट्रिक्स), साथै विलम्बता निगरानी (यसको लागि त्यहाँ छ) को साथ पूरक गर्न राम्रो हुनेछ। बुरो) र अन्त-देखि-अन्त निगरानी - यो प्रयोगको लागि काफ्का मनिटर.

लगिङ

लगिङ अर्को महत्वपूर्ण काम हो। सुनिश्चित गर्नुहोस् कि तपाईंको काफ्का स्थापनामा सबै कन्टेनरहरू लग इन छन् stdout и stderr, र यो पनि सुनिश्चित गर्नुहोस् कि तपाइँको Kubernetes क्लस्टरले केन्द्रीय लगिङ पूर्वाधारमा सबै लगहरू जम्मा गर्छ, जस्तै। Elasticsearch.

कार्यात्मक परीक्षण

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

अपडेटहरू रोल आउट गर्दै

स्टेटफुलसेटहरूले स्वचालित अद्यावधिकहरूलाई समर्थन गर्दछ: यदि तपाईंले रोलिङअपडेट रणनीति चयन गर्नुभयो भने, काफ्का अन्तर्गत प्रत्येकलाई पालैपालो अद्यावधिक गरिनेछ। यस तरिकाले, डाउनटाइम शून्यमा घटाउन सकिन्छ।

स्केलिंग

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

प्रशासन

तपाइँको काफ्का क्लस्टर प्रशासित गर्न सम्बन्धित कार्यहरू, जस्तै विषयहरू सिर्जना गर्ने र क्षेत्रहरू पुन: नियुक्त गर्ने, तपाइँको पोडहरूमा कमांड लाइन इन्टरफेस खोलेर अवस्थित शेल लिपिहरू प्रयोग गरेर गर्न सकिन्छ। यद्यपि, यो समाधान धेरै सुन्दर छैन। Strimzi ले फरक अपरेटर प्रयोग गरी विषयहरू व्यवस्थापन गर्न समर्थन गर्दछ। यहाँ सुधारको लागि केहि ठाउँ छ।

जगेडा र पुनर्स्थापना

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

निष्कर्षमा

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

स्रोत: www.habr.com