कुबर्नेट्सवरील काफ्का चांगला आहे का?

नमस्कार, हॅब्र!

एकेकाळी, आम्ही रशियन मार्केटमध्ये या विषयाची ओळख करून देणारे पहिले होतो काफका आणि सुरू ठेवा ट्रॅक त्याच्या विकासासाठी. विशेषतः, आम्हाला काफ्का आणि यांच्यातील संवादाचा विषय सापडला कुबेरनेट्स. निरीक्षण करण्यायोग्य (आणि खूप काळजीपूर्वक) लेख हा विषय ग्वेन शापिरा यांच्या लेखकत्वाखाली गेल्या वर्षी ऑक्टोबरमध्ये Confluent ब्लॉगवर प्रकाशित झाला होता. आज आम्‍ही तुमच्‍या लक्ष वेधून घेण्‍याच्‍या एप्रिलमध्‍ये जोहान गेगरच्‍या एका अलिकडच्‍या लेखाकडे वळू इच्छितो, जो शीर्षकात प्रश्‍नचिन्ह नसले तरीही, मजकुरासोबत मजकुरासह मनोरंजक दुव्‍यांसह विषयाचे अधिक ठोसपणे परीक्षण करतो. जर तुम्हाला शक्य असेल तर कृपया आम्हाला “अराजक माकड” चे विनामूल्य भाषांतर क्षमा करा!

परिचय

Kubernetes हे स्टेटलेस वर्कलोड हाताळण्यासाठी डिझाइन केलेले आहे. सामान्यतः, असे वर्कलोड मायक्रोसर्व्हिस आर्किटेक्चरच्या स्वरूपात सादर केले जातात, ते हलके असतात, क्षैतिजरित्या स्केल करतात, 12-घटक अनुप्रयोगांच्या तत्त्वांचे पालन करतात आणि सर्किट ब्रेकर्स आणि अराजक माकडांसह कार्य करू शकतात.

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

काही लोकांना असे वाटते की जर तुम्ही Kubernetes ला स्टेटफुल वर्कलोडमध्ये रोल केले तर तो RDS ला टक्कर देणारा पूर्णपणे व्यवस्थापित डेटाबेस बनतो. हे चुकीचे आहे. कदाचित, जर तुम्ही पुरेशी मेहनत केली, अतिरिक्त घटक जोडले आणि SRE अभियंत्यांची टीम आकर्षित केली, तर तुम्ही Kubernetes वर RDS तयार करू शकाल.

Kubernetes वर स्टेटफुल वर्कलोड चालवताना प्रत्येकाने अत्यंत सावधगिरी बाळगण्याची मी नेहमी शिफारस करतो. "मी Kubernetes वर स्टेटफुल वर्कलोड चालवू शकतो का" असे विचारणाऱ्या बहुतेक लोकांना कुबर्नेट्सचा पुरेसा अनुभव नसतो आणि अनेकदा ते विचारत असलेल्या वर्कलोडचाही अनुभव घेत नाहीत.

तर, तुम्ही काफ्काला कुबर्नेट्सवर चालवावे? काउंटर प्रश्न: काफ्का कुबर्नेट्सशिवाय चांगले काम करेल? म्हणूनच मला या लेखात काफ्का आणि कुबर्नेट्स एकमेकांना कसे पूरक आहेत आणि त्यांना एकत्र केल्याने कोणते नुकसान होऊ शकते यावर प्रकाश टाकायचा आहे.

पूर्ण होण्याची वेळ

चला मूलभूत गोष्टीबद्दल बोलूया - रनटाइम पर्यावरण स्वतः

प्रक्रिया

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

स्मृती

काफ्का दलाल स्मृती खातात. JVM हीपचा आकार सामान्यतः 4-5 GB पर्यंत मर्यादित असतो, परंतु काफ्का पेज कॅशे खूप मोठ्या प्रमाणात वापरत असल्याने तुम्हाला सिस्टम मेमरी देखील आवश्यक असेल. Kubernetes मध्ये, कंटेनर संसाधन सेट करा आणि त्यानुसार मर्यादांची विनंती करा.

