Helm: خطأ: configmaps محظور: المستخدم "system: serviceaccount: kube-system: افتراضي" لا يمكن سرد الموارد "configmaps" في مجموعة API "" في مساحة الاسم "kube-system"

تم إنشاؤها على ٢٦ ديسمبر ٢٠١٨  ·  16تعليقات  ·  مصدر: helm/helm

أحاول متابعة تثبيت TILLER ، ولكني أواجه الخطأ التالي:

$ helm list
Error: configmaps is forbidden: User "system:serviceaccount:kube-system:default" cannot list resource "configmaps" in API group "" in the namespace "kube-system"
$

ناتج helm version :

$ helm version
Client: &version.Version{SemVer:"v2.12.1", GitCommit:"02a47c7249b1fc6d8fd3b94e6b4babf9d818144e", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.12.1", GitCommit:"02a47c7249b1fc6d8fd3b94e6b4babf9d818144e", GitTreeState:"clean"}
$ 

الناتج kubectl version :

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:39:04Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:31:33Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/amd64"}
$ 

مزود / منصة السحابة (AKS ، GKE ، Minikube وما إلى ذلك):

المعادن العارية ، لينكس

من المحتمل أن يكون ذلك مرتبطًا ، فأنا أحاول أيضًا الوصول إلى Tiller و Role-Based Access Control ، ومع ذلك أحصل على 404.

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

ليس من الجيد إغلاق مشكلة بدون شرح طريقة الإصلاح :-)
اسمحوا لي أن أفعل ذلك بدلا من ذلك.

خطأ: configmaps محظور: المستخدم " system: serviceaccount : kube- system: default " لا يمكنه القائمة

أولا ، بعض المعلومات للمبتدئين.
يوجد في Kubernetes:

  • الحساب - شيء مثل هويتك. مثال: john
  • الدور - يسمح لبعض المجموعات في المشروع بفعل شيء ما. أمثلة: إدارة الكتلة ، دعم تكنولوجيا المعلومات ، ...
  • الربط - ربط الحساب بالدور. "يوحنا في دعمه" - ملزم.

وهكذا ، في رسالتنا أعلاه ، نرى أن Tiller يعمل كحساب "افتراضي" مسجل في مساحة الاسم "kube-system". على الأرجح أنك لم تربطه بدور كافٍ.

الآن عد إلى المشكلة.
كيف نتتبع ذلك:

  • تحقق مما إذا كان لديك حساب محدد للحارث. عادة ما يكون له نفس الاسم - "الحارث":
    kubectl [--namespace kube-system] get serviceaccount
    خلق إذا لم يكن:
    kubectl [--namespace kube-system] create serviceaccount tiller
  • تحقق مما إذا كان لديك دور أو مجموعة عنقودية (دور الكتلة هو "أفضل" للمبتدئين - فهو على مستوى الكتلة على عكس الدور على مستوى مساحة الاسم). إذا لم يكن هذا إنتاجًا ، فيمكنك استخدام الدور ذي الامتيازات العالية "مشرف المجموعة":
    kubectl [--namespace kube-system] get clusterrole
    يمكنك التحقق من محتوى الدور عبر:
    kubectl [--namespace kube-system] get clusterrole cluster-admin -o yaml
  • تحقق مما إذا كان الحساب "الحارث" في الفقرة الأولى له ارتباط بـ clusterrole "إدارة الكتلة" التي تراها كافية:
    kubectl [--namespace kube-system] get clusterrolebinding
    إذا كان من الصعب التعرف على الأسماء بناءً على الأسماء ، فيمكنك ببساطة إنشاء:
    kubectl [--namespace kube-system] create clusterrolebinding tiller-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
  • أخيرًا ، عندما يكون لديك الحساب والدور والربط بينهما ، يمكنك التحقق مما إذا كنت تتصرف بالفعل مثل هذا الحساب:
    kubectl [--namespace kube-system] get deploy tiller-deploy -o yaml

أظن أن مخرجاتك لن تحتوي على إعدادات "serviceAccount" و "serviceAccountName":

...
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
...

إذا كانت الإجابة بنعم ، فقم بإضافة حساب تريد أن تستخدمه الحراثة:
kubectl [--namespace kube-system] patch deploy tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'
(إذا كنت تستخدم PowerShell ، فابحث أدناه عن النشر منsnpdev)
الآن كرر أمر الفحص السابق ولاحظ الفرق:

...
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
serviceAccount: tiller                     <-- new line
serviceAccountName: tiller          <-- new line
terminationGracePeriodSeconds: 30
...

نعم. شئ مثل هذا.

ال 16 كومينتر

عنوان URL جديد لأي شخص يبحث: https://helm.sh/docs/rbac/#role -based-access-control

ليس من الجيد إغلاق مشكلة بدون شرح طريقة الإصلاح :-)
اسمحوا لي أن أفعل ذلك بدلا من ذلك.

خطأ: configmaps محظور: المستخدم " system: serviceaccount : kube- system: default " لا يمكنه القائمة

أولا ، بعض المعلومات للمبتدئين.
يوجد في Kubernetes:

  • الحساب - شيء مثل هويتك. مثال: john
  • الدور - يسمح لبعض المجموعات في المشروع بفعل شيء ما. أمثلة: إدارة الكتلة ، دعم تكنولوجيا المعلومات ، ...
  • الربط - ربط الحساب بالدور. "يوحنا في دعمه" - ملزم.

وهكذا ، في رسالتنا أعلاه ، نرى أن Tiller يعمل كحساب "افتراضي" مسجل في مساحة الاسم "kube-system". على الأرجح أنك لم تربطه بدور كافٍ.

الآن عد إلى المشكلة.
كيف نتتبع ذلك:

  • تحقق مما إذا كان لديك حساب محدد للحارث. عادة ما يكون له نفس الاسم - "الحارث":
    kubectl [--namespace kube-system] get serviceaccount
    خلق إذا لم يكن:
    kubectl [--namespace kube-system] create serviceaccount tiller
  • تحقق مما إذا كان لديك دور أو مجموعة عنقودية (دور الكتلة هو "أفضل" للمبتدئين - فهو على مستوى الكتلة على عكس الدور على مستوى مساحة الاسم). إذا لم يكن هذا إنتاجًا ، فيمكنك استخدام الدور ذي الامتيازات العالية "مشرف المجموعة":
    kubectl [--namespace kube-system] get clusterrole
    يمكنك التحقق من محتوى الدور عبر:
    kubectl [--namespace kube-system] get clusterrole cluster-admin -o yaml
  • تحقق مما إذا كان الحساب "الحارث" في الفقرة الأولى له ارتباط بـ clusterrole "إدارة الكتلة" التي تراها كافية:
    kubectl [--namespace kube-system] get clusterrolebinding
    إذا كان من الصعب التعرف على الأسماء بناءً على الأسماء ، فيمكنك ببساطة إنشاء:
    kubectl [--namespace kube-system] create clusterrolebinding tiller-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
  • أخيرًا ، عندما يكون لديك الحساب والدور والربط بينهما ، يمكنك التحقق مما إذا كنت تتصرف بالفعل مثل هذا الحساب:
    kubectl [--namespace kube-system] get deploy tiller-deploy -o yaml

أظن أن مخرجاتك لن تحتوي على إعدادات "serviceAccount" و "serviceAccountName":

...
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
...

إذا كانت الإجابة بنعم ، فقم بإضافة حساب تريد أن تستخدمه الحراثة:
kubectl [--namespace kube-system] patch deploy tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'
(إذا كنت تستخدم PowerShell ، فابحث أدناه عن النشر منsnpdev)
الآن كرر أمر الفحص السابق ولاحظ الفرق:

...
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
serviceAccount: tiller                     <-- new line
serviceAccountName: tiller          <-- new line
terminationGracePeriodSeconds: 30
...

نعم. شئ مثل هذا.

حل @ m-abramovich بالنسبة لي.

ملاحظة: في حالة استخدام Powershell ، يكون الأمر:

kubectl --namespace kube-system patch deploy tiller-deploy -p '{\"spec\":{\"template\":{\"spec\":{\"serviceAccount\":\"tiller\"}}}}'

وشرتان ونصف لا يزال شرحك مفيدًا ، شكرًا جزيلاً لك على قضاء الوقت في جدولك المزدحم ليكون مفصلاً ومفيدًا. @ m-abramovich على عكس bacongobbler

