Helm: स्कोपिंग नेमस्पेस को नाम जारी करता है

मुझे यकीन नहीं है कि मैं आपको समझता हूं। आप केवल एक रिलीज़ नाम रखते हुए एकाधिक नामस्थानों पर परिनियोजित करना चाहते हैं?

@21stio बिल्कुल सही। कुबेरनेट्स डॉक्स से:

Kubernetes एक ही भौतिक क्लस्टर द्वारा समर्थित कई वर्चुअल क्लस्टर का समर्थन करता है। इन वर्चुअल क्लस्टर्स को नेमस्पेस कहा जाता है।

तथा

नामस्थान नामों के लिए एक दायरा प्रदान करते हैं। संसाधनों के नाम नामस्थान के भीतर अद्वितीय होने चाहिए, लेकिन नामस्थानों में नहीं।

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

मैं सहमत हूँ। मेरे सभी नामस्थान ${site}-${environment} , लेकिन मेरी रिलीज़ ${site}-${environment}-${description} । जहां site हो सकता है internal या www और environment हो सकता है dev , staging , या team-a , team-b , और description कुछ ऐसा हो सकता है जैसे nginx , migrations , cache आदि।

लेकिन ${site}-${environment} बेहद बेमानी है:

NAMESPACE                    NAME
www-dev                     www-dev-redis-1234567890-cj241
www-dev                     www-dev-proxy-1234567890-kfd44
www-staging                 www-staging-redis-1234567890-cj241
www-staging                 www-staging-proxy-9876543210-kfd44
internal-team-b             internal-team-b-redis-1234567890-cj241
internal-team-b             internal-team-b-nginx-1234567890-cj241

मैं यही चाहता हूं, लेकिन मैं पसंद करूंगा कि पॉड्स सिर्फ redis-1234567890.. या proxy-9876543210..

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

K8s नेमस्पेस पहले से ही हमारे लिए नेमस्पेस है, मैं वास्तव में नेमस्पेस के साथ अपनी सभी चीजों को उपसर्ग करना पसंद नहीं करता हूं जब नामस्थान संघर्ष को रोकने में मदद के लिए डिज़ाइन किए जाते हैं।

स्पष्ट रूप से, यह वास्तव में अच्छा होगा यदि मैं वही काम कर सकता हूं जो मैं सेवाओं और अन्य k8s देशी प्रकारों के साथ कर सकता हूं जिसमें नाम स्थान से संबंधित हेल्म चार्ट हैं।

उदाहरण के लिए, मैं निम्नलिखित करने में सक्षम होना चाहता हूं:

helm install --namespace abc --name redis stable/redis
helm install --namespace def --name redis stable/redis

@Janpot @bcorijn ऊपर

तीसरे पक्ष के संसाधनों के बारे में क्या है, जो नेमस्पेस्ड नहीं हैं? या आरबीएसी, जहां "नेमस्पेस" एक नीति विशेषता है, न कि स्थान (https://kubernetes.io/docs/admin/authorization/)?

मुझे पता है कि मैंने इसे कई बार कहीं और कहा है, लेकिन हमारा अंतिम लक्ष्य संसाधनों को एक ही चार्ट से कई नामस्थानों में तैनात करना संभव बनाना है। (केस का उपयोग करें: एक ऐप में एक कंट्रोल प्लेन और एक डेटा प्लेन होता है, और आप सुरक्षा सीमाएँ बनाने के लिए प्रत्येक को अलग-अलग नेमस्पेस में तैनात करना चाहते हैं)

यदि हम किसी रिलीज़ को नाम स्थान से बाँधते हैं, तो हम निम्न करने की क्षमता खो देते हैं:

1. सीधे नामस्थान प्रबंधित करें
2. RBAC और सेवा खाते प्रबंधित करें
3. TPRs प्रबंधित करें (और कोई अन्य गैर-नामांकित ऑब्जेक्ट)
4. अंततः बहु-नामस्थान चार्ट का समर्थन करें।

मैं समझता हूं कि यह आपके लिए नामकरण की समस्या को थोड़ा कठिन बना देता है, लेकिन यह हेल्म को कुबेरनेट्स संसाधनों की एक विस्तृत श्रृंखला पर काम करने की अनुमति देता है।

क्या नामांकित और गैर-नामित दोनों रिलीज का समर्थन करना संभव होगा?

@technosophos संक्षेप में दो मुख्य ड्राइवर हैं:
1) उन संसाधनों का प्रबंधन करना जिनका नाम स्थान नहीं है
2) चार्ट को नेमस्पेस में स्थापित करने की अनुमति देने की भविष्य की योजनाएं

मैं आपका मुद्दा देखता हूं, लेकिन मुझे यकीन नहीं है कि यह वर्तमान कार्यान्वयन पर टिकने का एक कारण है, क्योंकि मुझे लगता है कि इन चिंताओं को दूर करने के लिए आपको इसे थोड़ा सा मजबूर करने की भी आवश्यकता है?

मल्टी-नेमस्पेस चार्ट के लिए अच्छी तरह से/मूल रूप से काम करने के लिए, आपको नेमस्पेसिंग सिस्टम के काफी ओवरहाल की आवश्यकता होगी, क्योंकि हेल्म की रिलीज को नेमस्पेस में रिलीज करने की वर्तमान अवधारणा काम नहीं करेगी? _EDIT: बस एहसास हुआ कि अगर रिलीज वास्तव में नामित थे, तो एक बहु-नामस्थान चार्ट सिर्फ एक छतरी चार्ट हो सकता है जिसमें एक अलग नामस्थान के साथ दो रिलीज होते हैं? _

