Das vollständige Entfernen der Freigabe von Helm über helm delete release funktioniert, ist jedoch keine praktikable Lösung.

Warum kann Helm nicht einfach überschreiben, was gerade installiert ist? Leben wir nicht mit Kubernetes in einer deklarativen Welt?

Ich habe gerade das Gleiche ... ziemlich neu für mich, es scheint ein neues Problem zu sein. Durch Löschen der Ressource wird das Problem behoben.
v2.7.2 mit Kubernetes 1.7.7.
hübsch es hat vorher geklappt ...

Ich hatte dieses Problem - es lag an einem PersistentVolume, das ich erstellt hatte. Zur Lösung habe ich PV und PVC gelöscht. Ran helm upgrade XXX XXX und es hat gut funktioniert. Wahrscheinlich noch etwas, das untersucht werden sollte, da die PV existierte.

Ich hatte das Gefühl, dass es mit schlechtem pv zusammenhängt ... aber dann ist der Fehler ziemlich irreführend!
auch einige seltsame Protokolle von Pinne ... scheint, dass es gleichzeitig auf 2 Version funktioniert ...

habe es gerade mit 2.7.1 ohne Glück versucht ...

[main] 2017/12/21 15:30:48 Starten von Tiller v2.7.1 (tls = false)
[main] 21.12.2017 15:30:48 GRPC hört zu: 44134
[main] 21.12.2017 15:30:48 Sonden hören zu: 44135
[main] 21.12.2017 15:30:48 Der Speichertreiber ist ConfigMap
[main] 21.12.2017 15:30:48 Maximaler Verlauf pro Veröffentlichung ist 0
[Pinne] 21.12.2017 15:30:55 Update für xxx wird vorbereitet
[Speicher] 21.12.2017 15:30:55 Bereitstellen der freigegebenen Version aus dem "xxx" -Historie
[Pinne] 21.12.2017 15:30:56 Kopieren von Werten von xxx (v65) in eine neue Version.
[Speicher] 21.12.2017 15:30:56 letzte Überarbeitung von "xxx"
[Speicher] 21.12.2017 15:30:56 Release-Verlauf für "xxx" abrufen
[Pinne] 2017/12/21 15:30:59 Rendern des helm-xxx-Diagramms unter Verwendung von Werten
2017/12/21 15:30:59 info: Manifest "helm-xxx / templates / scheduler-deploy.yaml" ist leer. Überspringen.
2017/12/21 15:30:59 info: Manifest "helm-xxx / templates / recomposer-deploy.yaml" ist leer. Überspringen.
2017/12/21 15:31:00 info: Manifest "helm-xxx / templates / recomposer-pvc.yaml" ist leer. Überspringen.
2017/12/21 15:31:00 info: Manifest "helm-xxx / templates / scheduler-pvc.yaml" ist leer. Überspringen.
2017/12/21 15:31:00 info: Manifest "helm-xxx / templates / scheduler-secret.yaml" ist leer. Überspringen.
2017/12/21 15:31:00 info: Manifest "helm-xxx / templates / recomposer-secret.yaml" ist leer. Überspringen.
[tiller] 2017/12/21 15:31:09 erstellt eine aktualisierte Version für xxx
[Speicher] 21.12.2017 15:31:09 Release "xxx.v80" erstellen
[Pinne] 21.12.2017 15:31:09 Update für xxx durchführen
[Pinne] 2017/12/21 15:31:09 Ausführen von 0 Pre-Upgrade-Hooks für xxx
[Pinne] 2017/12/21 15:31:09 Hooks für Pre-Upgrade xxx abgeschlossen
[Pinne] 21.12.2017 15:31:11 Update für xxx vorbereiten
[Speicher] 21.12.2017 15:31:11 Bereitgestellte Version aus dem "xxx" -Historie
[Speicher] 21.12.2017 15:31:11 letzte Überarbeitung von "xxx"
[Speicher] 21.12.2017 15:31:11 Release-Verlauf für "xxx" abrufen
[tiller] 2017/12/21 15:31:18 Rendern des helm-xxx-Diagramms unter Verwendung von Werten
2017/12/21 15:31:18 info: Manifest "helm-xxx / templates / scheduler-secret.yaml" ist leer. Überspringen.
2017/12/21 15:31:18 info: Manifest "helm-xxx / templates / scheduler-pvc.yaml" ist leer. Überspringen.
2017/12/21 15:31:19 info: Manifest "helm-xxx / templates / scheduler-deploy.yaml" ist leer. Überspringen.
[kube] 2017/12/21 15:31:28 Erstellen von Ressourcen aus einem aktualisierten Manifest
[Pinne] 2017/12/21 15:31:46 Erstellen einer aktualisierten Version für xxx
[Speicher] 21.12.2017 15:31:46 Release "xxx.v81" erstellen
[Pinne] 2017/12/21 15:31:47 Update für xxx durchführen
[Pinne] 2017/12/21 15:31:47 Ausführen von 0 Pre-Upgrade-Hooks für xxx
[Pinne] 2017/12/21 15:31:47 Haken für Pre-Upgrade xxx abgeschlossen
[kube] 2017/12/21 15:31:49 Überprüfung von 7 Ressourcen auf Änderungen
[kube] 2017/12/21 15:31:49 Es sieht so aus, als ob es keine Änderungen für Secret "xxx-helm-xxx-nginx-secret" gibt.
[kube] 2017/12/21 15:31:50 Es sieht so aus, als ob es keine Änderungen für Secret "xxx-application-secret" gibt.
[kube] 2017/12/21 15:31:50 Es sieht so aus, als ob es keine Änderungen für Secret "azure-secret" gibt.
[kube] 2017/12/21 15:31:51 Es sieht so aus, als ob es keine Änderungen für ConfigMap "xxx-helm-xxx-nginx-config" gibt.
[kube] 2017/12/21 15:31:51 Es sieht so aus, als ob es keine Änderungen für ConfigMap "xxx-application-config" gibt.
[kube] 2017/12/21 15:31:51 Es sieht so aus, als ob es keine Änderungen für den Dienst "xxx-application-svc" gibt.
[kube] 2017/12/21 15:31:51 Es sieht so aus, als ob es keine Änderungen für StatefulSet "xxx-application" gibt.
[Pinne] 2017/12/21 15:31:51 Ausführen von 0 Post-Upgrade-Hooks für xxx
[Pinne] 2017/12/21 15:31:51 Hooks für Post-Upgrade xxx abgeschlossen
[Speicher] 21.12.2017 15:31:51 Aktualisierung der Version "xxx.v65"
[Pinne] 21.12.2017 15:31:51 Aktualisierungsstatus für aktualisierte Version für xxx
[Speicher] 21.12.2017 15:31:51 Aktualisierung der Version "xxx.v80"
[kube] 21.12.2017 15:31:57 Ressourcen aus aktualisiertem Manifest erstellen
[kube] 2017/12/21 15:32:10 11 Ressourcen auf Änderungen prüfen
[kube] 2017/12/21 15:32:10 Es sieht so aus, als ob es keine Änderungen für Secret "xxx-helm-xxx-nginx-secret" gibt.
[Pinne] 21.12.2017 15:32:10 Warnung: Upgrade "xxx" fehlgeschlagen: Keine Ressource mit dem Namen "xxx-recomposer-secret" gefunden
[Speicher] 21.12.2017 15:32:10 Aktualisierung der Version "xxx.v65"
[Speicher] 21.12.2017 15:32:10 Aktualisierung der Version "xxx.v81"

Es scheint verwirrt zu sein, gleichzeitig zu veröffentlichen ...

habe die gleiche Konfiguration nur zweimal erneut angewendet ...

[Pinne] 21.12.2017 15:50:46 Update für xxx vorbereiten
[Speicher] 21.12.2017 15:50:46 Bereitgestellte Version aus dem "xxx" -Historie
[Speicher] 21.12.2017 15:50:46 letzte Überarbeitung von "xxx"
[Speicher] 21.12.2017 15:50:46 Release-Verlauf für "xxx" abrufen
[Pinne] 2017/12/21 15:50:50 Rendern von helm-xxx-Diagrammen mit Werten
2017/12/21 15:50:50 info: Manifest "helm-xxx / templates / scheduler-pvc.yaml" ist leer. Überspringen.
2017/12/21 15:50:50 info: Manifest "helm-xxx / templates / recomposer-deploy.yaml" ist leer. Überspringen.
2017/12/21 15:50:50 info: Manifest "helm-xxx / templates / scheduler-secret.yaml" ist leer. Überspringen.
2017/12/21 15:50:50 info: Manifest "helm-xxx / templates / scheduler-deploy.yaml" ist leer. Überspringen.
2017/12/21 15:50:50 info: Manifest "helm-xxx / templates / recomposer-secret.yaml" ist leer. Überspringen.
2017/12/21 15:50:50 info: Manifest "helm-xxx / templates / recomposer-pvc.yaml" ist leer. Überspringen.
[Pinne] 2017/12/21 15:50:58 Erstellen einer aktualisierten Version für xxx
[Speicher] 21.12.2017 15:50:58 Release "xxx.v85" erstellen
[Pinne] 2017/12/21 15:50:59 Update für xxx durchführen
[Pinne] 2017/12/21 15:50:59 Ausführen von 0 Pre-Upgrade-Hooks für xxx
[Pinne] 2017/12/21 15:50:59 Haken für Pre-Upgrade xxx abgeschlossen
[kube] 2017/12/21 15:51:13 Erstellen von Ressourcen aus einem aktualisierten Manifest
[kube] 2017/12/21 15:51:22 Überprüfung von 7 Ressourcen auf Änderungen
[kube] 2017/12/21 15:51:22 Es sieht so aus, als ob es keine Änderungen für Secret "xxx-helm-xxx-nginx-secret" gibt.
[kube] 2017/12/21 15:51:23 Es sieht so aus, als ob es keine Änderungen für Secret "xxx-application-secret" gibt.
[kube] 2017/12/21 15:51:23 Es sieht so aus, als ob es keine Änderungen für Secret "azure-secret" gibt.
[kube] 2017/12/21 15:51:23 Es sieht so aus, als ob es keine Änderungen für ConfigMap "xxx-helm-xxx-nginx-config" gibt.
[kube] 2017/12/21 15:51:23 Es sieht so aus, als ob es keine Änderungen für ConfigMap "xxx-application-config" gibt.
[kube] 2017/12/21 15:51:24 Es sieht so aus, als ob es keine Änderungen für den Dienst "xxx-application-svc" gibt.
[kube] 21.12.2017 15:51:24 Löschen von "xxx-recomposer-secret" in xxx ...
[kube] 2017/12/21 15:51:24 Fehler beim Löschen von "xxx-recomposer-secret", err: Geheimnisse "xxx-recomposer-secret" nicht gefunden
[kube] 2017/12/21 15:51:24 Löschen von "xxx-recomposer-config" in xxx ...
[kube] 2017/12/21 15:51:24 Fehler beim Löschen von "xxx-recomposer-config", err: configmaps "xxx-recomposer-config" nicht gefunden
[kube] 2017/12/21 15:51:24 Löschen von "xxx-recomposer-pv" in ...
[kube] 2017/12/21 15:51:24 Fehler beim Löschen von "xxx-recomposer-pv", err: persistentvolumes "xxx-recomposer-pv" nicht gefunden
[kube] 2017/12/21 15:51:24 Löschen von "xxx-recomposer-pvc" in xxx ...
[kube] 2017/12/21 15:51:24 Fehler beim Löschen von "xxx-recomposer-pvc", err: persistentvolumeclaims "xxx-recomposer-pvc" nicht gefunden
[kube] 21.12.2017 15:51:24 Löschen von "xxx-recomposer" in xxx ...
[kube] 2017/12/21 15:51:24 Verwenden von Reaper zum Löschen von "xxx-recomposer"
[kube] 2017/12/21 15:51:24 Fehler beim Löschen von "xxx-recomposer", err: deployments.extensions "xxx-recomposer" nicht gefunden
[Pinne] 2017/12/21 15:51:24 Ausführen von 0 Post-Upgrade-Hooks für xxx
[Pinne] 21.12.2017 15:51:24 Haken für Post-Upgrade xxx abgeschlossen
[Speicher] 21.12.2017 15:51:24 Aktualisierung der Version "xxx.v68"
[Pinne] 21.12.2017 15:51:24 Aktualisierungsstatus für aktualisierte Version für xxx
[Speicher] 21.12.2017 15:51:24 Aktualisierung der Version "xxx.v85"
[Speicher] 21.12.2017 15:51:25 letzte Überarbeitung von "xxx"
[Speicher] 21.12.2017 15:51:25 Release-Verlauf für "xxx"
[kube] 2017/12/21 15:51:38 Get for Secret: "xxx-helm-xxx-nginx-secret"
[kube] 2017/12/21 15:51:39 Relation Pod des Objekts abrufen: xxx / Secret / xxx-helm-xxx-nginx-secret
[kube] 2017/12/21 15:51:39 Get for Secret: "xxx-application-secret"
[kube] 2017/12/21 15:51:39 Relation Pod des Objekts abrufen: xxx / Secret / xxx-application-secret
[kube] 2017/12/21 15:51:39 Get for Secret: "azurblaues Geheimnis"
[kube] 2017/12/21 15:51:39 Relation Pod des Objekts abrufen: xxx / Secret / Azure-Secret
[kube] 21.12.2017 15:51:39 Get for ConfigMap: "xxx-helm-xxx-nginx-config"
[kube] 2017/12/21 15:51:39 Relation Pod des Objekts abrufen: xxx / ConfigMap / xxx-helm-xxx-nginx-config
[kube] 21.12.2017 15:51:39 Get for ConfigMap: "xxx-application-config"
[kube] 2017/12/21 15:51:39 Relation Pod des Objekts abrufen: xxx / ConfigMap / xxx-application-config
[kube] 21.12.2017 15:51:39 Get for Service: "xxx-application-svc"
[kube] 21.12.2017 15:51:39 Relation Pod des Objekts abrufen: xxx / Service / xxx-application-svc
[kube] 21.12.2017 15:51:39 Get for StatefulSet: "xxx-application"
[kube] 2017/12/21 15:51:39 Relation Pod des Objekts abrufen: xxx / StatefulSet / xxx-application

könnte mit # 2941 verwandt sein

a sagte im anderen Thread, eine der Möglichkeiten, das Problem zu beheben, bestand darin, die fehlerhaften Konfigurationskarten zu löschen ... scheint es derzeit für mich zu tun ...

Das ist alles in Ordnung und gut. Bis zu diesem Zeitpunkt, wenn Sie etwas Kritisches aus einem Produktions-Namespace löschen müssen. Was mir zufällig gerade passiert ist. : c

Ich bin auch mit dem Problem konfrontiert, wenn wir eine Version aktualisieren, wenn es mehrere DEPLOYED -Status dieser Version gibt. Sie müssen das Problem beheben, indem Sie die entsprechenden Konfigurationskarten löschen.

Gleiches Problem. Gestern war alles in Ordnung und ich habe mehrere Upgrades durchgeführt. Heute habe ich gerade ein neues Yaml mit service und deployment Block hinzugefügt, getrennt durch --- und das Upgrade ist fehlgeschlagen.

Das Interessante ist , dass das Ruder die service und sich dann darüber beschwert hat (und die Bereitstellung nicht durchgeführt hat).
Ich habe das service und gerade ein Upgrade mit dem deployment -Block durchgeführt - es hat funktioniert. Helm hat den Dienst jedoch nicht gelöscht - was er haben sollte, da er aus der yaml-Datei entfernt wurde.