डेटा स्टोअर

कंटेनरमधील डेटा स्टोरेज क्षणिक आहे - रीस्टार्ट केल्यावर डेटा गमावला जातो. काफ्का डेटासाठी तुम्ही व्हॉल्यूम वापरू शकता emptyDir, आणि प्रभाव समान असेल: तुमचा ब्रोकर डेटा पूर्ण झाल्यानंतर गमावला जाईल. तुमचे मेसेज अजूनही इतर ब्रोकरवर प्रतिकृती म्हणून साठवले जाऊ शकतात. म्हणून, रीस्टार्ट केल्यानंतर, अयशस्वी ब्रोकरने प्रथम सर्व डेटाची प्रतिकृती तयार करणे आवश्यक आहे आणि या प्रक्रियेस बराच वेळ लागू शकतो.

यामुळे तुम्ही दीर्घकालीन डेटा स्टोरेजचा वापर करावा. ते XFS फाइल प्रणालीसह किंवा अधिक स्पष्टपणे, ext4 सह स्थानिक नसलेले दीर्घकालीन स्टोरेज असू द्या. NFS वापरू नका. मी तुम्हाला सावध केले. NFS आवृत्त्या v3 किंवा v4 काम करणार नाहीत. थोडक्यात, NFS मधील "स्टुपिड रिनेम" समस्येमुळे काफ्का ब्रोकर डेटा निर्देशिका हटवू शकला नाही तर तो क्रॅश होईल. जर मी तुम्हाला अजून पटवले नसेल तर, खूप काळजीपूर्वक हा लेख वाचा. डेटा स्टोअर नॉन-लोकल असावा जेणेकरुन कुबर्नेट्स रीस्टार्ट किंवा रिलोकेशन नंतर अधिक लवचिकपणे नवीन नोड निवडू शकतील.

नेटवर्क

बर्‍याच वितरीत प्रणालींप्रमाणे, काफ्काचे कार्यप्रदर्शन नेटवर्क लेटन्सी कमीत कमी आणि बँडविड्थ जास्तीत जास्त ठेवण्यावर जास्त अवलंबून असते. एकाच नोडवर सर्व ब्रोकर होस्ट करण्याचा प्रयत्न करू नका, कारण यामुळे उपलब्धता कमी होईल. कुबर्नेट्स नोड अयशस्वी झाल्यास, संपूर्ण काफ्का क्लस्टर अयशस्वी होईल. तसेच, संपूर्ण डेटा सेंटरमध्ये काफ्का क्लस्टर पसरवू नका. कुबर्नेट्स क्लस्टरसाठीही हेच आहे. या प्रकरणात चांगली तडजोड म्हणजे भिन्न उपलब्धता क्षेत्रे निवडणे.

कॉन्फिगरेशन

नियमित जाहीरनामा

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

• अंतर्गत: पॉड हे कुबर्नेट्समधील सर्वात लहान तैनात करण्यायोग्य एकक आहे. पॉडमध्ये तुमचा वर्कलोड असतो आणि पॉड स्वतः तुमच्या क्लस्टरमधील प्रक्रियेशी संबंधित असतो. पॉडमध्ये एक किंवा अधिक कंटेनर असतात. काफ्का क्लस्टरमधील प्रत्येक झूकीपर सर्व्हर आणि काफ्का क्लस्टरमधील प्रत्येक ब्रोकर वेगळ्या पॉडमध्ये चालतील.
• स्टेटफुल सेट: स्टेटफुलसेट ही कुबरनेट ऑब्जेक्ट आहे जी एकापेक्षा जास्त स्टेटफुल वर्कलोड हाताळते आणि अशा वर्कलोड्ससाठी समन्वय आवश्यक असतो. स्टेटफुलसेट पॉड्सची ऑर्डर आणि त्यांच्या विशिष्टतेबद्दल हमी देतात.
• हेडलेस सेवा: सेवा तुम्हाला तार्किक नाव वापरून क्लायंटपासून पॉड वेगळे करण्याची परवानगी देतात. या प्रकरणात कुबर्नेट्स लोड बॅलेंसिंगसाठी जबाबदार आहेत. तथापि, ZooKeeper आणि Kafka सारखे स्टेटफुल वर्कलोड चालवताना, क्लायंटला विशिष्ट उदाहरणासह संप्रेषण करणे आवश्यक आहे. येथेच हेडलेस सेवा उपयोगी पडतात: या प्रकरणात, क्लायंटचे अद्याप तार्किक नाव असेल, परंतु तुम्हाला पॉडशी थेट संपर्क साधावा लागणार नाही.
• दीर्घकालीन स्टोरेज व्हॉल्यूम: वर नमूद केलेले नॉन-लोकल ब्लॉक पर्सिस्टंट स्टोरेज कॉन्फिगर करण्यासाठी हे व्हॉल्यूम आवश्यक आहेत.

वर योलेन Kubernetes वर Kafka सह प्रारंभ करण्यात मदत करण्यासाठी मॅनिफेस्टचा एक व्यापक संच प्रदान करते.

हेल्म चार्ट

हेल्म हा कुबरनेटसाठी पॅकेज व्यवस्थापक आहे ज्याची तुलना yum, apt, Homebrew किंवा Chocolatey सारख्या OS पॅकेज व्यवस्थापकांशी केली जाऊ शकते. हेल्म चार्टमध्ये वर्णन केलेले पूर्वनिर्धारित सॉफ्टवेअर पॅकेजेस स्थापित करणे सोपे करते. योग्यरित्या निवडलेला हेल्म चार्ट कुबरनेटेसवर काफ्का वापरण्यासाठी सर्व पॅरामीटर्स योग्यरित्या कसे कॉन्फिगर करावे हे कठीण काम सोपे करते. अनेक काफ्का आकृत्या आहेत: अधिकृत एक स्थित आहे इनक्यूबेटर स्थितीत, पासून एक आहे संगम, आणखी एक - पासून बटनामी.

ऑपरेटर

कारण हेल्ममध्ये काही कमतरता आहेत, दुसरे साधन लक्षणीय लोकप्रियता मिळवत आहे: कुबर्नेट्स ऑपरेटर. ऑपरेटर केवळ कुबरनेटसाठी सॉफ्टवेअर पॅकेज करत नाही तर तुम्हाला असे सॉफ्टवेअर तैनात करण्याची आणि ते व्यवस्थापित करण्याची देखील परवानगी देतो.

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

उत्पादकता

तुमच्या काफ्का उदाहरणाचे बेंचमार्क करून कार्यप्रदर्शन तपासणे महत्त्वाचे आहे. अशा चाचण्या तुम्हाला समस्या येण्यापूर्वी संभाव्य अडथळे शोधण्यात मदत करतील. सुदैवाने, काफ्का आधीच दोन कार्यप्रदर्शन चाचणी साधने प्रदान करते: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. त्यांचा सक्रिय वापर करा. संदर्भासाठी, आपण वर्णन केलेल्या परिणामांचा संदर्भ घेऊ शकता हे पोस्ट जय क्रेप्स, किंवा लक्ष केंद्रित करा हे पुनरावलोकन स्टीफन मारेक द्वारे Amazon MSK.

ऑपरेशन्स

देखरेख

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

स्ट्रिम्झीकडे काफ्कासाठी ग्राफाना डॅशबोर्डचे अतिशय सोयीचे उदाहरण आहे. हे मुख्य मेट्रिक्सची कल्पना करते, उदाहरणार्थ, कमी प्रतिकृती असलेल्या क्षेत्रांबद्दल किंवा जे ऑफलाइन आहेत. तिथे सर्व काही अगदी स्पष्ट आहे. हे मेट्रिक्स संसाधन वापर आणि कार्यप्रदर्शन माहिती, तसेच स्थिरता निर्देशकांद्वारे पूरक आहेत. त्यामुळे तुम्हाला बेसिक काफ्का क्लस्टर मॉनिटरिंग मिळत नाही.

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

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

