Hola, ¿puedes darnos más detalles sobre cómo estás implementando? ¿Estás usando helm upgrade --install por casualidad? Y si lo hace, ¿cuál es el estado de la implementación cuando está rota ( helm ls ), presumiblemente es Failed ?

Si este es el caso, un helm delete --purge <deployment> debería funcionar.

hola, perdón por faltar información.
Sí, estoy usando helm upgrade --install
Y sí, la implementación permanece en Failed para siempre.
Desafortunadamente, helm delete --purge <deployment> no es una opción aquí en absoluto. No puedo simplemente eliminar los servicios de producción por eso :)

La pregunta es por qué el timón no se puede recuperar después de 3 fallas consecutivas.

la única forma de ordenar eso sin eliminar la versión agrega --force

--force ¿a qué? a helm upgrade --install ?
y si es así, entonces significa que el problema anterior es una característica esperada y deberíamos usar --force con cada implementación. - Si es así, ¿significa que desplegará liberaciones rotas por la fuerza?

sí, por supuesto a helm upgrade --install :)
y sí, debes usar --force con cada implementación

¿Significa que --force también desplegará lanzamientos rotos a la fuerza? - Quiero decir, si el pod se rompe y se reinicia todo el tiempo, ¿eliminará los pods antiguos y programará otros nuevos?
--force force resource update through delete/recreate if needed
¿Cuál es la condición delete ? ¿Puedes explicar cómo funciona exactamente? la descripción es definitivamente demasiado corta para una bandera tan crítica; espero que haga miles de cosas bajo el capó.

Por cierto, realmente no quiero terminar con servicios de producción eliminados, por lo que la bandera --force no es una opción para mí.

y ¿de verdad crees que no es un problema?
incluso el mensaje de error es incorrecto:
app-name has no deployed releases
que establece que no hay lanzamientos implementados
mientras lo hay, pero con el estado Failed y el timón ni siquiera intenta arreglarlo :( - al arreglarlo me refiero a que intente implementarlo, en lugar de renunciar al principio

Ver https://github.com/helm/helm/issues/3208

No puede estar más de acuerdo. Nuestra producción está experimentando el mismo error. Por lo tanto, eliminar el gráfico no es una opción y forzar la instalación parece peligroso. Este error todavía está presente con Helm 3. Por lo tanto, podría ser bueno incluir una solución o una solución alternativa más segura.

se puede solucionar eliminando "status": "deployed", en storage.go: 136

Ver: https://github.com/helm/helm/pull/6933/commits/638229c3d3646e78d0fd5157309f8aeadfd01af1

Arreglaré la solicitud de extracción cuando tenga tiempo.

El código en su lugar era originalmente correcto. Eliminando status: deployed de los resultados de la consulta con Helm encontrando la última versión para actualizar, independientemente del estado en el que se encuentre actualmente, lo que podría generar resultados no deseados. Elude el problema temporalmente, pero presenta problemas mucho mayores en el futuro.

Si puede proporcionar la salida de helm history cuando encuentre este error, sería útil. Es más útil determinar cómo se termina en un caso en el que el libro mayor de entregas no tiene entregas en el estado "implementado".

Me encuentro con este problema al implementar por primera vez en un nuevo clúster. ¿Debo usar --force también?

Encontré este problema cuando eliminé la versión anterior sin usar la opción --purge .

helm delete --purge <release-name>

Versión de timón

Client: &version.Version{SemVer:"v2.15.X"}
Server: &version.Version{SemVer:"v2.15.X"}

También me encuentro con este problema.

@bacongobbler
Golpeé esto con helm3. El historial está completamente vacío cuando esto sucede, aunque los recursos k8s rotos están allí desde el intento 1.

La reproducción parece realmente fácil:

1. actualización de timón: instale "algo con un pod que tenga un contenedor que salga con error"
2. corrija lo que causó que el contenedor saliera, por ejemplo, un valor con un argumento no válido para el ejecutable dentro del contenedor, e intente nuevamente
   -> Error: ACTUALIZACIÓN FALLIDA: "foo" no tiene lanzamientos implementados

Parece que la bandera --atomic puede ser un camino a seguir en mi escenario (CI / CD). Dado que limpia la versión inicial fallida por completo como si nunca hubiera sucedido, no abordo este problema en el próximo intento.

Lo mismo aquí, no veo cómo se puede recomendar el uso de delete o --force especialmente cuando hay volúmenes persistentes en su lugar, ya perdí todos los paneles de grafana debido a esto una vez, no estoy haciendo de nuevo :)

Actualización: por cierto, en mi caso, el lanzamiento está fallando debido a:

Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims

incluso si no he cambiado nada en los valores de grafana

@ alex88 ¿ puede proporcionar la salida de helm history ? Necesito saber cómo otros están abordando este caso para que podamos tratar de identificar la causa raíz y encontrar una solución.

@bacongobbler seguro que me encantaría ver esto solucionado, ya que soy muy cauteloso al usar helm debido a que he perdido volúmenes persistentes un par de veces (aunque probablemente sea mi culpa)

REVISION    UPDATED                     STATUS  CHART           APP VERSION DESCRIPTION
4           Wed Dec  4 02:45:59 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
5           Mon Dec  9 12:27:22 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
6           Mon Dec  9 12:33:54 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
7           Mon Dec  9 12:36:02 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
8           Mon Dec  9 13:06:55 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
9           Mon Dec  9 13:38:19 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
10          Mon Dec  9 13:38:51 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
11          Mon Dec  9 13:41:30 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
12          Mon Dec  9 13:56:01 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
13          Mon Dec  9 15:15:05 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims

Básicamente, he intentado varias veces ejecutar la actualización para cambiar algunas variables env y dado que, aunque hubo un error de implementación, las variables env cambiaron de todos modos, seguí haciéndolo ignorando el error

¿Cómo llegaste a un estado en el que cada lanzamiento ha fallado? ¿Dónde están los lanzamientos 1, 2 y 3?

¿Cómo llegaste a un estado en el que cada lanzamiento ha fallado? ¿Dónde están los lanzamientos 1, 2 y 3?

cambiando las variables env (tuve que hacer varios cambios) y ejecutando una actualización cada vez, estaba cambiando las variables env pero no tenía idea de cómo solucionar el error de volumen persistente

Actualización: por cierto, estoy usando

version.BuildInfo{Version:"v3.0.0", GitCommit:"e29ce2a54e96cd02ccfce88bee4f58bb6e2a28b6", GitTreeState:"clean", GoVersion:"go1.13.4"}

con respecto a la versión anterior, probablemente Helm se queda solo con 10 de ellos

Helm3: Tengo un problema similar mientras actualizo istio, la versión falló, ahora no puedo volver a implementarla aunque se solucionó un pequeño error en las plantillas. No puedo eliminar la versión de producción ya que también eliminará el ELB asociado con el servicio istio-ingress.

¿Hay algún trabajo futuro para cambiar la lógica cuando la versión inicial termina en un estado fallido?

¿Qué tengo que hacer si no se acepta el tiempo de inactividad?

