Eliminar completamente la versión de Helm a través de helm delete release funciona, pero no es una solución viable.

¿Por qué Helm no puede simplemente sobrescribir lo que esté instalado actualmente? ¿No vivimos en un mundo declarativo con Kubernetes?

Acabo de recibir lo mismo ... bastante nuevo para mí, parece ser un tema nuevo. eliminar el recurso lo solucionará.
v2.7.2 con Kubernetes 1.7.7.
bonito funcionó antes ...

Tuve este problema: se debió a un PersistentVolume que había creado. Para resolver, eliminé el PV y el PVC. Ejecutó helm upgrade XXX XXX y funcionó bien. Probablemente todavía algo que debería investigarse ya que el PV existía.

Tengo la sensación de que podría estar relacionado con un pv malo ... ¡pero el error es bastante engañoso!
también algunos registros extraños de tiller ... parece que está funcionando en la versión 2 al mismo tiempo ...

acabo de probar con 2.7.1 sin suerte ...

[principal] 21/12/2017 15:30:48 Tiller de arranque v2.7.1 (tls = false)
[principal] 2017/12/21 15:30:48 GRPC escuchando: 44134
[principal] 2017/12/21 15:30:48 Sondas escuchando: 44135
[principal] 2017/12/21 15:30:48 El controlador de almacenamiento es ConfigMap
[principal] 2017/12/21 15:30:48 El historial máximo por lanzamiento es 0
[tiller] 2017/12/21 15:30:55 preparando actualización para xxx
[almacenamiento] 2017/12/21 15:30:55 obteniendo la versión implementada del historial "xxx"
[tiller] 2017/12/21 15:30:56 copiando valores de xxx (v65) a la nueva versión.
[almacenamiento] 2017/12/21 15:30:56 obteniendo la última revisión de "xxx"
[almacenamiento] 2017/12/21 15:30:56 obteniendo el historial de versiones de "xxx"
[tiller] 2017/12/21 15:30:59 renderizando el gráfico helm-xxx usando valores
2017/12/21 15:30:59 información: el manifiesto "helm-xxx / templates / Scheduler-deploy.yaml" está vacío. Salto a la comba.
2017/12/21 15:30:59 información: el manifiesto "helm-xxx / templates / recomposer-deploy.yaml" está vacío. Salto a la comba.
2017/12/21 15:31:00 información: el manifiesto "helm-xxx / templates / recomposer-pvc.yaml" está vacío. Salto a la comba.
2017/12/21 15:31:00 información: el manifiesto "helm-xxx / templates / planificador-pvc.yaml" está vacío. Salto a la comba.
2017/12/21 15:31:00 información: el manifiesto "helm-xxx / templates / Scheduler-secret.yaml" está vacío. Salto a la comba.
2017/12/21 15:31:00 información: el manifiesto "helm-xxx / templates / recomposer-secret.yaml" está vacío. Salto a la comba.
[tiller] 2017/12/21 15:31:09 creando una versión actualizada para xxx
[almacenamiento] 2017/12/21 15:31:09 creando la versión "xxx.v80"
[tiller] 2017/12/21 15:31:09 realizando una actualización para xxx
[tiller] 2017/12/21 15:31:09 ejecutando 0 ganchos previos a la actualización para xxx
[tiller] 2017/12/21 15:31:09 ganchos completos para pre-actualización xxx
[tiller] 2017/12/21 15:31:11 preparando actualización para xxx
[almacenamiento] 2017/12/21 15:31:11 obteniendo la versión implementada del historial "xxx"
[almacenamiento] 2017/12/21 15:31:11 obteniendo la última revisión de "xxx"
[almacenamiento] 2017/12/21 15:31:11 obteniendo el historial de versiones para "xxx"
[tiller] 2017/12/21 15:31:18 renderizando el gráfico helm-xxx usando valores
2017/12/21 15:31:18 información: el manifiesto "helm-xxx / templates / Scheduler-secret.yaml" está vacío. Salto a la comba.
2017/12/21 15:31:18 información: el manifiesto "helm-xxx / templates / planificador-pvc.yaml" está vacío. Salto a la comba.
2017/12/21 15:31:19 información: el manifiesto "helm-xxx / templates / Scheduler-deploy.yaml" está vacío. Salto a la comba.
[kube] 2017/12/21 15:31:28 creando recursos a partir del manifiesto actualizado
[tiller] 2017/12/21 15:31:46 creando una versión actualizada para xxx
[almacenamiento] 2017/12/21 15:31:46 creando la versión "xxx.v81"
[tiller] 2017/12/21 15:31:47 realizando una actualización para xxx
[tiller] 2017/12/21 15:31:47 ejecutando 0 ganchos previos a la actualización para xxx
[tiller] 2017/12/21 15:31:47 ganchos completos para pre-actualización xxx
[kube] 2017/12/21 15:31:49 comprobando 7 recursos para ver si hay cambios
[kube] 2017/12/21 15:31:49 Parece que no hay cambios para el secreto "xxx-helm-xxx-nginx-secret"
[kube] 2017/12/21 15:31:50 Parece que no hay cambios para el secreto "xxx-application-secret"
[kube] 2017/12/21 15:31:50 Parece que no hay cambios para Secret "azure-secret"
[kube] 2017/12/21 15:31:51 Parece que no hay cambios para ConfigMap "xxx-helm-xxx-nginx-config"
[kube] 2017/12/21 15:31:51 Parece que no hay cambios para ConfigMap "xxx-application-config"
[kube] 2017/12/21 15:31:51 Parece que no hay cambios para el servicio "xxx-application-svc"
[kube] 2017/12/21 15:31:51 Parece que no hay cambios para StatefulSet "xxx-application"
[tiller] 2017/12/21 15:31:51 ejecutando 0 ganchos posteriores a la actualización para xxx
[tiller] 2017/12/21 15:31:51 ganchos completos para post-actualización xxx
[almacenamiento] 2017/12/21 15:31:51 actualización de la versión "xxx.v65"
[tiller] 2017/12/21 15:31:51 estado de actualización de la versión actualizada para xxx
[almacenamiento] 2017/12/21 15:31:51 actualización de la versión "xxx.v80"
[kube] 2017/12/21 15:31:57 creando recursos a partir del manifiesto actualizado
[kube] 2017/12/21 15:32:10 comprobando 11 recursos para ver si hay cambios
[kube] 2017/12/21 15:32:10 Parece que no hay cambios para el secreto "xxx-helm-xxx-nginx-secret"
[tiller] 2017/12/21 15:32:10 advertencia: No se pudo actualizar "xxx": no se encontró ningún recurso con el nombre "xxx-recomposer-secret"
[almacenamiento] 2017/12/21 15:32:10 actualización de la versión "xxx.v65"
[almacenamiento] 2017/12/21 15:32:10 actualización de la versión "xxx.v81"

parece confundirse al hacer para liberar al mismo tiempo ...

simplemente volví a aplicar la misma configuración dos veces ...

[tiller] 2017/12/21 15:50:46 preparando actualización para xxx
[almacenamiento] 2017/12/21 15:50:46 obteniendo la versión implementada del historial "xxx"
[almacenamiento] 2017/12/21 15:50:46 obteniendo la última revisión de "xxx"
[almacenamiento] 2017/12/21 15:50:46 obteniendo el historial de versiones para "xxx"
[tiller] 2017/12/21 15:50:50 renderizando el gráfico helm-xxx usando valores
2017/12/21 15:50:50 información: el manifiesto "helm-xxx / templates / planificador-pvc.yaml" está vacío. Salto a la comba.
2017/12/21 15:50:50 información: el manifiesto "helm-xxx / templates / recomposer-deploy.yaml" está vacío. Salto a la comba.
2017/12/21 15:50:50 información: el manifiesto "helm-xxx / templates / Scheduler-secret.yaml" está vacío. Salto a la comba.
2017/12/21 15:50:50 información: el manifiesto "helm-xxx / templates / Scheduler-deploy.yaml" está vacío. Salto a la comba.
2017/12/21 15:50:50 información: el manifiesto "helm-xxx / templates / recomposer-secret.yaml" está vacío. Salto a la comba.
2017/12/21 15:50:50 información: el manifiesto "helm-xxx / templates / recomposer-pvc.yaml" está vacío. Salto a la comba.
[tiller] 2017/12/21 15:50:58 creando una versión actualizada para xxx
[almacenamiento] 2017/12/21 15:50:58 creando la versión "xxx.v85"
[tiller] 2017/12/21 15:50:59 realizando una actualización para xxx
[tiller] 2017/12/21 15:50:59 ejecutando 0 ganchos previos a la actualización para xxx
[tiller] 2017/12/21 15:50:59 ganchos completos para pre-actualización xxx
[kube] 2017/12/21 15:51:13 recursos de creación a partir del manifiesto actualizado
[kube] 2017/12/21 15:51:22 comprobando 7 recursos para ver si hay cambios
[kube] 2017/12/21 15:51:22 Parece que no hay cambios para el secreto "xxx-helm-xxx-nginx-secret"
[kube] 2017/12/21 15:51:23 Parece que no hay cambios para el secreto "xxx-application-secret"
[kube] 2017/12/21 15:51:23 Parece que no hay cambios para Secret "azure-secret"
[kube] 2017/12/21 15:51:23 Parece que no hay cambios para ConfigMap "xxx-helm-xxx-nginx-config"
[kube] 2017/12/21 15:51:23 Parece que no hay cambios para ConfigMap "xxx-application-config"
[kube] 2017/12/21 15:51:24 Parece que no hay cambios para el servicio "xxx-application-svc"
[kube] 2017/12/21 15:51:24 Eliminando "xxx-recomposer-secret" en xxx ...
[kube] 2017/12/21 15:51:24 No se pudo eliminar "xxx-recomposer-secret", err: no se encontraron los secretos "xxx-recomposer-secret"
[kube] 2017/12/21 15:51:24 Eliminando "xxx-recomposer-config" en xxx ...
[kube] 2017/12/21 15:51:24 Error al eliminar "xxx-recomposer-config", err: configmaps "xxx-recomposer-config" no encontrado
[kube] 2017/12/21 15:51:24 Eliminando "xxx-recomposer-pv" en ...
[kube] 2017/12/21 15:51:24 Error al eliminar "xxx-recomposer-pv", err: persistentvolumes "xxx-recomposer-pv" no encontrado
[kube] 2017/12/21 15:51:24 Eliminando "xxx-recomposer-pvc" en xxx ...
[kube] 2017/12/21 15:51:24 Error al eliminar "xxx-recomposer-pvc", err: persistentvolumeclaims "xxx-recomposer-pvc" no encontrado
[kube] 2017/12/21 15:51:24 Eliminando "xxx-recomposer" en xxx ...
[kube] 2017/12/21 15:51:24 Uso de reaper para eliminar "xxx-recomposer"
[kube] 2017/12/21 15:51:24 Error al eliminar "xxx-recomposer", err: deployments.extensions "xxx-recomposer" no encontrado
[tiller] 2017/12/21 15:51:24 ejecutando 0 ganchos posteriores a la actualización para xxx
[tiller] 2017/12/21 15:51:24 ganchos completos para post-actualización xxx
[almacenamiento] 2017/12/21 15:51:24 actualización de la versión "xxx.v68"
[tiller] 2017/12/21 15:51:24 estado de actualización de la versión actualizada para xxx
[almacenamiento] 2017/12/21 15:51:24 actualización de la versión "xxx.v85"
[almacenamiento] 2017/12/21 15:51:25 obteniendo la última revisión de "xxx"
[almacenamiento] 2017/12/21 15:51:25 obteniendo el historial de versiones de "xxx"
[kube] 2017/12/21 15:51:38 Haciendo get para Secret: "xxx-helm-xxx-nginx-secret"
[kube] 2017/12/21 15:51:39 obtener vaina de relación del objeto: xxx / Secret / xxx-helm-xxx-nginx-secret
[kube] 2017/12/21 15:51:39 Haciendo get para Secret: "xxx-application-secret"
[kube] 2017/12/21 15:51:39 obtener vaina de relación del objeto: xxx / Secret / xxx-application-secret
[kube] 2017/12/21 15:51:39 Haciendo get para Secret: "azure-secret"
[kube] 2017/12/21 15:51:39 obtener vaina de relación del objeto: xxx / Secret / azure-secret
[kube] 2017/12/21 15:51:39 Haciendo get para ConfigMap: "xxx-helm-xxx-nginx-config"
[kube] 2017/12/21 15:51:39 obtener pod de relación del objeto: xxx / ConfigMap / xxx-helm-xxx-nginx-config
[kube] 2017/12/21 15:51:39 Haciendo get para ConfigMap: "xxx-application-config"
[kube] 2017/12/21 15:51:39 obtener el pod de relación del objeto: xxx / ConfigMap / xxx-application-config
[kube] 2017/12/21 15:51:39 Haciendo get for Service: "xxx-application-svc"
[kube] 2017/12/21 15:51:39 obtener vaina de relación del objeto: xxx / Service / xxx-application-svc
[kube] 2017/12/21 15:51:39 Haciendo get para StatefulSet: "xxx-application"
[kube] 2017/12/21 15:51:39 obtener pod de relación del objeto: xxx / StatefulSet / xxx-application

