Helm: Erreur: aucun nom de version disponible trouvé

Question

J'ai un couple d'erreurs avec la Tête que je ne peux pas trouver des 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)

Plus de détails sur les deux erreurs sont dans le bloc de code ci-dessous.

J'ai installé un Kubernetes cluster sur Ubuntu 16.04. J'ai un Master (K8SMST01) et les deux nœuds (K8SN01 & K8SN02).

Il a été créé à l'aide de kubeadm à l'aide de Tisser le réseau de 1.6+.

Tout semble fonctionner parfaitement bien autant que les Déploiements, les Services, les Cosses, etc... DNS semble bien fonctionner, sens gousses peuvent accéder à des services en utilisant le nom DNS (myservicename.valeur par défaut).

À l'aide de "barre de créer" et "barre de recherche" travail, mais l'interaction avec la barre de déploiement ne semblent pas fonctionner. Tiller est installé et en cours d'exécution en fonction de la Barre d'installer la documentation.

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 le fonctionnement des gousses:

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

Answer 1

Solution donnée par kujenga à partir du problème github, cela a fonctionné sans aucun autre changement.

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

Answer 2

Je pense que c'est un RBAC question. Il semble que la barre n'est pas prêt pour 1.6.1 du RBAC.

Il y a une question ouverte sur la Barre de Github.

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

"Lors de l'installation d'un cluster pour la première fois à l'aide de kubeadm v1.6.1, l'initialisation par défaut à la création de RBAC accès contrôlé, qui mess avec les autorisations nécessaires par Talle de faire des installations, analyse des composants installés, et ainsi de suite. barre init fonctionne sans problème, mais en tête de liste, heaume installer, et ainsi de suite, tous ne fonctionnent pas, citant certains cas de disparition d'une autorisation ou d'une autre."

Une solution temporaire a été de suggérer:

"Nous "désactiver" RBAC l'aide de la commande kubectl créer clusterrolebinding permissive de liaison --clusterrole=cluster-admin --user=admin --user=kubelet --groupe=système:serviceaccounts;"

Mais je ne peux pas parler pour la validité. La bonne nouvelle, c'est que c'est un problème connu et le travail qui est fait pour le résoudre. Espérons que cette aide.

Answer 3

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

La barre n'est pas de faire un compte de service lorsque vous "barre init" et la valeur par défaut n'a pas les autorisations de lecture à partir de la configmaps - donc, il ne sera pas être en mesure d'exécuter une vérification pour voir si le nom de déploiement qu'il veut utiliser est unique.

Cela m'a passé ça:

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

Mais c'est donner le compte par défaut des tonnes de puissance, j'ai juste fait ce que je pouvais faire mon travail. La barre doit ajouter de la création de leur propre compte de service à la tête de l'init" du code.

Answer 4

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

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

Answer 5

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

helm init --service-account default

Cela a fonctionné pour moi lorsque les commandes RBAC (serviceaccount) ne l'ont pas fait.