Helm: 오류: configmaps는 금지됨: 사용자 "system:serviceaccount:kube-system:default"는 "kube-system" 네임스페이스의 API 그룹 ""에 있는 리소스 "configmaps"를 나열할 수 없습니다.

https://docs.helm.sh/using_helm/#role 기반 액세스 제어

찾는 사람을 위한 새 URL: https://helm.sh/docs/rbac/#role -based-access-control

해결 방법을 설명하지 않고 문제를 종료하는 것은 좋지 않습니다 :-)
그럼 제가 대신 하겠습니다.

오류: configmaps 금지: 사용자 " system:serviceaccount :kube- system:default " 나열할 수 없습니다.

먼저 뉴비들을 위한 정보입니다.
Kubernetes에는 다음이 있습니다.

• 계정 - 귀하의 ID와 같은 것. 예: 존
• 역할 - 프로젝트의 일부 그룹이 작업을 수행하도록 허용됩니다. 예: 클러스터 관리자, IT 지원, ...
• 바인딩 - 계정을 역할에 연결합니다. "John in it-support" - 바인딩입니다.

따라서 위의 메시지에서 Tiller는 네임스페이스 "kube-system"에 등록된 계정 "default"로 작동함을 알 수 있습니다. 아마도 당신은 그를 충분한 역할에 묶지 않았을 것입니다.

이제 문제로 돌아갑니다.
추적 방법:

• 틸러에 대한 특정 계정 이 있는지 확인하십시오. 일반적으로 "경운기"와 같은 이름을 갖습니다.
  kubectl [--namespace kube-system] get serviceaccount
  그렇지 않은 경우 생성:
  kubectl [--namespace kube-system] create serviceaccount tiller
• 역할 또는 클러스터 역할이 있는지 확인하십시오(클러스터 역할은 초보자에게 "더 나은" - 네임스페이스 전체 역할과 달리 클러스터 전체에 적용됨 ). 프로덕션이 아닌 경우 높은 권한의 역할 "cluster-admin"을 사용할 수 있습니다.
  kubectl [--namespace kube-system] get clusterrole
  다음을 통해 역할 내용을 확인할 수 있습니다.
  kubectl [--namespace kube-system] get clusterrole cluster-admin -o yaml
• 첫 번째 절의 "tiller" 계정 에 충분하다고 생각되는 clusterrole "cluster-admin"에 대한 바인딩이 있는지 확인합니다.
  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의 설명은 여전히 ​​도움이 됩니다. @bacongobbler와 달리 @m- abramovich

그리고 2개의 나방과 1/2의 설명은 여전히 ​​도움이 됩니다. @bacongobbler와 달리 @m-abramovich

이 문제를 닫은 사람이 열었습니다. 분명히 그들은 문제가 해결되었다고 느꼈습니다.

또한 원래 설명에서는 문제를 종료하지 않고 제공된 역할 기반 액세스 제어 문서에 대한 적절한 링크를 요청했습니다.

마지막으로 @bacongobbler 는 많은 사람들에게 중요한 휴일인 12월 25일에 요청된 정보를 제공하는 데 시간을 들였습니다. @iamaverrick에게 죄송하지만 귀하의 의견은 매우 부적절합니다.

와. 이 스레드에 답변한 기억조차 없습니다... 오랜만입니다.

@marckhouzam 의 가정은 정확합니다. 문제는 크리스마스 날에 열렸습니다. 그날 나는 우연히 가족과 함께 있었지만 OP에서 다음과 같은 빠른 질문을 보았습니다.

아마도 관련되어 Tiller 및 Role-Based Access Control 에 액세스하려고 시도하지만 아직 404가 표시됩니다.

그래서 정확한 링크로 빠른 답변을 하고 크리스마스를 축하하기 위해 다시 돌아가야겠다고 생각했습니다. 다음날 OP가 문제를 종료했으므로 더 이상의 후속 조치가 필요하지 않다고 생각했습니다.

내 의견이 간결하거나 도움이 되지 않는다고 생각하면 정말 속상합니다. 나는 그 문제를 해결하려고 한 것이 아니다. 나는 OP가 휴가철에 스스로 해결책을 찾는 동안 컨텍스트를 제공했을 뿐입니다.

@m-abramovich 및 @snpdev 에게 후속 조치를 취하고 OP 문제에 대한 답변을 제공해 주셔서 감사합니다.

