Я пытаюсь следовать УСТАНОВКЕ 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.
Новый URL для всех, кто ищет: https://helm.sh/docs/rbac/#role-based-access-control .
Нехорошо закрывать проблему, не объяснив, как исправить :-)
Позвольте мне сделать это вместо этого тогда.
Ошибка: configmaps запрещен: Пользователь " system: serviceaccount :kube- system:default " не может перечислить
Для начала немного информации для новичков.
В Кубернете есть:
Таким образом, в нашем сообщении выше мы видим, что наш 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
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\"}}}}'
и 2 месяца и 1/2 ваше объяснение все еще полезно, большое спасибо за то, что нашли время в своем плотном графике, чтобы быть подробным и полезным. @m-abramovich в отличие от @bacongobbler
и 2 месяца и 1/2 ваше объяснение все еще полезно, большое спасибо за то, что нашли время в своем плотном графике, чтобы быть подробным и полезным. @m-abramovich в отличие от @bacongobbler
Человек, который закрыл этот вопрос, был человеком, который его открыл. Очевидно, они считали, что проблема решена.
Кроме того, в исходном описании запрашивалась правильная ссылка на документацию по управлению доступом на основе ролей, которая была предоставлена без закрытия проблемы.
Наконец, @bacongobbler нашел время предоставить запрошенную информацию 25 декабря, что для многих является важным праздником. Извините , @iamaverrick, но я считаю ваш комментарий совершенно неуместным.
Ух ты. Я даже не помню, чтобы отвечал в этой ветке... Давненько.
Предположение @marckhouzam верно: выпуск был открыт в Рождество. В тот день я был со своей семьей, но я увидел этот быстрый вопрос от ОП:
возможно, связано, я также пытаюсь получить доступ к Tiller и Role-Based Access Control , но получаю 404.
Поэтому я решил, что напишу быстрый ответ с правильной ссылкой и вернусь к празднованию Рождества. На следующий день ОП закрыл проблему, поэтому я предположил, что дальнейших действий не требуется.
Меня действительно расстраивает мысль, что мой комментарий был воспринят как краткий или бесполезный. Я не пытался решить проблему; Я просто предоставлял контекст, пока ОП пытается найти решение самостоятельно в праздничный сезон.
Спасибо @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 приводит к этой проблеме здесь.
Возможно, его можно снова открыть как «улучшить краткое руководство, чтобы оно предупреждало новичков об этой ловушке»?
@pohly
Патрик, я считаю, что это уже не актуально.
Helm v3 не использует Tiller. Так что, может быть, все это уже ничего не стоит.
@m-abramovich Спасибо! Ваше подробное руководство помогло мне разобраться с этой проблемой. Я очень ценю время, которое вы потратили, чтобы написать свой ответ.
Это объяснение прекрасно! Спасибо!
Самый полезный комментарий
Нехорошо закрывать проблему, не объяснив, как исправить :-)
Позвольте мне сделать это вместо этого тогда.
Для начала немного информации для новичков.
В Кубернете есть:
Таким образом, в нашем сообщении выше мы видим, что наш 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
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»:
если да, то добавьте учетную запись, которую вы хотите использовать на румпеле:
kubectl [--namespace kube-system] patch deploy tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'
(если вы используете PowerShell, проверьте ниже пост от @snpdev)
Теперь вы повторяете предыдущую команду проверки и видите разницу:
да. Что-то такое.