Helm: UPGRADE FAILED: Keine Ressource mit dem Namen "" gefunden

Ich stoße auf ein ähnliches Problem, bei dem ich ein Diagramm mit gebündelten Abhängigkeiten habe. Wenn ich eine neue Abhängigkeit hinzufüge und ein helm upgrade ausführe, ist das Ergebnis das gleiche wie beschrieben. Die Ressourcen werden ordnungsgemäß erstellt, jedoch gibt helm einen Fehler zurück.

Also, wenn dies installiert ist: helm install -n my-release

my-thing/
  Chart.yml
  charts/
    depended-upon-thing/

Und dann wird ein neues Diagramm als Abhängigkeit hinzugefügt:

my-thing/
  Chart.yml
  charts/
    depended-upon-thing/
    new-dependency/

Wenn die Version aktualisiert wird mit: helm upgrade my-release my-thing helm wird der folgende Fehler ausgegeben:

Error: UPGRADE FAILED: No resource with the name new-dependency found.

@devth Ich kann dieses Problem nicht auf dem Master reproduzieren. Sehen Sie dieses Problem immer noch? Welche Version von Helm / Pinne fahren Sie?

Vielen Dank!

@elementalvoid Ich konnte auch den neuen Abhängigkeitsfehler vom Master nicht reproduzieren. Sehen Sie dieses Problem immer noch? Welche Version von Helm / Pinne fahren Sie?

Vielen Dank.

Zu der Zeit war ich auf Alpha 4. Mit Alpha 5 und dem Beispiel von @devth konnte ich das Problem auch nicht reproduzieren.

In Ordung. Ich werde das jetzt schließen. Sie können gerne ein Problem einreichen, wenn eines dieser Probleme erneut auftritt.

Danke noch einmal.

@michelleN danke! Entschuldigung, ich hatte diese Woche keine Zeit, einen Repro auf Master zu versuchen. Ich freue mich auf ein baldiges Upgrade!

Gleiches gilt für mich, wenn eine hostPath-Bereitstellungs- / Volume-Spezifikation auf PVC verschoben wird.
Fehler scheint zu sein, wenn ein Upgrade-Manifest von einem neuen abhängt ("fehlt" im alten?)
Version: 2.7.2

Seltsamerweise sehe ich dasselbe Verhalten beim Versuch, ein Diagramm in Version 2.7.2 mit einer neuen Rolle zu aktualisieren. Tiller beschwert sich, dass er die Rolle nicht finden kann und die Bereitstellungen fehlschlägt, obwohl er die Rolle wirklich erstellt hat.

Meine Situation war, dass ich eine neue Ressource hatte und die neue Version des Helmdiagramms mit der neuen Ressource bereitstellte. Dieser Einsatz schlug fehl, weil ich etwas Yaml gefingert hatte. Nun, die neuen Objekte wurden in Kubernetes erstellt. Ich habe das Yaml behoben und das Upgrade in meinem Diagramm erneut ausgeführt. Voila, die Fehlermeldung, dass die Ressource nicht gefunden wurde, wird angezeigt. Ich musste in Kubernetes gehen und die neuen Ressourcen (in meinem Fall eine Rolle und eine Rollenbindung) entfernen, die durch die fehlgeschlagene Bereitstellung erstellt wurden. Danach schlägt die Überprüfung des Helms fehl, um festzustellen, ob das aktuelle Objekt vorhanden ist (https://github.com/kubernetes/helm/blob/7432bdd716c4bc34ad95a85a761c7cee50a74ca3/pkg/kube/client.go#L257), und die Ressourcen werden nicht erstellt nochmal. Scheint ein Fehler zu sein, bei dem möglicherweise neue Ressourcen für ein fehlgeschlagenes Diagramm berücksichtigt werden sollten?

Beim Aktualisieren wird ein ähnlicher Fehler angezeigt:

$ helm upgrade --install bunny ./app --namespace=staging --reuse-values --debug
[debug] Created tunnel using local port: '53859'

[debug] SERVER: "127.0.0.1:53859"

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

Configmap wird erstellt

$ k get configmap
NAME                 DATA      AGE
bunny-proxy-config   1         7m

Meine Konfigurationskarte:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ template "proxy.fullname" . }}-config
  labels:
    app: {{ template "proxy.name" . }}
    chart: {{ template "proxy.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
data:
  asd: qwe

Wir haben das gleiche Problem.

Ich habe die gesamte Version gelöscht und dann erneut installiert. Derzeit scheint es zu funktionieren.

$ helm del --purge bunny

Ich habe auch dieses Problem

Client: & version.Version {SemVer: "v2.8.0", GitCommit: "14af25f1de6832228539259b821949d20069a222", GitTreeState: "clean"}
Server: & version.Version {SemVer: "v2.8.0", GitCommit: "14af25f1de6832228539259b821949d20069a222", GitTreeState: "clean"}

Dies passiert häufig bei unserer Verwendung von Helm und erfordert eine volle --purge . Das ist keine Lösung.

Dies gilt nicht, wenn Sie CI / CD verwenden.
Was passiert, wenn ein Upgrade fehlschlägt und Sie eine fortlaufende Update-Strategie verwenden? Muss ich meine noch funktionierende Version löschen?

Ich sehe das gleiche Problem auch, wenn es ein Bereitstellungsproblem oder ähnliches gibt, aber das Geheimnis / cm erstellt wurde, aber dann verliert Helm den Überblick und weigert sich, Sie viel tun zu lassen.

Ich habe es selten gesehen, auch nicht bei einer nicht kaputten Veröffentlichung (dh es wird als durchlaufen angesehen), aber ich muss noch herausfinden, was das verursachen könnte.

Wir können dieses Problem (Server v2.8.2) auch reproduzieren, wenn wir vorhandenen Helmbereitstellungen Ressourcen hinzufügen. Das Löschen der Bereitstellung und das erneute Bereitstellen jedes Mal, wenn eine neue Ressource hinzugefügt werden muss, ist ein großes Problem in der Produktion.

In unserem Fall haben wir einem Diagramm eine Konfigurationskarte hinzugefügt, und das Diagramm kann nicht aktualisiert werden mit:

Fehler: UPGRADE FAILED: Keine Ressource mit dem Namen ""gefunden

Hinweis: Wir verwenden 2.7.2;

Ich glaube, das passiert, weil das Ruder, wenn es feststellt, was sich geändert hat, nach der neuen configmap-Ressource in der alten Version sucht und diese nicht findet. Den Code, von dem dieser Fehler stammt, finden Sie unter https://github.com/kubernetes/helm/blob/master/pkg/kube/client.go#L276 -L280.

Pinnenprotokolle für das fehlgeschlagene Upgrade:

[tiller] 2018/05/03 19:09:14 preparing update for staging-collector
[storage] 2018/05/03 19:09:14 getting deployed release from "staging-collector" history
[tiller] 2018/05/03 19:10:39 getting history for release staging-collector
[storage] 2018/05/03 19:10:39 getting release history for "staging-collector"
[tiller] 2018/05/03 19:10:41 preparing update for staging-collector
[storage] 2018/05/03 19:10:41 getting deployed release from "staging-collector" history
[storage] 2018/05/03 19:10:42 getting last revision of "staging-collector"
[storage] 2018/05/03 19:10:42 getting release history for "staging-collector"
[tiller] 2018/05/03 19:10:44 rendering collector chart using values
[tiller] 2018/05/03 19:10:44 creating updated release for staging-collector
[storage] 2018/05/03 19:10:44 creating release "staging-collector.v858"
[tiller] 2018/05/03 19:10:44 performing update for staging-collector
[tiller] 2018/05/03 19:10:44 executing 0 pre-upgrade hooks for staging-collector
[tiller] 2018/05/03 19:10:44 hooks complete for pre-upgrade staging-collector
[kube] 2018/05/03 19:10:44 building resources from updated manifest
[kube] 2018/05/03 19:10:44 checking 3 resources for changes
[tiller] 2018/05/03 19:10:44 warning: Upgrade "staging-collector" failed: no resource with the name "collector-config" found 
[storage] 2018/05/03 19:10:44 updating release "staging-collector.v857"
[storage] 2018/05/03 19:10:44 updating release "staging-collector.v858" 

Dieses Problem tritt auch auf, wenn die Bezeichnung name eines bereitgestellten Dienstes geändert wird, möglicherweise auch andere Dinge.

Ich ändere den Namen eines Dienstes in einer Version und es kann nicht aktualisiert werden mit:

Fehler: UPGRADE FAILED: Kein Dienst mit dem Namen "new-service-name" gefunden

Ich wäre bereit, eine PR zu erstellen, um dieses Verhalten zu beheben, aber ich würde gerne wissen, wie dies beabsichtigt oder vorgeschlagen wird. Sogar ein CLI-Flag, mit dem --force Vorrang haben kann, wäre großartig.

Vereinbaren Sie die Wichtigkeit.

Dieses Problem kann seltsam sein, wenn Sie eine Bereitstellung nicht einfach löschen können.

Ich habe festgestellt, dass unser Problem auf eine fehlgeschlagene Bereitstellung zurückzuführen ist.

Helm versucht nicht, nach einer fehlgeschlagenen Bereitstellung zu bereinigen. Dies bedeutet, dass Dinge wie die neue ConfigMap, die ich oben hinzugefügt habe, erstellt werden, jedoch ohne Verweis in der vorherigen Bereitstellung. Das heißt, wenn die nächste Bereitstellung erfolgt, findet helm die Ressource in k8s und erwartet, dass sie in der letzten bereitgestellten Version referenziert wird (oder so; ich bin mir nicht sicher, welche genaue Logik es verwendet, um die 'vorherige' Version zu finden), um zu überprüfen, was Änderungen gibt es. Es ist nicht in dieser Version enthalten, daher kann es die Ressource nicht finden und schlägt fehl.

Dies ist hauptsächlich ein Problem, wenn ein Diagramm entwickelt wird, da eine fehlgeschlagene Bereitstellung k8s in einen Status versetzt, in dem das Ruder nicht richtig verfolgt wird. Als ich herausfand, dass dies geschah, wusste ich, dass ich nur die ConfigMap von k8s löschen und die Bereitstellung erneut versuchen musste.

@krishicks Ja, dies ist eine Möglichkeit, es zu

Wir treffen auch diesen. Es ist das gleiche Problem, das @krishicks und @jaredallard erwähnen:

1. Wir haben eine fehlgeschlagene Bereitstellung:
   UPGRADE FAILED: the server was unable to return a response in the time allotted, but may still be processing the request (get configmaps)
2. Alle nachfolgenden Änderungen, auch an anderen Releases, schlagen mit einer Warnung wie fehl
   Error: UPGRADE FAILED: no Service with the name "…" found

Ich werde versuchen, das Flag helm upgrade --timeout … verwenden, um das erste Problem zu beheben, aber eine fehlgeschlagene Bereitstellung, die alles blockiert, ist für uns ein ziemliches Problem. Die Verwendung von helm rollback … dies ebenfalls nicht behoben.

Da helm upgrade … in unserem Anwendungsfall automatisch ausgeführt wird, wäre ein --auto-rollback -Flag für helm upgrade sehr hilfreich, wodurch die fehlgeschlagenen Änderungen rückgängig gemacht werden.

Dies geschieht für mich mit Version 2.7.2, wenn dem Diagramm neue Ressourcen hinzugefügt werden.
Gibt es eine Schätzung, wann dies behoben werden kann?

Dies sollte mit # 4146 behoben werden.

EDIT: siehe unten

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

@bacongobbler Das funktioniert nicht immer. Wir hatten Situationen, in denen das Löschen funktioniert und einige, in denen es danach immer noch nicht funktioniert.

Dies kann leicht umgangen werden, indem die Ressource manuell eingegriffen und gelöscht wird

@bacongobbler Bitte haben Sie Verständnis dafür, dass es sich bei dieser Ressource möglicherweise um das Service- oder Bereitstellungsobjekt eines Produktions-Namespace handelt, wodurch unsere Servicegarantien möglicherweise (und bereits) stark beeinträchtigt werden.

Ja, ich weiß. Ich erkläre und beobachte nur das Verhalten des Fehlers, damit andere wissen, worum es geht. :) :)

