Helm: Erreur: aucun nom de version disponible trouvé

La prise en charge de Kubernetes 1.8 n'a été ajoutée que récemment dans helm v2.7.0, donc je ne m'attendrais pas à ce que Helm v2.6.2 fonctionne avec un cluster 1.8. Pouvez-vous essayer la version v2.7.0-rc1 et voir si cela fonctionne? Installer le binaire v2.7.0-rc1 localement et exécuter helm reset && helm init devrait faire l'affaire. Merci! :)

@bacongobbler merci pour un indice, mais n'a pas changé ce match

helm version
Client: &version.Version{SemVer:"v2.7.0", GitCommit:"08c1144f5eb3e3b636d9775617287cc26e53dba4", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.7.0", GitCommit:"08c1144f5eb3e3b636d9775617287cc26e53dba4", GitTreeState:"clean"}

et quand je réessaye:

$ helm install stable/mongodb-replicaset
Error: no available release name found

avec le journal suivant:

[tiller] 2017/10/26 18:11:22 preparing install for
[storage] 2017/10/26 18:11:22 getting release "listless-toucan.v1"
[storage/driver] 2017/10/26 18:11:36 get: failed to get "zealous-panther.v1": Get https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/zealous-panther.v1: dial tcp 10.96.0.1:443: i/o timeout
[tiller] 2017/10/26 18:11:36 info: generated name zealous-panther is taken. Searching again.
[storage] 2017/10/26 18:11:36 getting release "terrifying-serval.v1"
[storage/driver] 2017/10/26 18:11:52 get: failed to get "listless-toucan.v1": Get https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/listless-toucan.v1: dial tcp 10.96.0.1:443: i/o timeout
[tiller] 2017/10/26 18:11:52 info: generated name listless-toucan is taken. Searching again.
[storage] 2017/10/26 18:11:52 getting release "jittery-rat.v1"
[storage/driver] 2017/10/26 18:12:06 get: failed to get "terrifying-serval.v1": Get https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/terrifying-serval.v1: dial tcp 10.96.0.1:443: i/o timeout
[tiller] 2017/10/26 18:12:06 info: generated name terrifying-serval is taken. Searching again.
[storage] 2017/10/26 18:12:06 getting release "wayfaring-dachshund.v1"
[storage/driver] 2017/10/26 18:12:22 get: failed to get "jittery-rat.v1": Get https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/jittery-rat.v1: dial tcp 10.96.0.1:443: i/o timeout
[tiller] 2017/10/26 18:12:22 info: generated name jittery-rat is taken. Searching again.
[storage] 2017/10/26 18:12:22 getting release "lucky-arachnid.v1"
[storage/driver] 2017/10/26 18:12:36 get: failed to get "wayfaring-dachshund.v1": Get https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/wayfaring-dachshund.v1: dial tcp 10.96.0.1:443: i/o timeout
[tiller] 2017/10/26 18:12:36 info: generated name wayfaring-dachshund is taken. Searching again.
[storage] 2017/10/26 18:12:36 getting release "gangly-lambkin.v1"
[storage/driver] 2017/10/26 18:12:52 get: failed to get "lucky-arachnid.v1": Get https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/lucky-arachnid.v1: dial tcp 10.96.0.1:443: i/o timeout
[tiller] 2017/10/26 18:12:52 info: generated name lucky-arachnid is taken. Searching again.
[storage] 2017/10/26 18:12:52 getting release "boiling-kudu.v1"
[storage/driver] 2017/10/26 18:13:06 get: failed to get "gangly-lambkin.v1": Get https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/gangly-lambkin.v1: dial tcp 10.96.0.1:443: i/o timeout
[tiller] 2017/10/26 18:13:06 info: generated name gangly-lambkin is taken. Searching again.
[storage] 2017/10/26 18:13:06 getting release "quoting-sloth.v1"
[storage/driver] 2017/10/26 18:13:22 get: failed to get "boiling-kudu.v1": Get https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/boiling-kudu.v1: dial tcp 10.96.0.1:443: i/o timeout
[tiller] 2017/10/26 18:13:22 info: generated name boiling-kudu is taken. Searching again.
[storage] 2017/10/26 18:13:22 getting release "nordic-rabbit.v1"
[storage/driver] 2017/10/26 18:13:36 get: failed to get "quoting-sloth.v1": Get https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/quoting-sloth.v1: dial tcp 10.96.0.1:443: i/o timeout
[tiller] 2017/10/26 18:13:36 info: generated name quoting-sloth is taken. Searching again.
[tiller] 2017/10/26 18:13:36 warning: No available release names found after 5 tries
[tiller] 2017/10/26 18:13:36 failed install prepare step: no available release name found
[storage/driver] 2017/10/26 18:13:52 get: failed to get "nordic-rabbit.v1": Get https://10.96.0.1:443/api/v1/namespaces/kube-system/configmaps/nordic-rabbit.v1: dial tcp 10.96.0.1:443: i/o timeout
[tiller] 2017/10/26 18:13:52 info: generated name nordic-rabbit is taken. Searching again.
[tiller] 2017/10/26 18:13:52 warning: No available release names found after 5 tries
[tiller] 2017/10/26 18:13:52 failed install prepare step: no available release name found

d'accord...
J'ai remplacé la flanelle par calicot et ça marche

Selon https://github.com/kubernetes/helm/issues/2224#issuecomment -356344286, les commandes suivantes ont 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"}}}}'

après de nombreuses approches, enfin, cela a fonctionné pour moi, merci!

kubectl create serviceaccount --namespace kube-system barre franche
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"}}}}'

Les 3 lignes ci-dessus ont également résolu ce problème pour moi.
client kubectl: 1.9.6
serveur kubectl: 1.8.7
client de barre: 2.8.2
serveur de barre: 2.8.2

Le problème apparaît et la solution mentionnée ne fonctionne pas pour:

Kube Client Version: 1.10.1
Kube Server Version: 1.10.1
Helm Client: "v2.9.0"
Helm Server: "v2.9.0"

Aussi en exécutant helm list avec minikue activé, j'ai eu une erreur de
Error: Get http://localhost:8080/api/v1/namespaces/kube-system/configmaps?labelSelector=OWNER%!D(MISSING)TILLER: dial tcp 127.0.0.1:8080: connect: connection refused

@viane essayez helm init --service-account default ; c'est un autre ticket mais cela entraîne la même erreur générique.

@viane Essayez les étapes suivantes. (Vous aurez probablement besoin de kubectl delete le service de tiller et le déploiement.)

$ 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

Cela a résolu le problème pour moi.

helm reset && helm init n'a pas fonctionné pour moi, ni les solutions RBAC ci-dessus.
Enfin, il a fonctionné à nouveau en supprimant Tiller, puis en utilisant la suggestion de https://github.com/kubernetes/helm/issues/3055#issuecomment -385296641:

kubectl delete deployment tiller-deploy --namespace kube-system
helm init --upgrade --service-account default

J'ai rencontré le même problème. puis j'ai essayé de suivre

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

avec le
kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'
J'ai reçu le message "Erreur du serveur (BadRequest): caractère invalide recherchant le début de la chaîne de clé d'objet"

puis j'ai essayé de suivre les commandes

$ 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

J'ai eu le message:
failed: clusterroles.rbac.authorization.k8s.io .... [clusterroles.rbac.authorization.k8s.io "cluster-admin" not found]

Aidez-moi, s'il vous plaît!...
Voici mes informations:
version de barre

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

version kubectl

Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.0", GitCommit:"925c127ec6b946659ad0fd596fa959be43f0cc05", GitTreeState:"clean", BuildDate:"2017-12-15T21:07:38Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"windows/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.6", GitCommit:"9f8ebd171479bec0ada837d7ee641dec2f8c6dd1", GitTreeState:"clean", BuildDate:"2018-03-21T15:13:31Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

version minikube
minikube version: v0.25.0

L'étrange est que j'utilisais Helm pour installer stable / nginx-ingress le 9 mai et avec succès, puis j'ai supprimé Kubernetes (pour la pratique), puis réinstaller Kubernetes aujourd'hui et installer à nouveau stable / nginx-ingress .... Erreur.

Merci beaucoup pour votre soutien à l'avance

@ nguyenhuuloc304 J'ai rencontré le même problème. J'ai dû faire le cluster-admin ClusterRole.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: null
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: cluster-admin
rules:
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - '*'
- nonResourceURLs:
  - '*'
  verbs:
  - '*'

Je pense qu'il est vraiment important d'ajouter ceci quelque part dans le guide. AKS sur Azure ne fournit pas le rôle d'administrateur de cluster par défaut et un utilisateur doit le créer.
https://github.com/jenkins-x/jx/issues/485#issuecomment -376804810
c'était aussi le cas sur ACS comme on peut le voir ici: https://github.com/Azure/acs-engine/issues/1892#issuecomment -353960778

Cela a fonctionné pour moi alors que j'essayais de gérer l'installation de redis:
kubectl create serviceaccount --namespace kube-system barre franche
kubectl create clusterrolebinding tiller-cluster-rule --clusterrole = cluster-admin --serviceaccount = kube- system: tiller
helm init - tiller de compte de service --upgrade
repo de mise à jour de helm. # C'était la dernière pièce du puzzle
helm install stable / redis - version 3.3.5

Pareil ici,
client kube: v1.10.4
serveur kube: v1.9.6
helm client / erver v2.9.1

# helm install stable/prometheus --namespace=monitoring --set rbac.create="true"
Error: no available release name found

# helm search | grep prometheus
coreos/grafana                          0.0.35                                          Grafana instance for kube-prometheus
coreos/kube-prometheus                  0.0.82                                          Manifests, dashboards, and alerting rules for e...
coreos/prometheus                       0.0.43                                          Prometheus instance created by the CoreOS Prome...
coreos/prometheus-operator              0.0.26          0.20.0                          Provides easy monitoring definitions for Kubern...
stable/prometheus                       6.7.2           2.2.1                           Prometheus is a monitoring system and time seri...

Je viens de lancer cette ligne et de travailler, merci de l'avoir postée! : kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller

#kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
clusterrolebinding.rbac.authorization.k8s.io "tiller-cluster-rule" created
[root@ip-172-31-90-223 charts]# helm install stable/prometheus --namespace=monitoring --set rbac.create="true"
NAME:   ungaged-sloth
LAST DEPLOYED: Thu Jun 14 23:52:31 2018
NAMESPACE: monitoring
STATUS: DEPLOYED

Pourquoi est-ce que Error: no available release name found autant de temps à apparaître? Honnêtement, il me faut 5 minutes pour recevoir le message d'erreur, donc les 40000 choses que je dois essayer pour le faire fonctionner prennent 5m * 40000

Pour moi, pas une seule solution n'a fonctionné. Cependant, j'ai réinstallé minikube ainsi que la barre franche et j'ai d'abord effectué cette étape:

Si le contrôle d'accès en fonction du rôle (RBAC) est activé sur votre cluster, vous souhaiterez peut-être configurer un compte de service et des règles avant de continuer.

Ceci est en effet mentionné dans la documentation mais c'est un peu déroutant car il apparaît après ce paragraphe:

Si vous utilisez Helm sur un cluster que vous contrôlez complètement, comme minikube ou un cluster sur un réseau privé dans lequel le partage n'est pas un problème, l'installation par défaut - qui n'applique aucune configuration de sécurité - convient, et c'est certainement la plus simple. Pour installer Helm sans étapes de sécurité supplémentaires, installez Helm, puis initialisez Helm.

Les instructions ci-dessous ont également résolu mon problème pour les versions helm v2.11.0 et kube 1.12.1.

$ kubectl create serviceaccount --namespace kube-system tiller
$ kubectl create clusterrolebinding tiller-cluster-rule --clusterrole = cluster-admin --serviceaccount = kube- system: tiller
$ helm init - tiller de compte de service

sudo iptables -P FORWARD ACCEPTER

La commande ci-dessus est tout ce que j'avais à faire pour me débarrasser de l'erreur .. aucune des autres solutions ne semblait fonctionner pour moi.

Salutations
Ranga

De la même manière mais avec terraform.

  resource "kubernetes_service_account" "tiller" {
    metadata {
      name = "tiller"
      namespace = "kube-system"
    }
  }

  resource "kubernetes_cluster_role_binding" "tiller-cluster-rule" {

    metadata {
      name = "tiller-cluster-rule"
    }

    role_ref {
      kind = "ClusterRole"
      name = "cluster-admin"
      api_group = "rbac.authorization.k8s.io"
    }

    subject {
      kind = "ServiceAccount"
      namespace = "kube-system"
      name = "tiller"
      api_group = ""
    }

    provisioner "local-exec" {
      command = "helm init --service-account tiller"
    }
  }

Avez-vous essayé ceci
sudo iptables -P FORWARD ACCEPTER
Salutations
Ranga

J'ai essayé toutes les options ci-dessus en vain et celle suggérée par rangapv a fonctionné pour moi. Merci.

Rien ci-dessus n'a fonctionné.

Aucune des solutions mentionnées ci-dessus ne fonctionne.

Version de $ kubectl
Version du client: version.Info {Major: "1", Minor: "12", GitVersion: "v1.12.4", GitCommit: "f49fa022dbe63faafd0da106ef7e05a29721d3f1", GitTreeState: "clean", BuildDate: "2018-12-14T07: 10: 00Z ", GoVersion:" go1.10.4 ", Compilateur:" gc ", Plate-forme:" darwin / amd64 "}
Version du serveur: version.Info {Major: "1", Minor: "13", GitVersion: "v1.13.2", GitCommit: "cff46ab41ff0bb44d8584413b598ad8360ec1def", GitTreeState: "clean", BuildDate: "2019-01-10T23: 28: 14Z ", GoVersion:" go1.11.4 ", Compilateur:" gc ", Plate-forme:" linux / amd64 "}

$ version helm
Client: & version.Version {SemVer: "v2.12.3", GitCommit: "eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState: "clean"}
Serveur: & version.Version {SemVer: "v2.12.3", GitCommit: "eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState: "clean"}

$ kubectl create serviceaccount --namespace kube-system tiller
Erreur du serveur (Déjàexiste): les comptes de service "tiller" existent déjà
Ravis-MacBook-Pro-2: .kube ravi $ kubectl create clusterrolebinding tiller-cluster-rule --clusterrole = cluster-admin --serviceaccount = kube- system: tiller
Erreur du serveur (alreadyExists): clusterrolebindings.rbac.authorization.k8s.io "tiller-cluster-rule" existe déjà
Ravis-MacBook-Pro-2: .kube ravi $ helm init --service-account tiller --upgrade
$ HELM_HOME a été configuré dans /Users/ravi/.helm.

Tiller (le composant côté serveur Helm) a été mis à niveau vers la version actuelle.
Bonne barre!
Ravis-MacBook-Pro-2: Repo de mise à jour .kube ravi $ helm
La commande "update" est obsolète, utilisez "helm repo update"

Accrochez-vous pendant que nous récupérons les dernières informations de vos référentiels de graphiques ...
... Ignorer le référentiel de cartes local
... Obtention réussie d'une mise à jour du référentiel de graphiques "stable"
Mise à jour terminée. ⎈ Bonne barre! ⎈

Ravis-MacBook-Pro-2: .kube ravi $ helm installer stable / redis
Erreur: aucun nom de version disponible trouvé

Hey,

une solution plus sécurisée sans autorisation d'administrateur de rôle de cluster:

1. Créez le rôle suivant dans le $ {TILLER_NAMESPACE}:

TILLER_NAMESPACE='your tiller namespace'
cat <<EOF | kubectl create -n ${TILLER_NAMESPACE} -f -
- kind: Role
  apiVersion: v1
  metadata:
    name: tiller
  rules:
  - apiGroups:
    - ""
    resources:
    - configmaps
    verbs:
    - create
    - get
    - list
    - update
    - delete
  - apiGroups:
    - ""
    resources:
    - namespaces
    verbs:
    - get
EOF

1. Créer un compte de service, lier le rôle local et déployer le correctif

kubectl create serviceaccount --namespace ${TILLER_NAMESPACE} tiller
kubectl create rolebinding tiller-rule --role=tiller --serviceaccount=${TILLER_NAMESPACE}:tiller
kubectl patch deploy --namespace ${TILLER_NAMESPACE} tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'

Cela devrait corriger l'erreur ci-dessus.

Si vous souhaitez déployer des graphiques à barre franche pour projeter, vous devez accorder des autorisations de modification de barre franche:

kubectl create rolebinding tiller-edit-rights -n ${YOUR-PROJECT_NAMESPACE} --clusterrole=edit --serviceaccount=${TILLER_NAMESPACE}:tiller

Aucune des solutions ci-dessus n'a fonctionné pour moi, mais les instructions du lien suivant ont fonctionné.

https://scriptcrunch.com/helm-error-no-available-release/

Aucune des solutions ci-dessus n'a fonctionné pour moi, mais les instructions du lien suivant ont fonctionné.

https://scriptcrunch.com/helm-error-no-available-release/

Merci mon pote, ça marche