<p>actualización del timón: la instalación ya no funciona</p>

Pensé que estaba experimentando el mismo problema, pero resultó que acababa de tener una eliminación anterior (pero no purgada), la liberación por ahí. verifique helm list -a, y si su lanzamiento está allí, helm delete --purge releasename. helm upgrade -i está funcionando correctamente en 2.7.2 para mí.

Este es un efecto secundario de solucionar problemas relacionados con la actualización de versiones que estaban en mal estado. https://github.com/kubernetes/helm/pull/3097 fue el PR que solucionó este problema. ¿Hay un caso límite aquí que no pudimos atrapar?

Marque helm list -a como mencionó @tcolgate , quizás también explicando cómo reproducirlo también sería útil para determinar si se trata de un caso de borde no detectado o un error.

También tiene el mismo problema, junto con nombres de versiones duplicados:

$>helm ls -a|grep ingress
nginx-ingress               9           Thu Nov 30 11:33:06 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
nginx-ingress               11          Thu Nov 30 11:37:58 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
nginx-ingress               12          Thu Nov 30 11:38:50 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
nginx-ingress               8           Thu Nov 30 11:31:27 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
nginx-ingress               10          Thu Nov 30 11:33:53 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
$>helm diff nginx-ingress ./nginx-ingress
Error: "nginx-ingress" has no deployed releases

Cuando estaba actualizando, ¿qué mensaje se mostró?

mismo error que el diff anterior, pero una instalación diría que ya estaba instalado.

Me refiero a los intentos de actualización anteriores que terminaron en estado FALLIDO. Quiero saber cómo llegamos a la situación en la que todos los lanzamientos están en un estado fallido.

Ohh, ¿las implementaciones de nombres de versiones duplicadas? Eso no estoy seguro, lo entiendo con bastante frecuencia. A veces, todos están en un estado DESPLEGADO, a veces una mezcla de FALLADO y DESPLEGADO. Usamos un servidor Jenkins de CI / CD que actualiza constantemente cada combinación de relaciones públicas, por lo que hacemos varios helm upgrade al día, generalmente solo con una nueva etiqueta de contenedor. Por lo general, los duplicados son molestos cuando se mira lo que se implementó, esta fue la primera vez que tuvimos un problema difícil con ellos, y normalmente no actualizamos el controlador de ingreso como lo hicimos en este caso.

Parece que terminé con algo similar, veo algunos duplicados en mis listas de lanzamientos:

$ helm ls
NAME                      REVISION    UPDATED                     STATUS      CHART                           NAMESPACE
.....
front-prod                180         Tue Dec  5 17:28:22 2017    DEPLOYED    front-1                         prod
front-prod                90          Wed Sep 13 14:36:06 2017    DEPLOYED    front-1                         prod 
...

Todos parecen estar en un estado DESPLEGADO, pero bien podría ser que una actualización anterior fallara en algún momento, ya que he encontrado ese error varias veces. Todavía estoy en K8S 1.7, por lo que aún no he actualizado a Helm 2.7.

El mismo problema, no se puede actualizar sobre la implementación FALLIDA

Lo mismo aquí usando 2.7.2. El primer intento de liberación fracasó. Luego, cuando intenté una actualización --instalar, me apareció el error "Error: ACTUALIZACIÓN FALLIDA:" $ {RELEASE} "no tiene versiones implementadas".

El mismo problema aquí con 2.7.2, helm upgrade --install falla con:

Error: UPGRADE FAILED: "APPNAME" has no deployed releases

Si la versión se purga por completo con helm del --purge APPNAME entonces un upgrade --install posterior funciona bien.

Estoy experimentando el mismo problema. Combinado con # 3134 que no deja opción para implementaciones idempotentes automatizadas sin algunas secuencias de comandos para solucionarlo.

@winjer acaba de intentar eliminar con --purge y para mí no funcionó, aunque el error cambió
/ # actualización de timón foo / charts / foo / -i --wait
Error: ACTUALIZACIÓN FALLIDA: "foo" no tiene versiones implementadas
/ # helm delete --purge foo
lanzamiento "foo" eliminado
/ # actualización de timón foo / charts / foo / -i --wait
La versión "foo" no existe. Instalándolo ahora.
Error: lanzamiento de foo fallido: deployments.extensions "foo-foo-some-service-name" ya existe

@prein Esto se debe a que tiene un servicio que no es "propietario" por helm, pero que ya existe en el clúster. El comportamiento que está experimentando me parece correcto. La implementación no puede tener éxito porque helm tendría que "tomar posesión" de un objeto API que antes no poseía.

Tiene sentido poder actualizar una versión FAILED, si el nuevo manifiesto es realmente correcto y no se contenta con ningún otro recurso en el clúster.