% helm upgrade prometheus-thanos --namespace metrics -f values.yaml . 
Error: UPGRADE FAILED: "prometheus-thanos" has no deployed releases
% helm install --atomic prometheus-thanos --namespace metrics -f values.yaml .                                                                                                               
Error: cannot re-use a name that is still in use
% helm version
version.BuildInfo{Version:"v3.0.1", GitCommit:"7c22ef9ce89e0ebeb7125ba2ebf7d421f3e82ffa", GitTreeState:"clean", GoVersion:"go1.13.4"}

¿Qué tengo que hacer si no se acepta el tiempo de inactividad?

por ahora solo uso helm para generar las plantillas y las guardo manualmente localmente y las aplico

Parece que la bandera --atomic puede ser un camino a seguir en mi escenario (CI / CD). Dado que limpia la versión inicial fallida por completo como si nunca hubiera sucedido, no abordo este problema en el próximo intento.

@ henrikb123 lo anterior funciona solamente si se ha utilizado Allways --atomic bandera. De lo contrario, no funcionará. Por ejemplo: intente instalar un gráfico roto sin él y ejecute el mismo comando con la bandera --atomic . Se romperá. Para su información, estoy usando la última versión de Helm -> 3.0.2

@ alex88 ¿ puede proporcionar el resultado del historial del timón? Necesito saber cómo otros están abordando este caso para que podamos tratar de identificar la causa raíz y encontrar una solución.

@bacongobbler, ¿por qué no haces lo que @ henrikb123 dijo aquí para simular el problema? Como señaló @ henrikb123 , el historial está completamente vacío . Puedo confirmar eso también. Eche un vistazo por favor:

$ helm upgrade --install --cleanup-on-fail --reset-values --force --namespace teleport --values values.test.yaml teleport ./
Release "teleport" does not exist. Installing it now.
Error: Secret "teleport-secrets" is invalid: metadata.labels: Invalid value: "helm.sh/chart:teleport-1.0.0app.kubernetes.io/managed-by": a qualified name must consist of alphanumeric characters, '-', '_' or '.', and must start and end with an alphanumeric character (e.g. 'MyName',  or 'my.name',  or '123-abc', regex used for validation is '([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9]') with an optional DNS subdomain prefix and '/' (e.g. 'example.com/MyName')

$ helm history teleport
Error: release: not found

$ helm upgrade --install --cleanup-on-fail --reset-values --force --namespace teleport --values values.test.yaml teleport ./
Error: UPGRADE FAILED: "teleport" has no deployed releases

También me encontré con esto con Istio.

Hay un problema de Istio con 1.4.3 en el que uno de los trabajos que ejecuta la instalación fallará si no puede acceder al servidor de la API de Kubernetes. Luego deja un trabajo atrás y si intenta volver a ejecutar el comando Helm, falla porque el trabajo ya existe. Intenté eliminar el trabajo, ajustar cosas y volver a ejecutar la actualización, pero nunca tuve éxito ... y ahora estoy atascado.

(Así es como puede entrar en un estado de lanzamiento totalmente fallido, ya que había una pregunta al respecto).

REVISION    UPDATED                     STATUS  CHART       APP VERSION DESCRIPTION                                                                                                                                                                                                         
10          Tue Jan 14 09:17:00 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition
11          Tue Jan 14 09:22:21 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: warning: Hook post-upgrade istio/charts/security/templates/create-custom-resources-job.yaml failed: jobs.batch "istio-security-post-install-1.4.3" already exists
12          Tue Jan 14 09:23:10 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: warning: Hook post-upgrade istio/charts/security/templates/create-custom-resources-job.yaml failed: jobs.batch "istio-security-post-install-1.4.3" already exists
13          Tue Jan 14 09:25:58 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition 
14          Tue Jan 14 09:35:21 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: warning: Hook post-upgrade istio/charts/security/templates/create-custom-resources-job.yaml failed: jobs.batch "istio-security-post-install-1.4.3" already exists
15          Tue Jan 14 09:38:08 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition 
16          Tue Jan 14 14:02:47 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition
17          Tue Jan 14 14:19:44 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition
18          Tue Jan 14 14:33:36 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: warning: Hook post-upgrade istio/charts/security/templates/create-custom-resources-job.yaml failed: jobs.batch "istio-security-post-install-1.4.3" already exists
19          Tue Jan 14 14:36:59 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition

Esto es con Helm 3.0.2.

En mi opinión, este es un problema crítico que debe solucionarse lo antes posible. Vi muchos otros problemas similares que estaban abiertos para el mismo problema desde la versión 2 y hasta ahora parece que no se ha solucionado.

Solo pido a los desarrolladores que hagan exactamente lo que dijo @ henrikb123 en su comentario para simular este problema. Es una forma muy sencilla de simularlo. Puede probarlo con cualquier versión de Helm (2.xx y 3.xx). Estoy casi seguro de que ocurrirá con todos ellos.

Quizás --atomic debería ser un requisito estricto (no un argumento de línea de comando). Incluso es bastante redundante como --cleanup-on-fail . La diferencia es que --cleanup-on-fail no solucionó este problema como lo hizo --atomic .

También nos hemos encontrado con esto en la producción y el tiempo de inactividad no es una opción. Encontramos una solución al parchear el último mapa de configuración FALLIDO para tener la etiqueta STATUS: DEPLOYED usando un comando como ...

kubectl -n kube-system patch configmap app-name.v123 --type=merge -p '{"metadata":{"labels":{"STATUS":"DEPLOYED"}}}'

En nuestro caso, estábamos seguros de que kubernetes finalmente implementó con éxito la última revisión FALLIDA.

¿Cómo llegamos a este estado?

Básicamente, nuestro equipo de desarrollo ignoró las actualizaciones FALLAS porque Kubernetes todavía estaba haciendo las modificaciones después de que se agotó el tiempo de espera del timón.

Específicamente, estamos usando Helm 2 y configuramos TILLER_HISTORY_MAX=20 en la implementación de implementación de timón. Usábamos helm upgrade --wait --timeout 1080 para todas nuestras actualizaciones RollingUpdate, que estaban demorando más con el tiempo. Luego, las actualizaciones del timón comenzaron a agotarse, pero nadie se alarmó (solo molesto) porque Kubernetes todavía estaba haciendo las modificaciones con éxito. Después de que se agotó el tiempo de espera de 20 actualizaciones (hoy), nos alarmamos porque ya no podíamos implementar porque, en cambio, estábamos viendo app-name has no deployed releases .

¿Por qué funciona el parche?

Descubrimos que solo necesitábamos parchear la etiqueta STATUS en el mapa de configuración porque nos dimos cuenta de que Helm probablemente estaba solicitando mapas de configuración usando una solicitud similar a ...

kubectl -n kube-system get configmap -l NAME=app-name,STATUS=DEPLOYED

La pista se encontró cuando vimos el mapa de configuración yaml y notamos las siguientes etiquetas ...

