Helm 2.6.2 został zainstalowany w klastrze Kubernetes 8. helm initdziałało dobrze. ale kiedy uruchomię helm listto podając ten błąd.

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

Jak naprawić ten komunikat o błędzie RABC?

Gdy te polecenia:

kubectl create serviceaccount --namespace kube-system tiller
kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'      
helm init --service-account tiller --upgrade

zostały uruchomione, problem został rozwiązany.

Bardziej bezpieczna odpowiedź

Zaakceptowana odpowiedź daje pełny dostęp administracyjny do Helm, co nie jest najlepszym rozwiązaniem pod względem bezpieczeństwa. Przy odrobinie pracy możemy ograniczyć dostęp Helma do określonej przestrzeni nazw. Więcej szczegółów w dokumentacji Helm .

$ kubectl create namespace tiller-world
namespace "tiller-world" created
$ kubectl create serviceaccount tiller --namespace tiller-world
serviceaccount "tiller" created

Zdefiniuj rolę, która pozwoli Tillerowi zarządzać wszystkimi zasobami tiller-worldw role-tiller.yaml:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: tiller-manager
  namespace: tiller-world
rules:
- apiGroups: ["", "batch", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]

Następnie uruchomić:

$ kubectl create -f role-tiller.yaml
role "tiller-manager" created

W rolebinding-tiller.yaml,

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: tiller-binding
  namespace: tiller-world
subjects:
- kind: ServiceAccount
  name: tiller
  namespace: tiller-world
roleRef:
  kind: Role
  name: tiller-manager
  apiGroup: rbac.authorization.k8s.io

Następnie uruchomić:

$ kubectl create -f rolebinding-tiller.yaml
rolebinding "tiller-binding" created

Następnie możesz uruchomić helm initinstalację Tillera w tiller-worldprzestrzeni nazw.

$ helm init --service-account tiller --tiller-namespace tiller-world

Teraz poprzedzaj wszystkie polecenia zmiennymi środowiskowymi --tiller-namespace tiller-worldlub ustaw je TILLER_NAMESPACE=tiller-worldw nich.

Więcej odpowiedzi na przyszłość

Przestań używać Tillera. Helm 3 całkowicie eliminuje potrzebę używania Rumpla. Jeśli używasz Helm 2, możesz użyć helm templatedo wygenerowania yaml z wykresu Helm, a następnie uruchomić, kubectl applyaby zastosować obiekty do klastra Kubernetes.

helm template --name foo --namespace bar --output-dir ./output ./chart-template
kubectl apply --namespace bar --recursive --filename ./output -o yaml

Helm działa z „domyślnym” kontem usługi. Powinieneś nadać mu uprawnienia.

Uprawnienia tylko do odczytu:

kubectl create rolebinding default-view --clusterrole=view --serviceaccount=kube-system:default --namespace=kube-system

Dostęp administratora: Np .: aby zainstalować pakiety.

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

Domyślne konto usługi nie ma uprawnień interfejsu API. Helm prawdopodobnie musi mieć przypisane konto usługi, a to konto usługi ma uprawnienia interfejsu API. Zobacz dokumentację RBAC dotyczącą nadawania uprawnień do kont usług: https://kubernetes.io/docs/admin/authorization/rbac/#service-account-permissions

apiVersion: v1
kind: ServiceAccount
metadata:
  name: tiller
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: tiller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: tiller
    namespace: kube-system

kubectl apply -f your-config-file-name.yaml

a następnie zaktualizuj instalację Helm, aby korzystać z serviceAccount:

helm init --service-account tiller --upgrade

Otrzymałem ten błąd podczas próby zainstalowania tillera w trybie offline, myślałem, że konto usługi „tiller” nie ma wystarczających uprawnień, ale okazuje się, że polityka sieciowa blokuje komunikację między rumpelem a serwerem api.

Rozwiązaniem było stworzenie polityki sieciowej dla rumpla, która umożliwi całą komunikację wyjściową sterownicy

export TILLER_NAMESPACE=<your-tiller-namespace>rozwiązał to dla mnie, jeśli <your-tiller-namespace>nie kube-system. Wskazuje to klientowi Helm na prawą przestrzeń nazw Tiller.

Jeśli używasz klastra EKS z AWS i masz do czynienia z niedozwolonym problemem ( np . forbidden: User ... cannot list resource "jobs" in API group "batch" in the namespace "default"To zadziałało dla mnie:

Rozwiązanie:

1. Upewnij się, że skonfigurowałeś AWS
2. Upewnij się, że skonfigurowany użytkownik ma uprawnienia dostępu do klastra.