También veo este comportamiento en una versión llamada content :

helm upgrade --install --wait --timeout 300 -f ./helm/env/staging.yaml --set image.tag=xxx --namespace=content content ./helm/content
Error: UPGRADE FAILED: no resource with the name "content-content" found
helm list | grep content
content                         60          Mon Dec 25 06:02:38 2017    DEPLOYED    content-0.1.0                   content           
content                         12          Tue Oct 10 00:02:24 2017    DEPLOYED    content-0.1.0                   content           
content                         37          Tue Dec 12 00:42:42 2017    DEPLOYED    content-0.1.0                   content           
content                         4           Sun Oct  8 05:58:44 2017    DEPLOYED    k8s-0.1.0                       content           
content                         1           Sat Oct  7 22:29:24 2017    DEPLOYED    k8s-0.1.0                       content           
content                         61          Mon Jan  1 06:39:21 2018    FAILED      content-0.1.0                   content           
content                         62          Mon Jan  1 06:50:41 2018    FAILED      content-0.1.0                   content           
content                         63          Tue Jan  2 17:05:22 2018    FAILED      content-0.1.0                   content           

Tendré que eliminar esto para poder continuar con la implementación, avíseme si hay algo que pueda hacer para ayudar a depurar esto.
(Creo que deberíamos cambiar el nombre del problema, ¿ya que se trata más de duplicados?)
(también ejecutamos 2.7.2 )

De hecho, tengo otra versión duplicada en mi clúster, si tiene algún comando que pueda ejecutar para ayudar a depurarlo. ¡Hágamelo saber!

Acabamos de actualizar a Tiller 2.7.2 y estamos viendo lo mismo. helm delete RELEASE_NAME seguido de helm upgrade RELEASE_NAME . falla con Error: UPGRADE FAILED: "RELEASE_NAME" has no deployed releases . upgrade es la forma prevista de restaurar una versión eliminada (pero no purgada), ¿correcto?

Parece que puede restaurar la versión volviendo a la versión eliminada.

al ver el mismo problema con v2.7.2 , falla cuando no hay versiones anteriores implementadas con éxito

También viendo dos posibles versiones de este problema:

en CI:

+ helm upgrade --install --wait api-feature-persistent-data . --values -
+ cat
WARNING: Namespace doesn't match with previous. Release will be deployed to default
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
Error: UPGRADE FAILED: "api-feature-persistent-data" has no deployed releases

en mi máquina local:

(tanto en mi OSX bash como en un contenedor gcloud / kubectl)

+ helm upgrade --install --wait api-feature-persistent-data . --values -
+ cat
WARNING: Namespace doesn't match with previous. Release will be deployed to default
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
Error: UPGRADE FAILED: no PersistentVolumeClaim with the name "api-feature-persistent-data-db" found

Las advertencias son normales para nuestro gráfico.
Los errores son interesantes porque uno de nuestros subgráficos tiene un pvc.yaml en él.

helm del --purge <release> mitiga el problema.
Esto hace que nuestra canalización de CI sea difícil de actualizar.

@adamreese ¿cuál es la resolución final para este problema? Estamos en 2.8 y todavía no podemos actualizar una versión anterior de FAILED con el cambio a helm list .

En particular, nos encontramos con los siguientes tipos de problemas:

• implementar un lanzamiento, de acuerdo
• upgrade --install --wait , pero tal vez haya un pequeño error y --wait no tenga éxito (por ejemplo, las sondas de vida nunca lo compensan)
• después de arreglar el gráfico, upgrade --install --wait falla con xxx has no deployed releases

Eliminar / purgar no es deseable ni aceptable aquí: la versión puede tener varios recursos (pods, balanceadores de carga) que no se ven afectados por el único recurso que no aumentará. En versiones anteriores de Helm, upgrade --install nos permitió parchear solo el cambio que rompió la versión completa sin tener que eliminar todos los recursos.

Helm es el propietario de todos los recursos involucrados en todo momento aquí: el recurso solo está marcado como FAILED porque --wait no logró esperar a que todos los recursos estuvieran en buen estado. Supongo que sucederá lo mismo si un pod es demasiado lento para comenzar y en muchos casos similares.

@peay vea # 3353 para una discusión de seguimiento.

Gracias, eso lo aclara. Realmente nos dimos cuenta de que solo lo estábamos logrando cuando no teníamos un lanzamiento exitoso para empezar. En ese caso, la purga es una buena solución.

Esto todavía sucede si falla la instalación.
Necesita purgar y volver a intentarlo.

UPGRADE FAILED: "API" has no deployed releases
entonces necesitas purgar manualmente
helm delete --purge API
y funcionará.

A partir de helm 2.9, también puede realizar helm upgrade --install --force por lo que no es necesario purgar. Para versiones anteriores:

helm delete API
helm install --replace --name API ./mychart

@bacongobbler Todavía estoy confundido acerca de este comportamiento.
¿Podrías responder https://github.com/kubernetes/helm/pull/3597#issuecomment -382843932 cuando tengas tiempo?

Gracias por tu trabajo en esto.

Seguro. Estoy AFK en este momento, pero puedo responder más tarde esta noche. Entienda completamente la confusión e intentaré responder a sus preguntas lo mejor que pueda. Es una locura en la oficina preparando otras cosas para KubeCon EU. :)

Estoy dispuesto a ayudar a piratear esto y / o mejorar los documentos cuando estemos ahí fuera.
Definitivamente nos vemos: +1:

@bacongobbler, ¿esta dirección # 3353 y niega el montón de código que he escrito como parte de # 4004?

En mi caso, helm upgrade --install --force hizo un delete --purge y luego una instalación.

Es este el comportamiento esperado? Casi pierdo 2 meses de trabajo por esto. ¿Cuándo force comenzó a significar delete ?

^ Tuve algunas conversaciones con la gente de kubecon y descubrí que bastantes equipos están anclados a v2.7.0 debido a este cambio de comportamiento.

Estoy de acuerdo en que upgrade install nunca debería ser destructivo, incluso con lo que sea que --force pueda significar.

@bacongobbler , lo siento, no pude reunirme cuando estábamos en CPH.
¿Existe documentación detrás de la justificación para cambiar el comportamiento para no permitir la actualización de una versión fallida?
El antiguo comportamiento parece mucho más deseable que el que tenemos ahora.

Consulte el segundo comentario en https://github.com/kubernetes/helm/issues/3353 para obtener un contexto de fondo sobre por qué tuvimos que hacer ese cambio

Tengo mucha curiosidad por saber cuál es el camino propuesto en el futuro. No podemos dar marcha atrás en el número 3097 debido a los problemas demostrados en el número 3353, por lo que me encantaría saber cuál cree la comunidad que es el camino correcto para solucionar este problema. Podemos retroceder # 3597, pero por lo que he oído, no hay una buena solución en el futuro para solucionar el problema helm upgrade --install . :decepcionado:

Sé que estamos trabajando para reelaborar la lógica de aplicación para Helm 3, pero eso es un largo camino

Gracias por vincular eso @bacongobbler :)
Su sugerencia aquí parece un enfoque razonable:

Puede ser útil no realizar una diferencia cuando no se hayan implementado lanzamientos exitosos. La experiencia sería la misma que si el usuario ejecutara helm install por primera vez, en el sentido de que no habría una versión "actual" contra la que diferenciarse. Sin embargo, estaría un poco preocupado por ciertos casos extremos. @adamreese ¿tienes alguna opinión sobre este?

Esto nos permitiría retroceder # 3597 ya que se abordaría el único caso de falla (nada contra lo que diferenciarse).
Esto vuelve a hacer upgrade --install no destructivo y más similar a kubectl apply .

Intuitivamente, eso es lo que esperaría que hiciera un upgrade --force : no haga operaciones de diferenciar y parchear, simplemente aplique la plantilla completa, ignorando lo que está en su lugar en este momento. Realmente no puedo pensar en ninguna razón técnica por la que esto no sería posible, pero tampoco estoy familiarizado con el funcionamiento interno de Helm.
Aún puede ser una operación peligrosa, pero cualquiera que use una bandera --force normalmente espera un cierto riesgo al forzar las actualizaciones. Si bien yo diría que uno no espera que esto elimine y vuelva a crear su implementación, con un posible tiempo de inactividad.

He leído las discusiones, pero todavía no tengo claro cómo tener un comando upgrade --install idempotente (o secuencia de comandos).

Con la versión estable actual, ¿cómo puedo lograr esto en un script automatizado? Necesito poder implementar de forma no interactiva sin usar delete --purge , incluso si un intento anterior falló.

En cuanto a los planes futuros, este es el comportamiento que esperaba originalmente de upgrade --install :

• Instalar si no se realizaron instalaciones previas
• Actualizar una instalación previamente exitosa
• Reemplazar una instalación fallida anteriormente
• Si la instalación falla, los recursos antiguos aún deben estar en su lugar, sin tiempo de inactividad cuando sea posible
• Sin operaciones destructivas (como el delete --purge automático mencionado anteriormente)

En mi opinión personal, no se deberían requerir banderas adicionales para este comportamiento. Así es como se comportan generalmente los administradores de paquetes. A menos que no haya entendido bien los requisitos, no creo que sea necesaria una bandera --force , por ejemplo.

¿Ha habido alguna actualización al respecto? ¿Cuál es la forma correcta de ejecutar de manera confiable una actualización en una instalación existente sin tener que ejecutar una purga si algo falla?

@MythicManiac FWIW:
Todavía tengo a nuestros equipos anclados en v2.7.0 debido a este comportamiento.
No parece que tengamos problemas con la actualización y eliminación de recursos cuando se supone que deben usar helm upgrade --install con esta versión.

También tenemos este problema. Es muy molesto tener que eliminar los servicios de K8 y los ELB de AWS relacionados porque helm has no deployed releases . El administrador de paquetes es excelente, pero este problema conduce a un tiempo de inactividad de la producción, lo cual no es bueno.

Como una solución muy hacky, si el problema con la implementación de origen es
resolvable (por ejemplo, servicio preexistente), hacer una reversión al original
la liberación fallida puede funcionar.

El viernes 5 de octubre de 2018, a las 18:13, Eugene Glotov, [email protected] escribió:

También tenemos este problema. Es muy molesto tener que eliminar K8s
servicios y AWS ELB relacionados porque helm no tiene versiones implementadas. El
el administrador de paquetes es excelente, pero este problema conduce a un tiempo de inactividad de la producción que
no es bueno.

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

@tcolgate , ¡gracias! Acabo de solucionar otro problema (https://github.com/helm/helm/issues/2426#issuecomment-427388715) con su solución e intentaré probarlo para detectar ELB existentes cuando implemente un nuevo gráfico la próxima semana sobre los recursos existentes .

Hacer una reversión a la versión fallida original puede funcionar.

@tcolgate , acabo de probar y no, no funciona en el caso de la primera implementación.

$ helm upgrade --wait --timeout 900 --install myproject charts/myproject/myproject-1.1.1.tgz
14:53:18 Release "myproject" does not exist. Installing it now.
14:53:18 Error: release myproject failed: deployments.apps "myproject" already exists

$ helm list
NAME            REVISION    UPDATED                     STATUS      CHART               APP VERSION NAMESPACE
myproject       1           Mon Oct  8 11:53:18 2018    FAILED      myproject-1.1.1                 default

$ helm rollback myproject 1
Error: "myproject" has no deployed releases

Tengo curiosidad, si Helm no puede implementar un gráfico sobre los recursos existentes, ¿por qué helm delete causa que se eliminen exactamente estos recursos?

@ thomastaylor312 , enfrentamos este problema ~ así como https://github.com/helm/helm/issues/2426~ (arriba: encontré la causa raíz real de 2426) con helm 2.11.0. ¿Crees que deberían reabrirse?

Encontré este hilo después de Error: UPGRADE FAILED: "xxx-service" has no deployed releases
Si bien era visible desde un timón ls -a.

Decidí ver si era un problema debido a un valor --set incorrecto, y --debug --dry-run --force en realidad TODAVÍA eliminó mi pod de ejecución ... mi expectativa era que una acción de ejecución en seco NUNCA se modificaría recursos del clúster.

Sin embargo, funcionó y el servicio podría volver a implementarse después, pero experimentamos un tiempo de inactividad.

Mi expectativa era que una acción de ejecución en seco NUNCA modificaría los recursos del clúster.

Esta es una expectativa justa, deberíamos hacer que ... no suceda

Creo que fue parcheado en https://github.com/helm/helm/pull/4402 pero sería bueno si alguien lo verificara. ¡Lo siento por eso!

mismo problema después de la actualización a 2.11.0

Publicación cruzada:
https://github.com/reactiveops/reckoner/issues/48#issuecomment -453411283

¿Por qué está esto cerrado? ¿Tenemos una forma adecuada de manejar esto ahora?

@gerbsen , no hay forma de evitar esto con las versiones actuales de Helm que no sea destructivo.
Todavía usamos Helm 2.7.0 para todo en mi organización. Es una versión muy antigua que tiene otros errores, pero no tiene este problema.

Acabo de hacer que helm upgrade --install --force hiciera un delete --purge y destruyera mi pvc / pv sin avisarme (sobre el reciclaje). Tenía varias versiones fallidas, por lo que estaba en un estado en el que se estaba ejecutando en Kubernetes, pero Helm pensó que no había versiones en ejecución. No son buenos tiempos en absoluto.

@notque después de perder todo el panel de grafana dos veces, comencé a hacer copias de seguridad antes de realizar cualquier tipo de actualización, tener este tipo de riesgo elimina todos los beneficios de usar helm

Para aquellos que buscan ayuda, el problema desapareció después de actualizar Helm a la versión 2.15.2.

Sigo viendo este problema en 2.16.0

¿Por qué sigue cerrado? 2.16.1 todavía está afectado

@ nick4fake Creo que es un duplicado de https://github.com/helm/helm/issues/5595