Helm: ACTUALIZACIÓN FALLIDA: no se encontró ningún recurso con el nombre ""

Me encuentro con un problema similar en el que tengo un gráfico con dependencias agrupadas. Si agrego una nueva dependencia y ejecuto un helm upgrade el resultado es el mismo que el descrito. Los recursos se crearon correctamente, sin embargo, helm devuelve un error.

Entonces, si esto está instalado: helm install -n my-release

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

Y luego se agrega un nuevo gráfico como dependencia:

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

Cuando la versión se actualiza con: helm upgrade my-release my-thing helm produce el siguiente error:

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

@devth No puedo reproducir este problema en master. ¿Sigues viendo este problema? ¿Qué versión de timón / timón está ejecutando?

¡Gracias!

@elementalvoid Tampoco pude reproducir el nuevo error de dependencia en el maestro. ¿Sigues viendo este problema? ¿Qué versión de timón / timón está ejecutando?

Gracias.

En ese momento estaba en alpha 4. Usando alpha 5 y el ejemplo de @devth tampoco pude reproducir el problema.

Bien. Cerraré esto por ahora. No dude en presentar un problema si vuelve a ver alguno de estos problemas.

Gracias de nuevo.

@michelleN gracias! Lamento no haber tenido tiempo esta semana para intentar una reproducción en el maestro. ¡Esperamos actualizar pronto!

Lo mismo para mí cuando muevo una especificación de Volumen / Implementación de hostPath a PVC.
El error parece ser cuando un manifiesto de actualización depende de uno nuevo (¿"falta" en el antiguo?)
versión: 2.7.2

Extraño, estoy viendo el mismo comportamiento al intentar actualizar un gráfico en la versión 2.7.2 con un nuevo rol. Tiller se queja de que no puede encontrar el rol y falla en las implementaciones, a pesar de que realmente creó el rol.

Mi situación era que tenía un nuevo recurso y desplegué la nueva versión del gráfico de timón con el nuevo recurso. Ese despliegue falló porque me puse los dedos gordos con algunos yaml. Bueno, los nuevos objetos se crearon en kubernetes. Arreglé el yaml y volví a ejecutar la actualización en mi gráfico, y listo, aparece el mensaje de error de que no se encuentra el recurso. Tuve que ir a kubernetes y eliminar los nuevos recursos (en mi caso, un rol y un enlace de rol) que fueron creados por la implementación fallida. Después de eso, la verificación del timón para ver si el objeto actual existe falla (https://github.com/kubernetes/helm/blob/7432bdd716c4bc34ad95a85a761c7cee50a74ca3/pkg/kube/client.go#L257) no se realizará correctamente y se crearán los recursos de nuevo. Parece un error, ¿dónde tal vez deberían tenerse en cuenta los nuevos recursos para un gráfico fallido?

Obteniendo un error similar al actualizar:

$ 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

Se crea el mapa de configuración

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

Mi mapa de configuración:

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

Tenemos el mismo problema.

Eliminé toda la versión y luego la instalé de nuevo. Actualmente parece estar funcionando.

$ helm del --purge bunny

También estoy teniendo este problema en

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

Esto sucede con frecuencia con nuestro uso de helm y requiere un --purge completo. Eso no es una solución.

No es aplicable si usa CI / CD.
¿Qué sucede si una actualización falla y usa la estrategia de actualización continua? ¿Debo eliminar mi versión que aún funciona?

También veo el mismo problema cuando hay un problema de implementación o similar, pero se creó el / cm secreto, pero luego Helm lo pierde de vista y se niega a permitirle hacer mucho.

Lo he visto, aunque rara vez, incluso en un lanzamiento no roto (es decir, se ve que ha pasado) pero aún tengo que descubrir qué podría causar eso.

También podemos reproducir este problema (servidor v2.8.2) al agregar recursos a las implementaciones de helm existentes. Tener que eliminar la implementación y volver a implementar cada vez que se debe agregar un nuevo recurso será un gran problema en la producción.

En nuestro caso, estábamos agregando un mapa de configuración a un gráfico y el gráfico no se actualiza con:

Error: ACTUALIZACIÓN FALLIDA: no hay recurso con el nombre "" encontró

Nota: estamos usando 2.7.2;

Creo que esto sucede porque cuando timón es determinar qué ha cambiado busca el nuevo recurso configMap en la vieja versión, y no puede encontrarla. Consulte https://github.com/kubernetes/helm/blob/master/pkg/kube/client.go#L276 -L280 para ver el código de donde proviene este error.

Registros de Tiller para la actualización fallida:

[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" 

Este problema también surge cuando se cambia la etiqueta name de un Servicio implementado, quizás también otras cosas.

Estoy cambiando el nombre de un servicio en una versión y no se actualiza con:

Error: ACTUALIZACIÓN FALLIDA: no se encontró ningún servicio con el nombre "new-service-name"

Estaría dispuesto a crear un PR para corregir este comportamiento, pero me gustaría saber cuál es la forma prevista o sugerida de manejar esto. Incluso una bandera CLI que permita que --force tenga prioridad sería genial.

Acuerde la importancia.

Este problema puede ser extraño cuando no puede simplemente eliminar una implementación.

Descubrí que nuestro problema se debía a una implementación fallida.

Helm no intenta limpiar después de una implementación fallida, lo que significa que se crean cosas como el nuevo ConfigMap que agregué anteriormente, pero sin una referencia en la implementación 'anterior'. Eso significa que cuando ocurre la siguiente implementación, helm encuentra el recurso en k8s y espera que se haga referencia a él en la última revisión implementada (o algo así; no estoy seguro de qué lógica exacta usa para encontrar la versión 'anterior') para verificar qué cambios que hay. No está en esa versión, por lo que no puede encontrar el recurso y falla.

Esto es principalmente un problema cuando se desarrolla un gráfico, ya que una implementación fallida pone k8s en un estado que el timón no rastrea correctamente. Cuando me di cuenta de que esto era lo que estaba sucediendo, supe que solo necesitaba eliminar el ConfigMap de k8s e intentar la implementación nuevamente.

@krishicks Sí, esta es una forma de reproducirlo. Una implementación fallida + un recurso nunca creado (es decir, un mapa de configuración no válido) también puede causar esto, también lo he notado, lo que luego conduce a un estado irrecuperable

También estamos alcanzando este. Es el mismo problema que mencionan @krishicks y @jaredallard :

1. Tenemos una implementación fallida:
   UPGRADE FAILED: the server was unable to return a response in the time allotted, but may still be processing the request (get configmaps)
2. Cualquier cambio posterior, también en otras versiones, fallará con una advertencia como
   Error: UPGRADE FAILED: no Service with the name "…" found

Intentaré usar la helm upgrade --timeout … para mitigar el primer problema, pero una implementación fallida que bloquea todo es un problema para nosotros. Además, el uso de helm rollback … no resolvió esto.

Como helm upgrade … ejecuta automáticamente en nuestro caso de uso, una bandera --auto-rollback para helm upgrade sería muy útil, que revierte los cambios fallidos.

Esto me está sucediendo con la v2.7.2 al agregar nuevos recursos al gráfico.
¿Hay alguna estimación sobre cuándo se solucionará esto?

Esto debería arreglarse con # 4146.

EDITAR: ver más abajo

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

@bacongobbler Eso no siempre funciona. Hemos tenido situaciones en las que eliminarlo funciona y algunas en las que aún no funciona después de hacerlo.

esto se puede solucionar fácilmente interviniendo manualmente y eliminando el recurso

@bacongobbler Por favor, comprenda que este recurso podría ser un objeto Servicio o Implementación de un espacio de nombres de producción, que podría (y ya lo hizo) interrumpir en gran medida nuestras garantías de servicio.

Sí, lo sé. Solo estoy explicando y observando el comportamiento del error para que otros sepan lo que está involucrado. :)

Simplemente encuentre este problema dos veces en diferentes clústeres. Cada vez con configmaps. Eliminar los recursos no resolvió el problema, por lo que tuvimos que eliminar la versión completa.

Aquí igual. No solo Configmaps, tengo uno con ServiceAccount.

PVC aquí. :)

Básicamente, todo tipo de objeto priorizado está sujeto a este error.

¿Hay alguien asignado para arreglar esto? ¿Existe ya un PR para esto? ¿Puedo ayudar con algo?

Este problema me ha mordido más de una vez, ya que es una situación en la que es fácil meterse, pero aparentemente no hay una manera fácil de salir de ella. Supongo que la parte "buena" en mi caso es que los recursos se actualizan incluso con el error en el lanzamiento (no estoy seguro si eso me hace feliz o preocupado)

Creo que helm debería prohibir al usuario entrar en este estado incorrecto o manejarlo correctamente.
¿Hay alguna solución real para esto fuera de eliminar todo (que solo es viable para usos que no sean de producción)?

Si alguien más puede determinar el otro caso límite en el que eliminar el recurso no resolvió el problema, sería muy útil para determinar la causa raíz para resolver ese problema en particular. Puede haber varias rutas que pueden terminar con el mismo error.

@Draiken no, hemos intentado varias soluciones al problema, y ​​ninguna parece razonable, ya que tampoco

a) no realice la actualización según lo previsto, o
b) introducir nuevos errores

Escribí sobre esas soluciones aquí y por qué no funcionarán. Si puede encontrar una solución alternativa, estaremos encantados de echarle un vistazo.

Tampoco podemos evitar que los usuarios entren en este estado incorrecto; hemos buscado soluciones, pero nuevamente todas presentan un conjunto diferente de problemas. Una vez que la instalación está en un estado inconsistente, es difícil "arreglarlo" sin una intervención manual. 😢

Una solución que funcionó para mí es hacer un helm rollback ... justo antes de que ocurriera la falla. Luego valido que el gráfico funciona en una nueva versión con helm install -n new-test-release . .

Una vez que todo funciona, limpio la versión de prueba y ejecuto helm upgrade ... con la versión anterior; y todo funcionó. Esta es una solución molesta, pero parece funcionar.

No sé si esto ayuda en absoluto, pero me encontré con este problema tanto en mis grupos de prueba como en los de producción.

Los cambios que hice en mis archivos de helm fueron bastante simples:
Tenía 1 implementación existente, con un servicio asociado y un presupuesto de interrupción de pod, que no se modificó.
Agregué una segunda implementación, con su propio servicio y poddisruptionbudget.
Incrementé el número de versión del gráfico.

Al ejecutar helm recibí este error la primera vez:

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`

Cuando vuelvo a ejecutar helm, aparece este error una y otra vez:

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

El gráfico de timón, por supuesto, funcionó en la prueba cuando eliminé todo y lo volví a implementar. Sin embargo, esa no es realmente una opción para prod.

@veqryn Me he encontrado con esto mucho, básicamente uso mi compilación en # 4146 cada vez que me encuentro con este problema y luego vuelvo a la línea principal. Funciona todo el tiempo. Sé que los mantenedores pueden no recomendarlo, pero _ funciona_, que es mejor que nada.

EDITAR : Si alguien está interesado en probarlo, puedo enviarlo a un repositorio de Docker público e incluir un fragmento rápido de cómo usarlo.

@jaredallard estamos interesados. ¡Gracias!

Sé que los mantenedores pueden no recomendarlo, pero funciona, lo cual es mejor que nada.

@jaredallard, no pudimos recomendar ese parche simplemente porque no funciona por sí solo (ref: https://github.com/helm/helm/pull/4223#issuecomment-397413568). Omite el error, pero no actualiza los recursos, por lo que el parche no hace lo que el usuario originalmente pretendía hacer. Soluciona un problema pero introduce otro sin solucionar el problema original que los usuarios pretenden realizar: actualizar un recurso.

Sin embargo, esto es intrigante:

Básicamente, uso mi compilación en # 4146 cada vez que me encuentro con este problema y luego vuelvo a la línea principal.

Si estoy leyendo esto bien, estás sugiriendo que has encontrado una solución que

a) evita el error
b) permite actualizar los recursos como se pretendía originalmente

haciendo 2 helm upgrade s: ¿uno con el parche y otro sin? Eso podría ayudarnos a identificar mejor la causa raíz y cómo solucionar este error.

@bacongobbler Tendría que revisar esto para verificar al 100% que ese es el comportamiento. Actualizaré este comentario o publicaré otro cuando lo haya hecho.

Sé que los mantenedores pueden no recomendarlo, pero funciona, lo cual es mejor que nada.

Además, para aclarar, ¡no estoy tratando de arrojar sombra allí! Está un poco mal redactado mirando hacia atrás ahora, lo siento

Todavía estoy confundido sobre por qué mi timón falló la primera vez para empezar.
No recibió el error no X with the name Y hasta la segunda vez que intenté aplicarlo.

@veqryn Escribí sobre cómo surge este problema en primer lugar en el problema que vinculé anteriormente. Por favor lea el comentario; feliz de ayudar a aclarar el problema con más detalle si no está claro.

Para los perezosos: https://github.com/helm/helm/pull/4223#issuecomment -397413568

De hecho, leí eso, y tengo entendido que el problema le sucedió porque cambió el nombre de su servicio.

Sin embargo, en ningún momento ninguno de mis servicios o recursos cambió de nombre.

Y después de volver a leer su comentario y hablar con mi equipo, descubrimos la causa de nuestro error:
Había chocado con la versión de Chart de mi timón.
Mis implementaciones y servicios hicieron referencia a esa versión del gráfico como una etiqueta.
A Kube / helm no le gusta cuando cambia su etiqueta, y esto es lo que causó el error original.

La solución (para mí) fue usar helm para volver a la última implementación exitosa, luego revertir el cambio de versión del gráfico para que la versión del gráfico permaneciera igual, lo que luego fue exitoso.

esta (fea) solución funciona para mí:

1. Obtengo un error:

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. buscar las últimas revisiones DESPLEGADAS

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. (Importante) Busque todos los recursos Los nuevos recursos existentes se agregaron desde la última implementación (v16) y elimínelos, por ejemplo
kubectl -nmonitor delete cm az-test-2-prom-prometheus-grafana-config
kubectl -nmonitor delect svc ...

Ejecute helm upgrade ... y vea Happy Helming

Como dijo @ kosta709 , volver a la última versión implementada, arreglar (manualmente) el gráfico o el estado actual (lo que sea que esté mal) y hacer una nueva actualización, generalmente funciona.

Helm es una gran pieza de software que se puede descartar en algunos flujos de trabajo automáticos (CI / CD) si el resultado de un comando no es estable.

¿Existe la opción de que las soluciones conocidas se implementen eventualmente en Helm para (intentar) resolver este problema bien conocido (y un poco molesto)? Gracias.

Por lo tanto, recientemente también estoy abordando esto a menudo, lo suficiente como para que pueda trabajar en este problema por mi cuenta. Para empezar, he creado una solución alternativa (
https://github.com/Nopik/helm/commit/afe6451cc2c6295e71ea2213ccce654ec3f5b686) que básicamente hace que Tiller obtenga un recurso existente como punto de partida en lugar de un recurso tomado del manifiesto anterior. Funciona como un encanto para mí, aunque creo que los desarrolladores principales no querrán fusionarlo, ya que contiene un comportamiento codificado.

Puede haber dos errores ocultos bajo el mismo comportamiento, ya que al menos una vez, cuando este error me atacó, tuve que eliminar muchos recursos (> 40), incluidos algunos que ya estaban presentes en> 20 versiones de lanzamiento exitosas. Pero en el 99% de los casos, basta con eliminar los recursos recién creados (y aún desconocidos para el timón).

Entonces, he estado pensando en cómo resolverlo de la manera adecuada. Lo estoy describiendo a continuación. Desarrolladores principales, corríjanme aquí y opinen si están de acuerdo conmigo. Si es así, estoy dispuesto a liderar este esfuerzo y proporcionar relaciones públicas para solucionarlo.

En general, helm parece funcionar en modo 'parche': si el usuario modifica el recurso de alguna manera y la nueva versión cambia algunos otros parámetros, helm calcula el parche entre 2 revisiones y lo aplica; creo que está tratando de mantener intactos los cambios del usuario.

Eso lamentablemente nos deja con un problema de fusión de 3 vías, ya que tenemos una versión de recurso tomada del manifiesto anterior, otra versión del nuevo manifiesto y otra versión del recurso activo actualmente. Y Helm aparentemente es malo para resolver conflictos, cuando surgen.

Creo que la forma correcta sería elegir mejores valores predeterminados (básicamente, fusionar mi rama será un largo camino) o proporcionar una bandera para el usuario. Por ejemplo, así:

• --ignore-old-manifest=never (predeterminado, comportamiento actual)
• --ignore-old-manifest=create-only (se aplica a este caso, cuando el manifiesto antiguo no tiene una noción del recurso, pero el recurso ya existe, podemos tomar esto como una nueva base y simplemente parchearlo, si es necesario) - recomendaría que sea nuevo defecto. Esto también permitiría a Helm comenzar a tomar posesión de los recursos creados manualmente.
• --ignore-old-manifest=always - solo para completar, probablemente no sea estrictamente necesario. Siempre crearía un parche entre el recurso actual y el manifiesto más reciente, básicamente eliminando todas las modificaciones del usuario.

Por supuesto, puede cambiar el nombre de la bandera para usar la lógica inversa: --use-current-resources=never(currently default)/create-only/always o algo así.

Más adelante, esta bandera podría tomarse de las anotaciones de recursos, algo como:

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

qué timón podría reconocer y aplicar esta estrategia por recurso. Sin embargo, no estoy seguro de si los desarrolladores de Helm quieren ir allí;)

Entonces, ¿qué opinas de esta propuesta?

Consulte también el número 3805 donde los desarrolladores de Helm están considerando un parche de fusión de 3 vías.

El mismo problema aquí.
Intentando configurar un entorno de CD / CI con Google Cloud Build.
Error: UPGRADE FAILED: no Deployment with the name "baobab-sidekiq" found

Lo curioso es que el despliegue 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

Este es el primer gráfico que creo y esperaba que helm fuera la solución para manejar la complejidad de implementar aplicaciones complejas en un entorno CI / CD.

¿La intención de Helm es poder trabajar en una tubería de CI / CD?

Gracias

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

También me encuentro con esto, tratando de actualizar helm 0.8.0 a 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"}

También me he encontrado con esto al actualizar los requisitos de un gráfico. Veo que Istio también se está encontrando con este error, su documento de instalación usa helm template . ¿Es esa una solución para este problema?

Consulte las discusiones recientes en https://github.com/helm/helm/issues/3805

teniendo esto también, todavía sucede para el último timón 2.10

Es hora de que este problema se considere seriamente, han pasado 2 años y muchas personas informan exactamente los mismos problemas, lo que hace que el timón sea bastante inutilizable en producción, y es un verdadero dolor cuando su implementación depende del timón.

Con muchas estrellas de GitHub vienen grandes responsabilidades

@ brendan-rius Puede contribuir con código para solucionar este problema o pensar en ideas. Vea # 3805 y # 4146 para algunos consejos.

@ brendan-rius, # 3805 en particular tiene las discusiones actualizadas más recientes sobre este error. Sugiero encarecidamente leer ese hilo para tener una idea de a qué nos enfrentamos.

Volviendo a publicar mi comentario aquí, ya que está más relacionado con este problema que las estrategias de combinación de 3 vías:

Si una combinación de tres vías no es viable para nuevas implementaciones en Helm 2.yz, ¿cuándo se solucionará el # 1193? El error ha estado abierto durante casi dos años sin una resolución clara planificada para Helm 2.0.

En este punto, no sabemos cómo proceder. Hemos discutido el error durante semanas y ninguna de las soluciones propuestas funcionará en todos los casos, ya sea introduciendo nuevos errores o cambiando significativamente el comportamiento de actualización de Tiller.

Por ejemplo, @michelleN y yo

1. Cuando falla una actualización, automáticamente revertimos y eliminamos los recursos que se crearon durante esta versión.

Esto es muy arriesgado ya que el clúster puede estar en un estado desconocido después de una actualización fallida, por lo que es posible que Helm no pueda continuar de manera limpia, lo que podría causar tiempo de inactividad de la aplicación.

1. Durante una actualización, si estamos creando un nuevo recurso y vemos que ya existe, en su lugar aplicamos esos cambios al recurso existente, o lo borramos / volvemos a crear.

Esto es extremadamente arriesgado ya que Helm puede eliminar objetos que se instalaron a través de otros paquetes o mediante kubectl create , ninguno de los cuales los usuarios pueden querer.

La opción más segura hasta ahora ha sido pedir a los usuarios que intervengan manualmente en el caso de este conflicto, que demostraré a continuación.

Si alguien tiene sugerencias / comentarios / propuestas alternativas, nos encantaría escuchar sus opiniones.

@bacongobbler , si no se

Para repetir el problema y la solución alternativa:

Cuando falla una actualización que instala nuevos recursos, la versión entra en un estado FALLIDO y detiene el proceso de actualización. La próxima vez que llame a helm upgrade , Helm hará una diferencia con la última versión DESPLEGADA. En la última versión DEPLOYED, este objeto no existía, por lo que intenta crear el nuevo recurso, pero falla porque ya existe. El mensaje de error es completamente engañoso como señala @arturictus .

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/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 otras palabras, eliminar los recursos creados durante la versión FAILED soluciona el problema.

@bacongobbler en primer lugar, quiero agradecerle por haber cuál es exactamente el problema en la actualización de Istio 0.8.0 a Istio 1.0.0 que causa el problema o si coincide completamente con su declaración de problema. Mi especulación es que aproximadamente 3 días antes del lanzamiento, algunos objetos que antes no se administraban (es decir, se agregaron en un trabajo posterior a la instalación) se migraron para no instalarse en un trabajo posterior a la instalación.

Al hablar con la comunidad de operadores de Istio que tiene mucha experiencia previa con Helm, algunos operadores nos han dicho que los recursos no administrados en Helm son malas noticias y, a menudo, conducen a fallas de actualización. Si la implementación de los gráficos de Istio tiene una falla que los hace incompatibles con la actualización con Helm 2.yz, corregir esas incompatibilidades sería excelente, por lo que no tendremos fallas de actualización en el futuro.

Estamos dispuestos a tomar el primer golpe de actualización de 0.8.0 a 1.0.0. Si la actualización es constantemente inestable, ese es un problema diferente.

Ejecuté una bisección en Istio, ya que la actualización estuvo funcionando hasta el 27 de julio (3 días antes del lanzamiento de Istio 1.0.0) y encontré que este compromiso era problemático: https://github.com/istio/istio/commit/301612af08128b15069d27ff6d03cdb87420e15b

Este RP esencialmente eliminó el registro de objetos de los trabajos posteriores a la instalación. Creo, pero no estoy seguro, que hemos eliminado todas las instancias de trabajos posteriores a la instalación en los 3 días previos a Istio 1.0.0.

¿Puede ofrecer algún consejo sobre la tabla Helm específica de Istio en lo que respecta a la actualización? ¿Mantener el registro de objetos fuera de los trabajos posteriores a la instalación resolverá nuestros problemas de actualización de forma permanente?

Realmente no puedo ofrecer ningún consejo sólido ni propuesta para solucionar este problema en todo el timón, ya que las personas con experiencia más reciente con Helm no han podido encontrar una solución generalizada (y no por no haber analizado el problema). No creo que pueda hacerlo mejor.

Salud
-steve

Se actualizó el título para reflejar mejor el error.

También nos afecta el problema. Usamos el último timón 2.10 con GKE 10.6.
¿Cuándo puedo esperar que se solucione?
¿Tenemos alguna solución alternativa razonable para el problema? Eliminar toda la implementación con la opción --purge es tan pobre.

No dude en opinar sobre mi último comentario. Realmente necesitamos comentarios sobre cómo proceder mejor aquí.

Se ha repetido una solución alternativa varias veces en este hilo. Lea https://github.com/helm/helm/issues/1193#issuecomment -419555433.

Me gusta la idea de una función de retroceso automático del timón ( opción 1 ) para resolver este problema. Sabemos que la última versión de Helm DEPLOYED estaba funcionando y el clúster estaba en buen estado, por lo que debería ser seguro volver a usarlo. Si es arriesgado para algunos casos de uso, podría optar por participar a través de una bandera para dirigir la actualización.

Esto es muy riesgoso ya que el clúster puede estar en un estado desconocido después de una actualización fallida, por lo que es posible que Helm no pueda continuar de manera limpia, lo que podría causar tiempo de inactividad de la aplicación.

Creo que muchos usuarios de helm usan helm de forma automatizada a través de un CD o una herramienta CM y es más arriesgado dejar la versión del timón en un estado FAILED. Esos recursos incompletos en una versión fallida podrían afectar a otros recursos de forma inesperada y podrían causar por sí mismos tiempo de inactividad. Por ejemplo, si la especificación del pod contenía una versión de imagen faltante que de alguna manera llegó a producción, entonces su carga de trabajo estaría en un estado ImagePullBackOff que no funciona. Para nuestra empresa, es aún peor, ya que tenemos algunos clientes en las instalaciones que pueden actualizarse a través de nuestra interfaz de usuario y, si falla, tenemos que obtener acceso a su sistema para depurar.

Incluso sin tener en cuenta el hecho de que podría solucionar este problema, la reversión automática sería una característica útil y ayudaría a garantizar que las versiones de Helm sean de naturaleza más transaccional. Gira Helm desde las implementaciones de mejor esfuerzo hasta la priorización de la estabilidad y las implementaciones exitosas.

@bacongobbler sería nuevas implementaciones:

• Agregar una bandera - -three-way-merge
• Solo permita que esa bandera se consuma en un helm install (nueva implementación)
• Una vez que esta bandera está habilitada, la actualización siempre usaría una combinación de 3 vías
• Las implementaciones existentes se bloquearían sin una ruta de migración: la solución alternativa estándar que la gente parece estar usando en este punto es helm delete --purge seguido de helm reinstall por lo que es posible que esto no sea tan desagradable como parece.

¿Resolvería esto realmente el problema?

Algunas personas están considerando la implementación de un operador para solucionar esta limitación de Helm. Eso sería una verdadera lástima. Ver https://github.com/istio/istio/issues/8841#issue -361871147

Salud
-steve

Volviendo al comentario anterior de @bacongobbler :

1. Durante una actualización, si estamos creando un nuevo recurso y vemos que ya existe, en su lugar aplicamos esos cambios al recurso existente, o lo borramos / volvemos a crear.
   Esto es extremadamente arriesgado ya que Helm puede eliminar objetos que se instalaron a través de otros paquetes o mediante kubectl create, ninguno de los cuales los usuarios pueden querer.

Me pregunto si podemos mitigar este riesgo haciendo que el nuevo comportamiento sea aceptado. Dentro de un espacio de nombres dado, generalmente uso helm exclusivamente, y sospecho que este es el caso de muchos. Si pudiera darle a Helm install / upgrade una marca para decirle que cualquier cosa en el espacio de nombres dado que no sea parte de una versión existente está bien para borrar / sobrescribir, ¿ayudaría eso?

Dado que también dijo "a través de otros paquetes", supongo que no desea que Helm tenga que examinar otras versiones como parte de la realización de una versión, por lo que mi sugerencia no funcionaría excepto en el modelo de lanzamiento único por espacio de nombres. Para responder a esa objeción, diría: si desea administrar varios paquetes en un espacio de nombres y aún así obtener este comportamiento, cree un gráfico general cuyo único propósito sea especificar las dependencias del gráfico que desea. Luego use la nueva bandera ("--exclusive"?) Cuando despliegue ese gráfico general.

Obviamente, esto no resuelve el problema para todos los casos de uso, pero quizás sea una solución alternativa suficiente.

@bacongobbler Podría estar muy lejos de aquí. Estoy enfrentando problemas similares en la actualización. A juzgar por lo difícil que es resolver este problema, me pregunto si es necesario reconsiderar algo más fundamental. Parte de la complejidad parece deberse al hecho de que Helm mantiene su propia versión de la configuración conocida, separada de la fuente de verdad real que es kubernetes. ¿Sería más confiable el sistema si Helm solo conservara una copia de los gráficos de timón implementados previamente con fines de historial y reversión, pero no la usara en absoluto durante la actualización? En cambio, Helm obtendría la verdad de kubectl en sí, y luego siempre tendría una diferencia de 2 vías para realizar.

Si un gráfico de timón dice que debería tener el recurso X, y kubectl ve un recurso X existente, entonces:

• Si el recurso existente está etiquetado como controlado por Helm, Helm realiza la actualización necesaria.
• Si el recurso existente no está etiquetado como controlado por Helm, Helm falla con un mensaje de error limpio (o se puede usar alguna marca de línea de comando para forzar la actualización y hacer que Helm se apropie del Recurso X existente).

Si el gráfico de helm dice que debería tener el recurso X y no hay uno según kubectl, Helm lo crea.

Si kubectl informa que tiene un recurso Y etiquetado como controlado por este gráfico de timón, y no hay ningún recurso Y en este gráfico de timón, entonces helm elimina el recurso.

Todos los recursos que no están etiquetados como controlados por este gráfico de timón siempre son ignorados por timón al realizar la actualización, excepto en el caso mencionado anteriormente donde el gráfico de timón dice que necesita el recurso X y X existe pero no está etiquetado.

Si por alguna razón la implementación de un gráfico de timón ocurre y falla, y solo se implementaron la mitad de los recursos, entonces durante una reversión, el timón usaría los archivos de configuración almacenados de la implementación exitosa anterior y ejecutaría exactamente el mismo algoritmo, o cosas podría dejarse en un estado roto en relación con algún indicador de línea de comando de timón. Si el usuario intenta actualizar nuevamente, dado que kubernetes se usa como la fuente de la verdad y no como la última implementación exitosa conocida, debería ser una diferencia simple de 2 vías entre el nuevo gráfico de timón y el estado existente del sistema.

También estamos viendo este problema. Nuestros pasos de reproducción:

1. helm install un gráfico que instala con éxito una implementación
2. Actualice el gráfico para incluir un recurso personalizado además de la implementación existente
3. Cambiar la imagen de la especificación del pod de implementación para imitar un error de implementación
4. helm install nuevo gráfico. Esto provocará una actualización continua de la implementación, que hemos configurado intencionalmente para que falle.
5. La instalación del timón debería fallar. Pero el recurso personalizado debe dejarse en k8s, etc. (verificar usando kubectl )
6. (En este punto, el timón está en mal estado)
7. Arregle el gráfico: coloque una imagen de goot en la especificación del pod de implementación.
8. helm install . Esperamos que esto funcione, pero no es así. Reporta "Sin recurso con nombre ___". El nombre es el del recurso personalizado.
9. Recuperación: elimine el recurso personalizado residual usando kubectl . Ahora funcionará helm install .

Tenga en cuenta que el primer intento en helm install con un recurso personalizado recién introducido en el gráfico debe fallar para entrar en este estado.

@ rbair23 lo intentamos antes y no funcionó. Está el grupo de trabajo de Apply, que busca mejorar el estado de la administración de objetos declarativos arreglando kubectl apply, moviendo la lógica del cliente al servidor , pero eso aún está en sus etapas iniciales. Kubectl (y tiller) necesitan conservar una copia de la última configuración aplicada para realizar una diferencia. No puede diferenciarse del estado en vivo del clúster sin realizar una estrategia de parche de combinación de tres vías, volviendo a este ticket.

Como el # 3275 se cerró como duplicado de eso: tenemos una situación similar a la del # 3275

Ya hay un trabajo en ejecución my-long-running-job . Y estamos intentando actualizar la versión:

>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

El trabajo existe:

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

Eliminando ese trabajo:

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

Resuelve ese impedimento:

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

Al menos el mensaje no Job with the name "my-long-running-job" found es engañoso, pero mi expectativa era que el trabajo también se actualizaría.

Sigo viendo esto en v2.9.1 (versión estable actualmente lanzada)

No estoy de acuerdo con que sea "muy peligroso" dar marcha atrás en una actualización. Creo que hacerlo es la solución correcta.

Kubernetes es declarativo. Obtenga una instantánea del estado del clúster antes de intentar la actualización.
Si hay un error a la mitad, vuelva a la instantánea.
Si alguien tiene ganchos de script que dejarían el clúster en mal estado al hacer esto, entonces es su culpa. (Quizás eso también podría resolverse con ganchos de retroceso)

Por supuesto, sería genial si una actualización se hiciera previamente y no se archivara en primer lugar tanto como fuera posible.
Los errores en los gráficos de dependencia generados por valores o argumentos --set deberían poder comprobarse antes de intentar cambiar algo, por ejemplo. Cosas como olvidarse de aumentar el número de versión también se pueden volar previamente para evitar hacer cambios cuando no funcione.

Hola,

Tuve el mismo problema con:

Cliente: v2.10.0 + g9ad53aa
Servidor: v2.10.0 + g9ad53aa

Eliminar serviceAccount, configMap y service era la única forma de hacer que Helm actualizara la versión.

Hola,

tenemos el mismo problema que describió @dilumr ... con la versión 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

Me encontré con esto en v2.9.1.

La actualización del gráfico que estaba ejecutando estaba saltando algunas versiones principales en un gráfico privado con muchos cambios, por lo que no estoy seguro de qué desencadenó exactamente el error en el futuro, pero la razón por la que la implementación terminó originalmente en FAILED estado era que tenía una bandera --wait y se agotó el tiempo de espera.

Terminamos con varias implementaciones duplicadas FAILED en helm list pero la última implementación en funcionamiento fue DEPLOYED . La creación de nuevas implementaciones arrojó No resource with the name x found .

Se pudo arreglar ejecutando helm rollback a la última versión que estaba en el estado DEPLOYED en helm list . Después de esa actualización, se pudo ejecutar sin errores.

Mira esto https://github.com/helm/helm/pull/4871.

Al igual que otros desde el punto de vista de las cosas, este error parece ocurrir con mayor frecuencia (no estoy seguro de siempre) para mí cuando falló mi última implementación y se dejaron instalados nuevos activos de esa implementación.

Entiendo cómo podría ser complicado y / o indeseable desinstalar componentes de una implementación fallida de Helm, pero ¿cuál es el comportamiento ideal de Helm para este tipo de situación?

Primero, creo que Helm debería estar bien con los espacios de nombres y otros recursos ya existentes si está intentando (reinstalarlos). Kubernetes se trata de "hacer la configuración correcta y dejar que kube descubra cómo hacer que el mundo coincida con la configuración".
En segundo lugar, creo que Helm debería ser todo o nada. Si una implementación falla, el clúster debe estar en el estado en el que estaba antes de que comenzara la implementación.
Si hay dos versiones en las que ambas quieren crear un espacio de nombres X, entonces hay un problema de recuento de referencias. Si hay una versión que quiere crear un espacio de nombres X, pero ya existe, entonces hay un problema de procedencia. Sin embargo, helm puede registrar esto usando anotaciones en los objetos y hacer lo correcto.

También estoy abordando este problema con el último helm 2.12.0 y kubernetes 1.10.11, incluso retrocediendo a la última versión buena ya que @aguilarm sugirió que no funcionó, también eliminar los recursos de los que helm se queja no ayuda, y después de la actualización el comando falla, deja esos mismos recursos como en realidad parcialmente recreados. Muy molesto para un entorno prod ...

Tengo 2 clústeres con un entorno muy similar, siendo la principal diferencia entre los 2 el número total de nodos. En un caso, un helm delete --purge seguido de un helm install funcionó, pero en otro no funcionó y todavía tengo que encontrar una manera de llevar eso a los últimos cambios de plantilla.

¿Hay alguna ETA sobre esto?

Pude solucionar esto con helm rollback y especificando la revisión más reciente (la que falló)

Tuve el mismo problema hoy,
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 funcionó.

Estamos experimentando esto de forma bastante regular mientras realizamos actualizaciones de timón; esto sucede después de implementaciones exitosas, no solo de implementaciones fallidas. No podemos eliminar --purge ya que estos son sistemas de producción con componentes no triviales que 1) no pueden no estar disponibles y 2) tardarían demasiado en recuperarse completamente desde cero para ser aceptables.

Vea el diagnóstico y la solución que publiqué anteriormente. Avísame si eso funciona para ti.

@bacongobbler Gracias por la respuesta. De hecho, esa es la solución que se me ocurrió también y tendrá que ser suficiente por ahora, pero estamos usando actualizaciones de timón docenas de veces al día a través de nuestro CICD, por lo que esto surge con la frecuencia suficiente como para ser un dolor de cabeza. Sin embargo, no estoy seguro de que lo anterior sea toda la historia, ya que los recursos nombrados a menudo ya existen, son parte de una implementación exitosa y no se cambian en la implementación actual; iirc es casi siempre el conjunto de recursos más reciente en la última implementación exitosa aunque curiosamente.

+1 a @ajcann y gracias @bacongobbler
Estoy exactamente en la misma situación.
Nuestro CICD está automatizado y, a menudo, las implementaciones las realiza un bot slack para entornos inferiores.
Cuando falla, tengo que hacer retroceder el timón manualmente y desplegarlo de nuevo.
El problema no es coherente en absoluto, pero sí frecuente.
Para mí, sucede solo durante la segunda implementación del gráfico / recurso hasta ahora.
Los recursos siempre existen.

observamos el mismo problema. Sucede si tienes una plantilla, que es:

• en un estado de cuenta {{if $condition -}}
• o en un {{ range $index, $value := $array-}}

@jkroepke acaba de señalarme que el PR # 5143 proporciona una buena solución para esto. Cuando se publique el indicador --atomic en la próxima versión secundaria, debería poder usarlo para purgar o revertir automáticamente cuando haya un error.

@bacongobbler dado que ha estado involucrado con la mayor parte de los idas y venidas en este caso, ¿hay algo más que se pueda hacer para solucionarlo por completo, o sería suficiente la bandera --atomic ?

Creo que @distorhead podría querer echarle un vistazo a ese y ver si también resuelve sus preocupaciones que planteó en https://github.com/helm/helm/pull/4871. Aparte de eso, parece que --atomic debería abordar la preocupación asumiendo que siempre usa la bandera --atomic .

No creo que se hayan propuesto soluciones para abordar el problema cuando se llega a este estado en particular, pero podría estar equivocado. Si la estrategia de mitigación para este problema es

• pasar manualmente por el estado en vivo del clúster y arreglarlo según la solución alternativa
• actualice a Helm 2.13.0 y use helm upgrade --atomic en el futuro

Entonces creo que es seguro cerrar esto.

Con suerte, Helm 2.13.0 no está tan lejos.
Este error rompe CI si ocurre un error en alguna parte de una versión.

Atomic no resolverá el problema

Gráfico de ejemplo: https://github.com/distorhead/ex-helm-upgrade-failure

1. Echa un vistazo a master, ejecuta deploy.

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

El gráfico contiene 2 implementaciones: myserver1 y 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. Haz un cambio radical. Elimine la implementación myserver1 del gráfico y modifique la implementación myserver2 con el error de usuario (elimine el campo de imagen, por ejemplo):

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. Ejecutar implementar:

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

Saluda a nuestro amigo de nuevo:

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 ¿cuál fue su comportamiento esperado para este escenario?

Un poco fuera de lugar sobre los retrocesos, pero de todos modos.

Para aquellas personas que desean usar la reversión, pero que tampoco desean que la reversión ocurra inmediatamente después de la implementación como en --atomic por algunas razones. Porque, por ejemplo, no hay forma de que el usuario inspeccione manualmente el estado incorrecto del clúster después de una falla y porque --wait flag no hace que helm registre información sobre fallas en los recursos que se están implementando. Entonces hay alguna manera: retroceder en la próxima ejecución, antes de la actualización (más información https://github.com/helm/helm/issues/3149#issuecomment-462271103)

Para repetir el problema y la solución alternativa:

Cuando falla una actualización que instala nuevos recursos, la versión entra en un estado FALLIDO y detiene el proceso de actualización. La próxima vez que llame a helm upgrade , Helm hará una diferencia con la última versión DESPLEGADA. En la última versión DEPLOYED, este objeto no existía, por lo que intenta crear el nuevo recurso, pero falla porque ya existe. El mensaje de error es completamente engañoso como señala @arturictus .

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 el # 4223 (comentario) :

><> 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 otras palabras, eliminar los recursos creados durante la versión FAILED soluciona el problema.

Gracias por poner esta solución en conjunto @bacongobbler , es esencialmente lo que también llegamos como proceso. Un problema doloroso aquí es que durante las actualizaciones complejas, muchos recursos nuevos, a veces algunos niveles de dependencia de profundidad, pueden encontrarse en este estado. Todavía no he encontrado una manera de enumerar completamente estos estados de una manera automática que lleve a situaciones en las que uno necesita fallar repetidamente una actualización para "buscar" todos los recursos relevantes. Por ejemplo, recientemente una dependencia recién agregada tenía una dependencia en un gráfico postgresql. Para resolver este problema, fue necesario eliminar un secreto, un mapa de configuración, un servicio, una implementación y un pvc; cada uno encontró el camino más largo.

Podría escribir un complemento similar a helm diff que enumeraría las plantillas creadas en la última versión. Incluso podría consumir pkg/kube directamente de Helm. client.Update tiene alguna lógica de negocios escrita para el seguimiento / eliminación de recursos de helm que podría reutilizarse obteniendo las dos versiones de Tiller e invirtiendo el orden de comparación. target.Difference(original) debería darle un resultado de todos los recursos que se introdujeron desde la versión anterior.

@bacongobbler ¿Qué solución recomendaría para tomar una aplicación implementada como parte de la versión A (por ejemplo, una versión más grande compuesta por varias aplicaciones) y dividirla de la versión A en su propia versión (o viceversa) sin incurrir en tiempo de inactividad? (la solución para eliminar recursos causaría un tiempo de inactividad) ... Intentar actualizar un recurso a través de una versión diferente da como resultado el error que se describe en este problema de Github.

Parece que este nuevo gráfico se ha instalado y reemplaza a los antiguos incluso antes de una implementación exitosa. Lo mismo ocurre con una actualización fallida: instalar. No debería instalarse si la tabla es incorrecta.
Simplemente retroceda al estado anterior en caso de error o actualice los gráficos de timón en caso de éxito.

Este es un proceso que utilizo para recuperarme de este problema (hasta ahora ha funcionado cada vez sin ningún incidente ... pero tenga cuidado de todos modos):

1. Ejecute helm list y descubra la última revisión del gráfico afectado

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

2. Vaya desde allí y busque la última revisión con DEPLOYED state
   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. Una vez que encuentre la última revisión DESPLEGADA, cambie su estado de DEPLOYED a SUPERSEDED y guarde el archivo
4. Intente hacer helm upgrade nuevamente, si tiene éxito, ¡ya está!
5. Si encuentra un error de actualización como este:
   Error: UPGRADE FAILED: "fetlife-web" has no deployed releases
   luego edite el estado de la última revisión de FAILED a DEPLOYED
kubectl -n kube-system edit cm fetlife-web.v381
6. Intente hacer helm upgrade nuevo, si vuelve a fallar, simplemente voltee la mesa ...

@bacongobbler @michelleN
¿Hay algo que dificulte la mejora del mensaje de error para este problema?

Creo que el mensaje de error debería indicar que "hay un conflicto porque el recurso no fue creado por helm y se requiere la intervención manual" y no "no encontrado". Solo este pequeño cambio en el error mejorará la experiencia del usuario por un buen margen.

@selslack Me

@michelleN He preparado un PR para cambiar el texto de error: # 5460.

Estoy experimentando este problema y me encuentro en una situación en la que no estoy seguro de cómo resolverlo.

Probé todos los pasos enumerados por https://github.com/helm/helm/issues/1193#issuecomment -470208910

Desafortunadamente eso no funcionó. Lo único que resuelve el problema es eliminar el recurso que genera el mensaje de error, luego helm upgrade nuevamente, lo cual será exitoso.

Sin embargo, la próxima actualización del timón fallará con el mismo error, y tengo que eliminar el recurso nuevamente y actualizarlo ... esto no es sostenible ni bueno.

Tengo dos entornos en los que uso helm para implementar como parte de nuestro proceso de CI: un entorno de control de calidad y un entorno de producción.

El entorno de control de calidad tenía el mismo problema, así que usé helm delete --purge , y luego helm upgrade , que resolvió el problema de forma permanente.

Sin embargo, no puedo hacer esto para el entorno de producción, no puedo simplemente borrarlo y actualizarlo, por lo que actualmente estoy atascado eliminando el recurso antes de cada implementación. Tengo suerte de que no sea un recurso de importación.

@zacharyw ¿a qué error te enfrentas en este momento? No resource with the name ... o "fetlife-web" has no deployed releases ?

¿Puede compartir alguna información adicional que ayude a depurar esto?

Tal vez la salida de kubectl -n kube-system describe cm -l NAME=YOUR_RELEASE_NAME | grep -A1 STATUS= (reemplace YOUR_RELEASE_NAME )

No dude en enviarme un correo electrónico con más información si no desea enviar spam a este problema con datos potencialmente no relacionados (rene (at) klacan (dot) sk).

Consulte https://github.com/helm/helm/issues/1193#issuecomment -419555433 para obtener un posible diagnóstico y una solución alternativa, @zacharyw.

@reneklacan Es el error no resource with the name ... . En nuestro caso, agregamos una entrada, aparentemente funcionó, pero luego las actualizaciones posteriores comenzaron a fallar con este error ... aunque la entrada ya existía.

El estado de mi versión más reciente (después de eliminar la entrada infractora y permitir que la actualización del timón la vuelva a crear) es DEPLOYED :

STATUS=DEPLOYED
VERSION=197

Sin embargo, si intentara actualizar de nuevo, fallaría.

@bacongobbler A menos que esté malinterpretando, creo que ya estoy haciendo la solución en ese comentario: elimino el recurso y dejo que se vuelva a crear ... el problema es que tengo que hacer esto cada vez.

@reneklacan en https://github.com/helm/helm/issues/1193#issuecomment -470208910 me salvó la vida.

Es una decepción que Helm falle de esta manera. Eliminar cosas en prácticamente cualquier entorno está lejos de ser ideal.

Sería genial si helm actualizara su propia base de datos cuando aparezca este tipo de error y luego vuelva a intentarlo.

Creo que con el indicador --cleanup-on-fail habilitado, este caso de error debería desaparecer. Cierre según lo resuelto mediante # 4871 y # 5143.

Si surgen más problemas sin esos indicadores, vuelva a abrir un nuevo problema. ¡Gracias!

El problema está cerrado, pensé en agregar un comentario sobre cómo lidiar con el problema sin tener que eliminar la versión del timón o las implementaciones en ejecución.

Entonces, reproduje el problema con los siguientes pasos:

1. Instale el gráfico test-chart-failure con una plantilla de servicio.
2. Agregue un subgráfico con una plantilla de servicio que tenga una cadena (por ejemplo, "prueba") en el puerto del servicio
3. Actualice la tabla. Fallará con el error Service in version "v1" cannot be handled as a Service: v1.Service.Spec: v1.ServiceSpec.Ports: []v1.ServicePort: v1.ServicePort.Port: readUint32: unexpected character: ...

Pude actualizar después de corregir el puerto a un número, sin ejecutar helm delete , aplicando la sugerencia en http://centosquestions.com/helm-how-to-delete-bad-deployment :

1. Encontré la revisión fallida con helm history test-chart-failure
2. Eliminó el mapa de configuración de la revisión específica con kubectl delete cm -n kube-system test-chart-failure.v2
3. Ejecutado helm upgrade con el gráfico corregido