कुबेरनेट्स क्लस्टर
के संसाधनों को
हथियाने की आवश्यकता युद्ध की स्थिति में पैदा हो सकती है, जब आप उन्हें हेलम टूल्स के साथ फिर से नहीं बना सकते। दो मुख्य कारणों को प्रतिष्ठित किया जा सकता है:
- यह सरल होगा - चाहे आपके पास बादल या नंगे धातु हो।
- हटाने पर, बादलों में सेवाएं खो सकती हैं, साथ ही साथ कुबेरनेट्स में संबंधित लोड बैलेंसर्स उड़ जाएंगे।
हमारे मामले में, हमारे कुबेरनेट्स ऑपरेटर को एकीकृत करते हुए वर्किंग इनग्रेस-नग्नेक्स को पकड़ने के लिए एक समाधान की आवश्यकता थी।
हेल्म के लिए यह कड़ाई से अस्वीकार्य है कि वह जिन संसाधनों का प्रबंधन करता है, वे उसके द्वारा नहीं बनाए गए हैं।
"यदि आपकी टीम के रिलीज़ संसाधन मैन्युअल रूप से बदले जा सकते हैं, तो अनुभाग में वर्णित समस्याओं का सामना करने के लिए तैयार रहें: [BUG] बाहर रोल करने के बाद, क्लस्टर में रिलीज़ संसाधनों की स्थिति वर्णित हेलम चार्ट के अनुरूप नहीं है ।" (हमारे पिछले लेख से )
जैसा कि पहले उल्लेख किया गया था, हेल्म इस प्रकार काम करता है:
- प्रत्येक इंस्टॉलेशन (
helm install , helm upgrade कमांड) हेल्म स्टोरेज बैकएंड में जेनरेट किए गए रिलीज के डिस्प्ले को बचाता है। डिफ़ॉल्ट रूप से, कॉन्फ़िगैप का उपयोग किया जाता है: किसी रिलीज़ के प्रत्येक संशोधन के लिए, कॉन्फ़िगरमैप उसी नामस्थान में बनाया जाता है जिसमें टिलर चल रहा होता है। - बार-बार रोलआउट (
helm upgrade कमांड) के दौरान हेल्म कॉन्फिगरेशन से नवीनतम DEPLOYED रिलीज रिवीजन के पुराने प्रकटन के साथ नए उत्पन्न हुए प्रकट की तुलना करता है, और कुबेरनेट्स में परिणामी अंतर को लागू करता है।
इन विशेषताओं के आधार पर, हम इस निष्कर्ष पर पहुंचे हैं कि विन्यास (भंडारण बैकएंड रिलीज) को
लेने के लिए पैच करना पर्याप्त है, अर्थात। क्लस्टर में मौजूदा संसाधनों
को अपनाएं ।
Tiller निम्न प्रारूप में विन्यास मानचित्र को संदर्भित करता है:
%RELEASE_NAME.v%REVISION । मौजूदा
प्रविष्टियों को प्राप्त करने के लिए, आपको कमांड चलाना चाहिए
kubectl get cm -l OWNER=TILLER --namespace kube-system (डिफ़ॉल्ट रूप से, Tiller नामस्थान
kube-system में स्थापित
kube-system - अन्यथा आपको उपयोग किए गए एक को निर्दिष्ट करना होगा)।
$ kubectl get cm -l OWNER=TILLER -n kube-system NAME DATA AGE release_name_1.v618 1 5d release_name_1.v619 1 1d release_name_2.v1 1 2d release_name_2.v2 1 3d
प्रत्येक विन्यास मानचित्र इस प्रारूप में प्रस्तुत किया गया है:
apiVersion: v1 data: release: H4sIAHEEd1wCA5WQwWrDMAyG734Kwc52mtvwtafdAh27FsURjaljG1kp5O3nNGGjhcJ21M/nT7+stVZvcEozO7LAFAgLnSNOdG4boSkHFCpNIb55R2bBKSjM/ou4+BQt3Fp19XGwcNoINZHggIJWAayaH6leJ/24oTIBewplpQEwZ3Ode+JIdanxqXkw/D4CGClMpoyNG5HlmdAH05rDC6WPRTC6p2Iv4AkjXmjQ/WLh04dArEomt9aVJVfHMcxFiD+6muTEsl+i74OF961FpZEvJN09HEXyHmdOklwK1X7s9my7eYdK7egk8b8/6M+HfwNgE0MSAgIAAA== kind: ConfigMap metadata: creationTimestamp: 2019-02-08T11:12:38Z labels: MODIFIED_AT: "1550488348" NAME: release_name_1 OWNER: TILLER STATUS: DEPLOYED VERSION: "618" name: release_name_1.v618 namespace: kube-system resourceVersion: "298818981" selfLink: /api/v1/namespaces/kube-system/configmaps/release_name_1.v618 uid: 71c3e6f3-2b92-11e9-9b3c-525400a97005 ou4 + BQt3Fp19XGwcNoINZHggIJWAayaH6leJ / 24oTIBewplpQEwZ3Ode + JIdanxqXkw / D4CGClMpoyNG5HlmdAH05rDC6WPRTC6p2Iv4AkjXmjQ / WLh04dArEomt9aVJVfHMcxFiD + 6muTEsl + i74OF961FpZEvJN09HEXyHmdOklwK1X7s9my7eYdK7egk8b8 / 6M + HfwNgE0MSAgIAAA == apiVersion: v1 data: release: H4sIAHEEd1wCA5WQwWrDMAyG734Kwc52mtvwtafdAh27FsURjaljG1kp5O3nNGGjhcJ21M/nT7+stVZvcEozO7LAFAgLnSNOdG4boSkHFCpNIb55R2bBKSjM/ou4+BQt3Fp19XGwcNoINZHggIJWAayaH6leJ/24oTIBewplpQEwZ3Ode+JIdanxqXkw/D4CGClMpoyNG5HlmdAH05rDC6WPRTC6p2Iv4AkjXmjQ/WLh04dArEomt9aVJVfHMcxFiD+6muTEsl+i74OF961FpZEvJN09HEXyHmdOklwK1X7s9my7eYdK7egk8b8/6M+HfwNgE0MSAgIAAA== kind: ConfigMap metadata: creationTimestamp: 2019-02-08T11:12:38Z labels: MODIFIED_AT: "1550488348" NAME: release_name_1 OWNER: TILLER STATUS: DEPLOYED VERSION: "618" name: release_name_1.v618 namespace: kube-system resourceVersion: "298818981" selfLink: /api/v1/namespaces/kube-system/configmaps/release_name_1.v618 uid: 71c3e6f3-2b92-11e9-9b3c-525400a97005
उत्पन्न मैनिफ़ेस्ट बाइनरी फॉर्म (
.data.release कुंजी के साथ ऊपर के उदाहरण में) में संग्रहीत किए जाते हैं, इसलिए हमने मानक हेल्म टूल्स का उपयोग करके रिलीज़ बनाने का फैसला किया, लेकिन एक विशेष
ठूंठ के साथ , जिसे बाद में चयनित संसाधनों के अभिव्यक्तियों के साथ बदल दिया गया।
कार्यान्वयन
समाधान एल्गोरिथ्म इस प्रकार है:
- हम एक
manifest.yaml तैयार कर रहे हैं। गोद लेने के लिए संसाधन मेनिफ़ेस्ट के साथ फ़ाइल की आवश्यकता होती है (यह आइटम नीचे और अधिक विस्तार से चर्चा की जाएगी)। - हम एक चार्ट बनाते हैं जिसमें एक अस्थायी कॉन्फ़िगरेशन के साथ एक एकल टेम्पलेट होता है, क्योंकि बिना संसाधनों के हेल्म रिलीज नहीं बना सकता है।
- हम एक स्टब के साथ एक
templates/stub.yaml बनाते हैं, जो templates/stub.yaml में वर्णों की संख्या के बराबर होगी templates/stub.yaml (प्रयोगों के दौरान यह पता चला कि बाइट्स की संख्या से मेल खाना चाहिए)। एक स्टब के रूप में, एक प्रतिलिपि प्रस्तुत करने योग्य चरित्र सेट का चयन किया जाना चाहिए, जो पीढ़ी के बाद रहेगा और भंडारण बैकेंड में संग्रहीत किया जाएगा। सादगी और स्पष्टता के लिए, # उपयोग किया जाता है, अर्थात:
{{ repeat ${manifest_file_length} "#" }}
- चार्ट इंस्टॉल करें:
helm install और helm upgrade --install । - हम स्टोरेज बैकएंड रिलीज़ में स्टुब को रिप्लेस से
manifest.yaml करते हैं। manifest.yaml से गोद लेने के लिए चुने गए थे।
stub=$(printf '#%.0s' $(seq 1 ${manifest_file_length})) release_data=$(kubectl get -n ${tiller_namespace} cm/${release_name}.v1 -o json | jq .data.release -r) updated_release_data=$(echo ${release_data} | base64 -d | zcat | sed "s/${stub}/$(sed -z 's/\n/\\n/g' ${manifest_file_path} | sed -z 's/\//\\\//g')/" | gzip -9 | base64 -w0) kubectl patch -n ${tiller_namespace} cm/${release_name}.v1 -p '{"data":{"release":"'${updated_release_data}'"}}'
- हम जांचते हैं कि टिलर उपलब्ध है और हमारे परिवर्तनों को उठाया।
- अस्थायी कॉन्फ़िगरेशन मैप (दूसरे चरण से) को हटा दें।
- इसके अलावा, रिलीज के साथ काम नियमित से अलग नहीं है।
ऊपर वर्णित कार्यान्वयन के साथ प्रदान करें:
$ ./script.sh Example: ./script.sh foo bar-prod manifest.yaml Usage: ./script.sh CHART_NAME RELEASE_NAME MANIFEST_FILE_TO_ADOPT [TILLER_NAMESPACE]
स्क्रिप्ट के परिणामस्वरूप,
RELEASE_NAME की रिलीज़ बनाई गई है। यह उन संसाधनों से संबद्ध होता है, जिनका
MANIFEST_FILE_TO_ADOPT फ़ाइल में वर्णित है। एक
CHART_NAME चार्ट भी जनरेट किया गया है, जिसका उपयोग विशेष रूप से मैनिफ़ेस्ट और रिलीज़ के साथ किया जा सकता है।
संसाधनों के साथ प्रकट की तैयारी करते समय, कुबेरनेट द्वारा उपयोग किए जाने वाले सेवा क्षेत्रों को हटाना आवश्यक है (ये गतिशील सेवा डेटा हैं, इसलिए उन्हें हेल्म में संस्करणित करना गलत है)। एक आदर्श दुनिया में, प्रशिक्षण एक कमांड के लिए नीचे आता है:
kubectl get RESOURCE -o yaml --export । आखिरकार, प्रलेखन कहता है:
--export=false: If true, use 'export' for the resources. Exported resources are stripped of cluster-specific information.
... लेकिन, जैसा कि अभ्यास से पता चला है,
--export विकल्प अभी भी
--export , इसलिए अतिरिक्त प्रकट स्वरूपण की आवश्यकता होगी। नीचे दी गई
service/release-name-habr , आपको
selfLink और
selfLink को हटाना होगा।
kubectl संस्करण $ kubectl version Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.3", GitCommit:"721bfa751924da8d1680787490c54b9179b1fed0", GitTreeState:"clean", BuildDate:"2019-02-01T20:08:12Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.3", GitCommit:"721bfa751924da8d1680787490c54b9179b1fed0", GitTreeState:"clean", BuildDate:"2019-02-01T20:00:57Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}
kubectl को सेवा / रिलीज़-नाम-हब्र -o yaml --export मिलता है apiVersion: v1 kind: Service metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app.kubernetes.io/instance":"release-name","app.kubernetes.io/managed-by":"Tiller","app.kubernetes.io/name":"habr","helm.sh/chart":"habr-0.1.0"},"name":"release-name-habr","namespace":"default"},"spec":{"ports":[{"name":"http","port":80,"protocol":"TCP","targetPort":"http"}],"selector":{"app.kubernetes.io/instance":"release-name","app.kubernetes.io/name":"habr"},"type":"ClusterIP"}} creationTimestamp: null labels: app.kubernetes.io/instance: release-name app.kubernetes.io/managed-by: Tiller app.kubernetes.io/name: habr helm.sh/chart: habr-0.1.0 name: release-name-habr selfLink: /api/v1/namespaces/default/services/release-name-habr spec: ports: - name: http port: 80 protocol: TCP targetPort: http selector: app.kubernetes.io/instance: release-name app.kubernetes.io/name: habr sessionAffinity: None type: ClusterIP status: loadBalancer: {}
स्क्रिप्ट का उपयोग करने के उदाहरण निम्नलिखित हैं। वे दोनों प्रदर्शित करते हैं कि क्लस्टर में काम कर रहे संसाधनों को अपनाने के लिए स्क्रिप्ट का उपयोग कैसे करें और बाद में हेल्म टूल्स का उपयोग करके उन्हें हटा दें।
उदाहरण 1
उदाहरण 2
निष्कर्ष
लेख में वर्णित समाधान को अंतिम रूप दिया जा सकता है और न केवल कुबरनेट्स संसाधनों को खरोंच से अपनाने के लिए उपयोग किया जा सकता है, बल्कि उन्हें मौजूदा रिलीज़ में भी जोड़ा जा सकता है।
फिलहाल क्लस्टर में मौजूद संसाधनों को जब्त करने, उन्हें हेल्म प्रबंधन को हस्तांतरित करने की अनुमति नहीं है। यह संभव है कि हेल्म 3 इस समस्या को कवर करने के लिए एक समाधान लागू करेगा (कम से कम इस विषय पर एक
प्रस्ताव है )।
पुनश्च
K8s टिप्स एंड ट्रिक्स चक्र से अन्य:
हमारे ब्लॉग में भी पढ़ें: