Helm: ECHEC DE LA MISE À NIVEAU: aucune ressource portant le nom "" n'a été trouvée

Je rencontre un problème similaire où j'ai un graphique avec des dépendances groupées. Si j'ajoute une nouvelle dépendance et que j'exécute un helm upgrade le résultat est le même que celui décrit. Les ressources sont correctement créées mais helm renvoie une erreur.

Donc, si cela est installé: helm install -n my-release

my-thing/
  Chart.yml
  charts/
    depended-upon-thing/

Et puis un nouveau graphique est ajouté en tant que dépendance:

my-thing/
  Chart.yml
  charts/
    depended-upon-thing/
    new-dependency/

Lorsque la version est mise à niveau avec: helm upgrade my-release my-thing helm génère l'erreur suivante:

Error: UPGRADE FAILED: No resource with the name new-dependency found.

@devth Je ne parviens pas à reproduire ce problème sur master. Constatez-vous toujours ce problème? Quelle version de barre / barre utilisez-vous?

Merci!

@elementalvoid J'ai également été incapable de reproduire la nouvelle erreur de dépendance sur master. Constatez-vous toujours ce problème? Quelle version de barre / barre utilisez-vous?

Merci.

À l'époque, j'étais sur alpha 4. En utilisant l'exemple d'alpha 5 et de @devth , je n'ai pas non plus pu reproduire le problème.

Bien. Je vais fermer ça pour l'instant. N'hésitez pas à signaler un problème si vous rencontrez à nouveau l'un de ces problèmes.

Merci encore.

@michelleN merci! Désolé, je n'ai pas eu le temps cette semaine de tenter une repro sur le maître. Dans l'attente d'une mise à niveau bientôt!

Idem pour moi lors du déplacement d'une spécification de déploiement / volume hostPath vers PVC.
Un bug semble se produire lorsqu'un manifeste de mise à niveau dépend d'un nouveau ("manquant" dans l'ancien?)
version: 2.7.2

Étrange, je vois le même comportement en essayant de mettre à niveau un graphique dans la version 2.7.2 avec un nouveau rôle. Tiller se plaint de ne pas trouver le rôle et d'échouer les déploiements, même s'il a vraiment créé le rôle.

Ma situation était que j'avais une nouvelle ressource, et j'ai déployé la nouvelle version du graphique de barre avec la nouvelle ressource. Ce déploiement a échoué car j'ai gros doigts sur du yaml. Eh bien, les nouveaux objets ont été créés dans kubernetes. J'ai corrigé le yaml et exécuté à nouveau la mise à niveau sur mon graphique, et voilà, le message d'erreur indiquant que la ressource n'est pas trouvée apparaît. J'ai dû aller dans kubernetes et supprimer les nouvelles ressources (dans mon cas, un rôle et une liaison de rôle) créées par l'échec du déploiement. Après cela, la barre vérifie si l'objet actuel existe échoue (https://github.com/kubernetes/helm/blob/7432bdd716c4bc34ad95a85a761c7cee50a74ca3/pkg/kube/client.go#L257) échoue et les ressources sont créées de nouveau. Cela ressemble à un bogue, où peut-être de nouvelles ressources pour un graphique échoué devraient-elles être prises en compte?

Obtenir une erreur similaire lors de la mise à niveau:

$ helm upgrade --install bunny ./app --namespace=staging --reuse-values --debug
[debug] Created tunnel using local port: '53859'

[debug] SERVER: "127.0.0.1:53859"

Error: UPGRADE FAILED: no ConfigMap with the name "bunny-proxy-config" found

Configmap est créé

$ k get configmap
NAME                 DATA      AGE
bunny-proxy-config   1         7m

Ma configmap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ template "proxy.fullname" . }}-config
  labels:
    app: {{ template "proxy.name" . }}
    chart: {{ template "proxy.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
data:
  asd: qwe

Nous avons le même problème.

J'ai supprimé la version entière, puis je l'ai réinstallée. Actuellement, cela semble fonctionner.

$ helm del --purge bunny

J'ai également ce problème sur

Client: & version.Version {SemVer: "v2.8.0", GitCommit: "14af25f1de6832228539259b821949d20069a222", GitTreeState: "clean"}
Serveur: & version.Version {SemVer: "v2.8.0", GitCommit: "14af25f1de6832228539259b821949d20069a222", GitTreeState: "clean"}

Cela se produit fréquemment avec notre utilisation de helm et nécessite un --purge complet. Ce n'est pas une solution.

Cela ne s'applique pas si vous utilisez CI / CD.
Que se passe-t-il si une mise à niveau échoue et que vous utilisez une stratégie de mise à jour progressive? Dois-je supprimer ma version toujours active?

Je vois également le même problème lorsqu'il y a un problème de déploiement ou similaire, mais le secret / cm a été créé, mais Helm en perd la trace, refusant de vous laisser faire beaucoup.

Je l'ai vu, rarement, se produire même sur une version non cassée (c'est-à-dire qu'il est considéré comme étant passé) mais je n'ai pas encore compris ce qui pourrait en être la cause.

Nous sommes également en mesure de reproduire ce problème (serveur v2.8.2) lors de l'ajout de ressources aux déploiements de barre existants. Le fait de devoir supprimer le déploiement et le redéployer chaque fois qu'une nouvelle ressource doit être ajoutée sera un gros problème en production.

Dans notre cas, nous ajoutions un configmap à un graphique et le graphique ne parvient pas à être mis à niveau avec:

Erreur: ECHEC DE LA MISE À NIVEAU: aucune ressource avec le nom "" trouvé

Remarque: nous utilisons 2.7.2;

Je crois que cela se produit parce que lorsque helm détermine ce qui a changé, il recherche la nouvelle ressource configmap dans l' ancienne version et ne parvient pas à la trouver. Voir https://github.com/kubernetes/helm/blob/master/pkg/kube/client.go#L276 -L280 pour le code d'où provient cette erreur.

Journaux du timon pour l'échec de la mise à niveau:

[tiller] 2018/05/03 19:09:14 preparing update for staging-collector
[storage] 2018/05/03 19:09:14 getting deployed release from "staging-collector" history
[tiller] 2018/05/03 19:10:39 getting history for release staging-collector
[storage] 2018/05/03 19:10:39 getting release history for "staging-collector"
[tiller] 2018/05/03 19:10:41 preparing update for staging-collector
[storage] 2018/05/03 19:10:41 getting deployed release from "staging-collector" history
[storage] 2018/05/03 19:10:42 getting last revision of "staging-collector"
[storage] 2018/05/03 19:10:42 getting release history for "staging-collector"
[tiller] 2018/05/03 19:10:44 rendering collector chart using values
[tiller] 2018/05/03 19:10:44 creating updated release for staging-collector
[storage] 2018/05/03 19:10:44 creating release "staging-collector.v858"
[tiller] 2018/05/03 19:10:44 performing update for staging-collector
[tiller] 2018/05/03 19:10:44 executing 0 pre-upgrade hooks for staging-collector
[tiller] 2018/05/03 19:10:44 hooks complete for pre-upgrade staging-collector
[kube] 2018/05/03 19:10:44 building resources from updated manifest
[kube] 2018/05/03 19:10:44 checking 3 resources for changes
[tiller] 2018/05/03 19:10:44 warning: Upgrade "staging-collector" failed: no resource with the name "collector-config" found 
[storage] 2018/05/03 19:10:44 updating release "staging-collector.v857"
[storage] 2018/05/03 19:10:44 updating release "staging-collector.v858" 

Ce problème se pose également lors de la modification de l'étiquette name d'un service déployé, peut-être aussi d'autres choses.

Je change le nom d'un service dans une version et la mise à niveau échoue avec:

Erreur: ECHEC DE LA MISE À NIVEAU: aucun service avec le nom "nouveau-service-nom" trouvé

Je serais prêt à créer un PR pour corriger ce problème, mais j'aimerais savoir quelle est la manière prévue ou suggérée de gérer cela. Même un indicateur CLI qui permet à --force de prendre la priorité serait génial.

Mettez-vous d'accord sur l'importance.

Ce problème peut être étrange lorsque vous ne pouvez pas simplement supprimer un déploiement.

J'ai trouvé que notre problème était dû à un déploiement échoué.

Helm ne tente pas de nettoyer après un déploiement échoué, ce qui signifie que des choses comme le nouveau ConfigMap que j'ai ajouté ci-dessus sont créés mais sans référence dans le déploiement `` précédent ''. Cela signifie que lorsque le prochain déploiement se produit, helm trouve la ressource dans k8s et s'attend à ce qu'elle soit référencée dans la dernière révision déployée (ou quelque chose; je ne suis pas sûr de la logique exacte qu'il utilise pour trouver la version `` précédente '') pour vérifier ce que il y a des changements. Ce n'est pas dans cette version, il ne peut donc pas trouver la ressource et échoue.

C'est principalement un problème lors du développement d'un graphique car un déploiement échoué met les k8 dans un état que la barre ne suit pas correctement. Quand j'ai compris que c'était ce qui se passait, je savais que j'avais juste besoin de supprimer le ConfigMap de k8s et de réessayer le déploiement.

@krishicks Oui, c'est une façon de le reproduire. Un déploiement échoué + une ressource jamais créée (c'est-à-dire une configmap invalide) peuvent également causer cela, j'ai remarqué, ce qui conduit alors à un état irrécupérable

Nous frappons celui-ci aussi. C'est le même problème que @krishicks et @jaredallard mentionnent:

1. Nous avons un déploiement échoué:
   UPGRADE FAILED: the server was unable to return a response in the time allotted, but may still be processing the request (get configmaps)
2. Toutes les modifications ultérieures, également sur d'autres versions, échouent avec un avertissement comme
   Error: UPGRADE FAILED: no Service with the name "…" found

J'essaierai d'utiliser l'indicateur helm upgrade --timeout … pour atténuer le premier problème, mais un déploiement échoué bloquant tout est un problème pour nous. De plus, l'utilisation de helm rollback … n'a pas résolu ce problème.

Comme helm upgrade … s'exécute automatiquement dans notre cas d'utilisation, un indicateur --auto-rollback pour helm upgrade serait très utile, ce qui annule les modifications échouées.

Cela se produit pour moi avec la v2.7.2 lors de l'ajout de nouvelles ressources au graphique.
Y a-t-il une estimation du moment où un correctif sera apporté pour cela?

Cela devrait être corrigé avec # 4146.

EDIT: voir ci-dessous

J'ai donc trouvé quelques bugs avec # 4146 qui en font un PR indésirable. J'ai rapporté mes découvertes entre master, # 4146 et # 4223 ici: https://github.com/kubernetes/helm/pull/4223#issuecomment -397413568

@adamreese et moi avons réussi à identifier le bogue sous-jacent qui cause cette erreur particulière, et à parcourir les différents scénarios et cas

Oh, et quelque chose que je n'ai pas mentionné: parce que le cluster est dans un état incohérent, cela peut facilement être contourné en intervenant manuellement et en supprimant la ressource que l'erreur signale comme "non trouvée". En suivant l'exemple que j'ai démontré dans https://github.com/kubernetes/helm/pull/4223#issuecomment -397413568:

><> helm fetch --untar https://github.com/kubernetes/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml
><> kubectl create -f foo/templates/service.yaml
service "foo-bar" created
><> helm upgrade $(helm last) ./foo/
Error: UPGRADE FAILED: no Service with the name "foo-bar" found
><> kubectl delete svc foo-bar
service "foo-bar" deleted
><> helm upgrade $(helm last) ./foo/
Release "riotous-echidna" has been upgraded. Happy Helming!
...
><> kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
foo-bar      ClusterIP   10.104.143.52   <none>        80/TCP    3s
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   1h

@bacongobbler Cela ne fonctionne pas toujours. Nous avons eu des situations où la suppression fonctionne et d'autres où cela ne fonctionne toujours pas après cela.

cela peut facilement être contourné en intervenant manuellement et en supprimant la ressource

@bacongobbler Veuillez comprendre que cette ressource peut être un objet Service ou Deployment d'un espace de noms de production, ce qui pourrait (et l'a déjà fait) fortement perturber nos garanties de service.

Oui je sais. J'explique et j'observe simplement le comportement du bogue pour que les autres sachent ce qui est impliqué. :)

Il suffit de rencontrer ce problème deux fois sur différents clusters. À chaque fois avec configmaps. La suppression des ressources n'a pas résolu le problème, nous avons donc dû supprimer la version entière.

Pareil ici. Non seulement Configmaps, j'en ai un avec ServiceAccount.

PVC ici. :)

Fondamentalement, chaque type d'objet prioritaire est soumis à ce bogue.

Y a-t-il quelqu'un chargé de résoudre ce problème? Existe-t-il déjà un PR pour cela? Puis-je aider avec quoi que ce soit?

J'ai été mordu par ce problème plus d'une fois car c'est une situation facile à vivre, mais apparemment, il n'y a pas de moyen facile de s'en sortir. Je suppose que la "bonne" partie dans mon cas est que les ressources sont mises à jour même avec l'erreur sur la version (je ne sais pas si cela me rend heureux ou inquiet)

Je pense que la barre devrait soit interdire à l'utilisateur d'entrer dans ce mauvais état, soit la gérer correctement.
Existe-t-il de véritables correctifs à cela en dehors de la suppression de tout (ce qui n'est viable que pour les utilisations hors production)?

Si quelqu'un d'autre peut déterminer l'autre cas périphérique où la suppression de la ressource n'a pas résolu le problème, cela serait très utile pour déterminer la cause première de la résolution de ce problème particulier. Il peut y avoir plusieurs chemins qui peuvent aboutir à la même erreur.

@Draiken non, nous avons tenté plusieurs solutions au problème, et aucune d'entre elles ne semble raisonnable car elles non plus

a) n'effectuez pas la mise à niveau comme prévu, ou
b) introduire de nouveaux bogues

J'ai écrit sur ces solutions ici et pourquoi elles ne fonctionneront pas. Si vous pouvez trouver une solution alternative, nous serons heureux de l'examiner.

Nous ne pouvons pas non plus empêcher les utilisateurs d'entrer dans ce mauvais état; nous avons examiné des solutions, mais encore une fois, elles introduisent toutes un ensemble différent de problèmes. Une fois l'installation dans un état incohérent, il est difficile de la «réparer» sans intervention manuelle. 😢

Une solution de contournement qui a fonctionné pour moi est de faire un helm rollback ... juste avant que l'échec ne se produise. Je valide ensuite que le graphique fonctionne sur une nouvelle version avec helm install -n new-test-release . .

Une fois que tout fonctionne, je nettoie la version de test et lance helm upgrade ... sur l'ancienne version; et tout a fonctionné. C'est une solution de contournement ennuyeuse mais elle semble fonctionner.

Je ne sais pas si cela aide du tout, mais je viens de rencontrer ce problème sur mes clusters de test et de production.

Les modifications que j'ai apportées à mes fichiers helm étaient assez simples:
J'avais 1 déploiement existant, avec un service associé et un budget de poddisruption, qui est resté inchangé.
J'ai ajouté un 2ème déploiement, avec son propre service et son propre budget de poddisruption.
J'ai incrémenté le numéro de version du graphique.

Lors de l'exécution de helm, j'ai eu cette erreur la première fois:

KUBECONFIG=**** helm upgrade --kube-context=mycluster -f helm/project/mycluster.yaml project ./helm/project --install --wait --timeout 1200

Error: UPGRADE FAILED: Deployment.apps "blah-blah" is invalid: spec.template.metadata.labels: Invalid value: map[string]string{"app":"blah-blah", "chart":"blah-3", "name":"blah", "release":"project"}: `selector` does not match template `labels`

Lorsque j'exécute à nouveau helm, j'obtiens cette erreur encore et encore:

KUBECONFIG=**** helm upgrade --kube-context=mycluster -f helm/project/mycluster.yaml project ./helm/project --install --wait --timeout 1200

Error: UPGRADE FAILED: no Service with the name "blah-blah" found

Le diagramme de barre a bien sûr fonctionné en test lorsque j'ai tout supprimé et redéployé. Ce n'est pas vraiment une option pour la production.

@veqryn J'ai beaucoup rencontré ce problème, j'utilise essentiellement ma version # 4146 chaque fois que je rencontre ce problème, puis je reviens au problème principal. Fonctionne à chaque fois. Je sais que les mainteneurs pourraient ne pas le recommander, mais cela fonctionne, ce qui est mieux que rien.

EDIT : Si quelqu'un est intéressé à l'essayer, je peux le pousser dans un repo de docker public et inclure un extrait rapide de la façon de l'utiliser.

@jaredallard nous sommes intéressés. Merci!

Je sais que les responsables peuvent ne pas le recommander, mais cela fonctionne, ce qui est mieux que rien.

@jaredallard nous ne pouvons pas recommander ce patch simplement parce qu'il ne fonctionne pas tout seul (réf: https://github.com/helm/helm/pull/4223#issuecomment-397413568). Il contourne l'erreur, mais ne met pas à niveau les ressources, de sorte que le correctif ne fait pas ce que l'utilisateur avait initialement l'intention de faire. Il corrige un problème mais en introduit un autre sans résoudre le problème initial que les utilisateurs ont l'intention de résoudre: mettre à niveau une ressource.

Cependant, c'est intrigant:

J'utilise essentiellement ma version n ° 4146 chaque fois que je rencontre ce problème, puis je reviens à la version principale.

Si je lis bien, vous suggérez que vous avez trouvé une solution de contournement qui

a) contourne l'erreur
b) permet de mettre à niveau les ressources comme prévu à l'origine

en faisant 2 helm upgrade s: un avec le patch et un sans? Cela pourrait nous aider à mieux identifier la cause première et comment corriger cette erreur.

@bacongobbler Je devrais revoir ceci pour vérifier à 100% que c'est bien le comportement. Je mettrai à jour ce commentaire ou en posterai un autre quand je l'aurai.

Je sais que les responsables peuvent ne pas le recommander, mais cela fonctionne, ce qui est mieux que rien.

Aussi, pour clarifier, je n'essaye pas d'y jeter de l'ombre! C'est un peu mal formulé en y repensant maintenant, désolé

Je ne comprends toujours pas pourquoi ma barre a échoué la première fois.
Il n'a pas obtenu l'erreur no X with the name Y jusqu'à la deuxième fois que j'ai essayé de l'appliquer.

@veqryn J'ai écrit sur la façon dont ce problème survient en premier lieu dans le numéro que j'ai lié ci-dessus. Veuillez lire le commentaire; heureux d'aider à clarifier le problème plus en détail s'il n'est pas clair.

Pour les paresseux: https://github.com/helm/helm/pull/4223#issuecomment -397413568

J'ai effectivement lu cela et j'ai cru comprendre que le problème vous est arrivé parce que vous avez changé le nom de votre service.

Cependant, à aucun moment aucun de mes services ou ressources n'a changé de nom.

Et après avoir relu votre commentaire et discuté avec mon équipe, nous avons découvert la cause de notre erreur:
J'avais heurté la version de mon Helm Chart.
Cette version de graphique a été référencée comme étiquette par mes déploiements et services.
Kube / helm n'aime pas quand votre étiquette change, et c'est ce qui a causé l'erreur d'origine.

La solution (pour moi) était d'utiliser helm pour revenir au dernier déploiement réussi, puis d'annuler le changement de version du graphique afin que la version du graphique reste la même, ce qui a ensuite réussi.

ce correctif (laid) fonctionne pour moi:

1. J'obtiens une erreur:

helm upgrade az-test-2-prom ./prometheus --namespace monitor --set cluster_name="az-test-2" -f values.yaml
Error: UPGRADE FAILED: no ConfigMap with the name "az-test-2-prom-prometheus-grafana-config" found

1. trouver les dernières révisions DÉPLOYÉES

export TEMPLATE='{{range .items}}{{.metadata.name}}{{"\t"}}{{.metadata.labels.STATUS}}{{"\n"}}{{end}}'
kubectl -nkube-system get cm -l 'OWNER=TILLER' -ogo-template="$TEMPLATE"

az-test-2-prom.v1   SUPERSEDED
az-test-2-prom.v10  SUPERSEDED
az-test-2-prom.v11  SUPERSEDED
az-test-2-prom.v12  SUPERSEDED
az-test-2-prom.v13  SUPERSEDED
az-test-2-prom.v14  SUPERSEDED
az-test-2-prom.v15  SUPERSEDED
az-test-2-prom.v16  SUPERSEDED
az-test-2-prom.v17  DEPLOYED
az-test-2-prom.v18  FAILED
az-test-2-prom.v19  FAILED
az-test-2-prom.v2   SUPERSEDED
az-test-2-prom.v20  FAILED
az-test-2-prom.v21  FAILED
az-test-2-prom.v22  FAILED
az-test-2-prom.v23  FAILED
az-test-2-prom.v24  FAILED
az-test-2-prom.v25  FAILED
az-test-2-prom.v26  FAILED
az-test-2-prom.v27  FAILED
az-test-2-prom.v28  FAILED
az-test-2-prom.v29  FAILED
az-test-2-prom.v3   SUPERSEDED
az-test-2-prom.v30  FAILED
az-test-2-prom.v4   SUPERSEDED
az-test-2-prom.v5   FAILED
az-test-2-prom.v6   SUPERSEDED
az-test-2-prom.v7   SUPERSEDED
az-test-2-prom.v8   SUPERSEDED
az-test-2-prom.v9   FAILED



md5-6d9e4edff5e9111525fecb734bfec15a



for ii in {17..30}
> do
>   kubectl -nkube-system delete cm az-test-2-prom.v${ii}
> done



md5-cf6357e67a21fb9f80abb7b78b9e5b8e



kubectl -nkube-system patch cm az-test-2-prom.v16 -p '{"metadata": {"labels": {"STATUS": "DEPLOYED"}}}'

** 4. (Important) Trouvez toutes les ressources que de nouvelles ressources ont été ajoutées depuis le dernier déploiement (v16) et supprimez-les, par exemple
kubectl -nmonitor delete cm az-test-2-prom-prometheus-grafana-config
kubectl -nmonitor delect svc ...

Exécutez helm upgrade ... et voyez Happy Helming

Comme @ kosta709 l'a dit, revenir à la dernière version déployée, corriger (manuellement) le graphique ou l'état actuel (tout ce qui ne va pas) et faire une nouvelle mise à niveau fonctionne généralement.

Helm est un excellent logiciel qui peut être abandonné dans certains workflows automatiques (CI / CD) si le résultat d'une commande n'est pas stable.

Existe-t-il une option pour que les solutions connues soient éventuellement implémentées dans helm pour (essayer de) résoudre ce problème bien connu (et un peu ennuyeux)? Merci.

Donc, récemment, je frappe souvent aussi, assez pour que je travaille sur ce problème par moi-même. Pour commencer, j'ai créé une solution de contournement (
https://github.com/Nopik/helm/commit/afe6451cc2c6295e71ea2213ccce654ec3f5b686), ce qui oblige Tiller à obtenir la ressource existante comme point de départ au lieu de la ressource extraite de l'ancien manifeste. Cela fonctionne comme un charme pour moi, même si je pense que les développeurs principaux ne voudront pas le fusionner, car il contient un comportement codé en dur.

Il peut y avoir deux bogues cachés sous le même comportement, car au moins une fois, quand ce bogue me mord, j'ai dû supprimer beaucoup (> 40) ressources, y compris certaines qui étaient déjà présentes pour plus de 20 versions réussies. Mais dans 99% des cas, il suffit de supprimer des ressources fraîchement créées (et encore inconnues de la barre).

Donc, j'ai réfléchi à la façon de le résoudre de la bonne manière. Je le décris ci-dessous. Les développeurs principaux, veuillez me corriger ici et peser si vous êtes d'accord avec moi. Si oui, je suis prêt à diriger cet effort et à fournir des relations publiques pour y remédier.