$ kubectl -n kube-system describe configmap app-name.v123
Name:         app-name.v123
Namespace:    kube-system
Labels:       MODIFIED_AT=1579154404
              NAME=app-name
              OWNER=TILLER
              STATUS=FAILED
              VERSION=123
Annotations:  <none>
Data
====
release:
----
H4sIAAAAAAAC...snipped...

Y esto es consistente con https://github.com/helm/helm/issues/5595#issuecomment -552743196

@bacongobbler en lugar de preguntarse cómo

Pero en realidad, para responder a sus inquietudes: un tiempo de espera es una buena razón para un lanzamiento fallido. La versión también se bloqueará y no se puede revertir cuando se actualiza y se agota el tiempo de espera.

Por lo tanto, tener volúmenes creados dinámicamente por las reclamaciones. Al eliminar las reclamaciones (al eliminar un gráfico), los volúmenes también se eliminan de forma permanente . No es así como te gusta. Yo y muchos otros desarrolladores estamos estancados durante meses y estamos tratando de solucionar este problema.

No le gustó la idea de eliminar status: deployed de la consulta. Entonces, ¿qué hay de agregar una nueva etiqueta que realmente marque la última versión sin importar si su estado fue implementado o falló? Eso realmente tendría sentido. Porque eso es lo que quiere hacer, quiere obtener la última versión para actualizar. Y si no hay ninguno, probablemente debería buscar versiones fallidas en su lugar. O simplemente use una nueva etiqueta que marque la última directamente.

_Estoy emocionado de escuchar tu opinión sobre esto._

Colocación perfecta @AmazingTurtle.

No estoy seguro de si esto ya se ha notado, pero este problema también surge si la primera instalación de un gráfico falla por cualquier motivo (lo cual es una ocurrencia muy común, especialmente para los usuarios de gráficos por primera vez que pueden necesitar iterar en su configuración para que todo funcione).

Creo que la única solución para los usuarios de CLI en este caso es eliminar el secreto de seguimiento de la versión si usa el controlador de secretos, así como todos los recursos que fueron creados por la última versión (para evitar encontrarse con las verificaciones de propiedad de recursos de Helm).

Esta es una función real de una herramienta que escribí internamente para manejar este problema cuando surge:

package foo

import (
    "helm.sh/helm/v3/pkg/action"
    "helm.sh/helm/v3/pkg/release"
    "helm.sh/helm/v3/pkg/storage/driver"
)

// DangerouslyApplyRelease allows installing or upgrading any release from a failed state,
// but does not enforce Helm's standard resource ownership checks.
func DangerouslyApplyRelease(cfg *action.Configuration, rel *release.Release) error {
    // Forcibly mark the last release as successful and increment the version
    rel.Info = &release.Info{
        Status: release.StatusDeployed,
    }
    rel.Version++

    var err error

    // Attempt to create the release
    err = cfg.Releases.Create(rel)

    // If release already exists, update it
    if err == driver.ErrReleaseExists {
        err = cfg.Releases.Update(rel)
    }

    return err
}

@jlegrone ¿El uso de helm delete --purge (v2) o helm uninstall (v3) también funcionaría, ya que todas son versiones fallidas?

Lo señalado por @jlegrone es cierto.
@hickeyma su propuesta es una solución que puede funcionar. Pero necesito una solución definitiva.

Es un error dañino durante los últimos 2 años y el timón no lo va a solucionar.
helm delete no es aceptable en la mayoría de los casos de producción
con helm3 no podemos kubectl edit secret sh.helm.release.... porque está encriptado
helm rollback <latest-successful> es solo la solución correcta

así que si tiene por defecto HISTORY_MAX = 10 y lo intentó 10 veces para que algo funcione, está completamente perdido ...

y si tiene algo de lógica en la instalación frente a la actualización, no puede eliminar sh.helm.release ..... v * secrets

el timón debe morir o arreglarlo

encontrado solución
helm3 establece etiquetas en sus secretos:
kubectl get secrets --show-labels | grep sh.helm.release.v1

....
sh.helm.release.v1.helm-must-die.v34                 helm.sh/release.v1                    1         13h       modifiedAt=1580326073,name=helm-must-die,owner=helm,status=failed,version=34
sh.helm.release.v1.helm-must-die.v35                 helm.sh/release.v1                    1         13h       modifiedAt=1580326228,name=helm-must-die,owner=helm,status=failed,version=35
sh.helm.release.v1.helm-must-die.v36                 helm.sh/release.v1                    1         1h        modifiedAt=1580370043,name=helm-must-die,owner=helm,status=failed,version=36
...

así que hazlo para los últimos kubectl edit secret sh.helm.release.v1.helm-must-die.v36 y establece el estado de la etiqueta = implementado
y para su lanzamiento antes (v35), establezca el estado de la etiqueta = reemplazado

el próximo helm upgrade --install ... funcionará

@ kosta709 Similar a mi hallazgo para Helm2, que almacena las versiones como ConfigMaps en el espacio de nombres del sistema kube con etiquetas que son todas CAPS, Helm3 ahora almacena las versiones como Secretos en el espacio de nombres de la aplicación con etiquetas que están todas en minúsculas.

Entonces, para Helm3, puede usar un comando de parche de kubectl ligeramente diferente ...

kubectl -n app-namespace patch secret app-name.v123 --type=merge -p '{"metadata":{"labels":{"status":"deployed"}}}'

Ojalá no tuviéramos que discutir estas soluciones. Arreglar esto en el producto debe ser la máxima prioridad. Un recordatorio de lo malo que es esto (sin tener en cuenta las soluciones alternativas):

Si una versión falló la primera vez que se implementó O si suficientes versiones no pudieron rotar el último éxito del historial, la versión no se puede arreglar sin una intervención manual.

Dado que el uso de Helm de una canalización de implementación continua es probablemente un patrón común o al menos uno deseado, esto no es viable.

Estoy completamente de acuerdo, pero al menos quería documentar claramente el trabajo porque cuando entras en este estado, parece que no hay otra opción que abandonar el lanzamiento y hacer una interrupción.

Junto con los parches para evitar una interrupción, también dejamos de usar helm --wait y, en su lugar, confiamos en nuestra propia lógica de sondeo para saber cuándo el lanzamiento es exitoso o no. Es más trabajo, pero ahora tenemos mucha más visibilidad, lo cual es útil cuando una versión está demorando más de lo esperado y podemos detectar fallas antes del tiempo de espera.

Esto no fue un problema para mí en versiones anteriores de helm, y no hay implementaciones fallidas, kubectl muestra servicios en ejecución y todo está funcionando.

Ahora simplemente estoy tratando de ejecutar helm upgrade -f app.yaml --namespace prometheus prometheus prometheus y aparece el error: Error: UPGRADE FAILED: "prometheus" has no deployed releases pero no puedo probar ninguna de las soluciones porque esto está en producción ...

@zrsm, lo que estamos haciendo ahora es generar los archivos yaml usando helm y usando kubectl diff / dry-run para obtener una vista previa de los cambios antes de aplicarlos manualmente.

