<p>Helm-Upgrade --Installieren funktioniert nicht mehr</p>

Ich dachte, ich hätte das gleiche Problem, aber es stellte sich heraus, dass ich nur eine alte (aber nicht gelöschte) Veröffentlichung hatte. check helm list -a , und wenn dein Release dort ist, helm delete --purge releasename. helm upgrade -i funktioniert bei mir erfolgreich an 2.7.2.

Dies ist ein Nebeneffekt der Behebung von Problemen bei der Aktualisierung von Versionen, die sich in einem schlechten Zustand befanden. https://github.com/kubernetes/helm/pull/3097 war die PR, die dieses Problem behoben hat. Gibt es hier einen Randfall, den wir nicht erkannt haben?

Überprüfen Sie helm list -a wie @tcolgate erwähnt, und erklären Sie vielleicht auch, wie Sie es reproduzieren können, um festzustellen, ob es sich um einen nicht

Habe auch das gleiche Problem, zusammen mit doppelten Release-Namen:

$>helm ls -a|grep ingress
nginx-ingress               9           Thu Nov 30 11:33:06 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
nginx-ingress               11          Thu Nov 30 11:37:58 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
nginx-ingress               12          Thu Nov 30 11:38:50 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
nginx-ingress               8           Thu Nov 30 11:31:27 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
nginx-ingress               10          Thu Nov 30 11:33:53 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
$>helm diff nginx-ingress ./nginx-ingress
Error: "nginx-ingress" has no deployed releases

Welche Meldung wurde beim Upgrade angezeigt?

gleicher Fehler wie das obige Diff, aber eine Installation würde sagen, dass es bereits installiert war.

Ich meine, in den vorherigen Upgrade-Versuchen, die in einem FAILED-Status endeten. Ich möchte wissen, wie wir in die Situation kommen, in der alle Releases in einem gescheiterten Zustand sind.

Ohh, die doppelten Bereitstellungen des Releasenamens? Das bin ich mir nicht sicher, ich bekomme es ziemlich oft. Manchmal befinden sie sich alle im Zustand DEPLOYED, manchmal in einer Mischung aus FAILED und DEPLOYED. Wir verwenden einen CI/CD-Jenkins-Server, der ständig jeden PR-Merge aktualisiert, also tun wir mehrere helm upgrade 'pro Tag, normalerweise nur mit einem neuen Container-Tag. Normalerweise sind die Duplikate nur nervig, wenn man sich die Bereitstellung ansieht. Dies war das erste Mal, dass wir ein schweres Problem damit hatten, und normalerweise aktualisieren wir den Ingress-Controller nicht wie in diesem Fall.

Ich scheine mit etwas Ähnlichem gelandet zu sein, ich sehe ein paar Duplikate in meinen Veröffentlichungslisten:

$ helm ls
NAME                      REVISION    UPDATED                     STATUS      CHART                           NAMESPACE
.....
front-prod                180         Tue Dec  5 17:28:22 2017    DEPLOYED    front-1                         prod
front-prod                90          Wed Sep 13 14:36:06 2017    DEPLOYED    front-1                         prod 
...

Alle scheinen sich im Zustand DEPLOYED zu befinden, aber es könnte durchaus sein, dass ein früheres Upgrade irgendwann fehlgeschlagen ist, da ich diesen Fehler mehrmals getroffen habe. Ich bin immer noch auf K8S 1.7, habe also noch nicht auf Helm 2.7 aktualisiert.

Gleiches Problem, Upgrade über FEHLGESCHLAGENE Bereitstellung nicht möglich

Das gleiche hier mit 2.7.2. Der erste Versuch einer Freigabe war fehlgeschlagen. Als ich dann ein Upgrade versuchte --install habe ich den Fehler "Error: UPGRADE FAILED: "${RELEASE}" has no deployed releases" erhalten.

Gleiches Problem hier mit 2.7.2, helm upgrade --install schlägt fehl mit:

Error: UPGRADE FAILED: "APPNAME" has no deployed releases

Wenn die Freigabe vollständig mit helm del --purge APPNAME dann funktioniert ein nachfolgendes upgrade --install ok.

Ich habe das gleiche Problem. In Kombination mit #3134 lässt dies keine Option für automatisierte idempotente Bereitstellungen ohne Skripting zur Umgehung.

@winjer hat gerade versucht mit --purge zu löschen und bei mir hat es nicht funktioniert, obwohl sich der Fehler geändert hat
/ # helm upgrade foo /charts/foo/ -i --wait
Fehler: UPGRADE FEHLGESCHLAGEN: "foo" hat keine bereitgestellten Releases
/ # helm delete --purge foo
Release "foo" gelöscht
/ # helm upgrade foo /charts/foo/ -i --wait
Release "foo" existiert nicht. Installieren Sie es jetzt.
Fehler: Veröffentlichung von foo fehlgeschlagen: deploys.extensions "foo-foo-some-service-name" existiert bereits

@prein Dies liegt daran, dass Sie einen Dienst haben, der nicht "Eigentümer" von helm ist, sondern bereits im Cluster vorhanden ist. Das von Ihnen erlebte Verhalten scheint mir richtig zu sein. Die Bereitstellung kann nicht erfolgreich sein, da helm den Besitz eines API-Objekts übernehmen müsste, das er zuvor nicht besaß.

Es ist sinnvoll, ein FAILED-Release aktualisieren zu können, wenn das neue Manifest tatsächlich korrekt ist und nicht mit anderen Ressourcen im Cluster zufrieden ist.

Ich sehe dieses Verhalten auch bei einer Version namens content :

helm upgrade --install --wait --timeout 300 -f ./helm/env/staging.yaml --set image.tag=xxx --namespace=content content ./helm/content
Error: UPGRADE FAILED: no resource with the name "content-content" found
helm list | grep content
content                         60          Mon Dec 25 06:02:38 2017    DEPLOYED    content-0.1.0                   content           
content                         12          Tue Oct 10 00:02:24 2017    DEPLOYED    content-0.1.0                   content           
content                         37          Tue Dec 12 00:42:42 2017    DEPLOYED    content-0.1.0                   content           
content                         4           Sun Oct  8 05:58:44 2017    DEPLOYED    k8s-0.1.0                       content           
content                         1           Sat Oct  7 22:29:24 2017    DEPLOYED    k8s-0.1.0                       content           
content                         61          Mon Jan  1 06:39:21 2018    FAILED      content-0.1.0                   content           
content                         62          Mon Jan  1 06:50:41 2018    FAILED      content-0.1.0                   content           
content                         63          Tue Jan  2 17:05:22 2018    FAILED      content-0.1.0                   content           

Ich muss dies löschen, um die Bereitstellung fortsetzen zu können. Lassen Sie mich wissen, ob ich beim Debuggen helfen kann.
(Ich denke, wir sollten das Problem umbenennen, da es mehr um die Duplikate geht?)
(wir betreiben auch 2.7.2 )

Ich habe tatsächlich eine weitere doppelte Version auf meinem Cluster, wenn Sie einen Befehl haben, den ich ausführen kann, um das Debuggen zu unterstützen? Gib mir Bescheid!

gerade auf Tiller 2.7.2 aktualisiert und wir sehen das gleiche. helm delete RELEASE_NAME gefolgt von helm upgrade RELEASE_NAME . schlägt mit Error: UPGRADE FAILED: "RELEASE_NAME" has no deployed releases fehl. upgrade ist der beabsichtigte Weg, um eine gelöschte (aber nicht bereinigte) Version wiederherzustellen, richtig?

Anscheinend können Sie die Version wiederherstellen, indem Sie auf die gelöschte Version zurücksetzen.

das gleiche Problem mit v2.7.2 auftritt, schlägt fehl, wenn keine vorherigen erfolgreich bereitgestellten Versionen vorhanden sind

Sehen Sie auch zwei mögliche Versionen dieses Problems:

im CI:

+ helm upgrade --install --wait api-feature-persistent-data . --values -
+ cat
WARNING: Namespace doesn't match with previous. Release will be deployed to default
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
Error: UPGRADE FAILED: "api-feature-persistent-data" has no deployed releases

auf meinem lokalen Rechner:

(sowohl in meiner OSX-Bash als auch in einem gcloud/kubectl-Container)

+ helm upgrade --install --wait api-feature-persistent-data . --values -
+ cat
WARNING: Namespace doesn't match with previous. Release will be deployed to default
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
Error: UPGRADE FAILED: no PersistentVolumeClaim with the name "api-feature-persistent-data-db" found

Die Warnungen sind für unser Diagramm normal.
Die Fehler sind interessant, weil eines unserer Subcharts ein pvc.yaml .

helm del --purge <release> mildert das Problem.
Dies erschwert die Aktualisierung unserer CI-Pipeline.

@adamreese was ist die endgültige Lösung für dieses Problem? Wir sind auf 2.8 und können eine vorherige Version von FAILED mit der Änderung auf helm list immer noch nicht aktualisieren.

Insbesondere stoßen wir auf die folgenden Arten von Problemen:

• ein Release bereitstellen, OK
• upgrade --install --wait , aber vielleicht gibt es einen kleinen Fehler und --wait ist nicht erfolgreich (z.
• Nachdem das Diagramm repariert wurde, schlägt upgrade --install --wait mit xxx has no deployed releases fehl

Löschen/Bereinigen ist hier nicht wünschenswert oder akzeptabel: Die Version kann mehrere Ressourcen (Pods, Load Balancer) enthalten, die von der einen Ressource, die nicht hochgefahren wird, nicht betroffen sind. In früheren Helm-Versionen ermöglichte es uns upgrade --install , nur die Änderung zu patchen, die die vollständige Version beschädigte, ohne alle Ressourcen entfernen zu müssen.

Helm ist hier zu jeder Zeit Eigentümer aller beteiligten Ressourcen -- die Ressource ist nur mit FAILED weil es --wait nicht gelungen ist, darauf zu warten, dass alle Ressourcen in einem guten Zustand sind. Ich gehe davon aus, dass das gleiche passiert, wenn ein Pod etwas zu langsam zum Starten ist und in vielen ähnlichen Fällen.

@peay siehe #3353 für

Danke - das klärt es auf. Eigentlich haben wir gemerkt, dass wir es erst geschafft haben, als wir von Anfang an keine erfolgreiche Veröffentlichung hatten. In diesem Fall ist Purge eine gute Lösung.

Dies geschieht immer noch, wenn die Installation fehlschlägt.
Sie müssen es löschen und es erneut versuchen.

UPGRADE FAILED: "API" has no deployed releases
dann musst du manuell bereinigen
helm delete --purge API
und es wird funktionieren.

Ab Helm 2.9 können Sie auch helm upgrade --install --force ausführen, so dass keine Säuberung erforderlich ist. Für frühere Versionen:

helm delete API
helm install --replace --name API ./mychart

@bacongobbler Ich bin immer noch verwirrt über dieses Verhalten.
Könnten Sie https://github.com/kubernetes/helm/pull/3597#issuecomment -382843932 beantworten, wenn Sie Zeit haben?

Danke für deine Arbeit dazu.

Sicher. Ich bin im Moment AFK, kann aber heute Abend später antworten. Verstehen Sie die Verwirrung voll und ganz und ich werde versuchen, Ihre Fragen so gut wie möglich zu beantworten. Es ist einfach verrückt, im Büro andere Dinge für die KubeCon EU vorzubereiten. :)

Ich bin offen, um zu helfen, dies zu hacken und / oder die Dokumentation zu verbessern, wenn wir da draußen sind.
Treffen wir uns auf jeden Fall :+1:

@bacongobbler adressiert diese Nummer #3353 und negiert den Code, den ich als Teil von #4004 geschrieben habe?

In meinem Fall hat helm upgrade --install --force delete --purge und danach eine Installation.

Ist das das erwartete Verhalten? Ich habe deswegen fast 2 Monate Arbeit verloren. Wann hat force angefangen, delete zu bedeuten?

^ Ich habe mich mit Leuten von kubecon unterhalten und festgestellt, dass aufgrund dieser Verhaltensänderung ziemlich viele Teams an v2.7.0 angeheftet sind.

Ich stimme zu, dass upgrade install niemals destruktiv sein sollte, auch wenn --force jemals bedeuten könnte.

@bacongobbler , tut mir leid, dass ich mich nicht treffen konnte, als wir in CPH waren.
Gibt es eine Dokumentation hinter der Begründung für die Änderung des Verhaltens, um ein Upgrade einer fehlgeschlagenen Version nicht zuzulassen?
Das alte Verhalten scheint viel wünschenswerter zu sein als das, was wir jetzt haben.

Siehe den zweiten Kommentar in https://github.com/kubernetes/helm/issues/3353 für Hintergrundkontext, warum wir diese Änderung vornehmen mussten

Ich bin wirklich gespannt, was der vorgeschlagene Weg für die Zukunft ist. Wir können #3097 aufgrund der in #3353 demonstrierten Probleme nicht rückgängig machen, daher würde ich gerne hören, was die Community für den richtigen Weg zur Behebung dieses Problems hält. Wir können #3597 rückgängig machen, aber nach allem, was ich gehört habe, gibt es keine gute Lösung, um das helm upgrade --install Problem zu beheben. :enttäuscht:

Ich weiß, dass wir daran arbeiten, die Anwendungslogik für Helm 3 zu überarbeiten, aber das ist noch ein langer Weg

Danke fürs Verlinken von @bacongobbler :)
Ihr Vorschlag hier klingt nach einem vernünftigen Ansatz:

Es kann sinnvoll sein, keinen Diff durchzuführen, wenn keine erfolgreichen Releases bereitgestellt wurden. Die Erfahrung wäre die gleiche, als ob der Benutzer helm install zum allerersten Mal ausführen würde, in dem Sinne, dass es keine "aktuelle" Version geben würde, gegen die man sich unterscheiden könnte. Ich wäre jedoch ein wenig besorgt über bestimmte Randfälle. @adamreese hast du dazu irgendwelche

Dies würde es uns ermöglichen, #3597 rückgängig zu machen, da der einzige Fehlerfall (nichts zu unterscheiden) behandelt würde.
Dadurch wird upgrade --install wieder zerstörungsfrei und ähnlicher wie kubectl apply .

Intuitiv würde ich erwarten, dass ein upgrade --force das tut: keine Diff-and-Patch-Operationen durchführen, sondern einfach die komplette Vorlage anwenden und dabei ignorieren, was im Moment vorhanden ist. Ich kann mir keine wirklichen technischen Gründe vorstellen, warum dies nicht möglich wäre, aber ich kenne das Innenleben von Helm auch nicht.
Es kann immer noch eine gefährliche Operation sein, aber jeder, der ein --force Flag verwendet, erwartet normalerweise ein gewisses Risiko, indem er Updates erzwingt. Obwohl ich argumentieren würde, dass dies Ihre Bereitstellung mit potenziellen Ausfallzeiten nicht löscht und neu erstellt.

Ich habe die Diskussionen durchgelesen, aber mir ist immer noch nicht klar, wie man einen idempotenten upgrade --install Befehl (oder eine Befehlsfolge) verwendet.

Wie kann ich dies mit der aktuellen stabilen Version in einem automatisierten Skript erreichen? Ich muss in der Lage sein, nicht interaktiv bereitzustellen, ohne delete --purge , auch wenn ein vorheriger Versuch fehlgeschlagen ist.

Was zukünftige Pläne betrifft, so habe ich ursprünglich von upgrade --install erwartet:

• Installieren, wenn keine vorherigen Installationen vorgenommen wurden
• Upgrade einer zuvor erfolgreichen Installation
• Ersetzen Sie eine zuvor fehlgeschlagene Installation
• Wenn die Installation fehlschlägt, sollten die alten Ressourcen noch vorhanden sein, möglichst ohne Ausfallzeiten
• Keine destruktiven Operationen (wie das oben erwähnte automatische delete --purge )

Meiner persönlichen Meinung nach sollten für dieses Verhalten keine zusätzlichen Flags erforderlich sein. So verhalten sich Paketmanager im Allgemeinen. Sofern ich die Anforderungen nicht falsch verstanden habe, denke ich beispielsweise nicht, dass ein --force Flag notwendig ist.

Gab es diesbezüglich Neuigkeiten? Wie kann ein Upgrade einer bestehenden Installation zuverlässig ausgeführt werden, ohne dass eine Bereinigung ausgeführt werden muss, wenn etwas fehlschlägt?

@MythicManiac FWIW:
Ich habe unsere Teams aufgrund dieses Verhaltens immer noch auf v2.7.0 gepinnt.
Wir scheinen keine Probleme mit dem Aktualisieren und Löschen von Ressourcen zu haben, wenn diese mit dieser Version helm upgrade --install .

Dieses Problem haben wir auch. Es ist sehr ärgerlich, dass ich K8s-Dienste und zugehörige AWS-ELBs löschen muss, weil helm has no deployed releases . Der Paketmanager ist großartig, aber dieses Problem führt zu Produktionsausfallzeiten, was nicht gut ist.

Als sehr hackige Problemumgehung, wenn das Problem mit der Ursprungsbereitstellung ist
lösbar (z. B. bereits vorhandener Dienst.), Rollback auf das Original durchführen
fehlgeschlagene Freigabe kann funktionieren.

Am Freitag, den 5. Oktober 2018, 18:13 Uhr schrieb Eugene Glotov, [email protected] :