गैर-नामित संसाधनों के प्रबंधन के लिए; मेरे पास इसके साथ व्यक्तिगत अनुभव नहीं है इसलिए इसका न्याय करना थोड़ा कठिन है, लेकिन फिर से मुझे लगता है कि यह हेल्म को अभी काम करने के सही तरीके से कम करने के लिए मजबूर कर रहा है, एक रिलीज के रूप में जो नेमस्पेस का प्रबंधन करता है, आरबीएसी या टीपीआर का नामस्थान होगा लेकिन बस इसे अनदेखा करें?
हो सकता है कि उनके साथ अनुभव न होने के कारण मुझे कुछ याद आ रहा हो, लेकिन नामों को स्कोप नहीं करना और नामस्थान को अनदेखा करना एक ही अंतिम परिणाम है, यह उपयोगकर्ता पर यह सत्यापित करने के लिए अधिक ज़िम्मेदारी डाल देगा कि उसके रिलीज नाम और चयनकर्ता हैं इन संसाधनों से निपटने के दौरान सही/अद्वितीय। (जो मैं सहमत हूं वह काफी जिम्मेदारी है)

तो हो सकता है कि केवल स्कोपिंग रिलीज जाने का रास्ता नहीं है, लेकिन जिस तरह से उन्हें हेलम में संभाला जाता है और भविष्य में संभाला जाएगा उस पर एक और नज़र डालना इसके लायक है? @Janpot के उल्लेख के रूप में दोनों विकल्प होने से "वैश्विक" रिलीज़ और
मेरी _वेरी पर्सनल_ राय यह भी है कि @kylebyerly-hp, @chancez और मैंने ऊपर वर्णित तरीके से परिनियोजन करना उन दो उपयोग मामलों की तुलना में बहुत अधिक सामान्य है जो काम करने के इस तरीके को रोकते हैं।

सबसे पहले, मैं मुख्य बिंदु को फिर से दोहराता हूं: हेल्म चार्ट वैश्विक स्तर पर काम करते हैं, नामस्थान स्तर पर नहीं। इसलिए उनके नाम विश्व स्तर पर अद्वितीय हैं।

मल्टी-नेमस्पेस्ड चार्ट के लिए, हमें जो ठीक करने की आवश्यकता है, वह है टिलर की नेमस्पेस में क्वेरी करने की क्षमता। (आप वास्तव में अब बहु-नाम वाले चार्ट _install_ कर सकते हैं। आप उन्हें मज़बूती से अपग्रेड या हटा नहीं सकते, क्योंकि टिलर विश्वसनीय रूप से उनसे पूछताछ नहीं कर सकता)।

गैर-नामित वस्तुओं के लिए, चीजें बहुत जटिल हो जाएंगी। हमारे पास गैर-नामित चीज़ों को प्रबंधित करने वाले नेमस्पेस रिलीज़ होंगे, जो बदले में, अन्य नामस्थानों को प्रभावित कर सकते हैं। कृपया देखें कि आरबीएसी और टीपीआर कैसे काम करते हैं। ये ऐसी चीजें नहीं हैं जिनका हेलम केवल समर्थन नहीं करने का निर्णय ले सकता है, और एक नाम स्थान को "नकली" करने से इसके लायक होने की तुलना में अधिक समस्याएं पैदा होंगी, खासकर आरबीएसी के साथ।

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

@technosophos

आप वास्तव में अब बहु-नामांकित चार्ट स्थापित कर सकते हैं

कैसे? कॉन्फ़िगरेशन में नामस्थानों के बारे में धारणा कहां रखी जानी चाहिए?

क्या आप बहु-नामस्थान रिलीज़ को आधिकारिक रूप से समर्थन देने की योजना बना रहे हैं?

हम हेल्म 3.0 तक पूरी तरह से मल्टी-नेमस्पेस रिलीज़ को सपोर्ट करने की योजना नहीं बनाते हैं क्योंकि ऐसा करने से बैकवर्ड कम्पैटिबिलिटी टूट जाएगी और हेलम/टिलर के कुबेरनेट्स कोड के एक प्रमुख रिफ्लेक्टर की आवश्यकता होगी।

दुर्भाग्य से हमारे लिए हेलम का उपयोग करके कई नामस्थानों को तैनात और प्रबंधित करने में सक्षम नहीं होना एक डील-ब्रेकर है।

हमारी योजना एक छत्र चार्ट बनाने की थी, जिसमें निर्भरता के रूप में हमारे सभी ऐप (जैसे छोटे चार्ट) होंगे। हमारे सभी ऐप्स अपने नामस्थान में रहते हैं, यह डिज़ाइन द्वारा था (भविष्य में हम आरबीएसी प्रति-नामस्थान चाहते हैं)। एक छत्र चार्ट के साथ हम एक ही बार में विभिन्न माइक्रोसर्विसेज के पूरे क्लस्टर को स्थापित और अपग्रेड कर सकते हैं, केवल एक values.yml , जो वास्तव में सुविधाजनक होगा।

@technosophos , धन्यवाद। इस तथ्य पर ध्यान दिया गया कि उपरोक्त के लिए समर्थन जल्द ही नहीं आएगा, कम से कम हेल्म 3.0 तक नहीं।

क्या कई नामस्थानों का समर्थन करने के लिए हेलम/टिलर में वास्तव में पुन: सक्रिय करने की आवश्यकता के बारे में कोई सामान्य विचार है? या 3.0 यह बहुत दूर है?

