Helm: تحديد النطاق يطلق أسماء لمساحات الأسماء

لست متأكدًا مما إذا كنت أفهمك. هل تريد النشر إلى مساحات أسماء متعددة مع وجود اسم إصدار واحد فقط؟

@ 21stio بالضبط. من مستندات Kubernetes:

يدعم Kubernetes مجموعات افتراضية متعددة تدعمها نفس المجموعة المادية. تسمى هذه المجموعات الظاهرية مساحات الأسماء.

و

توفر مساحات الأسماء نطاقًا للأسماء. يجب أن تكون أسماء الموارد فريدة داخل مساحة الاسم ، ولكن ليس عبر مساحات الأسماء.

أنا شخصياً لا أستطيع التفكير في سبب وجيه لعدم احترام helm لمفهوم مساحات الأسماء.

أنا موافق. جميع مساحات الأسماء الخاصة بي بصيغة ${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

Janpotbcorijn الافتراض الواردة أعلاه هو أن الرسوم البيانية هيلم العمل فقط مع الكائنات التي يتم تغليف داخل النطاقات. لا نرغب في قصر هيلم على تلك الأنواع من الموارد فقط.

ماذا عن موارد الطرف الثالث ، التي لم يتم تحديد مساحة أسماء فيها؟ أو RBACs ، حيث "مساحة الاسم" هي سمة سياسة وليست موقعًا (https://kubernetes.io/docs/admin/authorization/)؟

أعلم أنني قلت ذلك عدة مرات في مكان آخر ، لكن هدفنا النهائي هو إتاحة إمكانية نشر الموارد في مساحات أسماء متعددة من نفس المخطط. (حالة الاستخدام: يحتوي التطبيق على مستوى تحكم ومستوى بيانات ، وتريد نشر كل منهما في مساحات أسماء منفصلة لإنشاء حدود أمان)

إذا ربطنا إصدارًا بمساحة اسم ، فإننا نفقد القدرة على:

1. إدارة مساحات الأسماء مباشرة
2. إدارة RBACs وحسابات الخدمة
3. إدارة TPRs (وأي كائنات أخرى ليس لها مساحة أسماء)
4. دعم في نهاية المطاف المخططات متعددة مساحات الأسماء.

أتفهم أن هذا يجعل مشكلة التسمية أصعب قليلاً بالنسبة لك ، لكنه يسمح لشركة Helm بالعمل على مجموعة أكبر من موارد Kubernetes.

هل سيكون من الممكن دعم كل من الإصدارات التي لا تعتمد على فراغات الأسماء؟

technosophos للتلخيص ، هناك عاملان رئيسيان:
1) إدارة الموارد التي ليست في نطاق أسماء
2) الخطط المستقبلية للسماح بتثبيت المخططات عبر مساحة الاسم

أرى وجهة نظرك ، لكنني لست متأكدًا مما إذا كان هذا سببًا للالتزام بالتنفيذ الحالي ، لأن لدي انطباع أنك تحتاج أيضًا إلى إجباره قليلاً لمعالجة هذه المخاوف؟

لكي تعمل مخططات مساحات الأسماء المتعددة بشكل جيد / أصلي ، ستحتاج على الأرجح إلى إصلاح شامل لنظام تباعد الأسماء ، لأن المفهوم الحالي لـ Helm الذي يضع إصدارات في مساحة اسم لن ينجح؟ _EDIT: أدركت للتو أنه إذا كانت الإصدارات ذات مساحة اسم فعلية ، يمكن أن يكون مخطط مساحات الأسماء المتعددة مجرد مخطط شامل يحتوي على إصدارين بهما مساحة اسم مختلفة؟ _

لإدارة الموارد غير المحددة بمساحة أسماء ؛ ليس لدي خبرة شخصية في ذلك ، لذا من الصعب الحكم عليها ، لكن مرة أخرى أشعر أن هذا يجبر Helm على طريقة عمل أقل من مثالية في الوقت الحالي ، كإصدار يدير مساحات الأسماء ، سيكون لـ RBAC أو TPR مساحة اسم ولكن فقط تجاهله؟
ربما أفتقد شيئًا ما بسبب عدم وجود خبرة معهم ، لكنني لن أفحص الأسماء وتجاهل مساحة الاسم له نفس النتيجة النهائية ، بل سيضع مزيدًا من المسؤولية على المستخدم للتحقق من أن أسماء الإصدارات والمحددات الخاصة به صحيحة / فريدة عند التعامل مع هذه الموارد. (التي أوافق أنها المسؤولية تماما)

لذلك ربما لا يكون مجرد تحديد نطاق الإصدارات هو السبيل للذهاب ، ولكن إلقاء نظرة أخرى على الطريقة التي يتم التعامل بها في Helm وسيتم التعامل معها في المستقبل أمر يستحق ذلك؟ وجود كلا الخيارين كما هو الحال مع
رأيي الشخصي للغاية هو أيضًا أن النشر بالطريقة @ kylebyerly-hp و chancez و التي وصفتها أعلاه هو أكثر شيوعًا من حالتي الاستخدام اللذين يمنعان طريقة العمل هذه.

أولاً ، دعني أعيد التأكيد على النقطة الرئيسية: تعمل مخططات Helm على مستوى عالمي ، وليس على مستوى مساحة الاسم. لذلك فإن أسمائهم فريدة من نوعها على مستوى العالم.

بالنسبة إلى المخططات متعددة المساحات ، ما نحتاج إلى إصلاحه هو قدرة تيلر على الاستعلام عبر مساحات الأسماء. (يمكنك بالفعل _ تثبيت_ مخططات متعددة المساحات الآن. لا يمكنك ترقيتها أو حذفها بشكل موثوق ، لأن Tiller لا يمكنه الاستعلام عنها بشكل موثوق).

بالنسبة للعناصر التي ليس لها مسافة أسماء ، ستصبح الأمور معقدة للغاية. كان لدينا إصدارات ذات مسافات اسم تدير أشياء بدون مسافة أسماء والتي بدورها يمكن أن تؤثر على مساحات الأسماء الأخرى. يرجى إلقاء نظرة على كيفية عمل RBACs و TPRs. هذه ليست أشياء يمكن أن يقرر Helm ببساطة عدم دعمها ، و "تزوير" مساحة اسم من شأنه أن يسبب مشاكل أكثر مما تستحق ، خاصة مع RBACs.

ما زلت لم أر سببًا جيدًا لمساحة الاسم باسم إصدار. تستند شكاويك الأولية إلى سوء فهم مفاده أن جميع الأشياء (المهمة) في Kubernetes يتم تحديدها في نطاق اسم. لكن الأشياء المهمة مثل TPRs و RBACs ليست كذلك. يبدو أن الجزء الأكبر من الشكاوى الأخرى يتعلق بحقيقة أن مخططات التسمية التي يستخدمونها "ليست جميلة" مع هيلم. يبدو أن العمل على حل ذلك من خلال إنشاء تغيير هائل لكسر التوافق يخطئ في تمثيل الإصدارات على أنها "في مساحة اسم" هو الأسلوب الخاطئ الذي يجب اتباعه.

تضمين التغريدة

يمكنك بالفعل تثبيت مخططات متعددة المساحات الآن

كيف؟ أين يجب وضع فكرة مساحات الأسماء في التكوين؟

هل تخطط لدعم إصدارات مساحات الأسماء المتعددة رسميًا؟

نحن لا نخطط لتقديم الدعم الكامل للإصدارات متعددة الأسماء حتى Helm 3.0 لأن القيام بذلك سيؤدي إلى كسر التوافق مع الإصدارات السابقة ويتطلب إعادة بناء كبيرة لكثير من كود Helm / Tiller Kubernetes.

لسوء الحظ بالنسبة لنا ، فإن عدم قدرتنا على نشر وإدارة مساحات أسماء متعددة باستخدام helm يعد بمثابة كسر للصفقات.

كانت خطتنا هي إنشاء مخطط شامل ، والذي سيكون لجميع تطبيقاتنا (مثل المخططات الأصغر) على أنها تبعيات. جميع تطبيقاتنا تعيش في مساحات الأسماء الخاصة بها ، وكان هذا حسب التصميم (في المستقبل نود أن يكون لدينا RBAC لكل مساحة اسم). باستخدام مخطط شامل ، يمكننا تثبيت وترقية مجموعة كاملة من الخدمات المصغرة المختلفة في وقت واحد ، مع منح values.yml واحد فقط

technosophos ، شكرا. علمًا بحقيقة أن الدعم لما ورد أعلاه لن يصل قريبًا ، وليس حتى Helm 3.0 على الأقل.

هل هناك فكرة عامة عما يحتاج بالضبط إلى إعادة هيكلة في Helm / Tiller لدعم مساحات أسماء متعددة؟ أم أنها 3.0 بعيدة جدًا؟

لقد لجأنا إلى التعامل مع الدفة name أنها أكثر من UUID ، باستخدام --name-template والسماح لها بإنشاء اسم بسيط ولكن عشوائي. لا أستطيع أن أقول إنني أفضل هذا على احترام مساحة الاسم نفسها ، لكني أرى كلا النقطتين وهذا بالنسبة لنا سيكون كافياً مع الحد الأدنى من النفقات العامة.

على سبيل المثال 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 كيف ستجد اسم redis (uvtiwh) في تطبيقاتك للاتصال به؟

النمط الذي أفكر في استخدامه في مجموعاتنا هو:

• مثيل Tiller واحد في kube-system ، ليتم استخدامه بواسطة مسؤولي المجموعة
• مثيل Tiller لكل مساحة اسم ، مع أذونات RBAC محدودة أكثر ، ليتم استخدامها من قبل فريق المطورين الذي يمتلك مساحة الاسم هذه

يُعد مبدأ التصميم "أسماء إصدارات Helm فريدة عالميًا" مشكلة في عمليات النشر اللينة للمستأجرين المتعددين مثل عملياتنا ، لذلك أنا مهتم بمعرفة المزيد عن النهج الموصى به!

شعرت بخيبة أمل كبيرة عندما اكتشفت أن هيلم لا تلتزم بمفهوم تحديد الإصدارات بناءً على اسمها ومساحة الاسم. في رأيي ، لا يتبع هذا مبادئ تصميم Kubernetes حيث تكون الموارد فريدة ضمن مساحة الاسم الخاصة بكل منها (باستثناء بعض الموارد العالمية).

كما علق الملصقات الأخرى في هذا الموضوع ، لدينا العديد من مساحات الأسماء الملحقة بالبيئة لمجموعات مختلفة من التطبيقات. لدينا مئات من عمليات النشر المختلفة في ثلاث أو أربع بيئات. نحن نعتمد بشدة على أسماء DNS الفريدة داخل مساحات الأسماء حتى نتمكن من الرجوع إلى الخدمات التي تحمل الاسم نفسه داخل مساحات أسماء مختلفة ؛ على سبيل المثال يمكن الوصول إلى خدمة redis الخاصة بنا عبر tcp: // redis في كلٍّ من فضاء الاسم a-test و a-prod ، حيث توجد نسخة منشورة من redis لكلٍّ من مساحات الأسماء.

استهداف هذا كنقطة مناقشة للدفة 3. يبدو أن هناك قدرًا هائلاً من الطلب على ذلك.

النقطة المعاكسة:

تقوم جميع أشجار المخططات الخاصة بنا تقريبًا بنشر عناصر أثرية عبر مساحات أسماء متعددة مقسمة على طول خطوط الاستمرارية / API / المستوى 7 ALB (+ ثابت). من هذا الموقف ، أحب حقيقة أن أسماء إصدارات الدفة عالمية.

تم العثور على وجود خيار --namespace في helm شبه عديم الفائدة من نقطة الوقوف لتجميع التطبيقات متعددة الطبقات ، حيث يمكن إعادة استخدام الطبقات الأساسية بواسطة الطبقات العليا المنشورة باللونين الأحمر / الأزرق. بدلاً من حقن سلاسل مشتقة من {{ .Release.Name }} في أسماء القطع الأثرية ، نقوم بإنشاء مساحة اسم جديدة لكل عملية نشر. يتيح لنا ذلك نشر عناوين URL للخدمة المشكلة بشكل محدد من خلال التكوينات المتسلسلة ( same_service_name.some_product_release20171102a.svc.cluster.local > same_service_name.some_product_release20171105c.svc.cluster.local ).

نظرًا لأن أسماء الإصدارات التي يتم إنشاؤها تلقائيًا هي مبتذلة على أي حال - لا يوجد إخلاص لما يقف وراء هذا الشيء في helm list ، لقد تجاوزنا --name بسلسلة مشتقة من اسم المنتج / المكدس وإصدار متزايد بشكل رتيب / build version ( "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"

أكثر من نموذجين هما أجزاء من مخططين منفصلين (مخطط استمراري ومخطط API) ويمكن تشغيلهما بشكل منفصل أو مشترك من خلال مخطط ثالث شامل. في كلتا الحالتين ، نظرًا لاستخدام .global. ، يتم تجاوز القيم مرة واحدة في سطر الأوامر ويتم تطبيقها بشكل نظيف على جميع المخططات الفرعية.

باستخدام هذا النهج ، نظرًا لأن قيمة مساحة اسم الوجهة تكون أحيانًا مشتقًا جزئيًا من ReleaseName وأحيانًا تكون شبه ثابتة ، فنحن نعتمد إلى حد كبير على ReleaseName لتكون عمومية حتى يتذمر هذا النظام إذا حاولنا إنشاء مكدس باستخدام ReleaseName العام نفسه.

تتمثل إحدى مزايا امتلاك واستخدام مساحات الأسماء في أن أسماء الكائنات (بما في ذلك أسماء DNS) داخلها محلية ولا يلزم تغييرها من مساحة الاسم إلى مساحة الاسم. على وجه التحديد في مثال dvdotsenko أعلاه ، يجب أن يكون اسم REDIS_SERVER_HOST هو نفسه (على سبيل المثال ، redis ) ويجب ألا يتم حقنه بقيم معولمة. والسبب هو تجنب التكرار.

من وجهة نظر البساطة (وبغض النظر عن بعض الحالات المعقدة بشكل طبيعي ، مثل عمليات نشر مساحة الأسماء المتعددة والكائنات التي ليست لها مسافات أسماء) ، فإن الحالة المثالية هي أن مساحة الاسم "تجمع" المكدس الخاص بك وتحتوي على مثيل واحد بالضبط من تطبيقك.

يتيح ذلك للأسماء داخل المكدس أن تكون محلية وبسيطة ، والأهم من ذلك أنها ثابتة لأنها مرتبطة بمساحة الاسم.

تتمثل إحدى الطرق الممكنة في أن تدعم helm الحالة البسيطة بشكل أو بآخر كما تفعل اليوم (مع تجنب وضع بادئة للكائنات بمساحة الاسم) ؛ سيؤدي هذا إلى إنتاج افتراضي معقول وآمن لأفضل الممارسات والذي سيعمل خارج الصندوق لمعظم الاستخدامات. ويمكن أيضا أن يكون وضع مساحة المتقدم مما يسمح بمزيد من الحرية (على حساب تعقيد)، للسماح لحالات الاستخدامdvdotsenko وbcorijn وصف.

بلدي .02 دولار

يجب أن أتفق مع pnickolov ، هذا مانع رئيسي لنا. في حالة الاستخدام الخاصة بنا ، لدينا أكثر من 150 بيئة ، ومجموعات متعددة ، والتي يجب أن تقوم بتشغيل متغيرات من نفس حزمة التطبيقات. تعمل مساحات الأسماء على حل هذه المشكلة مما يسمح بفصل البيئات وبساطة التكوين ، خاصة فيما يتعلق باكتشاف الخدمة.

بدون طريقة سهلة لتكوين نقاط نهاية الخدمة في مخططات الأشقاء ... فقط عبر القيم ...

أجد هذا محيرا أيضا. كما كتب technosophos :

لا يرتبط الإصدار بمساحة اسم. (لهذا السبب يمكن أن يحتوي الإصدار نفسه على تعريف مساحة الاسم). في الواقع ، من الممكن (على الرغم من أنني لا أستطيع أن أقول أنني حاولت شخصيًا) نشر مخطط واحد يقوم بإنشاء كائنات متعددة في مساحات أسماء متعددة.

أنا أكافح لفهم هذا بالضبط. لقد اطلعت على الوثائق ونظرت في العديد من القضايا هنا على GH وما زلت في حيرة من أمري:

• من ناحية ، يمكنني استخدام helm install --namespace لتحديد مساحة الاسم التي أرغب في استهدافها
• من ناحية أخرى ، يمكن للمخطط الخاص بي تحديد مساحات الأسماء التي يريدها داخل كائنات البيانات الوصفية الخاصة به.

إذن ، أسئلتي:

• إذا كانت مساحة الاسم المحددة بواسطة helm install --namespace غير موجودة ، فهل يقوم Helm بإنشائها؟ هل تقوم بعد ذلك بتعيين مساحة الاسم هذه على جميع الموارد التي تنشئها من chrt؟
• إذا كان قالب المورد يحدد مساحة اسم في البيانات الوصفية الخاصة به ، فهل يقوم الدفة بالكتابة فوقه؟

جعلتني هذه الأسئلة مترددة حتى في اللعب بـ --namespace ، الأمر غير واضح. إذا كان بإمكان أي شخص مساعدتي في فهم ذلك ، فسأكون ممتنًا حقًا. شكرا لك!

f مساحة الاسم المحددة بواسطة تثبيت helm - مساحة الاسم غير موجودة ، هل قام Helm بإنشائها؟

نعم. إذا لم تكن مساحة الاسم موجودة بالفعل ، فسيقوم --namespace بإنشاء مساحة الاسم المحددة للمخطط.

إذا كان قالب المورد يحدد مساحة اسم في البيانات الوصفية الخاصة به ، فهل يقوم الدفة بالكتابة فوقه؟

لا. إذا قمت بتوفير نفس مساحة الاسم في --namespace بالإضافة إلى مورد Namespace في المخطط ، فسيكون هناك تعارض حيث سيتم تثبيت مساحة الاسم أولاً بواسطة الحارث ، ثم bork عندما يحاول المخطط ذلك أعد تثبيت نفس مساحة الاسم مرة أخرى.

لمزيد من السياق ، تتمثل فكرة helm في تثبيت جميع الموارد في مساحة الاسم التي يوفرها helm install --namespace . المستخدمون الذين يقومون بـ "تشفير" مساحة الاسم في المخطط عادةً ما يريدون تثبيت مخطط في مساحات أسماء متعددة.

هذا بعيد قليلاً عن الموضوع الذي يقترحه OP ، ولكن لا تتردد في فتح تذكرة جديدة أو الانضمام إلينا على Slack إذا كان لديك المزيد من الأسئلة! :)

لست متأكدًا من أنني أريد الخوض في هذه المناقشة كن لطيفًا من فضلك

المعلمة helm --namespace هي في الحقيقة --default-namespace

تظهر قراءة المكدس والمرتبطة بها الكثير من الالتباس حول الخيار --namespace لأن الناس (بشكل معقول جدًا) يفترضون أنه مثل kubectl --namespace اعتادوا عليه ، مما يحد فعليًا من مساحة الاسم هذه (بواسطة التأثير الجانبي لخطأ التحليل ، وليس الأمان في الواقع). هذا ليس هو الحال بالنسبة لـ helm لأن tiller عبارة عن خدمة عنقودية تعمل على الكتلة بأكملها. كان من الأفضل تسمية الخيار --default-namespace ، أي. هذه هي مساحة الاسم التي ستنتقل إليها مواردك إذا لم تحدد مساحة اسم معينة.

هناك حاجة أيضًا إلى إصدارات متعددة لمساحات الأسماء

أنا أعتمد بالفعل على المخططات التي تنشر مكونات مختلفة لكل إصدار في مساحات أسماء متعددة ، وأنا أتطلع إلى تعزيز الدعم في helm 3.0. 👍 🎉

متعدد المستأجرين مع قيود على القيادة ومساحة الاسم ممكن بالفعل

أرى أيضًا حالة الاستخدام حيث يريد الأشخاص تثبيتات متعددة المستأجرين ومقيدة بمساحة الاسم. IMHO الفحص أو تقييد الإطلاقات إلى مساحات ليست شيئا helm / tiller يجب أن يهتم فرض، وهذا هو وظيفة RBAC. يوجد نموذجان على الأقل لتحقيق ذلك ، أحدهما ممكن الآن:

1. انشر لكل مساحة اسم tiller مع حساب خدمة و RBAC الذي يسمح فقط بالعمليات في مساحة الاسم تلك. هذا يعمل الآن وأرى الناس يستخدمونه. مثالية للمجموعات متعددة المستأجرين.
2. بالنسبة إلى tiller لدعم انتحال هوية مستخدم k8s ، لذا كمستخدم helm . تتم مناقشة هذا tiller بفرض قيود مساحة الاسم RBAC ، مع الاستمرار في دعم الإصدارات متعددة مساحات الأسماء.

الموارد التي تحمل نفس الاسم لإصدارات مختلفة في مساحات أسماء مختلفة ممكنة بالفعل

للأشخاص الراغبين في تثبيت نفس المخطط في مساحات أسماء مختلفة ولكن بنفس أسماء الموارد (مثل redis). هذا ممكن تمامًا ، ويرجع ذلك إلى كيفية كتابة قوالب الرسم البياني الخاصة بك. لا تحتاج إلى إضافة بادئة إلى أسماء الموارد باسم الإصدار ، فهذا مجرد مصطلح افتراضي / اصطلاح يتبعه الكثير من المخططات. تحتوي المخططات الحديثة بالفعل على قيمة .fullnameOverride التي تتيح لك إلغاء بادئة اسم الإصدار. يمكنك نشر redis كـ redis مع كل helm install إذا أردت.

نحن في وضع مشابه لـ gmile وأردنا معرفة أفضل ممارسة للقيام بذلك. تطبيقنا الأساسي ، ingestion-service يعتمد على kafka والذي بدوره يعتمد على zookeeper . لكننا نريد كل الثلاثة في مساحات الأسماء الخاصة بهم ولكننا نريد إدارتها من خلال دفة واحدة install . كنا نخطط لإضافة kafka في requirements.yaml من ingestion-service . ولكن الحصول على kafka في مساحة الاسم الخاص لا تبدو واضحة مع helm لذلك ما ذهبنا تم إزالة من requirements.yaml وجود اختلاف helm install لكل من نشر .

مجرد لمعلوماتك تم تدوينه وجزء من اقتراح Helm 3 المدرج تحت القسم 3: إدارة الولاية . نرحب بالتعليقات!

هذه أخبار رائعة @ bacongobbler 😄🎉

bacongobbler هل yaml كما هو موضح في

من مستند الاقتراح (اقرأه!: ابتسامة :):

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

كما هو الحال مع Helm 2 ، إذا أعلن مورد ما بشكل صريح عن مساحة الاسم الخاصة به (على سبيل المثال مع metadata.namespace = شيء ما) ، فسيقوم Helm بتثبيته في مساحة الاسم تلك. ولكن نظرًا لأن مراجع المالك لا يتم الاحتفاظ بها على مساحات الأسماء ، فإن أي مورد من هذا القبيل سيصبح في الأساس غير مُدار.

bacongobbler قرأته ، لكن ما زلت لا أرى أنه يدعمه. لا أقصد بيانات التعريف المشفرة بشكل ثابت في المخططات التي أتحكم فيها ، فقد تم دعمها دائمًا. ما أعنيه هو تحديد مساحة الاسم لمخطط جهة خارجية لا يمكنني تعديله. على سبيل المثال ، في متطلباتي. yaml ، أعتمد على لوحة معلومات ثابتة / kubernetes وأريد تثبيتها في نظام kube ، لكن مخططي ينتقل إلى مساحة اسم التطوير.

تصبح المشكلات قديمة بعد 90 يومًا من الخمول.
ضع علامة على المشكلة على أنها جديدة /remove-lifecycle stale .
تتعفن المشكلات التي لا معنى لها بعد 30 يومًا إضافيًا من عدم النشاط وتغلق في النهاية.

إذا كان إغلاق هذه المشكلة آمنًا الآن ، فيرجى القيام بذلك باستخدام /close .

إرسال التعليقات إلى اختبار سيج ، kubernetes / test-infra و / أو fejta .
/ دورة الحياة التي لا معنى لها

يبدو أن طلب الميزة بالذات يمكن تحقيقه بواسطة helmfile . من ما هو موجود في الملف التمهيدي ، يجب أن يكون من الممكن تحديد إصدارات مختلفة في نطاق لمساحات الأسماء الخاصة بهم.

gmile أنا متأكد بنسبة 99٪ من أن مشرفو helmfile لم يصلحوا هذه المشكلة بالذات في helmfile. إذا أعلنت عن إصدارين باسم vault بهما مساحات أسماء مختلفة في helmfile.yaml وقمت بتشغيل helmfile sync ، فسوف تفشل لأن اسم الإصدار vault تمت المطالبة به من خلال الإصدار الأول.

إخلاء المسؤولية: لم أختبر هذا باستخدام helmfile ، لذلك أحب أن يتم إخباري أنني مخطئ. 😄

فقط في حالة فقد التعليق الأخير ، فإننا نتناول هذا في Helm 3 بالتغييرات في كيفية تعامل Helm مع الإصدارات . :)

@ steven-sheehy يمكن إصلاح هذه المشكلة المعينة عبر نموذج وضع الحماية من خلال توسيع المخطط الفرعي للنشر إلى مساحة اسم معينة أكثر مما تم تحديده.

/ إزالة دورة الحياة التي لا معنى لها

ذات صلة: https://discuss.kubernetes.io/t/timeline-for-helm-3/2776

تم التنفيذ في Helm 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 لذا لست متأكدًا من مقدار ذلك يغير التحديات.

تضمين التغريدة

أحاول أن أفهم كيف يتفاعل Helm v2 مع مساحات الأسماء وكيف سيكون الإصدار 3 مختلفًا ، وأحد تعليقاتك القديمة في هذا الموضوع يربكني:

أولاً ، دعني أعيد التأكيد على النقطة الرئيسية: تعمل مخططات Helm على مستوى عالمي ، وليس على مستوى مساحة الاسم. لذلك فإن أسمائهم فريدة من نوعها على مستوى العالم.

....