En général, helm semble fonctionner en mode `` patch '': si l'utilisateur modifie la ressource d'une manière ou d'une autre et que la nouvelle version change certains autres paramètres, helm calcule le correctif entre 2 révisions et l'applique - je pense qu'il essaie de garder les modifications de l'utilisateur intactes.

Cela nous laisse malheureusement avec un problème de fusion à 3 voies, car nous avons une version de ressource tirée de l'ancien manifeste, une autre version du nouveau manifeste et une autre version de la ressource actuellement vivante. Et la barre est apparemment mauvaise pour résoudre les conflits, lorsqu'ils surviennent.

Je pense que la bonne façon serait soit de choisir de meilleures valeurs par défaut (fondamentalement, fusionner ma branche fera beaucoup de chemin), soit de fournir un drapeau à l'utilisateur. Par exemple, comme ceci:

• --ignore-old-manifest=never (par défaut, comportement actuel)
• --ignore-old-manifest=create-only (s'applique à ce cas, lorsque l'ancien manifeste n'a aucune notion de la ressource, mais que la ressource existe déjà, nous pouvons la prendre comme nouvelle base et la corriger, si nécessaire) - Je recommanderais que ce soit nouveau défaut. Cela permettrait également à Helm de commencer à s'approprier les ressources créées manuellement.
• --ignore-old-manifest=always - juste pour être complet, probablement pas strictement nécessaire. Il créerait toujours un correctif entre la ressource actuelle et le manifeste le plus récent, supprimant essentiellement toutes les modifications utilisateur.

Bien sûr, vous pouvez renommer l'indicateur pour utiliser la logique inversée: --use-current-resources=never(currently default)/create-only/always ou quelque chose comme ça.

Plus tard, cet indicateur pourrait être extrait des annotations de ressources, quelque chose comme:

annotations:
  helm.io/ignore-old-manifest: always

quel pilote pourrait reconnaître et appliquer cette stratégie par ressource. Je ne sais pas si les développeurs de helm veulent y aller, cependant;)

Alors, que pensez-vous de cette proposition?

Voir aussi le numéro 3805 où les développeurs Helm envisagent un patch de fusion à 3 voies.

Même problème ici.
Essayer de configurer un environnement CD / CI avec Google Cloud Build.
Error: UPGRADE FAILED: no Deployment with the name "baobab-sidekiq" found

Le plus drôle est que le déploiement existe:

kc get deployments
NAME             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
baobab           3         3         3            2           2d
baobab-ermis     1         1         1            1           23h
baobab-sidekiq   1         1         1            1           23h

C'est le premier graphique que je crée et je m'attendais helm ce que

L'intention de la barre est-elle de pouvoir travailler dans un pipeline CI / CD?

Merci

Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

Je suis également en train de rencontrer cela, en essayant de mettre à niveau helm 0.8.0 vers helm 1.0.0.

helm version --tls Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

J'ai également rencontré ce problème lors de la mise à niveau des exigences d'un graphique. Je vois qu'Istio rencontre également ce bogue, leur doc d'installation utilise helm template . Est-ce une solution de contournement pour ce problème?

Consultez les discussions récentes sur https://github.com/helm/helm/issues/3805

avoir cela aussi, se produit toujours pour la dernière barre 2.10

Il est temps que ce problème soit sérieusement pris en compte, cela fait maintenant 2 ans et une foule de personnes signalent exactement les mêmes problèmes qui rendent la barre assez inutilisable en production, et c'est une vraie douleur lorsque votre déploiement dépend de la barre.

Avec beaucoup de stars de GitHub, de grandes responsabilités

@ brendan-rius Vous pouvez contribuer au code pour résoudre ce problème ou penser à des idées. Voir # 3805 et # 4146 pour quelques conseils.

@ brendan-rius, # 3805 en particulier a les discussions les plus récentes à jour concernant ce bogue. Je suggère fortement de lire ce fil pour avoir une idée de ce à quoi nous sommes confrontés.

Republier mon commentaire ici car il est plus lié à ce problème que les stratégies de fusion à 3 voies:

Si une fusion à trois n'est pas viable pour les nouveaux déploiements dans Helm 2.yz, quand le # 1193 sera-t-il corrigé? Le bogue est ouvert depuis près de deux ans sans résolution claire prévue pour Helm 2.0.

À ce stade, nous ne savons pas comment procéder. Nous discutons du bogue depuis des semaines et aucune des solutions proposées ne fonctionnera dans tous les cas, que ce soit en introduisant de nouveaux bogues ou en modifiant considérablement le comportement de mise à niveau de la barre.

Par exemple, @michelleN et moi avons réfléchi plus tôt cette semaine et avons pensé à deux solutions possibles, dont aucune n'est particulièrement fantastique:

1. Lorsqu'une mise à niveau échoue, nous annulons et supprimons automatiquement les ressources créées au cours de cette version.

Ceci est très risqué car le cluster peut être dans un état inconnu après l'échec d'une mise à niveau, de sorte que Helm peut ne pas être en mesure de procéder de manière propre, ce qui peut entraîner un temps d'arrêt de l'application.

1. Lors d'une mise à niveau, si nous créons une nouvelle ressource et que nous voyons qu'elle existe déjà, nous appliquons à la place ces modifications à la ressource existante, ou la supprimons / recréons.

Ceci est extrêmement risqué car Helm peut supprimer des objets qui ont été installés via d'autres packages ou via kubectl create , dont aucun des utilisateurs ne souhaite.

L'option la plus sûre jusqu'à présent a été de demander aux utilisateurs d'intervenir manuellement dans le cas de ce conflit, ce que je démontrerai ci-dessous.

Si quelqu'un a des suggestions / commentaires / propositions alternatives, nous aimerions connaître votre opinion.

@bacongobbler , si aucune prise en charge de la fonctionnalité de fusion à 3 voies n'est prévue, nous avons besoin d'une alternative ou d'une solution de contournement. Sinon, # 1193 est un bocker très douloureux.

Pour réitérer le problème ainsi que la solution de contournement:

Lorsqu'une mise à niveau qui installe de nouvelles ressources échoue, la version passe à l'état ÉCHEC et arrête le processus de mise à niveau. La prochaine fois que vous appelez helm upgrade , Helm effectue une comparaison avec la dernière version DEPLOYED. Dans la dernière version DEPLOYED, cet objet n'existait pas, il tente donc de créer la nouvelle ressource, mais échoue car il existe déjà. Le message d'erreur est complètement trompeur comme le souligne @arturictus .

Cela peut facilement être contourné en intervenant manuellement et en supprimant la ressource que l'erreur signale comme "introuvable". En suivant l'exemple que j'ai démontré dans https://github.com/helm/helm/pull/4223#issuecomment -397413568:

><> helm fetch --untar https://github.com/helm/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml                    # change the service name from "foo" to "foo-bar"
><> kubectl create -f foo/templates/service.yaml      # create the service
service "foo-bar" created
><> helm upgrade $(helm last) ./foo/
Error: UPGRADE FAILED: no Service with the name "foo-bar" found
><> kubectl delete svc foo-bar
service "foo-bar" deleted
><> helm upgrade $(helm last) ./foo/
Release "riotous-echidna" has been upgraded. Happy Helming!
...
><> kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
foo-bar      ClusterIP   10.104.143.52   <none>        80/TCP    3s
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   1h

En d'autres termes, la suppression des ressources créées lors de la version FAILED résout le problème.

@bacongobbler tout d' abord, je tiens à vous remercier d'avoir examiné ce problème plus en détail au cours des dernières semaines. Je ne sais pas exactement quel est le problème dans la mise à niveau d'Istio 0.8.0 vers Istio 1.0.0 qui cause le problème ou s'il correspond complètement à votre déclaration de problème. Ma spéculation est qu'environ 3 jours avant la publication, certains objets qui n'étaient auparavant pas gérés (c'est-à-dire ajoutés dans un travail de post-installation) ont été migrés pour ne pas être installés dans un travail de post-installation.

En discutant avec la communauté d'opérateurs Istio qui a beaucoup d'expérience préalable avec Helm, quelques opérateurs nous ont dit que les ressources non gérées dans Helm sont une mauvaise nouvelle et conduisent souvent à des échecs de mise à niveau. Si l'implémentation des graphiques Istio a une faille qui les rend incompatibles avec la mise à niveau avec Helm 2.yz, corriger ces incompatibilités serait génial - nous n'avons donc pas d'échecs de mise à niveau à l'avenir.

Nous sommes prêts à prendre le coup 1 fois de la mise à niveau 0.8.0 à 1.0.0. Si la mise à niveau est constamment floconneuse - c'est un problème différent.

J'ai exécuté une bissectrice sur Istio - car la mise à niveau fonctionnait jusqu'au 27 juillet (3 jours avant la version Istio 1.0.0) et j'ai trouvé que ce commit était problématique: https://github.com/istio/istio/commit/301612af08128b15069d27ff6d03cdb87420e15b

Ce PR a essentiellement supprimé l'enregistrement d'objet des travaux de post-installation. Je crois, mais je ne suis pas certain, que nous avons supprimé toutes les instances de travaux de post-installation dans les 3 jours précédant Istio 1.0.0.

Pouvez-vous offrir des conseils sur le tableau Helm spécifique d'Istio en ce qui concerne la mise à niveau? Le fait de garder l'enregistrement des objets hors des travaux de post-installation résoudra-t-il nos problèmes de mise à niveau de manière permanente?

Je ne peux pas vraiment offrir de conseils solides ni de proposition pour résoudre ce problème à l'échelle de la barre, car les personnes ayant une expérience plus récente avec Helm n'ont pas été en mesure de trouver une solution généralisée (et pas faute d'avoir examiné le problème). Je ne pense pas que je pourrais faire mieux.

Acclamations
-steve

Mise à jour du titre pour mieux refléter l'erreur.

Nous sommes également touchés par le problème. Nous utilisons le dernier helm 2.10 avec GKE 10.6.
Quand puis-je espérer que cela sera corrigé?
Avons-nous une solution de contournement raisonnable pour le problème? Supprimer tout le déploiement avec l'option --purge est si médiocre.

N'hésitez pas à peser sur mon dernier commentaire. Nous avons vraiment besoin de commentaires sur la meilleure façon de procéder ici.

Une solution de contournement a été répétée plusieurs fois dans ce fil. Veuillez lire https://github.com/helm/helm/issues/1193#issuecomment -419555433.

J'aime l'idée d'une fonction de restauration automatique de la barre ( option 1 ) pour résoudre ce problème. Nous savons que la dernière version de DEPLOYED Helm fonctionnait et que le cluster était en bon état, il devrait donc être prudent de revenir dessus. Si c'est risqué pour certains cas d'utilisation, il pourrait être opt-in via un drapeau pour la mise à niveau de la barre.

Ceci est très risqué car le cluster peut être dans un état inconnu après l'échec d'une mise à niveau, de sorte que Helm peut être incapable de procéder de manière propre, ce qui peut entraîner un temps d'arrêt de l'application.

Je pense que beaucoup d'utilisateurs de barre utilisent la barre de manière automatisée via un CD ou un outil CM et il est plus risqué de laisser la commande de barre dans un état ÉCHEC. Ces ressources incomplètes dans une version échouée peuvent affecter de manière inattendue d'autres ressources et provoquer elles-mêmes des temps d'arrêt. Par exemple, si la spécification du pod contenait une version d'image manquante qui est arrivée en production, votre charge de travail serait dans un état ImagePullBackOff non fonctionnel. Pour notre entreprise, c'est encore pire car nous avons des clients sur site qui peuvent se mettre à niveau via notre interface utilisateur et en cas d'échec, nous devons accéder à leur système pour déboguer.

Même sans tenir compte du fait qu'il pourrait résoudre ce problème, la restauration automatique serait une fonctionnalité utile et aiderait à garantir que les versions de Helm sont de nature plus transactionnelle. Cela fait passer Helm des déploiements au meilleur effort à la priorité à la stabilité et aux déploiements réussis.

@bacongobbler serait l'approche suivante viable pour les nouveaux déploiements:

• Ajouter un drapeau - -three-way-merge
• Autoriser uniquement cet indicateur à être utilisé dans un helm install (nouveau déploiement)
• Une fois cet indicateur activé, la mise à niveau utilisera toujours une fusion à 3 voies
• Les déploiements existants seraient bloqués sans chemin de migration - la solution de contournement standard que les gens semblent utiliser à ce stade est helm delete --purge suivi d'un helm reinstall donc cela peut ne pas être aussi désagréable qu'il n'y paraît.

Cela résoudrait-il réellement le problème?

Certaines personnes envisagent la mise en œuvre d'un opérateur pour contourner cette limitation de Helm. Ce serait vraiment dommage. Voir https://github.com/istio/istio/issues/8841#issue -361871147

Acclamations
-steve

Pour revenir au commentaire précédent de @bacongobbler :

1. Lors d'une mise à niveau, si nous créons une nouvelle ressource et que nous voyons qu'elle existe déjà, nous appliquons à la place ces modifications à la ressource existante, ou la supprimons / recréons.
   Ceci est extrêmement risqué car Helm peut supprimer des objets qui ont été installés via d'autres packages ou via kubectl create, ce que les utilisateurs ne souhaitent peut-être pas.

Je me demande si nous pouvons atténuer ce risque en optant pour le nouveau comportement? Dans un espace de noms donné, j'utilise généralement exclusivement helm, et je suppose que c'est le cas pour beaucoup. Si je pouvais donner à Helm un indicateur pour l'installation / la mise à niveau pour lui dire que tout ce qui ne fait pas partie de l'espace de noms donné qui ne fait pas partie d'une version existante peut être supprimé / écrasé, cela aiderait-il?

Puisque vous avez également dit "via d'autres paquets", je suppose que vous ne voulez pas que Helm ait à examiner d'autres versions dans le cadre de l'exécution d'une version, donc ma suggestion ne fonctionnerait pas sauf dans le modèle single-release-per-namespace. Pour répondre à cette objection, je dirais: si vous souhaitez gérer plusieurs packages dans un espace de noms et obtenir toujours ce comportement, créez un graphique ombrelle dont le seul but est de spécifier les dépendances de graphique souhaitées. Utilisez ensuite le nouvel indicateur ("--exclusive"?) Lors du déploiement de ce graphique ombrelle.

Évidemment, cela ne résout pas le problème pour tous les cas d'utilisation, mais c'est peut-être une solution de contournement suffisante.

@bacongobbler Je pourrais être loin d'ici. Je suis confronté à des problèmes similaires lors de la mise à niveau. A en juger par la difficulté de résoudre ce problème, je me demande si quelque chose de plus fondamental doit être reconsidéré. Une partie de la complexité semble être due au fait que Helm maintient sa propre version de la configuration connue, séparée de la véritable source de vérité qui est kubernetes. Le système serait-il plus fiable si Helm ne conservait qu'une copie des graphiques de barre précédemment déployés à des fins d'historique et de restauration, mais ne l'utilisait pas du tout pendant la mise à niveau. Au lieu de cela, Helm obtiendrait la vérité de kubectl lui-même, puis aurait toujours un diff à 2 voies à effectuer?

Si un graphique de barre indique qu'il devrait avoir la ressource X et que kubectl voit une ressource X existante, alors:

• Si la ressource existante est marquée comme étant contrôlée par Helm, Helm effectue la mise à niveau requise
• Si la ressource existante n'est pas marquée comme étant contrôlée par Helm, Helm échoue avec un message d'erreur propre (ou un indicateur de ligne de commande peut être utilisé pour - forcer la mise à niveau et amener Helm à s'approprier la ressource X existante).

Si le diagramme de barre indique qu'il devrait avoir la ressource X et qu'il n'y en a pas selon kubectl, alors Helm le crée.

Si kubectl signale qu'il a une ressource Y marquée comme étant contrôlée par ce graphique de barre, et qu'il n'y a pas de ressource Y dans ce graphique de barre, alors helm supprime la ressource.

Toutes les ressources non étiquetées comme étant contrôlées par ce diagramme de barre sont toujours ignorées par helm lors de la mise à niveau, sauf dans le cas mentionné ci-dessus où le diagramme de barre indique qu'il a besoin des ressources X et X existe mais n'est pas marqué.

Si, pour une raison quelconque, le déploiement d'un graphique de barre se produit et échoue, et que seulement la moitié des ressources ont été déployées, alors pendant une barre de restauration, utiliser les fichiers de configuration stockés du déploiement réussi précédent et exécuter exactement le même algorithme, ou des choses. pourrait être laissé dans un état cassé par rapport à un indicateur de ligne de commande de barre. Si l'utilisateur tente à nouveau de mettre à niveau, étant donné que kubernetes est utilisé comme source de vérité et non comme le dernier déploiement réussi connu, il devrait toujours s'agir d'un simple différentiel bidirectionnel entre le nouveau diagramme de barre et l'état existant du système.

Nous constatons également ce problème. Nos étapes de reproduction:

1. helm install un graphique qui installe avec succès un déploiement
2. Mettez à jour le graphique pour inclure une ressource personnalisée en plus du déploiement existant
3. Changer l'image du podspec de déploiement pour imiter un échec de déploiement
4. helm install nouveau graphique. Cela entraînera une mise à jour continue du déploiement, que nous avons intentionnellement configurée pour échouer.
5. L'installation de la barre devrait échouer. Mais la ressource personnalisée doit être laissée dans k8s etcd. (vérifier avec kubectl )
6. (À ce stade, la barre est en mauvais état)
7. Corrigez le graphique - mettez une image goot dans le podspec de déploiement.
8. helm install . Nous nous attendons à ce que cela fonctionne, mais ce n'est pas le cas. Signale "Aucune ressource avec le nom ___". Le nom est celui de la ressource personnalisée.
9. Récupération: supprimez la ressource personnalisée résiduelle en utilisant kubectl . Maintenant, helm install fonctionnera.

Notez que la première tentative de helm install avec une ressource personnalisée nouvellement introduite dans le graphique doit échouer pour entrer dans cet état.

@ rbair23 nous avons essayé cela plus tôt et cela n'a pas fonctionné. Il y a le groupe de travail Apply qui cherche à améliorer l'état de la gestion déclarative des objets en corrigeant kubectl apply, en déplaçant la logique du client vers le serveur , mais cela en est encore à ses balbutiements. Kubectl (et tiller) doivent tous deux conserver une copie de la dernière configuration appliquée pour effectuer un diff. Vous ne pouvez pas comparer l'état réel du cluster sans exécuter une stratégie de patch de fusion à trois voies, en revenant à ce ticket.

Comme le # 3275 a été fermé en double: nous avons une situation similaire comme dans # 3275

Une tâche est déjà en cours d'exécution my-long-running-job . Et nous essayons de mettre à jour la version:

>helm upgrade --install my-release --namespace my-environment my-chart --timeout 60
Error: UPGRADE FAILED: no Job with the name "my-long-running-job" found

Le travail existe:

>kubectl -n=my-environment get jobs
NAME                                DESIRED   SUCCESSFUL   AGE
my-long-running-job                 1         0            16m

Suppression de ce travail:

>kubectl -n=my-environment delete job my-long-running-job
job.batch "my-long-running-job" deleted

Résout cet obstacle:

>helm upgrade --install my-release --namespace my-environment my-chart --timeout 60
Error: UPGRADE FAILED: timed out waiting for the condition

Au moins, le message no Job with the name "my-long-running-job" found est trompeur, mais je m'attendais à ce que le travail soit également mis à jour.

Toujours voir cela dans la v2.9.1 (version stable actuellement publiée)

Je ne suis pas d'accord pour dire qu'il est "très dangereux" de se retirer d'une mise à niveau. Je pense que cela est la bonne solution.

Kubernetes est déclaratif. Prenez un instantané de l'état du cluster avant de tenter la mise à niveau.
S'il y a une erreur en cours, revenez à l'instantané.
Si quelqu'un a des hooks de script qui laisseraient le cluster dans un mauvais état lors de cette opération, c'est sa propre faute. (Peut-être que cela pourrait être résolu avec des crochets de restauration aussi)

Bien sûr, ce serait formidable si une mise à niveau était pré-volée et ne déposait pas en premier lieu autant que possible.
Les erreurs dans les graphiques de dépendances générées par des valeurs ou des arguments --set doivent pouvoir être vérifiées avant d'essayer de changer quoi que ce soit, par exemple. Des choses comme oublier de modifier le numéro de version pourraient également être pré-volées pour éviter d'apporter des modifications lorsque cela ne fonctionnera pas.

Salut,

J'ai eu le même problème avec:

Client: v2.10.0 + g9ad53aa
Serveur: v2.10.0 + g9ad53aa

La suppression de serviceAccount, configMap et service était le seul moyen de faire en sorte que Helm mette à niveau la version.

Salut,

nous avons le même problème que @dilumr décrit ... avec la version 2.11.0:

Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}

Error: UPGRADE FAILED: no ConfigMap with the name "xxx" found

Ran dans cela sur v2.9.1.

La mise à niveau du graphique que j'exécutais sautait de quelques versions majeures sur un graphique privé avec beaucoup de changements, donc je ne sais pas exactement ce qui a déclenché l'erreur à l'avenir, mais la raison pour laquelle le déploiement s'est à l'origine terminé dans l'état FAILED était que j'avais un drapeau --wait et il a expiré.

Nous nous sommes retrouvés avec plusieurs déploiements FAILED en double dans helm list mais le dernier déploiement opérationnel était DEPLOYED . La création de nouveaux déploiements a généré No resource with the name x found .

A été en mesure de corriger en exécutant un helm rollback vers la dernière version qui était dans l'état DEPLOYED sur helm list . Après cette mise à niveau, cela a pu fonctionner sans erreurs.

Vérifiez ceci https://github.com/helm/helm/pull/4871.

Comme d'autres du point de vue des choses, cette erreur semble se produire le plus fréquemment (je ne suis pas sûr de toujours) pour moi lorsque mon dernier déploiement a échoué et que les nouveaux actifs de ce déploiement ont été laissés installés.

Je comprends comment il peut être difficile et / ou indésirable de désinstaller des composants d'un déploiement Helm qui a échoué, mais quel est le comportement Helm idéal pour ce type de situation?

Premièrement, je pense que Helm devrait être OK avec les espaces de noms et autres ressources déjà existants s'il essaie de les (ré) installer. Kubernetes consiste à "faire la bonne configuration et laisser kube trouver comment faire en sorte que le monde corresponde à la configuration".
Deuxièmement, je pense que Helm devrait être tout ou rien. Si un déploiement échoue, le cluster doit être dans l'état dans lequel il se trouvait avant le démarrage du déploiement.
S'il y a deux versions qui veulent toutes deux créer l'espace de noms X, il y a un problème de comptage de références. S'il y a une version qui veut créer l'espace de noms X, mais qu'il existe déjà, alors il y a un problème de provenance. Cependant, helm peut enregistrer cela en utilisant des annotations sur les objets et faire ce qu'il faut.

Je rencontre également ce problème avec les derniers helm 2.12.0 et kubernetes 1.10.11, même revenir à la dernière bonne version car @aguilarm a suggéré ne pas fonctionner, supprimer également les ressources dont helm se plaint n'aide pas, et après la mise à niveau échoue, elle laisse ces mêmes ressources comme partiellement recréées. Très ennuyeux pour une prod env ...

J'ai 2 clusters avec un environnement très similaire, le principal différent entre les 2 étant le nombre total de nœuds. Dans un cas, un helm delete --purge suivi de frais helm install fonctionné, mais dans un autre, cela n'a pas fonctionné et je n'ai pas encore trouvé un moyen d'apporter cela aux derniers changements de modèle.

Y a-t-il un ETA à ce sujet?

J'ai pu contourner cela avec helm rollback et en spécifiant la révision la plus récente (celle qui a échoué)

J'ai eu le même problème aujourd'hui,
Error: UPGRADE FAILED: no Service with the name "xxx-api" found
kubectl get svc -n stage | grep xxx-api
xxx-api ClusterIP 172.20.149.229 <none> 8300/TCP 19h
helm rollback travaillé.

Nous en faisons l'expérience de manière assez régulière lors des mises à niveau de la barre - cela se produit après des déploiements réussis, pas seulement après des déploiements qui ont échoué. Nous ne pouvons pas gérer la suppression - purge car ce sont des systèmes de production avec des composants non triviaux qui 1) ne peuvent pas être indisponibles et 2) prendraient trop de temps pour récupérer complètement à partir de zéro pour être acceptable.

Voir le diagnostic et la solution de contournement que j'ai posté ci-dessus. Laissez-moi savoir si cela fonctionne pour vous.

@bacongobbler Merci pour la réponse. C'est en fait la solution de contournement que j'ai également proposée et cela devra suffire pour l'instant, mais nous utilisons des mises à niveau de barre des dizaines de fois par jour via notre CICD, donc cela revient assez souvent pour être un casse-tête. Je ne suis pas sûr que ce qui précède soit toute l'histoire, car les ressources nommées sont souvent déjà existantes, font partie d'un déploiement réussi et ne sont pas modifiées dans le déploiement actuel - iirc c'est presque toujours l'ensemble de ressources le plus récent lors du dernier déploiement réussi mais assez intéressant.

+1 à @ajcann et merci @bacongobbler
Je suis exactement dans la même situation.
Notre CICD est automatisé et les déploiements sont souvent effectués par un robot lâche pour les environnements inférieurs.
En cas d'échec, je dois effectuer manuellement la restauration de la barre et le déployer à nouveau.
Le problème n'est pas du tout cohérent mais fréquent.
Pour moi, cela n'arrive que lors du deuxième déploiement du graphique / de la ressource jusqu'à présent.
La ressource existe toujours.

nous observons le même problème. Cela se produit si vous avez un modèle, qui est soit:

• dans un relevé {{if $condition -}}
• ou dans un {{ range $index, $value := $array-}}

@jkroepke vient de me faire remarquer que PR # 5143 fournit une bonne solution de contournement pour cela. Lorsque l'indicateur --atomic est publié dans la prochaine version mineure, vous devriez pouvoir l'utiliser pour purger ou annuler automatiquement en cas d'erreur.

@bacongobbler étant donné que vous avez été impliqué dans la plupart des allers-retours sur celui-ci, y a-t-il quelque chose d'autre qui peut être fait pour résoudre complètement ce problème, ou le drapeau --atomic serait-il suffisant?

Je pense que @distorhead voudra peut-être jeter un coup d'œil à celui-ci et voir si cela résout également ses préoccupations qu'il a soulevées sur https://github.com/helm/helm/pull/4871. En dehors de cela, il semble que --atomic devrait résoudre le problème en supposant que vous utilisez toujours l'indicateur --atomic .

Je ne crois pas qu'il y ait eu de solutions proposées pour régler le problème lorsque vous entrez dans cet état particulier, mais je peux me tromper. Si la stratégie d'atténuation de ce problème est

• parcourir manuellement l'état en direct du cluster et le corriger selon la solution de contournement
• passez à Helm 2.13.0 et utilisez helm upgrade --atomic à l'avenir

Ensuite, je pense que c'est sûr de fermer.

Espérons que Helm 2.13.0 n'est pas si loin.
Ce bogue casse CI si une erreur s'est produite quelque part sur une version.

Atomic ne résoudra pas le problème

Exemple de graphique: https://github.com/distorhead/ex-helm-upgrade-failure

1. Vérifiez le maître, exécutez le déploiement.

git clone https://github.com/distorhead/ex-helm-upgrade-failure
cd ex-helm-upgrade-failure
helm upgrade --atomic --install --namespace myns myrelease .

Le graphique contient 2 déploiements - myserver1 et myserver2 :

Release "myrelease" does not exist. Installing it now.
NAME:   myrelease
LAST DEPLOYED: Tue Feb  5 23:48:57 2019
NAMESPACE: myns
STATUS: DEPLOYED

RESOURCES:
==> v1beta1/Deployment
NAME       READY  UP-TO-DATE  AVAILABLE  AGE
myserver1  1/1    1           1          5s
myserver2  1/1    1           1          5s

1. Faites des changements de rupture. Supprimez le déploiement myserver1 du graphique et modifiez le déploiement myserver2 avec erreur utilisateur (supprimer le champ d'image par exemple):

git checkout break-atomic
git diff master

diff --git a/templates/deploy.yaml b/templates/deploy.yaml
index 198516e..64be153 100644
--- a/templates/deploy.yaml
+++ b/templates/deploy.yaml
@@ -1,21 +1,5 @@
 apiVersion: apps/v1beta1
 kind: Deployment
-metadata:
-  name: myserver1
-spec:
-  replicas: 1
-  template:
-    metadata:
-      labels:
-        service: myserver1
-    spec:
-      containers:
-      - name: main
-        command: ["/bin/bash", "-c", "while true ; do date ; sleep 1 ; done"]
-        image: ubuntu:16.04
----
-apiVersion: apps/v1beta1
-kind: Deployment
 metadata:
   name: myserver2
 spec:
@@ -28,4 +12,3 @@ spec:
       containers:
       - name: main
         command: ["/bin/bash", "-c", "while true ; do date ; sleep 1 ; done"]
-        image: ubuntu:16.04

1. Exécutez le déploiement:

git checkout break-atomic
helm upgrade --atomic --install --namespace myns myrelease .

Dites encore bonjour à notre ami:

UPGRADE FAILED
ROLLING BACK
Error: Deployment.apps "myserver2" is invalid: spec.template.spec.containers[0].image: Required value
Error: no Deployment with the name "myserver1" found

@bacongobbler @ thomastaylor312 @jkroepke

@distorhead quel était votre comportement attendu pour ce scénario?

Légèrement décalé à propos des retours en arrière, mais de toute façon.

Pour les personnes qui souhaitent utiliser la restauration, mais qui ne veulent pas non plus que la restauration se produise immédiatement après le déploiement, comme dans --atomic pour certaines raisons. Parce que, par exemple, il n'y a aucun moyen pour l'utilisateur d'inspecter manuellement l'état incorrect du cluster après un échec et parce que l'indicateur --wait ne permet pas à helm de consigner des informations sur les échecs dans les ressources en cours de déploiement. Ensuite, il y a un moyen: revenir en arrière à la prochaine exécution, avant la mise à niveau (plus d'infos https://github.com/helm/helm/issues/3149#issuecomment-462271103)

Pour réitérer le problème ainsi que la solution de contournement:

Lorsqu'une mise à niveau qui installe de nouvelles ressources échoue, la version passe à l'état ÉCHEC et arrête le processus de mise à niveau. La prochaine fois que vous appelez helm upgrade , Helm effectue une comparaison avec la dernière version DEPLOYED. Dans la dernière version DEPLOYED, cet objet n'existait pas, il tente donc de créer la nouvelle ressource, mais échoue car il existe déjà. Le message d'erreur est complètement trompeur comme le souligne @arturictus .

Cela peut facilement être contourné en intervenant manuellement et en supprimant la ressource que l'erreur signale comme "introuvable". En suivant l'exemple que j'ai démontré dans # 4223 (commentaire) :

><> helm fetch --untar https://github.com/helm/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml                    # change the service name from "foo" to "foo-bar"
><> kubectl create -f foo/templates/service.yaml      # create the service
service "foo-bar" created
><> helm upgrade $(helm last) ./foo/
Error: UPGRADE FAILED: no Service with the name "foo-bar" found
><> kubectl delete svc foo-bar
service "foo-bar" deleted
><> helm upgrade $(helm last) ./foo/
Release "riotous-echidna" has been upgraded. Happy Helming!
...
><> kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
foo-bar      ClusterIP   10.104.143.52   <none>        80/TCP    3s
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   1h

En d'autres termes, la suppression des ressources créées lors de la version FAILED résout le problème.

Merci d'avoir mis en place cette solution de contournement @bacongobbler - c'est essentiellement ce à quoi nous sommes arrivés en tant que processus. Un problème douloureux ici est lors des mises à niveau complexes, de nombreuses nouvelles ressources - parfois quelques niveaux de dépendances profonds - peuvent se trouver dans cet état. Je n'ai pas encore trouvé un moyen d'énumérer complètement ces états d'une manière automatique conduisant à des situations où l'on doit échouer à plusieurs reprises une mise à niveau pour «rechercher» toutes les ressources pertinentes. Par exemple, récemment, une dépendance nouvellement ajoutée elle-même avait une dépendance sur un graphique postgresql. Afin de résoudre ce problème, il était nécessaire de supprimer un secret, une configuration, un service, un déploiement et un PVC - chacun trouvé le long chemin.

Vous pouvez écrire un plugin similaire à helm diff qui énumérerait les modèles créés dans la dernière version. Vous pouvez même consommer pkg/kube directement depuis Helm. client.Update a une logique métier écrite pour le suivi / suppression des ressources de helm qui pourrait être réutilisée en récupérant les deux versions de Tiller et en inversant l'ordre de comparaison. target.Difference(original) devrait vous donner un résultat de toutes les ressources qui ont été introduites depuis la version précédente.

@bacongobbler Quelle solution recommanderiez-vous pour prendre une application déployée dans le cadre de la version A (par exemple, une version plus grande composée de plusieurs applications) et la séparer de la version A dans sa propre version (ou vice versa) sans subir de temps d'arrêt (la solution de contournement pour supprimer des ressources entraînerait des temps d'arrêt) ... Essayer de mettre à jour une ressource via une version différente entraîne l'erreur décrite par ce problème Github.

cela ressemble à ce nouveau graphique, il a été installé et remplace les anciens graphiques avant même un déploiement réussi. Même chose avec une mise à niveau échouant --install. Il ne doit pas être installé si le graphique est erroné.
Revenez simplement à l'état précédent en cas d'erreur ou mettez à jour les graphiques de barre en cas de succès.

C'est un processus que j'utilise pour récupérer de ce problème (jusqu'à présent, il a fonctionné à chaque fois sans aucun incident ... mais soyez prudent quand même):

1. Exécutez helm list et découvrez la dernière révision du graphique concerné

   NAME        REVISION UPDATED                  STATUS  CHART              NAMESPACE
   fetlife-web 381      Thu Mar 15 19:46:00 2018 FAILED  fetlife-web-0.1.0  default
   

2. Allez à partir de là et trouvez la dernière révision avec l'état DEPLOYED
kubectl -n kube-system edit cm fetlife-web.v381 kubectl -n kube-system edit cm fetlife-web.v380 kubectl -n kube-system edit cm fetlife-web.v379 kubectl -n kube-system edit cm fetlife-web.v378
3. Une fois que vous avez trouvé la dernière révision DÉPLOYÉE, changez son état de DEPLOYED à SUPERSEDED et enregistrez le fichier
4. Essayez à nouveau de faire helm upgrade , si cela réussit, vous avez terminé!
5. Si vous rencontrez une erreur de mise à niveau comme celle-ci:
   Error: UPGRADE FAILED: "fetlife-web" has no deployed releases
   puis modifiez le statut de la toute dernière révision de FAILED à DEPLOYED
kubectl -n kube-system edit cm fetlife-web.v381
6. Essayez à nouveau de faire helm upgrade , si cela échoue à nouveau, retournez simplement la table ...

@bacongobbler @michelleN
Y a-t-il quelque chose qui rend difficile l'amélioration du message d'erreur pour ce problème?

Je crois que le message d'erreur devrait indiquer qu '"il y a un conflit parce que la ressource n'a pas été créée par la barre et qu'une intervention manuelle est requise" et non "introuvable". Seule cette petite modification de l'erreur améliorera l'expérience utilisateur d'une bonne marge.

@selslack Je serais très favorable à l'amélioration du message d'erreur 👍

@michelleN J'ai préparé un PR pour modifier le texte d'erreur: # 5460.

Je rencontre ce problème et je suis dans une situation où je ne sais pas comment le résoudre.

J'ai essayé toutes les étapes répertoriées par @reneklacan ici: https://github.com/helm/helm/issues/1193#issuecomment -470208910

Malheureusement, cela n'a pas fonctionné. La seule chose qui résout le problème est de supprimer la ressource générant le message d'erreur, puis de nouveau helm upgrade , ce qui réussira.

Cependant, la prochaine mise à niveau de la barre échouera avec la même erreur, et je dois à nouveau supprimer la ressource et la remettre à niveau ... ce n'est pas durable ou bon.

J'ai deux environnements dans lesquels j'utilise helm pour me déployer dans le cadre de notre processus CI: un QA et un environnement de production.

L'environnement QA avait le même problème, j'ai donc utilisé helm delete --purge , puis helm upgrade - qui a résolu le problème de manière permanente.

Cependant, je ne peux pas faire cela pour l'environnement de production - je ne peux pas simplement l'effacer et le remettre à niveau, donc actuellement je suis bloqué en supprimant la ressource avant chaque déploiement. J'ai juste de la chance que ce ne soit pas une ressource d'importation.

@zacharyw à quelle erreur êtes-vous confronté en ce moment? No resource with the name ... ou "fetlife-web" has no deployed releases ?

Pouvez-vous partager des informations supplémentaires qui aideraient à déboguer cela?

Peut-être une sortie de kubectl -n kube-system describe cm -l NAME=YOUR_RELEASE_NAME | grep -A1 STATUS= (remplace YOUR_RELEASE_NAME )

N'hésitez pas à m'envoyer un e-mail avec plus d'informations si vous ne voulez pas spammer ce problème avec des données potentiellement non liées (rene (at) klacan (dot) sk).

Veuillez consulter https://github.com/helm/helm/issues/1193#issuecomment -419555433 pour un diagnostic possible et une solution de contournement, @zacharyw.

@reneklacan C'est l'erreur no resource with the name ... . Dans notre cas, nous avons ajouté une entrée, cela a apparemment fonctionné, mais les mises à niveau ultérieures ont commencé à échouer avec cette erreur ... même si l'entrée existait déjà.

Le statut de ma version la plus récente (après avoir supprimé l'entrée incriminée et autorisé la mise à niveau de la barre à la recréer) est DEPLOYED :

STATUS=DEPLOYED
VERSION=197

Cependant, si je devais essayer de mettre à niveau à nouveau, cela échouerait.

@bacongobbler Sauf erreur de compréhension, je pense que je fais déjà la solution de contournement dans ce commentaire: je supprime la ressource et la laisse recréer ... le problème est que je dois le faire à chaque fois.

@reneklacan sur https://github.com/helm/helm/issues/1193#issuecomment -470208910 m'a sauvé la vie.

C'est une déception que Helm échoue de cette façon. Supprimer des éléments dans à peu près n'importe quel environnement est loin d'être idéal.

Ce serait formidable si helm mettait à jour sa propre base de données lorsque ce type d'erreur apparaît, puis réessayez.

Je crois qu'avec le drapeau --cleanup-on-fail activé, ce cas d'erreur devrait disparaître. Clôture résolue via les # 4871 et # 5143.

Si d'autres problèmes surviennent sans ces indicateurs, veuillez rouvrir un nouveau numéro. Merci!

Le problème est clos, j'ai pensé ajouter un commentaire sur la façon de traiter le problème sans avoir à supprimer la version de la barre ou les déploiements en cours.

J'ai donc reproduit le problème avec les étapes suivantes:

1. Installez le graphique test-chart-failure avec un modèle de service.
2. Ajouter un sous-diagramme avec un modèle de service qui a une chaîne (par exemple "test") dans le port du service
3. Mettez à niveau le graphique. Il échouera avec l'erreur Service in version "v1" cannot be handled as a Service: v1.Service.Spec: v1.ServiceSpec.Ports: []v1.ServicePort: v1.ServicePort.Port: readUint32: unexpected character: ...

J'ai pu mettre à niveau après avoir corrigé le port vers un numéro, sans exécuter helm delete , en appliquant la suggestion à http://centosquestions.com/helm-how-to-delete-bad-deployment :

1. La révision a échoué avec helm history test-chart-failure
2. Suppression de la carte de configuration de la révision spécifique avec kubectl delete cm -n kube-system test-chart-failure.v2
3. Exécuté helm upgrade avec le graphique corrigé