कुबर्नेट्सची योग्य तुलना लागू करा, बदला आणि पॅच करा

Kubernetes कडे संसाधने अपडेट करण्यासाठी अनेक पर्याय आहेत: लागू करा, संपादित करा, पॅच करा आणि बदला. प्रत्येकजण काय करतो आणि कधी वापरायचा याबाबत संभ्रम आहे. चला ते बाहेर काढूया.

तर Google वर शोधा "kubernetes apply vs बदला" हा वाक्यांश स्थित आहे StackOverflow ला उत्तर द्या, जे योग्य नाही. शोधताना "kubernetes लागू वि पॅच" साठी पहिली लिंक आहे kubectl patch, ज्यात तुलना समाविष्ट नाही apply и patch. हा लेख विविध पर्याय, तसेच प्रत्येकाचा योग्य वापर पाहणार आहे.

कुबर्नेट्स संसाधनाच्या जीवनचक्रादरम्यान (सेवा, उपयोजन, प्रवेश, इ.) काहीवेळा तुम्हाला या संसाधनाचे काही गुणधर्म बदलणे, जोडणे किंवा काढून टाकणे आवश्यक आहे. उदाहरणार्थ, एक टीप जोडा, प्रतिकृतींची संख्या वाढवा किंवा कमी करा.

कुबर्नेट्स सीएलआय

जर तुम्ही आधीच CLI द्वारे Kubernetes क्लस्टर्ससह काम करत असाल, तर तुम्ही आधीच परिचित आहात apply и edit. संघ apply फाईलमधील संसाधन तपशील वाचते आणि कुबर्नेट्स क्लस्टरला "अप्सर्ट" बनवते, उदा. जर ते अस्तित्वात नसेल तर संसाधन तयार करते आणि ते अस्तित्वात असल्यास ते अद्यतनित करते. संघ edit API द्वारे संसाधन वाचते, नंतर स्थानिक फाइलवर संसाधन तपशील लिहिते, जी नंतर मजकूर संपादकात उघडली जाते. तुम्ही फाइल संपादित करून सेव्ह केल्यानंतर, kubectl API द्वारे केलेले बदल परत पाठवेल, जे हे बदल संसाधनावर काळजीपूर्वक लागू करेल.

प्रत्येकाला आज्ञा माहित नाहीत patch и replace. संघ patch कमांड लाइनवर फक्त बदललेला भाग प्रदान करून तुम्हाला संसाधन तपशीलाचा भाग बदलण्याची परवानगी देते. संघ replace सारखेच कार्य करते edit, परंतु सर्वकाही व्यक्तिचलितपणे करणे आवश्यक आहे: आपल्याला संसाधन तपशीलाची वर्तमान आवृत्ती डाउनलोड करण्याची आवश्यकता आहे, उदाहरणार्थ, वापरून kubectl get -o yaml, संपादित करा, नंतर वापरा replace बदललेल्या तपशीलानुसार संसाधन अद्यतनित करण्यासाठी. संघ replace रिसोर्स वाचणे आणि बदलणे यामध्ये कोणतेही बदल झाल्यास कार्य करणार नाही.

Kubernetes API

आपण कदाचित पद्धतींशी परिचित आहात CoreV1().Pods().Update(), replaceNamespacedService किंवा patch_namespaced_deployment, जर तुम्ही क्लस्टर्स द्वारे काम करत असाल Kubernetes API साठी क्लायंट लायब्ररी काही प्रोग्रामिंग भाषा वापरणे. लायब्ररी पद्धती वापरून HTTP विनंत्यांद्वारे या पद्धती हाताळते PUT и PATCH... ज्यात update и replace वापरा PUTआणि patch, ते कितीही क्षुल्लक असले तरी वापरते PATCH.

हे लक्षात घेण्यासारखे आहे kubectl API द्वारे क्लस्टरसह देखील कार्य करते. दुसऱ्या शब्दात, kubectlगो लँग्वेजसाठी क्लायंट लायब्ररीच्या वर एक रॅपर आहे, जे मानक API क्षमतांव्यतिरिक्त अधिक संक्षिप्त आणि वाचनीय स्वरूपात सबकमांड प्रदान करण्याची क्षमता प्रदान करते. उदाहरणार्थ, जसे आपण आधीच लक्षात घेतले असेल, पद्धत apply मागील परिच्छेदात वर उल्लेख केला नव्हता. सध्या (मे 2020, अंदाजे अनुवादक) सर्व तर्क kubectl apply, म्हणजे अस्तित्वात नसलेली संसाधने तयार करणे आणि विद्यमान संसाधने अद्यतनित करणे, पूर्णपणे कोडच्या बाजूने कार्य करते kubectl. प्रयत्न केले जात आहेत तर्क हस्तांतरण वर apply API बाजूला, परंतु ते अद्याप बीटामध्ये आहे. मी खाली अधिक तपशीलवार लिहीन.

