कुबेरनेट्स की उचित तुलना लागू करें, बदलें और पैच करें

कुबेरनेट्स के पास संसाधनों को अद्यतन करने के लिए कई विकल्प हैं: लागू करें, संपादित करें, पैच करें और बदलें। इस बात को लेकर भ्रम है कि प्रत्येक व्यक्ति क्या करता है और उनका उपयोग कब करना है। आइए इसका पता लगाएं।

अगर गूगल पर खोजें वाक्यांश "कुबेरनेट्स अप्लाई बनाम रिप्लेस" स्थित है StackOverflow को उत्तर दें, जो सही नहीं है. खोजते समय "कुबेरनेट्स अप्लाई बनाम पैच" के लिए पहला लिंक दस्तावेज़ीकरण है kubectl patch, जिसमें तुलना शामिल नहीं है apply и patch. यह आलेख विभिन्न विकल्पों के साथ-साथ प्रत्येक के उचित उपयोग पर भी गौर करेगा।

कुबेरनेट्स संसाधन (सेवा, परिनियोजन, प्रवेश, आदि) के जीवनचक्र के दौरान, कभी-कभी आपको इस संसाधन के कुछ गुणों को बदलने, जोड़ने या हटाने की आवश्यकता होती है। उदाहरण के लिए, एक नोट जोड़ें, प्रतिकृतियों की संख्या बढ़ाएँ या घटाएँ।

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

यदि आप पहले से ही सीएलआई के माध्यम से कुबेरनेट्स क्लस्टर के साथ काम कर रहे हैं, तो आप पहले से ही परिचित हैं apply и edit. टीम apply फ़ाइल से संसाधन विनिर्देश पढ़ता है और कुबेरनेट्स क्लस्टर में "अपसर्ट" बनाता है, अर्थात। यदि संसाधन मौजूद नहीं है तो उसे बनाता है और यदि मौजूद है तो उसे अद्यतन करता है। टीम edit एपीआई के माध्यम से एक संसाधन को पढ़ता है, फिर संसाधन विनिर्देश को एक स्थानीय फ़ाइल में लिखता है, जिसे बाद में एक टेक्स्ट एडिटर में खोला जाता है। फ़ाइल को संपादित और सहेजने के बाद, kubectl एपीआई के माध्यम से किए गए परिवर्तनों को वापस भेज देगा, जो इन परिवर्तनों को संसाधन पर सावधानीपूर्वक लागू करेगा।

हर कोई आदेश नहीं जानता patch и replace. टीम patch आपको संसाधन विनिर्देश के भाग को बदलने की अनुमति देता है, केवल कमांड लाइन पर परिवर्तित भाग प्रदान करता है। टीम replace के समान ही कार्य करता है edit, लेकिन सब कुछ मैन्युअल रूप से करने की आवश्यकता है: आपको संसाधन विनिर्देश के वर्तमान संस्करण को डाउनलोड करने की आवश्यकता है, उदाहरण के लिए, का उपयोग करना kubectl get -o yaml, इसे संपादित करें, फिर उपयोग करें replace किसी संसाधन को बदले हुए विनिर्देश के अनुसार अद्यतन करना। टीम replace यदि संसाधन को पढ़ने और बदलने के बीच कोई परिवर्तन हुआ तो यह काम नहीं करेगा।

कुबेरनेट्स एपीआई

आप संभवतः तरीकों से परिचित हैं CoreV1().Pods().Update(), replaceNamespacedService या patch_namespaced_deployment, यदि आप क्लस्टर के साथ काम करते हैं कुबेरनेट्स एपीआई के लिए क्लाइंट लाइब्रेरी कुछ प्रोग्रामिंग भाषा का उपयोग करना। लाइब्रेरी इन विधियों को HTTP अनुरोधों के माध्यम से विधियों का उपयोग करके संभालती है PUT и PATCH. इस प्रकार update и replace प्रयुक्त PUTऔर patch, चाहे वह कितना भी तुच्छ क्यों न हो , उपयोग करता है PATCH.

यह ध्यान दिया जाना चाहिए कि kubectl एपीआई के माध्यम से क्लस्टर के साथ भी काम करता है। दूसरे शब्दों में, kubectlगो भाषा के लिए क्लाइंट लाइब्रेरी के शीर्ष पर एक रैपर है, जो मानक एपीआई क्षमताओं के अलावा उप-कमांड को अधिक कॉम्पैक्ट और पठनीय रूप में प्रदान करने की क्षमता प्रदान करता है। उदाहरण के लिए, जैसा कि आपने पहले ही देखा होगा, विधि apply पिछले पैराग्राफ में ऊपर उल्लेख नहीं किया गया था। वर्तमान में (मई 2020, लगभग। अनुवादक) सभी तर्क kubectl apply, अर्थात। गैर-मौजूद संसाधनों को बनाना और मौजूदा संसाधनों को अपडेट करना, पूरी तरह से कोड पक्ष पर काम करता है kubectl. प्रयास किये जा रहे हैं तर्क स्थानांतरण पर apply एपीआई पक्ष में, लेकिन यह अभी भी बीटा में है। मैं नीचे और अधिक विस्तार से लिखूंगा.

