Supprimer complètement la version de Helm via helm delete release fonctionne, mais ce n'est pas une solution viable.

Pourquoi Helm ne peut-il pas simplement écraser tout ce qui est actuellement installé? Ne vivons-nous pas dans un monde déclaratif avec Kubernetes?

J'ai juste la même chose ... tout à fait nouveau pour moi car cela semble être un nouveau problème. supprimer la ressource le corrigera.
v2.7.2 avec Kubernetes 1.7.7.
joli ça marchait avant ...

J'ai eu ce problème - c'était dû à un PersistentVolume que j'avais créé. Pour résoudre, j'ai supprimé le PV et le PVC. Ran helm upgrade XXX XXX et cela a bien fonctionné. Probablement encore quelque chose qui devrait être étudié car le PV existait.

J'ai eu le sentiment que cela pourrait être lié à un mauvais pv ... mais l'erreur est plutôt trompeuse!
aussi quelques journaux bizarres de tiller ... il semble qu'il fonctionne sur la version 2 en même temps ...

juste essayé avec 2.7.1 sans chance ...

[main] 2017/12/21 15:30:48 Démarrage de Tiller v2.7.1 (tls = false)
[main] 2017/12/21 15:30:48 GRPC écoute sur: 44134
[main] 2017/12/21 15:30:48 Sondes en écoute sur: 44135
[main] 2017/12/21 15:30:48 Le pilote de stockage est ConfigMap
[main] 21/12/2017 15:30:48 L'historique maximum par version est de 0
[tiller] 21/12/2017 15:30:55 préparation de la mise à jour pour xxx
[stockage] 2017/12/21 15:30:55 obtention de la version déployée de l'historique "xxx"
[tiller] 2017/12/21 15:30:56 copie des valeurs de xxx (v65) vers la nouvelle version.
[stockage] 21/12/2017 15:30:56 obtention de la dernière révision de "xxx"
[stockage] 21/12/2017 15:30:56 obtention de l'historique des versions pour "xxx"
[tiller] 2017/12/21 15:30:59 rendu du graphique helm-xxx à l'aide de valeurs
2017/12/21 15:30:59 info: le manifeste "helm-xxx / templates / scheduler-deploy.yaml" est vide. Saut.
2017/12/21 15:30:59 info: le manifeste "helm-xxx / templates / recomposer-deploy.yaml" est vide. Saut.
2017/12/21 15:31:00 info: le manifeste "helm-xxx / templates / recomposer-pvc.yaml" est vide. Saut.
2017/12/21 15:31:00 info: le manifeste "helm-xxx / templates / scheduler-pvc.yaml" est vide. Saut.
2017/12/21 15:31:00 info: le manifeste "helm-xxx / templates / scheduler-secret.yaml" est vide. Saut.
2017/12/21 15:31:00 info: le manifeste "helm-xxx / templates / recomposer-secret.yaml" est vide. Saut.
[tiller] 2017/12/21 15:31:09 création de la version mise à jour pour xxx
[stockage] 2017/12/21 15:31:09 création de la version "xxx.v80"
[tiller] 2017/12/21 15:31:09 mise à jour pour xxx
[tiller] 21/12/2017 15:31:09 exécution de 0 hooks de pré-mise à niveau pour xxx
[tiller] 21/12/2017 15:31:09 crochets terminés pour la pré-mise à niveau xxx
[tiller] 21/12/2017 15:31:11 préparation de la mise à jour pour xxx
[stockage] 2017/12/21 15:31:11 obtention de la version déployée de l'historique "xxx"
[stockage] 2017/12/21 15:31:11 obtention de la dernière révision de "xxx"
[stockage] 21/12/2017 15:31:11 obtention de l'historique des versions pour "xxx"
[tiller] 2017/12/21 15:31:18 rendu du graphique helm-xxx à l'aide de valeurs
2017/12/21 15:31:18 info: le manifeste "helm-xxx / templates / scheduler-secret.yaml" est vide. Saut.
2017/12/21 15:31:18 info: le manifeste "helm-xxx / templates / scheduler-pvc.yaml" est vide. Saut.
2017/12/21 15:31:19 info: le manifeste "helm-xxx / templates / scheduler-deploy.yaml" est vide. Saut.
[kube] 2017/12/21 15:31:28 création de ressources à partir du manifeste mis à jour
[tiller] 2017/12/21 15:31:46 création de la version mise à jour pour xxx
[stockage] 21/12/2017 15:31:46 création de la version "xxx.v81"
[tiller] 2017/12/21 15:31:47 exécution d'une mise à jour pour xxx
[tiller] 21/12/2017 15:31:47 exécution de 0 hooks de pré-mise à niveau pour xxx
[tiller] 21/12/2017 15:31:47 hooks terminés pour la pré-mise à niveau xxx
[kube] 2017/12/21 15:31:49 vérification de 7 ressources pour les changements
[kube] 2017/12/21 15:31:49 On dirait qu'il n'y a pas de changement pour Secret "xxx-helm-xxx-nginx-secret"
[kube] 2017/12/21 15:31:50 On dirait qu'il n'y a pas de changement pour Secret "xxx-application-secret"
[kube] 2017/12/21 15:31:50 Il semble qu'il n'y ait aucun changement pour Secret "azure-secret"
[kube] 2017/12/21 15:31:51 Il semble qu'il n'y ait aucun changement pour ConfigMap "xxx-helm-xxx-nginx-config"
[kube] 2017/12/21 15:31:51 Il semble qu'il n'y ait aucun changement pour ConfigMap "xxx-application-config"
[kube] 21/12/2017 15:31:51 Il semble qu'il n'y ait aucun changement pour le service "xxx-application-svc"
[kube] 21/12/2017 15:31:51 Il semble qu'il n'y ait aucun changement pour StatefulSet "xxx-application"
[tiller] 21/12/2017 15:31:51 exécution de 0 hooks post-mise à niveau pour xxx
[tiller] 21/12/2017 15:31:51 hooks terminés pour la post-mise à niveau xxx
[stockage] 2017/12/21 15:31:51 mise à jour de la version "xxx.v65"
[tiller] 2017/12/21 15:31:51 état de mise à jour de la version mise à jour pour xxx
[stockage] 2017/12/21 15:31:51 mise à jour de la version "xxx.v80"
[kube] 21/12/2017 15:31:57 création de ressources à partir du manifeste mis à jour
[kube] 21/12/2017 15:32:10 vérification de 11 ressources pour les modifications
[kube] 21/12/2017 15:32:10 On dirait qu'il n'y a pas de changement pour Secret "xxx-helm-xxx-nginx-secret"
[tiller] 21/12/2017 15:32:10 avertissement: échec de la mise à niveau "xxx": aucune ressource portant le nom "xxx-recomposer-secret" trouvée
[stockage] 2017/12/21 15:32:10 mise à jour de la version "xxx.v65"
[stockage] 2017/12/21 15:32:10 mise à jour de la version "xxx.v81"

