web-dev-qa-db-fra.com

Helm: Erreur: aucun nom de version disponible trouvé

Je reçois quelques erreurs avec Helm pour lesquelles je ne trouve pas d’explications ailleurs. Les deux erreurs sont ci-dessous.

Error: no available release name found
Error: the server does not allow access to the requested resource (get configmaps)

Vous trouverez plus de détails sur les deux erreurs dans le bloc de code ci-dessous.

J'ai installé un cluster Kubernetes sur Ubuntu 16.04. J'ai un maître (K8SMST01) et deux nœuds (K8SN01 et K8SN02).

Cela a été créé en utilisant kubeadm en utilisant le réseau Weave pour 1.6+.

Tout semble fonctionner parfaitement en ce qui concerne les déploiements, les services, les pods, etc. Le DNS semble fonctionner correctement, ce qui signifie que les pods peuvent accéder aux services en utilisant le nom DNS (myservicename.default).

L'utilisation de "helm create" et de "Helm search" fonctionne, mais interagir avec le déploiement du motoculteur ne semble pas fonctionner. Le motoculteur est installé et fonctionne conformément à la documentation d'installation de Helm.

root@K8SMST01:/home/blah/charts# helm version

Client: &version.Version{SemVer:"v2.3.0", 
GitCommit:"d83c245fc324117885ed83afc90ac74afed271b4", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.3.0", GitCommit:"d83c245fc324117885ed83afc90ac74afed271b4", GitTreeState:"clean"}

root@K8SMST01:/home/blah/charts# helm install ./mychart

Error: no available release name found

root@K8SMST01:/home/blah/charts# helm ls

Error: the server does not allow access to the requested resource (get configmaps)

Voici les pods en cours d'exécution:

root@K8SMST01:/home/blah/charts# kubectl get pods -n kube-system -o wide
NAME                                      READY     STATUS    RESTARTS   AGE       IP             NODE
etcd-k8smst01                             1/1       Running   4          1d        10.139.75.19   k8smst01
kube-apiserver-k8smst01                   1/1       Running   3          19h       10.139.75.19   k8smst01
kube-controller-manager-k8smst01          1/1       Running   2          1d        10.139.75.19   k8smst01
kube-dns-3913472980-dm661                 3/3       Running   6          1d        10.32.0.2      k8smst01
kube-proxy-56nzd                          1/1       Running   2          1d        10.139.75.19   k8smst01
kube-proxy-7hflb                          1/1       Running   1          1d        10.139.75.20   k8sn01
kube-proxy-nbc4c                          1/1       Running   1          1d        10.139.75.21   k8sn02
kube-scheduler-k8smst01                   1/1       Running   3          1d        10.139.75.19   k8smst01
tiller-deploy-1172528075-x3d82            1/1       Running   0          22m       10.44.0.3      k8sn01
weave-net-45335                           2/2       Running   2          1d        10.139.75.21   k8sn02
weave-net-7j45p                           2/2       Running   2          1d        10.139.75.20   k8sn01
weave-net-h279l                           2/2       Running   5          1d        10.139.75.19   k8smst01
kuberneteskubernetes-helm
32
cjp

Je pense que c'est un problème RBAC. Il semble que la barre ne soit pas prête pour le RBAC 1.6.1.

Il y a un problème en suspens dans Helm's Github.

https://github.com/kubernetes/helm/issues/2224

"Lors de la première installation d’un cluster à l’aide de kubeadm v1.6.1, l’initialisation définit par défaut la configuration de l’accès contrôlé par RBAC, qui dérange les autorisations requises par Tiller pour effectuer des installations, rechercher les composants installés, etc." helm init fonctionne sans problème , mais la liste de barre, l’installation de barre, etc. ne fonctionnent pas, citant une permission manquante ou une autre. "

Un travail temporaire a été suggéré:

"Nous" désactivons "RBAC à l'aide de la commande kubectl créer clusterrolebinding permissive-binding --clusterrole = admin-cluster - user = admin --user - kubelet --group = system: serviceaccounts;"

Mais je ne peux pas parler pour sa validité. La bonne nouvelle est qu’il s’agit d’un problème connu et que des travaux sont en cours pour le résoudre. J'espère que cela t'aides.

24
Simon I

La solution donnée par kujenga du numéro de GitHub a fonctionné sans autre modification:

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"}}}}'
56
karthik101

J'ai eu le même problème avec la configuration de kubeadm sur CentOS 7.

Helm ne crée pas de compte de service lorsque vous "pilotez init" et que le compte par défaut ne dispose pas des autorisations nécessaires pour lire les configmaps - il ne pourra donc pas exécuter de contrôle pour voir si le nom du déploiement qu'il souhaite utiliser. l'utilisation est unique.

Cela m'a permis de le dépasser:

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

Mais cela revient à donner beaucoup d’énergie au compte par défaut. Je l’ai fait pour que je puisse continuer à travailler. Helm doit ajouter la création de son propre compte de service au code "helm init".

11
MrMackey

Tous les addons des kubernetes utilisent le compte de service "par défaut". Helm fonctionne également avec un compte de service "par défaut". Vous devez lui donner des autorisations. Attribuez-lui des liaisons de rôle.

Pour les autorisations en lecture seule:

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

Pour un accès administrateur: par exemple: pour installer des packages.

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

Vous pouvez également installer le serveur de barre dans un espace de noms différent en utilisant la commande ci-dessous.

  1. Commencez par créer le nom
  2. Créer le compte de service pour l'espace de noms
  3. installez la barre dans cet espace de noms respectif à l'aide de la commande ci-dessous.

helm init --tiller-namespace test-namespace

3
suresh Palemoni

Cette solution a fonctionné pour moi: https://github.com/helm/helm/issues/3055#issuecomment-397296485

$ kubectl create serviceaccount --namespace kube-system tiller

$ kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller

$ helm init --service-account tiller --upgrade

$ helm update repo

$ helm install stable/redis --version 3.3.5

Mais après cela, quelque chose a changé. Je dois ajouter - insecure-skip-tls-verify = true indicateur à mes commandes kubectl! Je ne sais pas comment résoudre ce problème, sachant que j'interagis avec un cluster de conteneurs gcloud.

3
Omar L.

Pour https://github.com/kubernetes/helm/issues/2224#issuecomment-356344286 , les commandes suivantes ont également résolu l'erreur:

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"}}}}'
2
Vikram Hosakote

Per https://github.com/kubernetes/helm/issues/3055

helm init --service-account default

Cela a fonctionné pour moi lorsque les commandes RBAC (serviceaccount) ne fonctionnaient pas.

2
robrich

C'est un problème RBAC. Vous devez avoir un compte de service avec un rôle administrateur de cluster. Et vous devez passer ce compte de service lors de l'initialisation de HELM.

Par exemple, si vous avez créé un compte de service avec le nom tiller, votre commande heml ressemblerait à ce qui suit.

helm init --service-account=tiller

J'ai suivi ce blog pour résoudre ce problème. https://scriptcrunch.com/helm-error-no-available-release/

0
Bibin Wilson