कुबेरनेट्स संसाधन ट्रैकिंग के लिए कुबेदोग पुस्तकालय का परिचय

हम DevOps- विशेषज्ञों के लिए फ़्लैंट कंपनी के एक नए ओपन सोर्स विकास की घोषणा करने में प्रसन्न हैं और न केवल कुबेदोग । कुबेरनेट्स संसाधन घटनाओं पर नज़र रखने और उनके लॉग को इकट्ठा करने के लिए यह एक गो-लिखित पुस्तकालय और इसके आधार पर एक सीएलआई है।


वर्तमान में, पुस्तकालय निम्नलिखित संसाधनों पर नज़र रखने का समर्थन करता है: पोड (और कंटेनर), नौकरी, तैनाती, स्टेटफुलसेट, और डेमनसेट। ईवेंट और लॉग कॉलबैक के माध्यम से प्रेषित होते हैं।

कुबेदोग सीएलआई में ऑपरेशन के दो तरीके हैं:

• रोलआउट ट्रैक - सीआई / सीडी में सुविधाजनक उपयोग के लिए त्रुटि के मामले में तैयार स्थिति तक पहुंचने और बाहर निकलने तक संसाधन पर नज़र रखना;
• अनुवर्ती - एक्ज़िट के बिना स्क्रीन पर घटनाओं और लॉग को प्रिंट करें , tail -f समान।

समस्या

अगर इसी तरह की परियोजनाएं पहले से मौजूद हैं ( इस समीक्षा में "लॉग के साथ काम करना" देखें) तो हमने एक नई लाइब्रेरी लिखना क्यों शुरू किया? कुबेदोग का उपयोग हमारे DevOps डैप उपयोगिता में हेलम चार्ट के रोलआउट को ट्रैक करने के लिए किया जाता है। हेल्म खुद नहीं जानता है कि संसाधनों की स्थिति की निगरानी कैसे करें जो इसे जोड़ता है, और लॉग ट्रांसफर हेल्म और टिलर के बीच जीआरपीसी बातचीत के स्तर पर प्रदान नहीं किया जाता है। इस अवसर पर, हमारा मुद्दा 3481 है , जिसके ढांचे में हमने अतिरिक्त संसाधनों की ट्रैकिंग को लागू किया है ... हालांकि, हेलम परियोजना अब हेल्म 2 में नई सुविधाओं को जोड़ने के लिए अनिच्छुक है, क्योंकि सभी प्रयास हेल्म 3 के नए संस्करण पर केंद्रित हैं। इस कारण से, हमने कुबेदोग को एक अलग परियोजना में बदलने का फैसला किया।

लाइब्रेरी पर संसाधन ट्रैकिंग की क्या आवश्यकता है ?

• पॉड्स के लॉग प्राप्त करें जो एक संसाधन से संबंधित हैं - उदाहरण के लिए, परिनियोजन।
• संसाधन से संबंधित पॉड्स की संरचना में परिवर्तन का जवाब दें: नए पॉड्स से लॉग प्राप्त करना जोड़ें, पुराने प्रतिकृति के पॉड्स से लॉग को अक्षम करें।
• ट्रैकिंग ईवेंट जिसमें विभिन्न त्रुटियां आती हैं। उदाहरण के लिए, एक अज्ञात छवि के कारण एक पॉड नहीं बनाया जा सकता है या एक पॉड बनाया जाता है, लेकिन टेम्पलेट में निर्दिष्ट कमांड छवि में नहीं है।
• और एक और आवश्यकता rollout से ready मोड में एक संसाधन के संक्रमण को ट्रैक कर रही है। और इसके लिए प्रत्येक संसाधन की अपनी शर्तें हैं।

जैसा कि आप अनुमान लगा सकते हैं, कुबडोग में हमने उपरोक्त सभी को ध्यान में रखने की कोशिश की थी।

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

मौजूदा समाधान

kubespy

→ गिटहब

• केवल परिनियोजन और सेवा की निगरानी करने में सक्षम, नए पॉड्स पर प्रतिक्रिया करता है।
• संसाधन और उसकी स्थिति के विवरण के लिए एक ट्रैकिंग मोड है और json के रूप में परिवर्तनों का आउटपुट।
• रेप्लिकासेट्स की स्थिति और स्थितियों को दिखाने वाले परिवर्तनों का एक रंग सारणीबद्ध प्रतिनिधित्व है।
• पॉड लॉग नहीं दिखाता है।
• यह गो में लिखा है, लेकिन इसे लाइब्रेरी के रूप में उपयोग नहीं किया जा सकता है।

kubetail

→ गिटहब

• एक बैश स्क्रिप्ट जिसे कुबेटेल कहते हैं।
• मौजूदा पॉड्स के लॉग दिखाने में सक्षम।
• यह नए पॉड्स का पता नहीं लगाता है; यदि रोलबैक होता है, तो कुबेटेल को फिर से शुरू करने की आवश्यकता होती है।