हम पतवार के उपचार का सहारा लिया गया है name एक UUID के और अधिक, का उपयोग कर के रूप में --name-template और दे यह एक सरल लेकिन यादृच्छिक नाम उत्पन्न करते हैं। मैं यह नहीं कह सकता कि मैं नेमस्पेस का सम्मान करने पर इसे पसंद करता हूं लेकिन मुझे दोनों बिंदु दिखाई देते हैं और हमारे लिए यह पर्याप्त होगा w/न्यूनतम ओवरहेड।

उदाहरण के लिए https://github.com/kubernetes/helm/pull/1015#issuecomment -237309305

> helm install --namespace www-dev --name-template "{{randAlpha 6 | lower}}" stable/redis

> kubectl --namespace www-dev get pods
NAME                                    READY     STATUS    RESTARTS   AGE
uvtiwh-redis-4101942544-qdvtw           1/1       Running   0          14m

> helm list --namespace www-dev
NAME    REVISION        UPDATED    STATUS          CHART                   NAMESPACE
uvtiwh  1               ...        DEPLOYED        redis-0.8.0             www-dev

@icereval आप इसे कनेक्ट करने के लिए अपने ऐप्स में रेडिस (uvtiwh) का नाम कैसे

एक पैटर्न जिसे मैं अपने क्लस्टर में उपयोग करने पर विचार कर रहा हूं वह है:

• kube-system में एक टिलर उदाहरण, क्लस्टर व्यवस्थापकों द्वारा उपयोग किया जाना है
• प्रति नाम स्थान के लिए एक टिलर इंस्टेंस, अधिक सीमित RBAC अनुमतियों के साथ, उस नाम स्थान के स्वामित्व वाली डेवलपर टीम द्वारा उपयोग किया जाएगा

"हेल्म रिलीज़ नाम विश्व स्तर पर-अद्वितीय हैं" डिज़ाइन सिद्धांत हमारे जैसे सॉफ्ट-मल्टीटेनेंट परिनियोजन के लिए एक सिरदर्द है, इसलिए मुझे अनुशंसित दृष्टिकोण के बारे में अधिक सुनने में दिलचस्पी है!

मैं बहुत निराश था जब मुझे पता चला कि हेल्म उनके नाम और नाम स्थान के आधार पर रिलीज की पहचान करने की अवधारणा का पालन नहीं करता है। मेरी राय में यह कुबेरनेट्स के डिजाइन सिद्धांतों का पालन नहीं करता है जहां संसाधन उनके संबंधित नामस्थान (कुछ वैश्विक संसाधनों के अपवाद के साथ) के भीतर अद्वितीय हैं।

जैसा कि अन्य पोस्टरों ने इस धागे में टिप्पणी की है, हमारे पास अनुप्रयोगों के विभिन्न समूहों के लिए कई पर्यावरण-प्रत्यय नामस्थान हैं। हमारे पास तीन या चार परिवेशों में प्रत्येक में सैकड़ों भिन्न परिनियोजन हैं। हम नामस्थानों के भीतर अद्वितीय DNS नामों पर बहुत अधिक भरोसा करते हैं ताकि हम अलग-अलग नामस्थानों में समान नाम वाली सेवाओं का उल्लेख कर सकें; उदाहरण के लिए हमारी रेडिस सेवा को tcp://redis पर दोनों नेमस्पेस a-test और a-prod में एक्सेस किया जा सकता है, जहां दोनों नेमस्पेस में रेडिस का एक परिनियोजित संस्करण है।

इसे शीर्ष 3 के लिए एक चर्चा बिंदु के रूप में लक्षित करना। ऐसा प्रतीत होता है कि इसके लिए भारी मात्रा में मांग है।

विपरीत बिंदु:

काफी हद तक हमारे सभी चार्ट पेड़ दृढ़ता/एपीआई/लेवल 7 एएलबी (+ स्थैतिक) लाइनों के साथ विभाजित कई नामस्थानों में कलाकृतियों को तैनात करते हैं। उस दृष्टिकोण से प्यार इस तथ्य से है कि शीर्ष रिलीज नाम वैश्विक हैं।

--namespace विकल्प की उपस्थिति helm में बहु-स्तरित अनुप्रयोगों के संयोजन के स्टैंड-पॉइंट से अर्ध-बेकार है, जहां आधार परतों को लाल/नीली तैनात ऊपरी परतों द्वारा पुन: उपयोग किया जा सकता है। कलाकृतियों के नाम में {{ .Release.Name }} -व्युत्पन्न तार डालने के बजाय, हम प्रत्येक परिनियोजन के लिए एक नया नाम स्थान बनाते हैं। यह हमें जंजीर वाले कॉन्फिग ( same_service_name.some_product_release20171102a.svc.cluster.local > same_service_name.some_product_release20171105c.svc.cluster.local ) के माध्यम से नियतात्मक रूप से निर्मित सेवा URL को प्रचारित करने की अनुमति देता है।

चूंकि स्वचालित रूप से जेनरेट किए गए रिलीज नाम वैसे भी gobbledygook हैं - helm list में उस चीज़ के पीछे क्या है, इसमें कोई निष्ठा नहीं है, हम उत्पाद/स्टैक नाम से प्राप्त स्ट्रिंग के साथ --name को हार्ड-ओवरराइड करते हैं और मोनोटोनिकली-बढ़ती रिलीज / बिल्ड संस्करण ( "appname-v20171103xyz" ) चार्ट में कहीं भी --name-template मूल्य को परिभाषित करने में सक्षम होना पसंद करेंगे और बस चार्ट नाम + डेटाटाइम व्युत्पन्न या स्पष्ट बिल्ड आईडी मान का उपयोग करें।

उदाहरण

आधार दृढ़ता परत