डिफ़ॉल्ट रूप से पैच करें

सबसे अच्छा इस्तेमाल किया गया patch, यदि आप संसाधन को अद्यतन करना चाहते हैं। कुबेरनेट्स एपीआई के शीर्ष पर दोनों क्लाइंट लाइब्रेरी इस प्रकार काम करती हैं kubectl (आश्चर्य की बात नहीं है, क्योंकि यह क्लाइंट लाइब्रेरी के लिए एक रैपर है, लगभग। अनुवादक).

रणनीतिक ढंग से काम करें

सभी दल kubectl apply, edit и patch विधि का प्रयोग करें PATCH किसी मौजूदा संसाधन को अद्यतन करने के लिए HTTP अनुरोधों में। यदि आप आदेशों के कार्यान्वयन पर अधिक विस्तार से विचार करते हैं, तो वे सभी दृष्टिकोण का उपयोग करते हैं रणनीतिक-विलय पैचिंग संसाधनों को अद्यतन करने के लिए, हालाँकि आदेश patch अन्य तरीकों का उपयोग कर सकते हैं (इस पर अधिक जानकारी नीचे दी गई है)। रणनीतिक-मर्ज पैचिंग दृष्टिकोण मौजूदा विनिर्देश के साथ आपूर्ति किए गए विनिर्देश को विलय करके "इसे सही करने" का प्रयास करता है। अधिक विशेष रूप से, यह वस्तुओं और सरणियों दोनों को संयोजित करने का प्रयास करता है, जिसका अर्थ है कि परिवर्तन योगात्मक होते हैं। उदाहरण के लिए, कमांड चलाना patch पॉड कंटेनर विनिर्देश में एक नए पर्यावरण चर के साथ, उस पर्यावरण चर को मौजूदा पर्यावरण चर में जोड़ने के बजाय उन्हें ओवरराइट करने का कारण बनता है। इस दृष्टिकोण का उपयोग करके हटाने के लिए, आपको दिए गए विनिर्देश में पैरामीटर मान को शून्य करने के लिए बाध्य करना होगा। कौन सी टीमें kubectl क्या अद्यतन करने के लिए इसका उपयोग करना सर्वोत्तम है?

यदि आप अपने संसाधनों का उपयोग करके बनाते और प्रबंधित करते हैं kubectl apply, अद्यतन करते समय इसे हमेशा उपयोग करना बेहतर होता है kubectl applyको kubectl कॉन्फ़िगरेशन को प्रबंधित कर सकता है और एप्लिकेशन से एप्लिकेशन में अनुरोधित परिवर्तनों को सही ढंग से ट्रैक कर सकता है। लाभ हमेशा उपयोग करें apply क्या यह पहले से लागू विनिर्देश का ट्रैक रखता है, जिससे यह पता चल जाता है कि विनिर्देश गुण और सरणी तत्व स्पष्ट रूप से कब हटा दिए गए हैं। यह आपको उपयोग करने की अनुमति देता है apply गुणों और सरणी तत्वों को हटाने के लिए, जबकि एक सामान्य रणनीतिक विलय काम नहीं करेगा। टीमें edit и patch नोट्स को अपडेट न करें kubectl apply इसके परिवर्तनों को ट्रैक करने के लिए उपयोग करता है, इसलिए कोई भी परिवर्तन जो ट्रैक किया जाता है और कुबेरनेट्स एपीआई के माध्यम से किया जाता है, लेकिन कमांड के माध्यम से किया जाता है edit и patch, बाद के आदेशों के लिए अदृश्य applyयही कारण है, apply भले ही वे इनपुट विनिर्देशन में प्रकट न हों, फिर भी उन्हें नहीं हटाता apply (दस्तावेज़ यह कहता है edit и patch उपयोग किए गए नोट्स को अपडेट करें apply, लेकिन व्यवहार में - नहीं)।

