ऑपरेटर फ्रेमवर्क के साथ कुबेरनेट्स ऑपरेटर विकास

जैसा कि रडार टेक्नॉलॉजी लेख में उल्लेख किया गया है, लमोडा सक्रिय रूप से माइक्रोसैस आर्किटेक्चर की ओर बढ़ रहा है। हमारी अधिकांश सेवाएँ हेल्म का उपयोग करके पैक की जाती हैं और कुबेरनेट्स में तैनात की जाती हैं। यह दृष्टिकोण 99% मामलों में हमारी आवश्यकताओं को पूरी तरह से पूरा करता है। 1% तब रहता है जब मानक कुबेरनेट्स कार्यक्षमता पर्याप्त नहीं होती है, उदाहरण के लिए, जब आपको किसी विशिष्ट घटना के लिए बैकअप या सेवा अद्यतन को कॉन्फ़िगर करने की आवश्यकता होती है। इस समस्या को हल करने के लिए, हम ऑपरेटर पैटर्न का उपयोग करते हैं। लेखों की इस श्रृंखला में, मैं - ग्रिगोरी मिखाल्किन, लमोडा में आर एंड डी टीम के विकासकर्ता - उन पाठों के बारे में बात करेंगे, जिन्हें मैंने संचालक फ्रेमवर्क का उपयोग करके K8s ऑपरेटरों को विकसित करने में अपने अनुभव से सीखा था।

एक ऑपरेटर क्या है?

कुबेरनेट्स कार्यक्षमता का विस्तार करने का एक तरीका अपने स्वयं के नियंत्रक बनाना है। कुबेरनेट्स में मुख्य सार वस्तुएं और नियंत्रक हैं। ऑब्जेक्ट क्लस्टर की वांछित स्थिति का वर्णन करते हैं। उदाहरण के लिए, एक पॉड बताता है कि किन कंटेनरों को शुरू करने और स्टार्टअप मापदंडों की आवश्यकता है, और रेप्लिकासेट ऑब्जेक्ट बताता है कि किसी दिए गए पॉड को कितने प्रतिकृतियां चलाने की आवश्यकता है। नियंत्रक ऑब्जेक्ट के विवरण के आधार पर क्लस्टर की स्थिति को नियंत्रित करते हैं, ऊपर वर्णित मामले में, प्रतिकृतिकंट्रोलर प्रतिकृति में निर्दिष्ट पॉड प्रतिकृतियों की संख्या का समर्थन करेगा। नए नियंत्रकों की मदद से, आप अतिरिक्त तर्क को लागू कर सकते हैं, जैसे कि घटनाओं के लिए सूचनाएं भेजना, विफलता से उबरना या तीसरे पक्ष के संसाधनों का प्रबंधन करना ।

एक ऑपरेटर एक कुबेरनेट्स अनुप्रयोग है जिसमें एक या एक से अधिक नियंत्रक शामिल होते हैं जो तीसरे पक्ष के संसाधन की सेवा करते हैं। अवधारणा का आविष्कार कोरोस टीम ने 2016 में किया था, और हाल ही में, ऑपरेटरों की लोकप्रियता तेजी से बढ़ रही है। आप कुबेडेक्स पर सूची में वांछित ऑपरेटर को खोजने की कोशिश कर सकते हैं, (100 से अधिक सार्वजनिक रूप से उपलब्ध ऑपरेटरों को यहां सूचीबद्ध किया गया है), साथ ही साथ ऑपरेटरहब पर। ऑपरेटर विकास के लिए 3 लोकप्रिय उपकरण हैं: कुबेबुइस्टर , ऑपरेटर एसडीके और मेटाकंट्रोलर । लमोडा में हम ऑपरेटर एसडीके का उपयोग करते हैं, इसलिए हम इसके बारे में बाद में बात करेंगे।

संचालक एस.डी.के.

ऑपरेटर SDK ऑपरेटर फ्रेमवर्क का एक हिस्सा है, जिसमें दो और महत्वपूर्ण भाग शामिल हैं: ऑपरेटर जीवनचक्र प्रबंधक और ऑपरेटर मीटरिंग।

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

एक नया प्रोजेक्ट बनाएं

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

एक नए ऑपरेटर के साथ एक परियोजना बनाएं:

operator-sdk new config-monitor 

कोड जनरेटर आवंटित नाम स्थान में काम करने वाले ऑपरेटर के लिए कोड बनाएगा। यह दृष्टिकोण पूरे क्लस्टर तक पहुंच देने के लिए बेहतर है, क्योंकि त्रुटियों के मामले में समस्याओं को एक ही नाम स्थान के भीतर अलग किया जाएगा। cluster-wide ऑपरेटर --cluster-scoped जोड़कर उत्पन्न किया जा सकता है। निम्नलिखित निर्देशिकाएं बनाई गई परियोजना के अंदर स्थित होंगी:

• cmd - में main package , जिसमें Manager प्रारंभ और लॉन्च किया जाता है;
• तैनात - ऑपरेटर, सीआरडी और आरबीएसी ऑपरेटर स्थापित करने के लिए आवश्यक वस्तुओं की घोषणाएं शामिल हैं;
• pkg - यहाँ नई वस्तुओं और नियंत्रकों के लिए हमारा मुख्य कोड होगा।

cmd/manager/main.go में केवल एक cmd/manager/main.go फ़ाइल है।

 // Become the leader before proceeding err = leader.Become(ctx, "config-monitor-lock") if err != nil { log.Error(err, "") os.Exit(1) } // Create a new Cmd to provide shared dependencies and start components mgr, err := manager.New(cfg, manager.Options{ Namespace: namespace, MetricsBindAddress: fmt.Sprintf("%s:%d", metricsHost, metricsPort), }) ... // Setup Scheme for all resources if err := apis.AddToScheme(mgr.GetScheme()); err != nil { log.Error(err, "") os.Exit(1) } // Setup all Controllers if err := controller.AddToManager(mgr); err != nil { log.Error(err, "") os.Exit(1) } ... // Start the Cmd if err := mgr.Start(signals.SetupSignalHandler()); err != nil { log.Error(err, "Manager exited non-zero") os.Exit(1) } 

पहली पंक्ति में: err = leader.Become(ctx, "config-monitor-lock") - एक नेता का चयन किया जाता है। ज्यादातर परिदृश्यों में, नामस्थान / क्लस्टर पर एक बयान के केवल एक सक्रिय उदाहरण की जरूरत है। डिफ़ॉल्ट रूप से, ऑपरेटर SDK जीवन रणनीति के लिए लीडर का उपयोग करता है - ऑपरेटर का पहला लॉन्च किया गया उदाहरण तब तक लीडर रहेगा जब तक कि उसे क्लस्टर से हटा नहीं दिया जाता।

इस ऑपरेटर उदाहरण के बाद नेता नियुक्त किया गया है, एक नए Manager को इनिशियलाइज़ किया गया है - mgr, err := manager.New(...) । उनकी जिम्मेदारियों में शामिल हैं:

• err := apis.AddToScheme(mgr.GetScheme()) - नई संसाधन योजनाओं का पंजीकरण;
• err := controller.AddToManager(mgr) - नियंत्रकों का पंजीकरण;
• err := mgr.Start(signals.SetupSignalHandler()) - नियंत्रक लॉन्च और नियंत्रित करें।

फिलहाल, हमारे पास पंजीकरण के लिए न तो नए संसाधन हैं, न ही नियंत्रक। आप कमांड का उपयोग करके एक नया संसाधन जोड़ सकते हैं:

 operator-sdk add api --api-version=services.example.com/v1alpha1 --kind=MonitoredService 

यह कमांड MonitoredService स्कीमा परिभाषा को pkg/apis निर्देशिका में जोड़ेगा, साथ ही deploy/crds crds में CRD परिभाषा के साथ yaml करेगा। सभी जेनरेट की गई फ़ाइलों में से, आपको मैन्युअल रूप से केवल monitoredservice_types.go परिभाषाओं को monitoredservice_types.go में बदलना चाहिए। मॉनीटर टाइप किए गएServiceSpec संसाधन की इच्छित स्थिति को परिभाषित करता है: उपयोगकर्ता संसाधन की परिभाषा के साथ याम्ल में क्या निर्दिष्ट करता है। हमारे ऑपरेटर के संदर्भ में, Size फ़ील्ड प्रतिकृति की वांछित संख्या निर्धारित करता है, ConfigRepo इंगित करता है कि वर्तमान कॉन्फ़िगरेशन को कहाँ से खींचा जा सकता है। MonitoredServiceStatus , संसाधन की देखी गई स्थिति को निर्धारित करता है, उदाहरण के लिए, यह इस संसाधन से संबंधित पॉड्स के नाम और वर्तमान spec पॉड्स को संग्रहीत करता है।

योजना को संपादित करने के बाद, आपको कमांड चलाने की आवश्यकता है:

 operator-sdk generate k8s 

यह deploy/crds में CRD परिभाषा को अद्यतन करेगा।

अब हमारे ऑपरेटर का मुख्य भाग बनाते हैं, नियंत्रक:

 operator-sdk add controller --api-version=services.example.com/v1alpha1 --kind=Monitor 

monitor_controller.go फ़ाइल pkg/controller monitor_controller.go में दिखाई देगी, जिसमें हम अपनी आवश्यकता के तर्क जोड़ते हैं।

नियंत्रक विकास

नियंत्रक ऑपरेटर की मुख्य कार्य इकाई है। हमारे मामले में, दो नियंत्रक हैं:

• मॉनिटर नियंत्रक सेवा कॉन्फ़िगरेशन परिवर्तनों की निगरानी करता है;
• नवीनीकरण नियंत्रक सेवा को अद्यतन करता है और इसे वांछित स्थिति में रखता है।

इसके मूल में, नियंत्रक एक नियंत्रण लूप है, यह उन घटनाओं के साथ कतार की निगरानी करता है जिन्हें इसे सब्सक्राइब किया जाता है और उन्हें संसाधित करता है:

एक नया नियंत्रक प्रबंधक द्वारा add मेथड में बनाया और पंजीकृत किया गया है:

 c, err := controller.New("monitor-controller", mgr, controller.Options{Reconciler: r}) 

Watch विधि का उपयोग करते हुए, हम इसे एक नए संसाधन के निर्माण या किसी मौजूदा MonitoredService संसाधन के विशेष अद्यतन के बारे में घटनाओं की सदस्यता लेते हैं:

 err = c.Watch(&source.Kind{Type: &servicesv1alpha1.MonitoredService{}}, &handler.EnqueueRequestForObject{}, common.CreateOrUpdateSpecPredicate) 

घटना का प्रकार src का उपयोग करके कॉन्फ़िगर किया जा सकता है और मापदंडों की predicates करता है। src टाइप Source की ऑब्जेक्ट्स को स्वीकार करता है।

• Informer - समय-समय पर फिल्टर से मेल खाने वाली घटनाओं के लिए apiserver को apiserver करता है, अगर ऐसी कोई घटना है, तो इसे नियंत्रक की कतार में रखता है। controller-runtime यह client-go SharedIndexInformer से SharedIndexInformer पर एक आवरण है।
• Kind भी SharedIndexInformer पर एक आवरण है, लेकिन Informer विपरीत, यह स्वतंत्र रूप से पारित मापदंडों (निगरानी संसाधन की योजना) के आधार पर एक मुखबिर उदाहरण बनाता है।
• Channel - chan event.GenericEvent को स्वीकार करता है। एक पैरामीटर के रूप में chan event.GenericEvent , इसके माध्यम से आने वाली घटनाओं को नियंत्रक की कतार में रखा जाता है।

redicates वस्तुओं की अपेक्षा करता है जो Predicate इंटरफ़ेस को संतुष्ट करते हैं। वास्तव में, यह घटनाओं के लिए एक अतिरिक्त फ़िल्टर है, उदाहरण के लिए, UpdateEvent फ़िल्टर करते UpdateEvent आप वास्तव में देख सकते हैं कि संसाधन spec में क्या बदलाव किए गए थे।

जब कोई घटना आती है, तो एक EventHandler इसे स्वीकार करता है - Watch विधि का दूसरा तर्क - जो उस घटना को अनुरोध प्रारूप में लपेटता है, जो रीकॉन्सीलर को उम्मीद है:

• EnqueueRequestForObject - घटना के कारण वस्तु के नाम और नाम स्थान के साथ एक अनुरोध बनाता है;
• EnqueueRequestForOwner - ऑब्जेक्ट के माता-पिता के डेटा के साथ एक अनुरोध बनाता है। यह आवश्यक है, उदाहरण के लिए, यदि संसाधन नियंत्रित Pod हटा Pod गया है, और आपको इसका प्रतिस्थापन शुरू करने की आवश्यकता है;
• EnqueueRequestsFromMapFunc - एक पैरामीटर को map फ़ंक्शन के रूप में लेता है जो एक घटना प्राप्त करता है ( MapObject में लिपटे) और अनुरोधों की एक सूची देता है। एक उदाहरण जब इस हैंडलर की आवश्यकता होती है - एक टाइमर होता है, जिसके प्रत्येक टिक के लिए आपको सभी उपलब्ध सेवाओं के लिए नए कॉन्फ़िगरेशन को बाहर निकालने की आवश्यकता होती है।

अनुरोधों को नियंत्रक कतार में रखा जाता है, और श्रमिकों में से एक (डिफ़ॉल्ट रूप से नियंत्रक के पास एक है) घटना को कतार से बाहर निकालता है और इसे Reconciler को पास करता है।