apiVersion: v1
kind: Service
metadata:
  name: redis
  namespace: {{ .Values.global.product }}-persistence-{{ .Values.global.tier }}
  labels:
    app: redis
    chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"
    release: "{{ .Release.Name }}"
    heritage: "{{ .Release.Service }}"
...

इस तरह किसी अन्य नामस्थान से उपभोग किया गया:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: {{ .Values.global.product }}
  namespace: {{ .Release.Name }}
  labels:
    app: {{ .Values.global.product }}
    chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
spec:
...
          env:
            - name: REDIS_SERVER_HOSTNAME
----->      value: "redis.{{ .Values.global.product }}-persistence-{{ .Values.global.tier }}.svc.cluster.local"

2 से ऊपर के टेम्प्लेट 2 अलग-अलग चार्ट (दृढ़ता चार्ट और एपीआई चार्ट) के भाग हैं और इन्हें अलग-अलग या संयुक्त रूप से तीसरे, व्यापक चार्ट के माध्यम से चलाया जा सकता है। दोनों ही मामलों में, .global. कारण मान कमांड लाइन पर एक बार ओवरराइड हो जाते हैं और सभी उप-चार्टों पर स्पष्ट रूप से लागू होते हैं।

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

नेमस्पेस होने और उपयोग करने के लाभों में से एक यह है कि उनके भीतर ऑब्जेक्ट नाम (डीएनएस नाम सहित) स्थानीय हैं और उन्हें नेमस्पेस से नेमस्पेस में बदलने की जरूरत नहीं है। विशेष रूप से ऊपर @dvdotsenko उदाहरण में, REDIS_SERVER_HOSTNAME समान होना चाहिए (उदाहरण के लिए, केवल redis ) और इसे वैश्वीकृत मूल्यों के साथ इंजेक्ट करने की आवश्यकता नहीं होनी चाहिए। कारण दोहराव से बचना है।

सादगी के दृष्टिकोण से (और कुछ स्वाभाविक रूप से जटिल मामलों को अलग रखते हुए, जैसे कि मल्टी-नेमस्पेस डिप्लॉय और नॉन-नेमस्पेस्ड ऑब्जेक्ट्स), आदर्श मामला यह है कि नेमस्पेस आपके स्टैक को "इकट्ठा" करता है और इसमें आपके एप्लिकेशन का ठीक एक उदाहरण होता है।

यह स्टैक के भीतर नामों को स्थानीय, सरल और सबसे महत्वपूर्ण रूप से तय करने की अनुमति देता है क्योंकि वे नामस्थान-सापेक्ष हैं।

एक संभावित तरीका यह है कि पतवार कमोबेश साधारण मामले का समर्थन करे जैसा कि आज होता है (नामस्थान के साथ वस्तुओं को उपसर्ग करने से बचते हुए); यह उचित, सुरक्षित सर्वोत्तम-अभ्यास डिफ़ॉल्ट उत्पन्न करेगा जो अधिकांश उपयोगों के लिए बॉक्स से बाहर काम करेगा। इसमें उन्नत नेमस्पेस मोड भी हो सकता है जो अधिक स्वतंत्रता (जटिलता की कीमत पर) की अनुमति देगा, उपयोग के मामलों के लिए अनुमति देने के लिए @dvdotsenko और @bcorijn वर्णन करें।

मेरा $.02

मुझे @pnickolov से सहमत

सिबलिंग चार्ट में सर्विस एंड-पॉइंट्स को कॉन्फ़िगर करने के आसान तरीके के बिना... विशुद्ध रूप से मूल्यों के माध्यम से...

मुझे यह भ्रमित करने वाला भी लगता है। जैसा कि @technosophos लिखते हैं :

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

मैं इसे ठीक से समझने के लिए संघर्ष कर रहा हूं। मैंने प्रलेखन को देखा है और मैंने जीएच पर यहां कई मुद्दों को देखा है और मैं अभी भी उलझन में हूं:

• एक तरफ, मैं उस नामस्थान को निर्दिष्ट करने के लिए helm install --namespace का उपयोग कर सकता हूं जिसे मैं लक्षित करना चाहता हूं
• दूसरी तरफ, मेरा चार्ट अपने मेटाडेटा ऑब्जेक्ट्स के अंदर जो भी नामस्थान चाहता है उसे निर्दिष्ट कर सकता है।

तो, मेरे प्रश्न:

• यदि helm install --namespace द्वारा निर्दिष्ट नाम स्थान मौजूद नहीं है, तो क्या हेल्म इसे बनाता है? क्या यह उस नामस्थान को chrt से बनाए गए सभी संसाधनों पर सेट करता है?
• यदि कोई संसाधन टेम्पलेट अपने मेटाडेटा में नाम स्थान निर्दिष्ट करता है, तो क्या हेलम उसे अधिलेखित कर देता है?

इन सवालों ने मुझे --namespace साथ खेलने में भी संकोच किया है, यह इतना अस्पष्ट है। अगर कोई मुझे इसे समझने में मदद कर सकता है, तो मैं वास्तव में इसकी सराहना करता हूं। आपको धन्यवाद!

f हेल्म इंस्टाल द्वारा निर्दिष्ट नेमस्पेस - नेमस्पेस मौजूद नहीं है, क्या हेल्म इसे बनाता है?

हां। यदि नाम स्थान पहले से मौजूद नहीं है, तो --namespace चार्ट के लिए निर्दिष्ट नाम स्थान बनाता है।

यदि कोई संसाधन टेम्पलेट अपने मेटाडेटा में नाम स्थान निर्दिष्ट करता है, तो क्या हेलम उसे अधिलेखित कर देता है?

नहीं। यदि आप चार्ट में --namespace साथ-साथ नेमस्पेस संसाधन में समान नाम स्थान प्रदान करते हैं, तो एक विरोध होगा क्योंकि नेमस्पेस पहले टिलर द्वारा स्थापित किया जाएगा, और फिर चार्ट के प्रयास करने पर बोर्क हो जाएगा। उसी नामस्थान को फिर से स्थापित करें।

आगे के संदर्भ के लिए, पतवार का विचार helm install --namespace द्वारा प्रदान किए गए नामस्थान में सभी संसाधनों को स्थापित करना है। जो उपयोगकर्ता चार्ट में नाम स्थान को "हार्डकोडिंग" कर रहे हैं, वे आमतौर पर एक से अधिक नामस्थानों में चार्ट स्थापित करना चाहते हैं।

यह ओपी जो सुझाव दे रहा है, उससे थोड़ा हटकर है, लेकिन कृपया बेझिझक एक नया टिकट खोलें या यदि आपके कोई और प्रश्न हैं तो स्लैक पर हमसे जुड़ें! :)

सुनिश्चित नहीं है कि मैं इस चर्चा में उतरना चाहता हूं कृपया कृपया 🙏

पतवार --namespace पैरामीटर वास्तव में --default-namespace है

स्टैक और संबंधित को पढ़ना --namespace विकल्प के आसपास बहुत भ्रम प्रतीत होता है क्योंकि लोग (काफी उचित रूप से) मानते हैं कि यह kubectl --namespace जैसा है, जिसका उपयोग वे प्रभावी रूप से उस नामस्थान पर गतिविधि को सीमित करते हैं (द्वारा एक पार्सिंग त्रुटि का दुष्प्रभाव, वास्तव में सुरक्षा नहीं)। helm के मामले में ऐसा नहीं है क्योंकि tiller एक क्लस्टर सेवा है जो पूरे क्लस्टर पर काम करती है। विकल्प का नाम बेहतर होगा --default-namespace , अर्थात। यह वह नामस्थान है जिस पर आपके संसाधन जाएंगे यदि वे कोई विशेष नामस्थान निर्दिष्ट नहीं करते हैं।

मल्टी-नेमस्पेस रिलीज की भी जरूरत है

मैं पहले से ही चार्ट पर भरोसा करता हूं जो प्रत्येक रिलीज के विभिन्न घटकों को कई नामस्थानों में तैनात करता है, और मैं हेलम 3.0 में उन्नत समर्थन की उम्मीद कर रहा हूं। मैं

हेलम और नेमस्पेस प्रतिबंधों के साथ बहु-किरायेदार पहले से ही संभव है

मैं उपयोग के मामले को भी देखता हूं जहां लोग बहु-किरायेदार, नामस्थान-प्रतिबंधित इंस्टॉल चाहते हैं। IMHO स्कोपिंग या रिलीज को नेमस्पेस तक सीमित करना कुछ ऐसा नहीं है helm / tiller को खुद को लागू करने से संबंधित होना चाहिए, यह RBAC का काम है। इसे प्राप्त करने के लिए कम से कम दो मॉडल हैं, एक अभी संभव है:

1. सेवा खाते और RBAC के साथ प्रति-नामस्थान tiller परिनियोजित करें जो केवल उस नामस्थान में संचालन की अनुमति देता है। यह अब काम करता है और मैं लोगों को इसका इस्तेमाल करते देखता हूं। बहु-किरायेदार समूहों के लिए आदर्श।
2. tiller लिए k8s उपयोगकर्ता प्रतिरूपण का समर्थन करने के लिए, और इसलिए प्रत्येक रिलीज़ को helm उपयोगकर्ता के रूप में तैनात भविष्य के helm संस्करणों के लिए इस पर जा रही है , और ऐसा लगता है कि कुछ कार्यान्वयन चुनौतियां हैं। लेकिन यह क्लस्टर-सेवा tiller को RBAC नेमस्पेस प्रतिबंधों को लागू करने की अनुमति देगा, जबकि अभी भी मल्टी-नेमस्पेस-स्पैनिंग रिलीज़ का समर्थन करता है।

अलग-अलग नामस्थानों में अलग-अलग रिलीज़ के लिए समान नाम वाले संसाधन पहले से ही संभव हैं

उन लोगों के लिए जो एक ही चार्ट को अलग-अलग नामस्थानों में स्थापित करना चाहते हैं लेकिन एक ही संसाधन नाम (जैसे रेडिस) के साथ। यह पूरी तरह से संभव है, यह इस बात पर निर्भर करता है कि आप अपने चार्ट टेम्प्लेट कैसे लिखते हैं। आपको रिलीज़ नाम के साथ संसाधन नामों को उपसर्ग करने की आवश्यकता नहीं है, यह केवल एक डिफ़ॉल्ट/सम्मेलन है जिसका बहुत सारे चार्ट अनुसरण करते हैं। हाल के चार्ट में पहले से ही .fullnameOverride मान है जो आपको रिलीज़ नाम उपसर्ग को निक्स करने देता है। आप अपने redis को redis के रूप में हर एक helm install साथ तैनात कर सकते हैं यदि आप चाहें।

हम @gmile जैसी ही स्थिति में हैं और हम जानना चाहते हैं कि ऐसा करने के लिए सबसे अच्छा अभ्यास क्या है। हमारा मूल अनुप्रयोग, ingestion-service की निर्भरता kafka जो बदले में zookeeper पर निर्भरता है। लेकिन, हम तीनों को उनके अपने नामस्थान में चाहते हैं लेकिन एक ही शीर्ष install माध्यम से प्रबंधित करना चाहते हैं। हम kafka के requirements.yaml में ingestion-service kafka जोड़ने की योजना बना रहे थे। लेकिन अपने नामस्थान में kafka प्राप्त करना helm साथ सीधा नहीं दिखता है, इसलिए हम जो चाहते थे वह requirements.yaml से हटा रहा था और दोनों तैनाती के लिए अलग-अलग helm install .