Update : Ich habe das service manuell gelöscht, es aus dem Yaml entfernt und das Upgrade ausgeführt - diesmal hat es wie ein Zauber funktioniert!

Ich hatte genau diesen Fehler. Es sieht so aus, als ob das Problem mit Vorlagen mit mehreren API-Objekten zusammenhängt, die denen von @amritb ähneln . In meinem Fall hatte ich eine Vorlage mit mehreren API-Objekten, die ein- und ausgeschaltet werden konnten, ähnlich wie:

{{ if .Values.enabled }}
---
...

Das Problem wurde für mich behoben, indem ich das in eine eigene Vorlagendatei zerlegte und die verwaisten Objekte bereinigte, die der Helm erstellt und vergessen hatte. Es hört sich so an, als ob es einen Fehler in der Art und Weise gibt, wie das Helm die vorherige Konfiguration erhält, wenn sich die Anzahl der Objekte pro Vorlage zwischen den Versionen ändert.

Hinzufügen eines weiteren Datenpunkts: Ich habe anscheinend genau das gleiche Problem wie @awwithro. Wir verwenden eine Jinja-Schleife, um mehrere Cronjobs über eine Vorlage zu erstellen, und als ein neues Upgrade dazu führte, dass diese Schleife einen zusätzlichen Cronjob ausfüllte, stießen wir auf den Fehler. Scheint auch # 2941 auszulösen (oder möglicherweise verursacht ein Fehler den anderen), und das Löschen der Zombie-Konfigurationskarten behebt das Problem.

Einfach darin gefangen, auch ohne Konfigurationskarten

Einige zusätzliche Farben für alle, die stecken bleiben könnten:
Ich bin darauf gestoßen, als ich neue Subcharts und Objekte in meine Version aufgenommen habe. Ich konnte das Problem lösen, indem ich jeden hinzugefügten Objekttyp überprüfte und alle vorhandenen Objekte löschte, die eine Namenskollision verursachen würden.

Dies scheint im Einklang mit den Beweisen anderer zu stehen, dass das Löschen derzeit der einzige Weg ist, dies zu lösen 😕

Läuft auch über diese = \