@iamaverrick 문서에 대한 링크를 제공하는 것은 문제에 응답할 때 드문 일이 아닙니다. 이것은 도움이 되지 않는 것이 아니라 커뮤니티로서 우리가 많은 시간을 투자하는 문서에 대한 믿음입니다. 문서가 부적절하면 그 사람은 일반적으로 응답하고 이것은 응답자에게 더 많은 컨텍스트를 제공할 기회를 제공합니다. 또한 문서에 개선이 필요함을 알려줍니다. 사용자로부터 이와 같은 상호 작용이나 피드백이 없으면 문서가 개선되지 않습니다.

장기적으로 더 나은 문서는 관련이 없는 버그나 기능에 대한 문제를 제기하는 것보다 사람들에게 더 많은 도움이 됩니다.

다른 차원에서 @bacongobbler 가 휴가철에 응답하는 것은 매우 인상적입니다. 우리 모두는 최선을 다하는 사람들임을 기억하십시오.

여러분, 진정하세요.
우리는 모두 소프트웨어 개발자이며 인생에서 같은 가치를 공유합니다. 우리는 당신이 상상할 수 있는 것보다 훨씬 더 많은 공통점을 가지고 있습니다. 서로 존중합시다 제발.

@marckhouzam 부적절? 어떤 형태나 형태로든 나는 내 의견으로 누군가를 폄하한 적이 없습니다. 나는 단지 내 관점에서 사실을 진술했을 뿐이다. 이 댓글은 @bacongobbler 에서 직접 언급한 것입니다. 다른 모든 사람들이 2센트를 투자한 것은 아닙니다. 휴일에 링크를 붙여 넣은 @bacongobbler 에게 감사드립니다. 원래 질문에는 문제가 있고 링크가 아닌 지침이 필요하다고 나와 있습니다. 건설적인 비판을 할 수 없다면 이 스레드에 아무 것도 게시하지 마십시오. 우리 모두는 더 나은 사람이 되고 더 나은 정보를 제공하기 위해 노력하는 소프트웨어 개발자입니다.

내 질문에 답을 암시한 다음 @bacongobbler 가 내 답변을 확인하고 @m-abramovich의 훌륭한 댓글이 이어지면서 더 자세한 내용으로 내 답변을 증명하지 못한 것에 대해 사과드립니다.

모든 분들의 도움 및/또는 의견에 진심으로 감사드립니다. 다음에는 더 나은 작업을 할 수 있도록 노력하겠습니다. 약속합니다!

그리고 다시 한 번 이런 일을 일으켜서 죄송합니다(정말 이렇게까지 될 줄은 몰랐습니다...

내 2센트: https://helm.sh/docs/intro/quickstart/ 를 따를 때 RBAC에 대한 언급이 없고 거기에 있는 지침에 따라 틸러가 제대로 설치되지 않습니다. 그런 다음 Google 검색은 여기에서 이 문제로 이어집니다.

아마도 "이 함정에 대해 초보자에게 경고하도록 빠른 시작 가이드를 향상"으로 다시 열 수 있습니까?

전제 조건에 "설치에 적용할 보안 구성 결정"이 있지만 일회용 클러스터에서 시도했을 때 "있는 경우"는 신경 쓰지 않기 때문에 아무것도 할 필요가 없습니다.

내가 뭔가를 해야 한다는 것을 알았더라도 지침에 대한 링크가 없습니다.

내 2센트: https://helm.sh/docs/intro/quickstart/ 를 따를 때 RBAC에 대한 언급이 없고 거기에 있는 지침에 따라 틸러가 제대로 설치되지 않습니다. 그런 다음 Google 검색은 여기에서 이 문제로 이어집니다.

아마도 "이 함정에 대해 초보자에게 경고하도록 빠른 시작 가이드를 향상"으로 다시 열 수 있습니까?

@폴리
패트릭, 나는 이것이 더 이상 관련이 없다고 생각합니다.
Helm v3는 Tiller를 사용하지 않습니다. 그래서 어쩌면 지금은 그 모든 것이 무의미합니다.

@m-abramovich 감사합니다! 귀하의 자세한 안내는 이 문제를 해결하는 데 도움이 되었습니다. 시간을 내어 응답을 작성해 주셔서 대단히 감사합니다.

이 설명은 훌륭합니다! 감사 해요!