@zrsm, lo que estamos haciendo ahora es generar los archivos yaml usando helm y usando kubectl diff / dry-run para obtener una vista previa de los cambios antes de aplicarlos manualmente.

Gracias por la respuesta, bajé la calificación a 2.15.1 pero encontré problemas similares, sin embargo, intenté algo como eliminar mi ~ / .helm y luego reinicialicé la cuenta de servicio de tiller de kubectl, después de hacer esto, pude aplicar gráficos a kubernetes . Intentaré probar esto con helm 3 más tarde hoy y responderé con una solución. Tengo la sensación de que este podría haber sido el problema.

Hola, probé esto ... y parece que realizar el siguiente comando después de eliminar también mi anterior ~ / .helm / resolvió esto ...

helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's<strong i="6">@apiVersion</strong>: extensions/v1beta1<strong i="7">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

Estoy pensando que si instalas una nueva edición de helm y las cosas de tu cuenta de servicio no están ubicadas (limpié mi computadora portátil y la restauré en algún momento), esto sucede y esta fue la solución. Espero que también funcione para ti.

Este error está en curso en Helm 3, ¿hay alguna solución planificada?

También se encuentra con este problema con un clúster nuevo y una implementación nueva debido a un tiempo de espera. No me gusta conectarme manualmente a nuestro clúster para solucionar este problema, pero supongo que esa es la única opción ahora.

¿Podemos asegurarnos de que este problema se resuelva lo antes posible?

este problema es tan frustrante que es una razón para dejar de usar helm completo.

Estoy de acuerdo. Esto me está volviendo loco. Voy a trabajar para solucionarlo. Deséame suerte.

Estoy de acuerdo. Esto me está volviendo loco. Voy a trabajar para solucionarlo. Deséame suerte.

¡gracias y buena suerte!

No me importaría que algunos de ustedes vean el PR # 7653.

Creo que esto resolverá los problemas descritos anteriormente.

No puedo creer que todavía esté abierto sin reacción de los mantenedores

cc @bacongobbler @mattfarina

¿El uso de helm delete --purge (v2) o helm uninstall (v3) también funcionaría, ya que todas son versiones fallidas?

@hickeyma no siempre; esto también podría ser el resultado de la corrupción de los metadatos de la versión de helm, por lo que en algunos casos la desinstalación podría eliminar los recursos bajo carga.

a veces, la versión no falla, pero el tiempo de espera y el timón la etiquetan como la que falla, y la próxima vez muestra que no tiene una versión implementada, pero la aplicación es en realidad completamente funcional, me sucedió muchas veces, así que tuve que cambiar la versión. etiqueta a deployed uno. no siempre es una opción hacer helm delete --purge (v2) or helm uninstall (v3)

@rimusz ¿cómo vas a cambiar la etiqueta de lanzamiento?

@dudicoco editando manualmente el secreto de la última versión de helm v3, puede automatizarlo y usar kubectl patch

se han trasladado a https://github.com/k14s/kapp, que funciona de maravilla.

@rimusz eso es lo que pensé, gracias.

También realicé una copia de mi corrección para el timón 2 en el n. ° 7668, pero todavía estoy esperando comentarios sobre el n. ° 7653

El mismo problema aquí,

Una versión implementada con --wait superó el tiempo de espera y finalmente está en funcionamiento. Todavía está marcado como fallido.
Y así, las implementaciones posteriores también están fallando.

Esto significa que el estado de publicación no es una información confiable.

Usamos k8s en nuestra empresa para muchos servicios de producción.
Algunas veces en un mes, tenemos los mismos problemas con helm en diferentes aplicaciones (" * no tiene versiones implementadas").
Usamos diferentes versiones de helm (desde la 2.7 hasta la 3.0.3).
El problema no se soluciona.
Esto causa mucha incomodidad a nuestros usuarios (desarrolladores que despliegan aplicaciones en clúster)
Cada vez, cuando lo alcanzamos, solo parcheamos el último secreto de la versión (estado de implementado).
¿Hay algún plan para agregar un comportamiento que ignore el estado de las últimas versiones e instale nuevas versiones?

Teniendo --history-max establecido en 10 (valor predeterminado), la primera versión tuvo éxito.
Luego, las siguientes 10 versiones fallaron en:
Error: UPGRADE FAILED: timed out waiting for the condition (Se simuló, por lo que se esperaba).
Después de eso, la siguiente versión (la undécima fallida) falló en:
Error: UPGRADE FAILED: "app" has no deployed releases (¡ese es el problema!)

¿Sería posible que helm conservara siempre el último lanzamiento

Me encanta la idea. Necesitaría modificar la funcionalidad de almacenamiento, pero creo que podría hacerse.

https://github.com/helm/helm/pull/4978 se fusionó para Helm 2. Quizás no se transfirió a Helm 3. Si alguien tiene tiempo y quiere transferirlo, no dude en hacerlo.

Intenté portar esto a Helm 3 con # 7806, y me encantaría verlo combinado lo antes posible. ¡Gracias, @ultimateboy!

¿Qué pasa con las versiones que fallan en la _primera_ instalación, es decir, no tienen versiones anteriores exitosas?
Estamos usando upgrade --install para la implementación idempotente de lanzamientos de helm y cuando falla el primer lanzamiento, todas las invocaciones posteriores de upgrade --install fallan con el error "no tiene lanzamientos implementados" (este problema).

El escenario de "falla de la primera versión" es al menos más manejable, porque generalmente lo ejecuta o monitorea manualmente (y puede aplicar una solución en ese momento), en lugar de tener el timón ejecutado por un sistema CI / CD que simplemente comienza a fallar día y no se recupera incluso después de corregir el código.

Por supuesto, todavía debería estar arreglado.

También es valioso preservar la última versión exitosa de todos modos, no solo por este error. Por ejemplo, problemas de depuración con archivos de valores, etc.

@peterholak El escenario de "falla de la primera versión" a veces también se realiza con un CI / CD y, por ejemplo, tenemos acceso restringido a nuestro clúster y ni siquiera podemos hacer un "helm ls", ¿cómo se supone que debemos "administrar esto"?

Este problema debería ser de alta prioridad, ya que la mayoría de la gente usa Helm en producción. Podría ejecutar la instalación de helm con --atomic , pero ¿y si quisiera inspeccionar el motivo del error antes de implementarlo? Estaría bloqueado por el tiempo de espera antes de que la instalación falle y luego se revierte. Si pudiera actualizar con éxito, no tendré que sentirme atrapado en el tiempo al inspeccionar la falla.

También estamos usando upgrade --install para una implementación idempotente de lanzamientos de helm. Porque así es como funcionan las canalizaciones ci / cd automatizadas. No planeamos jugar manualmente con el timón porque eso evitaría nuestra canalización de implementación.

En una canalización de implementación automatizada, la primera implementación casi siempre fallará. Las implementaciones posteriores no deben activarse de manera diferente al primer intento.

Considere aumentar considerablemente la prioridad de este tema.

