Helm: Fehler: Kein verfügbarer Versionsname gefunden

Die Unterstützung für Kubernetes 1.8 wurde erst kürzlich in helm v2.7.0 hinzugefügt, sodass ich nicht erwarten würde, dass Helm v2.6.2 mit einem 1.8-Cluster funktioniert. Können Sie die Version 2.7.0-rc1 ausprobieren und sehen, ob das funktioniert? Die lokale Installation der Binärdatei v2.7.0-rc1 und die Ausführung von helm reset && helm init sollten den Trick tun. Vielen Dank! :) :)

@bacongobbler danke für einen Hinweis, hat aber das Match nicht geändert

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

und wenn ich es nochmal versuche:

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

mit folgendem Protokoll:

[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

OK...
Ich habe Flanell durch Kaliko ersetzt und es läuft

Per https://github.com/kubernetes/helm/issues/2224#issuecomment -356344286 haben die folgenden Befehle den Fehler für mich behoben:

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

Nach vielen Ansätzen hat das endlich bei mir funktioniert, danke!

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

Die obigen 3 Zeilen haben dies auch für mich gelöst.
kubectl client: 1.9.6
kubectl server: 1.8.7
Steuerkunde: 2.8.2
Steuerserver: 2.8.2

Das Problem tritt auf und die erwähnte Lösung funktioniert nicht für:

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

Auch durch Ausführen von helm list mit aktiviertem Minikue wurde der Fehler angezeigt
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 try helm init --service-account default ; Es ist ein anderes Ticket, aber es führt zu demselben generischen Fehler.

@viane Versuche die folgenden Schritte. (Sie müssen wahrscheinlich kubectl delete den Pinnenservice und die Bereitstellung durchführen.)

$ 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

Das hat es für mich behoben.

helm reset && helm init hat bei mir nicht funktioniert, und die oben genannten RBAC-Lösungen haben auch nicht funktioniert.
Schließlich funktionierte es wieder, indem Tiller gelöscht und dann der Vorschlag in https://github.com/kubernetes/helm/issues/3055#issuecomment -385296641 verwendet wurde:

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

Ich bin auf das gleiche Problem gestoßen. dann habe ich versucht zu folgen

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

mit dem
kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'
Ich habe die Meldung "Fehler vom Server (BadRequest): Ungültige Zeichen suchen nach dem Beginn der Objektschlüsselzeichenfolge".

und dann habe ich versucht, Befehle zu befolgen

$ 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

Ich habe es verstanden:
failed: clusterroles.rbac.authorization.k8s.io .... [clusterroles.rbac.authorization.k8s.io "cluster-admin" not found]

Bitte hilf mir!...
Unten sind meine Informationen:
Steuerversion

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

kubectl version

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

Minikube-Version
minikube version: v0.25.0

Das Seltsame ist, dass ich am 9. Mai Helm verwendet habe, um Stable / Nginx-Ingress zu installieren, und dann erfolgreich Kubernetes (zum Üben) gelöscht, Kubernetes heute erneut installiert und Stable / Nginx-Ingress erneut installiert habe Error.

Vielen Dank für Ihre Unterstützung im Voraus

@ nguyenhuuloc304 Ich bin auf das gleiche Problem cluster-admin ClusterRole machen.

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:
  - '*'

Ich denke, es ist wirklich wichtig, dies irgendwo in der Anleitung hinzuzufügen. AKS on Azure bietet keine Standard-Cluster-Administratorrolle und muss von einem Benutzer erstellt werden.
https://github.com/jenkins-x/jx/issues/485#issuecomment -376804810
Dies war auch bei ACS der Fall, wie wir hier sehen können: https://github.com/Azure/acs-engine/issues/1892#issuecomment -353960778

Dies funktionierte für mich, als ich versuchte, redis zu installieren:
kubectl create serviceaccount --namespace kube-system pinne
kubectl create clusterrolebinding tiller-cluster-rule --clusterrole = cluster-admin --serviceaccount = kube- system: tiller
helm init --service-account pinne --upgrade
Helm Update Repo. # Dies war das letzte Puzzleteil
helm installstable / redis --version 3.3.5

Hier gilt das gleiche,
kube client: v1.10.4
kube server: 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...

Gerade diese Zeile gelaufen und funktioniert, danke für das Posten! : 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

Warum dauert es so lange, bis Error: no available release name found angezeigt wird? Ehrlich gesagt dauert es 5 Minuten, bis ich die Fehlermeldung erhalte. Die 40.000 Dinge, die ich versuchen muss, um sie zum Laufen zu bringen, dauern 5 m * 40.000

Für mich hat keine einzige Lösung funktioniert. Ich habe jedoch sowohl Minikube als auch Pinne neu installiert und diesen Schritt zuerst ausgeführt:

Wenn in Ihrem Cluster die rollenbasierte Zugriffssteuerung (RBAC) aktiviert ist, möchten Sie möglicherweise ein Dienstkonto und Regeln konfigurieren, bevor Sie fortfahren.

Dies wird zwar in der Dokumentation erwähnt, ist jedoch etwas verwirrend, da es nach diesem Absatz erscheint:

Wenn Sie Helm in einem Cluster verwenden, den Sie vollständig steuern, wie z. B. Minikube oder einem Cluster in einem privaten Netzwerk, in dem die Freigabe keine Rolle spielt, ist die Standardinstallation - für die keine Sicherheitskonfiguration angewendet wird - in Ordnung und definitiv die einfachste. Um Helm ohne zusätzliche Sicherheitsschritte zu installieren, installieren Sie Helm und initialisieren Sie Helm.

Die folgenden Anweisungen haben mein Problem auch für die Versionen helm v2.11.0 und kube 1.12.1 gelöst.

$ kubectl create serviceaccount --namespace kube-system pinne
$ kubectl create clusterrolebinding tiller-cluster-rule --clusterrole = cluster-admin --serviceaccount = kube- system: tiller
$ helm init - Service-Account-Pinne

sudo iptables -P FORWARD ACCEPT

Der obige Befehl ist alles, was ich tun musste, um den Fehler zu beseitigen. Keine der anderen Lösungen schien für mich zu funktionieren.

Grüße
Ranga

Der gleiche Weg, aber mit 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"
    }
  }

Hast du das versucht?
sudo iptables -P FORWARD ACCEPT
Grüße
Ranga

Ich habe alle oben genannten Optionen vergeblich ausprobiert und die von Rangapv vorgeschlagene Option hat für mich funktioniert. Vielen Dank.

Nichts oben hat funktioniert.

Keine der oben genannten Lösungen funktioniert.

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

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

$ kubectl create serviceaccount --namespace kube-system pinne
Fehler vom Server (AlreadyExists): Servicekonten "Pinne" sind bereits vorhanden
Ravis-MacBook-Pro-2: .kube ravi $ kubectl erstellt Clusterrollenbindung Pinnen-Cluster-Regel --clusterrole = Cluster-Administrator --serviceaccount = Kube- System: Pinne
Fehler vom Server (AlreadyExists): clusterrolebindings.rbac.authorization.k8s.io "Pinnen-Cluster-Regel" existiert bereits
Ravis-MacBook-Pro-2: .kube ravi $ helm init - Service-Account-Pinne - Upgrade
$ HELM_HOME wurde unter /Users/ravi/.helm konfiguriert.

Tiller (die serverseitige Helm-Komponente) wurde auf die aktuelle Version aktualisiert.
Viel Spaß beim Helming!
Ravis-MacBook-Pro-2: .kube ravi $ helm Update Repo
Befehl "update" ist veraltet, benutze 'helm repo update'

Bleib dran, während wir das Neueste aus deinen Chart-Repositories holen ...
... Überspringen Sie das lokale Karten-Repository
... hat erfolgreich ein Update aus dem "stabilen" Chart-Repository erhalten
Aktualisierung abgeschlossen. ⎈ Happy Helming! ⎈

Ravis-MacBook-Pro-2: .kube ravi $ helm installiere stabil / redis
Fehler: Kein verfügbarer Versionsname gefunden

Hallo,

Eine sicherere Lösung ohne Administratorberechtigung für Clusterrollen:

1. Erstellen Sie die folgende Rolle im $ {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. Erstellen Sie ein Dienstkonto, binden Sie die lokale Rolle und stellen Sie die Patch-Bereitstellung bereit

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

Dies sollte den obigen Fehler beheben.

Wenn Sie Pinnen-Diagramme für Projekte bereitstellen möchten, müssen Sie Pinnen-Bearbeitungsberechtigungen erteilen:

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

Keine der oben genannten Lösungen hat bei mir funktioniert, aber die Anweisungen unter dem folgenden Link haben funktioniert.

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

Keine der oben genannten Lösungen hat bei mir funktioniert, aber die Anweisungen unter dem folgenden Link haben funktioniert.

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

Danke Kumpel, es funktioniert