Helm: `helm upgrade --install` no realiza una instalación / actualización si falla la primera instalación

Esto fue intencional por diseño de https://github.com/kubernetes/helm/pull/3097. Básicamente, diferenciarse de una implementación fallida provocó un comportamiento no deseado, en particular esta larga lista de errores:

• https://github.com/kubernetes/helm/issues/2257
• https://github.com/kubernetes/helm/issues/2341
• https://github.com/kubernetes/helm/issues/2346
• https://github.com/kubernetes/helm/issues/2437
• https://github.com/kubernetes/helm/issues/3068

Si su versión inicial termina en un estado fallido, le recomendamos que elimine la versión a través de helm delete --purge foo y vuelva a intentarlo. Después de una versión inicial exitosa, se ignorará cualquier versión fallida posterior y helm hará una diferencia con la última versión exitosa conocida.

Dicho esto, podría ser valioso 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 hacer diferencias. Sin embargo, estaría un poco preocupado por ciertos casos extremos. @adamreese ¿tienes alguna opinión sobre este?

La solución sugerida parece completamente insostenible en un sistema automatizado. Definitivamente no quiero que todo lo que invoque a helm tenga que saber sobre "si la primera versión falla, elimínelo y vuelva a intentarlo". Por un lado, la mayoría de mis herramientas no saben si se trata de una instalación o actualización, o si es la primera o la centésima vez, casi siempre se ejecuta helm upgrade --install .

También me gustaría señalar que hice un comentario sobre el PR original https://github.com/kubernetes/helm/pull/3097#discussion_r151808599 preguntando específicamente sobre este caso.

El comportamiento anterior fue mejor para este caso.
Estoy de acuerdo con @chancez. Esto hace que upgrade --install no sean idempotentes para una ocurrencia común.

@bacongobbler
Si nos preocupa que los lanzamientos fallen y dejen metralla debido a ganchos fallidos, diría que es un problema de diseño del gráfico. (Los ganchos funcionan mejor cuando son idempotentes)
Los usuarios son libres de crear un manejo de errores y un comportamiento no idempotente alrededor del timón.

¿Qué otros casos extremos nos preocupan?
Parece que el # 3097 se encarga mucho 👍

Mi desarrollo local sería mucho más fluido si pudiera hacer que helm upgrade -i fuera idempotente incluso contra lanzamientos fallidos por al menos alguna combinación de argumentos. Mi caso de uso es cuando tengo un script de muchas versiones que sé que quiero poner en marcha para iniciar un entorno de desarrollo local.

Esto podría ser análogo a la bandera --replace para helm install . Tenga en cuenta que --replace es una de las dos únicas banderas de helm install que faltan en helm upgrade , siendo la otra --name-template .

Para ser absolutamente claro, sí, sería bueno arreglarlo. ¿Alguien quiere probarlo mientras tenemos las manos ocupadas con otro trabajo?

Hola,
Creé un PR https://github.com/kubernetes/helm/pull/3437 que debería solucionar este problema

No estoy seguro de por qué necesitamos los comandos install y upgrade , yo solo uso el comando upgrade --install y parece que mucha gente hace lo mismo. Solo necesito un comando que haga upgrade --install y no se tropiece con una ejecución fallida. ¿Podemos simplemente cambiar el nombre de upgrade --install a deploy , hacerlo verdaderamente idempotente y deshacernos de los otros dos?

(Estoy luchando con una nueva variante de este problema de comportamiento en 2.8.0. Desde que actualicé desde 2.7.2 ahora si tengo una instalación fallida, y luego delete --purge it, y upgrade --install it , Todavía puedo obtener el error Error: UPGRADE FAILED: "xyz" has no deployed releases . Parece que --purge no es completamente efectivo en 2.8.0 y el timón tiene un estado atascado que no se muestra en list --all . Tengo que luego a install para que el timón vuelva a un estado en el que pueda hacer el upgrade --install habitual nuevamente)