وشرتان ونصف لا يزال شرحك مفيدًا ، شكرًا جزيلاً لك على قضاء الوقت في جدولك المزدحم ليكون مفصلاً ومفيدًا. @ m-abramovich على عكس bacongobbler

الشخص الذي أغلق هذه المشكلة هو الشخص الذي فتحها. من الواضح أنهم شعروا أن المشكلة قد تم حلها.

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

أخيرًا ، استغرق bacongobbler وقتًا لتقديم المعلومات المطلوبة في الخامس والعشرين من ديسمبر ، والذي يعتبر بالنسبة للكثيرين عطلة مهمة. أنا آسف iamaverrick لكني أجد أن تعليقك غير مناسب تمامًا.

رائع. لا أتذكر حتى الرد على هذا الموضوع ... مر وقت طويل.

افتراض marckhouzam هنا صحيح: تم فتح القضية في يوم عيد الميلاد. صادف أن كنت مع عائلتي في ذلك اليوم ، لكنني رأيت هذا السؤال السريع من OP:

من المحتمل أن يكون ذلك مرتبطًا ، فأنا أحاول أيضًا الوصول إلى Tiller و Role-Based Access Control ، ومع ذلك أحصل على 404.

لذلك اعتقدت أنني سألتقط إجابة سريعة بالرابط الصحيح وأعود للاحتفال بعيد الميلاد. في اليوم التالي ، أغلقت OP القضية ، لذلك افترضت أنه لم تكن هناك حاجة إلى مزيد من المتابعة.

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

شكرًا لك على @ m-abramovich و snpdev على المتابعة وتقديم إجابات لمشكلة OP.

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

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

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

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

marckhouzam غير مناسب؟ لم أكن أحترم أي شخص بتعليقي بأي شكل أو شكل. لقد ذكرت الحقائق من وجهة نظري. تم ذكر هذا التعليق مباشرة bacongobbler وليس أي شخص آخر وضع هناك 2 سنت. أقدر @ bacongobbler للصق الرابط في عطلة. يشير السؤال الأصلي إلى أنه كان يواجه مشكلات ويحتاج إلى إرشادات وليس رابطًا. أيها الرجال ، إذا كنت لا تستطيع تحمل النقد البناء ، فلا تنشر أي شيء على هذه المواضيع. نحن جميعًا مطورو برامج نحاول أن نصبح أفضل ونقدم معلومات أفضل.

أعتذر عن عدم إثبات إجابتي بمزيد من التفاصيل حيث ألمحت نوعًا ما إلى الإجابة في سؤالي ثم أكد @ bacongobbler إجابتي ، متبوعًا بتعليق رائع من @ m-abramovich

أنا حقًا أقدر مساعدة و / أو مدخلات الجميع وسأحاول القيام بعمل أفضل في المرة القادمة ، أعدك!

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

سنتي: عند اتباع https://helm.sh/docs/intro/quickstart/ ، لا يوجد ذكر لـ RBAC والتعليمات هناك تؤدي إلى تثبيت غير عامل للحارث. ثم يؤدي بحث google إلى هذه المشكلة هنا.

ربما يمكن إعادة فتحه "كتعزيز دليل البدء السريع بحيث يحذر المبتدئين من هذا المأزق"؟

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

حتى لو لاحظت أنني بحاجة إلى القيام بشيء ما ، فلا يوجد رابط للتعليمات.

سنتي: عند اتباع https://helm.sh/docs/intro/quickstart/ ، لا يوجد ذكر لـ RBAC والتعليمات هناك تؤدي إلى تثبيت غير عامل للحارث. ثم يؤدي بحث google إلى هذه المشكلة هنا.

ربما يمكن إعادة فتحه "كتعزيز دليل البدء السريع بحيث يحذر المبتدئين من هذا المأزق"؟

تضمين التغريدة
باتريك ، أعتقد أن هذا لم يعد ذا صلة.
لا يستخدم Helm v3 Tiller. لذا ، ربما ، كل هذا لا قيمة له الآن.

@ m-abramovich شكرا لك! ساعدتني مسيرتك التفصيلية في تجاوز هذه المشكلة. أقدر كثيرًا الوقت الذي استغرقته لكتابة ردك.

هذا الشرح عظيم! شكرا!

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