Helm: النظام: الافتراضي غير كافٍ للقيادة ، ولكنه يعمل مع kubectl

تم إنشاؤها على ١٤ يوليو ٢٠١٧  ·  22تعليقات  ·  مصدر: helm/helm

مشكلة

أبلغ Helm عن عدم وجود ACL كسبب لعدم تمكنه من عمل قائمة configmaps / pods / etc ... ومع ذلك ، فإن kubeconfig الذي يستخدمه صالح. هذا مربك ب / ج ، فهو يخلط بين فشل Tiller مع فشل العميل ، وليس من الواضح ما إذا كان عميل الدفة ينكسر ، أو ما إذا كان Tiller ينكسر.

على سبيل المثال ، تظهر سجلات الحارث بشكل أساسي نفس الشيء مثل فشل العميل.

المحلول

اجعل عميل الدفة أكثر دفاعية.

  • يجب أن تفشل عمليات عميل Helm بسرعة ، وشرح أنهم يفشلون b / c الحارث لا يعمل.
  • يجب أن يبلغ فشل عميل Helm دائمًا ما إذا كان خطأ في المصب (الحارث) أو ما إذا كان خطأ في العميل.
  • من الناحية المثالية ، أود أيضًا معرفة سبب فشل أداة الحرث الخاصة بي ، ولكن آمل أن أتمكن من معرفة ذلك بمفردي :).

تفاصيل

لديّ جهاز يعمل بنظام التشغيل Linux حيث يكون المشرف قادرًا على سرد البودات وخرائط التكوين وما إلى ذلك:

ubuntu@ip-10-0-22-242:/opt$ kubectl  get configmaps
NAME             DATA      AGE
hub-config       6         2d
special-config   3         2d

باستخدام عميل kubectl قياسي .... ومع ذلك ، مع helm ، أحصل على خطأ:

ubuntu@ip-10-0-22-242:/opt$ export KUBECONFIG=/home/ubuntu/kubeconfig
ubuntu@ip-10-0-22-242:/opt$ helm-exec list
Error: User "system:serviceaccount:kube-system:default" cannot list configmaps in the namespace "kube-system". (get configmaps)

تفاصيل إصدار هيلم