بالنسبة للعناصر التي ليس لها مسافة أسماء ، ستصبح الأمور معقدة للغاية. كان لدينا إصدارات ذات مسافات اسم تدير أشياء بدون مسافة أسماء والتي بدورها يمكن أن تؤثر على مساحات الأسماء الأخرى. يرجى إلقاء نظرة على كيفية عمل RBACs و TPRs. هذه ليست أشياء يمكن أن يقرر Helm ببساطة عدم دعمها ، و "تزوير" مساحة اسم من شأنه أن يسبب مشاكل أكثر مما تستحق ، خاصة مع RBACs.

يبدو أن الإصدارات التي تم نشرها من Helm v3 ستكون في الواقع بأسماء مختلفة ؛ هل هذا صحيح؟ هل تعرف كيف تم حل مشكلة RBAC؟ الحل الوحيد الذي يمكنني التفكير فيه والذي من شأنه تجنب المشكلة التي أشرت إليها هو أن مخططات Helm v3 لا تدعم تعديل كائنات RBAC ، لكنني لم أجد أي شيء في منشورات المدونة المختلفة وما إلى ذلك حول v3 يشير إلى ما إذا كانت مخططات v3 ستدعم الإدارة كائنات RBAC أم لا.

كل ما نحتاجه حقًا هو أن نتمكن من استخدام معلمة مساحة الاسم و
اسم المعلمة كمفتاح مركب لتحديد الإصدار بدلاً من إلصاقه
مساحة اسم على اسم.

لم أقرأ اقتراح helm v3 ، لكن الشيء المنطقي الذي يجب فعله هو
اعتماد نمط المحدد الذي تستخدمه k8s بالفعل ولا داعي لذلك
دعم أي مجالات محددة.

في الثلاثاء ، 25 حزيران (يونيو) 2019 ، الساعة 11:01 صباحًا كتب BatmanAoD [email protected] :

technosophos https://github.com/technosophos

أحاول أن أفهم كيف يتفاعل Helm v2 مع مساحات الأسماء وكيف v3
سيكون مختلفًا ، وأحد تعليقاتك القديمة في هذا الموضوع تحيرني:

أولاً ، اسمحوا لي أن أعيد التأكيد على النقطة الرئيسية: تعمل مخططات Helm على مستوى عالمي
المستوى ، وليس على مستوى مساحة الاسم. لذا فإن أسمائهم فريدة من نوعها على مستوى العالم ...

بالنسبة للعناصر التي ليس لها مسافة أسماء ، ستصبح الأمور معقدة للغاية. لكنا لدينا
الإصدارات ذات مساحة الاسم التي تدير الأشياء التي ليس لها مسافات اسم والتي بدورها يمكن أن
تؤثر على مساحات الأسماء الأخرى. يرجى إلقاء نظرة على كيفية عمل RBACs و TPRs.
هذه ليست أشياء يمكن أن يقرر هيلم ببساطة عدم دعمها ، و
"تزوير" مساحة اسم من شأنه أن يسبب مشاكل أكثر مما تستحق ، على وجه الخصوص
مع RBACs.

يبدو أن الإصدارات التي تم نشرها من Helm v3 ستكون في الواقع بأسماء مختلفة ؛
هل هذا صحيح؟ هل تعرف كيف تم حل مشكلة RBAC؟ الوحيد
القرار الذي يمكنني التفكير فيه يتجنب المشكلة التي أشرت إليها
لا تدعم مخططات Helm v3 تعديل كائنات RBAC ، لكني لم أجدها
أي شيء في منشورات المدونة المختلفة وما إلى ذلك حول الإصدار 3 يشير إلى ما إذا كان الإصدار v3
الرسوم البيانية ستدعم إدارة كائنات RBAC أم لا.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/helm/helm/issues/2060؟email_source=notifications&email_token=AACFHREXHFSKFSB7FXQ5VPTP4JMP3A5CNFSM4DCII7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LN
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AACFHRH2JPXPKMX23WVQLCDP4JMP3ANCNFSM4DCII7XQ
.

BatmanAoDgyndick في هيلم V3، يتم تثبيت الخرائط في سياق المستخدم. هذا يعني أنه مثبت في مساحة اسم المستخدم وسيستخدم RBAC للمستخدم. أسماء الإصدارات على أساس مساحة الاسم أيضًا.

يمكنك تجربته مع الإصدار Alpha.1: https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1 أو الإنشاء من الفرع dev-v3 .