Estoy de acuerdo con @whereisaaron , estaría bien con un comando deploy que funcionara más como kubectl apply . También hace que la automatización de Helm sea mucho más fácil, ya que no tiene que verificar las versiones existentes en alguna locura de scripts de shell :)

¿Quizás la solución es hacer que helm ejecute automáticamente helm delete --purge ?
Algo como:
1) El usuario ejecuta helm upgrade --install
2) La primera versión falla
3) El usuario realiza algunos cambios en el gráfico y vuelve a ejecutar helm upgrade --install
4) Helm intenta ejecutar el comando
5) Falla y hay precisamente una versión anterior en estado fallido
6) Helm ejecuta silenciosamente helm delete --purge
6) Después de la purga, Helm reintenta automáticamente helm upgrade --install y muestra el resultado de eso

Quizás este comportamiento podría activarse a través de la bandera --force que ya tiene un comportamiento similar para otros escenarios

Buena idea, pero no creo que jamás deberíamos eliminar el libro mayor liberación sin que el usuario que pide explícitamente para eliminar esos datos. Los operadores de Helm querrán saber por qué el servicio no se actualizó a partir de versiones fallidas anteriormente, o deducir las fallas mediante la recopilación de esos datos del libro mayor.

Proporcioné un comentario anteriormente en el hilo que describe una solución al problema. Es similar a su solución en ejecución, pero sin la necesidad de eliminar todo el libro mayor de versiones. Creo que # 3437 está intentando aplicar esa solución como parche.

@rchernobelskiy también me pasa a mí. Exactamente como lo describe.

Me encuentro con este problema tal vez una vez al día al implementar nuevas aplicaciones.
¡Es un dolor!

@gmanolache Todavía estamos en el timón 2.7.0 por esta razón.
No me queda claro si actualizar para usar la bandera --force es seguro: comentario

Si necesita degradar, esta es una buena manera de hacerlo: rebajar a 2.7.0

¿Cuál es esta útil información de diagnóstico del 'libro mayor del timón' y cómo llegamos a ella? :sonrisa:

Me preocupa que lo siguiente se pueda interpretar como de mal humor, es realmente solo una invitación para recibir sugerencias sobre cómo podemos obtener información de diagnóstico cuando tiene una implementación fallida. Porque realmente parece que me estoy perdiendo algo. ¿Parece que se supone que el estado fallido tiene alguna utilidad para los operadores? Volví a rastrear el sitio del manual del timón; ¿Funcionará algo como 'helm get manifest' en un estado fallido para extraer información de diagnóstico útil?

Mi experiencia de usuario cuando obtengo una implementación fallida es que no obtienes información útil. Helm rechaza todos los recursos parcialmente creados / restantes, de modo que el 'estado del timón' no muestra nada. Todo lo que puede hacer es 'deshacer' o 'eliminar - purgar' (no puede simplemente 'eliminar' o su CI 'actualizar - instalar' seguirá fallando). El estado fallido solo parece servir para romper la idempotencia de 'actualización - instalación' que todos anhelamos para nuestras implementaciones de CI.

¿Sería razonable tener una opción '--auto-rollback' para situaciones de CI, por ejemplo, 'actualizar --install --auto-rollback'. Por lo general, prefiero retroceder y tener que levantarme de la cama para lidiar con un estado fallido 😆 😴 💤

¿Cuál es esta útil información de diagnóstico del 'libro mayor del timón' y cómo llegamos a ella? 😄

helm help history

Gracias @bacongobbler. Ok, entiendo que esa lista es lo que significa el libro mayor. Y si todavía tiene el libro mayor, ¿puede usar helm get manifest --revision 123 para ver qué se implementó que falló? Ciertamente es útil preservarlo. Y si rollback no perdemos esa información.

History prints historical revisions for a given release.

A default maximum of 256 revisions will be returned. Setting '--max'
configures the maximum length of the revision list returned.