लॉगिंग

लॉगिंग हे आणखी एक गंभीर काम आहे. तुमच्या काफ्का इंस्टॉलेशनमधील सर्व कंटेनर लॉग इन केलेले असल्याची खात्री करा stdout и stderr, आणि हे देखील सुनिश्चित करा की तुमचे Kubernetes क्लस्टर सर्व लॉग केंद्रीय लॉगिंग इन्फ्रास्ट्रक्चरमध्ये एकत्रित करते, उदा. Elasticsearch.

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

तुमच्या शेंगा सामान्यपणे चालू आहेत की नाही हे तपासण्यासाठी कुबर्नेट्स लाइव्हनेस आणि रेडिनेस प्रोबचा वापर करतात. लाइव्हनेस चेक अयशस्वी झाल्यास, Kubernetes तो कंटेनर थांबवेल आणि त्यानंतर रीस्टार्ट धोरण त्यानुसार सेट केले असल्यास ते आपोआप रीस्टार्ट होईल. तत्परता तपासणी अयशस्वी झाल्यास, Kubernetes पॉडला सर्व्हिसिंग विनंत्यांपासून वेगळे करते. अशा प्रकारे, अशा प्रकरणांमध्ये, मॅन्युअल हस्तक्षेप यापुढे अजिबात आवश्यक नाही, जे एक मोठे प्लस आहे.

अद्यतने रोल आउट करत आहे

स्टेटफुलसेट्स स्वयंचलित अद्यतनांना समर्थन देतात: जर तुम्ही रोलिंगअपडेट धोरण निवडले, तर काफ्का अंतर्गत प्रत्येक अपडेट बदलले जाईल. अशा प्रकारे, डाउनटाइम शून्यावर कमी केला जाऊ शकतो.

स्केलिंग

काफ्का क्लस्टर स्केल करणे सोपे काम नाही. तथापि, Kubernetes विशिष्ट संख्येच्या प्रतिकृतींपर्यंत पॉड्स स्केल करणे खूप सोपे करते, याचा अर्थ आपण आपल्या आवडीनुसार अनेक काफ्का ब्रोकरची व्याख्या करू शकता. या प्रकरणात सर्वात कठीण गोष्ट म्हणजे स्केलिंग अप नंतर किंवा स्केलिंग डाउन करण्यापूर्वी सेक्टर्स पुन्हा नियुक्त करणे. पुन्हा, Kubernetes या कार्यात तुम्हाला मदत करेल.

प्रशासन

तुमच्या काफ्का क्लस्टरच्या व्यवस्थापनाशी संबंधित कार्ये, जसे की विषय तयार करणे आणि क्षेत्रे पुन्हा नियुक्त करणे, तुमच्या पॉड्समध्ये कमांड लाइन इंटरफेस उघडून विद्यमान शेल स्क्रिप्ट वापरून करता येते. तथापि, हे समाधान फार सुंदर नाही. स्ट्रिमझी भिन्न ऑपरेटर वापरून विषय व्यवस्थापित करण्यास समर्थन देते. येथे सुधारणेला काही वाव आहे.

बॅकअप आणि पुनर्संचयित करा

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

निष्कर्ष

लहान ते मध्यम आकाराच्या काफ्का क्लस्टर्ससह काम करताना, Kubernetes वापरणे निश्चितच फायदेशीर आहे कारण ते अतिरिक्त लवचिकता प्रदान करते आणि ऑपरेटर अनुभव सुलभ करते. जर तुमच्याकडे अत्यंत महत्त्वपूर्ण नॉन-फंक्शनल लेटन्सी आणि/किंवा थ्रूपुट आवश्यकता असतील, तर काही इतर उपयोजन पर्यायांचा विचार करणे अधिक चांगले होईल.

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