ubuntu@ip-10-0-22-242:/opt$ helm-exec version
Client: &version.Version{SemVer:"v2.5.0", GitCommit:"012cb0ac1a1b2f888144ef5a67b8dab6c2d45be6", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.5.0", GitCommit:"012cb0ac1a1b2f888144ef5a67b8dab6c2d45be6", GitTreeState:"clean"}

يبدو أن مستخدم Helm صحيح (admin @ kubernetes) ولكن عند البحث بشكل أعمق عن الحارث:

ubuntu@ip-10-0-22-242:/opt$ kubectl logs tiller-deploy-3703072393-pn7f6 --namespace=kube-system
[main] 2017/07/13 22:50:37 Starting Tiller v2.5.0 (tls=false)
[main] 2017/07/13 22:50:37 GRPC listening on :44134
[main] 2017/07/13 22:50:37 Probes listening on :44135
[main] 2017/07/13 22:50:37 Storage driver is ConfigMap
[storage] 2017/07/14 15:02:51 listing all releases with filter
[storage/driver] 2017/07/14 15:02:51 list: failed to list: User "system:serviceaccount:kube-system:default" cannot list configmaps in the namespace "kube-system". (get configmaps)
[storage] 2017/07/14 15:03:18 listing all releases with filter
[storage/driver] 2017/07/14 15:03:18 list: failed to list: User "system:serviceaccount:kube-system:default" cannot list configmaps in the namespace "kube-system". (get configmaps)
[storage] 2017/07/14 15:06:36 listing all releases with filter
[storage/driver] 2017/07/14 15:06:36 list: failed to list: User "system:serviceaccount:kube-system:default" cannot list configmaps in the namespace "kube-system". (get configmaps)
[storage] 2017/07/14 15:07:25 listing all releases with filter
[storage/driver] 2017/07/14 15:07:25 list: failed to list: User "system:serviceaccount:kube-system:default" cannot list configmaps in the namespace "kube-system". (get configmaps)
[storage] 2017/07/14 15:07:54 listing all releases with filter
[storage/driver] 2017/07/14 15:07:54 list: failed to list: User "system:serviceaccount:kube-system:default" cannot list configmaps in the namespace "kube-system". (get configmaps)
[storage] 2017/07/14 15:11:57 listing all releases with filter
[storage/driver] 2017/07/14 15:11:57 list: failed to list: User "system:serviceaccount:kube-system:default" cannot list configmaps in the namespace "kube-system". (get configmaps)
proposal

التعليق الأكثر فائدة

لكل نصيحة jayunit100 ، أضف الدور cluster-admin إلى حساب الخدمة kube-system:default يعمل بالنسبة لي ، أدناه هو cmd.

kubectl create clusterrolebinding add-on-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default

ال 22 كومينتر

لقد أصلحت مشكلتي - كانت تتعلق بتشغيل الأشياء في نظام kube. لا أعرف لماذا لم يتمكن عميل الدفة (باستخدام نفس kubeconfig مثل kubectl الخاص بي) من الوصول إلى NS ، لكنني أعتقد أنه يجب علينا طباعة تحذير عند تثبيت مساحة اسم مخصصة helm w / oa.

@ jayunit100 هل يمكنك من فضلك أن تشرح كيف يمكنك

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

  • http://jayunit100.blogspot.com/2017/07/helm-on.html كتبت ملاحظاتي هنا. tiller-namespace= تبديل مساحة الاسم نيابةً عنك ، ولكن على الأرجح ،
  • إذا كنت ترى أخطاء failed to list ، فإن المشكلة الحقيقية التي تواجهها هي أنه ، بشكل افتراضي ، لا تضيف مجموعتك حساب خدمة إلى البودات مما يسمح لقرون الحرث بسرد الأشياء.

  • لذا فإن الحيلة الحقيقية هي أنه يجب عليك التأكد من وجود حساب خدمة مطابق ، والذي يمنح الامتيازات التي يحتاجها القائد ، مثل

roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
  • ملاحظة أخيرة: قد يكون حساب svc أعلاه مجموعة شاملة لما هو مطلوب فعلاً للقيادة ، ولكنه يعمل ، وقد تمت مشاركته مع أشخاص heptio ، حسب الضرورة في بعض المجموعات ، اعتمادًا على حسابات الخدمة الافتراضية التي تحصل عليها pods انطلقت مع /

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

@ jayunit100 مشاركة مدونة لطيفة! لقد قمت بحلها بالمثل ، ولكن كان علي حل بعض المشكلات الأخرى في OpenShift أيضًا. لقد نزلت بشكل أساسي إلى نفس المشكلة ، على الرغم من أن rbac يحظر وصولي ، ويحتاج إلى إضافة مسؤول الكتلة إلى حساب الخدمة الذي ينشر الحارث. لقد قمت أيضًا بنشره في مساحة اسم مختلفة واضطررت إلى إزالة بعض محددات العقد ، وما إلى ذلك (على الرغم من أنني تجاوزت تلك النقطة بالفعل عندما نشرت سؤالي هنا). آمل أن تتم الموافقة على اقتراحك للسماح للآخرين بحل هذه المشكلة بسهولة أكبر في المستقبل. :)

نعم بالتأكيد آمل ذلك. يسعدني المساعدة في التنفيذ أيضًا ؛ قد تحتاج إلى بعض المؤشرات حول كيفية تحسين أداء التطوير / الاختبار. سوف أتحقق من المستندات أولاً

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

لكل نصيحة jayunit100 ، أضف الدور cluster-admin إلى حساب الخدمة kube-system:default يعمل بالنسبة لي ، أدناه هو cmd.