Ich musste auch betroffene Ressourcen löschen. Nicht gut für eine Produktionsumgebung = _ (

Ich sehe etwas, das ich für ähnlich halte. Das Problem scheint zu sein , dass ein helm upgrade nicht --reuse-Werte aus der vorherige deploy. Wenn ich in der Befehlszeile denselben Wertesatz wie bei der Erstinstallation angegeben habe, funktioniert helm upgrade . Keine Ahnung, ob dies hilft (oder jemand anderes kann dies bestätigen).

Wie bei @amritb war es nach dem nächsten Upgrade

Das gleiche Problem mit Helm 2.8.0 . Kubernetes-Versionen client=v1.8.6 und server=v1.8.5-gke.0 .

$ helm upgrade bunny ./app --debug
[debug] Created tunnel using local port: '54274'

[debug] SERVER: "127.0.0.1:54274"

Error: UPGRADE FAILED: no ConfigMap with the name "bunny-proxy-config" found

Die Konfigurationskarte ist jedoch in $ kubectl get configmap . Wenn ich die Konfigurationskarte manuell lösche, funktioniert sie, aber beim nächsten Mal schlägt sie erneut fehl.

Hier ist die Konfigurationskarte:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ template "proxy.fullname" . }}-config
  # namespace: {{ .Release.Namespace }} # I've tried adding and removing it
  labels: # labels are the same as labels from $ kubectl describe configmap bunny-proxy-config
    app: {{ template "proxy.name" . }}
    chart: {{ template "proxy.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
data:
  asd: qwe

Ich habe die Version gelöscht und erneut installiert. Außerdem habe ich die API-Version extensions/v1beta für die Bereitstellung verwendet. Ich habe zu apiVersion: apps/v1beta2 gewechselt. Ich weiß nicht, ob dies geholfen hat oder nicht.
Außerdem führe ich derzeit tiller lokal aus.

Im Moment scheint alles zu funktionieren.

Dies ist wirklich einfach zu reproduzieren, passiert, wenn es einen Fehler im Manifest gibt.

Wie wir Ressource1 und Ressource2 haben, hängt Ressource2 zuerst von ab. Wenn wir die Version aktualisieren, wird Ressource1 erstellt (z. B. PV & PVC), aber Ressource2 schlägt fehl. Danach hilft nur noch das Löschen von resource1, da helm beim Upgrade immer ein Problem meldet (PersistentVolume mit Name ... nicht gefunden)

Wir hatten das gleiche Problem (die Ressource, die uns brachte, war Secrets). Durch Entfernen der neuen Geheimnisse und erneutes Bereitstellen wurde das Problem behoben.

Beachten Sie, dass wir aufgrund der Fehler jetzt 11 verschiedene Releases haben, wenn wir helm list , 10 FAILED und 1 DEPLOYED ausführen. Das wird doch nicht erwartet, oder? Gleiches Problem wie hier: https://github.com/kubernetes/helm/issues/2941

Dies hat das Ruder für reguläre Produktionsbereitstellungen für uns so gut wie unbrauchbar gemacht :( Wir untersuchen derzeit Dinge wie das Übergeben von --dry-run an das Ruder und das Weiterleiten an kubectl apply ... Da dies nur eine Teilmenge der Benutzer zu betreffen scheint Ich bin mir nicht sicher, was wir falsch machen :(

Nachdem ich die Pinnenprotokolle überprüft hatte, stellte ich fest, dass die Pinne gleichzeitig versuchte, eine alte Version zu aktualisieren:

[storage] 2018/02/14 18:25:40 updating release "s2osf.v10"
[storage] 2018/02/14 18:25:40 updating release "s2osf.v44"

Das Löschen der alten Konfigurationskarte für s2osf.v10 und das anschließende Upgrade haben funktioniert.

Client: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}

Das gleiche Problem wie bei @binoculars :

[storage] 2018/02/15 10:20:50 updating release "control.v136"
[storage] 2018/02/15 10:20:50 updating release "control.v226"

Verursacht seltsame Probleme mit UPGRADE FAILED: no Secret with the name "foobar" found .
Ich habe sogar versucht, dieses Geheimnis zu löschen, was stattdessen zu Fehlern in einer Konfigurationskarte führte, und beim dritten Start habe ich mich erneut über das vorherige Geheimnis beschwert.

Dies wurde möglicherweise nach dem Upgrade von Helm 2.7.x auf 2.8.1 ausgelöst.

Client: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}

Wenn es bei Ihrem letzten Ausweg darum geht, die alte Version zu löschen, wird möglicherweise weniger destruktiv gearbeitet, wie in meinem Kommentar https://github.com/kubernetes/helm/issues/3513#issuecomment -366918019 beschrieben

Im Grunde genommen finden Sie diese alte Revision in den Protokollen und bearbeiten die Konfigurationskarte manuell, in der die Pinne den bereitgestellten Status speichert. Es sollte keine zwei Revisionen mit dem Status DEPLOYED afaik geben.

Es wurde eine neue Lösung für dieses Problem gefunden.

kubectl -n kube-system edit cm name_of_your_release.v2 , wobei v2 die letzte Versionsnummer ist, die in helm list als FEHLGESCHLAGEN markiert ist. Möglicherweise möchten Sie auch eine der DEPLOYED-Versionen bearbeiten und den Status in SUPERSEDED ändern, damit nicht zwei Versionen gleichzeitig bereitgestellt werden.

@zuzzas das ist, worauf ich mich bezog. Hat auch für mich gearbeitet

@balboah das Problem ist, dass wir nur eine Bereitstellung im Status DEPLOYED haben, aber wenn es nicht die neueste ist (die in den meisten Szenarien als FAILED markiert sind), stürzt es immer noch ab. Das Problem scheint in den meisten Fällen nicht damit verbunden zu sein, dass zwei oder mehr Bereitstellungen im Status DEPLOYED vorliegen.

@zuzzas hast du viele Releases im selben Namespace oder nur eines? Einmal hatte ich ein Problem mit zwei Releases, die dieselben Objekte aktualisieren, dann stehen sie in Konflikt miteinander.

Wenn es nur einer ist, wie viele Fehler haben Sie bis zur bereitgestellten Version? Wie haben Sie überprüft, ob nur einer bereitgestellt wurde?

Wir glauben, dass dies über # 3539 behoben wurde (vorwärts geht). Bitte öffnen Sie erneut, wenn wir falsch liegen. :) :)

Vielen Dank an alle für Ihre Arbeit daran!

Beachten Sie, dass dies für vorhandene Diagramme in diesem Status nicht behoben wurde. Sie müssen immer noch die alten Releases entfernen, die sich im Status DEPLOYED befinden, damit die Dinge wieder funktionieren. @balboah hat gerade den Fall verhindert, dass Sie in den Status "Mehrere Releases als DEPLOYED markiert" gelangen können. :) :)

Hm, ich bekomme dieses Problem immer noch auf Helm 2.8.2 (nicht das neueste, aber ich habe es mit 2.9.0 versucht und es gibt den gleichen Fehler.) Normalerweise kann das manuelle Löschen der fehlerhaften Ressource das Problem beheben, obwohl es häufig in mehrere Ressourcen übergeht Alle müssen gelöscht werden, bevor ein erfolgreiches Upgrade durchgeführt werden kann.

Ich habe ein großes Helmdiagramm mit verschachtelten Abhängigkeiten. könnte das sein

Ich sehe das gleiche Problem mit der Clusterrollenbindung. Ich habe die neue Ressource zu meinem Diagramm hinzugefügt und upgrade sowie upgrade --install würden mit Error: UPGRADE FAILED: no ClusterRoleBinding with the name "test-clusterrolebinding" found fehlschlagen

Ich habe das gleiche Problem wie @ramyala mit ClusterRole. Die ClusterRole ist vorhanden, aber das Erstellen der Rollenbindung schlägt mit diesem Fehler fehl.

Auf Helm 2.9.1 bin ich auf dasselbe Problem gestoßen:

helm upgrade --install --namespace my-namespace my-stack stack
Error: UPGRADE FAILED: no ConfigMap with the name "my-stack-my-app" found

Während ich diese ConfigMap in meinem Cluster sehe.

Dieses Problem tritt auf, wenn ich mehrere Ressourcen mit Hooks in einer Datei habe

+1, dies passiert wieder mit 2.9.1. Bitte wieder öffnen.