यदि आप कमांड का उपयोग नहीं करते हैं apply, के रूप में उपयोग किया जा सकता है editऔर patch, उस आदेश को चुनना जो किए जा रहे परिवर्तन के लिए सबसे उपयुक्त हो। बीओएम गुणों को जोड़ते और बदलते समय, दोनों दृष्टिकोण लगभग समान होते हैं। विनिर्देश गुणों या सरणी तत्वों को हटाते समय edit एक बार लॉन्च की तरह व्यवहार करता है apply, जिसमें संपादन के पहले और बाद में विनिर्देश कैसा था, इसका ट्रैक रखना शामिल है, ताकि आप किसी संसाधन से गुणों और सरणी तत्वों को स्पष्ट रूप से हटा सकें। आपको विनिर्देशन में संपत्ति मान को स्पष्ट रूप से शून्य पर सेट करने की आवश्यकता है patchइसे संसाधन से हटाने के लिए. रणनीतिक-मर्ज पैचिंग का उपयोग करके किसी सरणी तत्व को हटाना अधिक जटिल है क्योंकि इसमें मर्ज निर्देशों के उपयोग की आवश्यकता होती है। अधिक व्यवहार्य विकल्पों के लिए नीचे अन्य अपग्रेड दृष्टिकोण देखें।

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

अद्यतन के लिए अन्य दृष्टिकोण

कुबेरनेट्स दो अन्य अद्यतन दृष्टिकोणों का समर्थन करता है: JSON मर्ज पैच и JSON पैच. JSON मर्ज पैच दृष्टिकोण इनपुट के रूप में आंशिक कुबेरनेट्स विनिर्देश लेता है और रणनीतिक-मर्ज पैचिंग दृष्टिकोण के समान विलय वस्तुओं का समर्थन करता है। दोनों के बीच अंतर यह है कि यह केवल ऐरे प्रतिस्थापन का समर्थन करता है, जिसमें पॉड विनिर्देश में कंटेनर ऐरे भी शामिल है। इसका मतलब यह है कि JSON मर्ज पैच का उपयोग करते समय, आपको किसी भी कंटेनर की किसी भी संपत्ति में परिवर्तन होने की स्थिति में सभी कंटेनरों के लिए पूर्ण विनिर्देश प्रदान करने की आवश्यकता होती है। इसलिए यह दृष्टिकोण BOM में किसी सरणी से तत्वों को हटाने के लिए उपयोगी है। कमांड लाइन पर आप JSON मर्ज पैच का उपयोग करके चयन कर सकते हैं kubectl patch --type=merge. कुबेरनेट्स एपीआई के साथ काम करते समय, आपको अनुरोध विधि का उपयोग करना चाहिए PATCH और स्थापना content-type в application/merge-patch+json.

JSON पैच दृष्टिकोण, किसी संसाधन का आंशिक विनिर्देश प्रदान करने के बजाय, उन परिवर्तनों को प्रदान करने का उपयोग करता है जो आप संसाधन में एक सरणी के रूप में करना चाहते हैं, जिसमें सरणी का प्रत्येक तत्व संसाधन में किए जा रहे परिवर्तन का विवरण दर्शाता है। यह दृष्टिकोण किए जा रहे परिवर्तनों को व्यक्त करने का एक अधिक लचीला और शक्तिशाली तरीका है, लेकिन आंशिक संसाधन विनिर्देश भेजने के बजाय एक अलग, गैर-कुबेरनेट्स प्रारूप में किए जा रहे परिवर्तनों को सूचीबद्ध करने की कीमत पर। में kubectl आप JSON पैच का उपयोग करके चयन कर सकते हैं kubectl patch --type=json. कुबेरनेट्स एपीआई का उपयोग करते समय, यह दृष्टिकोण अनुरोध विधि का उपयोग करके काम करता है PATCH और स्थापना content-type в application/json-patch+json.

हमें आत्मविश्वास की आवश्यकता है - प्रतिस्थापित का उपयोग करें

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

• ए और बी को एपीआई से संसाधन की वर्तमान स्थिति मिलती है
• प्रत्येक व्यक्ति स्थानीय रूप से काउंटर को एक-एक बढ़ाकर और "अपडेटेड-बाय" नोट में क्रमशः "ए" या "बी" जोड़कर विनिर्देश को अपडेट करता है।
• और यह संसाधन को थोड़ी तेजी से अद्यतन करता है
• बी संसाधन को अद्यतन करता है

परिणामस्वरूप, अद्यतन A खो गया है। आखिरी ऑपरेशन patch जीतता है, काउंटर दो के बजाय एक से बढ़ जाता है, और "अपडेटेड-बाय" नोट का मूल्य "बी" के साथ समाप्त होता है और इसमें "ए" शामिल नहीं होता है। आइए उपरोक्त की तुलना इस बात से करें कि जब दृष्टिकोण का उपयोग करके अपडेट किया जाता है तो क्या होता है replace:

• ए और बी को एपीआई से संसाधन की वर्तमान स्थिति मिलती है
• प्रत्येक व्यक्ति स्थानीय रूप से काउंटर को एक-एक बढ़ाकर और "अपडेटेड-बाय" नोट में क्रमशः "ए" या "बी" जोड़कर विनिर्देश को अपडेट करता है।
• और यह संसाधन को थोड़ी तेजी से अद्यतन करता है
• बी संसाधन को अद्यतन करने का प्रयास करता है, लेकिन अद्यतन एपीआई द्वारा अस्वीकार कर दिया जाता है क्योंकि संसाधन संस्करण विनिर्देश में है replace कुबेरनेट्स में संसाधन के वर्तमान संस्करण से मेल नहीं खाता क्योंकि संसाधन का संस्करण ए के प्रतिस्थापन ऑपरेशन द्वारा बढ़ाया गया था।

उपरोक्त मामले में, बी को संसाधन फिर से लाना होगा, नई स्थिति में बदलाव करना होगा और फिर से प्रयास करना होगा replace. इससे काउंटर दो से बढ़ जाएगा और "अपडेटेड-बाय" नोट में अंत में "एबी" शामिल हो जाएगा।

उपरोक्त उदाहरण का तात्पर्य यह है कि निष्पादित करते समय 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, एपीआई के साथ काम करने वाली क्लाइंट लाइब्रेरी का उपयोग करते समय आपको इस पर भरोसा नहीं करना चाहिए। इस मामले में आपको वर्तमान संसाधन विनिर्देश को पढ़ना होगा, इसे अद्यतन करना होगा और फिर निष्पादित करना होगा PUT अनुरोध।

आप एक पैच नहीं कर सकते - हम एक प्रतिस्थापन करते हैं

कभी-कभी आपको कुछ बदलाव करने की ज़रूरत होती है जिन्हें एपीआई द्वारा नियंत्रित नहीं किया जा सकता है। इन मामलों में, आप संसाधन को हटाकर और पुनः बनाकर उसे बदलने के लिए बाध्य कर सकते हैं। इसका प्रयोग करके किया जाता है kubectl replace --force. कमांड चलाने से संसाधन तुरंत हटा दिए जाते हैं और फिर उन्हें आपूर्ति किए गए विनिर्देश से पुनः बनाया जाता है। एपीआई में कोई "फोर्स रिप्लेस" हैंडलर नहीं है, और एपीआई के माध्यम से ऐसा करने के लिए, आपको दो ऑपरेशन करने होंगे। सबसे पहले आपको इसके लिए सेटिंग करके संसाधन को हटाना होगा gracePeriodSeconds शून्य से (0) और propagationPolicy "पृष्ठभूमि" में और फिर वांछित विनिर्देश के साथ इस संसाधन को फिर से बनाएं।

चेतावनी: यह दृष्टिकोण संभावित रूप से खतरनाक है और अपरिभाषित स्थिति का कारण बन सकता है।

सर्वर साइड पर आवेदन करें

जैसा कि ऊपर उल्लेख किया गया है, कुबेरनेट्स डेवलपर्स तर्क को लागू करने पर काम कर रहे हैं apply से kubectl कुबेरनेट्स एपीआई में। लॉजिक्स apply कुबेरनेट्स 1.18 में उपलब्ध है kubectl apply --server-side या विधि का उपयोग करके एपीआई के माध्यम से PATCH с content-type application/apply-patch+YAML.

ध्यान दें: JSON भी मान्य YAML है, इसलिए आप विनिर्देशन को JSON के रूप में भी भेज सकते हैं content-type होगा application/apply-patch+yaml.

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

परिणाम

मुझे आशा है कि क्लस्टर में संसाधनों को अद्यतन करने के विभिन्न तरीकों का यह संक्षिप्त अवलोकन आपके लिए उपयोगी होगा। यह जानना अच्छा है कि यह केवल लागू बनाम प्रतिस्थापित नहीं है; किसी संसाधन को लागू करना, संपादित करना, पैच करना या प्रतिस्थापित करना संभव है। आखिरकार, सिद्धांत रूप में, प्रत्येक दृष्टिकोण का अपना आवेदन क्षेत्र होता है। परमाणु परिवर्तनों के लिए, प्रतिस्थापित करना बेहतर है; अन्यथा, आपको अप्लाई के माध्यम से रणनीतिक-मर्ज पैच का उपयोग करना चाहिए। कम से कम, मैं आपसे यह समझने की अपेक्षा करता हूं कि "कुबेरनेट्स अप्लाई बनाम रिप्लेस" खोजते समय आप Google या StackOerflow पर भरोसा नहीं कर सकते। कम से कम जब तक यह लेख वर्तमान उत्तर को प्रतिस्थापित नहीं कर देता।

स्रोत: www.habr.com