semble être confus à faire pour sortir en même temps ...

vient de réappliquer la même configuration deux fois ...

[tiller] 21/12/2017 15:50:46 préparation de la mise à jour pour xxx
[stockage] 21/12/2017 15:50:46 obtention de la version déployée de l'historique "xxx"
[stockage] 2017/12/21 15:50:46 obtention de la dernière révision de "xxx"
[stockage] 21/12/2017 15:50:46 obtention de l'historique des versions pour "xxx"
[tiller] 2017/12/21 15:50:50 rendu du graphique helm-xxx à l'aide de valeurs
2017/12/21 15:50:50 info: le manifeste "helm-xxx / templates / scheduler-pvc.yaml" est vide. Saut.
2017/12/21 15:50:50 info: le manifeste "helm-xxx / templates / recomposer-deploy.yaml" est vide. Saut.
2017/12/21 15:50:50 info: le manifeste "helm-xxx / templates / scheduler-secret.yaml" est vide. Saut.
2017/12/21 15:50:50 info: le manifeste "helm-xxx / templates / scheduler-deploy.yaml" est vide. Saut.
2017/12/21 15:50:50 info: le manifeste "helm-xxx / templates / recomposer-secret.yaml" est vide. Saut.
2017/12/21 15:50:50 info: le manifeste "helm-xxx / templates / recomposer-pvc.yaml" est vide. Saut.
[tiller] 2017/12/21 15:50:58 création de la version mise à jour pour xxx
[stockage] 21/12/2017 15:50:58 création de la version "xxx.v85"
[tiller] 21/12/2017 15:50:59 exécution d'une mise à jour pour xxx
[tiller] 21/12/2017 15:50:59 exécution de 0 hooks de pré-mise à niveau pour xxx
[tiller] 21/12/2017 15:50:59 hooks terminés pour la pré-mise à niveau xxx
[kube] 21/12/2017 15:51:13 création de ressources à partir du manifeste mis à jour
[kube] 2017/12/21 15:51:22 vérification de 7 ressources pour les changements
[kube] 21/12/2017 15:51:22 Il semble qu'il n'y ait aucun changement pour Secret "xxx-helm-xxx-nginx-secret"
[kube] 2017/12/21 15:51:23 Il semble qu'il n'y ait aucun changement pour Secret "xxx-application-secret"
[kube] 2017/12/21 15:51:23 Il semble qu'il n'y ait aucun changement pour Secret "azure-secret"
[kube] 2017/12/21 15:51:23 Il semble qu'il n'y ait aucun changement pour ConfigMap "xxx-helm-xxx-nginx-config"
[kube] 2017/12/21 15:51:23 On dirait qu'il n'y a pas de changements pour ConfigMap "xxx-application-config"
[kube] 21/12/2017 15:51:24 Il semble qu'il n'y ait aucun changement pour le service "xxx-application-svc"
[kube] 21/12/2017 15:51:24 Suppression de "xxx-recomposer-secret" dans xxx ...
[kube] 21/12/2017 15:51:24 Échec de la suppression de "xxx-recomposer-secret", err: secrets "xxx-recomposer-secret" non trouvés
[kube] 21/12/2017 15:51:24 Suppression de "xxx-recomposer-config" dans xxx ...
[kube] 2017/12/21 15:51:24 Échec de la suppression de "xxx-recomposer-config", err: configmaps "xxx-recomposer-config" introuvable
[kube] 21/12/2017 15:51:24 Suppression de "xxx-recomposer-pv" dans ...
[kube] 21/12/2017 15:51:24 Échec de la suppression de "xxx-recomposer-pv", erreur: les volumes persistants "xxx-recomposer-pv" sont introuvables
[kube] 21/12/2017 15:51:24 Suppression de "xxx-recomposer-pvc" dans xxx ...
[kube] 2017/12/21 15:51:24 Échec de la suppression de "xxx-recomposer-pvc", erreur: persistentvolumeclaims "xxx-recomposer-pvc" introuvable
[kube] 21/12/2017 15:51:24 Suppression de "xxx-recomposer" dans xxx ...
[kube] 2017/12/21 15:51:24 Utilisation de Reaper pour supprimer "xxx-recomposer"
[kube] 21/12/2017 15:51:24 Échec de la suppression de "xxx-recomposer", erreur: deployments.extensions "xxx-recomposer" introuvable
[tiller] 21/12/2017 15:51:24 exécution de 0 hooks post-mise à niveau pour xxx
[tiller] 21/12/2017 15:51:24 hooks terminés pour la post-mise à niveau xxx
[stockage] 2017/12/21 15:51:24 mise à jour de la version "xxx.v68"
[tiller] 2017/12/21 15:51:24 état de mise à jour de la version mise à jour pour xxx
[stockage] 2017/12/21 15:51:24 mise à jour de la version "xxx.v85"
[stockage] 2017/12/21 15:51:25 obtention de la dernière révision de "xxx"
[stockage] 21/12/2017 15:51:25 obtention de l'historique des versions pour "xxx"
[kube] 21/12/2017 15:51:38 Faire get for Secret: "xxx-helm-xxx-nginx-secret"
[kube] 2017/12/21 15:51:39 obtenir la relation pod de l'objet: xxx / Secret / xxx-helm-xxx-nginx-secret
[kube] 21/12/2017 15:51:39 Faire get for Secret: "xxx-application-secret"
[kube] 21/12/2017 15:51:39 obtenir le module de relation de l'objet: xxx / Secret / xxx-application-secret
[kube] 21/12/2017 15:51:39 Faire get for Secret: "azure-secret"
[kube] 21/12/2017 15:51:39 obtenir la relation pod de l'objet: xxx / Secret / azure-secret
[kube] 21/12/2017 15:51:39 Faire get pour ConfigMap: "xxx-helm-xxx-nginx-config"
[kube] 21/12/2017 15:51:39 obtenir le module de relation de l'objet: xxx / ConfigMap / xxx-helm-xxx-nginx-config
[kube] 21/12/2017 15:51:39 Faire get pour ConfigMap: "xxx-application-config"
[kube] 21/12/2017 15:51:39 obtenir le pod de relation de l'objet: xxx / ConfigMap / xxx-application-config
[kube] 21/12/2017 15:51:39 Obtention du service: "xxx-application-svc"
[kube] 21/12/2017 15:51:39 obtenir le pod de relation de l'objet: xxx / Service / xxx-application-svc
[kube] 21/12/2017 15:51:39 Faire get pour StatefulSet: "xxx-application"
[kube] 21/12/2017 15:51:39 obtenir le module de relation de l'objet: xxx / StatefulSet / xxx-application