डीफॉल्टनुसार पॅच

सर्वोत्तम वापरले patch, आपण संसाधन अद्यतनित करू इच्छित असल्यास. अशा प्रकारे दोन्ही क्लायंट लायब्ररी Kubernetes API वर कार्य करतात आणि kubectl (आश्चर्यकारक नाही, कारण ते क्लायंट लायब्ररीसाठी एक आवरण आहे, अंदाजे अनुवादक).

धोरणात्मक काम करा

सर्व संघ kubectl apply, edit и patch पद्धत वापरा PATCH विद्यमान संसाधन अद्यतनित करण्यासाठी HTTP विनंत्यांमध्ये. जर तुम्ही कमांड्सच्या अंमलबजावणीमध्ये अधिक तपशीलवार विचार केला तर ते सर्व दृष्टीकोन वापरतात स्ट्रॅटेजिक-मर्ज पॅचिंग संसाधने अद्यतनित करण्यासाठी, जरी आदेश patch इतर पध्दती वापरू शकतात (खालील यावर अधिक). स्ट्रॅटेजिक-मर्ज पॅचिंग पध्दत सध्याच्या स्पेसिफिकेशनसह पुरवलेले स्पेसिफिकेशन विलीन करून "ते बरोबर मिळवण्याचा" प्रयत्न करते. अधिक विशिष्टपणे, ते ऑब्जेक्ट आणि अॅरे दोन्ही एकत्र करण्याचा प्रयत्न करते, याचा अर्थ बदल हे जोडण्यासारखे असतात. उदाहरणार्थ, कमांड चालवणे patch पॉड कंटेनर स्पेसिफिकेशनमध्ये नवीन एन्व्हायर्नमेंट व्हेरिएबलसह, ते एन्व्हायर्नमेंट व्हेरिएबल त्यांना ओव्हरराइट करण्याऐवजी विद्यमान पर्यावरण व्हेरिएबलमध्ये जोडले जाते. हा दृष्टिकोन वापरून काढून टाकण्यासाठी, तुम्ही प्रदान केलेल्या तपशीलामध्ये पॅरामीटर मूल्य शून्य करण्यासाठी सक्ती करणे आवश्यक आहे. संघ कोणत्या kubectl अद्ययावत करण्यासाठी वापरणे चांगले आहे का?

आपण वापरून आपली संसाधने तयार आणि व्यवस्थापित केल्यास kubectl apply, अद्यतनित करताना नेहमी वापरणे चांगले kubectl applyते kubectl कॉन्फिगरेशन व्यवस्थापित करू शकते आणि विनंती केलेल्या बदलांचा अनुप्रयोग ते अनुप्रयोग योग्यरित्या मागोवा घेऊ शकते. फायदा नेहमी वापरा apply म्हणजे ते पूर्वी लागू केलेल्या तपशीलाचा मागोवा ठेवते, जे स्पेसिफिकेशन गुणधर्म आणि अॅरे घटक स्पष्टपणे काढून टाकले जातात तेव्हा हे जाणून घेण्यास अनुमती देते. हे आपल्याला वापरण्याची परवानगी देते apply गुणधर्म आणि अॅरे घटक काढून टाकण्यासाठी, तर सामान्य धोरणात्मक विलीनीकरण कार्य करणार नाही. संघ edit и patch त्या नोट्स अपडेट करू नका kubectl apply त्‍याच्‍या बदलांचा मागोवा घेण्‍यासाठी वापरते, त्यामुळे कुबेर्नेट्स API द्वारे ट्रॅक केलेले आणि केलेले कोणतेही बदल, परंतु आदेशांद्वारे केले जातात edit и patch, त्यानंतरच्या आदेशांना अदृश्य applyते आहे apply साठी इनपुट स्पेसिफिकेशनमध्ये दिसत नसले तरीही त्यांना काढून टाकत नाही apply (कागदपत्रात असे म्हटले आहे edit и patch वापरलेल्या नोट्समध्ये सुधारणा करा apply, परंतु सराव मध्ये - नाही).

