☝🏾 👨🏼‍💼 👦🏽 3-वेफ में मर्ज: हेल्म के साथ कुबेरनेट्स में तैनाती "स्टेरॉयड पर" ♒️ 😥 🕠

कुछ ऐसा हुआ कि हम (और न केवल हमें) इंतजार कर रहे थे: वेयरफ , अनुप्रयोगों के निर्माण और उन्हें कुबेरनेट्स तक पहुंचाने के लिए हमारी ओपन सोर्स उपयोगिता, अब 3-वे-मर्ज पैच का उपयोग करके परिवर्तन लागू करने का समर्थन करता है! इसके अलावा, इन संसाधनों को फिर से बनाए बिना हेल्म रिलीज में मौजूदा K8s संसाधनों को अपनाना संभव हो गया।

यदि यह बहुत छोटा है, तो WERF_THREE_WAY_MERGE=enabled सेट करें - हमें तैनाती " kubectl apply ", हेल्म 2 पर मौजूदा प्रतिष्ठानों के साथ संगत और यहां तक कि थोड़ी अधिक।

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

3-वे-मर्ज पैच क्या है?

तो, आइए कुबेरनेट्स में यमल के मैनिफेस्टों में वर्णित संसाधनों को रोल आउट करने के कार्य के साथ शुरू करें।

संसाधनों के साथ काम करने के लिए, कुबेरनेट्स एपीआई निम्नलिखित बुनियादी संचालन प्रदान करता है: बनाएँ, पैच, बदलें, और हटाएं। यह माना जाता है कि उनकी मदद से क्लस्टर के लिए संसाधनों का एक सुविधाजनक निरंतर रोलआउट करना आवश्यक है। कैसे?

इंपीरियल कुबेकल टीमें

कुबेरनेट्स में वस्तुओं के प्रबंधन के लिए पहला दृष्टिकोण इन वस्तुओं को बनाने, संशोधित करने और हटाने के लिए आवश्यक है। सीधे शब्दों में कहें:

kubectl run कमांड परिनियोजन या नौकरी चला सकते हैं:
```
 kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE 
```
kubectl scale कमांड - प्रतिकृतियों की संख्या बदलें:
```
 kubectl scale --replicas=3 deployment/mysql 
```
आदि

ऐसा दृष्टिकोण पहली नज़र में सुविधाजनक लग सकता है। हालाँकि, समस्याएं हैं:

इसे स्वचालित करना कठिन है।
Git में कॉन्फ़िगरेशन को कैसे प्रतिबिंबित करें? क्लस्टर में होने वाले परिवर्तनों की समीक्षा कैसे करें?
पुनरारंभ पर कॉन्फ़िगरेशन की प्रतिलिपि कैसे सुनिश्चित करें?
...

यह स्पष्ट है कि यह दृष्टिकोण कोड (IaC; या यहां तक कि GitOps को कुबेरनेट्स पारिस्थितिकी तंत्र में लोकप्रियता प्राप्त करने के रूप में) के रूप में एप्लिकेशन कोड और बुनियादी ढांचे को संग्रहीत करने के साथ अच्छी तरह से फिट नहीं है। इसलिए, इन टीमों को कुबेटेल में और अधिक विकास नहीं मिला।

संचालन बनाएं, प्राप्त करें, बदलें और हटाएं

प्राथमिक निर्माण के साथ, सब कुछ सरल है: हम क्यूब आपी के create लिए प्रकटन भेजते हैं और संसाधन बनाया जाता है। मैनिफ़ेल का प्रतिनिधित्व प्रतिनिधित्व Git में संग्रहित किया जा सकता है, और बनाने के लिए, kubectl create -f manifest.yaml उपयोग करें kubectl create -f manifest.yaml कमांड।

हटाना भी सरल है: हम Git से kubectl delete -f manifest.yaml कमांड में एक ही manifest.yaml kubectl delete -f manifest.yaml विकल्प देते हैं।

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