The historical release set is printed as a formatted table, e.g:

    $ helm history angry-bird --max=4
    REVISION   UPDATED                      STATUS           CHART        DESCRIPTION
    1           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  Initial install
    2           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  Upgraded successfully
    3           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  Rolled back to 2
    4           Mon Oct 3 10:15:13 2016     DEPLOYED        alpine-0.1.0  Upgraded successfully

Si tuviéramos helm upgrade --install --auto-rollback , tanto la implementación fallida como la reversión se registrarían en el libro mayor y estarán disponibles para los operadores. Y eso contribuiría en gran medida a evitar que las implementaciones de CI lleguen al estado intratable de 'fallido' en el que la 'actualización del timón - instalación' deja de funcionar. Las implementaciones de CI fallidas generalmente son desarrolladores que inyectan errores tipográficos / errores en el sistema de implementación. Con '--auto-rollback', pueden inspeccionar el mensaje de error del comando helm retenido en el registro del servidor de implementación, corregir e implementar los valores corregidos.

Supongo que incluso sin la opción '--auto-rollback' podríamos usar un contenedor automático para ejecutar helm rollback cualquier momento helm update --install devuelve un error 'FAILED'. Y tal vez detecte dónde está la instalación inicial, y helm delete --purge en su lugar en esos casos.

Es decir, podríamos diseñar un script de envoltura para asegurar que los resultados de una 'actualización de timón --instalar' de CI siempre sea un estado en el que la próxima 'actualización de timón --instalar' de CI siempre será posible. Mientras se conserva la información del libro mayor para cualquier intento fallido (al menos para las versiones cuya instalación inicial funcionó).

helm deploy =

• helm upgrade --install
• si falla entonces
  
  
  
  • si revisión = 1
  
  
  • luego helm delete --purge
  
  
  • más helm rollback
  
  

@whereisaaron eso sería elegante 👍

¿Existe una manera fácil de obtener la última versión de trabajo que no sea helm history ${name} | tail -2 | head -1 | awk '{print $1}' , para ser utilizada por helm rollback ?

Hola a todos,

Estoy usando Helm 2.12.2 y todavía tengo el problema, ese timón falla, cuando falla la primera implementación. ¿Es esto quizás una regresión?

No estoy seguro de que sea una regresión, pero en realidad nunca se "arregló".

@ RickS-C137 Creo que se supone que esto se debe solucionar usando helm upgrade --install --force que 'eliminará' y luego 'instalará - reemplazará' una versión fallida.

Todavía estoy tratando de solucionar este problema en una tubería de Jenkins que estoy tratando de usar.
Estoy tratando de implementar una nueva imagen de mi aplicación y no podría importarme menos si la implementación ya existe o no.
Quiero ejecutar un comando que reemplace la implementación actual o simplemente lo instale si no existe.
Intenté helm install --replace A menudo obtengo Error: a released named xyz is in use, cannot re-use a name that is still in use Lo que obviamente mata mi canalización y la compilación falla.

@bacongobbler ¿Qué opinas sobre https://github.com/helm/helm/issues/3353#issuecomment -385222233?

No veo cómo habría tiempo de inactividad o pérdida de datos si destruimos y recreamos la versión inicial si falla la versión inicial.

Implementé esto en nuestra compilación:

if helm history --max 1 "$name" 2>/dev/null | grep FAILED | cut -f1 | grep -q 1; then
    helm delete --purge "$name"
fi

helm upgrade --install --wait "$release" chart/

Con helm actualmente, no sabe qué combinación de comando + opciones de helm usar sin inspeccionar el estado actual. Y para un comando de timón dado, no sabe lo que obtendrá, porque depende del estado actual. Ese no es realmente el sueño declarativo del estado deseado ☁️ 💤 😄

En el timón 3 podemos potencialmente desaprobar install / upgrade / --replace / --upgrade / --force y reemplazarlos todos con un helm deploy idempotente anterior , que si helm deploy falla, retrocede (revisión> 1) o elimina + purga (revisión = 1), para dejar el estado como estaba antes. El manifiesto fallido aún estaría disponible a través de helm history/get . E incluso podría haber una opción '--no-rollback' para las personas que quieran preservar la implementación en un estado fallido para su investigación

La opción de helm upgrade --install --force está acercando, excepto que en lugar de revertir y actualizar, elimina y reemplaza las versiones fallidas (incluso para revisiones> 1), lo que hace que algunas personas se enojen por el # 3208 ... 😮 ⚡️ 💥

Por ahora, podemos usar scripts de envoltura o metaherramientas como helmsman cuya lista de funciones es en parte para emplear helm pero mitigar este problema:

• Idempotencia : siempre que el archivo de estado deseado no cambie, puede ejecutar Helmsman varias veces y obtener el mismo resultado. _ [... independientemente del estado actual] _
• Continuar a partir de fallas : en el caso de una implementación parcial debido a una falla de implementación de carta específica, arregle su carta de timón y ejecute Helmsman nuevamente sin necesidad de deshacer primero los éxitos parciales.

reemplácelos todos con un despliegue de timón idempotente que logra el estado deseado o deja el estado sin cambios

En retrospectiva, este es un objetivo de diseño asombrosamente obvio.

Hola,
En nuestro caso, la versión inicial realmente no falló ... Es solo que nuestra aplicación no estaba completamente operativa cuando transcurrió el tiempo de espera de instalación o algún otro problema extraño que se solucionó. En cualquier caso, la aplicación está funcionando perfectamente, por lo que tener que eliminarla sería un problema para nosotros (¡tenemos algo de almacenamiento persistente adjunto que también sería eliminado!).

¿Existe alguna solución para implementar un gráfico cuando la versión inicial 'aparentemente falló' pero en realidad está bien?

Entonces, ¿la conclusión de que upgrade --force es demasiado contundente, es decir, hay ocasiones en las que eliminar + reemplazar + retry_upgrade no es el remedio correcto para una actualización fallida?

¿Existe un problema separado que rastrea la idea de fusionar install & upgrade en un comando deploy ?

No es que yo sepa de @dcow. ¿Cuál es el caso de uso del comando helm upgrade --install ?

https://github.com/helm/helm/issues/3353#issuecomment -362497951

No estoy seguro de por qué necesitamos los comandos de instalación y actualización, yo solo uso el comando de actualización --install y parece que mucha gente hace lo mismo. Solo necesito un comando que se actualice: se instale y no se tropiece con una ejecución fallida. ¿Podemos simplemente cambiar el nombre de la actualización: instalar para implementar, hacerla verdaderamente idempotente y deshacernos de las otras dos?
...

y

https://github.com/helm/helm/issues/3353#issuecomment -469109854

Con helm actualmente, no sabe qué combinación de comando + opciones de helm usar sin inspeccionar el estado actual. Y para un comando de timón dado, no sabe lo que obtendrá, porque depende del estado actual. Ese no es realmente el estado declarativo deseado sueño nube zzz sonrisa

En helm 3 podemos potencialmente desaprobar install / upgrade / --replace / --upgrade / --force y reemplazarlos todos con una implementación de helm idempotente que logra el estado deseado o deja el estado sin cambios.
...

En general, estoy de acuerdo en que helm debería funcionar como kubectl apply e intentar lograr la realidad deseada en lugar de tener que ejecutar diferentes tipos de comandos según el estado de su clúster. Esperaba agregar soporte a un problema dedicado si existía uno o al menos averiguar cuál era la resolución, ya que deploy no está implementado actualmente y estamos en el timón 3.2.

@dcow Ok, ¿quieres crear un problema entonces con tu propuesta?

@hickeyma hecho https://github.com/helm/helm/issues/8415!