तुम्ही कमांड वापरत नसल्यास apply, म्हणून वापरले जाऊ शकते edit, आणि patch, केल्या जाणाऱ्या बदलासाठी सर्वोत्तम अनुकूल असलेली कमांड निवडणे. BOM गुणधर्म जोडताना आणि बदलताना, दोन्ही दृष्टिकोन अंदाजे समान असतात. तपशील गुणधर्म किंवा अॅरे घटक हटवताना edit एक-वेळ लाँच सारखे वागते apply, संपादनापूर्वी आणि नंतर तपशील कसा होता याचा मागोवा ठेवण्यासह, जेणेकरून तुम्ही स्त्रोतामधून गुणधर्म आणि अॅरे घटक स्पष्टपणे काढून टाकू शकता. तुम्हाला स्पेसिफिकेशनमध्ये स्पष्टपणे प्रॉपर्टी व्हॅल्यू शून्य वर सेट करणे आवश्यक आहे patchसंसाधनातून काढून टाकण्यासाठी. स्ट्रॅटेजिक-मर्ज पॅचिंग वापरून अॅरे घटक काढून टाकणे अधिक क्लिष्ट आहे कारण त्यासाठी मर्ज निर्देशांचा वापर आवश्यक आहे. अधिक व्यवहार्य पर्यायांसाठी खाली इतर अपग्रेड पध्दती पहा.

क्लायंट लायब्ररीमध्ये अद्ययावत पद्धती लागू करण्यासाठी जे वरील आदेशांप्रमाणेच वागतात kubectl, विनंत्यांमध्ये सेट केले पाहिजे content-type в application/strategic-merge-patch+json. तुम्हाला स्पेसिफिकेशनमधील गुणधर्म काढून टाकायचे असल्यास, तुम्हाला त्यांची व्हॅल्यू स्पष्टपणे अशाच प्रकारे शून्य करण्यासाठी सेट करणे आवश्यक आहे. kubectl patch. तुम्हाला अॅरे घटक काढून टाकायचे असल्यास, तुम्ही अपडेट स्पेसिफिकेशनमध्ये मर्ज निर्देश समाविष्ट केले पाहिजेत किंवा अपडेट्ससाठी वेगळा दृष्टिकोन वापरावा.

अद्यतनांसाठी इतर दृष्टिकोन

Kubernetes दोन इतर अद्यतन पद्धतींना समर्थन देते: JSON मर्ज पॅच и JSON पॅच. JSON विलीन पॅच दृष्टिकोन इनपुट म्हणून आंशिक Kubernetes तपशील घेते आणि स्ट्रॅटेजिक-मर्ज पॅचिंग दृष्टिकोनाप्रमाणेच विलीन वस्तूंना समर्थन देते. दोघांमधील फरक असा आहे की ते पॉड स्पेसिफिकेशनमधील कंटेनर अॅरेसह केवळ अॅरे बदलण्याचे समर्थन करते. याचा अर्थ असा की JSON मर्ज पॅच वापरताना, कोणत्याही कंटेनरची मालमत्ता बदलल्यास तुम्हाला सर्व कंटेनरसाठी संपूर्ण तपशील प्रदान करणे आवश्यक आहे. त्यामुळे बीओएममधील अॅरेमधून घटक काढून टाकण्यासाठी हा दृष्टिकोन उपयुक्त आहे. कमांड लाइनवर तुम्ही JSON मर्ज पॅच वापरून निवडू शकता kubectl patch --type=merge. Kubernetes API सह काम करताना, तुम्ही विनंती पद्धत वापरावी PATCH आणि स्थापना content-type в application/merge-patch+json.

JSON पॅच दृष्टीकोन, संसाधनाचे आंशिक तपशील प्रदान करण्याऐवजी, आपण अ‍ॅरे म्हणून संसाधनामध्ये करू इच्छित बदल प्रदान करणे वापरतो, ज्यामध्ये अ‍ॅरेचा प्रत्येक घटक संसाधनामध्ये केलेल्या बदलाचे वर्णन दर्शवतो. केले जाणारे बदल व्यक्त करण्याचा हा दृष्टीकोन अधिक लवचिक आणि शक्तिशाली मार्ग आहे, परंतु आंशिक संसाधन तपशील पाठवण्याऐवजी वेगळ्या, कुबरनेट नसलेल्या स्वरूपात बदल सूचीबद्ध करण्याच्या किंमतीवर. IN kubectl तुम्ही JSON पॅच वापरून निवडू शकता kubectl patch --type=json. Kubernetes API वापरताना, हा दृष्टिकोन विनंती पद्धती वापरून कार्य करतो PATCH आणि स्थापना content-type в application/json-patch+json.

