<p>helm upgrade --install ne fonctionne plus</p>

Je pensais que je rencontrais le même problème, mais il s'est avéré que j'avais juste une ancienne version de suppression (mais pas purgée), qui traînait. vérifiez helm list -a , et si votre version est là, helm delete --purge releasename. helm upgrade -i fonctionne avec succès sur 2.7.2 pour moi.

Il s'agit d'un effet secondaire de la résolution des problèmes liés à la mise à niveau des versions qui étaient en mauvais état. https://github.com/kubernetes/helm/pull/3097 était le PR qui a résolu ce problème. Y a-t-il un cas limite ici que nous n'avons pas réussi à attraper ?

Vérifiez helm list -a comme @tcolgate l'a mentionné, en expliquant peut-être également comment le reproduire serait également utile pour déterminer s'il s'agit d'un cas limite non détecté ou d'un bogue.

Ayant également le même problème, avec des noms de version en double :

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

Lors de la mise à niveau, quel message s'affichait ?

même erreur que le diff ci-dessus, mais une installation dirait qu'il est déjà installé.

Je veux dire dans les tentatives de mise à niveau précédentes qui se sont soldées par un état ÉCHEC. Je veux savoir comment nous nous retrouvons dans une situation où toutes les versions sont en échec.

Ohh, les déploiements de noms de version en double ? Ça je n'en suis pas sûr, je le reçois assez souvent. Parfois, ils sont tous dans un état DÉPLOYÉ, parfois un mélange d'ÉCHEC et DE DÉPLOIEMENT. Nous utilisons un serveur Jenkins CI/CD qui met constamment à jour chaque fusion de relations publiques. Nous effectuons donc plusieurs helm upgrade par jour, en n'ayant généralement qu'une nouvelle étiquette de conteneur. Habituellement, les doublons sont simplement ennuyeux lorsque l'on regarde ce qui est déployé, c'était la première fois que nous avions un problème difficile avec eux, et normalement nous ne mettons pas à niveau le contrôleur d'entrée comme nous l'étions dans ce cas.

Il semble que je me sois retrouvé avec quelque chose de similaire, je vois quelques doublons dans mes listes de versions :

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

Tous semblent être dans un état DÉPLOYÉ, mais il se pourrait bien qu'une mise à niveau précédente ait échoué à un moment donné, car j'ai rencontré ce bogue plusieurs fois. Je suis toujours sur K8S 1.7, donc je n'ai pas encore mis à jour vers la barre 2.7.

Même problème, impossible de mettre à niveau sur le déploiement ÉCHEC

Idem ici en utilisant 2.7.2. La première tentative de libération a échoué. Ensuite, lorsque j'ai essayé une mise à niveau --install, j'ai l'erreur "Erreur : ÉCHEC DE LA MISE À JOUR : "${RELEASE}" n'a pas de versions déployées".

Même problème ici avec la 2.7.2, helm upgrade --install échoue avec :

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

Si la version est entièrement purgée avec helm del --purge APPNAME alors une upgrade --install fonctionne correctement.

Je rencontre le même problème. Combiné avec #3134 qui ne laisse aucune option pour les déploiements idempotents automatisés sans quelques scripts pour contourner.

@winjer vient d'essayer de supprimer avec --purge et pour moi, cela n'a pas fonctionné bien que l'erreur ait changé
/ # helm upgrade foo /charts/foo/ -i --wait
Erreur : ÉCHEC DE LA MISE À JOUR : « foo » n'a aucune version déployée
/ # helm delete --purge foo
release "foo" supprimé
/ # helm upgrade foo /charts/foo/ -i --wait
La version "foo" n'existe pas. L'installer maintenant.
Erreur : échec de la version de foo : deploys.extensions "foo-foo-some-service-name" existe déjà

@prein C'est parce que vous avez un service qui n'est pas "propriétaire" par helm, mais qui existe déjà dans le cluster. Le comportement que vous rencontrez me semble correct. Le déploiement ne peut pas réussir car helm devrait "s'approprier" un objet API qu'il ne possédait pas auparavant.

Il est logique de pouvoir mettre à niveau une version ÉCHEC, si le nouveau manifeste est réellement correct et ne se contente d'aucune autre ressource dans le cluster.

Je constate également ce comportement sur une version appelée content :

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

Je devrai supprimer ceci pour pouvoir continuer à déployer, faites-moi savoir s'il y a quelque chose que je peux faire pour aider à déboguer cela.
(Je pense que nous devrions renommer le problème, car il s'agit plutôt de doublons ?)
(nous courons aussi 2.7.2 )

J'ai en fait une autre version en double sur mon cluster, si vous avez une commande à exécuter pour aider à déboguer cela ? Fais-moi savoir!

vient de passer à la barre franche 2.7.2 et nous voyons la même chose. helm delete RELEASE_NAME suivi de helm upgrade RELEASE_NAME . échoue avec Error: UPGRADE FAILED: "RELEASE_NAME" has no deployed releases . upgrade est le moyen prévu pour restaurer une version supprimée (mais pas purgée), n'est-ce pas ?

On dirait que vous pouvez restaurer la version en revenant à la version supprimée.

voir le même problème avec v2.7.2 , échoue lorsqu'il n'y a pas de versions précédentes déployées avec succès

Voir également deux versions potentielles de ce problème :

en CI :

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

sur ma machine locale :

(à la fois sur mon OSX bash et dans un conteneur gcloud/kubectl)

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

Les avertissements sont normaux pour notre graphique.
Les erreurs sont intéressantes car l'un de nos sous-graphiques contient un pvc.yaml .

helm del --purge <release> atténue le problème.
Cela rend notre pipeline CI difficile à mettre à niveau.

@adamreese quelle est la résolution finale de ce problème ? Nous sommes sur 2.8 et nous ne pouvons toujours pas mettre à jour une version précédente de FAILED avec le changement vers helm list .

En particulier, nous rencontrons les types de problèmes suivants :

• déployer une version, OK
• upgrade --install --wait , mais peut-être qu'il y a un petit bug et que --wait ne réussit pas (par exemple, les sondes de vivacité ne le résolvent jamais)
• après avoir corrigé le graphique, upgrade --install --wait échoue avec xxx has no deployed releases

La suppression/purge n'est pas souhaitable ou acceptable ici : la version peut avoir plusieurs ressources (pods, équilibreurs de charge) qui ne sont pas affectées par la seule ressource qui ne montera pas. Dans les versions précédentes de Helm, upgrade --install nous permettait de ne corriger que le changement qui cassait la version complète sans avoir à supprimer toutes les ressources.

Helm est le propriétaire de toutes les ressources impliquées à tout moment ici -- la ressource n'est marquée que FAILED car --wait n'a pas réussi à attendre que toutes les ressources soient en bon état. Je suppose que la même chose se produira si un pod est un peu trop lent à démarrer et dans de nombreux cas similaires.

@peay voir #3353 pour une discussion de suivi.

Merci -- cela s'éclaircit. En fait, nous avons réalisé que nous n'étions en train de le frapper que lorsque nous n'avions pas eu de sortie réussie pour commencer. Dans ce cas, la purge est une bonne solution de contournement.

Cela se produit toujours si l'installation échoue.
Vous devez purger et réessayer.

UPGRADE FAILED: "API" has no deployed releases
alors vous devez purger manuellement
helm delete --purge API
et ça marchera.

À partir de helm 2.9, vous pouvez également effectuer helm upgrade --install --force afin qu'il n'y ait pas besoin de purger. Pour les versions précédentes :

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

@bacongobbler Je suis toujours confus à propos de ce comportement.
Pourriez-vous répondre https://github.com/kubernetes/helm/pull/3597#issuecomment-382843932 quand vous avez le temps ?

Merci pour votre travail à ce sujet.

Sûr. Je suis AFK pour le moment mais je peux répondre plus tard ce soir. Comprenez parfaitement la confusion et je vais essayer de répondre à vos questions du mieux que je peux. C'est juste fou au bureau de préparer d'autres trucs pour KubeCon EU. :)

Je suis prêt à aider à pirater cela et/ou à améliorer les documents lorsque nous sommes là-bas.
Rencontrons-nous définitivement :+1:

@bacongobbler fait cette adresse #3353 et annule le tas de code que j'ai écrit dans le cadre de #4004 ?

Dans mon cas, helm upgrade --install --force fait un delete --purge et ensuite une installation.

Est-ce le comportement attendu ? J'ai presque perdu 2 mois de travail à cause de ça. Quand est-ce que force commencé à signifier delete ?

^ J'ai eu quelques conversations avec des gens de kubecon et j'ai découvert que de nombreuses équipes sont épinglées sur la version 2.7.0 à cause de ce changement de comportement.

Je suis d'accord que upgrade install ne devrait jamais être destructeur, même avec tout ce que --force pourrait jamais signifier.

@bacongobbler , désolé je n'ai pas pu me rencontrer quand nous étions à CPH.
Existe-t-il une documentation expliquant la justification du changement de comportement pour ne pas autoriser la mise à niveau d'une version ayant échoué ?
L'ancien comportement semble beaucoup plus souhaitable que ce que nous avons maintenant.

Voir le deuxième commentaire dans https://github.com/kubernetes/helm/issues/3353 pour le contexte sur les raisons pour lesquelles nous avons dû faire ce changement

Je suis vraiment curieux d'entendre quelle est la voie proposée pour l'avenir. Nous ne pouvons pas revenir en arrière sur #3097 en raison des problèmes démontrés dans #3353, donc j'aimerais savoir ce que la communauté pense être la bonne voie à suivre pour résoudre ce problème. Nous pouvons revenir sur #3597, mais d'après ce que j'ai entendu, il n'y a pas de bonne solution pour résoudre le problème de helm upgrade --install . :désappointé:

Je sais que nous travaillons à retravailler la logique d'application pour Helm 3 mais c'est un long chemin

Merci d'avoir mis ce lien @bacongobbler :)
Votre suggestion ici semble être une approche raisonnable :

il peut être utile de ne pas effectuer de comparaison lorsqu'aucune version réussie n'a été déployée. L'expérience serait la même que si l'utilisateur exécutait helm install pour la toute première fois dans le sens où il n'y aurait pas de version "actuelle" contre laquelle comparer. Je serais un peu préoccupé par certains cas limites cependant. @adamreese avez-vous des opinions sur celui-ci?

Cela nous permettrait de revenir sur #3597 puisque le seul cas d'échec (rien contre quoi diff) serait traité.
Cela rend upgrade --install non destructif à nouveau et plus similaire à kubectl apply .

Intuitivement, c'est ce que j'attendrais d'un upgrade --force : ne faites pas d'opérations de diff-and-patch mais appliquez simplement le modèle complet, en ignorant ce qui est en place pour le moment. Je ne peux pas vraiment penser à des raisons techniques pour lesquelles cela ne serait pas possible, mais je ne connais pas non plus le fonctionnement interne de Helm.
Cela peut toujours être une opération dangereuse, mais toute personne utilisant un indicateur --force s'attend normalement à un certain risque en forçant les mises à jour. Bien que je dirais que l'on ne s'attend pas à ce que cela supprime et recrée votre déploiement, avec des temps d'arrêt potentiels.

J'ai lu les discussions, mais je ne sais toujours pas comment avoir une commande idempotente upgrade --install (ou une séquence de commandes).

Avec la version stable actuelle, comment puis-je y parvenir dans un script automatisé ? Je dois pouvoir déployer de manière non interactive sans utiliser delete --purge , même si une tentative précédente a échoué.

En ce qui concerne les plans futurs, c'est le comportement que j'attendais à l'origine de upgrade --install :

• Installer si aucune installation précédente n'a été effectuée
• Mettre à niveau une installation précédemment réussie
• Remplacer une installation précédemment échouée
• Si l'installation échoue, les anciennes ressources doivent toujours être en place, sans temps d'arrêt dans la mesure du possible
• Aucune opération destructrice (comme le delete --purge automatique mentionné ci-dessus)

À mon avis, aucun indicateur supplémentaire ne devrait être requis pour ce comportement. C'est ainsi que les gestionnaires de paquets se comportent généralement. À moins d'avoir mal compris les exigences, je ne pense pas qu'un indicateur --force , par exemple, soit nécessaire.

Y a-t-il eu des mises à jour à ce sujet ? Quelle est la bonne manière d'exécuter de manière fiable une mise à niveau sur une installation existante sans avoir à exécuter une purge en cas d'échec ?

@MythicManiac FWIW :
J'ai toujours épinglé nos équipes sur la v2.7.0 à cause de ce comportement.
Nous ne semblons pas avoir de problèmes avec la mise à niveau et la suppression des ressources lorsqu'elles sont censées utiliser helm upgrade --install avec cette version.

