Helm: `helm upgrade --install` führt keine Installation / Aktualisierung durch, wenn die erste Installation fehlschlägt

Dies war beabsichtigt durch das Design von https://github.com/kubernetes/helm/pull/3097. Grundsätzlich verursachte die Abweichung von einer fehlgeschlagenen Bereitstellung unerwünschtes Verhalten, insbesondere diese lange Liste von Fehlern:

• https://github.com/kubernetes/helm/issues/2257
• https://github.com/kubernetes/helm/issues/2341
• https://github.com/kubernetes/helm/issues/2346
• https://github.com/kubernetes/helm/issues/2437
• https://github.com/kubernetes/helm/issues/3068

Wenn Ihre erste Version in einem fehlgeschlagenen Zustand endet, empfehlen wir, die Version über helm delete --purge foo löschen und es erneut zu versuchen. Nach einer erfolgreichen ersten Version werden alle nachfolgenden fehlgeschlagenen Versionen ignoriert, und das Ruder führt einen Unterschied zur letzten bekannten erfolgreichen Version durch.

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

Die vorgeschlagene Korrektur scheint in einem automatisierten System völlig unhaltbar zu sein. Ich möchte definitiv nicht, dass alles, was helm aufruft, über "Wenn die erste Version fehlschlägt, löschen und erneut versuchen" Bescheid wissen muss. Zum einen wissen die meisten meiner Tools nicht, ob es sich um eine Installation oder ein Upgrade handelt oder ob es das erste oder 100. Mal ist, dass fast immer nur helm upgrade --install .

Ich möchte auch darauf hinweisen, dass ich die ursprüngliche PR https://github.com/kubernetes/helm/pull/3097#discussion_r151808599 kommentiert habe und speziell nach diesem Fall gefragt habe.

Das alte Verhalten war für diesen Fall besser.
Ich stimme @chancez zu. Dies macht upgrade --install für ein häufiges Vorkommen nicht idempotent.

@ Bacongobbler
Wenn wir uns Sorgen machen, dass Releases aufgrund fehlgeschlagener Hooks fehlschlagen und Splitter verlassen, würde ich sagen, dass dies ein Designproblem in der Tabelle ist. (Haken funktionieren besser, wenn sie idempotent sind)
Es steht den Benutzern frei, Fehlerbehandlung und nicht idempotentes Verhalten um das Ruder herum aufzubauen.

Um welche anderen Randfälle kümmern wir uns?
Scheint, dass die # 3097 sich um viel kümmert 👍

Meine lokale Entwicklung würde viel reibungsloser verlaufen, wenn ich helm upgrade -i selbst gegen fehlgeschlagene Releases für zumindest eine Kombination von Argumenten idempotent machen könnte. Mein Anwendungsfall ist, wenn ich ein Skript mit vielen Releases habe, von denen ich weiß, dass ich aufstehen möchte, um eine lokale Entwicklungsumgebung zu starten.

Dies könnte analog zum Flag --replace für helm install . Beachten Sie, dass --replace eines von nur zwei Flags von helm install ist, die in helm upgrade fehlen, das andere ist --name-template .

Um ganz klar zu sein, ja, das wäre eine gute Sache, um das Problem zu beheben. Möchte jemand eine Pause einlegen, während wir mit anderen Arbeiten alle Hände voll zu tun haben?

Hallo,
Ich habe eine PR https://github.com/kubernetes/helm/pull/3437 erstellt , die dieses Problem beheben soll

Ich bin mir nicht sicher, warum wir die Befehle install und upgrade benötigen. Ich verwende immer nur den Befehl upgrade --install und es scheint, als würden viele Leute dasselbe tun. Ich brauche nur einen Befehl, der upgrade --install und nicht über einen fehlgeschlagenen Lauf stolpert. Können wir einfach upgrade --install in deploy umbenennen, es wirklich idempotent machen und die anderen beiden fallen lassen?

(Ich habe mit einer neuen Variante dieses Problemverhaltens in 2.8.0 zu kämpfen. Seit dem Upgrade von 2.7.2 jetzt, wenn ich eine fehlgeschlagene Installation habe, und dann delete --purge it und upgrade --install it Ich kann immer noch den Fehler Error: UPGRADE FAILED: "xyz" has no deployed releases . Scheint, als ob --purge in 2.8.0 nicht voll wirksam ist und die Pinne einen festgefahrenen Zustand hat, der in list --all nicht angezeigt wird. Ich muss dann zu einem install , um die Pinne wieder in einen Zustand zu bringen, in dem ich wieder die üblichen upgrade --install machen kann.)

Ich stimme @whereisaaron zu , ich wäre nett mit einem deploy Befehl, der eher wie kubectl apply funktioniert. Erleichtert auch die Automatisierung von Helm erheblich, da Sie nicht nach Releases suchen müssen, die in einem Shell-Skript-Wahnsinn vorhanden sind :)

Vielleicht besteht die Lösung darin, dass das Ruder automatisch helm delete --purge ausführt?
So etwas wie:
1) Der Benutzer führt helm upgrade --install
2) Die erste Version schlägt fehl
3) Der Benutzer nimmt einige Änderungen am Diagramm vor und führt helm upgrade --install
4) Helm versucht den Befehl auszuführen
5) Es schlägt fehl und es gibt genau eine vorherige Version im fehlerhaften Zustand
6) Helm führt still helm delete --purge
6) Nach dem Löschen versucht Helm automatisch, helm upgrade --install auszuführen, und zeigt die Ausgabe davon an

Möglicherweise könnte dieses Verhalten über das Flag --force ausgelöst werden, das bereits ein ähnliches Verhalten für andere Szenarien aufweist

Gute Idee, aber ich denke nicht, dass wir jemals das Release-Ledger löschen sollten

Ich habe früher im Thread einen

@rchernobelskiy passiert mir auch. Genau so, wie Sie es beschreiben.

Dieses Problem tritt möglicherweise einmal pro Tag auf, wenn neue Apps bereitgestellt werden.
Es ist nervtötend!

@gmanolache Aus diesem Grund sind wir immer noch am Ruder 2.7.0.
Es ist mir unklar, ob ein Upgrade auf das Flag --force sicher ist: Kommentar

Wenn Sie ein Downgrade benötigen, ist dies eine gute Möglichkeit: Downgrade auf 2.7.0

Was sind diese nützlich klingenden Diagnoseinformationen für das Steuerbuch und wie kommen wir dazu? :Lächeln:

Ich mache mir Sorgen, dass das Folgende als launisch gelesen werden könnte. Es ist wirklich nur eine Einladung, um Hinweise zu erhalten, wie wir Diagnoseinformationen erhalten können, wenn Sie eine fehlgeschlagene Bereitstellung haben. Weil es wirklich so klingt, als würde mir etwas fehlen. Es hört sich so an, als ob der fehlgeschlagene Zustand ein Dienstprogramm für Bediener haben soll. Ich durchsuchte erneut die Handbuchseite des Ruders. Funktioniert so etwas wie "Helm wird manifest" in einem fehlgeschlagenen Zustand, um nützliche Diagnoseinformationen zu extrahieren?

Meine Benutzererfahrung, wenn ich eine fehlgeschlagene Bereitstellung erhalte, ist, dass Sie keine nützlichen Informationen erhalten. Helm lehnt alle teilweise erstellten / verbleibenden Ressourcen ab, sodass der "Helmstatus" nichts anzeigt. Alles, was Sie tun können, ist "Rollback" oder "Löschen - Löschen" (Sie können nicht einfach "Löschen" oder Ihr CI "Upgrade - Installieren" schlägt weiterhin fehl). Der fehlgeschlagene Zustand scheint nur dazu zu dienen, die Idempotenz von 'upgrade --install' zu brechen, nach der wir uns alle für unsere CI-Bereitstellungen sehnen.

Wäre es sinnvoll, eine Option "--auto-rollback" für CI-Situationen zu haben, z. B. "upgrade --install --auto-rollback"? Normalerweise würde ich lieber einen Rollback machen, der aus dem Bett muss, um mit einem fehlgeschlagenen Zustand fertig zu werden 😆 😴 💤

Was sind diese nützlich klingenden Diagnoseinformationen für das Steuerbuch und wie kommen wir dazu? 😄

helm help history

Danke @bacongobbler. Ok, ich verstehe, dass diese Liste das ist, was mit dem Hauptbuch gemeint ist. Und wenn Sie noch das Hauptbuch haben, können Sie mit helm get manifest --revision 123 sehen, was bereitgestellt wurde und was fehlgeschlagen ist? Das ist sicherlich nützlich zu bewahren. Und wenn wir rollback verlieren, verlieren wir diese Informationen nicht.

History prints historical revisions for a given release.

A default maximum of 256 revisions will be returned. Setting '--max'
configures the maximum length of the revision list returned.

The historical release set is printed as a formatted table, e.g:

    $ helm history angry-bird --max=4
    REVISION   UPDATED                      STATUS           CHART        DESCRIPTION
    1           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  Initial install
    2           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  Upgraded successfully
    3           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  Rolled back to 2
    4           Mon Oct 3 10:15:13 2016     DEPLOYED        alpine-0.1.0  Upgraded successfully

Wenn wir helm upgrade --install --auto-rollback hätten, würde sowohl die fehlgeschlagene Bereitstellung als auch das Rollback im Hauptbuch aufgezeichnet und den Betreibern zur Verfügung stehen. Dies würde einen großen Beitrag dazu leisten, zu verhindern, dass CI-Bereitstellungen in den unlösbaren Zustand "Fehlgeschlagen" gelangen, in dem "Helm-Upgrade - Installation" nicht mehr funktioniert. Fehlgeschlagene CI-Bereitstellungen sind normalerweise Entwickler, die Tippfehler / Fehler in das Bereitstellungssystem einfügen. Mit '--auto-rollback' können sie die Fehlermeldung des Befehls helm überprüfen, die im Protokoll des Bereitstellungsservers gespeichert ist, korrigierte Werte korrigieren und bereitstellen.

Ich denke, auch ohne die Option '--auto-rollback' könnten wir eine Wrapper-Automatisierung verwenden, um helm rollback jederzeit auszuführen, wenn helm update --install einen Fehler 'FAILED' zurückgibt. Und vielleicht erkennen Sie, wo es sich um die Erstinstallation handelt, und in diesen Fällen stattdessen helm delete --purge .

Das heißt, wir könnten ein Wrapper-Skript erstellen, um sicherzustellen, dass die Ergebnisse eines CI-Helm-Upgrades --install immer ein Zustand sind, in dem das nächste CI-Helm-Upgrade --install immer möglich ist. Unter Beibehaltung der Ledger-Informationen für fehlgeschlagene Versuche (zumindest für Releases, deren Erstinstallation funktioniert hat).

helm deploy =

• helm upgrade --install
• wenn FAIL dann
  
  
  
  • wenn Revision = 1
  
  
  • dann helm delete --purge
  
  
  • sonst helm rollback
  
  

@whereisaaron das wäre elegant 👍

Gibt es eine einfache Möglichkeit, die neueste Arbeitsversion zu erhalten, außer helm history ${name} | tail -2 | head -1 | awk '{print $1}' , die von helm rollback ?

Hallo,

Ich verwende Helm 2.12.2 und habe immer noch das Problem, dass der Helm fehlschlägt, wenn die erste Bereitstellung fehlschlägt. Ist das vielleicht eine Regression?

Ich bin nicht sicher, ob es sich um eine Regression handelt, aber dass sie nie wirklich "behoben" wurde.

@ RickS-C137 Ich denke, dies soll behoben werden, indem helm upgrade --install --force wird, wodurch eine fehlgeschlagene Version 'gelöscht' und dann 'installiert - ersetzt' wird.

Ich versuche immer noch, dieses Problem in einer Jenkins-Pipeline zu beheben, die ich verwenden möchte.
Ich versuche, ein neues Image meiner Anwendung bereitzustellen, und es ist mir egal, ob die Bereitstellung bereits vorhanden ist oder nicht.
Ich möchte einen Befehl ausführen, der entweder die aktuelle Bereitstellung ersetzt oder sie nur installiert, wenn sie nicht vorhanden ist.
Ich habe helm install --replace ausprobiert. Ich bekomme oft Error: a released named xyz is in use, cannot re-use a name that is still in use was offensichtlich meine Pipeline zerstört und der Build fehlschlägt.

@bacongobbler Was denkst du über https://github.com/helm/helm/issues/3353#issuecomment -385222233?

Ich sehe keine Ausfallzeiten oder Datenverluste, wenn wir die ursprüngliche Version zerstören und neu erstellen, wenn die erste Version fehlschlägt.

Ich habe dies in unserem Build implementiert:

if helm history --max 1 "$name" 2>/dev/null | grep FAILED | cut -f1 | grep -q 1; then
    helm delete --purge "$name"
fi

helm upgrade --install --wait "$release" chart/

Mit helm wissen Sie derzeit nicht, welche Kombination aus helmbefehl und Optionen verwendet werden soll, ohne den aktuellen Status zu überprüfen. Und für einen bestimmten Steuerbefehl wissen Sie nicht, was Sie bekommen werden, da dies vom aktuellen Status abhängt. Das ist nicht wirklich der deklarativ gewünschte Staatstraum ☁️ 💤 😄

In Ruder 3 können wir möglicherweise install / upgrade / --replace / --upgrade / --force ablehnen und sie alle durch ein idempotentes helm deploy ersetzen. oben . Wenn helm deploy fehlschlägt, wird ein Rollback (Revision> 1) oder Löschen + Löschen (Revision = 1) durchgeführt, um den Status wie zuvor zu belassen. Das fehlgeschlagene Manifest wäre weiterhin über helm history/get verfügbar. Und es könnte sogar eine "--no-rollback" -Option für Personen geben, die den Einsatz in einem fehlgeschlagenen Untersuchungszustand erhalten möchten

Die Option von helm upgrade --install --force rückt näher, mit der Ausnahme, dass nicht zurückgesetzt und aktualisiert, sondern fehlgeschlagene Releases gelöscht und ersetzt werden (auch bei Revisionen> 1), was einige Leute über # 3208 verärgert ... 😮 ⚡️ 💥

Im Moment können wir Wrapper-Skripte oder Meta-Tools wie helmsman deren Funktionsliste teilweise helm aber dieses Problem abmildern:

• Idempotenz : Solange sich Ihre gewünschte Statusdatei nicht ändert, können Sie Helmsman mehrmals ausführen und das gleiche Ergebnis erzielen. _ [... unabhängig vom aktuellen Zustand] _
• Fahren Sie mit Fehlern fort : Bei einer teilweisen Bereitstellung aufgrund eines bestimmten Fehlers bei der Kartenbereitstellung beheben Sie Ihr Helmdiagramm und führen Sie Helmsman erneut aus, ohne die teilweisen Erfolge zuerst zurücksetzen zu müssen.

Ersetzen Sie sie alle durch einen idempotenten Steuerstand, der entweder den gewünschten Status erreicht oder den Status unverändert lässt

Rückblickend ist dies ein atemberaubend offensichtliches Designziel.

Hallo,
In unserem Fall ist die erste Version nicht wirklich fehlgeschlagen ... Entweder war unsere Anwendung nach Ablauf des Installationszeitlimits nicht vollständig aktiv oder es wurde ein anderes seltsames Problem behoben. In jedem Fall läuft die Anwendung einwandfrei, und daher wäre es ein Problem für uns, sie löschen zu müssen (wir haben einen dauerhaften Speicher angehängt, der ebenfalls entfernt würde !!).

Gibt es eine Problemumgehung, um ein Diagramm bereitzustellen, wenn die erste Version "anscheinend fehlgeschlagen" ist, aber tatsächlich in Ordnung ist?

Ist die Schlussfolgerung also, dass upgrade --force zu kraftvoll ist, dh es gibt Zeiten, in denen ein Löschen + Ersetzen + erneutes Aktualisieren nicht das richtige Mittel ist, um ein fehlgeschlagenes Upgrade zu beheben?

Gibt es ein separates Problem, das die Idee verfolgt, install & upgrade zu einem deploy Befehl zusammenzuführen?

Nicht dass ich von @dcow wüsste. Was ist der Anwendungsfall helm upgrade --install Befehl

https://github.com/helm/helm/issues/3353#issuecomment -362497951

Ich bin mir nicht sicher, warum wir die Befehle zum Installieren und Aktualisieren benötigen. Ich verwende immer nur den Befehl upgrade --install und es scheint, als würden viele Leute dasselbe tun. Ich brauche nur einen Befehl, der ein Upgrade durchführt - installieren und nicht über einen fehlgeschlagenen Lauf stolpern. Können wir das Upgrade einfach umbenennen - installieren, um es bereitzustellen, es wirklich idempotent zu machen und die anderen beiden loszuwerden?
...

und

https://github.com/helm/helm/issues/3353#issuecomment -469109854

Mit helm wissen Sie derzeit nicht, welche Kombination aus helmbefehl und Optionen verwendet werden soll, ohne den aktuellen Status zu überprüfen. Und für einen bestimmten Steuerbefehl wissen Sie nicht, was Sie bekommen werden, da dies vom aktuellen Status abhängt. Das ist nicht wirklich das deklarativ gewünschte Zustandstraumwolke zzz Lächeln

In Helm 3 können wir möglicherweise install / upgrade / --replace / --upgrade / --force ablehnen und sie alle durch eine idempotente Helmbereitstellung ersetzen, die entweder den gewünschten Status erreicht oder den Status unverändert lässt.
...

Ich stimme im Allgemeinen zu, dass das Ruder wie kubectl apply funktionieren und versuchen sollte, die gewünschte Realität zu erreichen, anstatt je nach Status Ihres Clusters verschiedene Arten von Befehlen ausführen zu müssen. Ich hatte gehofft, ein spezielles Problem zu unterstützen, falls es eines gab, oder zumindest herauszufinden, wie die Lösung lautete, da deploy derzeit nicht implementiert ist und wir das Ruder 3.2 übernehmen.

@dcow Ok, möchten Sie dann ein Problem mit Ihrem Vorschlag erstellen?

@hickeyma erledigt https://github.com/helm/helm/issues/8415!