Dies als Fehler neu kennzeichnen. Wir sind uns nicht sicher, warum diese Regression aufgetreten ist, aber wenn jemand Schritte zur Reproduktion dieses Fehlers in 2.9.1 bereitstellen kann, wäre dies sehr zu begrüßen.

@ Bacongobbler

Ich sehe dies auch, wenn ich versuche, einen neuen Ingress in meinem Helmdiagramm bereitzustellen. Ich bin zwar neu bei Ingress, aber es scheint, als ob es auf der Grundlage aller Beispiele korrekt ist, und ich mache seit ein paar Monaten andere Helm / K8-Sachen.

Ich habe das Steuerdiagramm stable/nginx-ingress bereits bereitgestellt, damit der Controller vorhanden ist. Der Fehler scheint darauf hinzudeuten, dass versucht wird, den zu finden, den ich erstellen möchte. Hier ist der Befehl, den ich ausführe:

helm upgrade some-existing-release-name -i --set imageTag=$TAG-$BUILD_NUMBER --namespace=default ./deploy/helm wobei deploy/helm meine Diagrammmanifeste enthält.

Error: UPGRADE FAILED: no Ingress with the name "my-ingress" found

Yaml:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  labels:
    app: my-app
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - host: {{ $.Values.appDomain }}
    http:
      paths:
      - path: /*
        backend:
          serviceName: web-app
          servicePort: 80
      - path: /api/*
        backend:
          serviceName: api
          servicePort: 8080

AKTUALISIEREN
Ich habe die /* von meinen beiden Pfaden entfernt und es gab keinen Fehler mehr beim Versuch, ein Upgrade / eine Installation durchzuführen. Vielleicht ist das einfach keine gültige Syntax

Hallo,
Hier sind die Schritte, die das Problem in meiner Umgebung eingeführt haben:

1. Ich hatte ein Helmdiagramm mehrmals bereitgestellt und aktualisiert.
2. Neues CronJob-Objekt im Diagramm erstellt und erneut aktualisiert - der Cron-Job wurde erfolgreich erstellt.
3. Alle nächsten Upgrades schlagen mit dem gemeldeten Fehler "Fehler: UPGRADE FEHLGESCHLAGEN: Kein CronJob mit dem Namen" Cronjob-Name "gefunden" fehl.

Ich sehe das Problem auch, wenn ich ein Geheimnis hinzufüge, das vorher nicht existierte. Ich habe versucht, eine "Datenbank-Anmeldeinformationen" hinzuzufügen
Geheimnis, das führte zu:

Error: UPGRADE FAILED: no Secret with the name "db-credentials" found

potenziell relevanter Fix: # 4146

Wenn jemand, der auf diesen Fehler stößt, diesen PR testen und prüfen könnte, ob er dies behebt, können wir bestätigen, dass es sich wahrscheinlich um eine Regression in der k8s-API handelt, und mit diesem Fix fortfahren. Vielen Dank!

Ich kann nicht 100% ig bestätigen, ob dies immer reproduziert wird, aber ich habe festgestellt, dass dies in der folgenden Situation der Fall ist:

1. Ich aktualisiere ein Helmdiagramm, einschließlich einer neuen Ressource
2. Dieses Upgrade schlägt fehl, aber die Ressource wurde im Rahmen des fehlgeschlagenen Upgrades erstellt
3. Alle nachfolgenden Upgrades schlagen fehl

Wenn ich bis zur letzten erfolgreichen Bereitstellung ein helm rollback mache und dann ein erneutes Upgrade versuche, scheint es zu funktionieren.

Es scheint sehr einfach zu sein, es manuell zu reproduzieren, ohne absichtlich zu versuchen, ein Diagramm mit schädlichen Änderungen zu aktualisieren (z. B. das Ändern unveränderlicher Jobobjekte):

1. Nehmen Sie ein Diagramm und stellen Sie es bereit (aber lassen Sie eine Ressource weg, sagen wir einen Service).
2. Fügen Sie ausgelassene Ressourcen manuell hinzu (z. B. mit "kubectl create"), jedoch mit dem Namen, der der Version entspricht
3. Fügen Sie die ausgelassene Ressource wieder zum Diagramm hinzu und versuchen Sie dann, sie zu aktualisieren. Das Ruder sollte "UPGRADE FAILED: no" meldenmit dem Namengefunden "

Die Schritte sind unterschiedlich, aber die Grundursache scheint dieselbe zu sein. Korrigieren Sie mich, wenn ich in der Annahme falsch liege, aber es scheint mir, dass die Revision der letzten DEPLOYED-Version keine Informationen über die bestimmte Ressource enthält, entweder weil sie "außerhalb" Helm hinzugefügt wurde (zum Beispiel manuell) oder das letzte Upgrade fehlgeschlagen ist In einem Schritt (z. B. beim Aktualisieren eines unveränderlichen Jobs) werden gleichzeitig andere Objekte bereitgestellt und dann in der FAILED-Revision aufgezeichnet (jedoch immer noch ohne Spur in der DEPLOYED-Revision, was erwartet wird, da dies sonst eine Änderung des Verlaufs bedeuten würde. . Beim nächsten Lauf sieht der Tube-Kube-Client die Ressourcen im Cluster, dh sie sollten bereits bereitgestellt und somit aufgezeichnet sein. Er überprüft die letzte DEPLOYED-Revision (anscheinend wird die FAILED-Revision überhaupt nicht kontaktiert) und sieht sie dort nicht aufgelistet so meldet es Fehler.

@bacongobbler Ich habe # 4146 mit einem benutzerdefinierten behoben ! Für andere, die nach einer Lösung suchen, können Sie den Patch in der Ausgabe auf den aktuellen Master anwenden und kompilieren:

make bootstrap build docker-build

Sie müssen das Pinnenbild in Ihr Repo hochladen und die Pinne in Ihrem Cluster neu installieren. Ich konnte mit einem Force-Reset davonkommen und neu installieren, ohne die aktuellen Releases zu zerstören.

$GO_HOME/src/k8s.io/helm/bin/helm init -i gcr.io/my-repo/tiller:1 --service-account tiller

Vielen Dank an @ramyala für das Testen des

Also habe ich ein paar Fehler mit # 4146 gefunden, die es zu einer unerwünschten PR machen, mit der man weitermachen kann. Ich habe meine Ergebnisse zwischen Master Nr. 4146 und Nr. 4223 hier gemeldet: https://github.com/kubernetes/helm/pull/4223#issuecomment -397413568

@adamreese und ich haben es geschafft, den zugrunde liegenden Fehler zu identifizieren, der diesen bestimmten Fehler verursacht, und die verschiedenen Szenarien und

Oh, und etwas, das ich nicht erwähnt habe: Da sich der Cluster in einem inkonsistenten Zustand befindet, kann dies leicht umgangen werden, indem die Ressource, die der Fehler als "nicht gefunden" meldet, manuell eingegriffen und gelöscht wird. Nach dem Beispiel, das ich in https://github.com/kubernetes/helm/pull/4223#issuecomment -397413568 demonstriert habe:

><> helm fetch --untar https://github.com/kubernetes/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml
><> kubectl create -f foo/templates/service.yaml
service "foo-bar" created
><> helm upgrade $(helm last) ./foo/
Error: UPGRADE FAILED: no Service with the name "foo-bar" found
><> kubectl delete svc foo-bar
service "foo-bar" deleted
><> helm upgrade $(helm last) ./foo/
Release "riotous-echidna" has been upgraded. Happy Helming!
...
><> kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
foo-bar      ClusterIP   10.104.143.52   <none>        80/TCP    3s
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   1h

Um alles zusammen zu halten, werde ich dies als Duplikat von # 1193 schließen, da die beiden Tickets identisch sind. Bitte melden Sie dort alle Ergebnisse, damit wir alle ein einziges Ticket abarbeiten können. Vielen Dank!

Warnung: Diese Informationen sind etwas lückenhaft und ich kann sie nicht verstehen. Für den Fall, dass dies für jemanden nützlich ist, habe ich dieses Problem umgangen, indem ich meine Dienstauswahl geändert habe von:

selector:
    app: {{ template "mything.name" . }}

zu

selector:
    app: mything

Vielleicht gibt es in diesem Zusammenhang ein Problem mit der Verwendung einer Variablen?

Versuchen Sie helm delete RELEASE_NAME --purge
und installieren Sie es erneut.

Ich treffe auch dieses Problem. Ich habe versucht, ein Unterdiagramm mit einer Bereitstellung in meinem Diagramm hinzuzufügen. Es war erfolgreich, als es zum ersten Mal mit helm upgrade chart chart-1.0.1.tgz aktualisiert wurde. Danach ist es mit dem Fehler Error: UPGRADE FAILED: no Deployment with name "subchart-deployment" found fehlgeschlagen, als ich helm upgrade chart chart-1.0.1.tgz ausprobiert habe

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

Die Helmpinne protokolliert nur den gleichen Fehler. Hat das auch jemand erlebt?

Gleiches Problem. Gestern war alles in Ordnung und ich habe mehrere Upgrades durchgeführt. Heute habe ich gerade ein neues Yaml mit service und deployment Block hinzugefügt, getrennt durch --- und das Upgrade ist fehlgeschlagen.

Das Interessante ist , dass das Ruder die service und sich dann darüber beschwert hat (und die Bereitstellung nicht durchgeführt hat).
Ich habe das service und gerade ein Upgrade mit dem deployment -Block durchgeführt - es hat funktioniert. Helm hat den Dienst jedoch nicht gelöscht - was er haben sollte, da er aus der yaml-Datei entfernt wurde.

Update : Ich habe das service manuell gelöscht, es aus dem Yaml entfernt und das Upgrade ausgeführt - diesmal hat es wie ein Zauber funktioniert!

Hallo, ich habe auch dieses Problem, und ich kann es nicht lösen, können Sie mir einige Aufforderungen geben.

Siehe https://github.com/helm/helm/issues/1193#issuecomment -419555433.

Ich bestätige nur, dass ich Zeuge des gleichen Problems bin und die Ursache auch wie oben angegeben ist.

Ein neues Geheimnis wurde hinzugefügt und in einem Volume referenziert (ungültige Syntax). Upgrade fehlgeschlagen, nachfolgende Upgrades mit dem oben beschriebenen Fehler fehlgeschlagen.

Das Auflisten von Geheimnissen zeigte, dass es erstellt wurde. Manuell gelöschtes Geheimnis und das Upgrade wurde erfolgreich durchgeführt.

Gleich, @thedumbtechguy. Ich stoße routinemäßig auf dieses Problem. Es macht besonders Spaß, wenn Helm entscheidet, dass Sie alle Ihre Geheimnisse, Konfigurationskarten, Rollen usw. löschen müssen. Das Upgrade wird zu einem Wack-a-Mole-Spiel mit einer ständig wachsenden Liste von Argumenten auf kubectl delete . Ich hätte vor Monaten das Handtuch für diese Sisyphus-Aufgabe werfen sollen, aber dafür ist es jetzt zu spät. Ich hoffe, dies und die Dutzende ähnlicher Probleme können behoben werden!

Ich benutze das Ruder seit einer Woche und habe mich bereits mit allem konfrontiert, was beschrieben wurde
hier https://medium.com/@7mind_dev/the -problems-with-helm-72a48c50cb45

Hier muss viel repariert werden.

Am Fr, 15. März 2019, 22:49 Uhr schrieb Tom Davis [email protected] :

Gleiches gilt für @thedumbtechguy https://github.com/thedumbtechguy . Ich treffe
dieses Problem routinemäßig. Es macht besonders Spaß, wenn Helm entscheidet, dass Sie es brauchen
Löschen Sie alle Ihre Geheimnisse, Konfigurationskarten, Rollen usw. Das Upgrade wird zu einem
Wack-a-Mole-Spiel mit einer ständig wachsenden Liste von Argumenten für Kubectl
löschen. Ich hätte das Handtuch für diese Sisyphus-Aufgabe Monate werfen sollen
vor, aber dafür ist es jetzt zu spät. Sicher hoffe das und die Dutzende von
ähnliche Probleme können behoben werden!

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/helm/helm/issues/3275#issuecomment-473464809 oder stumm schalten
der Faden
https://github.com/notifications/unsubscribe-auth/AA4XZU4KMQePtZKcir8S5kWulkbYg-8Uks5vXCNggaJpZM4RGz7W
.

Das habe ich auch mit Helm v2.10 erlebt. Ich hatte bereits ein Diagramm bereitgestellt und dem Diagramm eine weitere configMap hinzugefügt. Es wurde gemeldet, dass die Bereitstellung fehlgeschlagen ist, weil configMap "blah" nicht gefunden wurde. Ich tat

helm upgrade <NAME> chart --debug --dryrun 

Um zu überprüfen, ob die configMap tatsächlich gerendert wurde, war dies der Fall. Überprüfte die configMaps im Cluster und fand sie dort. Löschte die blah configMap, führte das Upgrade erneut aus, es funktionierte.

https://github.com/helm/helm/pull/5460 sollte die zukünftige Fehlermeldung besser klären.

Gutes Argument.

$ helm upgrade linting-unicorn testrail                                                                                                                                                                                        
Error: UPGRADE FAILED: no ConfigMap with the name "linting-unicorn-testrail-php-config" found

Machen Sie weiter so mit dem guten Arbeitsteam.

Für den Fall, dass dies für andere eine große Sache ist, sollte ich darauf hinweisen, dass https://github.com/helm/helm/pull/4871 diese Probleme beheben sollte.

Beachten Sie, dass es anscheinend noch nicht vom Helm-Team genehmigt wurde. Außerdem gab es einige Bedenken hinsichtlich der Ressourcen für das automatische Löschen. Erwähnen Sie es nur für den Fall, dass jemand es aus dem Quellcode erstellen und ausprobieren möchte.

Das gleiche Problem und die einzige Problemumgehung zu haben, scheint helm delete --purge release und erneut zu installieren!

Ich bin auf das gleiche Problem gestoßen. @fbcbarbosa es sieht aus wie es war fusionierte vor 2 Wochen. Es sollte hoffentlich Teil der nächsten Version 2.14.0 sein .

Das gleiche Problem und die einzige Problemumgehung zu haben, scheint helm delete --purge release und erneut zu installieren!

Eine weniger zerstörerische Option ist das Ausführen eines helm rollback für die / current / version (dh in Schritten von 0). Ich kann den Erfolg nicht garantieren, aber für uns hat es bisher immer erfolgreich geklappt.

Gibt es eine Idee, ob dies in der nächsten Version sein wird und ob dies der Fall ist, wenn es kommt?

5460 wurde vor 2 Monaten zusammengelegt, was bedeutet, dass es in Ruder 2.14.0 sein sollte.

Ich habe das Problem durch behoben

1. Löschen Sie die Ressourcen, die durch "Helm-Upgrade" beanstandet wurden. (Es heißt Nicht gefunden, aber tatsächlich kann es gefunden werden). Löschen Sie nicht die gesamte Version, da Sie sonst in der Produktion komplett verschraubt werden.
2. Helm-Upgrade wiederholen. Jetzt sollte diesmal "Happy Helming" auftauchen. :) :)

Wir sind in PROD auf dieses Problem gestoßen, als eine Anforderung an unser Umbrella-Helmdiagramm eine Konfigurationskarte hinzufügte, die auf einer Bedingung basiert. Für uns war die Problemumgehung zu beheben

helm rollback <some revision that's acceptable>
helm upgrade <desired version>

Für uns hat ein einfacher Rollback auf die aktuelle Revision immer funktioniert:

helm ls
helm rollback <NAME> <current REVISION>

@tobypeschel Hast du eine Idee, wie dein Fix funktioniert?