kubectl create clusterrolebinding add-on-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default

لماذا تقوم بتشغيل Tiller مع حساب الخدمة "الافتراضي"؟

يبدو هذا مرتبطًا وسيتم إغلاقه على الأرجح من خلال الوثائق المقترحة في https://github.com/kubernetes/helm/issues/2962.

seh أنا أقوم بتشغيل الدفة مع الإعدادات الافتراضية ، حيث تشير الإرشادات إلى القيام بـ "helm init" وما حصلت عليه هو هذا الموقف ، فإنه يقوم بتثبيت Tiller-publish-xxxx في مساحة اسم نظام kube وأفترض ذلك افتراضيًا يحاول استخدام حساب الخدمة الافتراضي أيضًا.

أعتقد أنه يمكننا إغلاق هذا الآن بعد أن تم دمج 3094 # وهو متاح للعرض على https://docs.helm.sh/using_helm/#role -based-access-control. سأغلق هذا ولكن يرجى إعلامنا إذا كان هناك شيء آخر فاتنا. شكرا!

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

يجب أن يكون حساب الخدمة الافتراضي موجودًا بالفعل بواسطة ... يضع ظلالًا ... افتراضيًا. 😎

أليست هذه الحالة؟ لم أسمع بحالة من قبل حيث لا يوجد حساب الخدمة الافتراضي في نظام kube.

للحصول على معلومات أساسية ، ليس لدى Helm (وبالتالي الحارث) أي فكرة عن ماهية حساب الخدمة. إنهم يحتاجون فقط للتحدث إلى خادم kubernetes API. هناك العديد من حالات الاستخدام المختلفة في بيئات RBAC ، ويمكن رؤية بعضها helm init ومستخدمي pigeon hole في سيناريو واحد.

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

ولا يتم وصفه في أي مكان ، باستثناء صفحة منفصلة ، مما يقودني إلى الاعتقاد بأنه مشكلة جانبية ، أو موضوع متقدم ، ولكن هذا أمر بالغ الأهمية لجعله يعمل في وضع kubernetes الافتراضي RBAC

@ leejian0612 شكرًا جزيلاً ، لقد كنت عالقًا لمدة 3 أيام تقريبًا مع المشكلة https://github.com/kubernetes/helm/issues/2464#issuecomment -356986809 وبعد حل هذه المشكلة التي تم حلها باقتراحك .
راجع أيضًا https://github.com/kubernetes/helm/issues/2464#issuecomment -381101015
chrisglass أتفق معك تمامًا. يجب أن يكون جزءًا من Helm doc ، على سبيل المثال قسم الأسئلة الشائعة.

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

kubectl -n kube-system edit deploy/tiller-deploy

# add these two lines in container (tiller) scope
serviceAccount: admin-user
serviceAccountName: admin-user

هذا الحل أكثر أمانًا من إنشاء ربط المجموعات بالمعلمات التالية (--clusterrole = إدارة المجموعة --serviceaccount = kube-system: افتراضي).

أهلا

@ النتائج
لقد جربت هذا ولكن ما زلت أتلقى هذا الخطأ:
Error: configmaps is forbidden: User "system:serviceaccount:kube-system:default" cannot list configmaps in the namespace "kube-system"
هل هناك شيء فاتني؟

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

  1. تشغيل helm init
  2. kubectl -n kube-system edit deploy/tiller-deploy والسطرين العلويين
  3. ابدأ بملاحظة قرون الحارث kubectl get pods -w | grep tiller ؛ يجب ألا يفشلوا.

لا حظ بعد.! مع ما سبق

باستخدام هذه الأسطر ، تم إصلاح pb الخاص بي:

# kubectl create clusterrolebinding add-on-cluster-admin \
  --clusterrole=cluster-admin \
  --serviceaccount=kube-system:default
clusterrolebinding "add-on-cluster-admin" created
# helm reset     

Error: error unstalling Tiller: timed out waiting for the condition

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

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات