Hallo, können Sie näher erläutern, wie Sie die Bereitstellung durchführen? Verwenden Sie zufällig helm upgrade --install ? Und wenn ja, wie ist der Status der Bereitstellung, wenn sie fehlerhaft ist ( helm ls ) - vermutlich Failed ?

Wenn dies der Fall ist, sollte ein helm delete --purge <deployment> den Trick machen.

Hallo, Entschuldigung für fehlende Informationen.
Ja, ich benutze helm upgrade --install
Und ja, die Bereitstellung bleibt für immer in Failed .
Leider ist das helm delete --purge <deployment> hier überhaupt keine Option. Aus diesem Grund kann ich Produktionsservices nicht einfach löschen :)

Die Frage ist, warum sich das Ruder nach drei aufeinander folgenden Fehlern nicht erholen kann.

Die einzige Möglichkeit, dies zu sortieren, ohne die Version zu löschen, ist das Hinzufügen von --force

--force zu was? zu helm upgrade --install ?
und wenn ja, dann bedeutet dies, dass das oben genannte Problem tatsächlich als Funktion erwartet wird und wir bei jeder Bereitstellung --force ? - Wenn ja, bedeutet dies, dass defekte Releases zwangsweise bereitgestellt werden?

ja natürlich zu helm upgrade --install :)
und ja, Sie sollten bei jeder Bereitstellung --force

Bedeutet dies, dass --force auch defekte Releases zwangsweise bereitstellen wird? - Ich meine, wenn der Pod ständig kaputt geht und neu gestartet wird, werden dann alte Pods gelöscht und neue geplant?
--force force resource update through delete/recreate if needed
Wie ist die Bedingung delete ? Können Sie näher erläutern, wie es genau funktioniert? Die Beschreibung ist definitiv zu kurz für solch eine kritische Flagge - ich gehe davon aus, dass sie Tausende von Dingen unter der Haube erledigt.

Übrigens möchte ich wirklich nicht mit gelöschten Produktionsservices enden, daher ist das Flag --force für mich keine Option.

und denkst du wirklich, dass es kein Problem ist?
sogar die Fehlermeldung ist falsch:
app-name has no deployed releases
Dies besagt, dass keine bereitgestellten Releases vorhanden sind
während es wird aber mit Zustand Failed ist und Helm nicht einmal versuchen :( zu beheben - durch die Festsetzung meine ich nur bitte versuchen Sie es zu implementieren, statt zu geben auf dem Anfang nach oben

Siehe https://github.com/helm/helm/issues/3208

Kann nicht mehr zustimmen. Unsere Produktion hat den gleichen Fehler. Das Löschen des Diagramms ist daher keine Option, und das Erzwingen der Installation scheint gefährlich. Dieser Fehler ist bei Helm 3 weiterhin vorhanden. Es kann daher sinnvoll sein, eine Korrektur oder eine sicherere Problemumgehung einzuschließen.

Sie kann behoben werden, indem "status": "deploy" in storage.go: 136 entfernt wird

Siehe: https://github.com/helm/helm/pull/6933/commits/638229c3d3646e78d0fd5157309f8aeadfd01af1

Ich werde die Pull-Anfrage beheben, wenn ich Zeit habe.

Der vorhandene Code war ursprünglich korrekt. Entfernen von status: deployed aus den Abfrageergebnissen, wobei Helm die neueste Version findet, von der ein Upgrade durchgeführt werden soll, unabhängig davon, in welchem ​​Status sie sich gerade befindet, was zu unbeabsichtigten Ergebnissen führen kann. Es umgeht das Problem vorübergehend, führt aber später viel größere Probleme ein.

Wenn Sie die Ausgabe von helm history bereitstellen können, wenn Sie auf diesen Fehler stoßen, wäre dies hilfreich. Es ist hilfreicher zu bestimmen, wie man in einem Fall endet, in dem das Release-Ledger keine Releases im Status "Bereitgestellt" enthält.

Dieses Problem tritt auf, wenn ich es zum ersten Mal in einem neuen Cluster bereitstelle. Sollte ich auch --force ?

Dieses Problem trat auf, als ich die vorherige Version ohne Verwendung der Option --purge löschte.

helm delete --purge <release-name>

Helm Version

Client: &version.Version{SemVer:"v2.15.X"}
Server: &version.Version{SemVer:"v2.15.X"}

Ich stoße auch auf dieses Problem.

@ Bacongobbler
Ich habe das mit helm3 getroffen. Der Verlauf ist in diesem Fall vollständig leer, obwohl seit Versuch 1 defekte k8-Ressourcen vorhanden sind.

Die Reproduktion scheint wirklich einfach zu sein:

1. helm upgrade --install "etwas mit einem Pod, der einen Container hat, der mit einem Fehler beendet wird"
2. Korrigieren Sie, was zum Beenden des Containers geführt hat, z. B. Wert mit ungültigem Argument für die ausführbare Datei im Container, und versuchen Sie es erneut
   -> Fehler: UPGRADE FEHLGESCHLAGEN: "foo" hat keine bereitgestellten Releases

Scheint, dass das --atomic-Flag in meinem (CI / CD) -Szenario ein Weg nach vorne sein könnte. Da die anfängliche fehlerhafte Version vollständig bereinigt wird, als ob es nie passiert wäre, habe ich dieses Problem beim nächsten Versuch nicht festgestellt.

Auch hier sehe ich nicht, wie die Verwendung von delete oder --force empfohlen werden kann, insbesondere wenn persistente Volumes vorhanden sind. Ich habe aus diesem Grund bereits alle Grafana-Dashboards verloren, ohne dies zu tun es wieder :)

Update: Übrigens in meinem Fall schlägt die Veröffentlichung aus folgenden Gründen fehl:

Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims

auch wenn ich an den grafana-werten nichts geändert habe

@ alex88 können Sie die Ausgabe von helm history bereitstellen? Ich muss wissen, wie andere diesen Fall treffen, damit wir versuchen können, die Grundursache zu finden und eine Lösung zu finden.

@bacongobbler sicher, ich würde es wirklich lieben, wenn dies behoben wird, da ich sehr vorsichtig bin, wenn ich das Ruder benutze, weil ich ein paar Mal hartnäckige Volumes verloren habe (wahrscheinlich meine Schuld)

REVISION    UPDATED                     STATUS  CHART           APP VERSION DESCRIPTION
4           Wed Dec  4 02:45:59 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
5           Mon Dec  9 12:27:22 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
6           Mon Dec  9 12:33:54 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
7           Mon Dec  9 12:36:02 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
8           Mon Dec  9 13:06:55 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
9           Mon Dec  9 13:38:19 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
10          Mon Dec  9 13:38:51 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
11          Mon Dec  9 13:41:30 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
12          Mon Dec  9 13:56:01 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
13          Mon Dec  9 15:15:05 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims

Im Grunde habe ich mehrmals versucht, das Upgrade auszuführen, um einige env-Variablen zu ändern, und da sich die env-Variablen während des Bereitstellungsfehlers trotzdem geändert haben, habe ich den Fehler weiterhin ignoriert

Wie bist du in einen Zustand gekommen, in dem jede Veröffentlichung fehlgeschlagen ist? Wo ist Release 1, 2 und 3?

Wie bist du in einen Zustand gekommen, in dem jede Veröffentlichung fehlgeschlagen ist? Wo ist Release 1, 2 und 3?

Das Ändern der env-Variablen (musste mehrere Änderungen vornehmen) und das Ausführen eines Upgrades jedes Mal wurden die env-Variablen geändert, aber ich hatte keine Ahnung, wie der dauerhafte Volume-Fehler behoben werden kann

Update: Übrigens benutze ich

version.BuildInfo{Version:"v3.0.0", GitCommit:"e29ce2a54e96cd02ccfce88bee4f58bb6e2a28b6", GitTreeState:"clean", GoVersion:"go1.13.4"}

In Bezug auf die vorherige Version behält das Ruder wahrscheinlich nur 10 davon

Helm3: Ich habe ein ähnliches Problem beim Upgrade von istio. Die Version ist fehlgeschlagen. Jetzt kann ich sie nicht erneut bereitstellen, obwohl ein kleiner Fehler in den Vorlagen behoben wurde. Ich kann die Produktionsversion nicht löschen, da dadurch auch die mit dem istio-ingress-Dienst verknüpfte ELB gelöscht wird.

Gibt es zukünftige Arbeiten, um die Logik zu ändern, wenn die erste Version in einem fehlgeschlagenen Zustand endet?