केवल एक FYI करें कि यह नोट किया गया है और धारा 3 के तहत सूचीबद्ध हेल्म 3 प्रस्ताव का हिस्सा है

यही कारण है कि शानदार खबर @bacongobbler है 😄🎉

@bacongobbler क्या हेलम 3 आवश्यकताओं में आश्रित चार्ट के लिए अलग नामस्थान निर्दिष्ट करने का समर्थन करना चाहता है। जैसा कि

प्रस्ताव दस्तावेज़ से (इसे पढ़ें! :मुस्कान:):

$ helm install -n foo bar --namespace=dynamite
# installs release, releaseVersion, and un-namespaced charts into dynamite namespace.

हेल्म 2 की तरह, यदि कोई संसाधन स्पष्ट रूप से अपना नामस्थान घोषित करता है (उदाहरण के लिए मेटाडेटा.नेमस्पेस = कुछ के साथ), तो हेल्म इसे उस नामस्थान में स्थापित करेगा। लेकिन चूंकि स्वामी के संदर्भ नामस्थानों पर नहीं होते हैं, इसलिए ऐसा कोई भी संसाधन मूल रूप से अप्रबंधित हो जाएगा।

@bacongobbler मैंने इसे पढ़ा, लेकिन मुझे अभी भी इसका समर्थन करते हुए नहीं दिख रहा है। मेरा मतलब उन चार्टों में हार्डकोडेड मेटाडेटा.नेमस्पेस नहीं है जिन्हें मैं नियंत्रित करता हूं, यह हमेशा समर्थित रहा है। मेरा मतलब किसी तृतीय-पक्ष चार्ट के लिए नाम स्थान निर्दिष्ट करना है जिसे संपादित करने की क्षमता मेरे पास नहीं है। उदाहरण के लिए, मेरी आवश्यकताओं में। yaml मैं स्थिर/कुबेरनेट्स-डैशबोर्ड पर निर्भर करता हूं और इसे क्यूब-सिस्टम में स्थापित करना चाहता हूं, लेकिन मेरा चार्ट विकास नामस्थान में जाना चाहता है।

90d निष्क्रियता के बाद मुद्दे पुराने हो जाते हैं।
/remove-lifecycle stale साथ समस्या को ताज़ा के रूप में चिह्नित करें।
अतिरिक्त 30d निष्क्रियता के बाद बासी मुद्दे सड़ जाते हैं और अंततः बंद हो जाते हैं।

अगर इस मुद्दे को अभी बंद करना सुरक्षित है तो कृपया इसे /close ।

सिग-टेस्टिंग, कुबेरनेट्स/टेस्ट-इन्फ्रा और/या फेजटा को फीडबैक भेजें ।
/जीवनचक्र बासी

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

@gmile मुझे 99% यकीन है कि हेल्मफाइल अनुरक्षकों ने इस विशेष मुद्दे को हेल्मफाइल में ठीक नहीं किया है। यदि आप अपने helmfile.yaml में अलग-अलग नामस्थानों के साथ vault नाम की दो रिलीज़ घोषित करते हैं और helmfile sync चलाते हैं, तो यह विफल हो जाएगी क्योंकि रिलीज़ नाम vault पर पहली रिलीज़ द्वारा दावा किया गया था।

अस्वीकरण: मैंने हेल्मफाइल का उपयोग करके इसका परीक्षण नहीं किया है, इसलिए मुझे यह बताया जाना अच्छा लगेगा कि मैं गलत हूं। मैं

बस अगर आखिरी टिप्पणी छूट गई थी, तो हम इसे हेल्म 3 में उन परिवर्तनों के साथ संबोधित कर रहे हैं कि कैसे हेल्म रिलीज को संभालता है । :)

@ स्टीवन-शेही उस विशेष मुद्दे को संभवतः सैंडबॉक्सिंग मॉडल के माध्यम से तय किया जा सकता है, जो कि परिभाषित किए गए की तुलना में किसी विशेष नाम स्थान पर तैनात करने के लिए उपचार्ट का विस्तार करके किया जा सकता है।

/निकालें-जीवनचक्र बासी

संबंधित: https://discuss.kubernetes.io/t/timeline-for-helm-3/2776

हेल्म 3 में लागू किया गया। नेमस्पेस संदर्भ को बदलना एक अलग उदाहरण को पूरी तरह से संदर्भित करता है।

><> ./bin/helm version
version.BuildInfo{Version:"v3.0+unreleased", GitCommit:"5eb48f4471ac3aa9a3c87a07ee6f9e5bbc60a0e1", GitTreeState:"clean"}
><> ./bin/helm list --all-namespaces
NAME            REVISION    UPDATED                                 STATUS      CHART               NAMESPACE
chartmuseum     1           2019-02-08 08:56:29.566393188 -0800 PST deployed    chartmuseum-1.9.0   default  
chartmuseum     1           2019-02-08 09:14:01.978866327 -0800 PST deployed    chartmuseum-1.9.0   foo

अच्छी खबर @bacongobbler

इस परिवर्तन को देखते हुए, क्या नेमस्पेस कॉलम को list आउटपुट में पहले कॉलम में ले जाना समझ में आता है। ताकि पहले दो कॉलम विशिष्ट रूप से रिलीज़ की पहचान कर सकें?