La experiencia es taaaaaaaaaaaaaaaaaan mala, no podemos simplemente eliminar toda la versión, ¡porque está en producción! ¡Causará el tiempo de inactividad del servidor! ¿Cómo podemos resolver este problema al final?

Además, ¿alguien puede quitar la etiqueta de pregunta / ayuda? Este problema no se trata de la falta de documentación, sino del comportamiento actual de Helm, que no es de gran ayuda para su uso en canalizaciones de implementación automatizadas.

El # 7806 PR se ha fusionado con el maestro. Se lanzará en 3.2. Cerraré este tema en consecuencia.

¡Estupendo! Esto resuelve la mayoría de nuestros problemas con Helm.

Sin embargo, ¿cuál es el comportamiento actual si falla la primera versión (todavía no hay versiones implementadas)?

Hubo https://github.com/helm/helm/issues/3353 que fue abordado por https://github.com/helm/helm/pull/3597 pero solo cuando se usa --force .

--force embargo, --force no siempre es adecuado de todos modos. Así que toda la situación aún no está clara.

@technosophos gracias por la corrección. Curioso, ¿cuándo sería 3.2. lanzamiento disponible para instalar? Sigue recibiendo el error app-name has no deployed releases en una versión fallida existente. Y es una especie de bloqueador en las canalizaciones de CI / CD.

@peterholak ver # 7913.

3.2 se discutirá en la llamada pública de desarrollo del 16 de abril. Lo he clasificado solo para los que actualmente parecen que se pueden envolver de inmediato. Luego, comenzaremos el proceso de lanzamiento de la versión beta (suponiendo que todos los mantenedores estén de acuerdo con la llamada de mañana).

Estaba enfrentando el mismo problema en AKS resolver para solucionar el problema mencionado con el siguiente comando:

helm version : 3.1.2
Acabo de eliminar el paquete del clúster k8s con el comando
helm delete <release-name>

y ejecuta el ciclo de implementación para solucionar el problema

El problema sigue ahí en la versión 3.2.0

@deimosfr Esto se corrigió en # 7653 que estará en la versión 3.2.1. Aún no se ha lanzado, pero puede obtener la solución si desea construir a partir del maestro.

Estoy en 3.2.1 y esto todavía está sucediendo

Aún existen razones por las que este error puede ocurrir. 3.2.1 no eliminó simplemente el error. Eliminó algunas de las causas. Si todavía lo está experimentando, su problema es diferente a lo que corrigió.

@yinzara Tengo un caso clásico de "ruta b" de la descripción original en un clúster nuevo sin problemas. También puedo reproducir este error en otro clúster donde Helm v2 funciona bien. Por supuesto, podemos hacer el clásico baile de "esto es causado por otra cosa, abre un nuevo problema", pero creo que será más rápido si simplemente se reconoce que no está realmente arreglado.

¿Cuál es la salida de helm list ? ¿Cuál es el "estado" de la versión fallida anterior? Helm 2 tiene este problema y no se ha solucionado en absoluto, así que sigo pensando que su problema no es lo que piensa.

Todavía ocurre en la versión 3.2.1.

Si la implementación inicial falla 3 veces, todo se atasca ... No hay forma de solucionarlo si no borra el gráfico e implementa uno bueno.

Detalles:

helm history t3-mac -n t3                                                                                                                                                                 REVISION        UPDATED                         STATUS          CHART           APP VERSION     DESCRIPTION
1               Fri May 22 18:55:11 2020        failed          t3-mac-2.13.0   2.13.0          Release "t3-mac" failed: timed out waiting for the condition
2               Fri May 22 19:33:44 2020        failed          t3-mac-2.13.0   2.13.0          Upgrade "t3-mac" failed: timed out waiting for the condition
3               Fri May 22 19:57:51 2020        pending-upgrade t3-mac-2.13.0   2.13.0          Preparing upgrade

helm.exe upgrade --namespace t3b --install --force --wait t3b-mac t3b-mac-2.13.0.tgz
2020-05-22T18:14:01.7103689Z Error: UPGRADE FAILED: "t3b-mac" has no deployed releases

Tengo el mismo problema en el gráfico implementado y el pod funciona bien

vm-victoria-metrics-single-server-0                    1/1     Running     0          2d18h

Pero no puedo actualizarlo.

$ helm version
version.BuildInfo{Version:"v3.1.2", GitCommit:"d878d4d45863e42fd5cff6743294a11d28a9abce", GitTreeState:"clean", GoVersion:"go1.13.8"}

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-26T06:16:15Z", GoVersion:"go1.14", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.8", GitCommit:"ec6eb119b81be488b030e849b9e64fda4caaf33c", GitTreeState:"clean", BuildDate:"2020-03-12T20:52:22Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}


ismail ~ $ helm list
NAME    NAMESPACE   REVISION    UPDATED                                 STATUS      CHART                                   APP VERSION    
vm      default     1           2020-05-23 16:20:35.243505 +0300 +03    deployed    victoria-metrics-single-0.5.3           1.35.6         

$ helm upgrade vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Error: UPGRADE FAILED: "vm" has no deployed releases


ismail ~ $ helm upgrade --install vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Release "vm" does not exist. Installing it now.
Error: rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: namespace: , name: vm-victoria-metrics-single, existing_kind: policy/v1beta1, Kind=PodSecurityPolicy, new_kind: policy/v1beta1, Kind=PodSecurityPolicy

Confirmo que también sucedió de mi lado

@zodraz El estado de tu timón muestra el motivo de tu error. La versión más reciente no se muestra como fallida, se muestra como "instalación pendiente". Esto implicaría que el proceso que estaba administrando la última actualización se terminó artificialmente antes de que se completara (es decir, antes de que presentara errores o tuviera éxito).

Los encargados del mantenimiento del proyecto decidieron no incluir el estado de instalación pendiente como un estado de error válido para permitir la actualización. (es decir, esto funciona según lo diseñado)

Le sugiero que intente averiguar por qué se cancela la actualización de su casco antes de que finalice. Esa debería ser una situación evitable.

Tengo el mismo problema en el gráfico implementado y el pod funciona bien

vm-victoria-metrics-single-server-0                    1/1     Running     0          2d18h

Pero no puedo actualizarlo.

$ helm version
version.BuildInfo{Version:"v3.1.2", GitCommit:"d878d4d45863e42fd5cff6743294a11d28a9abce", GitTreeState:"clean", GoVersion:"go1.13.8"}

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-26T06:16:15Z", GoVersion:"go1.14", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.8", GitCommit:"ec6eb119b81be488b030e849b9e64fda4caaf33c", GitTreeState:"clean", BuildDate:"2020-03-12T20:52:22Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}


ismail ~ $ helm list
NAME  NAMESPACE   REVISION    UPDATED                                 STATUS      CHART                                   APP VERSION    
vm    default     1           2020-05-23 16:20:35.243505 +0300 +03    deployed    victoria-metrics-single-0.5.3           1.35.6         

$ helm upgrade vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Error: UPGRADE FAILED: "vm" has no deployed releases