Was muss ich tun, wenn Ausfallzeiten nicht akzeptiert werden?

% helm upgrade prometheus-thanos --namespace metrics -f values.yaml . 
Error: UPGRADE FAILED: "prometheus-thanos" has no deployed releases
% helm install --atomic prometheus-thanos --namespace metrics -f values.yaml .                                                                                                               
Error: cannot re-use a name that is still in use
% helm version
version.BuildInfo{Version:"v3.0.1", GitCommit:"7c22ef9ce89e0ebeb7125ba2ebf7d421f3e82ffa", GitTreeState:"clean", GoVersion:"go1.13.4"}

Was muss ich tun, wenn Ausfallzeiten nicht akzeptiert werden?

Im Moment verwende ich nur helm, um die Vorlagen zu generieren, und ich speichere sie manuell lokal und wende sie an

Scheint, dass das --atomic-Flag in meinem (CI / CD) -Szenario ein Weg nach vorne sein könnte. Da die anfängliche fehlerhafte Version vollständig bereinigt wird, als ob es nie passiert wäre, habe ich dieses Problem beim nächsten Versuch nicht festgestellt.

@ henrikb123 das obige funktioniert nur, wenn Sie immer das --atomic verwendet haben. Sonst funktioniert es nicht. Beispiel: Versuchen Sie, ein fehlerhaftes Diagramm ohne dieses zu installieren, und führen Sie denselben Befehl mit dem Flag --atomic . Es wird brechen. Zu Ihrer Information Ich verwende die neueste Helm-Version -> 3.0.2

@ alex88 kannst du die ausgabe des

@bacongobbler warum machst du nicht einfach das, was @ henrikb123 hier gesagt @ henrikb123 hervorgehoben , ist der Verlauf vollständig leer . Das kann ich auch bestätigen. Schauen Sie bitte:

$ helm upgrade --install --cleanup-on-fail --reset-values --force --namespace teleport --values values.test.yaml teleport ./
Release "teleport" does not exist. Installing it now.
Error: Secret "teleport-secrets" is invalid: metadata.labels: Invalid value: "helm.sh/chart:teleport-1.0.0app.kubernetes.io/managed-by": a qualified name must consist of alphanumeric characters, '-', '_' or '.', and must start and end with an alphanumeric character (e.g. 'MyName',  or 'my.name',  or '123-abc', regex used for validation is '([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9]') with an optional DNS subdomain prefix and '/' (e.g. 'example.com/MyName')

$ helm history teleport
Error: release: not found

$ helm upgrade --install --cleanup-on-fail --reset-values --force --namespace teleport --values values.test.yaml teleport ./
Error: UPGRADE FAILED: "teleport" has no deployed releases

Ich bin auch mit Istio darauf gestoßen.

Es gibt ein Istio-Problem mit 1.4.3, bei dem einer der Jobs, die von der Installation ausgeführt werden, fehlschlägt, wenn er nicht auf den Kubernetes-API-Server zugreifen kann. Es hinterlässt dann einen Job und wenn Sie versuchen, den Helm-Befehl erneut auszuführen, schlägt dies fehl, da der Job bereits vorhanden ist. Ich habe versucht, den Job zu löschen, Dinge zu optimieren und das Upgrade erneut auszuführen, war aber nie erfolgreich ... und jetzt stecke ich fest.

(Auf diese Weise können Sie in einen vollständig fehlgeschlagenen Release-Status gelangen, da diesbezüglich eine Frage gestellt wurde.)

REVISION    UPDATED                     STATUS  CHART       APP VERSION DESCRIPTION                                                                                                                                                                                                         
10          Tue Jan 14 09:17:00 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition
11          Tue Jan 14 09:22:21 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: warning: Hook post-upgrade istio/charts/security/templates/create-custom-resources-job.yaml failed: jobs.batch "istio-security-post-install-1.4.3" already exists
12          Tue Jan 14 09:23:10 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: warning: Hook post-upgrade istio/charts/security/templates/create-custom-resources-job.yaml failed: jobs.batch "istio-security-post-install-1.4.3" already exists
13          Tue Jan 14 09:25:58 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition 
14          Tue Jan 14 09:35:21 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: warning: Hook post-upgrade istio/charts/security/templates/create-custom-resources-job.yaml failed: jobs.batch "istio-security-post-install-1.4.3" already exists
15          Tue Jan 14 09:38:08 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition 
16          Tue Jan 14 14:02:47 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition
17          Tue Jan 14 14:19:44 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition
18          Tue Jan 14 14:33:36 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: warning: Hook post-upgrade istio/charts/security/templates/create-custom-resources-job.yaml failed: jobs.batch "istio-security-post-install-1.4.3" already exists
19          Tue Jan 14 14:36:59 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition

Dies ist mit Helm 3.0.2.

IMO ist dies ein kritisches Problem, das so schnell wie möglich behoben werden muss. Ich habe viele andere ähnliche Probleme gesehen, die seit Version 2 für dasselbe Problem offen waren, und bis jetzt scheint es, dass es nicht behoben wurde.

Ich bitte die Entwickler nur, genau das zu tun, was @ henrikb123 in seinem Kommentar gesagt hat, um dieses Problem zu simulieren. Es ist eine sehr einfache Möglichkeit, es zu simulieren. Sie können es mit jeder Helm-Version (2.xx und 3.xx) testen. Ich bin mir fast sicher, dass es bei allen passieren wird.

Vielleicht sollte --atomic eine schwierige Anforderung sein (kein Befehlszeilenargument). Es ist sogar als --cleanup-on-fail ziemlich überflüssig. Der Unterschied ist, dass --cleanup-on-fail dieses Problem nicht wie --atomic behoben hat.

Wir haben dies auch gerade in der Produktion festgestellt und Ausfallzeiten sind keine Option. Wir haben eine Problemumgehung gefunden, indem wir einfach die neueste FAILED-Konfigurationskarte gepatcht haben, um stattdessen die Bezeichnung STATUS: DEPLOYED mit einem Befehl wie ...

kubectl -n kube-system patch configmap app-name.v123 --type=merge -p '{"metadata":{"labels":{"STATUS":"DEPLOYED"}}}'

In unserem Fall waren wir sicher, dass die letzte FAILED-Revision tatsächlich erfolgreich von kubernetes bereitgestellt wurde.

Wie sind wir in diesen Zustand gekommen?

Grundsätzlich ignorierte unser Entwicklerteam die FAILED-Upgrades, da Kubernetes die Änderungen nach Ablauf des Steuerzeitraums noch vornahm.

Insbesondere verwenden wir Helm 2 und setzen TILLER_HISTORY_MAX=20 für die Bereitstellung der Pinne. Wir haben helm upgrade --wait --timeout 1080 für alle unsere RollingUpdate-Upgrades verwendet, die im Laufe der Zeit länger dauerten. Dann begannen die Helm-Upgrades eine Zeitüberschreitung, aber niemand war alarmiert (nur genervt), weil Kubernetes die Änderungen immer noch erfolgreich durchführte. Nach 20 abgelaufenen Upgrades (heute) waren wir alarmiert, weil wir nicht mehr bereitstellen konnten, weil wir stattdessen app-name has no deployed releases sahen.

Warum funktioniert der Patch?

Wir haben herausgefunden, dass wir nur das STATUS-Label in der Konfigurationskarte patchen müssen, weil wir festgestellt haben, dass Helm wahrscheinlich Konfigurationskarten mit einer Anfrage anfordert, die ...

kubectl -n kube-system get configmap -l NAME=app-name,STATUS=DEPLOYED

Der Hinweis wurde gefunden, als wir die Konfigurationskarte yaml betrachteten und die folgenden Beschriftungen bemerkten ...

$ kubectl -n kube-system describe configmap app-name.v123
Name:         app-name.v123
Namespace:    kube-system
Labels:       MODIFIED_AT=1579154404
              NAME=app-name
              OWNER=TILLER
              STATUS=FAILED
              VERSION=123
Annotations:  <none>
Data
====
release:
----
H4sIAAAAAAAC...snipped...

Dies steht im Einklang mit https://github.com/helm/helm/issues/5595#issuecomment -552743196

@bacongobbler Anstatt sich zu fragen, wie Sie in einen fehlgeschlagenen Zustand geraten, sollten Sie eine wertvolle Lösung für das Upgrade einer fehlgeschlagenen Installation in Betracht ziehen, die nicht fehlschlagen sollte.

Um Ihre Bedenken zu beantworten: Eine Auszeit ist ein guter Grund für eine fehlgeschlagene Veröffentlichung. Die Version bleibt ebenfalls hängen und kann nicht zurückgesetzt werden, wenn ein Upgrade durchgeführt wird und eine Zeitüberschreitung auftritt.

Somit werden Volumina dynamisch durch die Ansprüche erzeugt. Beim Löschen der Ansprüche (durch Löschen eines Diagramms) werden auch die Volumes viele andere Entwickler stecken monatelang fest und versuchen, daran zu arbeiten.

Die Idee, status: deployed aus der Abfrage zu entfernen, hat Ihnen nicht gefallen. Wie wäre es also mit dem Hinzufügen eines neuen Labels, das tatsächlich die neueste Version kennzeichnet, unabhängig davon, ob der Status bereitgestellt wurde oder fehlgeschlagen ist? Das würde tatsächlich Sinn machen. Da Sie dies tun möchten, möchten Sie die neueste Version erhalten, von der Sie ein Upgrade durchführen können. Und wenn es keine gibt, sollten Sie stattdessen wahrscheinlich nach fehlgeschlagenen Releases suchen. Oder verwenden Sie einfach ein neues Etikett, das das neueste direkt kennzeichnet.

Ich freue mich auf Ihre Meinung dazu

Perfekte Kollokation @AmazingTurtle.

Ich bin mir nicht sicher, ob dies bereits bemerkt wurde, aber dieses Problem tritt auch auf, wenn die allererste Installation eines Diagramms aus irgendeinem Grund fehlschlägt (was besonders bei erstmaligen Diagrammbenutzern, die möglicherweise auf ihrem Diagramm iterieren müssen, sehr häufig vorkommt Konfiguration, um die Dinge zum Laufen zu bringen).

Ich glaube, die einzige Problemumgehung für CLI-Benutzer besteht in diesem Fall darin, das Release-Tracking-Geheimnis zu löschen, wenn der Geheimtreiber verwendet wird, sowie alle Ressourcen, die mit der letzten Version erstellt wurden (um zu vermeiden, dass Helms Ressourcenbesitzprüfungen durchgeführt werden).

Dies ist eine echte Funktion eines Tools, das ich intern geschrieben habe, um dieses Problem zu beheben, wenn es auftritt:

package foo

import (
    "helm.sh/helm/v3/pkg/action"
    "helm.sh/helm/v3/pkg/release"
    "helm.sh/helm/v3/pkg/storage/driver"
)

// DangerouslyApplyRelease allows installing or upgrading any release from a failed state,
// but does not enforce Helm's standard resource ownership checks.
func DangerouslyApplyRelease(cfg *action.Configuration, rel *release.Release) error {
    // Forcibly mark the last release as successful and increment the version
    rel.Info = &release.Info{
        Status: release.StatusDeployed,
    }
    rel.Version++

    var err error

    // Attempt to create the release
    err = cfg.Releases.Create(rel)

    // If release already exists, update it
    if err == driver.ErrReleaseExists {
        err = cfg.Releases.Update(rel)
    }

    return err
}

@jlegrone Würde die Verwendung von helm delete --purge (v2) oder helm uninstall (v3) auch funktionieren, da es sich bei allen um fehlgeschlagene Versionen handelt?

Was von @jlegrone hervorgehoben wurde, ist wahr.
@hickeyma Ihr Vorschlag ist eine Problemumgehung, die funktionieren kann. Aber ich brauche eine endgültige Lösung.

Es ist ein schädlicher Fehler für die letzten 2 Jahre und das Ruder wird ihn nicht beheben
helm delete ist in den meisten Produktionsfällen nicht akzeptabel
mit helm3 können wir nicht kubectl edit secret sh.helm.release.... weil es verschlüsselt ist
helm rollback <latest-successful> ist nur eine korrekte Problemumgehung

Wenn Sie also standardmäßig HISTORY_MAX = 10 haben und 10 Mal versucht haben, etwas zum Laufen zu bringen, sind Sie völlig verloren ...

und wenn Sie eine Logik für Installation oder Upgrade haben, können Sie sh.helm.release ..... v * Geheimnisse nicht löschen

Helm muss sterben oder es reparieren

Problemumgehung gefunden
helm3 beschriftet seine Geheimnisse:
kubectl get secrets --show-labels | grep sh.helm.release.v1

....
sh.helm.release.v1.helm-must-die.v34                 helm.sh/release.v1                    1         13h       modifiedAt=1580326073,name=helm-must-die,owner=helm,status=failed,version=34
sh.helm.release.v1.helm-must-die.v35                 helm.sh/release.v1                    1         13h       modifiedAt=1580326228,name=helm-must-die,owner=helm,status=failed,version=35
sh.helm.release.v1.helm-must-die.v36                 helm.sh/release.v1                    1         1h        modifiedAt=1580370043,name=helm-must-die,owner=helm,status=failed,version=36
...

Tun Sie dies für die neuesten kubectl edit secret sh.helm.release.v1.helm-must-die.v36 und setzen Sie den Label-Status = bereitgestellt
und für die Freigabe davor (v35) setzen Sie den Etikettenstatus = ersetzt

Das nächste helm upgrade --install ... wird funktionieren

@ kosta709 Ähnlich wie bei Helm2, bei dem Releases als ConfigMaps im Namespace des Kubesystems mit Labels gespeichert werden, die alle CAPS sind, speichert Helm3 Releases jetzt als Secrets im Namespace der Anwendung mit Labels, die alle in Kleinbuchstaben geschrieben sind.

Für Helm3 können Sie also einfach einen etwas anderen Kubectl-Patch-Befehl verwenden ...

kubectl -n app-namespace patch secret app-name.v123 --type=merge -p '{"metadata":{"labels":{"status":"deployed"}}}'

Ich wünschte, wir müssten diese Problemumgehungen nicht besprechen. Die Behebung dieses Problems im Produkt sollte oberste Priorität haben. Eine Erinnerung daran, wie schlimm dies ist (ohne Berücksichtigung von Problemumgehungen):

Wenn eine Version bei der ersten Bereitstellung fehlgeschlagen ist ODER wenn nicht genügend Versionen den letzten Erfolg aus dem Verlauf herausgeschleudert haben, kann die Version nicht ohne manuelles Eingreifen behoben werden.

Da die Verwendung von Helms aus einer Pipeline für die kontinuierliche Bereitstellung wahrscheinlich ein allgemeines oder zumindest gewünschtes Muster ist, ist dies nicht praktikabel.

Ich stimme vollkommen zu, wollte aber zumindest die Arbeit klar dokumentieren, denn wenn Sie in diesen Zustand geraten, scheint es keine andere Möglichkeit zu geben, als die Veröffentlichung abzubrechen und einen Ausfall zu nehmen.

Zusammen mit den Patches, um einen Ausfall zu vermeiden, haben wir auch die Verwendung von helm --wait und uns stattdessen auf unsere eigene Abfragelogik verlassen, um zu wissen, wann die Veröffentlichung erfolgreich ist oder nicht. Es ist mehr Arbeit, aber wir haben jetzt viel mehr Sichtbarkeit, was hilfreich ist, wenn eine Version länger als erwartet dauert und wir Fehler früher als das Zeitlimit erkennen können.

Dies war für mich bei älteren Versionen von helm kein Problem, und es gibt keine fehlgeschlagenen Bereitstellungen. Kubectl zeigt laufende Dienste an und alles funktioniert.

Jetzt versuche ich einfach, helm upgrade -f app.yaml --namespace prometheus prometheus prometheus auszuführen, und ich erhalte nur die Fehlermeldung: Error: UPGRADE FAILED: "prometheus" has no deployed releases aber ich kann keine der Problemumgehungen ausprobieren, da dies in Prod ...

@zrsm Was wir jetzt tun, ist, die Yaml-Dateien mit helm und kubectl diff / dry-run zu generieren, um Änderungen in der Vorschau anzuzeigen, bevor sie manuell angewendet werden

@zrsm Was wir jetzt tun, ist, die Yaml-Dateien mit helm und kubectl diff / dry-run zu generieren, um Änderungen in der Vorschau anzuzeigen, bevor sie manuell angewendet werden

Vielen Dank für die Antwort. Ich habe ein Downgrade auf 2.15.1 durchgeführt, bin jedoch auf ähnliche Probleme gestoßen. Ich habe jedoch versucht, mein ~ / .helm zu löschen, und dann das Pinnenwartungskonto von kubectl neu initialisiert. Danach konnte ich Diagramme auf Kubernetes anwenden . Ich werde später heute versuchen, dies mit Helm 3 zu testen und mit einem Fix zurück zu antworten. Ich habe das Gefühl, dass dies das Problem gewesen sein könnte.

Hallo zusammen, also habe ich das getestet ... und es sieht so aus, als würde ich den folgenden Befehl ausführen, nachdem ich auch mein vorheriges ~ / .helm / gelöst habe ...

helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's<strong i="6">@apiVersion</strong>: extensions/v1beta1<strong i="7">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

Ich denke, wenn Sie eine neue Helm-Edition installieren und Ihr Service-Account-Material nicht gefunden wird (ich habe meinen Laptop abgewischt und irgendwann wiederhergestellt), dann passiert dies und dies war die Lösung. Ich hoffe es funktioniert auch bei dir.

Dieser Fehler ist in Helm 3 weiterhin vorhanden. Gibt es eine geplante Lösung?

Dieses Problem tritt auch bei einem neuen Cluster und einer neuen Bereitstellung aufgrund eines Zeitlimits auf. Ich mag es nicht, manuell eine Verbindung zu unserem Cluster herzustellen, um dies zu beheben, aber ich denke, das ist jetzt die einzige Option.

Können wir sicherstellen, dass dieses Problem so schnell wie möglich behoben wird?

Dieses Problem ist so frustrierend, dass es ein Grund ist, die Verwendung von helm insgesamt einzustellen.

Genau. Das macht mich verrückt. Ich werde daran arbeiten, das Problem zu beheben. Wünsch mir Glück.

Genau. Das macht mich verrückt. Ich werde daran arbeiten, das Problem zu beheben. Wünsch mir Glück.

Danke und viel Glück!

Es würde mir nichts ausmachen, ein paar von Ihnen dazu zu bringen, sich PR # 7653 anzuschauen.

Ich glaube, dies wird die oben beschriebenen Probleme lösen.

Ich kann nicht glauben, dass es noch offen ist, ohne dass die Betreuer darauf reagieren

cc @bacongobbler @mattfarina

Würde die Verwendung von helm delete --purge (v2) oder helm uninstall (v3) auch funktionieren, da es sich bei allen um fehlgeschlagene Releases handelt?

@hickeyma nicht immer; Dies kann auch das Ergebnis einer Beschädigung der Helmfreigabe-Metadaten sein, sodass in einigen Fällen durch die Deinstallation Ressourcen unter Last gelöscht werden können.

Manchmal ist die Veröffentlichung nicht fehlgeschlagen, aber Timeout und Helm kennzeichnen sie als fehlerhaft. Wenn sie das nächste Mal anzeigt, dass keine Version bereitgestellt wurde, die App jedoch voll funktionsfähig ist, ist sie mir oft passiert, sodass ich die Version ändern musste beschriften Sie mit deployed eins. Es ist nicht immer eine Option, helm delete --purge (v2) or helm uninstall (v3) zu tun

@rimusz wie

@dudicoco Durch manuelles Bearbeiten des neuesten Release-Geheimnisses von helm v3 können Sie dies automatisieren und kubectl patch

sind zu https://github.com/k14s/kapp übergegangen, was wie ein Zauber wirkt.

@rimusz das habe ich mir gedacht, danke.

Ich habe meinen Fix auch in # 7668 auf Helm 2 zurückportiert, warte aber immer noch auf Feedback zu # 7653

Gleiches Problem hier,

Eine mit --wait bereitgestellte Version hat eine Zeitüberschreitung verursacht und ist nun endlich einsatzbereit. Es ist immer noch als fehlgeschlagen markiert.
Daher schlagen auch spätere Bereitstellungen fehl.

Dies bedeutet, dass der Freigabestatus keine verlässliche Information ist.

Wir verwenden k8s in unserem Unternehmen für viele Dienstleistungen in der Produktion.
Einige Male im Monat haben wir dieselben Probleme mit dem Steuerstand in verschiedenen Anwendungen (" * hat keine bereitgestellten Versionen.").
Wir haben verschiedene Versionen des Helms verwendet (von 2.7 bis 3.0.3).
Das Problem ist nicht behoben.
Dies ist für unsere Benutzer (Entwickler, die Anwendungen im Cluster bereitstellen) sehr unangenehm.
Jedes Mal, wenn wir es treffen, patchen wir nur das neueste Release-Geheimnis (Status zu bereitgestellt).
Gibt es Pläne, ein Verhalten hinzuzufügen, das den Status der letzten Versionen ignoriert und neue Versionen installiert?

Nachdem --history-max auf 10 (Standardwert) gesetzt wurde, war die erste Version erfolgreich.
Dann scheiterten die nächsten 10 Versionen am:
Error: UPGRADE FAILED: timed out waiting for the condition (Es wurde simuliert, also erwartet).
Danach schlug die nächste (11. fehlgeschlagene) Version fehl am:
Error: UPGRADE FAILED: "app" has no deployed releases (das ist das Problem!)

Wäre es möglich, dass das Ruder zusätzlich zu den 10 neuesten (unabhängig von ihrem Status) immer die neueste erfolgreiche Version in der Geschichte beibehält?

Ich liebe die Idee. Müsste die Speicherfunktionalität ändern, aber ich denke, es könnte getan werden.

https://github.com/helm/helm/pull/4978 wurde für Helm 2 zusammengeführt. Vielleicht wurde es nicht auf Helm 3 portiert. Wenn jemand die Zeit hat und es portieren möchte, fühlen Sie sich bitte frei.

Ich habe versucht, dies mit # 7806 auf Helm 3 zu portieren, und würde gerne sehen, wie es so schnell wie möglich zusammengeführt wird. Danke, @ultimateboy!

Was ist mit Releases, die bei der ersten Installation fehlschlagen, dh keine früheren erfolgreichen Releases haben?
Wir verwenden upgrade --install für die idempotente Bereitstellung von Helmversionen. Wenn die erste Version fehlschlägt, schlagen alle nachfolgenden Aufrufe von upgrade --install Fehler "Keine bereitgestellten Versionen" fehl (dieses Problem).

Das Szenario "Fehler beim ersten Release fehlgeschlagen" ist zumindest besser zu handhaben, da Sie es normalerweise manuell ausführen oder überwachen (und sofort einen Fix anwenden können) - im Gegensatz dazu, dass das Ruder von einem CI / CD-System ausgeführt wird, das gerade einen Fehler ausführt Tag und erholt sich auch nach dem Korrigieren des Codes nicht.

Es sollte natürlich noch behoben werden.

Es ist auch wertvoll, die letzte erfolgreiche Version beizubehalten, nicht nur wegen dieses Fehlers. ZB Debugging von Problemen mit der Wertedatei usw.

@peterholak Das Szenario "Erstes Release

Dieses Problem sollte eine hohe Priorität haben, da die meisten Leute das Ruder in der Produktion verwenden. Ich könnte die Helminstallation mit --atomic ausführen, aber was ist, wenn ich den Grund für den Fehler vor der Bereitstellung überprüfen möchte? Ich würde durch das Timeout eine Zeitbox bekommen, bevor die Installation fehlschlägt und dann zurückgesetzt wird. Wenn ich erfolgreich upgraden könnte, müsste ich mich bei der Überprüfung des Fehlers nicht überfordert fühlen.

Wir verwenden auch upgrade --install für die idempotente Bereitstellung von Helmversionen. Denn so funktionieren automatisierte ci / cd-Pipelines. Wir planen nicht, manuell mit dem Ruder herumzuspielen, da dies unsere Bereitstellungspipeline umgehen würde.

In einer automatisierten Bereitstellungspipeline schlägt die erste Bereitstellung fast immer fehl. Nachfolgende Bereitstellungen dürfen nicht anders als beim ersten Versuch ausgelöst werden.

Bitte erwägen Sie, die Priorität dieses Themas erheblich zu erhöhen.

Die Erfahrung ist soooooooo schlecht, wir können nicht einfach die gesamte Version löschen, da sie in Produktion ist! Dies führt zu Ausfallzeiten des Servers! Wie können wir am Ende mit diesem Problem umgehen?

Kann jemand bitte das Frage- / Support-Etikett entfernen? In diesem Problem geht es nicht um fehlende Dokumentation, sondern um das aktuelle Verhalten von Helm, das für die Verwendung in Pipelines mit automatisierter Bereitstellung nicht sehr hilfreich ist.

Die # 7806 PR wurde auf den Master zusammengeführt. Es wird in 3.2 veröffentlicht. Ich schließe diese Ausgabe entsprechend.

Groß! Dies löst die meisten unserer Probleme mit Helm.

Wie ist das aktuelle Verhalten, wenn die erste Version fehlschlägt (noch keine bereitgestellten Versionen)?

Es gab https://github.com/helm/helm/issues/3353, das von https://github.com/helm/helm/pull/3597 angesprochen wurde, jedoch nur, wenn --force verwendet wird.

--force hat jedoch einige Probleme in Helm 3 (https://github.com/helm/helm/issues/6378), mit einem Vorschlag, dies zu beheben (https://github.com/helm/helm/). Issues / 7082), und wie in anderen Kommentaren in diesem Thread erwähnt, ist die Verwendung von --force ohnehin nicht immer geeignet. Die ganze Situation ist also noch etwas unklar.

@technosophos danke für das app-name has no deployed releases angezeigt. Und es ist eine Art Blocker in CI / CD-Pipelines.

@ Peterholak siehe # 7913.

3.2 wird auf dem öffentlichen Entwickleraufruf vom 16. April besprochen. Ich habe es auf diejenigen reduziert, die derzeit so aussehen, als könnten sie sofort eingepackt werden. Dann werden wir den Beta-Release-Prozess starten (vorausgesetzt, alle Betreuer sind sich über den Anruf morgen einig).

Ich hatte das gleiche Problem bei der Lösung von AKS, um das erwähnte Problem mit dem folgenden Befehl zu beheben:

helm version : 3.1.2
Ich lösche das Paket einfach mit dem Befehl aus dem k8s-Cluster
helm delete <release-name>

Führen Sie den Bereitstellungszyklus aus, um das Problem zu beheben

Das Problem ist in der Version 3.2.0 immer noch vorhanden

@deimosfr Dies ist in # 7653 behoben, das in Version 3.2.1 enthalten sein wird. Es ist noch nicht veröffentlicht, aber Sie können das Update erhalten, wenn Sie den Master ausbauen möchten.

Ich bin auf 3.2.1 und das passiert immer noch

Es gibt immer noch Gründe, warum dieser Fehler auftreten kann. 3.2.1 hat den Fehler nicht einfach behoben. Es hat einige der Ursachen beseitigt. Wenn Sie es immer noch bemerken, ist Ihr Problem etwas anderes als das, was das Problem behoben hat.

@yinzara Ich habe einen klassischen Fall von "Pfad b" aus der ursprünglichen Beschreibung auf einem neuen Cluster ohne Probleme. Ich kann diesen Fehler auch in einem anderen Cluster reproduzieren, in dem Helm v2 einwandfrei funktioniert. Wir können natürlich den klassischen Tanz "Dies wird durch etwas anderes verursacht, eröffnen Sie ein neues Thema" machen, aber ich denke, es wird schneller gehen, wenn einfach erkannt wird, dass es nicht wirklich behoben ist.

Was ist die Ausgabe von helm list ? Wie ist der "Status" der vorherigen fehlgeschlagenen Version? Helm 2 hat dieses Problem und es wurde überhaupt nicht behoben, daher denke ich immer noch, dass Ihr Problem nicht das ist, was Sie denken.

Kommt immer noch auf Version 3.2.1 vor.

Wenn die anfängliche Bereitstellung dreimal fehlschlägt, bleibt alles hängen ... Keine Möglichkeit, das Problem zu beheben, wenn Sie das Diagramm nicht löschen und ein gutes bereitstellen.

Einzelheiten:

helm history t3-mac -n t3                                                                                                                                                                 REVISION        UPDATED                         STATUS          CHART           APP VERSION     DESCRIPTION
1               Fri May 22 18:55:11 2020        failed          t3-mac-2.13.0   2.13.0          Release "t3-mac" failed: timed out waiting for the condition
2               Fri May 22 19:33:44 2020        failed          t3-mac-2.13.0   2.13.0          Upgrade "t3-mac" failed: timed out waiting for the condition
3               Fri May 22 19:57:51 2020        pending-upgrade t3-mac-2.13.0   2.13.0          Preparing upgrade

helm.exe upgrade --namespace t3b --install --force --wait t3b-mac t3b-mac-2.13.0.tgz
2020-05-22T18:14:01.7103689Z Error: UPGRADE FAILED: "t3b-mac" has no deployed releases

Ich habe das gleiche Problem mit dem bereitgestellten Diagramm und der Pod läuft einwandfrei

vm-victoria-metrics-single-server-0                    1/1     Running     0          2d18h

Aber ich kann es nicht aktualisieren.

$ helm version
version.BuildInfo{Version:"v3.1.2", GitCommit:"d878d4d45863e42fd5cff6743294a11d28a9abce", GitTreeState:"clean", GoVersion:"go1.13.8"}

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-26T06:16:15Z", GoVersion:"go1.14", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.8", GitCommit:"ec6eb119b81be488b030e849b9e64fda4caaf33c", GitTreeState:"clean", BuildDate:"2020-03-12T20:52:22Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}


ismail ~ $ helm list
NAME    NAMESPACE   REVISION    UPDATED                                 STATUS      CHART                                   APP VERSION    
vm      default     1           2020-05-23 16:20:35.243505 +0300 +03    deployed    victoria-metrics-single-0.5.3           1.35.6         

$ helm upgrade vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Error: UPGRADE FAILED: "vm" has no deployed releases


ismail ~ $ helm upgrade --install vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Release "vm" does not exist. Installing it now.
Error: rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: namespace: , name: vm-victoria-metrics-single, existing_kind: policy/v1beta1, Kind=PodSecurityPolicy, new_kind: policy/v1beta1, Kind=PodSecurityPolicy

Ich bestätige, dass es auch auf meiner Seite passiert ist

@zodraz Ihr

Es war die Entscheidung der Projektbetreuer, den Status der ausstehenden Installation nicht als gültigen Fehlerstatus anzugeben, um das Upgrade zu ermöglichen. (dh dies funktioniert wie geplant)

Ich schlage vor, Sie versuchen herauszufinden, warum Ihr Helm-Upgrade abgebrochen wird, bevor es abgeschlossen ist. Das sollte eine vermeidbare Situation sein.

Ich habe das gleiche Problem mit dem bereitgestellten Diagramm und der Pod läuft einwandfrei

vm-victoria-metrics-single-server-0                    1/1     Running     0          2d18h

Aber ich kann es nicht aktualisieren.

$ helm version
version.BuildInfo{Version:"v3.1.2", GitCommit:"d878d4d45863e42fd5cff6743294a11d28a9abce", GitTreeState:"clean", GoVersion:"go1.13.8"}

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-26T06:16:15Z", GoVersion:"go1.14", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.8", GitCommit:"ec6eb119b81be488b030e849b9e64fda4caaf33c", GitTreeState:"clean", BuildDate:"2020-03-12T20:52:22Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}


ismail ~ $ helm list
NAME  NAMESPACE   REVISION    UPDATED                                 STATUS      CHART                                   APP VERSION    
vm    default     1           2020-05-23 16:20:35.243505 +0300 +03    deployed    victoria-metrics-single-0.5.3           1.35.6         

$ helm upgrade vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Error: UPGRADE FAILED: "vm" has no deployed releases


ismail ~ $ helm upgrade --install vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Release "vm" does not exist. Installing it now.
Error: rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: namespace: , name: vm-victoria-metrics-single, existing_kind: policy/v1beta1, Kind=PodSecurityPolicy, new_kind: policy/v1beta1, Kind=PodSecurityPolicy

Ich werde sagen, Ihr Problem ist für mich ziemlich verwirrend. Ich kann nicht sehen, wie das angesichts der Protokollausgabe, die Sie haben, hätte passieren können. Das Fix-Release in 3.2.1 wird Ihrer Situation sicherlich nicht helfen, da Sie kein fehlgeschlagenes Release haben. Ich würde vermuten, dass einige der Geheimnisse von Kubernetes entfernt wurden, die die Informationen zur Helmfreigabe enthalten. Ich würde vorschlagen, die Version vollständig zu deinstallieren und neu zu installieren, wenn Sie können.

Hallo @yinzara ,

Die Sache ist, dass ich es nicht abgebrochen habe ... Soweit ich weiß, hat es das dritte Mal, als ich gestartet habe (und mich geirrt habe ... weil ich Fehler bei den Bereitstellungen hatte, die es zum Scheitern brachten), dazu gebracht, diesen "beschädigten Zustand" zu erreichen. .

Dieser Status kann nicht wiederhergestellt werden. Die einzige Möglichkeit, ihn zu beheben, besteht darin, das Diagramm zu löschen. Um dies zu vermeiden, verwenden Sie das Atom-Flag, um immer ein Rollback durchzuführen und diesen "beschädigten Status" nie zu erreichen.

Ich verstehe die Entscheidung der Betreuer ... Aber dies führt zu Verwirrung, überhaupt keine mögliche Lösung (wenn das Diagramm nicht gelöscht wird) und wie gesagt, dieser Status wurde erreicht, als 3 Fehler aufgetreten sind ... ohne ihn abzubrechen. .

Wie auch immer, Lektion gelernt und Rollbacks durch die Atomflagge gemacht.

Hallo @yinzara

Ich habe den Grund gefunden, warum es fehlschlägt.

Ich habe den falschen Parameter -selfScrapeInterval=10 Es sollte server.extraArgs.selfScrapeInterval = 10 sein

Also das Problem mit - im Parameter.
Vielleicht war der Steuerfehler für diese Art von variablem Fehler nicht sinnvoll?

Fehlgeschlagen:

ismail sf $ helm upgrade vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Error: UPGRADE FAILED: "vm" has no deployed releases

Erfolg:

ismail sf $ helm upgrade vm vm/victoria-metrics-single --set "server.extraArgs.selfScrapeInterval=10" 
Release "vm" has been upgraded. Happy Helming!
NAME: vm
LAST DEPLOYED: Tue May 26 22:35:15 2020
NAMESPACE: default
STATUS: deployed
REVISION: 3
TEST SUITE: None
NOTES:
TBD

Dies funktioniert auch:

ismail sf $ helm upgrade vm vm/victoria-metrics-single --set "selfScrapeInterval=10" 
Release "vm" has been upgraded. Happy Helming!
NAME: vm
LAST DEPLOYED: Tue May 26 22:37:43 2020
NAMESPACE: default
STATUS: deployed
REVISION: 4
TEST SUITE: None
NOTES:
TBD

Ich habe das gleiche Problem: '(und ich kann die Bereinigung nicht verwenden, weil ich die Daten verlieren werde und das nicht kann. Ich weiß, dass dieses Problem geschlossen ist, aber nur ich drücke meinen Schmerz aus.

Wir müssen Helmfreigaben weglassen, wenn wir kritische Workloads bereitstellen, aus diesem Grund sogar istioctl von istio ditches helm (ich nehme an). Wir verwenden Helmvorlage .... | Problemen , die an gelöschte Ressourcen erinnert werden müssen.

@GloriaPG können Sie weitere Informationen teilen? Wie tritt das gleiche Problem auf? Wie @yinzara bereits im Thread erwähnt hat, tritt möglicherweise ein Fall auf, den # 7652 nicht behebt. Wir brauchen jedoch weitere Informationen, um zu diesem Schluss zu kommen.

Hallo @bacongobbler

Wir verwenden helm upgrade mit --install und --force Flags:

helm upgrade --install ${PROJECT_NAME} ${CHART_NAME} \
   --namespace $NAMESPACE_NAME \
   --values ${SECRETS} \
   --values ${CONFIG_VALUES} \
   --force \
   --wait \
   --timeout ${MAX_WAIT_SECONDS} || rollback

Leider, wenn die Veröffentlichung fehlgeschlagen ist:

$ helm list
NAME                    NAMESPACE   REVISION    UPDATED                                 STATUS      CHART           APP VERSION
PROJECT_NAME                CHART_NAME      136         2020-07-09 14:13:09.192381483 +0000 UTC failed      CHART_NAME-0.1.0

es ergibt sich:

Error: UPGRADE FAILED: "PROJECT_NAME" has no deployed releases
Error: failed to replace object: Deployment.apps "PROJECT_NAME" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"PROJECT_NAME"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable

Wie kann es gelöst werden? Es scheint, dass --force mit --install Flag nicht funktioniert

Da es sich um eine Produktionsumgebung handelt, kann ich die Version nicht einfach löschen und von Grund auf neu erstellen :(

Vielen Dank für alle Vorschläge

Ihr Fehler scheint mit https://github.com/kubernetes/client-go/issues/508 in Zusammenhang zu stehen
Sie können die Auswahl in einer Bereitstellung nicht ändern. Sie müssten die Bereitstellung aufheben und erneut bereitstellen.

@yinzara das lustige ist, dass ich den Selektor bei meiner Bereitstellung nicht ändere, alles funktioniert an 9/10 Releasone. In einem Fall ist etw während der Bereitstellung fehlgeschlagen, die Veröffentlichung ist fehlgeschlagen und ich kann sie in keiner Weise wiederherstellen. Die Bereitstellung selbst funktioniert, Pods werden ausgeführt, aber ich kann sie nicht mehr ändern.

Es ist ein bisschen eingängig, dass ich es nach dem Release im fehlgeschlagenen Zustand nicht mehr mit dem Helm ändern kann. Ich würde erwarten, dass das Flag --force es mir ermöglicht, die gesamte Bereitstellung zu ersetzen oder Änderungen zu erzwingen, aber ich konnte keinen Weg finden, die vorhandene Version zu reparieren und damit zu arbeiten.

Ja, leider scheint dies kein Steuerungsproblem zu sein. Bei Ihrer Veröffentlichung ist etwas fehlgeschlagen, und in Kubernetes ist es in einem schlechten Zustand. Höchstwahrscheinlich ist der Selektor durcheinander oder etwas ist nicht so, wie Sie es erwarten, aber der Fehler, den Sie bei "App-Name" sehen, hat keine bereitgestellten Versionen, ist nur ein roter Hering.

Ich habe versucht, auf die vorherige Version zurückzusetzen. Die Version befindet sich jetzt im Status deployed . Leider ändert sich nichts daran, daher denke ich, dass der einzige Weg darin besteht, leider zu löschen und erneut bereitzustellen.

Mein spezielles Problem dabei ist also leicht zu reproduzieren.

Starten Sie die Bereitstellung von etwas mit helm3 (mit --atomic und --cleanup-on-fail ) und drücken Sie Strg + C, um mit dem Erstellen von Ressourcen zu beginnen. Es wird kein Rollback durchgeführt, die Ressourcen sind noch vorhanden, und alle nachfolgenden Versuche, install --upgrade auszuführen, führen zu dem Fehler "Keine bereitgestellten Releases".

Diese Strg + C-Taste tritt im Wesentlichen auf, wenn jemand ein neues Commit an einen Zweig in unserem CI-System sendet, während bereits ein Build ausgeführt wird. Das Helm-Upgrade wird abgebrochen und befindet sich dann in einem vollständig fehlerhaften Zustand.

Können wir nach diesem Punkt etwas tun, um das Problem zu beheben? Wie bei vielen anderen in diesem Thread ist das Löschen keine Option.

BEARBEITEN: Sobald dies nicht funktioniert, zeigt helm ls die Version nicht an, helm history zeigt sie im Status "Ausstehend installieren" an.

Eigentlich - egal. Für die Betroffenen gibt es eine Lösung: Löschen Sie den Verlaufsdatensatz manuell aus kubernetes. Es ist als Geheimnis gespeichert. Wenn ich den fehlerhaften pending-install -Statuseintrag lösche, kann ich upgrade --install erneut erfolgreich ausführen!

@AirbornePorcine - Können Sie bitte die Änderungen erläutern, die in kubernetes erforderlich sind, um die ausstehenden Installationseinträge zu löschen?

@ tarunnarang0201 Helm erstellt für jede Bereitstellung ein Kubernetes-Geheimnis. In demselben Namespace, in dem Sie bereitgestellt haben, sehen Sie, dass es vom Typ 'helm.sh/release.v1' ist und so etwas wie 'sh.helm.release.v1.release' heißt -name.v1 '. Sie müssen nur das neueste Geheimnis löschen (sehen Sie sich das Suffix 'v1' im Beispiel an, es wird für jede Bereitstellung erhöht), und das schien die Dinge für mich freizugeben.

@ AirbornePorcine danke!

@AirbornePorcine @ tarunnarang0201 @ ninja- Sie können auch einfach die Statusbezeichnung patchen ... insbesondere, wenn Sie keine früheren DEPLOYED-Versionen haben.

Informationen zu Helm 3 finden Sie in meinem Kommentar unter https://github.com/helm/helm/issues/5595#issuecomment -580449247

Weitere Details und Anweisungen zu Helm 2 finden Sie in meinem Kommentar unter https://github.com/helm/helm/issues/5595#issuecomment -575024277

Dieses Gespräch ist zu lang ... und jeder Kommentar hat eine Lösung ... was ist die Schlussfolgerung?
Wir haben das alte Helm 2.12 verwendet und hatten nie Probleme, aber jetzt mit Version 3.2.4 schlägt eine zuvor fehlgeschlagene Bereitstellung mit diesem Fehler fehl.

Wir verwenden übrigens Terraform und den neuesten Helmanbieter. Also sollten wir --force oder --replace

@xbmono Das Gespräch ist lang, weil es gibt

• Es gibt eine ganze Reihe von Gründen, warum Ihre Veröffentlichung in diesen Zustand geraten kann
• Dies war auch auf Helm 2 möglich, und die dort und auf Helm 3 funktionierenden Lösungen sind unterschiedlich.
• Es gibt verschiedene Wege, die Benutzer in dieser Ausgabe eingeschlagen haben, um dorthin zu gelangen
• Es gibt verschiedene Optionen, je nachdem, was Sie versuchen und ob Sie bereit sind, den Verlust von PVCs und verschiedene mögliche Kombinationen von Ausfallzeiten zu riskieren / zu tolerieren.

Wenn Sie den Fehler "Keine bereitgestellten Releases" haben, bin ich mir nicht sicher, ob install --replace oder upgrade --install --force Ihnen alleine helfen werden.

Ein vernünftiger Vorschlag kann wahrscheinlich nur gegeben werden

• Wenn Sie die helm history für die Veröffentlichung angeben, damit die Leute sehen können, was passiert ist
• wenn Sie den ursprünglichen Grund für den Fehler angeben / was Sie getan haben, um dorthin zu gelangen - und ob Sie der Meinung sind, dass das ursprüngliche Problem behoben wurde

Meine Zusammenfassung möglicher Optionen

• Wenn Sie sich überhaupt nicht um die vorhandenen k8s-Ressourcen oder Ausfallzeiten kümmern, ist helm uninstall && helm install möglicherweise eine Option
• Wenn die erste Installation des Diagramms fehlgeschlagen ist, können Sie wahrscheinlich nur die geheimen Metadaten der Veröffentlichung und helm install erneut löschen . Möglicherweise müssen die k8s-Ressourcen manuell bereinigt werden, wenn Cruft aufgrund des Fehlers nicht mehr verfügbar ist, je nachdem, ob Sie --atomic usw. verwendet haben.
• Wenn Sie eine --wait ed-Installation teilweise abgebrochen haben und helm history anzeigt, dass sich die letzte Version in pending-install , können Sie die neuesten geheimen Metadaten der Version löschen oder den Veröffentlichungsstatus patchen
• in bestimmten anderen Kombinationen von Szenarien kann es auch möglich sein, den Freigabestatus Patch von einem oder mehreren der Release Geheimnisse und sehen , ob eine nachfolgende upgrade kann aber meines Wissens gehen, wurden adressiert den meisten dieser Fälle von # 7653 (um sicherzustellen, dass es irgendwo in der Geschichte eine Veröffentlichung von deployed , zu der man zurückkehren kann), wäre ich überrascht, wenn dies jetzt nützlich wäre.

Da dies ein geschlossenes Problem ist, vermute ich, dass es eine Grundursache gibt, die sich gut zum Debuggen und Dokumentieren in einem anderen, spezifischeren Ticket eignet.

@chadlwilson Danke für deine Antwort.

helm history gibt keine Zeilen zurück!

Error: release: not found

helm list gibt jedoch die fehlgeschlagene Bereitstellung zurück

M:\>helm3 list -n cluster171
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS  CHART                           APP VERSION
cluster171      cluster171      1               2020-09-01 04:45:26.108606381 +0000 UTC failed    mychart-prod-0.2.0-alpha.10    1.0

Wir verwenden Terraform und unsere Umgebungen werden stündlich automatisch von Jenkins bereitgestellt. Mit Terraform kann ich helm upgrade , das macht der Helmanbieter

Im Terraform-Code habe ich force_update auf true , kein Glück und ich habe replace auf true , wieder kein Glück

resource "helm_release" "productStack" {
  name = "${var.namespace}"
  namespace = "${var.namespace}"
  chart = "${var.product_stack}"
  force_update = true//"${var.helm_force_update}"
  max_history = 10
  replace = true

  wait = true
  timeout = "${var.timeout_in_seconds}"

}

Also frage ich mich, ob es mit wait=true zu tun hat? Der Grund, warum die vorherige Bereitstellung fehlgeschlagen ist, war, dass der Cluster nicht mit dem Docker-Repository kommunizieren konnte und daher die timeout erreicht wurden und der Status failed aber wir haben das Problem und die pods behoben helm delete offensichtlich, aber wenn ich dies jedes Mal tun würde, wären meine Manager oder die Entwickler glücklich.

Wenn die Bereitstellung mit helm v2 fehlschlägt und die Entwickler sie beheben, wird die fehlgeschlagene Bereitstellung durch die nächste Bereitstellung aktualisiert.

M:\>helm3 list -n cluster171
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS  CHART                           APP VERSION
cluster171      cluster171      1               2020-09-01 04:45:26.108606381 +0000 UTC failed    mychart-prod-0.2.0-alpha.10    1.0

Der Fehler helm history scheint seltsam (Tippfehler? Verpasster Namespace? Falsche Steuerversion?), Aber angesichts der Revision 1 in den list oben scheint es, als würden Sie versuchen, eine erste zu machen Die zeitliche Installation eines neuen Diagramms und die erstmalige Installation ist fehlgeschlagen. Wenn Sie versuchen, Dinge zu entsperren, können Sie wahrscheinlich die oben genannten geheimen Metadaten der Veröffentlichung löschen oder ihren Status patchen und es erneut versuchen. Dies kann darauf hinweisen, dass sich die Metadaten aus der Sicht von Helm oder des Helm Terraform Providers in einem schlechten Zustand befinden, aber nicht, wie sie dort angekommen sind.

Auf jeden Fall habe ich keine Probleme, upgrade bei fehlgeschlagenen Erstbereitstellungen mit Helm 3.2.1 auszuführen, seit # 7653 zusammengeführt wurde. Vielleicht möchten Sie die spezifische Helm-Version überprüfen, die der Anbieter tatsächlich verwendet? Es ist auch möglich, dass dies damit zusammenhängt, wie der Helm Terraform-Anbieter den Status der Veröffentlichung nach einem Fehler von install . Ich habe keine Erfahrung mit diesem Anbieter und bin persönlich nicht dafür, Helm mit einer anderen deklarativen Abstraktion wie TF zu versehen, da ich es noch undurchsichtiger finde, wenn etwas schief geht, aber Sie möchten vielleicht trotzdem weiter graben .

Wie ich bereits sagte, denke ich, wenn der Fehler, bei dem Sie stecken bleiben, nach einer fehlgeschlagenen erstmaligen Bereitstellung has no deployed releases , weder replace noch force werden Ihnen wahrscheinlich dabei helfen, die Situation ohne weitere Eingriffe wiederzubeleben, und es ist am besten, sie weiter zu debuggen und sich an anderer Stelle zu unterhalten, da das Hin- und Hergehen auf diesem alten geschlossenen Ticket mit 51 Teilnehmern nicht für alle Beteiligten so produktiv erscheint.

Nein, es gab keinen Tippfehler. Dies geschieht auch unabhängig von der ersten Bereitstellung oder später.

Wie bereits erwähnt, verwenden wir die Option --wait , um auf die Bereitstellung in Jenkins zu warten und dann zu benachrichtigen, ob die Bereitstellung fehlgeschlagen ist oder nicht.

Wenn das Zeitlimit erreicht ist und die Bereitstellung nicht erfolgreich ist, hat helm die Bereitstellung anscheinend als failed markiert, und es gibt keine andere Möglichkeit, sie wiederherzustellen, als diese Version manuell zu löschen. Und wir wollen die Veröffentlichung auch nicht automatisch löschen, weil das beängstigend ist.

Wenn wir also die Option --wait entfernen, markiert helm die Bereitstellung unabhängig davon als successful .

Problemumgehung:

Jetzt habe ich eine andere Lösung gefunden. Für diejenigen, die das gleiche Problem haben und möchten, dass ihre Automatisierung wie früher funktioniert, ist hier meine Problemumgehung:

• Entfernen Sie die Option --wait aus der Bereitstellung von helm
• Verwenden Sie diesen Befehl, um die Liste der Bereitstellung für den Namespace abzurufen, für den Sie die Bereitstellung durchführen: kubectl get deployments -n ${namespace} -o jsonpath='{range .items[*].metadata}{.name}{","}{end}'
• Sie können split , um die durch Kommas getrennte Liste oben in ein Array umzuwandeln
• Dann können Sie mehrere Befehle gleichzeitig ausführen (wir verwenden Jenkins, damit dies einfach ist), als kubectl rollout status deployment ${deploymentName} --watch=true --timeout=${timeout} -n ${namespace}
• Wenn nach timeout , zum Beispiel 7m , 7 Minuten bedeutet und die Bereitstellung immer noch nicht erfolgreich ist, wird der Befehl mit einem Fehler beendet
• Problem gelöst.

Eigentlich - egal. Für die Betroffenen gibt es eine Lösung: Löschen Sie den Verlaufsdatensatz manuell aus kubernetes. Es ist als Geheimnis gespeichert. Wenn ich den fehlerhaften pending-install -Statuseintrag lösche, kann ich upgrade --install erneut erfolgreich ausführen!

Alternativ hat das bei mir funktioniert:

helm uninstall {{release name}} -n {{namespace}}

behoben durch kubectl -n $namespace delete secret -lstatus=pending-upgrade
Lauf jetzt wieder Ruder.

Ich bin mir nicht sicher, warum dies geschlossen ist, ich habe es gerade mit dem brandneuen Helm 3.3.4 getroffen. Wenn die Erstinstallation fehlschlägt, zeigt das zweite Helm-Upgrade --install --force immer noch denselben Fehler an. Alle diese Problemumgehungen funktionieren, sind jedoch manuell . Sie helfen nicht, wenn Sie eine vollständig 100% automatische CI / CD durchführen möchten, bei der Sie einfach den Fix drücken können, um eine weitere Bereitstellung auszulösen, ohne die Bereinigung manuell durchzuführen.

Hat jemand daran gedacht, einfach ein Flag hinzuzufügen, dass dies die erste Version ist, sodass es sicher sein sollte, sie einfach automatisch zu löschen? Oder etwas wie "--force-delete-on-fail" hinzufügen? Das Ignorieren des Problems wird nicht helfen.

@ nick4fake AFIK es wurde von PR # 7653 geschlossen. @yinzara kann möglicherweise weitere Details bereitstellen.

Es war eine Entscheidung der Betreuer, das Überschreiben einer ausstehenden Upgrade-Version nicht zuzulassen. Ihre Aussage, dass alle Workarounds Workarounds sind, die in einer CI / CD-Pipeline nicht funktionieren, ist jedoch nicht wahr. Die letzte vorgeschlagene Problemumgehung könnte als Build-Schritt hinzugefügt werden, bevor Sie Ihr Helm-Upgrade ausführen (ich würde auch --force nicht in einer CI / CD-Pipieline verwenden). Es hat den gleichen Effekt wie das, was Sie vorgeschlagen haben, außer dass es die Version direkt vor der Installation der nächsten Version löscht, anstatt unmittelbar danach, damit Sie die Fehlerursache debuggen können.

In meinem automatisierten Build habe ich außerdem Folgendes verwendet, um "ausstehende" Releases zu deinstallieren, bevor ich meinen Upgrade-Befehl ausführe (stellen Sie sicher, dass die Umgebungsvariable NS_NAME auf den Namespace festgelegt ist, in dem Sie sie bereitstellen):
`` `Bash

! / usr / bin / env bash

RELEASES = $ (Steuerliste --Namespace $ NS_NAME --pending --output json | jq -r '. [] | Select (.status == "pending-install") | .name')
wenn [[ ! -z "$ RELEASES"]]; dann
helm delete --namespace $ NS_NAME $ RELEASES
fi

@yinzara danke für das Snippet, es ist sehr hilfreich für diejenigen, die diesen Thread finden.

Mein Punkt ist immer noch gültig - es ist nicht sicher, die Version einfach zu löschen. Warum kann Helm die Aktualisierung nicht erzwingen, wenn eine einzelne Ressource ausfällt? Das Ersetzen der Version durch eine neue Version scheint eine bessere Lösung zu sein als das vollständige Löschen. Ich verstehe möglicherweise einige grundlegende Grundlagen von Helm nicht (z. B. wie es den Status verwaltet), so dass dies möglicherweise nicht möglich ist, aber ich verstehe immer noch nicht, warum es besser ist, Benutzer zu zwingen, manuell einzugreifen, wenn die erste Installation fehlschlägt.

Ich meine, überprüfen Sie einfach diesen Diskussionsthread, die Leute stehen immer noch vor dem Problem. Was halten Sie davon, möglicherweise zusätzliche Informationen zur Helm-Fehlermeldung mit einem Link zu diesem Thread und einigen Vorschlägen hinzuzufügen, was zu tun ist?

@ nick4fake Ich denke, Sie

Die Bibliotheksbetreuer stimmen Ihnen in Bezug auf fehlgeschlagene Veröffentlichungen zu. Deshalb haben sie meine PR akzeptiert.

Eine "fehlgeschlagene" Version kann aktualisiert werden. Das hat meine PR gemacht. Wenn eine Version fehlschlägt, weil eine der Ressourcen fehlgeschlagen ist, können Sie diese Version einfach aktualisieren (dh das Upgrade --install funktioniert auch), und es wird nicht angegeben, dass der "App-Name" keinen Fehler bei den bereitgestellten Versionen aufweist.

Sie sprechen von einer "ausstehenden Installation". Die Betreuer halten es nicht für sicher, dass Sie ein Upgrade einer Version mit ausstehender Installation (erzwungen oder anderweitig) aktualisieren können, da diese möglicherweise noch ausgeführt wird oder sich in einem teilweise vollständigen Zustand befindet, von dem sie nicht glauben, dass er automatisch behoben werden kann. Meine PR erlaubte diesen Zustand ursprünglich und die Betreuer baten mich, ihn zu entfernen.

Wenn Sie Ihre Releases in diesem Status finden, möchten Sie möglicherweise Ihre Bereitstellungskonfiguration überdenken. Dies sollte in einer ordnungsgemäß konfigurierten CI / CD-Pipeline niemals passieren. Es sollte entweder fehlschlagen oder erfolgreich sein. "ausstehend" bedeutet, dass die Installation abgebrochen wurde, während sie noch verarbeitet wurde.

Ich bin kein Betreuer, daher ist meine Meinung zu Ihrem Vorschlag irrelevant. Ich finde jedoch in der Codebasis keine Erwähnung eines Github-Problems, das tatsächlich in einem Fehler oder einer Nachricht abgedruckt ist. Ich wette also, dass sie das nicht zulassen, aber Sie Gerne können wir eine PR zusammenstellen und sehen :-)

Davon abgesehen stimme ich Ihrer Aussage nicht zu, dass Ihr Punkt noch gültig ist. Mein Vorschlag kann die ausstehende Version entfernen, aber @abdennour schlägt direkt vor Ihrer vor, nur das Geheimnis zu löschen, das die ausstehende Installationsversion beschreibt. Wenn Sie dies tun, löschen Sie keine der Ressourcen aus der Version und können die Version aktualisieren.

Was halten Sie davon, möglicherweise zusätzliche Informationen zur Helm-Fehlermeldung mit einem Link zu diesem Thread und einigen Vorschlägen hinzuzufügen, was zu tun ist?

+1 dazu. Wir müssen noch googeln, um diesen Thread zu finden und zu verstehen, was eine pending-install -Version ist, damit wir anfangen können, über diese Fehlermeldung nachzudenken.

Ich hatte Probleme mit helm upgrade und es führte mich hierher. Es wurde durch Hinzufügen von -n <namespace> gelöst. Vielleicht hilft es jemandem da draußen.

Für Helm3, Könnte durch Patch gelöst werden
kubectl -n <namespace> patch secret <release-name>.<version> --type=merge -p '{"metadata":{"labels":{"status":"deployed"}}}'

release-name und version - Kann von kubectl get secrets -n <namespace> | grep helm