आम्हाला आत्मविश्वास हवा आहे - बदली वापरा

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

• A आणि B ला API मधून संसाधनाची वर्तमान स्थिती मिळते
• प्रत्येक एकाने काउंटर वाढवून आणि "अपडेट-बाय" नोटमध्ये अनुक्रमे "A" किंवा "B" जोडून स्पेसिफिकेशन अद्यतनित करते.
• आणि ते संसाधन थोडे जलद अद्यतनित करते
• B संसाधन अद्यतनित करते

परिणामी, अद्यतन A गमावला आहे. शेवटचे ऑपरेशन patch जिंकला, काउंटर दोन ऐवजी एकाने वाढवला जातो आणि "अपडेट-बाय" नोटचे मूल्य "B" ने समाप्त होते आणि त्यात "A" नसते. दृष्टीकोन वापरून अद्यतने केली जातात तेव्हा काय होते याच्याशी वरील तुलना करूया replace:

• A आणि B ला API मधून संसाधनाची वर्तमान स्थिती मिळते
• प्रत्येक एकाने काउंटर वाढवून आणि "अपडेट-बाय" नोटमध्ये अनुक्रमे "A" किंवा "B" जोडून स्पेसिफिकेशन अद्यतनित करते.
• आणि ते संसाधन थोडे जलद अद्यतनित करते
• B संसाधन अद्यतनित करण्याचा प्रयत्न करतो, परंतु संसाधन आवृत्ती तपशीलामध्ये असल्यामुळे API ने अद्यतन नाकारले आहे replace कुबर्नेट्स मधील संसाधनाच्या वर्तमान आवृत्तीशी जुळत नाही कारण संसाधनाची आवृत्ती A च्या बदली ऑपरेशनने वाढवली होती.

वरील बाबतीत, B ला संसाधन पुन्हा आणावे लागेल, नवीन स्थितीत बदल करावे लागतील आणि पुन्हा प्रयत्न करावा लागेल replace. यामुळे काउंटर दोनने वाढवले ​​जाईल आणि "अपडेट-बाय" नोटमध्ये शेवटी "AB" समाविष्ट होईल.

वरील उदाहरणाचा अर्थ असा होतो की कार्यान्वित करताना replace संपूर्ण संसाधन पूर्णपणे बदलले आहे. साठी वापरलेले तपशील replace, आंशिक किंवा मध्ये प्रमाणे भाग असू नये apply, परंतु जोडण्यासह पूर्ण resourceVersion तपशील मेटाडेटा मध्ये. आपण सक्षम केले नसल्यास resourceVersion किंवा तुम्ही प्रदान केलेली आवृत्ती सध्याची नाही, बदली नाकारली जाईल. म्हणून वापरण्यासाठी सर्वोत्तम दृष्टीकोन आहे replace - संसाधन वाचा, ते अद्यतनित करा आणि त्वरित बदला. वापरत आहे kubectl, हे असे दिसू शकते:

$ kubectl get deployment my-deployment -o json 
    | jq '.spec.template.spec.containers[0].env[1].value = "new value"' 
    | kubectl replace -f -

हे लक्षात घेण्यासारखे आहे की खालील दोन आज्ञा, क्रमशः अंमलात आणल्या गेल्या, यशस्वीरित्या कार्यान्वित होतील, कारण deployment.yaml मालमत्ता समाविष्ट नाही .metadata.resourceVersion

$ kubectl create -f deployment.yaml
$ kubectl replace -f deployment.yaml

हे वर सांगितलेल्या गोष्टीच्या विरोधाभास वाटेल, म्हणजे. "जोडून resourceVersion स्पेसिफिकेशन मेटाडेटामध्ये." असे म्हणणे चुकीचे आहे का? नाही, तसे नाही, कारण जर kubectl तुम्ही निर्दिष्ट न केलेल्या सूचना resourceVersion, ते ते रिसोर्समधून वाचेल आणि तुम्ही निर्दिष्ट केलेल्या स्पेसिफिकेशनमध्ये जोडेल आणि त्यानंतरच ते कार्यान्वित करेल replace. कारण आपण अणुशक्तीवर अवलंबून राहिल्यास हे संभाव्य धोकादायक आहे, जादू पूर्णपणे बाजूला कार्य करते kubectl, API सह कार्य करणाऱ्या क्लायंट लायब्ररी वापरताना तुम्ही त्यावर अवलंबून राहू नये. या प्रकरणात तुम्हाला वर्तमान संसाधन तपशील वाचावे लागेल, ते अद्यतनित करावे लागेल आणि नंतर कार्यान्वित करावे लागेल PUT विनंती