कठोर

→ गिटहब

• पॉड-क्वेरी द्वारा फ़िल्टर किए गए पॉड्स के लॉग दिखाता है।
• नई फली की खोज करें।
• बेहतर धारणा के लिए लॉग लाइनें रंगीन होती हैं।
• उन में कंटेनरों के नाम के साथ पोड्स को जोड़ने और हटाने की घटनाओं को दर्शाता है।
• यह ईवेंट्स का पालन नहीं करता है, इसलिए यह पॉड त्रुटियों का कारण नहीं दिखाता है।
• इसे गो में लिखा गया है, लेकिन इसका उपयोग पुस्तकालय के रूप में नहीं किया जा सकता है।

गोभी

→ गिटहब

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

k8stail

→ गिटहब

• नेमस्पेस और लेबल द्वारा पॉड्स का चयन।
• नए का ट्रैक रखता है, विलोपन।
• ईवेंट्स का पालन नहीं करता है, त्रुटियों को नहीं दिखाएगा।
• जाओ पर, लेकिन पुस्तकालय नहीं।

kubedog

→ गिटहब

• CLI दो मोड्स में चल रही है: अंतहीन ट्रैकिंग और ट्रैकिंग जब तक संसाधन READY स्थिति में नहीं बदल जाता।
• एक संसाधन का ट्रैक रखता है।
• संसाधन परिवर्तनों के प्रति प्रतिक्रिया, नए पॉड्स के लॉग की सदस्यता लेता है।
• तैनाती, स्टेटफुलसेट, डेमनसेट, जॉब या एक अलग पॉड की निगरानी करने में सक्षम।
• गो में लिखा गया है, आप संसाधनों की स्थिति की निगरानी करने और कंटेनरों से लॉग प्राप्त करने के लिए अपने कार्यक्रम में संसाधनों को जोड़ने के लिए एक पुस्तकालय के रूप में इसका उपयोग कर सकते हैं।

यदि आप एक करीब से देखते हैं, तो आप कह सकते हैं कि प्रत्येक उपयोगिता किसी न किसी तरह से अपने प्रतिद्वंद्वियों को मात देती है और कोई भी विजेता नहीं होता है जो दूसरों के लिए सब कुछ कर सकता है।

तो कुबेडोग!

कुबडोग के काम का सार इस प्रकार है: निर्दिष्ट संसाधन के लिए, इवेंट्स पर और पॉड्स से संबंधित संसाधन पर वॉचर्स चलाएँ, और जब पॉड दिखाई दे, तो अपना लकड़हारा चलाएँ। संसाधन के साथ होने वाली हर चीज कॉलबैक से क्लाइंट को प्रसारित की जाती है।

आइए DaemonSet के एक उदाहरण को देखें, जो लाइब्रेरी का उपयोग करने वाले कोड के लिए उपलब्ध है। तैनाती के लिए कॉलबैक इंटरफ़ेस, स्टेटफुलसेट और डेमनसेट एक ही * है - यह ControllerFeed :

 type ControllerFeed interface { Added(ready bool) error Ready() error Failed(reason string) error EventMsg(msg string) error AddedReplicaSet(ReplicaSet) error AddedPod(ReplicaSetPod) error PodLogChunk(*ReplicaSetPodLogChunk) error PodError(ReplicaSetPodError) error } 

* अपवाद AddedReplicaSet , जो केवल परिनियोजन के लिए समझ में आता है (आप डेमॉनसेट को ट्रैक करने के लिए इस विधि को परिभाषित नहीं कर सकते हैं)।

अन्य इंटरफ़ेस विधियों के लिए स्पष्टीकरण:

• Added watch.Added से मेल खाती है। चयनित संसाधन के लिए पर्यवेक्षक की watch.Added घटना;
• Ready कहा जाता है जब संसाधन ने Ready स्टेट में प्रवेश किया है (उदाहरण के लिए, डेमनसेट के लिए यह वह क्षण है जब अद्यतन और उपलब्ध पॉड्स की संख्या "वांछित" पॉड्स की संख्या के साथ मेल खाती है);
• Failed - इस विधि को उस समय कहा जाता है जब कोई संसाधन हटा दिया जाता है या उस घटना में जो किसी त्रुटि के कारण और विवरण के साथ प्राप्त होती है (उदाहरण के लिए, FailedCreate );
• EventMsg को संसाधन या उसके पॉड्स से प्राप्त प्रत्येक ईवेंट के लिए कहा जाता है: ये संसाधन के निर्माण के बारे में इवेंट हैं, छवि लिंक आदि के बारे में। त्रुटि संदेशों सहित;
• AddedPod - एक विधि जिसके द्वारा आप नए पॉड बनाने के क्षणों को पकड़ सकते हैं;
• PodLogChunk को कहा जाता है जब लॉग का एक और टुकड़ा कुबेरनेट्स एपीआई से आता है;
• पॉड फेल होने पर PodError को PodError जाएगा।