Führen Sie dieses Problem einfach zweimal in verschiedenen Clustern aus. Jedes Mal mit Konfigurationskarten. Das Löschen der Ressourcen hat das Problem nicht gelöst, daher mussten wir die gesamte Version entfernen.

Hier gilt das gleiche. Nicht nur Configmaps habe ich mit ServiceAccount.

PVC hier. :) :)

Grundsätzlich ist jede Art von priorisiertem Objekt diesem Fehler ausgesetzt.

Ist jemand damit beauftragt, das zu beheben? Gibt es dafür schon eine PR? Kann ich bei irgendetwas helfen?

Ich bin mehr als einmal von diesem Problem gebissen worden, da es eine einfache Situation ist, in die man sich hineinversetzen kann, aber anscheinend gibt es keinen einfachen Weg, um herauszukommen. Ich nehme an, der "gute" Teil in meinem Fall ist, dass die Ressourcen auch mit dem Fehler in der Version aktualisiert werden (nicht sicher, ob mich das glücklich oder besorgt macht).

Ich denke, das Ruder sollte dem Benutzer entweder verbieten, in diesen falschen Zustand zu gelangen, oder richtig damit umgehen.
Gibt es echte Korrekturen dafür, wenn nicht alles gelöscht wird (was nur für nicht produktive Zwecke möglich ist)?

Wenn jemand anderes den anderen Randfall bestimmen kann, in dem das Löschen der Ressource das Problem nicht gelöst hat, ist dies sehr hilfreich bei der Ermittlung der Grundursache für die Lösung dieses bestimmten Problems. Es kann mehrere Pfade geben, die denselben Fehler verursachen können.

@Draiken nein, wir haben mehrere Lösungen für das Problem versucht, und keine davon scheint vernünftig zu sein

a) Führen Sie das Upgrade nicht wie beabsichtigt durch, oder
b) neue Fehler einführen

Ich habe hier über diese Lösungen geschrieben und warum sie nicht funktionieren. Wenn Sie eine alternative Lösung finden, schauen wir uns diese gerne an.

Wir können Gatekeep-Benutzer auch nicht davon abhalten, in diesen falschen Zustand zu gelangen. Wir haben uns Lösungen angesehen, aber auch hier führen sie alle zu unterschiedlichen Problemen. Sobald sich die Installation in einem inkonsistenten Zustand befindet, ist es schwierig, sie ohne manuellen Eingriff zu "reparieren". 😢

Eine Problemumgehung, die für mich funktioniert hat, besteht darin, unmittelbar vor dem Auftreten des Fehlers ein helm rollback ... auszuführen. Ich bestätige dann, dass das Diagramm in einer neuen Version mit helm install -n new-test-release . funktioniert.

Sobald alles funktioniert, bereinige ich die Testversion und führe die helm upgrade ... gegen die alte Version aus. und alles hat funktioniert. Dies ist eine nervige Problemumgehung, aber es scheint zu funktionieren.

Ich weiß nicht, ob dies überhaupt hilft, aber ich bin gerade auf dieses Problem sowohl in meinen Test- als auch in meinen Produktionsclustern gestoßen.

Die Änderungen, die ich an meinen Steuerdateien vorgenommen habe, waren ziemlich einfach:
Ich hatte eine vorhandene Bereitstellung mit einem zugehörigen Service und einem Poddisruption-Budget, die unverändert blieben.
Ich habe eine zweite Bereitstellung mit eigenem Service und Poddisruptionbudget hinzugefügt.
Ich habe die Versionsnummer des Diagramms erhöht.

Beim Laufen des Ruders habe ich beim ersten Mal folgende Fehlermeldung erhalten:

KUBECONFIG=**** helm upgrade --kube-context=mycluster -f helm/project/mycluster.yaml project ./helm/project --install --wait --timeout 1200

Error: UPGRADE FAILED: Deployment.apps "blah-blah" is invalid: spec.template.metadata.labels: Invalid value: map[string]string{"app":"blah-blah", "chart":"blah-3", "name":"blah", "release":"project"}: `selector` does not match template `labels`

Wenn ich wieder das Ruder laufen lasse, erhalte ich jetzt immer wieder diesen Fehler:

KUBECONFIG=**** helm upgrade --kube-context=mycluster -f helm/project/mycluster.yaml project ./helm/project --install --wait --timeout 1200

Error: UPGRADE FAILED: no Service with the name "blah-blah" found

Das Ruderdiagramm funktionierte natürlich im Test, als ich alles löschte und erneut bereitstellte. Das ist allerdings keine Option für Prod.

@veqryn Ich bin stoße, und wechsle dann zurück zum Hauptproblem. Funktioniert jedes Mal. Ich weiß, dass die Betreuer es vielleicht nicht empfehlen, aber es funktioniert, was besser als nichts ist.

BEARBEITEN : Wenn jemand daran interessiert ist, es zu versuchen, kann ich es an ein öffentliches Docker-Repo senden und einen kurzen Ausschnitt seiner Verwendung beifügen.

@jaredallard wir sind interessiert. Vielen Dank!

Ich weiß, dass die Betreuer es vielleicht nicht empfehlen, aber es funktioniert, was besser als nichts ist.