Nous avons aussi ce problème. C'est très ennuyeux que je doive supprimer les services K8s et les ELB AWS associés car helm has no deployed releases . Le gestionnaire de packages est génial, mais ce problème entraîne un temps d'arrêt de la production, ce qui n'est pas bon.

En guise de solution de contournement très difficile, si le problème avec le déploiement d'origine est
résolvable (par exemple un service préexistant.), Faire une restauration à l'original
la libération échouée peut fonctionner.

Le vendredi 5 octobre 2018, 18:13 Eugene Glotov, [email protected] a écrit :

Nous avons aussi ce problème. C'est très ennuyeux que je doive supprimer les K8
services et les ELB AWS associés, car helm n'a pas de versions déployées. le
gestionnaire de paquets est génial, mais ce problème entraîne des temps d'arrêt de la production qui
n'est pas bon.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/helm/helm/issues/3208#issuecomment-427436187 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AAEo8_pISzHFAuOz6Lsv5EjrFaEo_HkYks5uh5M7gaJpZM4Qtexz
.

@tcolgate , merci ! Je viens de résoudre un autre problème (https://github.com/helm/helm/issues/2426#issuecomment-427388715) avec votre solution de contournement et j'essaierai de le tester pour les ELB existants lorsque je déploierai un nouveau graphique la semaine prochaine sur les ressources existantes .

Faire un retour à la version originale qui a échoué peut fonctionner.

@tcolgate , je viens de tester et non, cela ne fonctionne pas dans le cas du premier déploiement.

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

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

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

Je suis curieux de savoir si Helm ne peut pas déployer un graphique sur les ressources existantes, alors pourquoi helm delete entraîne la suppression exacte de ces ressources ?

@thomastaylor312 , nous avons rencontré ce problème ~ainsi que https://github.com/helm/helm/issues/2426~ (up: j'ai trouvé la véritable cause de 2426) avec helm 2.11.0. Pensez-vous qu'ils devraient être rouverts?

J'ai trouvé ce fil après un Error: UPGRADE FAILED: "xxx-service" has no deployed releases
Alors qu'il était visible depuis une barre ls -a.

J'ai décidé de voir s'il s'agissait d'un problème à cause d'une valeur --set incorrecte, et --debug --dry-run --force en fait TOUJOURS supprimé mon pod en cours d'exécution ... je m'attendais à ce qu'une action de simulation ne modifie JAMAIS ressources du cluster.

Cela a fonctionné cependant, et le service pourrait être redéployé par la suite, mais nous avons connu des temps d'arrêt.

je m'attendais à ce qu'une action de simulation ne modifie JAMAIS les ressources du cluster.

C'est une attente juste - nous devrions faire en sorte que... ne se produise pas

Je pense que cela a été corrigé dans https://github.com/helm/helm/pull/4402 mais ce serait bien que quelqu'un vérifie. Désolé pour ça!

même problème après la mise à niveau vers 2.11.0

Poste croisé :
https://github.com/reactiveops/reckoner/issues/48#issuecomment -453411283

Pourquoi est-ce fermé ? Avons-nous une bonne façon de gérer cela maintenant?

@gerbsen , il n'y a pas de moyen de contourner cela avec les versions actuelles de Helm qui ne sont pas destructrices.
Nous utilisons toujours Helm 2.7.0 pour tout dans mon organisation. C'est une très ancienne version qui a d'autres bogues, mais elle n'a pas ce problème.

Je viens de faire helm upgrade --install --force faire un delete --purge et détruire mon pvc/pv sans me le dire (sur le recyclage). Avait plusieurs versions échouées, il était donc dans un état où il s'exécutait dans kubernetes, mais helm pensait qu'il n'y avait aucune version en cours d'exécution. Pas du tout de bons moments.

@notque après avoir perdu tous les tableaux de bord grafana deux fois, j'ai commencé à faire des sauvegardes avant de faire toute mise à niveau, ce genre de risque supprime tous les avantages de l'utilisation de helm

Pour ceux qui recherchent de l'aide, le problème a disparu pour moi après la mise à niveau de helm vers la v.2.15.2

Je vois toujours ce problème sur 2.16.0

Pourquoi est-il toujours fermé ? 2.16.1 est toujours affecté

@nick4fake Je pense que c'est un doublon de https://github.com/helm/helm/issues/5595