Salut - pouvez-vous donner plus de détails sur la façon dont vous déployez? utilisez-vous helm upgrade --install par hasard? Et si vous le faites, quel est l'état du déploiement lorsqu'il est interrompu ( helm ls ) - probablement Failed ?

Si tel est le cas, un helm delete --purge <deployment> devrait faire l'affaire.

salut, désolé pour les informations manquantes.
Oui, j'utilise helm upgrade --install
Et oui, le déploiement reste indéfiniment dans Failed .
Malheureusement, le helm delete --purge <deployment> n'est pas du tout une option ici. Je ne peux pas simplement supprimer les services de production à cause de cela :)

La question est de savoir pourquoi la barre ne peut pas récupérer après 3 échecs consécutifs.

le seul moyen de trier cela sans supprimer la version ajouter --force

--force à quoi? à helm upgrade --install ?
et si oui, cela signifie que le problème ci-dessus est en fait une fonctionnalité attendue et que nous devrions utiliser --force avec chaque déploiement? - si oui, cela signifie-t-il qu'il déploiera de force des versions cassées?

oui, bien sûr à helm upgrade --install :)
et oui, vous devriez utiliser --force avec chaque déploiement

cela signifie-t-il que --force déploiera également de force des versions cassées? - Je veux dire, si le pod sera cassé et redémarrera tout le temps, supprimera-t-il les anciens pods et en planifiera-t-il de nouveaux?
--force force resource update through delete/recreate if needed
quelle est la condition delete ? pouvez-vous expliquer comment cela fonctionne exactement? la description est définitivement trop courte pour un drapeau aussi critique - je suppose qu'il fait des milliers de choses sous le capot.

BTW Je ne veux vraiment pas finir avec des services de production supprimés, donc l'indicateur --force n'est pas une option pour moi.

et pensez-vous vraiment que ce n'est pas un problème?
même le message d'erreur est faux:
app-name has no deployed releases
qui indique qu'il n'y a pas de versions déployées
alors qu'il y en a mais avec l'état Failed et helm n'essaye même pas de le réparer :( - en corrigeant je veux dire, essayez de le déployer, au lieu d'abandonner au tout début

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

Je ne peux pas être plus d'accord. Notre production connaît la même erreur. Donc, supprimer le graphique n'est pas une option et forcer l'installation semble dangereux. Cette erreur est toujours présente avec Helm 3. Il peut donc être judicieux d'inclure un correctif ou une solution de contournement plus sûre.

il peut être corrigé en supprimant "status": "deploy", dans storage.go: 136

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

Je corrigerai la demande de tirage lorsque j'aurai le temps.

Le code en place était à l'origine correct. Supprimer status: deployed des résultats de la requête avec Helm trouvant la dernière version à partir de laquelle effectuer la mise à niveau, quel que soit l'état dans lequel elle se trouve actuellement, pourrait conduire à des résultats inattendus. Cela évite temporairement le problème, mais cela introduit des problèmes beaucoup plus importants plus tard.

Si vous pouvez fournir la sortie de helm history lorsque vous rencontrez ce bogue, ce serait utile. Il est plus utile de déterminer comment on se termine dans un cas où le registre des versions n'a pas de versions à l'état «déployé».

Je rencontre ce problème lors du déploiement pour la première fois sur un nouveau cluster. Dois-je aussi utiliser --force ?

J'ai rencontré ce problème lorsque j'ai supprimé la version précédente sans utiliser l'option --purge .

helm delete --purge <release-name>

Version de la barre

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

Je rencontre également ce problème.

@bacongobbler
J'ai frappé ceci avec helm3. L'historique est complètement vide lorsque cela se produit, bien que des ressources k8 cassées soient présentes depuis la tentative 1.

La reproduction semble vraiment facile:

1. mise à niveau de la barre - installez "quelque chose avec un pod qui a un conteneur qui se termine avec une erreur"
2. corrigez ce qui a provoqué la fermeture du conteneur, par exemple une valeur avec un argument non valide pour l'exécutable à l'intérieur du conteneur, et réessayez
   -> Erreur: UPGRADE FAILED: "foo" n'a pas de version déployée

Il semble que le drapeau --atomic puisse être une voie à suivre dans mon scénario (CI / CD). Puisqu'il nettoie complètement la version initiale en échec comme si cela ne s'était jamais produit, je ne rencontre pas ce problème lors de la prochaine tentative.

Pareil ici, je ne vois pas comment utiliser delete ou --force peut être conseillé, surtout quand il y a des volumes persistants en place, j'ai déjà perdu tous les tableaux de bord grafana à cause de cela une fois, sans le faire encore une fois :)

Mise à jour: btw dans mon cas, la publication échoue à cause de:

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

même si je n'ai rien changé aux valeurs grafana

@ alex88 pouvez-vous fournir la sortie de helm history ? J'ai besoin de savoir comment les autres attaquent cette affaire afin que nous puissions essayer de déterminer la cause fondamentale et trouver une solution.

@bacongobbler bien sûr que j'aimerais vraiment voir cela corrigé car je suis vraiment prudent d'utiliser helm car j'ai perdu plusieurs fois des volumes persistants (probablement de ma faute)

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

En gros, j'ai essayé plusieurs fois d'exécuter la mise à niveau pour modifier certaines variables d'environnement et depuis qu'il y avait l'erreur de déploiement, les variables d'environnement ont quand même changé, j'ai continué à le faire en ignorant l'erreur

comment êtes-vous entré dans un état où chaque version a échoué? Où sont les versions 1, 2 et 3?

comment êtes-vous entré dans un état où chaque version a échoué? Où sont les versions 1, 2 et 3?

changer les variables d'env (a dû faire plusieurs changements) et exécuter une mise à niveau à chaque fois, cela changeait les variables d'env mais je ne savais pas comment corriger l'erreur de volume persistante

Mise à jour: btw que j'utilise

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

concernant la version précédente, helm n'en conserve probablement que 10

Helm3: J'ai le même problème lors de la mise à niveau d'istio, la version a échoué, maintenant je ne peux pas la redéployer même si une petite erreur dans les modèles est corrigée. Je ne peux pas supprimer la version de production car elle supprimera également l'ELB associé au service istio-ingress.

Y a-t-il des travaux futurs pour changer la logique lorsque la version initiale se termine dans un état d'échec?

Que dois-je faire si les temps d'arrêt ne sont pas acceptés?

% 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"}

Que dois-je faire si les temps d'arrêt ne sont pas acceptés?

pour l'instant, j'utilise simplement helm pour générer les modèles et je les enregistre manuellement localement et les applique

Il semble que le drapeau --atomic puisse être une voie à suivre dans mon scénario (CI / CD). Puisqu'il nettoie complètement la version initiale en échec comme si cela ne s'était jamais produit, je ne rencontre pas ce problème lors de la prochaine tentative.

@ henrikb123 ce qui précède ne fonctionne toujours utilisé l'indicateur --atomic . Sinon, cela ne fonctionnera pas. Par exemple: essayez d'installer un graphique cassé sans celui-ci et exécutez la même commande avec l'indicateur --atomic . Ça va casser. Pour info, j'utilise la dernière version de Helm -> 3.0.2

@ alex88 pouvez-vous fournir la sortie de l'historique de barre? J'ai besoin de savoir comment les autres attaquent cette affaire afin que nous puissions essayer de déterminer la cause fondamentale et trouver une solution.

@bacongobbler pourquoi ne faites-vous pas ce que @ henrikb123 a dit ici pour simuler le problème? Comme l'a souligné @ henrikb123 , l'historique est complètement vide . Je peux également le confirmer. Jetez un œil s'il vous plaît:

$ 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

J'ai aussi rencontré cela avec Istio.

Il existe un problème Istio avec la version 1.4.3 où l'une des tâches

(C'est ainsi que vous pouvez entrer dans un état de sortie en échec total, car il y avait une question à ce sujet.)

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

C'est avec Helm 3.0.2.

OMI c'est un problème critique qui doit être résolu dès que possible. J'ai vu de nombreux autres problèmes similaires qui étaient ouverts pour le même problème depuis la version 2 et jusqu'à ce qu'il semble maintenant qu'il ne soit pas résolu.

Je demande juste aux développeurs de faire exactement ce que @ henrikb123 a dit sur son commentaire pour simuler ce problème. C'est un moyen très simple de le simuler. Vous pouvez le tester avec n'importe quelle version de Helm (2.xx et 3.xx). Je suis presque sûr que cela se produira avec tous.

Peut-être que --atomic devrait être une exigence stricte (pas un argument de ligne de commande). C'est même assez redondant comme --cleanup-on-fail . La différence est que --cleanup-on-fail ne résout pas ce problème comme l'a fait --atomic .

Nous venons également de rencontrer cela en production et les temps d'arrêt ne sont pas une option. Nous avons trouvé une solution de contournement en corrigeant simplement la dernière configuration FAILED pour avoir à la place l'étiquette STATUS: DEPLOYED utilisant une commande comme ...

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

Dans notre cas, nous étions sûrs que la dernière révision FAILED a finalement été déployée avec succès par kubernetes.

Comment en sommes-nous arrivés à cet état?

Fondamentalement, notre équipe de développement a ignoré les mises à niveau FAILED car Kubernetes effectuait toujours les modifications après l'expiration du délai de barre.

Plus précisément, nous utilisons Helm 2 et nous définissons TILLER_HISTORY_MAX=20 sur le déploiement de tiller-deploy. Nous utilisions helm upgrade --wait --timeout 1080 pour toutes nos mises à jour RollingUpdate qui prenaient plus de temps au fil du temps. Ensuite, les mises à niveau de la barre ont commencé à expirer mais personne n'a été alarmé (juste ennuyé) car Kubernetes réussissait toujours à effectuer les modifications. Après l'expiration de 20 mises à jour (aujourd'hui), nous avons été alarmés car nous ne pouvions plus déployer parce qu'à la place, nous voyions app-name has no deployed releases .

Pourquoi le patch fonctionne-t-il?

Nous avons compris que nous avions juste besoin de patcher l'étiquette STATUS dans la configmap car nous nous sommes rendu compte que Helm demandait probablement des configmaps en utilisant une requête similaire à ...

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

L'indice a été trouvé lorsque nous avons consulté le fichier yaml de configmap et remarqué les étiquettes suivantes ...

$ 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...

Et cela est cohérent avec https://github.com/helm/helm/issues/5595#issuecomment -552743196

@bacongobbler au lieu de vous demander comment vous vous retrouveriez dans un état d'échec, vous devriez envisager une solution précieuse pour mettre à niveau une installation qui a échoué, qui .. ne devrait pas échouer.

Mais en fait, pour répondre à vos préoccupations: un temps mort est une bonne raison pour une version échouée. La version sera également bloquée et ne pourra pas être annulée lors de la mise à niveau et de l'expiration d'un délai.

Ainsi, ayant des volumes créés dynamiquement par les revendications. Lors de la suppression des revendications (en supprimant un graphique), les volumes sont également supprimés définitivement . Ce n'est pas comme ça que vous l'aimez. Moi et beaucoup d'autres développeurs sont bloqués pendant des mois et essayons de contourner ce problème.

Vous n’avez pas aimé l’idée de supprimer status: deployed de la requête. Alors qu'en est-il d'ajouter une nouvelle étiquette qui marque réellement la dernière version , que son statut ait été déployé ou échoué? Cela aurait du sens. Parce que c'est ce que vous voulez faire, vous souhaitez obtenir la dernière version à partir de laquelle effectuer la mise à niveau. Et s'il n'y en a pas, vous devriez probablement rechercher les versions ayant échoué à la place. Ou utilisez simplement une nouvelle étiquette qui marque directement la dernière.

_Je suis ravi d'entendre votre opinion à ce sujet._

Collocation parfaite @AmazingTurtle.

Je ne sais pas si cela a déjà été noté, mais ce problème survient également si la toute première installation d'un graphique échoue pour une raison quelconque (ce qui est très courant, en particulier pour les utilisateurs de graphiques novices qui peuvent avoir besoin d'itérer sur leur configuration pour faire fonctionner les choses).

Je pense que la seule solution de contournement pour les utilisateurs de CLI dans ce cas est de supprimer le secret de suivi de version si vous utilisez le pilote de secrets, ainsi que toutes les ressources créées par la dernière version (pour éviter de se heurter aux vérifications de propriété des ressources de Helm).

C'est une vraie fonction d'un outil que j'ai écrit en interne pour gérer ce problème lorsqu'il survient:

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 Est-ce que l'utilisation de helm delete --purge (v2) ou helm uninstall (v3) fonctionnerait également, car ce sont toutes des versions qui ont échoué?

Ce qui a été souligné par @jlegrone est vrai.
@hickeyma votre proposition est une solution de contournement qui peut fonctionner. Mais j'ai besoin d'une solution définitive.

c'est un bug nuisible pour les 2 dernières années et la barre ne va pas le réparer
helm delete n'est pas acceptable dans la plupart des cas de production
avec helm3 nous ne pouvons pas kubectl edit secret sh.helm.release.... car il est chiffré
helm rollback <latest-successful> n'est qu'une solution de contournement correcte

donc si vous avez par défaut HISTORY_MAX = 10 et que vous avez essayé 10 fois de faire fonctionner quelque chose - vous êtes complètement perdu ...

et si vous avez une logique sur l'installation par rapport à la mise à niveau, vous ne pouvez pas supprimer sh.helm.release ..... v * secrets

la barre doit mourir ou la réparer

solution de contournement trouvée
helm3 met des étiquettes sur ses secrets:
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
...

alors faites-le pour le dernier kubectl edit secret sh.helm.release.v1.helm-must-die.v36 et définissez le statut de l'étiquette = déployé
et pour la publication avant (v35) définir le statut de l'étiquette = remplacé

la prochaine helm upgrade --install ... fonctionnera

@ kosta709 Semblable à ma découverte pour Helm2, qui stocke les versions sous forme de ConfigMaps dans l'espace de noms kube-system avec des étiquettes qui sont toutes CAPS, Helm3 stocke maintenant les versions en tant que Secrets dans l'espace de noms de l'application avec des étiquettes qui sont toutes en minuscules.

Donc, pour Helm3, vous pouvez simplement utiliser une commande kubectl patch légèrement différente ...

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

J'aurais aimé que nous n'ayons pas à discuter de ces solutions de contournement. La résolution de ce problème dans le produit doit être la priorité absolue. Un rappel de la gravité de la situation (sans tenir compte des solutions de contournement):

Si une version a échoué la première fois qu'elle a été déployée OU si suffisamment de versions n'ont pas réussi à faire disparaître le dernier succès de l'historique, la version ne peut pas être corrigée sans intervention manuelle.

Étant donné que l'utilisation de Helm à partir d'un pipeline de déploiement continu est probablement un modèle courant ou au moins souhaité, cela n'est pas réalisable.

Je suis tout à fait d'accord, mais je voulais au moins documenter clairement le travail, car lorsque vous entrez dans cet état, vous avez l'impression qu'il n'y a pas d'autre option que d'abandonner la version et de faire une panne.

En plus des correctifs pour éviter une panne, nous avons également arrêté d'utiliser helm --wait et nous nous appuyons à la place sur notre propre logique d'interrogation pour savoir quand la publication est réussie ou non. C'est plus de travail mais nous avons maintenant beaucoup plus de visibilité, ce qui est utile lorsqu'une version prend plus de temps que prévu, et nous pouvons détecter les échecs avant l'expiration du délai.

Ce n'était pas un problème pour moi sur les anciennes versions de helm, et il n'y a pas de déploiements échoués, kubectl montre des services en cours d'exécution et tout fonctionne.

Maintenant, j'essaye simplement d'exécuter helm upgrade -f app.yaml --namespace prometheus prometheus prometheus et j'obtiens juste l'erreur: Error: UPGRADE FAILED: "prometheus" has no deployed releases mais je ne peux essayer aucune des solutions de contournement car c'est en cours ...

@zrsm ce que nous faisons pour l'instant est de générer les fichiers yaml à l'aide de helm et d'utiliser kubectl diff / dry-run pour prévisualiser les modifications avant de les appliquer manuellement

@zrsm ce que nous faisons pour l'instant est de générer les fichiers yaml à l'aide de helm et d'utiliser kubectl diff / dry-run pour prévisualiser les modifications avant de les appliquer manuellement

Merci pour la réponse, j'ai rétrogradé à 2.15.1 mais j'ai rencontré des problèmes similaires, cependant, j'ai essayé quelque chose comme la suppression de mon ~ / .helm, puis j'ai réinitialisé le compte de service de barre de kubectl, après avoir fait cela, j'ai pu appliquer des graphiques à kubernetes . J'essaierai de tester cela avec helm 3 plus tard dans la journée et je répondrai avec un correctif. J'ai le sentiment que c'est peut-être le problème.

Bonjour, j'ai donc testé cela ... et il semble que j'exécute la commande suivante après avoir également supprimé mon précédent ~ / .helm / résolu ce problème ...

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 -

Je pense que si vous installez une nouvelle édition de barre et que vos éléments de compte de service ne sont pas situés (j'ai effacé mon ordinateur portable et restauré à un moment donné), cela se produit et c'était le correctif. J'espère que cela fonctionne pour vous aussi.

Ce bogue est en cours dans Helm 3, y a-t-il un correctif prévu?

Également confronté à ce problème avec un nouveau cluster et un nouveau déploiement en raison d'un délai d'expiration. Je n'aime pas me connecter manuellement à notre cluster pour résoudre ce problème, mais je suppose que c'est la seule option maintenant.

Pouvons-nous nous assurer que ce problème est résolu dès que possible?

ce problème est tellement frustrant que c'est une raison pour arrêter complètement d'utiliser helm .

Je suis d'accord. Ça me rend dingue. Je vais travailler à le réparer. Souhaite moi bonne chance.

Je suis d'accord. Ça me rend dingue. Je vais travailler à le réparer. Souhaite moi bonne chance.

merci et bonne chance!

Cela ne me dérangerait pas que quelques-uns d'entre vous regardent le PR # 7653.

Je pense que cela résoudra les problèmes décrits ci-dessus.

Je ne peux pas croire qu'il est toujours ouvert sans réaction des responsables

cc @bacongobbler @mattfarina

L'utilisation de helm delete --purge (v2) ou de helm uninstall (v3) fonctionnerait-elle également, car ce sont toutes des versions ayant échoué?

@hickeyma pas toujours; cela pourrait également être le résultat de la corruption des métadonnées de la version de la barre, donc dans certains cas, la désinstallation pourrait supprimer des ressources sous charge.

Parfois, la publication n'est pas ratée mais timeout et helm la qualifient d'échec, et la prochaine fois, elle montre qu'elle n'a pas de version déployée, mais l'application est en fait entièrement fonctionnelle, cela m'est arrivé plusieurs fois, j'ai donc dû changer la version label à deployed un. ce n'est pas toujours une option pour faire helm delete --purge (v2) or helm uninstall (v3)

@rimusz comment

@dudicoco en modifiant manuellement le secret de la dernière version de helm v3, vous pouvez automatiser cela et utiliser kubectl patch

sont passés à https://github.com/k14s/kapp qui fonctionne comme un charme.

@rimusz c'est ce que j'ai pensé, merci.

J'ai également rétroporté mon correctif à la barre 2 dans # 7668 mais j'attends toujours des commentaires sur # 7653

Même problème ici,

Une version déployée avec --wait a expiré et est enfin opérationnelle. Il est toujours marqué comme ayant échoué.
Et donc, les déploiements ultérieurs échouent également.

Cela signifie que l'état de la version n'est pas une information fiable.

Nous utilisons les k8 dans notre entreprise pour de nombreux services de production.
Pendant quelques fois dans un mois, nous avons les mêmes problèmes avec la barre sur différentes applications (" * n'a pas de versions déployées.").
Nous avons utilisé différentes versions de helm (de 2.7 à 3.0.3).
Le problème n'est pas résolu.
Cela provoque beaucoup d'inconfort pour nos utilisateurs (développeurs qui déploient des applications en cluster)
Chaque fois, lorsque nous l'atteignons, nous corrigeons simplement le dernier secret de version (statut à déployé).
Existe-t-il un plan pour ajouter un comportement qui ignore l'état des dernières versions et installe les nouvelles versions?

Avec --history-max défini sur 10 (valeur par défaut), la première version a réussi.
Ensuite, les 10 prochaines versions ont échoué le:
Error: UPGRADE FAILED: timed out waiting for the condition (Il a été simulé, donc attendu).
Après cela, la prochaine version (11e échec) a échoué le:
Error: UPGRADE FAILED: "app" has no deployed releases (c'est ça le problème!)

Serait-il possible que helm conserve toujours la dernière version à

J'adore l'idée. Aurait besoin de modifier la fonctionnalité de stockage, mais je pense que cela pourrait être fait.

https://github.com/helm/helm/pull/4978 a été fusionné pour Helm 2. Peut-être qu'il n'a pas été porté sur Helm 3. Si quelqu'un a le temps et veut le porter, n'hésitez pas.

J'ai essayé de porter ceci sur Helm 3 avec le # 7806, et j'aimerais le voir fusionné dès que possible. Merci, @ultimateboy!

Qu'en est-il des versions qui échouent lors de la _first_ installation, c'est-à-dire qui n'ont pas de versions réussies?
Nous utilisons upgrade --install pour le déploiement idempotent des versions de helm et lorsque la première version échoue, tous les appels suivants de upgrade --install échouent avec l'erreur "n'a pas de versions déployées" (ce problème).

Le scénario «première version échouant» est au moins plus gérable, car vous l'exécutez ou le surveillez généralement manuellement (et pouvez appliquer un correctif sur-le-champ) - par opposition à la gestion de la barre par un système CI / CD qui commence juste à échouer. jour et ne récupère pas même après avoir corrigé le code.

Il devrait encore être corrigé bien sûr.

Il est également utile de conserver la dernière version réussie de toute façon, pas seulement à cause de ce bogue. Par exemple, problèmes de débogage avec le fichier de valeurs, etc.

@peterholak Le scénario "échec de la première version" se fait parfois aussi avec un CI / CD et par exemple - nous avons un accès restreint à notre cluster et ne pouvons même pas faire un "helm ls" comment sommes-nous censés "gérer cela"?

Cette question devrait être une priorité élevée étant donné que la plupart des gens utilisent la barre dans la production. Je pourrais exécuter l'installation de la barre avec --atomic , mais que se passe-t-il si je souhaite inspecter la raison de l'échec avant de déployer? Je serais temporisé par le délai avant que l'installation échoue, puis elle revienne. Si je pouvais mettre à niveau avec succès, je n'aurai pas à me sentir pris de temps lors de l'inspection de l'échec.

Nous utilisons également upgrade --install pour un déploiement idempotent des versions de barre. Parce que c'est ainsi que fonctionnent les pipelines ci / cd automatisés. Nous ne prévoyons pas de manipuler manuellement la barre, car cela contournerait notre pipeline de déploiement.

Dans un pipeline de déploiement automatisé, le premier déploiement échouera presque toujours. Les déploiements suivants ne doivent pas être déclenchés différemment de la première tentative.

Veuillez envisager de rehausser considérablement la priorité de cette question.

L'expérience est tellement mauvaise, nous ne pouvons pas simplement supprimer la version entière, car elle est en production! Cela entraînera un temps d'arrêt du serveur! Comment pouvons-nous régler ce problème à la fin?

Quelqu'un peut-il également supprimer l'étiquette de question / d'assistance? Ce problème ne concerne pas la documentation manquante, mais le comportement actuel de Helm qui n'est pas très favorable à l'utilisation dans les pipelines de déploiement automatisés.

Le PR # 7806 a été fusionné avec le maître. Il sortira en 3.2. Je clôture ce numéro en conséquence.

Génial! Cela résout la plupart de nos problèmes avec Helm.

Quel est le comportement actuel si la première version échoue (aucune version déployée pour le moment)?

Il y avait https://github.com/helm/helm/issues/3353 qui était adressé par https://github.com/helm/helm/pull/3597 mais uniquement lorsque --force est utilisé.

--force a cependant quelques problèmes dans Helm 3 (https://github.com/helm/helm/issues/6378), avec une proposition pour y remédier (https://github.com/helm/helm/ issues / 7082), et comme d'autres commentaires dans ce fil de discussion, l'utilisation de --force n'est pas toujours appropriée de toute façon. La situation dans son ensemble est donc encore quelque peu floue.

@technosophos merci pour le correctif. Curieux, quand serait-ce 3.2. version disponible à installer? Continuez à recevoir app-name has no deployed releases erreur

@peterholak voir # 7913.

3.2 sera discuté lors de l'appel public de développement du 16 avril. Je l'ai trié à ceux qui semblent actuellement pouvoir être emballés tout de suite. Ensuite, nous commencerons le processus de publication de la version bêta (en supposant que les responsables soient tous d'accord sur l'appel demain).

J'étais confronté au même problème sur AKS résoudre pour résoudre le problème mentionné en suivant la commande:

helm version : 3.1.2
Je viens de supprimer le package du cluster k8s avec la commande
helm delete <release-name>

et exécutez le cycle de déploiement pour résoudre le problème

Le problème est toujours là dans la version 3.2.0

@deimosfr Ceci est corrigé dans # 7653 qui sera dans la version 3.2.1. Il n'est pas encore publié, mais vous pouvez obtenir le correctif si vous souhaitez créer un master.

Je suis sur 3.2.1 et cela se produit toujours

Il existe encore des raisons pour lesquelles cette erreur peut se produire. 3.2.1 n'a pas simplement supprimé l'erreur. Cela a éliminé certaines des causes. Si vous le rencontrez toujours, votre problème est autre que ce qu'il a corrigé.

@yinzara J'ai un cas classique de "chemin b" de la description originale sur un nouveau cluster sans aucun problème. Je peux également reproduire cette erreur dans un autre cluster où Helm v2 fonctionne très bien. On peut bien sûr faire la danse classique "ceci est causé par autre chose, ouvrir un nouveau numéro", mais je pense que ce sera plus rapide si on reconnaît simplement que ce n'est pas vraiment réglé.

Quelle est la sortie de helm list ? Quel est le "statut" de la version précédente ayant échoué? Helm 2 a ce problème et il n'a pas été résolu du tout, donc je pense toujours que votre problème n'est pas ce que vous pensez.

Cela se produit toujours sur la version 3.2.1.

Si le déploiement initial échoue 3 fois, tout est bloqué ... Aucun moyen de le réparer si vous ne supprimez pas le graphique et n'en déployez pas un bon.

Des détails:

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

J'ai le même problème sur la carte déployée et le pod fonctionne correctement

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

Mais je ne peux pas l'améliorer.

$ 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

Je confirme que c'est aussi arrivé de mon côté

@zodraz L'état de votre barre indique la raison de votre erreur. La version la plus récente n'apparaît pas comme ayant échoué, mais comme "installation en attente". Cela impliquerait que le processus qui gérait la dernière mise à jour a été artificiellement arrêté avant qu'il ne soit terminé (c'est-à-dire avant qu'il n'ait commis une erreur ou ait réussi).

Les responsables du projet ont décidé de ne pas inclure l'état de l'installation en attente comme état d'erreur valide pour permettre la mise à niveau. (c'est-à-dire que cela fonctionne comme prévu)

Je vous suggère d'essayer de déterminer pourquoi votre mise à niveau de barre est annulée avant qu'elle ne se termine. Cela devrait être une situation évitable.

J'ai le même problème sur la carte déployée et le pod fonctionne correctement

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

Mais je ne peux pas l'améliorer.

$ 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

Je dirai que votre problème me rend assez perplexe. Je ne vois pas comment cela aurait pu arriver compte tenu de la sortie de journal que vous avez. La version de correctif de la version 3.2.1 n'aidera certainement pas votre situation car vous n'avez pas de version qui a échoué. Je suppose que certains des secrets ont été supprimés de Kubernetes qui contiennent les informations de version de la barre. Je suggérerais de désinstaller complètement la version et de la réinstaller si vous le pouvez.

Salut @yinzara ,

Le truc, c'est que je ne l'ai pas annulé ... Pour autant que je sache, la troisième fois que j'ai lancé (et erré ... parce que j'avais des erreurs sur les déploiements pour le faire échouer) l'a fait atteindre cet "état corrompu" .. .

Cet état n'est pas récupérable ... Donc le seul moyen de le réparer est de supprimer le graphique ... Ma solution de contournement pour éviter cela d'utiliser l'indicateur atomique pour toujours revenir en arrière et ne jamais atteindre cet "état corrompu" ...

Je comprends la décision des responsables ... Mais cela conduit à confusion, pas de solution possible du tout (si ce n'est la suppression du graphique) et bon, comme je l'ai dit, cet état a été atteint lorsque 3 erreurs se sont produites ... sans l'annuler .. .

Quoi qu'il en soit, leçon apprise et effectuant des annulations via le drapeau atomique.

Salut @yinzara

J'ai trouvé la raison pour laquelle cela échoue.

J'ai défini le mauvais paramètre -selfScrapeInterval=10 cela devrait être server.extraArgs.selfScrapeInterval = 10

Donc, le problème avec - dans le paramètre.
Peut-être que l'erreur de barre n'était pas significative pour ce type d'erreur de variable?

A défaut:

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

Succès:

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

Cela fonctionne également:

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

J'ai le même problème: '(et je ne peux pas utiliser la purge parce que je vais perdre les données et je ne peux pas le faire, je sais que ce problème est clos mais seulement j'exprime ma douleur.

Nous devons abandonner les versions de barre, lorsque nous déployons des charges de travail critiques, même istioctl de la barre des fossés istio pour cette raison (je suppose). Nous utilisons un modèle de barre .... |

@GloriaPG pouvez-vous partager plus d'informations? Comment rencontrez-vous le même problème? Comme @yinzara l'a mentionné plus tôt dans le fil de discussion, vous rencontrez peut-être un cas que # 7652 ne résout pas. Nous avons besoin de plus d’informations pour nous aider avant de pouvoir arriver à cette conclusion.

Salut @bacongobbler

Nous utilisons helm upgrade avec les indicateurs --install et --force :

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

Malheureusement, lorsque la version est en état d'échec:

$ 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

il en résulte:

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

Comment peut-il être résolu? Il semble que --force avec l'indicateur --install ne fonctionne pas

Comme il s'agit d'un environnement de production, je ne peux pas simplement purger la version et la créer à partir de zéro :(

Merci pour vos suggestions

Votre erreur semble être liée à https://github.com/kubernetes/client-go/issues/508
Vous ne pouvez pas modifier le sélecteur sur un déploiement. Vous devrez annuler le déploiement et redéployer.

@yinzara le plus drôle est que je ne change pas de sélecteur sur mon déploiement, tout fonctionne sur une version 9/10. Dans un cas lors du déploiement, qch a mal tourné, la version est en état d'échec et je ne suis pas en mesure de récupérer de quelque manière que ce soit - le déploiement lui-même fonctionne, les pods sont en cours d'exécution mais je ne suis plus en mesure de le modifier.

Il est un peu contre-intuitif qu'après la version en état d'échec, je ne puisse plus le changer en utilisant helm. Je m'attendrais à ce que l'indicateur --force me permette de remplacer tout le déploiement ou de forcer l'application des modifications, mais je n'ai pas trouvé de moyen de corriger la version existante et de travailler avec elle.

Ouais, malheureusement, cela ne semble pas être un problème de barre. Une erreur a échoué dans votre version et elle est en mauvais état dans kubernetes. Il est plus que probable que le sélecteur soit foiré ou que quelque chose ne soit pas ce à quoi vous vous attendiez, mais l'erreur que vous voyez à propos de "app-name" n'a pas de versions déployées n'est qu'un hareng rouge.

J'ai essayé de revenir à la version précédente, la version est maintenant dans le statut deployed . Malheureusement, cela ne change rien, donc je pense que le seul moyen est de supprimer et de déployer à nouveau malheureusement.

Donc, mon problème particulier avec cela est facile à reproduire.

Commencez à déployer quelque chose avec helm3 (avec --atomic et --cleanup-on-fail ), et ctrl + c le processus après avoir commencé à créer des ressources. Rien n'est annulé, les ressources existent toujours et toute tentative ultérieure d'exécution de install --upgrade entraîne l'erreur "n'a pas de versions déployées".

Ce ctrl + c est quelque chose qui se produit essentiellement lorsque quelqu'un pousse un nouveau commit dans une branche de notre système CI alors qu'une compilation est déjà en cours d'exécution - la mise à niveau de la barre sera annulée, puis elle est dans un état complètement cassé.

Y a-t-il quelque chose que nous pouvons faire pour y remédier après ce point? Comme pour beaucoup d'autres dans ce fil, la suppression n'est pas une option.

EDIT: une fois que cela est cassé, helm ls n'affiche pas la version, helm history affiche dans l'état en attente d'installation.

En fait - tant pis. Pour les personnes concernées, il existe une solution: supprimer manuellement l'enregistrement d'historique de kubernetes. Il est conservé sous forme de secret. Si je supprime l'entrée d'état pending-install incriminée, je peux exécuter à nouveau avec succès upgrade --install !

@AirbornePorcine - Pouvez-vous s'il vous plaît élaborer sur les changements requis dans kubernetes pour supprimer les entrées en attente d'installation.

@ tarunnarang0201 Helm crée un secret Kubernetes pour chaque déploiement, dans le même espace de noms que vous avez déployé, vous verrez qu'il est de type 'helm.sh/release.v1', et nommé quelque chose comme 'sh.helm.release.v1.release -nom.v1 '. Il vous suffit de supprimer le secret le plus récent (regardez le suffixe 'v1' dans l'exemple, il est incrémenté à chaque déploiement), et cela a semblé débloquer des choses pour moi.

@AirbornePorcine merci!

@AirbornePorcine @ tarunnarang0201 @ ninja- Vous pouvez également simplement patcher l'étiquette de statut ... surtout si vous n'avez aucune version DEPLOYED précédente.

Pour Helm 3, voir mon commentaire sur https://github.com/helm/helm/issues/5595#issuecomment -580449247

Pour plus de détails et d'instructions sur Helm 2, consultez mon commentaire sur https://github.com/helm/helm/issues/5595#issuecomment -575024277

Cette conversation est trop longue ... et chaque commentaire a une solution ... quelle est la conclusion?
Nous avons utilisé l'ancien helm 2.12 et nous n'avons jamais eu de problèmes, mais maintenant avec la v3.2.4, un déploiement précédemment échoué échoue avec cette erreur.

Nous utilisons Terraform par ailleurs et le dernier fournisseur de barre. Alors devrions-nous utiliser --force ou --replace

@xbmono La conversation est longue car il y a

• il y a un certain nombre de raisons pour lesquelles votre libération peut entrer dans cet état
• cela était également possible sur Helm 2, et les solutions qui ont fonctionné là-bas et sur Helm 3 sont différentes.
• les utilisateurs de ce numéro ont emprunté différents chemins pour y arriver
• il existe différentes options selon ce que vous essayez de faire et selon que vous êtes prêt à risquer / tolérer la perte de PVC et diverses combinaisons possibles de temps d'arrêt.

Si vous êtes à une erreur "n'a pas de versions déployées", je ne suis pas sûr que install --replace ni upgrade --install --force vous aideront seuls.

Une suggestion sensée ne peut probablement être donnée

• si vous fournissez le helm history pour la version afin que les gens puissent voir ce qui s'est passé
• si vous partagez la raison d'origine de l'échec / ce que vous avez fait pour y arriver - et si vous pensez que le problème d'origine a été résolu

Mon résumé des options possibles

• si vous ne vous souciez pas du tout des ressources k8s existantes ou des temps d'arrêt, helm uninstall && helm install peut être une option
• si c'est une première installation de graphique qui a échoué, vous pouvez probablement simplement supprimer les métadonnées secrètes de la version et helm install nouveau. Il sera peut-être nécessaire de nettoyer manuellement les ressources de k8 si la cruft est restée au-delà en raison de l'échec, selon que vous avez utilisé ou non --atomic etc.
• si vous avez abandonné une installation de --wait ed en cours et que helm history montre que la dernière version est dans pending-install vous pouvez supprimer les métadonnées secrètes de la version la plus récente ou corriger l'état de la version
• dans certaines autres combinaisons de scénarios, il peut également être possible de corriger le statut de upgrade ultérieur peut continuer, mais à ma connaissance, la plupart de ces cas ont été résolus par # 7653 (pour s'assurer qu'il y a une version deployed quelque part dans l'historique vers laquelle revenir) donc je serais surpris si cela était utile maintenant.

Puisqu'il s'agit d'un problème clos, je soupçonne qu'il existe une cause fondamentale qu'il serait bon de déboguer et de documenter de toute façon dans un ticket différent et plus spécifique.

@chadlwilson Merci pour votre réponse.

helm history ne renvoie aucune ligne!

Error: release: not found

mais helm list renvoie l'échec du déploiement

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

Nous utilisons Terraform et nos environnements sont déployés automatiquement toutes les heures par Jenkins. Avec terraform, je ne peux pas utiliser helm upgrade , c'est ce que fait le fournisseur de barre

Dans le code terraform, j'ai mis force_update à true , pas de chance et j'ai mis replace à true , encore une fois pas de chance

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}"

}

Alors je me demande si ça a à voir avec wait=true ? Donc, la raison pour laquelle le déploiement précédent a échoué était que le cluster n'était pas en mesure de communiquer avec le référentiel docker et donc le timeout atteint et le statut est failed mais nous avons résolu le problème et le pods redémarré avec succès, maintenant évidemment helm delete fonctionne, mais si je devais le faire à chaque fois, mes responsables ni les développeurs ne seront heureux.

Avec helm v2, si le déploiement échoue et que les développeurs le résolvent, le prochain déploiement mettra à niveau le déploiement échoué.

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

L'échec helm history semble étrange (faute de frappe? Espace de noms manqué? Mauvaise version de barre?), Mais étant donné sa révision 1 dans le list ci-dessus, il semble que vous essayez de faire une première heure de l'installation d'un nouveau graphique et de l'échec de la première installation. Si vous essayez de débloquer des choses, vous pouvez probablement supprimer les métadonnées secrètes de publication comme ci-dessus ou corriger son état, puis réessayer. Cela peut indiquer que les métadonnées sont dans un mauvais état du point de vue de Helm ou du fournisseur Helm Terraform, mais pas de la manière dont elles y sont arrivées.

Dans tous les cas, je n'ai aucun problème à faire upgrade sur les premiers déploiements échoués avec Helm 3.2.1 depuis la fusion de # 7653. Vous voudrez peut-être vérifier la version spécifique de Helm que le fournisseur utilise réellement? Il est également possible que cela soit lié à la façon dont le fournisseur Helm Terraform détermine l'état de la version après un échec install . Je n'ai aucune expérience avec ce fournisseur et je ne suis personnellement pas favorable à l'idée d'emballer Helm avec une autre abstraction déclarative telle que TF car je la trouve encore plus opaque lorsque les choses tournent mal, mais vous voudrez peut-être creuser plus loin tout de même. .

Dans tous les cas, comme je l'ai dit ci-dessus, si l'erreur à laquelle vous êtes bloqué est has no deployed releases après un premier déploiement échoué, je ne pense ni replace ni force sont susceptibles de vous aider à ressusciter la situation sans autre intervention et il serait préférable de la déboguer davantage et d'avoir une conversation ailleurs, car aller et venir sur ce vieux ticket fermé avec 51 participants ne semble pas si productif pour tous.

Non, il n'y avait pas de faute de frappe. En outre, cela se produit indépendamment du fait qu'il s'agisse du premier déploiement ou d'une version ultérieure.

Comme je l'ai mentionné, nous utilisons l'option --wait pour attendre le déploiement dans Jenkins, puis pour notifier si le déploiement a échoué ou non.

Il semble que si le délai d'expiration est atteint et que le déploiement échoue, helm marqué le déploiement comme failed et il n'y a aucun moyen de récupérer autre que la suppression manuelle de cette version. Et nous ne voulons pas non plus supprimer la version automatiquement parce que c'est effrayant.

Donc, si nous supprimons l'option --wait , helm marquera le déploiement comme successful quoi qu'il en soit.

Solution de contournement:

Maintenant, j'ai trouvé une autre solution. Pour ceux qui ont le même problème et veulent que leur automatisation fonctionne correctement comme avant, voici ma solution de contournement:

• Supprimer l'option --wait de helm deploy
• Utilisez cette commande pour récupérer la liste des déploiements pour cet espace de noms sur lequel vous déployez: kubectl get deployments -n ${namespace} -o jsonpath='{range .items[*].metadata}{.name}{","}{end}'
• Vous pouvez utiliser split pour transformer la liste séparée par des virgules ci-dessus en un tableau
• Ensuite, vous pouvez exécuter plusieurs commandes en parallèle (nous utilisons Jenkins donc c'est facile à faire) comme kubectl rollout status deployment ${deploymentName} --watch=true --timeout=${timeout} -n ${namespace}
• Si après timeout , par exemple 7m signifie 7 minutes, le déploiement échoue toujours, la commande se termine avec une erreur
• Problème résolu.

En fait - tant pis. Pour les personnes concernées, il existe une solution: supprimer manuellement l'enregistrement d'historique de kubernetes. Il est conservé sous forme de secret. Si je supprime l'entrée d'état pending-install incriminée, je peux exécuter à nouveau avec succès upgrade --install !

Alternativement, cela a fonctionné pour moi:

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

fixé par kubectl -n $namespace delete secret -lstatus=pending-upgrade
Exécutez à nouveau la barre.

Je ne sais pas pourquoi cela est fermé, je viens de le frapper avec le tout nouveau Helm 3.3.4. Si l'installation initiale échoue, la deuxième mise à niveau de la barre --install --force affiche toujours la même erreur. Toutes ces solutions de contournement fonctionnent, mais sont manuelles , elles n'aident pas lorsque vous voulez un CI / CD complètement et 100% automatique où vous pouvez simplement pousser le correctif pour déclencher un autre déploiement sans effectuer de nettoyage manuel.

Quelqu'un a-t-il pensé à simplement ajouter un indicateur indiquant qu'il s'agit de la première version, il devrait donc être prudent de simplement le supprimer automatiquement? Ou en ajoutant quelque chose comme "--force-delete-on-failure"? Ignorer le problème ne va pas aider.

@ nick4fake AFIK il a été fermé par PR # 7653. @yinzara pourra peut-être fournir plus de détails.

C'était une décision des responsables de ne pas autoriser l'écrasement d'une version en attente de mise à niveau. Mais votre déclaration selon laquelle tous les contournements sont des contournements qui ne fonctionnent pas dans un pipeline CI / CD n'est pas vraie. La dernière solution suggérée pourrait être ajoutée en tant qu'étape de construction avant d'exécuter la mise à niveau de votre barre (je n'utiliserais pas non plus --force dans un pipieline CI / CD). Il a le même effet que ce que vous avez suggéré, sauf qu'il supprime la version juste avant d'installer la prochaine version au lieu de vous permettre immédiatement après de déboguer la cause de l'échec.

J'ai également utilisé les éléments suivants dans ma version automatisée pour désinstaller toutes les versions "en attente" avant d'exécuter ma commande de mise à niveau (assurez-vous de définir la variable d'environnement NS_NAME sur l'espace de noms dans lequel vous effectuez le déploiement):
`` bash

! / usr / bin / env bash

RELEASES = $ (helm list --namespace $ NS_NAME --pending --output json | jq -r '. [] | Select (.status == "pending-install") | .name')
si [[ ! -z "$ RELEASES"]]; ensuite
helm delete --namespace $ NS_NAME $ RELEASES
Fi

@yinzara merci pour l'extrait, il est très utile pour ceux qui trouvent ce fil.

Mon point est toujours valable - il n'est pas sûr de simplement supprimer la version. Pourquoi Helm ne peut-il pas forcer la mise à niveau de la version si une seule ressource échoue? Le remplacement de la version par une nouvelle version semble être une meilleure solution que la suppression complète. Je ne comprends peut-être pas certains principes fondamentaux de Helm (comme la façon dont il gère l'état), donc ce n'est peut-être pas possible de le faire, mais je ne comprends toujours pas pourquoi il vaut mieux forcer les utilisateurs à intervenir manuellement si la première installation échoue.

Je veux dire, il suffit de consulter ce fil de discussion, les gens sont toujours confrontés au problème. Que pensez-vous de l'ajout éventuel d'informations supplémentaires au message d'erreur Helm avec un lien vers ce fil + quelques suggestions sur ce qu'il faut faire?

@ nick4fake Je pense que vous

Les responsables de la bibliothèque sont d'accord avec vous sur les versions ratées, c'est pourquoi ils ont accepté mon PR.

Une version "échouée" PEUT être mise à niveau. C'est ce que mon PR a fait. Si une version échoue parce que l'une des ressources a échoué, vous pouvez simplement mettre à niveau cette version (c'est-à-dire que la mise à niveau --install fonctionne aussi) et elle ne donnera pas l'erreur "app-name" n'a pas de versions déployées.

Vous parlez d'une version "en attente d'installation". Les responsables ne pensent pas qu'il soit sûr de vous permettre de mettre à niveau une version en attente d'installation (forcée ou non) car elle pourrait éventuellement être encore en cours ou être dans un état partiellement achevé qui, selon eux, ne peut pas être résolue automatiquement. Mon PR a initialement autorisé cet état et les responsables m'ont demandé de le supprimer.

Si vous trouvez vos versions dans cet état, vous souhaiterez peut-être reconsidérer votre configuration de déploiement. Cela ne devrait jamais se produire dans un pipeline CI / CD correctement configuré. Il devrait échouer ou réussir. «En attente» signifie que l'installation a été annulée alors qu'elle était encore en cours de traitement.

Je ne suis pas un responsable de la maintenance, donc mon opinion sur votre suggestion n'est pas pertinente, mais je ne trouve aucune mention dans la base de code d'un problème Github qui est en fait imprimé dans une erreur ou un message, donc je parie qu'ils ne le permettront pas, mais vous soyez les bienvenus pour mettre sur pied un PR et voir :-)

Cela étant dit, je ne suis pas d'accord avec votre déclaration selon laquelle votre argument est toujours valable. Ma suggestion peut supprimer la version en attente, mais @abdennour la suggestion juste avant la vôtre consiste simplement à supprimer le secret qui décrit la version d'installation en attente. Si vous faites cela, vous ne supprimez aucune des ressources de la version et pouvez mettre à niveau la version.

Que pensez-vous de l'ajout éventuel d'informations supplémentaires au message d'erreur Helm avec un lien vers ce fil + quelques suggestions sur ce qu'il faut faire?

+1 à cela. Nous devons encore chercher sur Google, trouver ce fil de discussion, comprendre ce qu'est une version pending-install , afin que nous puissions commencer à raisonner à propos de ce message d'erreur.

J'ai eu des problèmes avec helm upgrade et cela m'a conduit ici. Il a été résolu en ajoutant -n <namespace> . Peut-être que cela aidera quelqu'un là-bas.

Pour Helm3, pourrait être résolu via le patch
kubectl -n <namespace> patch secret <release-name>.<version> --type=merge -p '{"metadata":{"labels":{"status":"deployed"}}}'

release-name et version - Visible à partir de kubectl get secrets -n <namespace> | grep helm