डिफ़ॉल्ट सॉर्ट नाम स्थान और रिलीज़ द्वारा हो सकता है, ताकि एक ही नामस्थान में रिलीज़ को एक साथ समूहीकृत किया जा सके, उदाहरण के लिए सभी kube-system रिलीज़ एक साथ होंगे।

ज़रूर।

अभी के लिए, मैं अभी उपयोग करता हूँ

helm install --name <namespace>-<name> ...

हां, जिस तरह से चीजें काम करती हैं, उससे बदबू आती है, लेकिन, आपको प्रबंधन करने के लिए विश्व स्तर पर अद्वितीय नामों की आवश्यकता है, और ऐसा कोई कारण नहीं है कि आप रिलीज के नाम के लिए केवल एक कंपाउंड कुंजी नहीं बना सकते।

ठीक है तो ऐसा लगता है कि 3 मौलिक परिदृश्य हैं (प्रत्येक मिश्रण में विभिन्न क्रमपरिवर्तन की संभावना के साथ):

1. एकल नामस्थान चार्ट।
2. संसाधन जो नामस्थानीय नहीं है।
3. मल्टी-नेमस्पेस'ड चार्ट।

क्या विभिन्न परिदृश्यों को संबोधित करने के लिए यह एक उचित दृष्टिकोण होगा:

1. --namespace ध्वज के साथ आपूर्ति किए जाने पर नामस्थान को इंजेक्ट/ओवरराइड करें।
2. 1 के समान लेकिन उन संसाधनों के नामस्थान को अनदेखा करें जिनमें नामस्थान की कमी है।
3. "बहु-नामस्थान को ओवरराइड नहीं कर सकता" संसाधन या इसी तरह का हवाला देते हुए बाहर निकलें।

इसके अलावा: मैं टिलर का उपयोग नहीं करता, helm template प्राथमिकता देता हूं, इसलिए यह सुनिश्चित नहीं है कि यह चुनौतियों को कितना बदल देता है।

@technosophos

मैं यह समझने की कोशिश कर रहा हूं कि कैसे हेल्म v2 नेमस्पेस के साथ इंटरैक्ट करता है और कैसे v3 अलग होगा, और इस थ्रेड में आपकी पुरानी टिप्पणियों में से एक मुझे भ्रमित करती है:

सबसे पहले, मैं मुख्य बिंदु को फिर से दोहराता हूं: हेल्म चार्ट वैश्विक स्तर पर काम करते हैं, नामस्थान स्तर पर नहीं। इसलिए उनके नाम विश्व स्तर पर अद्वितीय हैं।

....

गैर-नामित वस्तुओं के लिए, चीजें बहुत जटिल हो जाएंगी। हमारे पास गैर-नामित चीज़ों को प्रबंधित करने वाले नेमस्पेस रिलीज़ होंगे, जो बदले में, अन्य नामस्थानों को प्रभावित कर सकते हैं। कृपया देखें कि आरबीएसी और टीपीआर कैसे काम करते हैं। ये ऐसी चीजें नहीं हैं जिनका हेलम केवल समर्थन नहीं करने का निर्णय ले सकता है, और एक नाम स्थान को "नकली" करने से इसके लायक होने की तुलना में अधिक समस्याएं पैदा होंगी, खासकर आरबीएसी के साथ।

ऐसा लगता है कि हेल्म v3 से तैनात रिलीज वास्तव में नामित होंगे; क्या वो सही है? क्या आप जानते हैं कि आरबीएसी मुद्दे को कैसे सुलझाया गया है? एकमात्र संकल्प जिसके बारे में मैं सोच सकता हूं कि आपके द्वारा बताए गए मुद्दे से बचना होगा हेल्म v3 चार्ट के लिए RBAC ऑब्जेक्ट्स को संशोधित करने का समर्थन नहीं करना है, लेकिन मुझे विभिन्न ब्लॉग पोस्टों में कुछ भी नहीं मिला है और इस तरह v3 के बारे में यह दर्शाता है कि क्या v3 चार्ट प्रबंधन का समर्थन करेंगे RBAC ऑब्जेक्ट करता है या नहीं।

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

मैंने हेलम v3 के प्रस्ताव को नहीं पढ़ा है, लेकिन समझदारी की बात यह है कि
k8s पहले से उपयोग किए जाने वाले चयनकर्ता पैटर्न को अपनाएं और इसकी कोई आवश्यकता नहीं है
किसी विशिष्ट क्षेत्र का समर्थन करें।

मंगल, जून 25, 2019 पर, 11:01 BatmanAoD [email protected] लिखा है:

@technosophos https://github.com/technosophos

मैं यह समझने की कोशिश कर रहा हूं कि कैसे हेल्म v2 नेमस्पेस के साथ इंटरैक्ट करता है और कैसे v3
अलग होगा, और इस सूत्र में आपकी एक पुरानी टिप्पणी मुझे भ्रमित करती है:

सबसे पहले, मैं मुख्य बिंदु को फिर से दोहराता हूं: हेल्म चार्ट वैश्विक पर काम करते हैं
स्तर, नामस्थान स्तर पर नहीं। तो उनके नाम विश्व स्तर पर अद्वितीय हैं ....

गैर-नामित वस्तुओं के लिए, चीजें बहुत जटिल हो जाएंगी। हमारे पास होगा
नेमस्पेस्ड रिलीज़ अन-नेमस्पेस्ड चीजों को प्रबंधित करते हैं, जो बदले में, कर सकते हैं
अन्य नामस्थानों को प्रभावित करें। कृपया देखें कि आरबीएसी और टीपीआर कैसे काम करते हैं।
ये ऐसी चीजें नहीं हैं जिन्हें हेल्म समर्थन नहीं करने का निर्णय ले सकता है, और
नामस्थान को "नकली" करने से इसके लायक होने की तुलना में अधिक समस्याएं पैदा होंगी, खासकर
आरबीएसी के साथ।