ismail ~ $ helm upgrade --install vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Release "vm" does not exist. Installing it now.
Error: rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: namespace: , name: vm-victoria-metrics-single, existing_kind: policy/v1beta1, Kind=PodSecurityPolicy, new_kind: policy/v1beta1, Kind=PodSecurityPolicy

Diré que su problema me deja bastante perplejo. No puedo ver cómo pudo haber sucedido eso dada la salida de registro que tiene. La versión de corrección en 3.2.1 ciertamente no ayudará a su situación, ya que no tiene una versión fallida. Supongo que de alguna manera se eliminaron algunos de los secretos de Kubernetes que contienen la información de lanzamiento del timón. Sugeriría desinstalar completamente la versión y reinstalarla si puede.

Hola @yinzara ,

El caso es que no lo cancele ... Por lo que tengo entendido la tercera vez que lancé (y cometí un error ... porque tuve errores en las implementaciones para que fallara) logré llegar a ese "estado corrupto" .. .

Este estado no es recuperable ... Así que la única forma de solucionarlo es eliminar el gráfico ... Mi trabajo para evitar esto es usar la bandera atómica para siempre retroceder y nunca alcanzar este "estado corrupto" ...

Entiendo la decisión de los mantenedores ... Pero esto lleva a confusión, no hay solución posible en absoluto (si no se borra el gráfico) y bueno, como dije, este estado se alcanzó cuando ocurrieron 3 errores ... sin cancelarlo .. .

De todos modos lección aprendida y haciendo retrocesos a través de la bandera atómica.

Hola @yinzara

Encontré la razón por la que falla.

Configuré el parámetro incorrecto -selfScrapeInterval=10 debería ser server.extraArgs.selfScrapeInterval = 10

Entonces, el problema con - en el parámetro.
¿Quizás el error de timón no fue significativo para este tipo de error de variable?

A falta de uno:

ismail sf $ helm upgrade vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Error: UPGRADE FAILED: "vm" has no deployed releases

Éxito:

ismail sf $ helm upgrade vm vm/victoria-metrics-single --set "server.extraArgs.selfScrapeInterval=10" 
Release "vm" has been upgraded. Happy Helming!
NAME: vm
LAST DEPLOYED: Tue May 26 22:35:15 2020
NAMESPACE: default
STATUS: deployed
REVISION: 3
TEST SUITE: None
NOTES:
TBD

Esto también funciona:

ismail sf $ helm upgrade vm vm/victoria-metrics-single --set "selfScrapeInterval=10" 
Release "vm" has been upgraded. Happy Helming!
NAME: vm
LAST DEPLOYED: Tue May 26 22:37:43 2020
NAMESPACE: default
STATUS: deployed
REVISION: 4
TEST SUITE: None
NOTES:
TBD

Tengo el mismo problema: '(y no puedo usar la purga porque perderé los datos y no puedo hacer eso, sé que este problema está cerrado, pero solo estoy expresando mi dolor.

Tenemos que deshacernos de las versiones de timón, cuando implementamos cargas de trabajo críticas, incluso istioctl de istio abandona el timón por esta razón (supongo). Usamos plantilla de timón .... |

@GloriaPG ¿puedes compartir más información? ¿Cómo está experimentando el mismo problema? Como @yinzara mencionó anteriormente en el hilo, es posible que esté experimentando un caso que # 7652 no soluciona. Sin embargo, necesitamos más información para ayudar antes de llegar a esa conclusión.

Hola @bacongobbler

Estamos usando helm upgrade con las banderas --install y --force :

helm upgrade --install ${PROJECT_NAME} ${CHART_NAME} \
   --namespace $NAMESPACE_NAME \
   --values ${SECRETS} \
   --values ${CONFIG_VALUES} \
   --force \
   --wait \
   --timeout ${MAX_WAIT_SECONDS} || rollback

Desafortunadamente, cuando el lanzamiento está en estado fallido:

$ helm list
NAME                    NAMESPACE   REVISION    UPDATED                                 STATUS      CHART           APP VERSION
PROJECT_NAME                CHART_NAME      136         2020-07-09 14:13:09.192381483 +0000 UTC failed      CHART_NAME-0.1.0

resulta en:

Error: UPGRADE FAILED: "PROJECT_NAME" has no deployed releases
Error: failed to replace object: Deployment.apps "PROJECT_NAME" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"PROJECT_NAME"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable

¿Cómo se puede solucionar? Parece que --force con la bandera --install no funciona