रीकॉन्सेलर केवल एक विधि को लागू करता है - Reconcile , जिसमें इवेंट प्रोसेसिंग का मूल तर्क होता है:

 func (r *ReconcileMonitor) Reconcile(request reconcile.Request) (reconcile.Result, error) { reqLogger := log.WithValues("Request.Namespace", request.Namespace, "Request.Name", request.Name) reqLogger.Info("Checking updates in repo for MonitoredService") // fetch the Monitor instance instance := &servicesv1alpha1.MonitoredService{} err := r.client.Get(context.Background(), request.NamespacedName, instance) if err != nil { if errors.IsNotFound(err) { // Request object not found, could have been deleted after reconcile request. // Owned objects are automatically garbage collected. For additional cleanup logic use finalizers. // Return and don't requeue return reconcile.Result{}, nil } // Error reading the object - requeue the request. return reconcile.Result{}, err } // check if service's config was updated // if it was, send event to upgrade controller if podSpec, ok := r.isServiceConfigUpdated(instance); ok { // Update instance Spec instance.Status.PodSpec = *podSpec instance.Status.ConfigChanged = true err = r.client.Status().Update(context.Background(), instance) if err != nil { reqLogger.Error(err, "Failed to update service status", "Service.Namespace", instance.Namespace, "Service.Name", instance.Name) return reconcile.Result{}, err } r.eventsChan <- event.GenericEvent{Meta: &servicesv1alpha1.MonitoredService{}, Object: instance} } return reconcile.Result{}, nil } 

विधि NamespacedName फ़ील्ड के साथ Request ऑब्जेक्ट को स्वीकार करती है, जिसके द्वारा संसाधन को कैश से खींचा जा सकता है: r.client.Get(context.TODO(), request.NamespacedName, instance) । उदाहरण में, संसाधन spec में ConfigRepo फ़ील्ड द्वारा संदर्भित सेवा कॉन्फ़िगरेशन के साथ फ़ाइल के लिए अनुरोध किया जाता है। यदि कॉन्फ़िगरेशन को अपडेट किया जाता है, तो GenericEvent प्रकार की एक नई घटना GenericEvent और उस चैनल पर भेजी जाती है जिसे Upgrade नियंत्रक सुनता है।

अनुरोध को संसाधित करने के बाद, Reconcile एक Result प्रकार और error । यदि Result फ़ील्ड Requeue: true या error != nil , तो नियंत्रक कतार का उपयोग करके कतार में वापस आ जाएगा। अनुरोध विलंब के साथ कतार में वापस आ जाएगा, जो RateLimiter द्वारा निर्धारित किया RateLimiter । डिफ़ॉल्ट रूप से, ItemExponentialFailureRateLimiter उपयोग किया जाता है, जो देरी के समय को "रिटर्न" की संख्या में वृद्धि के साथ तेजी से बढ़ाता है। यदि Requeue क्षेत्र निर्धारित नहीं है, और अनुरोध प्रसंस्करण के दौरान कोई त्रुटि नहीं हुई है, तो नियंत्रक Queue.Forget विधि को कॉल करेगा, जो RateLimiter कैश से अनुरोध को हटा देगा (जिससे रिटर्न की संख्या को रीसेट करना होगा)। अनुरोध प्रसंस्करण के अंत में, नियंत्रक इसे कतार से हटाता है। कतार विधि का उपयोग करके।

ऑपरेटर लॉन्च

ऑपरेटर के घटकों को ऊपर वर्णित किया गया था, और एक सवाल बना रहा: इसे कैसे शुरू किया जाए। पहले आपको यह सुनिश्चित करने की आवश्यकता है कि सभी आवश्यक संसाधन स्थापित हैं (स्थानीय परीक्षण के लिए, मैं मिनीब्यूब स्थापित करने की सलाह देता हूं ):

 # Setup Service Account kubectl create -f deploy/service_account.yaml # Setup RBAC kubectl create -f deploy/role.yaml kubectl create -f deploy/role_binding.yaml # Setup the CRD kubectl create -f deploy/crds/services_v1alpha1_monitoredservice_crd.yaml # Setup custom resource kubectl create -f deploy/crds/services_v1alpha1_monitoredservice_cr.yaml 

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

 operator-sdk up local --namespace=default 

दूसरा तरीका क्लस्टर में ऑपरेटर को तैनात करना है। पहले आपको ऑपरेटर के साथ डॉकटर छवि बनाने की आवश्यकता है:

 operator-sdk build config-monitor-operator:latest 

deploy/operator.yaml REPLACE_IMAGE फ़ाइल में, REPLACE_IMAGE को config-monitor-operator:latest प्रतिस्थापित करें config-monitor-operator:latest :

 sed -i "" 's|REPLACE_IMAGE|config-monitor-operator:latest|g' deploy/operator.yaml 

बयान के साथ तैनाती बनाएँ:

 kubectl create -f deploy/operator.yaml 

अब क्लस्टर पर Pod की सूची में एक परीक्षण सेवा के साथ Pod दिखाई देना चाहिए, और दूसरे मामले में - एक ऑपरेटर के साथ एक और।

एक निष्कर्ष या सर्वोत्तम प्रथाओं के बजाय

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

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

टिप्पणियों में, विकासशील ऑपरेटरों में अपने अनुभव के बारे में सुनना दिलचस्प होगा। और अगले भाग में हम ऑपरेटर परीक्षण के बारे में बात करेंगे।