@jaredallard Wir konnten diesen Patch nicht empfehlen, nur weil er alleine nicht funktioniert (siehe: https://github.com/helm/helm/pull/4223#issuecomment-397413568). Der Fehler wird umgangen, die Ressourcen werden jedoch nicht aktualisiert, sodass der Patch nicht das tut, was der Benutzer ursprünglich beabsichtigt hatte. Es behebt ein Problem, führt jedoch ein anderes ein, ohne das ursprüngliche Problem zu beheben, das Benutzer ausführen möchten: Aktualisieren einer Ressource.

Dies ist jedoch faszinierend:

Grundsätzlich verwende ich meinen Build in # 4146, wenn ich auf dieses Problem stoße, und wechsle dann zurück zum Hauptproblem.

Wenn ich das richtig lese, schlagen Sie vor, dass Sie eine Problemumgehung dafür gefunden haben

a) umgeht den Fehler
b) ermöglicht es einem, Ressourcen wie ursprünglich beabsichtigt zu aktualisieren

indem Sie 2 helm upgrade s machen: eine mit dem Patch und eine ohne? Dies könnte uns helfen, die Grundursache besser zu identifizieren und diesen Fehler zu beheben.

@bacongobbler Ich müsste dies erneut überprüfen, um zu 100% zu überprüfen, ob dies das Verhalten ist. Ich werde diesen Kommentar aktualisieren oder einen anderen posten, wenn ich habe.

Ich weiß, dass die Betreuer es vielleicht nicht empfehlen, aber es funktioniert, was besser als nichts ist.

Außerdem versuche ich zur Verdeutlichung nicht, dort Schatten zu werfen! Es ist ein wenig schlecht formuliert, wenn ich jetzt zurückblicke, sorry

Ich bin immer noch verwirrt darüber, warum mein Ruder beim ersten Mal versagt hat.
Der Fehler no X with the name Y erst beim zweiten Versuch angezeigt, ihn anzuwenden.

@veqryn Ich habe in der oben verlinkten Ausgabe geschrieben, wie dieses Problem überhaupt

Für die Faulen: https://github.com/helm/helm/pull/4223#issuecomment -397413568

Ich habe das tatsächlich gelesen und mein Verständnis war, dass das Problem bei Ihnen aufgetreten ist, weil Sie den Namen Ihres Dienstes geändert haben.

Zu keinem Zeitpunkt haben jedoch meine Dienste oder Ressourcen ihren Namen geändert.

Und nachdem wir Ihren Kommentar noch einmal gelesen und mit meiner Crew gesprochen haben, haben wir die Ursache unseres Fehlers herausgefunden:
Ich hatte die Version meines Ruderdiagramms gestoßen.
Diese Diagrammversion wurde von meinen Bereitstellungen und Diensten als Bezeichnung bezeichnet.
Kube / helm mag es nicht, wenn sich Ihr Etikett ändert, und dies hat den ursprünglichen Fehler verursacht.

Die Lösung (für mich) bestand darin, mithilfe des Helms zur letzten erfolgreichen Bereitstellung zurückzukehren und dann die Änderung der Diagrammversion zurückzusetzen, sodass die Diagrammversion dieselbe blieb, was dann erfolgreich war.

Diese (hässliche) Lösung funktioniert bei mir:

1. Ich erhalte die Fehlermeldung:

helm upgrade az-test-2-prom ./prometheus --namespace monitor --set cluster_name="az-test-2" -f values.yaml
Error: UPGRADE FAILED: no ConfigMap with the name "az-test-2-prom-prometheus-grafana-config" found

1. Finden Sie die letzten DEPLOYED-Revisionen

export TEMPLATE='{{range .items}}{{.metadata.name}}{{"\t"}}{{.metadata.labels.STATUS}}{{"\n"}}{{end}}'
kubectl -nkube-system get cm -l 'OWNER=TILLER' -ogo-template="$TEMPLATE"

az-test-2-prom.v1   SUPERSEDED
az-test-2-prom.v10  SUPERSEDED
az-test-2-prom.v11  SUPERSEDED
az-test-2-prom.v12  SUPERSEDED
az-test-2-prom.v13  SUPERSEDED
az-test-2-prom.v14  SUPERSEDED
az-test-2-prom.v15  SUPERSEDED
az-test-2-prom.v16  SUPERSEDED
az-test-2-prom.v17  DEPLOYED
az-test-2-prom.v18  FAILED
az-test-2-prom.v19  FAILED
az-test-2-prom.v2   SUPERSEDED
az-test-2-prom.v20  FAILED
az-test-2-prom.v21  FAILED
az-test-2-prom.v22  FAILED
az-test-2-prom.v23  FAILED
az-test-2-prom.v24  FAILED
az-test-2-prom.v25  FAILED
az-test-2-prom.v26  FAILED
az-test-2-prom.v27  FAILED
az-test-2-prom.v28  FAILED
az-test-2-prom.v29  FAILED
az-test-2-prom.v3   SUPERSEDED
az-test-2-prom.v30  FAILED
az-test-2-prom.v4   SUPERSEDED
az-test-2-prom.v5   FAILED
az-test-2-prom.v6   SUPERSEDED
az-test-2-prom.v7   SUPERSEDED
az-test-2-prom.v8   SUPERSEDED
az-test-2-prom.v9   FAILED



md5-6d9e4edff5e9111525fecb734bfec15a



for ii in {17..30}
> do
>   kubectl -nkube-system delete cm az-test-2-prom.v${ii}
> done



md5-cf6357e67a21fb9f80abb7b78b9e5b8e



kubectl -nkube-system patch cm az-test-2-prom.v16 -p '{"metadata": {"labels": {"STATUS": "DEPLOYED"}}}'

** 4. (Wichtig) Suchen Sie nach allen Ressourcen, die seit der letzten Bereitstellung (v16) vorhanden sind, und löschen Sie sie beispielsweise
kubectl -nmonitor delete cm az-test-2-prom-prometheus-grafana-config
kubectl -nmonitor delect svc ...

Führen Sie helm upgrade ... und sehen Sie Happy Helming

Wie @ kosta709 sagte, normalerweise , zur letzten bereitgestellten Version zurückzukehren, das Diagramm oder den aktuellen Status (was auch immer falsch ist) (manuell) zu durchzuführen .

Helm ist eine großartige Software, die in einigen automatischen Workflows (CI / CD) verworfen werden kann, wenn das Ergebnis eines Befehls nicht stabil ist.

Gibt es eine Option, dass die bekannten Lösungen irgendwann im Ruder implementiert werden, um dieses bekannte (und etwas nervige) Problem zu lösen (zu versuchen)? Vielen Dank.

In letzter Zeit treffe ich das auch oft genug, um mich selbst dazu zu bringen, an diesem Thema zu arbeiten. Für den Anfang habe ich eine Problemumgehung erstellt (
https://github.com/Nopik/helm/commit/afe6451cc2c6295e71ea2213ccce654ec3f5b686), wodurch Tiller im Grunde genommen eine vorhandene Ressource als Ausgangspunkt anstelle einer aus dem alten Manifest entnommenen Ressource erhält. Funktioniert wie ein Zauber für mich, obwohl ich glaube, dass die Kernentwickler es nicht zusammenführen wollen, da es hartcodiertes Verhalten enthält.

Möglicherweise sind zwei Fehler unter demselben Verhalten verborgen, da ich mindestens einmal, wenn dieser Fehler mich beißt, viele (> 40) Ressourcen löschen musste, einschließlich einiger, die bereits für> 20 erfolgreiche Release-Versionen vorhanden waren. In 99% der Fälle reicht es jedoch aus, nur neu erstellte (und dem Ruder unbekannte) Ressourcen zu löschen.

Also habe ich darüber nachgedacht, wie ich es richtig lösen kann. Ich beschreibe es unten. Core-Entwickler korrigieren mich bitte hier und wiegen Sie ab, wenn Sie mir zustimmen. Wenn ja, bin ich bereit, diese Bemühungen zu leiten und PR bereitzustellen, um sie zu beheben.

Im Allgemeinen scheint das Ruder im Patch-Modus zu arbeiten: Wenn der Benutzer die Ressource irgendwie ändert und die neue Release-Version einige andere Parameter ändert, berechnet das Ruder den Patch zwischen zwei Revisionen und wendet ihn an. Ich glaube, dass versucht wird, die Benutzeränderungen intakt zu halten.

Das führt leider zu einem 3-Wege-Zusammenführungsproblem, da wir eine Ressourcenversion aus dem alten Manifest, eine andere Version aus dem neuen Manifest und eine andere Version aus der aktuell lebenden Ressource haben. Und das Ruder ist anscheinend schlecht darin, Konflikte zu lösen, wenn sie entstehen.

Ich denke, dass der richtige Weg entweder darin besteht, bessere Standardeinstellungen zu wählen (im Grunde geht das Zusammenführen meines Zweigs weit) oder ein Flag für den Benutzer bereitzustellen. ZB so:

• --ignore-old-manifest=never (Standard, aktuelles Verhalten)
• --ignore-old-manifest=create-only (gilt für diesen Fall, wenn das alte Manifest keine Vorstellung von der Ressource hat, die Ressource jedoch bereits vorhanden ist, können wir dies als neue Basis verwenden und es bei Bedarf einfach patchen) - Ich würde dies als neu empfehlen Standard. Dies würde es dem Ruder auch ermöglichen, das Eigentum an manuell erstellten Ressourcen zu übernehmen.
• --ignore-old-manifest=always - der Vollständigkeit halber wahrscheinlich nicht unbedingt erforderlich. Es wird immer ein Patch zwischen der aktuellen Ressource und dem neuesten Manifest erstellt, wodurch im Grunde alle Benutzermodifikationen entfernt werden.

Natürlich können Sie das Flag umbenennen, um die umgekehrte Logik zu verwenden: --use-current-resources=never(currently default)/create-only/always oder so ähnlich.

Später könnte dieses Flag aus Ressourcenanmerkungen entnommen werden, etwa:

annotations:
  helm.io/ignore-old-manifest: always

Welches Ruder könnte diese Strategie pro Ressource erkennen und anwenden? Ich bin mir allerdings nicht sicher, ob Helmentwickler dorthin wollen;)

Was halten Sie von diesem Vorschlag?

Siehe auch Ausgabe Nr. 3805, in der Helmentwickler einen 3-Wege-Merge-Patch in Betracht ziehen.

Gleiches Problem hier.
Versuch, eine CD / CI-Umgebung mit Google Cloud Build einzurichten.
Error: UPGRADE FAILED: no Deployment with the name "baobab-sidekiq" found

Das Lustige ist, dass der Einsatz existiert:

kc get deployments
NAME             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
baobab           3         3         3            2           2d
baobab-ermis     1         1         1            1           23h
baobab-sidekiq   1         1         1            1           23h

Dies ist das erste Diagramm, das ich erstellt habe, und ich hatte erwartet, dass helm die Lösung ist, um die Komplexität der Bereitstellung komplexer Anwendungen in einer CI / CD-Umgebung zu bewältigen.

Ist die Absicht des Ruders, in einer CI / CD-Pipeline arbeiten zu können?

Vielen Dank

Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

Ich stoße auch darauf und versuche, Helm 0.8.0 auf Helm 1.0.0 zu aktualisieren.

helm version --tls Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

Ich bin auch darauf gestoßen, als ich die Anforderungen eines Diagramms aktualisiert habe. Ich sehe, dass Istio ebenfalls auf diesen Fehler stößt. Das Installationsdokument verwendet helm template . Ist das eine Problemumgehung für dieses Problem?

Überprüfen Sie die letzten Diskussionen unter https://github.com/helm/helm/issues/3805

Wenn dies auch so ist, passiert dies immer noch für das neueste Ruder 2.10

Es ist an der Zeit, dass dieses Problem ernsthaft in Betracht gezogen wird. Es ist nun 2 Jahre her und eine Menge Leute berichten über genau dieselben Probleme, die das Ruder in der Produktion ziemlich unbrauchbar machen und ein echtes Problem sind, wenn Ihr Einsatz vom Ruder abhängt.

Mit vielen GitHub-Stars geht eine große Verantwortung einher

@ brendan-rius Sie können gerne Code beisteuern, um dieses Problem zu beheben, oder sich Ideen einfallen lassen. Siehe # 3805 und # 4146 für einige Hinweise.

@ brendan-rius, # 3805 hat insbesondere die neuesten Diskussionen rund um diesen Fehler. Ich empfehle dringend, diesen Thread zu lesen, um eine Vorstellung davon zu bekommen, was uns erwartet.

Ich habe meinen Kommentar hier erneut veröffentlicht, da er mehr mit diesem Problem zu tun hat als mit 3-Wege-Zusammenführungsstrategien:

Wenn eine Drei-Wege-Zusammenführung für neue Bereitstellungen in Helm 2.yz nicht möglich ist, wann wird # 1193 behoben? Der Fehler ist seit fast zwei Jahren offen, für Helm 2.0 ist keine klare Lösung geplant.

An diesem Punkt sind wir ratlos, wie wir vorgehen sollen. Wir haben den Fehler wochenlang diskutiert und keine der vorgeschlagenen Lösungen wird in allen Fällen funktionieren, entweder durch Einführung neuer Fehler oder durch wesentliche Änderung des Upgrade-Verhaltens der Pinne.

Zum Beispiel haben @michelleN und ich Anfang dieser Woche ein Brainstorming uns zwei mögliche Lösungen überlegt, von denen keine besonders fantastisch ist:

1. Wenn ein Upgrade fehlschlägt, werden Ressourcen, die während dieser Version erstellt wurden, automatisch zurückgesetzt und gelöscht.

Dies ist sehr riskant, da sich der Cluster nach einem fehlgeschlagenen Upgrade möglicherweise in einem unbekannten Zustand

1. Wenn wir während eines Upgrades eine neue Ressource erstellen und feststellen, dass diese bereits vorhanden ist, wenden wir diese Änderungen stattdessen auf die vorhandene Ressource an oder löschen / erstellen sie neu.

Dies ist äußerst riskant, da Helm möglicherweise Objekte löscht, die über andere Pakete oder über kubectl create installiert wurden, von denen keiner Benutzer dies wünscht.

Die bisher sicherste Option bestand darin, die Benutzer zu bitten, im Fall dieses Konflikts manuell einzugreifen, was im Folgenden erläutert wird.

Wenn jemand Vorschläge / Feedback / alternative Vorschläge hat, würden wir gerne Ihre Gedanken hören.

@bacongobbler , wenn keine Unterstützung für die 3-Wege-Zusammenführungsfunktion geplant ist, benötigen wir eine Alternative oder eine Problemumgehung. Ansonsten ist # 1193 ein ernsthaft schmerzhafter Bocker.

So wiederholen Sie das Problem sowie die Problemumgehung:

Wenn ein Upgrade, bei dem neue Ressourcen installiert werden, fehlschlägt, wechselt die Version in den Status FAILED und stoppt den Upgrade-Prozess. Wenn Sie das nächste Mal helm upgrade aufrufen, unterscheidet sich Helm von der letzten DEPLOYED-Version. In der letzten Version von DEPLOYED war dieses Objekt nicht vorhanden, daher wird versucht, die neue Ressource zu erstellen, dies schlägt jedoch fehl, da es bereits vorhanden ist. Die Fehlermeldung ist völlig irreführend, wie @arturictus hervorhebt .

Dies kann leicht umgangen werden, indem die Ressource, die der Fehler als "nicht gefunden" meldet, manuell eingegriffen und gelöscht wird. Dem Beispiel folgend, das ich in https://github.com/helm/helm/pull/4223#issuecomment -397413568 demonstriert habe:

><> helm fetch --untar https://github.com/helm/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml                    # change the service name from "foo" to "foo-bar"
><> kubectl create -f foo/templates/service.yaml      # create the service
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

Mit anderen Worten, das Löschen von Ressourcen, die während der FAILED-Version erstellt wurden, umgeht das Problem.

@bacongobbler Zunächst einmal möchte ich mich bei Ihnen dafür bedanken, dass Sie sich dieses Problem in den letzten Wochen genauer angesehen haben. Ich bin mir nicht ganz sicher , was genau das Problem ist in Istio 0.8.0 bis 1.0.0 Istio Upgrade , das das Problem verursacht , oder wenn es vollständig entspricht Ihre Ausgabe Aussage. Ich spekuliere, dass ungefähr 3 Tage vor der Veröffentlichung einige Objekte, die zuvor nicht verwaltet wurden (dh in einem Job nach der Installation hinzugefügt wurden), migriert wurden, um nicht in einem Job nach der Installation installiert zu werden.

Im Gespräch mit der Istio-Betreibergemeinschaft, die bereits viel Erfahrung mit Helm gesammelt hat, haben uns einige Betreiber mitgeteilt, dass nicht verwaltete Ressourcen in Helm schlechte Nachrichten sind und häufig zu Upgrade-Fehlern führen. Wenn die Implementierung von Istio-Diagrammen einen Fehler aufweist, der sie mit dem Upgrade mit Helm 2.yz nicht kompatibel macht, wäre es großartig, diese Inkompatibilitäten zu beheben. Wir haben also in Zukunft keine Upgrade-Fehler mehr.

Wir sind bereit, das 1-malige Upgrade von 0.8.0 auf 1.0.0 durchzuführen. Wenn das Upgrade ständig flockig ist, ist das ein anderes Problem.

Ich habe eine Halbierung auf Istio ausgeführt, da das Upgrade bis zum 27. Juli (3 Tage vor der Veröffentlichung von Istio 1.0.0) funktionierte, und fand dieses Commit problematisch: https://github.com/istio/istio/commit/301612af08128b15069d27ff6d03cdb87420e15b

Diese PR entfernte im Wesentlichen die Objektregistrierung aus Aufträgen nach der Installation. Ich glaube, aber ich bin nicht sicher, dass wir alle Instanzen von Jobs nach der Installation im dreitägigen Hochlauf auf Istio 1.0.0 entfernt haben.

Können Sie Ratschläge zu Istios spezifischer Helmkarte in Bezug auf das Upgrade geben? Wird es unsere Upgrade-Probleme dauerhaft lösen, wenn die Objektregistrierung nicht in den Jobs nach der Installation enthalten ist?

Ich kann weder einen starken Rat noch einen Vorschlag zur Behebung dieses Problems helmweit machen, da Personen mit neueren Erfahrungen mit Helm keine allgemeine Lösung finden konnten (und nicht aus Mangel an einem Blick auf das Problem). Ich glaube nicht, dass ich es besser machen könnte.

Prost
-steve

Der Titel wurde aktualisiert, um den Fehler besser widerzuspiegeln.

Wir sind auch von dem Problem betroffen. Wir verwenden den neuesten Helm 2.10 mit GKE 10.6.
Wann kann ich damit rechnen, dass das behoben wird?
Haben wir eine vernünftige Problemumgehung für das Problem? Das Entfernen der gesamten Bereitstellung mit der Option --purge ist so schlecht.

Bitte zögern Sie nicht, meinen letzten Kommentar abzuwägen. Wir brauchen wirklich Feedback, wie wir hier am besten vorgehen können.

Eine Problemumgehung wurde in diesem Thread mehrmals wiederholt. Bitte lesen Sie https://github.com/helm/helm/issues/1193#issuecomment -419555433.

Ich mag die Idee einer automatischen Rollback-Funktion für das Ruder ( Option 1 ), um dieses Problem zu lösen. Wir wissen, dass die letzte Version von DEPLOYED Helm funktioniert hat und der Cluster in einem guten Zustand war, sodass es sicher sein sollte, darauf zurückzugreifen. Wenn es für einige Anwendungsfälle riskant ist, kann es über ein Flag aktiviert werden, um das Upgrade zu steuern.

Dies ist sehr riskant, da sich der Cluster nach einem fehlgeschlagenen Upgrade möglicherweise in einem unbekannten Zustand befindet. Daher kann Helm möglicherweise nicht sauber vorgehen, was möglicherweise zu Ausfallzeiten der Anwendung führen kann.

Ich denke, viele Helmbenutzer verwenden das Ruder automatisiert über ein CD- oder CM-Tool, und es ist riskanter, die Helmfreigabe in einem FEHLGESCHLAGENEN Zustand zu belassen. Diese unvollständigen Ressourcen in einer fehlgeschlagenen Version können sich unerwartet auf andere Ressourcen auswirken und selbst Ausfallzeiten verursachen. Wenn die Pod-Spezifikation beispielsweise eine fehlende Image-Version enthält, die es irgendwie in die Produktion geschafft hat, befindet sich Ihre Workload in einem nicht funktionierenden ImagePullBackOff-Status. Für unser Unternehmen ist es noch schlimmer, da wir einige lokale Kunden haben, die sich über unsere Benutzeroberfläche selbst aktualisieren können. Wenn dies fehlschlägt, müssen wir zum Debuggen Zugriff auf ihr System erhalten.

Selbst wenn die Tatsache nicht berücksichtigt wird, dass dieses Problem behoben werden könnte, wäre das automatische Rollback eine nützliche Funktion und würde dazu beitragen, dass Helm-Releases eher transaktionaler Natur sind. Es dreht Helm von Best-Effort-Bereitstellungen zu Prioritäten für Stabilität und erfolgreiche Bereitstellungen.

@bacongobbler wäre der folgende Ansatz für neue Bereitstellungen sinnvoll:

• Fügen Sie eine Flagge hinzu - -three-way-merge
• Erlaube nur, dass dieses Flag in einer helm install (neue Bereitstellung) verwendet wird.
• Sobald dieses Flag aktiviert ist, wird für das Upgrade immer eine 3-Wege-Zusammenführung verwendet
• Bestehende Bereitstellungen würden ohne einen Migrationspfad hängen bleiben - die Standardumgehung, die anscheinend zu diesem Zeitpunkt verwendet wird, ist helm delete --purge gefolgt von helm reinstall sodass dies möglicherweise nicht so unangenehm ist, wie es zunächst erscheint.

Würde dies das Problem tatsächlich lösen?

Einige Personen erwägen die Implementierung eines Operators, um diese Helm-Einschränkung zu umgehen. Das wäre eine ernsthafte Schande. Siehe https://github.com/istio/istio/issues/8841#issue -361871147

Prost
-steve

Zurück zu @bacongobblers früherem Kommentar:

1. Wenn wir während eines Upgrades eine neue Ressource erstellen und feststellen, dass diese bereits vorhanden ist, wenden wir diese Änderungen stattdessen auf die vorhandene Ressource an oder löschen / erstellen sie neu.
   Dies ist äußerst riskant, da Helm möglicherweise Objekte löscht, die über andere Pakete oder über kubectl create installiert wurden und von denen keiner Benutzer dies wünscht.

Ich frage mich, ob wir dieses Risiko mindern können, indem wir das neue Verhalten aktivieren. Innerhalb eines bestimmten Namespace verwende ich im Allgemeinen ausschließlich das Ruder, und ich vermute, dass dies bei vielen der Fall ist. Wenn ich Helm ein Flag zum Installieren / Aktualisieren geben könnte, um ihm mitzuteilen, dass alles im angegebenen Namespace, das nicht Teil einer vorhandenen Version ist, in Ordnung zum Löschen / Überschreiben ist, würde das helfen?

Da Sie auch "über andere Pakete" gesagt haben, möchten Sie vermutlich nicht, dass Helm andere Releases im Rahmen der Durchführung eines Releases untersuchen muss, sodass mein Vorschlag nur im Single-Release-per-Namespace-Modell funktioniert. Um auf diesen Einwand zu antworten, würde ich sagen: Wenn Sie mehrere Pakete in einem Namespace verwalten und dennoch dieses Verhalten erhalten möchten, erstellen Sie ein Umbrella-Diagramm, dessen einziger Zweck darin besteht, die gewünschten Diagrammabhängigkeiten anzugeben. Verwenden Sie dann das neue Flag ("--exclusive"?), Wenn Sie dieses Schirmdiagramm bereitstellen.

Dies löst das Problem natürlich nicht für alle Anwendungsfälle, aber vielleicht reicht es aus, um es zu umgehen.

@ Bacongobbler Ich könnte hier weit weg sein. Ich habe ähnliche Probleme beim Upgrade. Wenn man bedenkt, wie schwierig es ist, dieses Problem zu lösen, frage ich mich, ob etwas grundlegenderes überdacht werden muss. Ein Teil der Komplexität scheint auf die Tatsache zurückzuführen zu sein, dass Helm seine eigene Version der bekannten Konfiguration beibehält, die von der eigentlichen Wahrheitsquelle, den Kubernetes, getrennt ist. Wäre das System zuverlässiger, wenn Helm nur eine Kopie der zuvor bereitgestellten Helmkarten zum Zwecke des Verlaufs und des Rollbacks aufbewahren würde, diese jedoch während des Upgrades überhaupt nicht verwenden würde. Stattdessen würde Helm die Wahrheit von Kubectl selbst erfahren und dann immer einen 2-Wege-Diff ausführen?

Wenn ein Helmdiagramm angibt, dass es Ressource X haben soll, und kubectl eine vorhandene Ressource X sieht, dann:

• Wenn die vorhandene Ressource als von Helm gesteuert markiert ist, führt Helm das erforderliche Upgrade durch
• Wenn die vorhandene Ressource nicht als von Helm gesteuert markiert ist, schlägt Helm mit einer sauberen Fehlermeldung fehl (oder ein Befehlszeilenflag kann verwendet werden, um das Upgrade zu erzwingen und Helm zu veranlassen, den Besitz der vorhandenen Ressource X zu übernehmen).

Wenn das Helmdiagramm besagt, dass es Ressource X haben sollte und es laut kubectl keine gibt, erstellt Helm sie.

Wenn kubectl meldet, dass eine Ressource Y als von diesem Helmdiagramm gesteuert markiert ist und in diesem Helmdiagramm keine Ressource Y vorhanden ist, löscht der Helm die Ressource.