Dieses Problem haben wir auch. Es ist sehr ärgerlich, dass ich K8s löschen muss
Services und zugehörige AWS-ELBs, da helm keine bereitgestellten Releases hat. Der
Paketmanager ist großartig, aber dieses Problem führt zu Produktionsausfallzeiten, die
ist nicht gut.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/helm/helm/issues/3208#issuecomment-427436187 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AAEo8_pISzHFAuOz6Lsv5EjrFaEo_HkYks5uh5M7gaJpZM4Qtexz
.

@tcolgate , danke! Ich habe gerade ein weiteres Problem (https://github.com/helm/helm/issues/2426#issuecomment-427388715) mit Ihrer Problemumgehung behoben und werde versuchen, es auf vorhandene ELBs zu testen, wenn ich nächste Woche ein neues Diagramm über vorhandene Ressourcen bereitstelle .

Ein Rollback auf die ursprüngliche fehlgeschlagene Version kann funktionieren.

@tcolgate , habe ich gerade getestet und nein, es funktioniert nicht beim ersten Deployment.

$ helm upgrade --wait --timeout 900 --install myproject charts/myproject/myproject-1.1.1.tgz
14:53:18 Release "myproject" does not exist. Installing it now.
14:53:18 Error: release myproject failed: deployments.apps "myproject" already exists

$ helm list
NAME            REVISION    UPDATED                     STATUS      CHART               APP VERSION NAMESPACE
myproject       1           Mon Oct  8 11:53:18 2018    FAILED      myproject-1.1.1                 default

$ helm rollback myproject 1
Error: "myproject" has no deployed releases

Ich bin neugierig, wenn Helm kein Diagramm über vorhandene Ressourcen bereitstellen kann, warum also helm delete das Löschen genau dieser Ressourcen verursacht?

@thomastaylor312 , wir waren mit diesem Problem ~sowie https://github.com/helm/helm/issues/2426~ (up: Ich habe die wahre Ursache für 2426) mit helm 2.11.0 konfrontiert. Meinst du, sie sollten wieder geöffnet werden?

Ich habe diesen Thread nach einem Error: UPGRADE FAILED: "xxx-service" has no deployed releases
Während es von einem Helm aus sichtbar war, ls -a.

Ich beschloss, zu sehen, ob es ein Problem war, weil es einen falschen --set-Wert gab, und --debug --dry-run --force löschte tatsächlich IMMER NOCH meinen laufenden Pod ... meine Erwartung war, dass sich eine Probelauf-Aktion NIEMALS ändern würde Cluster-Ressourcen.

Es funktionierte zwar und der Dienst konnte danach neu bereitgestellt werden, aber wir hatten Ausfallzeiten.

Meine Erwartung war, dass eine Probelaufaktion NIEMALS Clusterressourcen ändern würde.

Dies ist eine faire Erwartung – wir sollten dafür sorgen, dass ... nicht passiert

Ich glaube, das wurde in https://github.com/helm/helm/pull/4402 gepatcht, aber es wäre schön, wenn jemand das überprüfen würde. Das tut mir leid!

gleiches Problem nach dem Upgrade auf 2.11.0

Querbeitrag:
https://github.com/reactiveops/reckoner/issues/48#issuecomment -453411283

Warum ist das geschlossen? Haben wir jetzt einen richtigen Weg, damit umzugehen?

@gerbsen , mit aktuellen Versionen von Helm führt kein Weg daran vorbei, der zerstörungsfrei ist.
Wir verwenden immer noch Helm 2.7.0 für alles in meiner Organisation. Es ist eine sehr alte Version, die andere Fehler aufweist, aber dieses Problem hat sie nicht.

Habe gerade helm upgrade --install --force delete --purge und meine PVC/PVC zerstören lassen, ohne es mir zu sagen (über Recycling). Hatte mehrere fehlgeschlagene Releases, also war es in einem Zustand, in dem es in Kubernetes lief, aber Helm dachte, es gäbe keine laufenden Releases. Überhaupt keine guten Zeiten.

@notque Nachdem ich zweimal das gesamte Grafana-Dashboard verloren habe, habe ich begonnen, Backups zu erstellen, bevor ich irgendeine Art von Upgrade durchführe, da dieses Risiko alle Vorteile der Verwendung von Helm beseitigt

Für diejenigen, die Hilfe suchen, war das Problem für mich nach dem Upgrade von Helm auf v.2.15.2 behoben

Dieses Problem wird immer noch bei 2.16.0

Warum ist es noch geschlossen? 2.16.1 ist immer noch betroffen

@nick4fake Ich denke, es ist ein Duplikat von https://github.com/helm/helm/issues/5595