Helm: `helm upgrade --install` n'effectue pas une installation / mise à niveau si la première installation échoue

C'était intentionnel par conception de https://github.com/kubernetes/helm/pull/3097. Fondamentalement, la différence avec un déploiement échoué a provoqué un comportement indésirable, notamment cette longue liste de bogues:

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

Si votre version initiale se retrouve dans un état d'échec, nous vous recommandons de purger la version via helm delete --purge foo et de réessayer. Après une version initiale réussie, toutes les versions ayant échoué suivantes seront ignorées et helm effectuera une comparaison avec la dernière version réussie connue.

Cela étant dit, 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 effectuer une comparaison. Je serais un peu préoccupé par certains cas extrêmes. @adamreese avez-vous des opinions sur celui-ci?

Le correctif suggéré semble totalement intenable dans un système automatisé. Je ne veux certainement pas que tout ce qui appelle helm doit savoir "si la première version échoue, supprimez et réessayez". D'une part, la plupart de mes outils ne savent pas s'il s'agit d'une installation ou d'une mise à niveau, ou si c'est la première ou la 100e fois, il exécute presque toujours helm upgrade --install .

Je voudrais également signaler que j'ai commenté le PR original https://github.com/kubernetes/helm/pull/3097#discussion_r151808599 en posant spécifiquement des questions sur cette affaire.

L'ancien comportement était meilleur pour ce cas.
Je suis d'accord avec @chancez. Cela rend upgrade --install non idempotent pour une occurrence courante.

@bacongobbler
Si nous craignons que les versions échouent et laissent des éclats d'obus en raison de crochets échoués, je dirais que c'est un problème de conception du graphique. (Les hameçons fonctionnent mieux lorsqu'ils sont idempotents)
Les utilisateurs sont libres de créer une gestion des erreurs et un comportement non idempotent autour de la barre.

De quels autres cas extrêmes sommes-nous préoccupés?
Il semble que le # 3097 s'occupe de beaucoup 👍

Mon développement local irait beaucoup plus facilement si je pouvais rendre helm upgrade -i idempotent même contre les versions ayant échoué pour au moins une combinaison d'arguments. Mon cas d'utilisation est lorsque j'ai un script de nombreuses versions que je sais que je veux me lever pour démarrer un environnement de développement local.

Cela peut être analogue à l'indicateur --replace pour helm install . Notez que --replace est l'un des deux seuls indicateurs de helm install manquant dans helm upgrade , l'autre étant --name-template .

Pour être absolument clair, oui, ce serait une bonne chose à corriger. Quelqu'un veut-il essayer pendant que nous avons les mains pleines d'autres travaux?

Salut,
J'ai créé un PR https://github.com/kubernetes/helm/pull/3437 qui devrait résoudre ce problème

Je ne sais pas pourquoi nous avons besoin des commandes install et upgrade , je n'utilise que la commande upgrade --install et il semble que beaucoup de gens font de même. J'ai juste besoin d'une commande qui fait upgrade --install et ne trébuche pas sur une exécution échouée. Pouvons-nous simplement renommer upgrade --install en deploy , le rendre vraiment idempotent et abandonner les deux autres?

(J'ai du mal avec une nouvelle variante ce problème de comportement dans la 2.8.0. Depuis la mise à niveau de 2.7.2 maintenant si j'ai une installation échouée, puis delete --purge it, et le upgrade --install it , Je peux toujours obtenir l'erreur Error: UPGRADE FAILED: "xyz" has no deployed releases . On dirait que --purge n'est pas pleinement efficace dans la version 2.8.0 et que le tiller a un état bloqué qui n'apparaît pas dans list --all . Je dois puis à un install pour ramener la barre dans un état où je peux refaire le upgrade --install habituel.)

Je suis d'accord avec @whereisaaron , je serais bien avec une commande deploy qui fonctionnait plus comme kubectl apply . Rend l'automatisation de Helm beaucoup plus facile aussi, puisque vous n'avez pas à vérifier les versions existantes dans une folie de script shell :)

Peut-être que la solution est que helm exécute automatiquement helm delete --purge ?
Quelque chose comme:
1) L'utilisateur exécute helm upgrade --install
2) La première version échoue
3) L'utilisateur apporte des modifications au graphique et exécute à nouveau helm upgrade --install
4) Helm essaie d'exécuter la commande
5) Il échoue et il y a précisément une version antérieure en état d'échec
6) Helm exécute silencieusement helm delete --purge
6) Après la purge, Helm essaie automatiquement helm upgrade --install et affiche la sortie de cela

Peut-être que ce comportement pourrait être déclenché via l'indicateur --force qui a déjà un comportement similaire pour d'autres scénarios

Bonne idée, mais je ne pense pas que nous devrions jamais supprimer le registre des versions sans que l'utilisateur ne demande explicitement de supprimer ces données. Les opérateurs de Helm voudront savoir pourquoi le service n'a pas pu être mis à niveau à partir de versions ayant échoué précédemment, ou en déduire les échecs en collectant ces données à partir du grand livre.

J'ai fourni un commentaire plus tôt dans le fil de discussion qui décrit une solution au problème. C'est similaire à votre solution en exécution, mais sans qu'il soit nécessaire de supprimer l'intégralité du registre des versions. Je crois que # 3437 tente d'appliquer cette solution sous forme de patch.

@rchernobelskiy m'arrive aussi. Exactement comme vous le décrivez.

Je rencontre ce problème peut-être une fois par jour lors du déploiement de nouvelles applications.
C'est une douleur!

@gmanolache Nous sommes toujours à la barre 2.7.0 pour cette raison.
Je ne sais pas si la mise à niveau pour utiliser l'indicateur --force est sûre: commentaire

Si vous avez besoin de rétrograder, voici un bon moyen de le faire: rétrograder à la version 2.7.0

Quelles sont ces informations de diagnostic utiles et comment y parvenir? :le sourire:

Je crains que ce qui suit puisse être lu comme de mauvaise humeur, c'est vraiment juste une invitation à des conseils sur la façon dont nous pouvons obtenir des informations de diagnostic lorsque vous avez un déploiement échoué. Parce qu'il semble vraiment que je manque quelque chose. On dirait que l'état défaillant est censé avoir une certaine utilité pour les opérateurs? J'ai de nouveau parcouru le site manuel de la barre; Quelque chose comme «helm get manifest» fonctionnera-t-il en état d'échec pour extraire des informations de diagnostic utiles?

Mon expérience utilisateur lorsque j'obtiens un déploiement échoué est que vous n'obtenez aucune information utile. Helm désavoue toutes les ressources partiellement créées / restantes de sorte que «l'état de la barre» ne montre rien. Tout ce que vous pouvez faire est «rollback» ou «delete --purge» (vous ne pouvez pas simplement «supprimer» ou votre CI «upgrade --install» échouera). L'état d'échec ne semble servir qu'à briser l'idempotence de «upgrade --install» dont nous rêvons tous pour nos déploiements CI.

Serait-il raisonnable d'avoir une option «--auto-rollback» pour les situations CI, par exemple «upgrade --install --auto-rollback». Je préfère généralement un retour en arrière qui doit sortir du lit pour faire face à un état défaillant 😆 😴 💤

Quelles sont ces informations de diagnostic utiles et comment y parvenir? 😄

helm help history

Merci @bacongobbler. Ok, je comprends que cette liste est ce que l'on entend par grand livre. Et si vous avez toujours le grand livre, que vous pouvez utiliser helm get manifest --revision 123 pour voir ce qui a échoué? C'est certainement utile à préserver. Et si nous rollback nous ne perdons pas cette information.

History prints historical revisions for a given release.

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

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

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

Si nous avions helm upgrade --install --auto-rollback le déploiement échoué serait enregistré dans le registre et disponible pour les opérateurs. Et cela contribuerait grandement à empêcher les déploiements de CI d'arriver à l'état intraitable `` échoué '' où la `` mise à niveau de la barre --install '' cesse de fonctionner. Les déploiements de CI échoués sont généralement des développeurs qui injectent des fautes de frappe / erreurs dans le système de déploiement. Avec '--auto-rollback', ils peuvent inspecter le message d'erreur de la commande helm conservé dans le journal du serveur de déploiement, corriger et déployer les valeurs corrigées.

Je suppose que même sans l'option '--auto-rollback', nous pourrions utiliser un automate wrapper pour exécuter helm rollback tout moment helm update --install renvoie une erreur 'FAILED'. Et peut-être détecter où se trouve l'installation initiale, et helm delete --purge place dans ces cas.

Autrement dit, nous pourrions créer un script wrapper pour nous assurer que les résultats d'une CI «mise à niveau de helm --install» sont toujours un état où la prochaine «mise à niveau de helm --install» de CI sera toujours possible. Tout en conservant les informations du grand livre pour toutes les tentatives infructueuses (au moins pour les versions dont l'installation initiale a fonctionné).

helm deploy =

• helm upgrade --install
• si FAIL alors
  
  
  
  • si révision = 1
  
  
  • puis helm delete --purge
  
  
  • sinon helm rollback
  
  

@whereisaaron ce serait élégant 👍

Existe-t-il un moyen simple d'obtenir la dernière version de travail autre que quelque chose comme helm history ${name} | tail -2 | head -1 | awk '{print $1}' , à utiliser par helm rollback ?

Bonjour,

J'utilise Helm 2.12.2 et j'ai toujours le problème, cette barre échoue, lorsque le premier déploiement échoue. Est-ce une régression peut-être?

Je ne suis pas sûr que ce soit une régression, mais cela n'a jamais été réellement «corrigé».

@ RickS-C137 Je pense que cela est censé être corrigé en utilisant helm upgrade --install --force qui "supprimera" puis "installera - remplacer" une version qui a échoué.

J'essaie toujours de résoudre ce problème dans un pipeline Jenkins que j'essaie d'utiliser.
J'essaye de déployer une nouvelle image de mon application et je m'en fiche si le déploiement existe déjà ou non.
Je souhaite exécuter une commande qui remplace le déploiement actuel ou l'installe simplement s'il n'existe pas.
J'ai essayé helm install --replace J'obtiens souvent Error: a released named xyz is in use, cannot re-use a name that is still in use Ce qui tue évidemment mon pipeline et la construction échoue.

@bacongobbler Que pensez-vous de https://github.com/helm/helm/issues/3353#issuecomment -385222233?

Je ne vois pas comment il y aurait des temps d'arrêt ou des pertes de données si nous détruisions et recréions la version initiale si la version initiale échouait.

J'ai implémenté ceci dans notre build:

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

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

Avec helm actuellement, vous ne savez pas quelle combinaison commande + options de barre utiliser sans inspecter l'état actuel. Et pour une commande de barre donnée, vous ne savez pas ce que vous allez obtenir, car cela dépend de l'état actuel. Ce n'est pas vraiment le rêve déclaratif de l'état souhaité ☁️ 💤 😄

Dans helm 3, nous pouvons potentiellement désapprouver install / upgrade / --replace / --upgrade / --force et les remplacer tous par un idempotent helm deploy qui atteint l'état souhaité ou laisse l'état inchangé. Peut-être en utilisant un algorithme similaire à ci - helm deploy échoue, annule (révision> 1) ou supprime + purges (révision = 1), pour laisser l'état tel qu'il était avant. Le manifeste ayant échoué serait toujours disponible via helm history/get . Et il pourrait même y avoir une option '--no-rollback' pour les personnes qui souhaitent préserver le déploiement dans un état d'échec pour enquête

L'option de helm upgrade --install --force se rapproche, sauf qu'au lieu de revenir en arrière et de mettre à niveau, elle supprime et remplace les versions ayant échoué (même pour les révisions> 1), ce qui met certaines personnes en colère contre # 3208 ... 😮 ⚡️ 💥

Pour l'instant, nous pouvons utiliser des scripts wrapper ou des méta-outils comme helmsman dont la liste de fonctionnalités est en partie pour utiliser helm mais atténuer ce problème:

• Idempotence : tant que votre fichier d'état souhaité ne change pas, vous pouvez exécuter Helmsman plusieurs fois et obtenir le même résultat. _ [... quel que soit l'état actuel] _
• Continuer à partir des échecs : dans le cas d'un déploiement partiel dû à un échec de déploiement de graphique spécifique, corrigez votre graphique de barre et exécutez à nouveau Helmsman sans avoir à annuler d'abord les succès partiels.

remplacez-les tous par un déploiement de barre idempotent qui soit atteint l'état souhaité, soit laisse l'état inchangé

Rétrospectivement, c'est un objectif de conception à couper le souffle.

Salut,
Dans notre cas, la version initiale n'a pas vraiment échoué ... C'est juste que notre application n'était pas complètement opérationnelle lorsque le délai d'installation s'est écoulé ou qu'un autre problème étrange a été corrigé. Dans tous les cas, l'application fonctionne parfaitement bien, et donc devoir la supprimer serait un problème pour nous (nous avons un stockage persistant attaché qui serait également supprimé !!).

Existe-t-il une solution de contournement pour déployer un graphique lorsque la version initiale `` a apparemment échoué '', mais que cela fonctionne vraiment?

Alors, est-ce que la conclusion que upgrade --force est trop forte, c'est-à-dire qu'il y a des moments où une suppression + remplacement + retry_upgrade n'est pas une solution correcte à l'échec de la mise à niveau?

Y a-t-il un problème distinct qui suit l'idée de fusionner install & upgrade dans une commande deploy ?

Pas que je connaisse @dcow. Quel est le cas d'utilisation de la commande helm upgrade --install ?

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

Je ne sais pas pourquoi nous avons besoin des commandes d'installation et de mise à niveau, je n'utilise que la commande upgrade --install et il semble que beaucoup de gens font de même. J'ai juste besoin d'une commande qui met à jour --install et ne trébuche pas sur une exécution ratée. Pouvons-nous simplement renommer upgrade --install pour déployer, le rendre vraiment idempotent et abandonner les deux autres?
...

et

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

Avec helm actuellement, vous ne savez pas quelle combinaison commande + options de barre utiliser sans inspecter l'état actuel. Et pour une commande de barre donnée, vous ne savez pas ce que vous allez obtenir, car cela dépend de l'état actuel. Ce n'est pas vraiment l'état déclaratif souhaité dream cloud zzz smile

Dans helm 3, nous pouvons potentiellement désapprouver install / upgrade / --replace / --upgrade / --force et les remplacer tous par un déploiement de helm idempotent qui soit atteint l'état souhaité, soit laisse l'état inchangé.
...

Je suis généralement d'accord pour dire que helm devrait fonctionner comme kubectl apply et tenter d'atteindre la réalité souhaitée plutôt que d'exécuter différents types de commandes en fonction de l'état de votre cluster. J'espérais ajouter le support à un problème dédié s'il en existait un ou au moins déterminer quelle était la résolution puisque deploy n'est pas actuellement implémenté et que nous sommes sur helm 3.2.

@dcow Ok, voulez-vous créer un problème avec votre proposition?

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