Alle Ressourcen, die nicht als von diesem Helmdiagramm gesteuert markiert sind, werden beim Ausführen des Upgrades immer vom Helm ignoriert, außer in dem oben erwähnten Fall, in dem das Helmdiagramm angibt, dass Ressource X und X vorhanden sind, aber nicht markiert sind.

Wenn aus irgendeinem Grund das Roll-out eines Helmdiagramms erfolgt und fehlschlägt und nur die Hälfte der Ressourcen ausgerollt wurde, würde während eines Rollback-Helms die gespeicherten Konfigurationsdateien aus der vorherigen erfolgreichen Bereitstellung verwendet und genau denselben Algorithmus oder dieselben Dinge ausgeführt könnte in einem defekten Zustand relativ zu einem Steuerbefehlszeilenflag belassen werden. Wenn der Benutzer erneut versucht, ein Upgrade durchzuführen, sollte Kubernetes als Quelle der Wahrheit und nicht als letzte bekannte erfolgreiche Bereitstellung verwendet werden, und es sollte dennoch ein einfacher Zwei-Wege-Unterschied zwischen dem neuen Helmdiagramm und dem vorhandenen Status des Systems bestehen.

Wir sehen auch dieses Problem. Unsere Reproduktionsschritte:

1. helm install ein Diagramm, das eine Bereitstellung erfolgreich installiert
2. Aktualisieren Sie das Diagramm so, dass es zusätzlich zur vorhandenen Bereitstellung eine benutzerdefinierte Ressource enthält
3. Ändern Sie das Image der Bereitstellungs-Podspezifikation, um einen Bereitstellungsfehler nachzuahmen
4. helm install neues Diagramm. Dies führt zu einem fortlaufenden Update der Bereitstellung, das wir absichtlich so eingerichtet haben, dass es fehlschlägt.
5. Die Helminstallation sollte fehlschlagen. Die benutzerdefinierte Ressource sollte jedoch in k8s etcd belassen werden. (Überprüfen Sie dies mit kubectl )
6. (Zu diesem Zeitpunkt ist das Ruder in einem schlechten Zustand)
7. Korrigieren Sie das Diagramm - fügen Sie ein Goot-Image in die Bereitstellungs-Podspec ein.
8. helm install . Wir erwarten, dass dies funktioniert, aber es funktioniert nicht. Meldet die Meldung "Keine Ressource mit dem Namen ___". Der Name ist der der benutzerdefinierten Ressource.
9. Wiederherstellung: Löschen Sie die verbleibende benutzerdefinierte Ressource mit kubectl . Jetzt wird helm install funktionieren.

Beachten Sie, dass der erste Versuch von helm install mit einer neu eingeführten benutzerdefinierten Ressource im Diagramm nicht in diesen Status gelangen darf.

@ rbair23 wir haben das früher versucht und das hat nicht funktioniert. Es gibt die Apply Working Group, die versucht, den Status der deklarativen Objektverwaltung zu

Da # 3275 als Duplikat davon geschlossen wurde: Wir haben eine ähnliche Situation wie in # 3275

Es gibt bereits einen laufenden Job my-long-running-job . Und wir versuchen, die Version zu aktualisieren:

>helm upgrade --install my-release --namespace my-environment my-chart --timeout 60
Error: UPGRADE FAILED: no Job with the name "my-long-running-job" found

Der Job existiert:

>kubectl -n=my-environment get jobs
NAME                                DESIRED   SUCCESSFUL   AGE
my-long-running-job                 1         0            16m

Diesen Job löschen:

>kubectl -n=my-environment delete job my-long-running-job
job.batch "my-long-running-job" deleted

Behebt dieses Hindernis:

>helm upgrade --install my-release --namespace my-environment my-chart --timeout 60
Error: UPGRADE FAILED: timed out waiting for the condition

Zumindest die Meldung no Job with the name "my-long-running-job" found ist irreführend, aber ich hatte erwartet, dass der Job auch aktualisiert wird.

Dies wird immer noch in Version 2.9.1 angezeigt (derzeit veröffentlichte stabile Version).

Ich bin nicht der Meinung, dass es "sehr gefährlich" ist, von einem Upgrade zurückzutreten. Ich denke, dies ist die richtige Lösung.

Kubernetes ist deklarativ. Erstellen Sie eine Momentaufnahme des Clusterstatus, bevor Sie versuchen, ein Upgrade durchzuführen.
Wenn auf halbem Weg ein Fehler auftritt, kehren Sie zum Schnappschuss zurück.
Wenn jemand Skript-Hooks hat, die den Cluster dabei in einem schlechten Zustand belassen würden, ist dies seine eigene Schuld. (Vielleicht könnte das auch mit Rollback-Haken gelöst werden)

Natürlich wäre es großartig, wenn ein Upgrade vor dem Flug durchgeführt würde und nicht so viel wie möglich eingereicht würde.
Fehler in Abhängigkeitsdiagrammen, die durch Werte oder --set-Argumente generiert wurden, sollten überprüft werden können, bevor beispielsweise versucht wird, Änderungen vorzunehmen. Dinge wie das Vergessen, die Versionsnummer zu erhöhen, können auch vorab geflogen werden, um Änderungen zu vermeiden, wenn dies nicht funktioniert.

Hallo,

Hatte das gleiche Problem mit:

Client: v2.10.0 + g9ad53aa
Server: v2.10.0 + g9ad53aa

Das Löschen von serviceAccount, configMap und service war die einzige Möglichkeit, Helm dazu zu bringen, die Version zu aktualisieren.

Hallo,

Wir haben das gleiche Problem wie @dilumr beschrieben ... mit Version 2.11.0:

Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}

Error: UPGRADE FAILED: no ConfigMap with the name "xxx" found

Bin auf v2.9.1 darauf gestoßen.

Bei dem von mir ausgeführten Diagramm-Upgrade wurden einige Hauptversionen in einem privaten Diagramm mit vielen Änderungen übersprungen, sodass ich nicht sicher bin, was genau den Fehler in der Zukunft ausgelöst hat, aber der Grund, warum die Bereitstellung ursprünglich im Status FAILED endete war, dass ich eine --wait Flagge hatte und es eine Zeitüberschreitung gab.

Am Ende hatten wir mehrere doppelte FAILED Bereitstellungen in helm list aber die letzte funktionierende Bereitstellung war DEPLOYED . Das Erstellen neuer Bereitstellungen warf No resource with the name x found .

Konnte behoben werden, indem ein helm rollback auf die letzte Version ausgeführt wurde, die sich im Zustand DEPLOYED auf helm list . Nach diesem Upgrade konnte das fehlerfrei ausgeführt werden.

Überprüfen Sie dies unter https://github.com/helm/helm/pull/4871.

Wie andere aus der Sicht der Dinge scheint dieser Fehler bei mir am häufigsten aufzutreten (ich bin mir nicht immer sicher), wenn meine letzte Bereitstellung fehlgeschlagen ist und neue Assets aus dieser Bereitstellung installiert bleiben.

Ich verstehe, wie schwierig und / oder unerwünscht es sein kann, Komponenten von einer fehlgeschlagenen Helmbereitstellung zu deinstallieren, aber was ist das ideale Helmverhalten für diese Art von Situation?

Erstens denke ich, dass Helm mit bereits vorhandenen Namespaces und anderen Ressourcen in Ordnung sein sollte, wenn versucht wird, diese (neu) zu installieren. Bei Kubernetes geht es darum, "die Konfiguration richtig zu machen und Kube herauszufinden, wie die Welt mit der Konfiguration übereinstimmt".
Zweitens denke ich, Helm sollte alles oder nichts sein. Wenn eine Bereitstellung fehlschlägt, sollte sich der Cluster in dem Zustand befinden, in dem er sich vor dem Start der Bereitstellung befand.
Wenn es zwei Releases gibt, die beide den Namespace X erstellen möchten, liegt ein Problem mit der Referenzzählung vor. Wenn es eine Version gibt, die den Namespace X erstellen möchte, diese aber bereits vorhanden ist, liegt ein Herkunftsproblem vor. Das Ruder kann dies jedoch mithilfe von Anmerkungen zu den Objekten aufzeichnen und das Richtige tun.

Ich stoße auch auf dieses Problem mit dem neuesten Helm 2.12.0 und kubernetes 1.10.11. Selbst das Zurücksetzen auf die neueste gute Version, wie @aguilarm vorgeschlagen hat, hat nicht funktioniert. Auch das Löschen der Ressourcen, über die sich der Helm beschwert, hilft nicht und nach dem Upgrade Wenn der Befehl fehlschlägt, bleiben dieselben Ressourcen übrig, die tatsächlich teilweise neu erstellt wurden. Sehr nervig für einen Prod env ...