Como este es un entorno de producción, no puedo purgar el lanzamiento y crearlo desde cero :(

Gracias por cualquier sugerencia

Su error parece estar relacionado con https://github.com/kubernetes/client-go/issues/508
No puede cambiar el selector en una implementación. Tendría que anular el despliegue y volver a desplegar.

@yinzara, lo curioso es que no voy a cambiar de selector en mi implementación, todo está funcionando en la versión 9/10. En uno, durante la implementación, algo salió mal, la versión está en estado fallido y no puedo recuperarme de ella de ninguna manera: la implementación en sí está funcionando, los pods se están ejecutando pero ya no puedo modificarlo.

Es un poco contradictorio que después de que el lanzamiento esté en estado fallido, ya no pueda cambiarlo usando helm. Esperaría que la bandera --force me permita reemplazar la implementación completa o forzar la aplicación de cambios, pero no pude encontrar una manera de arreglar la versión existente y trabajar con ella.

Sí, desafortunadamente, esto no parece ser un problema de timón. Algo falló en tu lanzamiento y está en mal estado en Kubernetes. Lo más probable es que el selector esté estropeado o algo no sea como esperabas, pero el error que estás viendo sobre "app-name" no tiene lanzamientos implementados es solo una pista falsa.

Intenté revertir a la versión anterior, el lanzamiento ahora está en estado deployed . Desafortunadamente, no cambia nada, así que creo que la única forma es eliminarlo e implementarlo nuevamente.

Entonces, mi problema particular con esto es fácil de reproducir.

Comience a implementar algo con helm3 (con --atomic y --cleanup-on-fail ), y presione ctrl + c el proceso después de que comience a crear recursos. No se revierte nada, los recursos aún existen y cualquier intento posterior de ejecutar install --upgrade dará como resultado el error "no tiene versiones implementadas".

Este ctrl + c es algo que, en esencia, sucede cuando alguien empuja una nueva confirmación a una rama en nuestro sistema CI mientras ya hay una compilación en ejecución; la actualización del timón se cancelará y luego estará en un estado completamente roto.

¿Hay algo que podamos hacer para solucionarlo después de este punto? Al igual que con muchos otros en este hilo, la eliminación no es una opción.

EDITAR: una vez que esto está roto, helm ls no muestra la versión, helm history muestra en estado pendiente de instalación.

En realidad, no importa. Para aquellos afectados por esto, hay una solución: eliminar el registro del historial de kubernetes manualmente. Está guardado en secreto. Si elimino la entrada del estado pending-install ofensiva, ¡entonces puedo ejecutar con éxito upgrade --install nuevamente!

@AirbornePorcine - ¿Puede explicar los cambios necesarios en kubernetes para eliminar las entradas pendientes de instalación?

@ tarunnarang0201 Helm crea un secreto de kubernetes para cada implementación, en el mismo espacio de nombres en el que implementaste, verás que es del tipo 'helm.sh/release.v1' y se llama algo como 'sh.helm.release.v1.release -nombre.v1 '. Solo tiene que eliminar el secreto más reciente (mire el sufijo 'v1' en el ejemplo, se incrementa para cada implementación), y eso pareció desbloquear las cosas para mí.

@AirbornePorcine ¡gracias!

@AirbornePorcine @ tarunnarang0201 @ ninja- También puedes parchear la etiqueta de estado ... especialmente, si no tienes ninguna versión DESPLEGADA anterior.

Para Helm 3, vea mi comentario en https://github.com/helm/helm/issues/5595#issuecomment -580449247

Para obtener más detalles e instrucciones para Helm 2, consulte mi comentario en https://github.com/helm/helm/issues/5595#issuecomment -575024277

Esta conversación es demasiado larga ... y cada comentario tiene una solución ... ¿cuál es la conclusión?
Hemos estado usando el viejo timón 2.12 y nunca tuvimos problemas, pero ahora con v3.2.4 una implementación fallida anteriormente falla con este error.

Por cierto, estamos usando Terraform y el último proveedor de timones. Entonces, ¿deberíamos usar --force o --replace

@xbmono La conversación es larga porque hay

• Hay bastantes razones por las que su liberación puede llegar a este estado.
• esto también fue posible en Helm 2, y las soluciones que funcionaron allí y en Helm 3 son diferentes.
• Hay diferentes caminos que tomaron los usuarios en este problema para llegar allí.
• Existen diferentes opciones según lo que intente hacer y si está dispuesto a correr el riesgo / tolerar la pérdida de PVC y varias combinaciones posibles de tiempo de inactividad.

Si se encuentra en un error "no tiene lanzamientos implementados", no estoy seguro de que install --replace ni upgrade --install --force lo ayuden por sí solo.

Probablemente solo se pueda dar una sugerencia sensata

• si proporciona helm history para el lanzamiento para que la gente pueda ver lo que ha sucedido
• si comparte la razón original de la falla / lo que hizo para llegar allí, y si siente que se ha abordado el problema original

Mi resumen de posibles opciones

• si no le importan los recursos de k8s existentes o el tiempo de inactividad, helm uninstall && helm install puede ser una opción
• si es la primera vez que se instala un gráfico que falla, probablemente pueda eliminar los metadatos secretos de la versión y helm install nuevamente. Tal vez necesite limpiar los recursos de k8s manualmente si cruft se quedó más allá debido a la falla, dependiendo de si usó --atomic etc.
• Si abandonó una instalación de --wait ed a la mitad y helm history muestra que la última versión está en pending-install , puede eliminar los metadatos secretos de la versión más reciente o parchear el estado de la versión.
• en ciertas otras combinaciones de escenarios, también puede ser posible parchear el estado de upgrade posterior puede continuar, sin embargo, que yo sepa, la mayoría de estos casos se abordaron por # 7653 (para asegurarse de que haya un lanzamiento de deployed en algún lugar del historial al que volver), así que me sorprendería si esto fuera útil ahora.

Dado que este es un problema cerrado, sospecho que hay una causa raíz que sería bueno depurar y documentar en un ticket diferente y más específico de todos modos.

@chadlwilson Gracias por tu respuesta.

helm history no devuelve filas!

Error: release: not found

pero helm list devuelve la implementación fallida

M:\>helm3 list -n cluster171
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS  CHART                           APP VERSION
cluster171      cluster171      1               2020-09-01 04:45:26.108606381 +0000 UTC failed    mychart-prod-0.2.0-alpha.10    1.0

Estamos utilizando Terraform y nuestros entornos se implementan automáticamente cada hora por Jenkins. Con terraform no puedo usar helm upgrade , es lo que está haciendo el proveedor del timón

En el código de terraform, configuré force_update en true , sin suerte y luego configuré replace en true , nuevamente sin suerte

resource "helm_release" "productStack" {
  name = "${var.namespace}"
  namespace = "${var.namespace}"
  chart = "${var.product_stack}"
  force_update = true//"${var.helm_force_update}"
  max_history = 10
  replace = true

  wait = true
  timeout = "${var.timeout_in_seconds}"

}

Entonces me pregunto si tiene que ver con wait=true . Entonces, la razón por la que falló la implementación anterior fue que el clúster no pudo comunicarse con el repositorio de Docker y, por lo tanto, se alcanzó timeout y el estado es failed pero solucionamos el problema y el pods reinició con éxito, ahora obviamente helm delete funciona, pero si tuviera que hacer esto cada vez, mis gerentes ni los desarrolladores estarán felices.

Con helm v2, si la implementación falla y los desarrolladores la arreglan, la siguiente implementación actualizaría la implementación fallida.

M:\>helm3 list -n cluster171
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS  CHART                           APP VERSION
cluster171      cluster171      1               2020-09-01 04:45:26.108606381 +0000 UTC failed    mychart-prod-0.2.0-alpha.10    1.0

El error helm history parece extraño (¿error tipográfico? ¿Espacio de nombres perdido? ¿Versión de timón incorrecta?), Pero dada su revisión 1 en el list arriba, parece que está intentando hacer una primera vez que la instalación de un nuevo gráfico y la primera vez que la instalación ha fallado. Si está intentando desbloquear cosas, probablemente pueda eliminar los metadatos secretos de la versión como se indicó anteriormente o parchear su estado e intentarlo de nuevo. Eso puede indicar que los metadatos están en mal estado desde la perspectiva de Helm o del Helm Terraform Provider, pero no cómo llegaron allí.

En cualquier caso, no tengo problemas para hacer upgrade en implementaciones fallidas por primera vez con Helm 3.2.1 desde que se fusionó # 7653. Es posible que desee volver a verificar la versión específica de Helm que el proveedor está usando realmente. También es posible que tenga que ver con la forma en que el proveedor de Helm Terraform determina el estado del lanzamiento después de una falla install . No tengo ninguna experiencia con ese proveedor, y personalmente no estoy a favor de envolver Helm con otra abstracción declarativa como TF porque lo encuentro aún más opaco cuando las cosas van mal, pero es posible que desee profundizar más allí de todos modos. .

En cualquier caso, como dije anteriormente, si el error en el que está atascado es has no deployed releases después de una implementación fallida por primera vez, no creo que replace ni force es probable que lo ayuden a resucitar la situación sin alguna otra intervención y sería mejor depurarlo más y tener cualquier conversación en otro lugar, ya que ir y venir en este viejo boleto cerrado con 51 participantes no parece tan productivo para todos los involucrados.

No, no hubo ningún error tipográfico. Además, esto sucede independientemente de que sea la primera implementación o más tarde.

Como mencioné, estamos usando la opción --wait para esperar la implementación en Jenkins y luego notificar si la implementación falló o no.

Al parecer, si se alcanza el tiempo de espera y la implementación no se realiza correctamente, helm marcó la implementación como failed y no hay forma de recuperar más que eliminar manualmente esa versión. Y tampoco queremos eliminar la versión automáticamente porque eso da miedo.

Entonces, si eliminamos la opción --wait , helm marcará la implementación como successful independientemente.

Solución alterna:

Ahora encontré otra solución. Para aquellos que tienen el mismo problema y quieren que su automatización funcione bien como solía funcionar antes, aquí está mi solución:

• Eliminar la opción --wait de helm deploy
• Utilice este comando para recuperar la lista de implementación para ese espacio de nombres en el que está implementando: kubectl get deployments -n ${namespace} -o jsonpath='{range .items[*].metadata}{.name}{","}{end}'
• Puede usar split para convertir la lista separada por comas de arriba en una matriz
• Luego, puede ejecutar varios comandos en paralelo (usamos Jenkins, por lo que es fácil de hacer) como kubectl rollout status deployment ${deploymentName} --watch=true --timeout=${timeout} -n ${namespace}
• Si después de timeout , por ejemplo 7m significa 7 minutos, la implementación aún no es exitosa, el comando sale con error
• Problema resuelto.

En realidad, no importa. Para aquellos afectados por esto, hay una solución: eliminar el registro del historial de kubernetes manualmente. Está guardado en secreto. Si elimino la entrada del estado pending-install ofensiva, ¡entonces puedo ejecutar con éxito upgrade --install nuevamente!

Alternativamente, esto funcionó para mí:

helm uninstall {{release name}} -n {{namespace}}

fijado por kubectl -n $namespace delete secret -lstatus=pending-upgrade
Corre ahora timón de nuevo.

No estoy seguro de por qué está cerrado, lo acabo de hacer con el nuevo Helm 3.3.4. Si la instalación inicial falla, la segunda actualización del timón --install --force aún muestra el mismo error. Todas esas soluciones funcionan, pero son manuales , no ayudan cuando lo desea completamente, CI / CD 100% automático donde simplemente puede presionar la solución para activar otra implementación sin hacer una limpieza manualmente.

¿Alguien ha pensado en simplemente agregar una bandera de que esta es la primera versión, por lo que debería ser seguro eliminarla automáticamente? ¿O agregar algo como "--force-delete-on-failure"? Ignorar el problema no ayudará.

@ nick4fake AFIK fue cerrado por PR # 7653. @yinzara podría proporcionar más detalles.

Los encargados del mantenimiento tomaron la decisión de no permitir la sobrescritura de una versión pendiente de actualización. Pero su afirmación de que todas las soluciones alternativas son soluciones alternativas que no funcionan en una canalización de CI / CD no es cierta. La última solución sugerida podría agregarse como un paso de compilación antes de ejecutar la actualización de su timón (tampoco usaría --force en una pipieline CI / CD). Tiene el mismo efecto que lo que ha sugerido, excepto que elimina la versión justo antes de instalar la próxima versión en lugar de inmediatamente después, lo que le permite depurar la causa de la falla.

También utilicé lo siguiente en mi compilación automatizada para desinstalar cualquier versión "pendiente" antes de ejecutar mi comando de actualización (asegúrese de establecer la variable de entorno NS_NAME en el espacio de nombres en el que está implementando):
`` bash

! / usr / bin / env bash

RELEASES = $ (helm list - espacio de nombres $ NS_NAME --pending --output json | jq -r '. [] | Select (.status == "pendiente-instalación") | .name')
Si [[ ! -z "$ LANZAMIENTOS"]]; luego
helm delete - espacio de nombres $ NS_NAME $ RELEASES
fi

@yinzara gracias por el fragmento, es muy útil para quienes encuentran este hilo.

Mi punto sigue siendo válido: no es seguro eliminar simplemente la versión. ¿Por qué Helm no puede forzar el lanzamiento de la actualización si falla un solo recurso? Reemplazar la versión con una nueva versión parece una mejor solución que la eliminación completa. Es posible que no entienda algunos de los fundamentos básicos de Helm (como cómo administra el estado), por lo que es posible que no sea posible hacerlo, pero todavía no entiendo por qué es mejor obligar a los usuarios a intervenir manualmente si falla la primera instalación.

Quiero decir, solo revisa este hilo de discusión, la gente todavía enfrenta el problema. ¿Qué piensas sobre la posibilidad de agregar información adicional al mensaje de error de Helm con un enlace a este hilo + algunas sugerencias sobre qué hacer?

@ nick4fake Creo que estás mezclando "fallido" con "pendiente de instalación".

Los encargados de la biblioteca están de acuerdo contigo sobre las versiones fallidas, por eso aceptaron mi PR.

Una versión "fallida" PUEDE actualizarse. Eso es lo que hizo mi PR. Si una versión falla porque uno de los recursos falló, puede simplemente actualizar esa versión (es decir, actualizar - la instalación también funciona) y no dará el error "app-name" no tiene versiones implementadas.

Estás hablando de una versión "pendiente de instalación". Los mantenedores no creen que sea seguro permitirle actualizar una versión pendiente de instalación (forzada o de otro tipo), ya que posiblemente aún esté en progreso o en un estado parcialmente completo que no creen que pueda resolverse automáticamente. Mi RP originalmente permitió este estado y los mantenedores me pidieron que lo eliminara.

Si encuentra sus versiones en este estado, es posible que desee reconsiderar su configuración de implementación. Esto nunca debería suceder en una canalización de CI / CD correctamente configurada. Debería fallar o tener éxito. "pendiente" implica que la instalación se canceló mientras aún se estaba procesando.

No soy un mantenedor, por lo que mi opinión sobre su sugerencia es irrelevante; sin embargo, no encuentro ninguna mención en la base de código a un problema de Github que esté impreso en un error o mensaje, así que apuesto a que no lo permitirán, pero usted eres bienvenido a armar un PR y ver :-)

Dicho esto, no estoy de acuerdo con su afirmación de que su punto sigue siendo válido. Mi sugerencia puede eliminar la versión pendiente, sin embargo, @abdennour sugerencia justo antes de la suya es simplemente eliminar el secreto que describe la versión de instalación pendiente. Si lo hace, no está eliminando ninguno de los recursos de la versión y puede actualizar la versión.

¿Qué piensas sobre la posibilidad de agregar información adicional al mensaje de error de Helm con un enlace a este hilo + algunas sugerencias sobre qué hacer?

+1 a esto. Todavía tenemos que buscar en Google, para encontrar este hilo, para entender qué es un lanzamiento de pending-install , para que podamos comenzar a razonar sobre este mensaje de error.

Tuve problemas con helm upgrade y me llevó aquí. Se resolvió agregando -n <namespace> . Tal vez ayude a alguien.

Para Helm3, podría resolverse mediante parche
kubectl -n <namespace> patch secret <release-name>.<version> --type=merge -p '{"metadata":{"labels":{"status":"deployed"}}}'

release-name y version - Se puede ver desde kubectl get secrets -n <namespace> | grep helm