तुम्ही पॅच करू शकत नाही - आम्ही बदलतो

कधीकधी तुम्हाला काही बदल करावे लागतात जे API द्वारे हाताळले जाऊ शकत नाहीत. या प्रकरणांमध्ये, आपण संसाधन हटवून आणि पुन्हा तयार करून बदलण्याची सक्ती करू शकता. हे वापरून केले जाते kubectl replace --force. कमांड रन केल्याने संसाधने ताबडतोब काढून टाकली जातात आणि नंतर त्यांना पुरवलेल्या स्पेसिफिकेशनमधून पुन्हा तयार केले जाते. API मध्ये कोणतेही "फोर्स रिप्लेस" हँडलर नाही आणि API द्वारे असे करण्यासाठी, तुम्हाला दोन ऑपरेशन्स करणे आवश्यक आहे. प्रथम तुम्हाला त्यासाठी सेट करून संसाधन हटवणे आवश्यक आहे gracePeriodSeconds शून्य (0) पर्यंत आणि propagationPolicy "पार्श्वभूमी" मध्ये आणि नंतर इच्छित तपशीलासह हे संसाधन पुन्हा तयार करा.

चेतावणी: हा दृष्टीकोन संभाव्य धोकादायक आहे आणि एक अपरिभाषित स्थिती होऊ शकते.

सर्व्हरच्या बाजूला अर्ज करा

वर नमूद केल्याप्रमाणे, Kubernetes विकासक तर्क लागू करण्यावर काम करत आहेत apply पासून kubectl Kubernetes API मध्ये. तर्कशास्त्र apply Kubernetes 1.18 द्वारे उपलब्ध kubectl apply --server-side किंवा पद्धत वापरून API द्वारे PATCH с content-type application/apply-patch+YAML.

टीप: JSON देखील वैध YAML आहे, त्यामुळे तुम्ही JSON म्हणून तपशील पाठवू शकता जरी content-type असेल application/apply-patch+yaml.

त्याशिवाय तर्क kubectl API द्वारे प्रत्येकासाठी उपलब्ध होते, apply सर्व्हरच्या बाजूने, स्पेसिफिकेशनमधील फील्डसाठी कोण जबाबदार आहे याचा मागोवा ठेवते, अशा प्रकारे विवाद-मुक्त संपादनासाठी सुरक्षित एकाधिक प्रवेशास अनुमती देते. दुसऱ्या शब्दांत, जर apply सर्व्हरच्या बाजूने अधिक व्यापक होईल, विविध क्लायंटसाठी एक सार्वत्रिक सुरक्षित संसाधन व्यवस्थापन इंटरफेस दिसेल, उदाहरणार्थ, kubectl, Pulumi किंवा Terraform, GitOps, तसेच क्लायंट लायब्ररी वापरून स्व-लिखित स्क्रिप्ट.

परिणाम

मला आशा आहे की क्लस्टर्समध्ये संसाधने अद्यतनित करण्याच्या विविध मार्गांचे हे संक्षिप्त विहंगावलोकन तुमच्यासाठी उपयुक्त ठरले. हे जाणून घेणे चांगले आहे की ते फक्त लागू विरुद्ध बदलणे नाही; लागू करा, संपादित करा, पॅच करा किंवा बदला वापरून संसाधन अद्यतनित करणे शक्य आहे. तथापि, तत्वतः, प्रत्येक दृष्टिकोनाचे स्वतःचे अनुप्रयोग क्षेत्र असते. अणु बदलांसाठी, पुनर्स्थित करणे श्रेयस्कर आहे; अन्यथा, तुम्ही लागू करून स्ट्रॅटेजिक-मर्ज पॅच वापरावा. कमीतकमी, मी तुम्हाला हे समजण्याची अपेक्षा करतो की "kubernetes apply vs replace" शोधताना तुम्ही Google किंवा StackOerflow वर विश्वास ठेवू शकत नाही. किमान हा लेख सध्याच्या उत्तराची जागा घेईपर्यंत.

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