لن أستخدم helm v3. كل فريق عمليات مختلف
القيود وطرق فعل الأشياء. يجب أن تكون الأدوات التشغيلية بسيطة ،
المرافق ذات الغرض الواحد ، أي متوافقة مع فلسفة يونكس.

البرمجة النصية والمنطق وما إلى ذلك تعيش خارج مدير الحزم الخاص بي.

TLDR ؛

أهم جانب في التوافق مع فلسفة يونكس هو
القدرة على توفير فتحات هروب بين الدرجات.

وجود سير عمل آلي طويل يعتني بالخدمات اللوجستية من
من المهد إلى اللحد رهيب حتى ينكسر. إذا لم يتم تزويد المستخدمين بامتداد
القدرة على تنفيذ كل خطوة من خطوات تدفق الأتمتة المطلوبة يدويًا
يصبح صندوق باندورا.

التعقيد المقترح للإصدار 3 سوف يستدعي العديد من الأخطاء والسيئة
تصميم من أشخاص لا يتمتعون بخبرة 25 عامًا.

التعقيد الإضافي فقط سيجعل الأمور أكثر صعوبة لأنه دائمًا ،
الأدوات التشغيلية التي تصبح بيئات تطوير خاصة بهم فقط
إبطاء الفرز.

المثال المثالي هو عندما يقنن شخص ما في واحدة ضخمة ، بشكل رهيب
نص مكتوب. يحدث انقطاع وتحتاج أجزاء من النص إلى التشغيل ،
يجب تجنب الأجزاء الأخرى بشكل صارم ، ولكن هذه الأجزاء جزء لا يتجزأ من
المنطق الرئيسي. ماذا تفعل بعد ذلك بحق الجحيم؟ اجلس هناك محاولًا بشكل محموم
لإعادة بناء التعليمات البرمجية بحيث لا تمتلك طريقة جيدة لتصحيح الأخطاء.

فكر في جميع الأدوات التي تدخل في نظام بيئي لدعمها
تطوير وتشغيل البرامج بأي لغة معينة. أنت لست
ستكون قادرًا على توفير ذلك للقيادة لبعض الوقت.

لذلك ، احتفظ بمسؤولية كيفية إدارة الترحيل بين إصدارات
برنامج مع الأشخاص الذين يطورون البرنامج الجاري نشره.

يجب أن يكون مدير الحزم بسيطًا وخفيفًا مع عدد قليل من
المسؤوليات.

1. تسليم القطع الأثرية
2. إزالة القطع الأثرية
3. قم بتشغيل البرامج النصية المتوفرة في القطع الأثرية
4. تتبع القطع الأثرية التي تعتقد أنها سلمتها
5. الأهم من ذلك ، KISS

أي شيء آخر يطلب الألم. بصراحة ، سيكون helm v2 مثاليًا تقريبًا
إذا تم إصلاح كيفية تتبع الإصدارات.

في الأربعاء ، 26 يونيو ، 2019 ، 1:31 صباحًا ، Martin Hickey [email protected]
كتب:

BatmanAoD https://github.com/BatmanAoD gyndick في هيلم V3، الرسوم البيانية هي
مثبتة في سياق المستخدم. هذا يعني أنه تم تثبيته في هذا المستخدم
مساحة الاسم وستستخدم RBAC للمستخدم. أسماء الإصدار موجودة على أ
أساس مساحة الاسم أيضا.

يمكنك تجربته مع إصدار Alpha.1:
https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1 أو البناء من
فرع dev-v3.

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/helm/helm/issues/2060؟email_source=notifications&email_token=AACFHREUTX77SJCPWZLQKATP4MSNRA5CNFSM4DCII7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63HS4DFVREXG43VMVBW63HS4DFVREXG43VMVBW63HS4DFVREXG43VMVBW63HS4DFVREXG43VMVBW63HS4DFVREXG43VMVBW63HS4DFVYXG43VMVBW63HS4DFYSG43VMVBW63
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AACFHRCAQLWUYHH6RJSUYF3P4MSNRANCNFSM4DCII7XQ
.

hickeyma شكرا على الرد! أنا في الواقع لا أتساءل كثيرًا عن كيفية التحكم في الوصول إلى عمليات Helm (على الرغم من أن هذه مشكلة ذات صلة) مثل ما إذا كانت Helm نفسها ستظل قادرة على أداء عمليات عالمية مثل إنشاء ClusterRoles في الإصدار 3.

BatmanAoD يجب أن يعمل ذلك لأنها موارد نطاق الكتلة. قد يكون الأمر يستحق التجربة إذا سنحت لك الفرصة.