Ich habe 2 Cluster mit sehr ähnlicher Umgebung, wobei der Hauptunterschied zwischen den 2 die Gesamtzahl der Knoten ist. In einem Fall funktionierte ein helm delete --purge gefolgt von einem neuen helm install , in einem anderen Fall jedoch nicht, und ich muss noch einen Weg finden, dies auf die neuesten Vorlagenänderungen zu übertragen.

Gibt es eine ETA dazu?

Ich konnte dies mit helm rollback umgehen und die letzte Revision angeben (die fehlgeschlagene).

Hatte heute das gleiche Problem,
Error: UPGRADE FAILED: no Service with the name "xxx-api" found
kubectl get svc -n stage | grep xxx-api
xxx-api ClusterIP 172.20.149.229 <none> 8300/TCP 19h
helm rollback funktioniert.

Wir erleben dies ziemlich regelmäßig, während wir Helm-Upgrades durchführen - dies geschieht nach erfolgreichen Bereitstellungen, nicht nur nach fehlgeschlagenen. Wir können das Löschen von --purge nicht steuern, da dies Produktionssysteme mit nicht trivialen Komponenten sind, die 1) nicht nicht verfügbar sein können und 2) zu lange dauern würden, um vollständig von Grund auf wiederhergestellt zu werden, um akzeptabel zu sein.

Siehe die Diagnose und Problemumgehung, die ich oben veröffentlicht habe. Lassen Sie mich wissen, ob das für Sie funktioniert.

@bacongobbler Danke für die Antwort. Das ist in der Tat die Problemumgehung, die ich mir auch ausgedacht habe, und sie muss vorerst ausreichen, aber wir verwenden Dutzende Male am Tag Steuer-Upgrades über unser CICD, sodass dies oft genug auftritt, um Kopfschmerzen zu verursachen. Ich bin mir nicht sicher, ob das oben Genannte die ganze Geschichte ist, da die genannten Ressourcen häufig bereits vorhanden sind, Teil einer erfolgreichen Bereitstellung sind und in der aktuellen Bereitstellung nicht geändert werden. Es handelt sich jedoch fast immer um die neuesten Ressourcen in der letzten erfolgreichen Bereitstellung obwohl interessanterweise.

+1 an @ajcann und danke @bacongobbler
Ich bin in genau der gleichen Situation.
Unser CICD ist automatisiert und wird häufig von einem Slack-Bot für niedrigere Umgebungen bereitgestellt.
Wenn dies fehlschlägt, muss ich das Helm-Rollback manuell durchführen und erneut bereitstellen.
Das Problem ist überhaupt nicht konsistent, aber häufig.
Für mich geschieht dies bisher nur während der zweiten Bereitstellung des Diagramms / der Ressource.
Ressourcen sind immer vorhanden.

Wir beobachten das gleiche Problem. Es passiert, wenn Sie eine Vorlage haben, die entweder:

• in einer {{if $condition -}} -Anweisung
• oder in einem {{ range $index, $value := $array-}}

@jkroepke hat mich gerade darauf hingewiesen, dass PR # 5143 eine gute --atomic in der nächsten Nebenversion freigegeben wird, sollten Sie es verwenden können, um bei einem Fehler automatisch zu bereinigen oder zurückzusetzen.

@bacongobbler Wenn Sie sich mit dem größten Teil des Hin und Her befasst haben, gibt es noch etwas, das getan werden kann, um dies vollständig zu beheben, oder würde das Flag --atomic ausreichen?

Ich denke, @distorhead möchte sich das vielleicht ansehen und sehen, ob es auch seine Bedenken löst, die er unter https://github.com/helm/helm/pull/4871 geäußert hat --atomic Problem lösen, vorausgesetzt, Sie verwenden immer das Flag --atomic .

Ich glaube nicht, dass es Lösungsvorschläge gegeben hat, um das Problem zu lösen, wenn Sie in diesen bestimmten Zustand geraten, aber ich könnte mich irren. Wenn die Minderungsstrategie für dieses Problem lautet

• Gehen Sie den Live-Status des Clusters manuell durch und beheben Sie ihn gemäß der Problemumgehung
• Aktualisieren Sie auf Helm 2.13.0 und verwenden Sie zukünftig helm upgrade --atomic

Dann denke ich, dass dies sicher zu schließen ist.

Hoffentlich ist Helm 2.13.0 nicht so weit weg.
Dieser Fehler unterbricht CI, wenn irgendwo in einer Version ein Fehler aufgetreten ist.

Atomic wird das Problem nicht lösen

Beispieldiagramm: https://github.com/distorhead/ex-helm-upgrade-failure

1. Überprüfen Sie den Master und führen Sie die Bereitstellung aus.

git clone https://github.com/distorhead/ex-helm-upgrade-failure
cd ex-helm-upgrade-failure
helm upgrade --atomic --install --namespace myns myrelease .

Das Diagramm enthält zwei Bereitstellungen - myserver1 und myserver2 :

Release "myrelease" does not exist. Installing it now.
NAME:   myrelease
LAST DEPLOYED: Tue Feb  5 23:48:57 2019
NAMESPACE: myns
STATUS: DEPLOYED

RESOURCES:
==> v1beta1/Deployment
NAME       READY  UP-TO-DATE  AVAILABLE  AGE
myserver1  1/1    1           1          5s
myserver2  1/1    1           1          5s

1. Machen Sie bahnbrechende Veränderungen. Löschen Sie die Bereitstellung myserver1 aus dem Diagramm und ändern Sie die Bereitstellung myserver2 mit einem Benutzerfehler (löschen Sie beispielsweise das Bildfeld):

git checkout break-atomic
git diff master

diff --git a/templates/deploy.yaml b/templates/deploy.yaml
index 198516e..64be153 100644
--- a/templates/deploy.yaml
+++ b/templates/deploy.yaml
@@ -1,21 +1,5 @@
 apiVersion: apps/v1beta1
 kind: Deployment
-metadata:
-  name: myserver1
-spec:
-  replicas: 1
-  template:
-    metadata:
-      labels:
-        service: myserver1
-    spec:
-      containers:
-      - name: main
-        command: ["/bin/bash", "-c", "while true ; do date ; sleep 1 ; done"]
-        image: ubuntu:16.04
----
-apiVersion: apps/v1beta1
-kind: Deployment
 metadata:
   name: myserver2
 spec:
@@ -28,4 +12,3 @@ spec:
       containers:
       - name: main
         command: ["/bin/bash", "-c", "while true ; do date ; sleep 1 ; done"]
-        image: ubuntu:16.04

1. Führen Sie die Bereitstellung aus:

git checkout break-atomic
helm upgrade --atomic --install --namespace myns myrelease .

Sag noch einmal Hallo zu unserem Freund:

UPGRADE FAILED
ROLLING BACK
Error: Deployment.apps "myserver2" is invalid: spec.template.spec.containers[0].image: Required value
Error: no Deployment with the name "myserver1" found

@bacongobbler @ thomastaylor312 @jkroepke

@distorhead Was war Ihr erwartetes Verhalten für dieses Szenario?

Etwas über Rollbacks, aber trotzdem.