pourrait être lié à # 2941

a dit dans l'autre fil, l'un des moyens de résoudre le problème était de supprimer les configmaps bogués ... semble le faire pour moi actuellement ...

Tout cela est bien et dandy. Jusque-là, lorsque vous devez supprimer quelque chose de critique d'un espace de noms de production. Ce qui, par hasard, m'est arrivé tout à l'heure. : c

J'ai également rencontré le problème lorsque nous mettons à jour une version s'il y a plusieurs statuts DEPLOYED de cette version, je dois le résoudre en supprimant les configmaps correspondantes.

Même problème. Tout allait bien hier et j'ai fait plusieurs mises à niveau. Aujourd'hui, je viens d'ajouter un nouveau yaml avec service bloc deployment séparé par --- et la mise à niveau a échoué.

Ce qui est intéressant, c'est que helm a créé le service puis s'en est plaint (et n'a pas fait le déploiement).
J'ai commenté le service et j'ai juste exécuté la mise à niveau avec le bloc deployment - cela a fonctionné. Cependant, helm n'a pas supprimé le service - ce qu'il devrait avoir car il est supprimé du fichier yaml.

Mise à jour : J'ai supprimé manuellement le service , je l'ai décommenté du yaml et j'ai exécuté la mise à niveau - cette fois, cela a fonctionné comme un charme!

J'avais cette erreur exacte. Il semble que le problème soit lié aux modèles avec plusieurs objets API similaires à ce que @amritb a vu. Dans mon cas, j'avais un modèle qui avait plusieurs objets API qui pouvaient être activés et désactivés comme:

{{ if .Values.enabled }}
---
...

Le fractionnement dans son propre fichier modèle et le nettoyage des objets orphelins que helm a créés et oubliés ont résolu le problème pour moi. Il semble qu'il y ait un bogue dans la façon dont helm obtient la configuration précédente si le nombre d'objets par modèle change entre les versions.

Ajout d'un autre point de données: je semble avoir exactement le même problème que @awwithro. Nous utilisons une boucle jinja pour créer plusieurs cronjobs via un modèle, et lorsqu'une nouvelle mise à jour a amené cette boucle à remplir un cronjob supplémentaire, nous avons rencontré le bogue. Semblait également déclencher le # 2941 (ou peut-être un bogue en cause l'autre), et la suppression des configmaps de zombies le corrige.

Juste piégé dans ce même sans utiliser de configmaps

Une couleur supplémentaire pour quiconque peut être coincé:
J'étais confronté à cela lors de l'introduction de nouveaux sous-graphiques et objets dans ma version. J'ai pu résoudre le problème en vérifiant chaque type d'objet ajouté et en supprimant tous les objets existants susceptibles de provoquer une collision de noms.

Cela semble aller dans le sens des preuves d'autres que la suppression est le seul moyen de résoudre maintenant

Courant également à travers ce = \

J'avais également besoin de supprimer les ressources affectées. Pas bon pour un environnement de production = _ (

Je vois quelque chose qui me semble similaire. Le problème semble être qu'un helm upgrade ne réutilise pas les valeurs du déploiement précédent. Si je spécifie le même ensemble de valeurs sur la ligne de commande que l'installation initiale, alors helm upgrade fonctionne. Je ne sais pas si cela aide (ou quelqu'un d'autre peut le confirmer).

Comme @amritb , après avoir supprimé manuellement l'objet sur lequel helm a échoué initialement, il a réussi après la prochaine mise à niveau. Je n'ai pas fait l'expérience du # 2941.

Le même problème avec helm 2.8.0 . Versions de Kubernetes client=v1.8.6 et server=v1.8.5-gke.0 .

$ helm upgrade bunny ./app --debug
[debug] Created tunnel using local port: '54274'

[debug] SERVER: "127.0.0.1:54274"

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

Mais la configuration existe dans $ kubectl get configmap . Si je supprime manuellement le configmap, cela fonctionne, mais la prochaine fois, il échoue à nouveau.

Voici le configmap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ template "proxy.fullname" . }}-config
  # namespace: {{ .Release.Namespace }} # I've tried adding and removing it
  labels: # labels are the same as labels from $ kubectl describe configmap bunny-proxy-config
    app: {{ template "proxy.name" . }}
    chart: {{ template "proxy.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
data:
  asd: qwe

J'ai supprimé la version et réinstallé à nouveau. De plus, j'utilisais la version api extensions/v1beta pour le déploiement, j'ai changé en apiVersion: apps/v1beta2 , je ne sais pas si cela a aidé ou non.
Aussi actuellement j'exécute tiller localement.

En ce moment, il semble que tout fonctionne.

Ceci est vraiment facile à reproduire, se produit s'il y a une erreur dans le manifeste.

Comme nous avons resource1 et resource2, resource2 dépend en premier. Lorsque nous mettons à niveau la version, resource1 est créée (par exemple PV & PVC), mais resource2 échoue. Après cela, seule la suppression de resource1 aide, car helm signale toujours un problème lors de la mise à niveau (PersistentVolume avec le nom ... introuvable)

Nous avons eu le même problème (la ressource qui nous a obtenus était Secrets). La suppression des nouveaux secrets et le redéploiement l'ont corrigé.

Notez qu'en raison des échecs, nous avons maintenant 11 versions différentes lorsque nous faisons helm list , 10 FAILED et 1 DEPLOYED. Ce n'est pas prévu, non? Même problème qu'ici il semble: https://github.com/kubernetes/helm/issues/2941

Cela a rendu Helm inutilisable pour les déploiements de production réguliers pour nous: (Nous étudions actuellement des choses comme passer --dry-run à helm et le faire passer à kubectl apply ... Puisque cela semble n'affecter qu'un sous-ensemble d'utilisateurs , je ne suis pas sûr de ce que nous faisons de mal :(

Après avoir suivi les journaux de barre franche, j'ai trouvé que tiller essayait de mettre à jour une ancienne version en même temps:

[storage] 2018/02/14 18:25:40 updating release "s2osf.v10"
[storage] 2018/02/14 18:25:40 updating release "s2osf.v44"

La suppression de l'ancienne configuration de s2osf.v10 et la mise à niveau ont fonctionné.

Client: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}

Ayant le même problème que @binoculars :

[storage] 2018/02/15 10:20:50 updating release "control.v136"
[storage] 2018/02/15 10:20:50 updating release "control.v226"

Causer des problèmes étranges avec UPGRADE FAILED: no Secret with the name "foobar" found .
J'ai même essayé de supprimer ce secret qui a ensuite causé des erreurs sur certains configmap à la place, et à la troisième exécution, il s'est à nouveau plaint du secret précédent.

Cela peut avoir été déclenché après la mise à niveau de helm 2.7.x vers 2.8.1.

Client: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}

si votre dernier recours consiste à supprimer l'ancienne version, il pourrait y avoir un travail moins destructeur comme mon commentaire https://github.com/kubernetes/helm/issues/3513#issuecomment -366918019

en gros, trouver cette ancienne révision dans les journaux et éditer manuellement la configmap où tiller stocke l'état déployé. Il ne devrait pas y avoir deux révisions avec le statut DEPLOYED afaik.

J'ai trouvé une nouvelle solution à ce problème.

kubectl -n kube-system edit cm name_of_your_release.v2 , où v2 est le dernier numéro de révision marqué comme FAILED dans helm list . Vous pouvez également modifier l'une des versions DEPLOYED et changer le statut en SUPERSEDED, afin que nous n'ayons pas deux versions déployées en même temps.

@zuzzas c'est ce à quoi j'ai fait référence. A travaillé pour moi aussi

@balboah le problème est que nous n'avons qu'un seul déploiement dans l'état DEPLOYED, mais s'il ne s'agit pas des derniers (qui sont marqués comme FAILED, dans la plupart des scénarios), il plantera toujours. Le problème ne semble pas lié au fait d'avoir deux ou plusieurs déploiements à l'état DÉPLOYÉ dans la plupart de nos cas.

@zuzzas avez-vous plusieurs versions dans le même espace de noms ou une seule? Une fois, j'ai eu un problème avec deux versions mettant à jour les mêmes objets, puis ils entreront en conflit.

S'il ne s'agit que d'un seul, combien de pannes avez-vous jusqu'à la version déployée? comment avez-vous vérifié que son seul déployé?

Nous pensons que cela a été corrigé (à l'avenir) via # 3539. Veuillez rouvrir si nous nous trompons. :)

Merci à tous pour votre travail là-dessus!

Notez que cela n'a pas été corrigé pour les graphiques existants dans cet état; vous devrez toujours supprimer les anciennes versions qui sont dans l'état DÉPLOYÉ pour que les choses fonctionnent à nouveau. @balboah a juste empêché le cas où vous pouvez entrer dans l'état "plusieurs versions marquées comme DÉPLOYÉES". :)

Hm, j'obtiens toujours ce problème sur Helm 2.8.2 (pas le dernier, mais j'ai essayé avec 2.9.0 et cela donne la même erreur.) Habituellement, la suppression manuelle de la ressource incriminée peut le résoudre, bien que souvent cela se transforme en plusieurs ressources qui tous doivent être supprimés avant d'être mis à niveau avec succès.

J'ai un peu d'un grand graphique de barre avec des dépendances imbriquées; ça pourrait être ça?

Je vois le même problème avec clusterrolebinding. J'ai ajouté la nouvelle ressource à mon graphique et upgrade ainsi que upgrade --install échoueraient avec Error: UPGRADE FAILED: no ClusterRoleBinding with the name "test-clusterrolebinding" found

Je rencontre le même problème que @ramyala avec ClusterRole. ClusterRole existe, mais la création de RoleBinding échoue avec cette erreur.

Sur Helm 2.9.1 j'ai rencontré le même problème:

helm upgrade --install --namespace my-namespace my-stack stack
Error: UPGRADE FAILED: no ConfigMap with the name "my-stack-my-app" found

Pendant que je vois ce ConfigMap sur mon cluster.

Je rencontre ce problème si j'ai plusieurs ressources avec des crochets dans un fichier

+1, cela se reproduit avec 2.9.1. Veuillez rouvrir.

Ré-étiqueter cela comme un bogue. Nous ne sommes pas sûrs de la cause de cette régression, mais si quelqu'un peut fournir des étapes sur la façon de reproduire ce bogue sur 2.9.1, ce serait très apprécié.

@bacongobbler

Je vois cela aussi en essayant de déployer une nouvelle Ingress dans mon graphique de barre. Je suis certes nouveau dans Ingress, mais il semble que ce soit correct d'après tous les exemples et je fais d'autres trucs de helm / k8 depuis quelques mois.

J'ai déjà déployé le graphique de barre stable/nginx-ingress donc le contrôleur est présent. L'erreur semble suggérer qu'il essaie de trouver celui que j'essaie de créer. Voici la commande que j'exécute:

helm upgrade some-existing-release-name -i --set imageTag=$TAG-$BUILD_NUMBER --namespace=default ./deploy/helm où deploy/helm contient mes manifestes de graphique.

Error: UPGRADE FAILED: no Ingress with the name "my-ingress" found

yaml:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  labels:
    app: my-app
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - host: {{ $.Values.appDomain }}
    http:
      paths:
      - path: /*
        backend:
          serviceName: web-app
          servicePort: 80
      - path: /api/*
        backend:
          serviceName: api
          servicePort: 8080

METTRE À JOUR
J'ai supprimé le /* de mes deux chemins et cela ne donnait plus d'erreur lors de la tentative de mise à niveau / d'installation. Peut-être que ce n'est tout simplement pas une syntaxe valide

Salut,
Voici les étapes qui ont introduit le problème dans mon env:

1. J'ai fait déployer et améliorer plusieurs fois une carte de barre.
2. Création d'un nouvel objet CronJob dans le graphique et mise à niveau à nouveau - le travail cron a été créé avec succès.
3. Toutes les prochaines mises à niveau échouent avec l'erreur signalée "Erreur: ECHEC DE LA MISE À NIVEAU: aucun CronJob avec le nom" cronjob-name "trouvé"

Je vois également le problème lorsque j'ajoute un secret qui n'existait pas auparavant. J'ai essayé d'ajouter un "db-credentials"
secret qui a conduit à:

Error: UPGRADE FAILED: no Secret with the name "db-credentials" found

correctif potentiellement pertinent: # 4146

si quelqu'un rencontrant cette erreur pouvait tester ce PR et voir s'il corrige cela, alors nous serions en mesure de confirmer qu'il s'agit probablement d'une régression dans l'API k8s et d'aller de l'avant avec ce correctif. Merci!

Je ne peux pas confirmer à 100% si cela se reproduira toujours, mais j'ai remarqué que cela a tendance à se produire dans la situation suivante:

1. Je mets à niveau un graphique Helm, y compris une nouvelle ressource
2. Cette mise à niveau échoue, mais la ressource a été créée dans le cadre de l'échec de la mise à niveau
3. Toutes les mises à niveau ultérieures échouent

Si je fais un helm rollback au dernier déploiement réussi et que j'essaye de le remettre à niveau, cela semble fonctionner.

Il semble très facile de le reproduire manuellement, sans essayer intentionnellement de mettre à niveau un graphique avec des changements nuisibles (par exemple, modifier un objet Job immuable):

1. Prenez un graphique et déployez-le (mais omettez une ressource, disons un service)
2. Ajouter la ressource omise manuellement (par exemple, avec "kubectl create"), mais avec le nom correspondant à la version
3. Ajoutez à nouveau la ressource omise au graphique, puis essayez de la mettre à niveau, la barre doit signaler «ÉCHEC DE LA MISE À NIVEAU: nonavec le nomtrouvé"

Les étapes sont différentes mais la cause première semble toujours la même. Corrigez-moi si je me trompe sur l'hypothèse, mais il me semble que la dernière révision de la version DEPLOYED ne contient pas d'informations sur la ressource particulière, soit parce qu'elle a été ajoutée "en dehors" de Helm (manuellement par exemple), soit parce que la dernière mise à jour a échoué sur une certaine étape (disons sur la mise à niveau d'un Job immuable), en même temps en déployant d'autres objets puis en les enregistrant dans la révision FAILED (mais toujours sans aucune piste dans la révision DEPLOYED ce qui est attendu, sinon cela signifierait changer l'historique) . Lors de la prochaine exécution, le client kube de Tiller voit les ressources sur le cluster, ce qui signifie qu'elles devraient être déjà déployées et donc enregistrées, il vérifie la dernière révision DEPLOYED (il semble que la révision FAILED n'est pas du tout contactée) et ne les voit pas listées ici donc il signale une erreur.

@bacongobbler J'ai testé # 4146 avec une image de barre personnalisée et cela a résolu ce problème! Pour les autres qui recherchent une solution, vous pouvez appliquer le correctif dans le problème sur le maître actuel et compiler:

make bootstrap build docker-build

Vous devrez télécharger l'image de la barre dans votre référentiel et réinstaller la barre dans votre cluster. J'ai pu m'en sortir avec une réinitialisation forcée et une réinstallation sans détruire les versions actuelles.

$GO_HOME/src/k8s.io/helm/bin/helm init -i gcr.io/my-repo/tiller:1 --service-account tiller

merci @ramyala pour avoir testé le correctif! Je le mentionnerai dans l'appel de développement de demain et verrai si l'un des autres responsables de base voit des cas extrêmes qui pourraient venir avec le correctif. Sinon, fusionnons.

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

Dans l'intérêt de garder les choses ensemble, je vais fermer cela comme un double de # 1193 puisque les deux tickets sont identiques. Veuillez y rapporter toutes les constatations afin que nous puissions tous travailler avec un seul ticket. Merci!

Attention: ces informations sont un peu fragmentaires et je ne peux pas les comprendre, mais juste au cas où cela serait utile à quelqu'un, j'ai contourné ce problème en changeant mon sélecteur de service de:

selector:
    app: {{ template "mything.name" . }}

à

selector:
    app: mything

Peut-être y a-t-il un problème avec l'utilisation d'une variable dans ce contexte?

Essayez helm delete RELEASE_NAME --purge
et réinstallez-le.

Je rencontre ce problème aussi. J'ai essayé d'ajouter un sous-diagramme avec un déploiement dans mon graphique, il a réussi lors de la mise à niveau avec helm upgrade chart chart-1.0.1.tgz juste pour la première fois, après cela, lorsque j'ai essayé helm upgrade chart chart-1.0.1.tgz il a échoué avec l'erreur Error: UPGRADE FAILED: no Deployment with name "subchart-deployment" found

Client: &version.Version{SemVer:"v2.12.0", GitCommit:"d325d2a9c179b33af1a024cdb5a4472b6288016a", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.12.0", GitCommit:"d325d2a9c179b33af1a024cdb5a4472b6288016a", GitTreeState:"clean"}

La barre franche enregistre simplement la même erreur. Quelqu'un a-t-il vécu cela aussi?

Même problème. Tout allait bien hier et j'ai fait plusieurs mises à niveau. Aujourd'hui, je viens d'ajouter un nouveau yaml avec service bloc deployment séparé par --- et la mise à niveau a échoué.

Ce qui est intéressant, c'est que helm a créé le service puis s'en est plaint (et n'a pas fait le déploiement).
J'ai commenté le service et j'ai juste exécuté la mise à niveau avec le bloc deployment - cela a fonctionné. Cependant, helm n'a pas supprimé le service - ce qu'il devrait avoir car il est supprimé du fichier yaml.

Mise à jour : J'ai supprimé manuellement le service , je l'ai décommenté du yaml et j'ai exécuté la mise à niveau - cette fois, cela a fonctionné comme un charme!

salut ， j'ai aussi ce problème, et je ne peux pas le résoudre, pouvez-vous me donner quelques invites.

voir https://github.com/helm/helm/issues/1193#issuecomment -419555433.

Je confirme simplement que je suis témoin du même problème et que la cause est également indiquée précédemment.

Ajout d'un nouveau secret, référencé dans un volume (syntaxe invalide). La mise à niveau a échoué, les mises à niveau ultérieures ont échoué avec l'erreur ci-dessus.

La liste des secrets a montré qu'elle avait été créée. Secret supprimé manuellement et la mise à niveau s'est déroulée avec succès.

Idem, @thedumbtechguy. Je rencontre régulièrement ce problème. C'est particulièrement amusant quand Helm décide que vous devez supprimer _tous_ vos secrets, configmaps, rôles, etc. La mise à niveau devient un jeu de wack-a-mole avec une liste toujours croissante d'arguments à kubectl delete . J'aurais dû jeter l'éponge sur cette tâche sisyphe il y a des mois, mais il est trop tard pour cela maintenant. J'espère que cela et les dizaines de problèmes similaires pourront être résolus!

J'utilise Helm depuis une semaine et j'ai déjà fait face à tout ce qui est décrit
ici https://medium.com/@7mind_dev/the -problems-with-helm-72a48c50cb45

Beaucoup de choses doivent être réparées ici.

Le vendredi 15 mars 2019, 22:49, Tom Davis [email protected] a écrit:

Idem, @thedumbtechguy https://github.com/thedumbtechguy . Je rencontre
ce problème régulièrement. C'est particulièrement amusant quand Helm décide que vous devez
supprimez tous vos secrets, configmaps, rôles, etc.
jeu de wack-a-mole avec une liste toujours croissante d'arguments à kubectl
effacer. J'aurais dû jeter l'éponge sur cette tâche sisyphéenne des mois
il y a, mais il est trop tard pour cela maintenant. J'espère bien que cela et les dizaines de
des problèmes similaires peuvent être résolus!

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/helm/helm/issues/3275#issuecomment-473464809 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AA4XZU4KMQePtZKcir8S5kWulkbYg-8Uks5vXCNggaJpZM4RGz7W
.

J'ai vécu la même chose avec Helm v2.10. J'avais déjà déployé un graphique, j'ai ajouté un autre configMap au graphique. Il a signalé que le déploiement a échoué car il n'a pas pu trouver configMap "bla". J'ai fait

helm upgrade <NAME> chart --debug --dryrun 

Pour vérifier que le configMap était bien rendu, il l'était. J'ai vérifié les configMaps dans le cluster et je l'ai trouvé là-bas. Supprimé le configMap blah, relancé la mise à niveau, cela a fonctionné.

https://github.com/helm/helm/pull/5460 devrait mieux clarifier le message d'erreur à l'avenir.

Bon point.

$ helm upgrade linting-unicorn testrail                                                                                                                                                                                        
Error: UPGRADE FAILED: no ConfigMap with the name "linting-unicorn-testrail-php-config" found

Continuez la bonne équipe de barre de travail.

Au cas où cela serait un gros problème pour quelqu'un d'autre, j'ai pensé que https://github.com/helm/helm/pull/4871 devrait résoudre ces problèmes.

Notez qu'il semble qu'il n'a toujours pas été approuvé par l'équipe Helm. De plus, il y avait des préoccupations concernant les ressources de suppression automatique. Il suffit de le mentionner au cas où quelqu'un voudrait le construire à partir des sources et l'essayer.

Avoir le même problème et la seule solution de contournement semble être helm delete --purge release et réinstaller!

J'ai rencontré le même problème. @fbcbarbosa il semble qu'il a été fusionné il y a 2 semaines. Il devrait, espérons-le, faire partie de la prochaine version 2.14.0 .

Avoir le même problème et la seule solution de contournement semble être helm delete --purge release et réinstaller!

Une option moins destructrice est de faire un helm rollback à la / current / version (c'est-à-dire par 0 pas). Je ne peux pas garantir le succès, mais pour nous, jusqu'à présent, il a toujours réussi à faire échouer les choses.

Y a-t-il une idée si cela sera dans la prochaine version, et si c'est le cas quand cela arrivera?

5460 a été fusionné il y a 2 mois, ce qui signifie qu'il devrait être à la barre 2.14.0.

J'ai résolu le problème en

1. supprimez les ressources qui se sont plaints de la "mise à niveau de la barre". (Il dit Non trouvé mais en fait, il peut être trouvé). Ne supprimez pas toute la version, sinon si vous êtes en production, vous serez complètement vissé.
2. refaire la mise à niveau de la barre. Maintenant, cette fois, il devrait être "Happy Helming" apparaît. :)

Nous avons rencontré ce problème dans PROD, lorsqu'une exigence de notre diagramme de barre ombrelle a ajouté une configuration basée sur un conditionnel. Pour nous, la solution de contournement consistait à

helm rollback <some revision that's acceptable>
helm upgrade <desired version>

Pour nous, un simple retour à la révision actuelle a toujours fonctionné:

helm ls
helm rollback <NAME> <current REVISION>

@tobypeschel avez-vous une idée du fonctionnement de votre solution?