ऐसा लगता है कि हेल्म v3 से तैनात रिलीज वास्तव में नामित होंगे;
क्या वो सही है? क्या आप जानते हैं कि आरबीएसी मुद्दे को कैसे सुलझाया गया है? केवल
संकल्प मैं सोच सकता हूं कि आपके द्वारा बताए गए मुद्दे से बचना होगा
हेल्म v3 चार्ट आरबीएसी ऑब्जेक्ट्स को संशोधित करने का समर्थन नहीं करते हैं, लेकिन मुझे नहीं मिला है
विभिन्न ब्लॉग पोस्ट में कुछ भी और जैसे v3 के बारे में यह दर्शाता है कि क्या v3
चार्ट आरबीएसी वस्तुओं के प्रबंधन का समर्थन करेंगे या नहीं।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/helm/helm/issues/2060?email_source=notifications&email_token=AACFHREXHFSKFSB7FXQ5VPTP4JMP3A5CNFSM4DCII7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVX55J55ZTWZDWWWYRC43
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AACFHRH2JPXPKMX23WVQLCDP4JMP3ANCNFSM4DCII7XQ
.

@BatmanAoD @gyndick हेल्म v3 में, उपयोगकर्ता संदर्भ में चार्ट स्थापित किए जाते हैं। इसका अर्थ है कि यह उस उपयोगकर्ता नाम स्थान में स्थापित है और उपयोगकर्ता के RBAC का उपयोग करेगा। रिलीज़ नाम नामस्थान के आधार पर भी हैं।

आप इसे Alpha.1 रिलीज़ के साथ आज़मा सकते हैं: https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1 या dev-v3 शाखा से निर्माण करें।

मैं हेलम v3 का उपयोग नहीं करूंगा। हर ऑपरेशन टीम अलग होती है
बाधाओं और चीजों को करने के तरीके। परिचालन उपकरण सरल होने चाहिए,
एकल प्रयोजन उपयोगिताओं अर्थात् यूनिक्स दर्शन संगत।

मेरी स्क्रिप्टिंग, तर्क, आदि मेरे पैकेज मैनेजर के बाहर रहते हैं।

टीएलडीआर;

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

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

v3 के लिए प्रस्तावित जटिलता कई गलतियों को आमंत्रित करेगी और खराब
उन लोगों से डिज़ाइन करें जिनके पास 25 वर्षों के अनुभव का लाभ नहीं है।

अतिरिक्त जटिलता केवल चीजों को करना कठिन बना देगी क्योंकि हमेशा,
परिचालन उपकरण जो केवल स्वयं के विकास के वातावरण बन जाते हैं
ट्राइएज को धीमा करें।

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

उन सभी उपकरणों के बारे में सोचें जो समर्थन के लिए एक पारिस्थितिकी तंत्र में जाते हैं
किसी विशिष्ट भाषा में सॉफ्टवेयर का विकास और संचालन। आप नहीं हैं
काफी समय के लिए यह प्रदान करने में सक्षम होने जा रहा है।

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

एक पैकेज मैनेजर सरल और हल्का होना चाहिए जिसमें कुछ ही हों
जिम्मेदारियां।

1. कलाकृतियों को वितरित करें
2. कलाकृतियों को हटा दें
3. कलाकृतियों में प्रदान की गई लिपियों को चलाएँ
4. उन कलाकृतियों पर नज़र रखें, जिनके बारे में उन्हें लगता है कि उन्होंने इसे वितरित किया
5. सबसे महत्वपूर्ण बात, किस

कोई और दर्द मांग रहा है। सच कहूँ तो, हेलम v2 लगभग सही होगा
अगर यह तय करता है कि यह रिलीज का ट्रैक कैसे रखता है।

बुध, जून 26, 2019, 1:31 पूर्वाह्न पर मार्टिन हिकी नोटिफिकेशन @github.com
लिखा था:

@BatmanAoD https://github.com/BatmanAoD @gyndick हेल्म v3 में, चार्ट हैं
उपयोगकर्ता संदर्भ में स्थापित। इसका मतलब है कि यह उस उपयोगकर्ता में स्थापित है
नेमस्पेस और उपयोगकर्ता के आरबीएसी का उपयोग करेगा। रिलीज के नाम a . पर हैं
नामस्थान आधार भी।

आप इसे Alpha.1 रिलीज़ के साथ आज़मा सकते हैं:
https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1 या इससे निर्माण
देव-v3 शाखा।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/helm/helm/issues/2060?email_source=notifications&email_token=AACFHREUTX77SJCPWZLQKATP4MSNRA5CNFSM4DCII7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXH2GOR76WS मुद्दा
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AACFHRCAQLWUYHH6RJSUYF3P4MSNRANCNFSM4DCII7XQ
.

@hickeyma उत्तर के लिए धन्यवाद! मैं वास्तव में इस बारे में इतना नहीं सोच रहा हूं कि हेलम के संचालन को कैसे एक्सेस-नियंत्रित किया जाएगा (हालांकि यह एक संबंधित मुद्दा है) जैसे कि हेल्म अभी भी वैश्विक संचालन करने में सक्षम होगा जैसे कि v3 में क्लस्टररोल बनाना।

@BatmanAoD को काम करना चाहिए क्योंकि वे क्लस्टर-