Git में कॉन्फ़िगरेशन को स्टोर करने के लिए और प्रतिस्थापन का उपयोग करके अपडेट करने के लिए, आपको एक ऑपरेशन करने की आवश्यकता है, Git से कॉन्फ़िगरेशन को पकड़ें जो हमें मिला है, और replace । आम तौर पर, kubectl आपको केवल kubectl replace -f manifest.yaml कमांड का उपयोग करने की अनुमति देता है, जहां manifest.yaml kubectl replace -f manifest.yaml पूरी तरह से तैयार है (हमारे मामले में, आसन्न) प्रकट है जिसे आपको स्थापित करने की आवश्यकता है। यह पता चला है कि उपयोगकर्ता को मर्ज मैनिफेस्टों को लागू करने की आवश्यकता है, लेकिन यह एक मामूली मामला नहीं है ...

यह भी ध्यान देने योग्य है कि यद्यपि manifest.yaml .yaml Git में संग्रहीत है, हम पहले से नहीं जान सकते हैं कि हमें कोई ऑब्जेक्ट बनाने या इसे अपडेट करने की आवश्यकता है - यह उपयोगकर्ता सॉफ़्टवेयर द्वारा किया जाना चाहिए।

नीचे पंक्ति: क्या हम यह सुनिश्चित कर सकते हैं कि कोड, और सुविधाजनक CI / CD के साथ ही यह सुनिश्चित किया जाए कि इन्फ्रास्ट्रक्चर कॉन्फ़िगरेशन को Git में स्टोर किया जाए, केवल बनाने, बदलने और हटाने के साथ एक निरंतर रोलआउट ?

मूल रूप से, हम कर सकते हैं ... ऐसा करने के लिए, हमें मैनिफ़ेस्ट के मर्ज ऑपरेशन को लागू करने की आवश्यकता है और कुछ प्रकार के बंधन हैं:

क्लस्टर में किसी वस्तु की उपस्थिति के लिए जाँच,
संसाधन का प्रारंभिक निर्माण करता है,
अद्यतन या इसे हटाता है।

अपडेट करते समय, आपको यह विचार करने की आवश्यकता है कि संसाधन पिछले get होने के बाद बदल गया है और स्वचालित रूप से आशावादी लॉकिंग के मामले को संभाल सकता है - अपडेट करने के लिए बार-बार प्रयास करें।

हालांकि, जब क्यूब-एपेसेवर संसाधनों को अपडेट करने का एक और तरीका प्रदान करता है तो पहिया को फिर से क्यों करें: patch ऑपरेशन, जो उपयोगकर्ता से वर्णित कुछ समस्याओं को दूर करता है?

पैच

तो हम पैच पर चढ़ गए।

पैच कुबेरनेट्स में मौजूदा वस्तुओं में परिवर्तन लागू करने का प्राथमिक तरीका है। patch ऑपरेशन इतना काम करता है:

kube-apiserver उपयोगकर्ता को JSON प्रारूप में पैच भेजने और ऑब्जेक्ट को निर्दिष्ट करने की आवश्यकता है,
और माफीकर्ता स्वयं वस्तु की वर्तमान स्थिति से निपटेगा और उसे वांछित रूप में लाएगा।

इस मामले में आशावादी लॉकिंग की आवश्यकता नहीं है। यह ऑपरेशन प्रतिस्थापित करने की तुलना में अधिक घोषणात्मक है, हालांकि पहले तो यह दूसरे तरीके से लग सकता है।

इस तरह से:

create ऑपरेशन का उपयोग करते हुए, हम Git से प्रकट वस्तु से एक वस्तु बनाते हैं,
delete का उपयोग करना - यदि ऑब्जेक्ट की आवश्यकता नहीं है, तो डिलीट करें,
patch का उपयोग करना - हम ऑब्जेक्ट को संशोधित करते हैं, इसे गिट में वर्णित रूप में लाते हैं।

हालाँकि, ऐसा करने के लिए, आपको सही पैच बनाना होगा!

हेल्म 2: 2-वे-मर्ज में पैच कैसे काम करते हैं

पहली बार रिलीज़ होने के बाद, हेल्म चार्ट संसाधनों पर एक create ऑपरेशन करता है।

प्रत्येक संसाधन के लिए हेल्म रिलीज को अपडेट करते समय:

पिछले चार्ट से संसाधन के संस्करण और चार्ट के वर्तमान संस्करण के बीच पैच की गणना करता है,
इस पैच को लागू करता है।

हम ऐसे पैच को 2-वे-मर्ज पैच कहेंगे, क्योंकि 2 घोषणापत्र इसके निर्माण में भाग लेते हैं:

पिछले रिलीज से संसाधन प्रकट,
वर्तमान संसाधन से संसाधन का प्रकटन।

हटाते समय, क्यूब एपिसेवर में delete ऑपरेशन उन संसाधनों के लिए कहा जाता है जो पिछली रिलीज में घोषित किए गए थे लेकिन वर्तमान में घोषित नहीं किए गए थे।

2 तरह के मर्ज पैच के साथ दृष्टिकोण में एक समस्या है: यह क्लस्टर में संसाधन की वास्तविक स्थिति और Git में प्रकट होने की वांछनीयता की ओर जाता है।

एक समस्या का एक उदाहरण

Git में, एक घोषणापत्र चार्ट पर संग्रहीत किया जाता है जिसमें परिनियोजन image फ़ील्ड का ubuntu:18.04 मान होता है ubuntu:18.04 ।
kubectl edit माध्यम से उपयोगकर्ता ने इस फ़ील्ड का मान बदलकर ubuntu:19.04 ।
जब आप चार्ट को फिर से तैनात करते हैं, तो हेल्म एक पैच उत्पन्न नहीं करता है , क्योंकि रिलीज के पिछले संस्करण में और वर्तमान चार्ट में image क्षेत्र समान हैं।
image की बार-बार तैनाती के बाद, ubuntu:19.04 बनी हुई है, हालांकि ubuntu:18.04 चार्ट पर लिखी गई है।

हम देसी हो गए और घोषणा को खो दिया।

एक सिंक्रनाइज़ संसाधन क्या है?

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

यह एक सिंक्रनाइज़ किए गए संसाधन के इस सामान्य नियम को बताता है: जब आप किसी संसाधन को रोल आउट करते हैं, तो आप केवल उन्हीं फ़ील्ड को बदल या हटा सकते हैं, जो स्पष्ट रूप से गिट से प्रकट में निर्दिष्ट हैं (या पिछले संस्करण में पंजीकृत थे, लेकिन अब हटा दिए गए हैं)।

3-रास्ता-मर्ज पैच

3-वे-मर्ज पैच का मुख्य विचार: हम गिट से प्रकट के अंतिम लागू संस्करण और गिट से प्रकट के लक्ष्य संस्करण के बीच एक पैच उत्पन्न करते हैं, काम कर रहे क्लस्टर से प्रकट होने के वर्तमान संस्करण को ध्यान में रखते हैं। अंतिम पैच को सिंक्रनाइज़ संसाधन नियम का पालन करना चाहिए:

लक्ष्य संस्करण में जोड़े गए नए फ़ील्ड पैच का उपयोग करके जोड़े गए हैं;
पिछले लागू संस्करण में पहले से मौजूद फ़ील्ड और लक्ष्य फ़ील्ड में मौजूद मौजूदा पैच का उपयोग करके रीसेट नहीं किया गया है;
ऑब्जेक्ट के वर्तमान संस्करण में फ़ील्ड्स जो पैच के उपयोग से प्रकट के लक्ष्य संस्करण से भिन्न होते हैं।

यह इस सिद्धांत के अनुसार है कि kubectl apply पैच उत्पन्न होते हैं:

प्रकट के अंतिम लागू संस्करण को ऑब्जेक्ट के एनोटेशन में ही संग्रहीत किया जाता है,
लक्ष्य - निर्दिष्ट YAML फ़ाइल से लिया गया,
वर्तमान - एक कामकाजी क्लस्टर से।

अब जब हमने सिद्धांत का पता लगा लिया है, तो यह बताने का समय आ गया है कि हमने क्या किया।

Werf में परिवर्तन लागू करें

इससे पहले, हर्फ 2 की तरह, werf, 2-तरह-मर्ज पैच का उपयोग करता था।

मरम्मत पैच

एक नए प्रकार के पैच पर स्विच करने के लिए - 3-वे-मर्ज - पहला कदम हमने तथाकथित मरम्मत पैच पेश किया ।

तैनाती मानक 2-तरह-मर्ज पैच का उपयोग करता है, लेकिन werf अतिरिक्त रूप से एक पैच उत्पन्न करता है जो कि Git में लिखे गए संसाधन की वास्तविक स्थिति को सिंक्रनाइज़ करता है (ऐसा पैच ऊपर वर्णित समान सिंक्रनाइज़ किए गए संसाधन नियम का उपयोग करके बनाया गया है)।

एक rassynchron की स्थिति में, परिनियोजन के अंत में, उपयोगकर्ता को उचित संदेश और पैच के साथ एक चेतावनी प्राप्त होती है, जिसे संसाधन को सिंक्रनाइज़ रूप में लाने के लिए लागू किया जाना चाहिए। इसके अलावा, यह पैच एक विशेष एनोटेशन werf.io/repair-patch में रिकॉर्ड किया गया है। यह माना जाता है कि उपयोगकर्ता स्वयं अपने हाथों से इस पैच को लागू करेगा : सिद्धांत में इसे लागू नहीं करेगा।

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

केवल नए रिलीज के लिए 3-तरह-मर्ज पैच

1 दिसंबर, 2019 से, पूर्ण रूप से 3-तरह-मर्ज पैच का उपयोग करने के लिए डिफ़ॉल्ट रूप से वेयरफ के बीटा-और अल्फा संस्करण शुरू होते हैं, केवल नए हेलम रिलीज के लिए परिवर्तन लागू करने के लिए। मौजूदा रिलीज़ 2-तरह-मर्ज + मरम्मत पैच दृष्टिकोण का उपयोग करना जारी रखेगा।

इस ऑपरेटिंग मोड को अभी WERF_THREE_WAY_MERGE_MODE=onlyNewReleases सेट करके स्पष्ट रूप से सक्षम किया जा सकता है।

नोट : यह सुविधा कई रिलीज से अधिक वेयरफ में दिखाई दी: अल्फा चैनल में यह संस्करण v1.0.5-Alpha.19 से तैयार हो गया, और बीटा चैनल में v1.0.4-beta.20 के साथ ।

सभी रिलीज के लिए 3-तरह-मर्ज पैच

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

WERF_THREE_WAY_MERGE_MODE=enabled अब WERF_THREE_WAY_MERGE_MODE=enabled ऑपरेशन के इस मोड को स्पष्ट रूप से WERF_THREE_WAY_MERGE_MODE=enabled जा सकता है।

ऑटोसैसलिंग संसाधनों के साथ क्या करना है?

कुबेरनेट्स में 2 प्रकार के ऑटोस्कोलिंग हैं: एचपीए (क्षैतिज) और वीपीए (ऊर्ध्वाधर)।

क्षैतिज स्वचालित रूप से प्रतिकृतियों की संख्या का चयन करता है, ऊर्ध्वाधर - संसाधनों की संख्या। संसाधन प्रकट में प्रतिकृति और संसाधन आवश्यकताओं की संख्या दोनों निर्दिष्ट हैं (देखें spec.replicas या spec.containers[].resources.limits.cpu , spec.containers[].resources.limits.memory और अन्य )।

समस्या: यदि कोई उपयोगकर्ता किसी संसाधन को चार्ट पर कॉन्फ़िगर करता है जिससे कि वह संसाधनों के लिए विशिष्ट मान प्रदर्शित करता है या इस संसाधन के लिए प्रतिकृतियां और ऑटो-स्केलर्स सक्षम हैं, तो प्रत्येक तैनाती वाले werf इन मूल्यों को चार्ट मेनिफेस्ट में लिखे गए मानों को रीसेट कर देगा।

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

werf.io/set-replicas-only-on-creation=true
werf.io/set-resources-only-on-creation=true

यदि ऐसा कोई एनोटेशन है, तो हर्फ प्रत्येक तैनाती पर संबंधित मानों को रीसेट नहीं करेगा, लेकिन केवल उन्हें संसाधन के प्रारंभिक निर्माण में सेट करें।

अधिक जानकारी के लिए, HPA और VPA के लिए प्रोजेक्ट दस्तावेज़ देखें।

3-वे-मर्ज पैच का उपयोग अस्वीकार करें

उपयोगकर्ता अभी भी पर्यावरण चर WERF_THREE_WAY_MERGE_MODE=disabled का उपयोग करके वेयरफ में नए पैच के उपयोग को प्रतिबंधित कर सकता है। हालाँकि, 1 मार्च, 2020 से, यह प्रतिबंध काम करना बंद कर देगा और केवल 3-वे-मर्ज पैच का उपयोग करना संभव होगा।

वसेफ में संसाधनों को अपनाना

3-वे-मर्ज-पैच में परिवर्तनों को लागू करने की विधि को माहिर करने से हमें इस तरह की सुविधा को तुरंत लागू करने की अनुमति मिली क्योंकि हेल्म-रिलीज में क्लस्टर में मौजूद संसाधनों को अपनाना।

हेल्म 2 में एक समस्या है: आप एक संसाधन को चार्ट मेनिफेस्ट में नहीं जोड़ सकते जो पहले से ही क्लस्टर में मौजूद है, इस संसाधन को खरोंच से फिर से बनाए बिना ( # 6031 , # 3275 देखें )। हमने एक रिलीज में मौजूदा संसाधनों को स्वीकार करने के लिए वर्फ को सिखाया। ऐसा करने के लिए, आपको एक रनिंग क्लस्टर से संसाधन के वर्तमान संस्करण पर एक एनोटेशन सेट करने की आवश्यकता है (उदाहरण के लिए, kubectl edit का उपयोग करके):

 "werf.io/allow-adoption-by-release": RELEASE_NAME

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

नोट : WERF_THREE_WAY_MERGE_MODE सेटिंग संसाधनों को अपनाने को प्रभावित नहीं करता है - गोद लेने के मामले में, 3-तरह-मर्ज पैच का हमेशा उपयोग किया जाता है।

विवरण प्रलेखन में हैं ।

निष्कर्ष और भविष्य की योजनाएं

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

हेल-जैसी तैनाती में अभी भी कुछ समस्याएं और कठिनाइयाँ हैं, जैसे कि गो-टेम्प्लेट का उपयोग, और हम उन्हें हल करना जारी रखेंगे।

संसाधन अद्यतन विधियों और गोद लेने की जानकारी भी इस प्रलेखन पृष्ठ पर पाई जा सकती है।

पतवार ३

एक विशेष नोट हेल्म - v3 के हाल ही में जारी किए गए नए प्रमुख संस्करण के योग्य है - जिसमें 3-वे-मर्ज पैच का उपयोग किया जाता है और टिलर से छुटकारा मिलता है। हेल्म के नए संस्करण को मौजूदा इंस्टॉलेशन के माइग्रेशन की आवश्यकता है ताकि उन्हें नए रिलीज स्टोरेज प्रारूप में परिवर्तित किया जा सके।

Werf, ने अपने हिस्से के लिए, अब Tiller के उपयोग को समाप्त कर दिया है, 3-वे-मर्ज में बदल दिया है और बहुत कुछ जोड़ा है, जबकि Helm 2 पर मौजूदा इंस्टॉलेशन के साथ शेष रहना (कोई माइग्रेशन स्क्रिप्ट आवश्यक नहीं है)। इसलिए, जब तक werf को Helm 3 में बदल दिया जाता है, तब तक werf उपयोगकर्ता Helm 2 के मुख्य लाभ से नहीं चूकते हैं (वे भी werf में मौजूद हैं)।

हालाँकि, हर्फ 3 कोडबेस पर वरीफ स्विच करना अपरिहार्य है और निकट भविष्य में होगा। संभवतया यह १.f या १.४ से होगा। (फिलहाल, यहाँ देखें। इस समय के दौरान, हेल्म 3 को स्थिर करने का समय होगा।

पुनश्च

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

3-वेफ में मर्ज: हेल्म के साथ कुबेरनेट्स में तैनाती "स्टेरॉयड पर"