podría estar relacionado con # 2941

Dicho en el otro hilo, una de las formas de solucionar el problema era eliminar los mapas de configuración con errores ... parece que lo hago por mí actualmente ...

Todo eso está muy bien. Hasta ese momento, cuando tenga que eliminar algo fundamental de un espacio de nombres de producción. Lo cual, casualmente, me pasó hace un momento. :C

También me he enfrentado al problema cuando actualizamos una versión si hay varios estados DEPLOYED de esta versión, tengo que solucionarlo eliminando los mapas de configuración correspondientes.

El mismo problema. Todo estuvo bien ayer e hice varias actualizaciones. Hoy acabo de agregar un nuevo yaml con los bloques service y deployment separados por --- y la actualización falló.

Lo interesante es que helm creó el service y luego se quejó (y no hizo la implementación).
Comenté el service y simplemente ejecuté la actualización con el bloque deployment - funcionó. Sin embargo, helm no eliminó el servicio, que debería tener ya que se eliminó del archivo yaml.

Actualización : eliminé manualmente el service , lo descomenté del yaml y ejecuté la actualización, ¡esta vez funcionó a las mil maravillas!

Estaba teniendo este error exacto. Parece que el problema está relacionado con plantillas con múltiples objetos API similares a lo que vio @amritb . En mi caso, tenía una plantilla que tenía varios objetos API que podían activarse y desactivarse de forma similar a:

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

Romper eso en su propio archivo de plantilla y limpiar los objetos huérfanos que Helm creó y se olvidó resolvió el problema para mí. Parece que hay un error en la forma en que helm obtiene la configuración anterior si el número de objetos por plantilla cambia entre lanzamientos.

Agregar otro punto de datos: parece que tengo exactamente el mismo problema que @awwithro. Estamos usando un bucle jinja para crear múltiples cronjobs a través de una plantilla, y cuando una nueva actualización hizo que este bucle completara un cronjob adicional, encontramos el error. Parecía disparar # 2941 también (o posiblemente un error causa el otro), y borrar los configmaps zombies lo corrige.

Simplemente atrapado en esto incluso sin usar ningún mapa de configuración

Un poco de color extra para cualquiera que pueda estar atascado:
Me estaba encontrando con esto al introducir nuevos subgráficos y objetos en mi lanzamiento. Pude resolverlo verificando cada tipo de objeto que se estaba agregando y eliminando cualquier objeto existente que causaría una colisión de nombres.

Esto parece estar en línea con la evidencia de otros de que la eliminación es la única forma de resolverlo en este momento 😕

También corriendo a través de esto = \

También necesitaba eliminar los recursos afectados. No es bueno para un entorno de producción = _ (

Estoy viendo algo que creo que es similar. El problema parece ser que un helm upgrade no reutiliza los valores de la implementación anterior. Si especifico el mismo conjunto de valores en la línea de comandos que hizo la instalación inicial, entonces helm upgrade funciona. No sé si esto ayuda (o alguien más puede confirmarlo).

Al igual que @amritb , después de que

El mismo problema al usar helm 2.8.0 . Versiones de Kubernetes client=v1.8.6 y 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

Pero el mapa de configuración existe en $ kubectl get configmap . Si elimino manualmente el mapa de configuración, funciona, pero la próxima vez volverá a fallar.

Aquí está el mapa de configuración:

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

Eliminé la versión y la volví a instalar. Además, estaba usando la versión de API extensions/v1beta para la implementación, cambié a apiVersion: apps/v1beta2 , no sé si esto ayudó o no.
También actualmente estoy ejecutando tiller localmente.

Ahora mismo parece que todo está funcionando.

Esto es realmente fácil de reproducir, sucede si hay un error en el manifiesto.

Como tenemos resource1 y resource2, resource2 depende primero. Cuando actualizamos la versión, se crea el recurso1 (por ejemplo, PV y PVC), pero el recurso2 falla. Después de esto, solo ayuda la eliminación de resource1, ya que helm siempre informa un problema en la actualización (PersistentVolume con nombre ... no encontrado)

Tuvimos el mismo problema (el recurso que nos consiguió fue Secretos). Eliminar los nuevos secretos y volver a implementarlo lo solucionó.

Tenga en cuenta que debido a las fallas, ahora tenemos 11 lanzamientos diferentes cuando hacemos helm list , 10 FAILED y 1 DEPLOYED. Eso no se espera, ¿verdad? El mismo problema que aquí parece: https://github.com/kubernetes/helm/issues/2941

Esto prácticamente ha hecho que helm sea inutilizable para implementaciones de producción regulares para nosotros :( Actualmente estamos investigando cosas como pasar --dry-run a helm y canalizarlo a kubectl apply ... Dado que esto parece afectar solo a un subconjunto de usuarios , no estoy seguro de qué es lo que estamos haciendo mal :(

Después de seguir los registros del timón, descubrí que el timón estaba intentando actualizar una versión anterior al mismo tiempo:

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

Eliminar el mapa de configuración anterior para s2osf.v10 y luego actualizar funcionó.

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

Tener el mismo problema que @binoculars :

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

Causando problemas extraños con UPGRADE FAILED: no Secret with the name "foobar" found .
Incluso intenté eliminar este secreto que luego causó errores en algún mapa de configuración, y en la tercera ejecución, una vez más me quejé del secreto anterior.

Esto podría haberse activado después de actualizar de helm 2.7.xa 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 su último recurso es eliminar la versión anterior, podría haber una solución menos destructiva como mi comentario https://github.com/kubernetes/helm/issues/3513#issuecomment -366918019

básicamente, encontrar esa revisión anterior en los registros y editar el mapa de configuración manualmente donde tiller almacena el estado implementado. No debería haber dos revisiones con estado DEPLOYED afaik.

Encontré una nueva solución a este problema.

kubectl -n kube-system edit cm name_of_your_release.v2 , donde v2 es el último número de revisión marcado como FALLIDO en helm list . Es posible que también desee editar una de las versiones DESPLEGADAS y cambiar el estado a SUPERSEDED, de modo que no tengamos dos versiones implementadas al mismo tiempo.

@zuzzas esto es a lo que me

@balboah, el problema es que solo tenemos una implementación en estado DEPLOYED, pero si no es de las más recientes (que están marcadas como FAILED, en la mayoría de los escenarios), aún fallará. El problema parece no estar relacionado con tener dos o más implementaciones en estado DEPLOYED en la mayoría de nuestros casos.

@zuzzas , ¿tienes muchos lanzamientos en el mismo espacio de nombres o solo uno? Una vez, tuve un problema con dos versiones que actualizaban los mismos objetos, luego entrarán en conflicto entre sí.

Si es solo una, ¿cuántas fallas tiene hasta la versión implementada? ¿Cómo verificaste que es el único desplegado?

Creemos que esto se ha solucionado (en el futuro) a través de # 3539. Vuelva a abrir si nos equivocamos. :)

¡Gracias a todos por su trabajo en esto!

Tenga en cuenta que esto no se ha corregido para los gráficos existentes en este estado; aún deberá eliminar las versiones anteriores que están en estado DEPLOYED para que las cosas vuelvan a funcionar. @balboah acaba de evitar el caso en el que puede entrar en el estado de "múltiples lanzamientos marcados como DESPLEGADOS". :)

Hm, sigo teniendo este problema en Helm 2.8.2 (no es el último, pero probé con 2.9.0 y me da el mismo error). Por lo general, eliminar el recurso ofensivo manualmente puede solucionarlo, aunque a menudo se produce en cascada en múltiples recursos que todos necesitan ser eliminados antes de que se actualice con éxito.

Tengo un gráfico de timón un poco grande con dependencias anidadas; ¿Podría ser eso?

Veo el mismo problema con la vinculación de roles de clúster. Agregué el nuevo recurso a mi gráfico y upgrade y upgrade --install fallarían con Error: UPGRADE FAILED: no ClusterRoleBinding with the name "test-clusterrolebinding" found

Estoy experimentando el mismo problema que @ramyala con ClusterRole. ClusterRole existe, pero la creación de RoleBinding falla con ese error.

En Helm 2.9.1 he encontrado el mismo problema:

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

Mientras veo este ConfigMap en mi clúster.

Experimento este problema si tengo varios recursos con ganchos en un archivo

+1, esto está sucediendo nuevamente con 2.9.1. Vuelva a abrir.

Volver a etiquetar esto como un error. No estamos seguros de qué causó esta regresión, pero si alguien puede proporcionar pasos sobre cómo reproducir este error en 2.9.1, sería muy apreciado.

@bacongobbler

También veo esto cuando intento implementar un nuevo Ingress en mi gráfico de timón. Admito que soy nuevo en Ingress, pero parece que es correcto según todos los ejemplos y he estado haciendo otras cosas de helm / k8s durante un par de meses.

Ya implementé el gráfico de timón stable/nginx-ingress para que el controlador esté presente. El error parece sugerir que está intentando encontrar el que estoy intentando crear. Aquí está el comando que estoy ejecutando:

helm upgrade some-existing-release-name -i --set imageTag=$TAG-$BUILD_NUMBER --namespace=default ./deploy/helm donde deploy/helm contiene mis manifiestos de gráfico.

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

ACTUALIZAR
Eliminé /* de mis dos rutas y ya no dio un error al intentar actualizar / instalar. Tal vez esa no sea una sintaxis válida

Hola,
Estos son los pasos que introdujeron el problema en mi entorno:

1. Hice desplegar y actualizar un gráfico de timón varias veces.
2. Se creó un nuevo objeto CronJob en el gráfico y se actualizó nuevamente: el trabajo cron se creó correctamente.
3. Todas las próximas actualizaciones fallan con el error informado "Error: ACTUALIZACIÓN FALLIDA: no se encontró ningún CronJob con el nombre" cronjob-name "

También veo el problema cuando agrego un secreto que no existía antes. Intenté agregar "db-credentials"
secreto que condujo a:

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

corrección potencialmente relevante: # 4146

Si alguien que se encuentra con este error puede probar ese PR y ver si lo soluciona, entonces podríamos confirmar que es probable que se trate de una regresión en la API de k8s y avanzar con esa solución. ¡Gracias!

No puedo confirmar al 100% si esto siempre se reproducirá, pero he notado que esto tiende a suceder en la siguiente situación:

1. Actualizo un gráfico de Helm, incluido un nuevo recurso
2. Esa actualización falla, pero el recurso se creó como parte de la actualización fallida.
3. Todas las actualizaciones posteriores fallan

Si hago un helm rollback en la última implementación exitosa y luego intento volver a actualizar, parece que funciona.

Parece muy fácil reproducirlo manualmente, sin intentar actualizar intencionalmente un gráfico con cambios dañinos (por ejemplo, modificar un objeto de trabajo inmutable):

1. Tome un gráfico e impleméntelo (pero omita un recurso, digamos un Servicio)
2. Agrega el recurso omitido manualmente (por ejemplo, con "kubectl create"), pero con el nombre correspondiente a la versión.
3. Vuelva a agregar el recurso omitido al gráfico y luego intente actualizarlo, el timón debería informar "ACTUALIZACIÓN FALLIDA: nocon el nombreencontró"

Los pasos son diferentes, pero la causa principal parece ser la misma. Corríjame si me equivoco en la suposición, pero me parece que la revisión de la última versión DESPLEGADA no tiene información sobre el recurso en particular, ya sea porque se agregó "fuera" de Helm (manualmente, por ejemplo) o porque la última actualización falló en algún paso (digamos en la actualización de un Trabajo inmutable), al mismo tiempo desplegando otros objetos y luego registrándolos en la revisión FAILED (pero aún sin ningún rastro en la revisión DEPLOYED de lo que se espera, de lo contrario significaría cambiar el historial) . En la próxima ejecución, el cliente kube de Tiller ve los recursos en el clúster, lo que significa que ya deberían estar implementados y, por lo tanto, registrados, verifica la última revisión DESPLEGADA (parece que no se contacta con la revisión FALLIDA) y no los ve en la lista allí por lo que informa de error.

@bacongobbler Probé # 4146 con una imagen de timón personalizada y ¡solucionó este problema! Para otros que buscan una solución, puede aplicar el parche en el problema en el maestro actual y compilar:

make bootstrap build docker-build

Tendrá que cargar la imagen del timón en su repositorio y reinstalar el timón en su clúster. Pude salirme con un reinicio forzado y reinstalar sin destruir las versiones actuales.

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

¡Gracias @ramyala por probar la solución! Lo mencionaré en la llamada de desarrollo mañana y veré si alguno de los otros mantenedores centrales ve algún caso de borde que pueda surgir con el parche. Si no, fusionémonos.

Entonces encontré algunos errores con # 4146 que lo convierten en un PR indeseable para seguir adelante. Informé mis hallazgos entre el maestro, # 4146 y # 4223 aquí: https://github.com/kubernetes/helm/pull/4223#issuecomment -397413568

@adamreese y yo revisamos los diferentes escenarios y casos

Ah, y algo que no mencioné: debido a que el clúster está en un estado inconsistente, esto se puede solucionar fácilmente interviniendo manualmente y eliminando el recurso que el error informa como "no encontrado". Siguiendo el ejemplo que demostré en 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

Con el fin de mantener las cosas juntas, cerraré esto como un duplicado del # 1193 ya que los dos tickets son idénticos. Informe cualquier hallazgo allí para que todos podamos trabajar con un solo boleto. ¡Gracias!

Advertencia: esta información es un poco incompleta y no puedo encontrarle sentido, pero en caso de que sea útil para alguien, solucioné este problema cambiando mi selector de servicio de:

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

a

selector:
    app: mything

¿Quizás hay algún tipo de problema con el uso de una variable en este contexto?

Prueba helm delete RELEASE_NAME --purge
e instálelo de nuevo.

También estoy abordando este problema. Intenté agregar un subgráfico con una implementación en mi gráfico, tuvo éxito cuando se actualizó con helm upgrade chart chart-1.0.1.tgz solo por primera vez, después de eso, cuando probé helm upgrade chart chart-1.0.1.tgz falló con el error 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"}

Los registros del timón del timón simplemente registran el mismo error. ¿Alguien está experimentando esto también?

El mismo problema. Todo estuvo bien ayer e hice varias actualizaciones. Hoy acabo de agregar un nuevo yaml con los bloques service y deployment separados por --- y la actualización falló.

Lo interesante es que helm creó el service y luego se quejó (y no hizo la implementación).
Comenté el service y simplemente ejecuté la actualización con el bloque deployment - funcionó. Sin embargo, helm no eliminó el servicio, que debería tener ya que se eliminó del archivo yaml.

Actualización : eliminé manualmente el service , lo descomenté del yaml y ejecuté la actualización, ¡esta vez funcionó a las mil maravillas!

hola, yo también tengo este problema, y ​​no puedo resolverlo, ¿me gustaría darme algunas indicaciones?

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

Solo confirmo que estoy presenciando el mismo problema y la causa también es como se indicó anteriormente.

Se agregó un nuevo secreto, se hizo referencia a él en un volumen (sintaxis no válida). La actualización falló, las actualizaciones posteriores fallaron con el error anterior.

La lista de secretos mostró que se había creado. Secreto eliminado manualmente y la actualización se realizó correctamente.

Lo mismo, @thedumbtechguy. Me encuentro con este problema de forma rutinaria. Es especialmente divertido cuando Helm decide que necesitas eliminar _todos_ tus secretos, mapas de configuración, roles, etc. La actualización se convierte en un juego de wack-a-mole con una lista cada vez mayor de argumentos a kubectl delete . Debería haber tirado la toalla en esta tarea de sísifo hace meses, pero ahora es demasiado tarde para eso. ¡Espero que esto y las docenas de problemas similares se puedan solucionar!

He estado usando Helm durante una semana y ya me enfrenté a todo lo descrito.
aquí https://medium.com/@7mind_dev/the -problems-with-helm-72a48c50cb45

Hay mucho que arreglar aquí.

El viernes 15 de marzo de 2019 a las 10:49 p.m., Tom Davis [email protected] escribió:

Lo mismo, @thedumbtechguy https://github.com/thedumbtechguy . Me encuentro con
este problema de forma rutinaria. Es especialmente divertido cuando Helm decide que necesitas
eliminar todos sus secretos, mapas de configuración, roles, etc. La actualización se convierte en una
juego de wack-a-mole con una lista cada vez mayor de argumentos para kubectl
Eliminar. Debería haber tirado la toalla en esta tarea de sísifo durante meses.
hace, pero ya es demasiado tarde para eso. Seguro espero que esto y las docenas de
¡Se pueden solucionar problemas similares!

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/helm/helm/issues/3275#issuecomment-473464809 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AA4XZU4KMQePtZKcir8S5kWulkbYg-8Uks5vXCNggaJpZM4RGz7W
.

Experimenté lo mismo con Helm v2.10. Ya tenía un gráfico implementado, agregué otro configMap al gráfico. Informó que la implementación falló porque no pudo encontrar configMap "bla". yo hice

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

Para verificar que configMap efectivamente se estaba renderizando, lo fue. Comprobé configMaps en el clúster y lo encontré allí. Eliminó el blah configMap, volvió a ejecutar la actualización, funcionó.

https://github.com/helm/helm/pull/5460 debería aclarar mejor el mensaje de error en el futuro.

Punto justo.

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

Sigan con el buen trabajo del equipo de timón.

En caso de que esto sea un gran problema para alguien más, pensé en señalar que https://github.com/helm/helm/pull/4871 debería solucionar estos problemas.

Tenga en cuenta que parece que aún no ha sido aprobado por el equipo de Helm. Además, hubo algunas preocupaciones sobre los recursos de eliminación automática. Solo menciono en caso de que alguien quiera construirlo desde la fuente y probarlo.

Tener el mismo problema y la única solución parece ser helm delete --purge release e instalar de nuevo!

Me encontré con el mismo problema. @fbcbarbosa parece que se fusionó hace 2 semanas. Con suerte, debería ser parte de la próxima versión 2.14.0 .

Tener el mismo problema y la única solución parece ser helm delete --purge release e instalar de nuevo!

Una opción menos destructiva es hacer un helm rollback a la versión / current / (es decir, en 0 pasos). No puedo garantizar el éxito, pero para nosotros, hasta ahora, siempre ha sido un éxito.

¿Hay alguna idea de si esto va a estar en la próxima versión y si lo hará cuando salga?

5460 se fusionó hace 2 meses, lo que significa que debería estar en el timón 2.14.0.

Arreglé el problema por

1. eliminar aquellos recursos que se quejaron por "actualización de timón". (Dice No encontrado pero en realidad se puede encontrar). No elimine la versión completa, de lo contrario, si está en producción, se arruinará por completo.
2. rehacer la actualización del timón. Ahora, esta vez debería aparecer "Happy Helming". :)

Nos encontramos con este problema en PROD, cuando un requisito a nuestro gráfico de timón paraguas agregó un mapa de configuración basado en un condicional. Para nosotros, la solución alternativa era

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

Para nosotros, una simple reversión a la revisión actual siempre ha funcionado:

helm ls
helm rollback <NAME> <current REVISION>

@tobypeschel , ¿tienes idea de cómo funciona tu solución?