प्रत्येक कॉलबैक StopTrack प्रकार की StopTrack वापस कर सकता है और ट्रैकिंग पूरी हो जाएगी। इसलिए, उदाहरण के लिए, रोलआउट ट्रैकर में किया गया - Ready StopTrack और सीएलआई अपना काम पूरा करता है।

कॉलबैक की परिभाषा को सुविधाजनक बनाने के लिए, एक ControllerFeedProto संरचना है, जब आप एक ऑब्जेक्ट का निर्माण कर सकते हैं, जिससे आप वांछित रिटर्न विधि का निर्धारण कर सकते हैं।

उदाहरण के लिए, इवेंट और स्थिति के बारे में अतिरिक्त जानकारी के बिना DaemonSet लॉग का अंतहीन आउटपुट कैसा दिखता है, यह है:

 // kubedog     Kubernetes',    // . https://github.com/flant/kubedog/blob/master/pkg/kube/kube.go kubeClient, err := kubernetes.NewForConfig(config) if err != nil { return err } feed := &tracker.ControllerFeedProto{ PodLogChunkFunc: func(chunk *tracker.ReplicaSetPodLogChunk) error { for _, line := range chunk.LogLines { fmt.Printf(">> po/%s %s: %s\n", chunk.PodName, chunk.ContainerName, line) } return nil }, } //    timeout   API   ,     .   ,     ,    Pod'. opts := tracker.Options{ Timeout: time.Second * time.Duration(300), LogsFromTime: time.Now(), } tracker.TrackDaemonSet(dsName, dsNamespace, kubeClient, feed, opts) 

आखिरी कॉल एक अवरोधक है : यह कुबेरनेट्स से घटनाओं को प्राप्त करने का एक अंतहीन लूप शुरू करता है और इसी कॉलबैक को कॉल करता है। आप कॉलबैक से StopTrack को वापस करके इस चक्र को प्रोग्रामेटिक रूप से बाधित कर सकते हैं।

आवेदन उदाहरण

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

कुबेदोग सीएलआई सीआई / सीडी सिस्टम में रोलआउट के साथ मदद करने में सक्षम है , और इसकी परवाह किए बिना कि क्या इसका उपयोग किया जाता है: कुबेटेल, हेल्म या कुछ और। आखिरकार, आप kubectl apply , और फिर kubedog rollout track चला सकते हैं, और यदि संसाधन में कुछ गड़बड़ है, तो आपको kubedog rollout track लॉग में त्रुटि दिखाई देगी। कुबडोग के इस प्रयोग से रोलआउट समस्याओं के निदान के लिए समय कम करने में मदद मिलेगी।

आगे क्या है?

हम अधिक संसाधनों का समर्थन करने की दिशा में पुस्तकालय विकसित करने की योजना बनाते हैं - उदाहरण के लिए, मैं वास्तव में सेवा और प्रगति का पालन करना चाहता हूं। इसके अलावा, यह Event'ah में reason के वर्गीकरण पर काम को पूरा करने के लिए माना जाता है, ताकि उस क्षण को अधिक सटीक रूप से निर्धारित किया जा सके जब हम यह मान सकें कि संसाधन का रोलआउट विफल हो गया। लाइब्रेरी डेवलपमेंट का एक और वेक्टर एक साथ कई संसाधनों को ट्रैक कर रहा है, उदाहरण के लिए, labelSelector या नाम नेमस्पेस द्वारा। मैं विभिन्न एनोटेशन का भी समर्थन करना चाहता हूं जो ट्रैकिंग की प्रकृति को बदल सकते हैं, उदाहरण के लिए, हेल्म हुक के लिए, लेकिन यह अभी भी डैप के लिए अधिक प्रासंगिक है।

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

कैसे करें कोशिश?

Kubedog CLI लिनक्स के लिए बनाता है और मैकओएस बिंट्रे पर उपलब्ध हैं।

वास्तव में GitHub पर आपकी प्रतिक्रिया और मुद्दों की प्रतीक्षा है !

पुनश्च

हमारे ब्लॉग में भी पढ़ें:

• " कुबर्नॉक्स और कुबेरनेट्स के लिए अन्य कंसोल गोले ";
• " लॉगहाउस का परिचय - कुबेरनेट्स में लॉग के साथ काम करने के लिए एक खुला स्रोत प्रणाली ";
• "हम आधिकारिक तौर पर dapp का प्रतिनिधित्व करते हैं - CI / CD का समर्थन करने के लिए DevOps- उपयोगिता ";
• " एक सस्ती सेवा के रूप में कुबेरनेट्स के साथ बुनियादी ढांचा ।"