Für diejenigen Personen, die Rollback verwenden möchten, aber aus bestimmten Gründen nicht möchten, dass das Rollback unmittelbar nach der Bereitstellung wie in --atomic . Zum Beispiel gibt es für den Benutzer keine Möglichkeit, den fehlerhaften Clusterstatus nach einem Fehler manuell zu überprüfen, und weil das Flag --wait nicht dazu führt, dass das Ruder Informationen über Fehler in den bereitgestellten Ressourcen protokolliert. Dann gibt es eine Möglichkeit: Rollback beim nächsten Lauf vor dem Upgrade (weitere Informationen unter https://github.com/helm/helm/issues/3149#issuecomment-462271103)

So wiederholen Sie das Problem sowie die Problemumgehung:

Wenn ein Upgrade, bei dem neue Ressourcen installiert werden, fehlschlägt, wechselt die Version in den Status FAILED und stoppt den Upgrade-Prozess. Wenn Sie das nächste Mal helm upgrade aufrufen, unterscheidet sich Helm von der letzten DEPLOYED-Version. In der letzten Version von DEPLOYED war dieses Objekt nicht vorhanden, daher wird versucht, die neue Ressource zu erstellen, dies schlägt jedoch fehl, da es bereits vorhanden ist. Die Fehlermeldung ist völlig irreführend, wie @arturictus hervorhebt .

Dies kann 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 # 4223 (Kommentar) demonstriert habe:

><> helm fetch --untar https://github.com/helm/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml                    # change the service name from "foo" to "foo-bar"
><> kubectl create -f foo/templates/service.yaml      # create the service
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

Mit anderen Worten, das Löschen von Ressourcen, die während der FAILED-Version erstellt wurden, umgeht das Problem.

Vielen Dank, dass Sie diese Problemumgehung @bacongobbler zusammengestellt

Sie könnten ein Plugin ähnlich helm diff schreiben, das die in der letzten Version erstellten Vorlagen auflistet. Sie könnten sogar pkg/kube direkt von Helm konsumieren. client.Update hat eine Geschäftslogik für die Ressourcenverfolgung / -löschung des target.Difference(original) sollte Ihnen ein Ergebnis aller Ressourcen liefern, die seit der vorherigen Version eingeführt wurden.

@bacongobbler Welche Lösung würden Sie empfehlen, um eine Anwendung, die als Teil von Release A bereitgestellt wird (z. B. eine größere Version, die aus mehreren Anwendungen besteht), aus Release A in eine eigene Version aufzuteilen (oder umgekehrt), ohne Ausfallzeiten zu verursachen (Die Problemumgehung zum Löschen von Ressourcen würde zu Ausfallzeiten führen.) ... Der Versuch, eine Ressource über eine andere Version zu aktualisieren, führt zu dem Fehler, der in diesem Github-Problem beschrieben wird.

Es klingt so, als ob dieses neue Diagramm installiert wurde und die alten Diagramme ersetzt, noch bevor eine erfolgreiche Bereitstellung erfolgt. Gleiches gilt für ein fehlgeschlagenes Upgrade --install. Es sollte nicht installiert werden, wenn das Diagramm falsch ist.
Bei Fehler einfach auf den vorherigen Status zurücksetzen oder die Pinnen-Diagramme bei Erfolg aktualisieren.

Dies ist ein Prozess, mit dem ich dieses Problem behebe (bisher hat es jedes Mal ohne Zwischenfälle funktioniert ... aber seien Sie trotzdem vorsichtig):

1. Führen Sie helm list und finden Sie die neueste Version für das betroffene Diagramm heraus

   NAME        REVISION UPDATED                  STATUS  CHART              NAMESPACE
   fetlife-web 381      Thu Mar 15 19:46:00 2018 FAILED  fetlife-web-0.1.0  default
   

2. Gehen Sie von dort aus und finden Sie die neueste Version mit dem Status DEPLOYED
kubectl -n kube-system edit cm fetlife-web.v381 kubectl -n kube-system edit cm fetlife-web.v380 kubectl -n kube-system edit cm fetlife-web.v379 kubectl -n kube-system edit cm fetlife-web.v378
3. Wenn Sie die letzte Version von DEPLOYED gefunden haben, ändern Sie den Status von DEPLOYED in SUPERSEDED und speichern Sie die Datei
4. Versuchen Sie erneut, helm upgrade machen. Wenn dies erfolgreich ist, sind Sie fertig!
5. Wenn ein Upgrade-Fehler wie folgt auftritt:
   Error: UPGRADE FAILED: "fetlife-web" has no deployed releases
   Bearbeiten Sie dann den Status für die letzte Überarbeitung von FAILED auf DEPLOYED
kubectl -n kube-system edit cm fetlife-web.v381
6. Versuchen Sie erneut, helm upgrade machen. Wenn dies erneut fehlschlägt, drehen Sie einfach den Tisch um ...

@bacongobbler @michelleN
Gibt es irgendetwas, das es schwierig macht, die Fehlermeldung für dieses Problem zu verbessern?

Ich glaube, die Fehlermeldung sollte besagen, dass "ein Konflikt vorliegt, weil die Ressource nicht vom Ruder erstellt wurde und manuelle Eingriffe erforderlich sind" und nicht "nicht gefunden". Nur diese kleine Änderung des Fehlers verbessert die Benutzererfahrung um ein gutes Stück.

@selslack Ich würde mich sehr für eine Verbesserung der Fehlermeldung 👍 aussprechen

@michelleN Ich habe eine PR vorbereitet, um den Fehlertext zu ändern: # 5460.

Ich habe dieses Problem und bin in einer Situation, in der ich nicht sicher bin, wie ich es beheben soll.

Ich habe alle von @reneklacan hier aufgeführten ausprobiert : https://github.com/helm/helm/issues/1193#issuecomment -470208910

Das hat leider nicht funktioniert. Das einzige, was das Problem behebt, ist das Löschen der Ressource, die die Fehlermeldung generiert, und dann erneut helm upgrade , was erfolgreich sein wird.

Das nächste Helm-Upgrade schlägt jedoch mit demselben Fehler fehl, und ich muss die Ressource erneut löschen und erneut aktualisieren ... dies ist weder nachhaltig noch gut.

Ich habe zwei Umgebungen, in denen ich mithilfe des Helms als Teil unseres CI-Prozesses bereitstelle: eine Qualitätssicherung und eine Produktionsumgebung.

Die QS-Umgebung hatte das gleiche Problem, also habe ich helm delete --purge und dann helm upgrade - das Problem wurde dauerhaft behoben.

Ich kann dies jedoch nicht für die Produktionsumgebung tun. Ich kann es nicht einfach löschen und erneut aktualisieren. Daher kann ich die Ressource derzeit vor jeder Bereitstellung nicht mehr löschen. Ich bin nur glücklich, dass es keine Importressource ist.

@ Zacharyw Welchen Fehler haben Sie im Moment? No resource with the name ... oder "fetlife-web" has no deployed releases ?

Können Sie zusätzliche Informationen teilen, die beim Debuggen helfen könnten?

Möglicherweise Ausgabe von kubectl -n kube-system describe cm -l NAME=YOUR_RELEASE_NAME | grep -A1 STATUS= (ersetzen Sie YOUR_RELEASE_NAME )

Sie können mir gerne eine E-Mail mit weiteren Informationen senden, wenn Sie dieses Problem nicht mit potenziell nicht verwandten Daten (rene (at) klacan (dot) sk) spammen möchten.

Eine mögliche Diagnose und Problemumgehung finden Sie unter https://github.com/helm/helm/issues/1193#issuecomment -419555433 unter @zacharyw.

@reneklacan Es ist der no resource with the name ... Fehler. In unserem Fall haben wir einen Ingress hinzugefügt, es hat anscheinend funktioniert, aber dann scheiterten nachfolgende Upgrades mit diesem Fehler ... obwohl der Ingress bereits vorhanden war.

Der Status meiner letzten Version (nach dem Löschen des fehlerhaften Eingriffs und dem erneuten Erstellen des Helm-Upgrades) ist DEPLOYED :

STATUS=DEPLOYED
VERSION=197

Wenn ich jedoch erneut versuchen würde, ein Upgrade durchzuführen, würde dies fehlschlagen.

@bacongobbler Wenn ich nicht falsch

@reneklacan in https://github.com/helm/helm/issues/1193#issuecomment -470208910 hat mir das Leben gerettet.

Es ist eine Enttäuschung, dass Helm auf diese Weise versagt. Das Löschen von Dingen in nahezu jeder Umgebung ist alles andere als ideal.

Es wäre großartig, wenn helm seine eigene Datenbank aktualisieren würde, wenn diese Art von Fehler auftritt, und es dann erneut versuchen würde.

Ich glaube, dass mit dem aktivierten Flag --cleanup-on-fail dieser Fehlerfall verschwinden sollte. Schließen wie gelöst über # 4871 und # 5143.

Wenn weitere Probleme ohne diese Flags auftreten, öffnen Sie bitte ein neues Problem. Vielen Dank!

Das Problem ist geschlossen, da ich mir überlegt habe, einen Kommentar zum Umgang mit dem Problem hinzuzufügen, ohne die Steuerfreigabe oder die ausgeführten Bereitstellungen löschen zu müssen.

Also habe ich das Problem mit den folgenden Schritten reproduziert:

1. Installieren Sie das Diagramm test-chart-failure mit einer Servicevorlage.
2. Fügen Sie ein Unterdiagramm mit einer Dienstvorlage hinzu, die eine Zeichenfolge (z. B. "Test") im Port des Dienstes enthält
3. Aktualisieren Sie das Diagramm. Es wird mit dem Fehler Service in version "v1" cannot be handled as a Service: v1.Service.Spec: v1.ServiceSpec.Ports: []v1.ServicePort: v1.ServicePort.Port: readUint32: unexpected character: ... fehlschlagen

Ich konnte ein Upgrade durchführen, nachdem ich den Port auf eine Zahl korrigiert hatte, ohne helm delete auszuführen , indem ich den Vorschlag unter

1. Fand die fehlgeschlagene Revision mit helm history test-chart-failure
2. Löschte die Konfigurationszuordnung der spezifischen Revision mit kubectl delete cm -n kube-system test-chart-failure.v2
3. helm upgrade mit dem korrigierten Diagramm ausgeführt