Olá - você pode dar mais alguns detalhes sobre como você está implantando? você está usando helm upgrade --install por acaso? E se você fizer isso, qual é o estado da implantação quando ela está interrompida ( helm ls ) - presumivelmente, é Failed ?

Se for esse o caso, um helm delete --purge <deployment> deve resolver o problema.

oi, desculpe por falta de informação.
Sim, estou usando helm upgrade --install
E sim, a implantação permanece em Failed para sempre.
Infelizmente helm delete --purge <deployment> não é uma opção aqui. Não posso simplesmente excluir serviços de produção por causa disso :)

A questão é por que o leme não pode se recuperar após 3 falhas consecutivas.

a única maneira de classificar isso sem excluir o release add --force

--force para quê? para helm upgrade --install ?
e se sim, isso significa que o problema acima é realmente o recurso esperado e devemos usar --force em cada implantação? - em caso afirmativo, isso significa que ele implantará versões interrompidas à força?

sim, claro para helm upgrade --install :)
e sim, você deve usar --force com cada implantação

isso significa que --force implantará versões quebradas à força também? - Quer dizer, se o pod for quebrado e reiniciado o tempo todo, isso excluirá pods antigos e programará novos?
--force force resource update through delete/recreate if needed
qual é a condição delete ? você pode explicar como funciona exatamente? a descrição é definitivamente muito curta para um sinalizador tão crítico - espero que faça milhares de coisas por baixo do capô.

BTW, eu realmente não quero acabar com serviços de produção excluídos, então o sinalizador --force não é uma opção para mim.

e você realmente acha que não é um problema?
até mesmo a mensagem de erro está errada:
app-name has no deployed releases
que afirma que não há versões implantadas
enquanto houver, mas com o estado Failed e o helm nem mesmo tenta consertá-lo :( - por consertar, quero dizer apenas tente implantá-lo, em vez de desistir logo no início

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

Não posso concordar mais. Nossa produção está apresentando o mesmo erro. Portanto, excluir o gráfico não é uma opção e forçar a instalação parece perigoso. Esse erro ainda está presente no Helm 3. Portanto, pode ser bom incluir uma correção ou uma solução alternativa mais segura.

pode ser corrigido removendo "status": "implantado", em storage.go: 136

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

Vou corrigir o Pull Request quando tiver tempo.

O código no local estava originalmente correto. Removendo status: deployed dos resultados da consulta com o Helm encontrando a versão mais recente para atualizar, independentemente do estado em que está atualmente, o que pode levar a resultados indesejados. Ele contorna o problema temporariamente, mas apresenta questões muito maiores no futuro.

Se você puder fornecer a saída de helm history quando encontrar este bug, isso seria útil. É mais útil determinar como terminar em um caso em que o livro de lançamento não tem lançamentos no estado "implantado".

Estou encontrando esse problema ao implantar pela primeira vez em um novo cluster. Devo usar --force também?

Eu encontrei esse problema quando excluí a versão anterior sem usar a opção --purge .

helm delete --purge <release-name>

Versão Helm

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

Eu também estou encontrando esse problema.

@bacongobbler
Eu acertei isso com o helm3. O histórico está completamente vazio quando isso acontece, embora recursos k8s quebrados estejam lá desde a tentativa 1.

A reprodução parece muito fácil:

1. helm upgrade - instalar "algo com um pod que tem um contêiner que sai com erro"
2. corrija o que causou a saída do contêiner, por exemplo, valor com argumento inválido para o executável dentro do contêiner e tente novamente
   -> Erro: FALHA NO UPGRADE: "foo" não tem versões implementadas

Parece que o sinalizador --atomic pode ser um caminho a seguir no meu cenário (CI / CD). Uma vez que ele limpa completamente o lançamento inicial com falha, como se nunca tivesse acontecido, não acerto esse problema na próxima tentativa.

Mesmo aqui, não vejo como usar delete ou --force pode ser aconselhado especialmente quando há volumes persistentes no lugar, eu já perdi todos os painéis de grafana por causa disso uma vez, não estou fazendo isso de novo :)

Atualização: aliás, no meu caso, o lançamento está falhando por causa de:

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

mesmo que eu não tenha mudado nada nos valores da grafana

@ alex88 você pode fornecer a saída de helm history ? Preciso saber como outras pessoas estão lidando com este caso para que possamos tentar descobrir a causa raiz e encontrar uma solução.

@bacongobbler certeza que realmente adoraria ver isso corrigido, pois sou muito cauteloso ao usar o helm por ter perdido volumes persistentes algumas vezes (provavelmente minha culpa, embora)

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

Basicamente, eu tentei várias vezes executar a atualização para alterar algumas variáveis ​​env e como houve o erro de implantação, as variáveis ​​env mudaram de qualquer maneira, continuei fazendo isso ignorando o erro

como você chegou a um estado em que cada versão falhou? Onde está a versão 1, 2 e 3?

como você chegou a um estado em que cada versão falhou? Onde está a versão 1, 2 e 3?

alterando as variáveis ​​env (tive que fazer várias mudanças) e executando uma atualização todas as vezes, estava mudando as variáveis ​​env, mas eu não tinha ideia de como consertar o erro de volume persistente

Atualização: btw estou usando

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

em relação à versão anterior, provavelmente o helm mantém apenas 10 deles

Helm3: Estou tendo um problema semelhante ao atualizar o istio, a versão falhou, agora não posso reimplantá-lo, embora um pequeno erro nos modelos tenha sido corrigido. Não posso excluir a liberação de produção, pois ela também excluirá o ELB associado ao serviço istio-ingress.

Existe algum trabalho futuro para alterar a lógica quando a versão inicial terminar em um estado de falha?

O que devo fazer se o tempo de inatividade não for aceito?

% 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"}

O que devo fazer se o tempo de inatividade não for aceito?

por enquanto, apenas uso o helm para gerar os modelos e os salvo manualmente localmente e aplico

Parece que o sinalizador --atomic pode ser um caminho a seguir no meu cenário (CI / CD). Uma vez que ele limpa completamente o lançamento inicial com falha, como se nunca tivesse acontecido, não acerto esse problema na próxima tentativa.

@ henrikb123 o acima só funciona se você sempre usou a bandeira --atomic . Caso contrário, não funcionará. Por exemplo: tente instalar um gráfico quebrado sem ele e execute o mesmo comando com o sinalizador --atomic . Vai quebrar. Para sua informação, estou usando a versão mais recente do Helm -> 3.0.2

@ alex88 você pode fornecer o resultado do histórico do leme? Preciso saber como outras pessoas estão lidando com este caso para que possamos tentar descobrir a causa raiz e encontrar uma solução.

@bacongobbler por que você simplesmente não faz o que @ henrikb123 disse aqui para simular o problema? Como apontado por @ henrikb123 , o histórico está completamente vazio . Eu posso confirmar isso também. Dê uma olhada, 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

Eu também corri para isso com o Istio.

Há um problema do Istio com 1.4.3, em que um dos jobs executados pela instalação falhará se não puder acessar o servidor da API Kubernetes. Em seguida, ele deixa um trabalho para trás e se você tentar executar novamente o comando Helm, ele falhará porque o trabalho já existe. Tentei excluir o trabalho, ajustar algumas coisas e executar novamente a atualização, mas nunca tive êxito ... e agora estou preso.

(É assim que você pode entrar em um estado de lançamento totalmente falho, já que havia uma dúvida sobre isso.)

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

Isso é com o Helm 3.0.2.

IMO, este é um problema crítico que precisa ser corrigido o mais rápido possível. Eu vi muitos outros problemas semelhantes que estavam abertos para o mesmo problema desde a versão 2 e até agora parece que não foi corrigido.

Eu apenas peço que os desenvolvedores façam exatamente o que @ henrikb123 disse em seu comentário para simular este problema. É uma forma muito simples de simular. Você pode testá-lo com qualquer versão do Helm (2.xx e 3.xx). Tenho quase certeza de que isso ocorrerá com todos eles.

Talvez --atomic deva ser um requisito rígido (não um argumento de linha de comando). É até mesmo redundante como --cleanup-on-fail . A diferença é que --cleanup-on-fail não corrigiu esse problema como --atomic fez.

Também acabamos de encontrar isso na produção e o tempo de inatividade não é uma opção. Encontramos uma solução alternativa apenas corrigindo o último configmap FAILED para ter o rótulo STATUS: DEPLOYED usando um comando como ...

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

Em nosso caso, tínhamos certeza de que a última revisão FALHA foi, na verdade, implantada com sucesso pelo kubernetes.

Como chegamos nesse estado?

Basicamente, nossa equipe de desenvolvimento ignorou as atualizações com FALHA porque o Kubernetes ainda estava fazendo as modificações após o tempo limite do helm.

Especificamente, estamos usando o Helm 2 e definimos TILLER_HISTORY_MAX=20 na implantação do timão. Estávamos usando helm upgrade --wait --timeout 1080 para todas as nossas atualizações RollingUpdate que estavam demorando mais. Em seguida, as atualizações do leme começaram a expirar, mas ninguém ficou alarmado (apenas irritado) porque o Kubernetes ainda estava fazendo as modificações com sucesso. Após o tempo limite de 20 atualizações expirar (hoje), ficamos alarmados porque não podíamos mais implementar porque, em vez disso, estávamos vendo app-name has no deployed releases .

Por que o patch funciona?

Descobrimos que só precisávamos corrigir o rótulo STATUS no configmap porque percebemos que o Helm provavelmente estava solicitando configmaps usando uma solicitação semelhante a ...

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

A pista foi encontrada quando vimos o configmap yaml e notamos os seguintes rótulos ...

$ 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...

E isso é consistente com https://github.com/helm/helm/issues/5595#issuecomment -552743196

@bacongobbler em vez de se perguntar como você entrou em um estado de falha, você deve considerar uma solução valiosa para atualizar uma instalação com falha, que ... não deve falhar.

Mas, na verdade, para responder às suas preocupações: um tempo limite é um bom motivo para um lançamento malsucedido. A versão também travará e não poderá ser revertida ao atualizar e atingir o tempo limite.

Assim, tendo volumes criados dinamicamente pelas reivindicações. Ao excluir as reivindicações (excluindo um gráfico), os volumes também são muitos outros desenvolvedores estamos presos por meses e tentando contornar isso.

Você não gostou da ideia de remover status: deployed da consulta. Então, que tal adicionar um novo rótulo que realmente marca o lançamento mais recente, não importa se seu status foi implantado ou falhou? Isso realmente faria sentido. Porque é isso que você deseja fazer, você deseja obter a versão mais recente para atualizar. E se não houver nenhum, você provavelmente deve verificar se há versões com falha. Ou apenas use um novo rótulo que marque o mais recente diretamente.

_Estou animado em ouvir sua opinião sobre isso._

Colocação perfeita @AmazingTurtle.

Não tenho certeza se isso já foi observado, mas esse problema também surge se a primeira instalação de um gráfico falhar por qualquer motivo (o que é uma ocorrência muito comum, especialmente para usuários de gráfico pela primeira vez que podem precisar iterar em seus configuração para fazer as coisas funcionarem).

Acredito que a única solução alternativa para os usuários da CLI neste caso é excluir o segredo de rastreamento de versão se estiver usando o driver secrets, bem como todos os recursos que foram criados pela última versão (para evitar a execução de verificações de propriedade de recursos do Helm).

Esta é uma função real de uma ferramenta que escrevi internamente para lidar com esse problema quando ele surgir:

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 Usar helm delete --purge (v2) ou helm uninstall (v3) também funcionaria, já que são todas versões com falha?

O que foi apontado por @jlegrone é verdade.
@hickeyma, sua proposta é uma solução alternativa que pode funcionar. Mas, preciso de uma solução definitiva.

é um bug prejudicial nos últimos 2 anos e o helm não vai consertá-lo
helm delete não é aceitável na maioria dos casos de produção
com helm3 não podemos kubectl edit secret sh.helm.release.... porque está criptografado
helm rollback <latest-successful> é apenas uma solução alternativa correta

então se você tem por padrão HISTORY_MAX = 10 e você tentou 10 vezes para fazer algo funcionar - você está completamente perdido ...

e se você tiver alguma lógica na instalação vs atualização, você não pode excluir sh.helm.release ..... v * secrets

leme deve morrer ou consertar

solução alternativa encontrada
helm3 define rótulos em seus segredos:
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
...

então faça para o último kubectl edit secret sh.helm.release.v1.helm-must-die.v36 e defina o status do rótulo = implantado
e para o lançamento antes dele (v35) definir status do rótulo = substituído

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

@ kosta709 Semelhante à minha descoberta para Helm2, que armazena releases como ConfigMaps no namespace do sistema kube com rótulos que são todos CAPS, Helm3 agora armazena releases como Secrets no namespace do aplicativo com rótulos todos minúsculos.

Portanto, para Helm3, você pode apenas usar um comando kubectl patch ligeiramente diferente ...

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

Eu gostaria que não tivéssemos que discutir essas soluções alternativas. Consertar isso no produto deve ser prioridade. Um lembrete de como isso é ruim (desconsiderando as soluções alternativas):

Se uma versão falhou na primeira vez que foi implementada OU se versões suficientes falharam em girar o último sucesso do histórico, a versão não pode ser corrigida sem intervenção manual.

Dado que o uso do Helm a partir de um pipeline de implantação contínua é provavelmente um padrão comum ou pelo menos desejado, isso não é viável.

Eu concordo totalmente, mas pelo menos queria documentar claramente a solução alternativa, porque quando você entra nesse estado, parece que não há outra opção a não ser abandonar a liberação e fazer uma paralisação.

Junto com os patches para evitar interrupções, também paramos de usar helm --wait e, em vez disso, contamos com nossa própria lógica de pesquisa para saber quando o lançamento foi bem-sucedido ou não. É mais trabalhoso, mas agora temos muito mais visibilidade, o que é útil quando uma versão está demorando mais do que o esperado e podemos detectar falhas antes do tempo limite.

Isso não era um problema para mim nas versões mais antigas do helm e não há implantações com falha, o kubectl está mostrando serviços em execução e tudo está funcionando.

Agora estou simplesmente tentando executar helm upgrade -f app.yaml --namespace prometheus prometheus prometheus e recebo o erro: Error: UPGRADE FAILED: "prometheus" has no deployed releases mas não posso tentar nenhuma das soluções alternativas porque isso está em produção ...

@zrsm, o que estamos fazendo agora é gerar os arquivos yaml usando o helm e usando kubectl diff / dry-run para visualizar as alterações antes de aplicá-las manualmente

@zrsm, o que estamos fazendo agora é gerar os arquivos yaml usando o helm e usando kubectl diff / dry-run para visualizar as alterações antes de aplicá-las manualmente

Obrigado pela resposta, fiz downgrade para 2.15.1, mas encontrei problemas semelhantes, no entanto, tentei algo como excluir meu ~ / .helm e reiniciei a conta de serviço do tiller do kubectl, depois de fazer isso, fui capaz de aplicar gráficos aos kubernetes . Vou tentar testar isso com o helm 3 mais tarde hoje e responder com uma correção. Tenho a sensação de que esse pode ter sido o problema.

Olá, eu testei isso ... e parece que estou executando o seguinte comando depois de excluir também meu ~ / .helm / resolvido ...

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 -

Estou pensando que se você instalar uma nova edição do leme e seu material de conta de serviço não estiver localizado (limpei meu laptop e restaurei em algum momento), isso acontece e esta foi a solução. Espero que funcione para você também.

Este bug está em andamento no Helm 3. Existe uma correção planejada?

Também enfrentando esse problema com um novo cluster e uma nova implantação devido a um tempo limite. Não gosto de me conectar manualmente ao nosso cluster para consertar isso, mas acho que essa é a única opção agora.

Podemos garantir que esse problema seja resolvido o mais rápido possível?

este problema é tão frustrante que é uma razão para parar de usar helm completamente.

Eu concordo. Isso está me deixando louco. Vou trabalhar para consertá-lo. Me deseje sorte.

Eu concordo. Isso está me deixando louco. Vou trabalhar para consertá-lo. Me deseje sorte.

obrigado e boa sorte!

Eu não me importaria que alguns de vocês olhassem para PR # 7653.

Acredito que isso resolverá os problemas descritos acima.

Não posso acreditar que ainda está aberto sem reação dos mantenedores

cc @bacongobbler @mattfarina

O uso do helm delete --purge (v2) ou helm uninstall (v3) também funcionaria, visto que são versões com falha?

@hickeyma nem sempre; isso também pode ser o resultado da corrupção de metadados de liberação do helm, portanto, em alguns casos, a desinstalação pode excluir recursos sob carga.

às vezes, o lançamento não falhou, mas o tempo limite e o leme o rotulam como com falha e, da próxima vez, ele mostra que não tem lançamento implantado, mas o aplicativo está totalmente funcional, isso aconteceu comigo muitas vezes, então tive que alterar o lançamento etiqueta para deployed one. nem sempre é uma opção fazer helm delete --purge (v2) or helm uninstall (v3)

@rimusz, como você está mudando o selo de lançamento?

@dudicoco editando manualmente o segredo do último lançamento do helm v3, você pode automatizar isso e usar kubectl patch

mudaram para https://github.com/k14s/kapp que funciona perfeitamente.

@rimusz foi o que pensei, obrigado.

Eu também retrocedi minha correção para o leme 2 no # 7668, mas ainda estou aguardando feedback no # 7653

Mesmo problema aqui,

Uma versão implantada com --wait atingiu o tempo limite e, finalmente, está funcionando. Ainda está marcado como falho.
E, portanto, implantações posteriores também estão falhando.

Isso significa que o status de liberação não é uma informação confiável.

Usamos k8s em nossa empresa para muitos serviços de produção.
Algumas vezes em um mês, temos os mesmos problemas com o helm em aplicativos diferentes (" * não tem versões implantadas.").
Usamos diferentes versões do leme (de 2.7 a 3.0.3).
O problema não está resolvido.
Isso causa muito desconforto para nossos usuários (desenvolvedores que implantam aplicativos em cluster)
Cada vez, quando o atingimos, apenas corrigimos o segredo do lançamento mais recente (status para implantado).
Existe algum plano para adicionar um comportamento que ignora o estado dos últimos lançamentos e instala novos lançamentos?

Tendo --history-max definido como 10 (valor padrão), o primeiro lançamento foi bem-sucedido.
Então, os próximos 10 lançamentos falharam em:
Error: UPGRADE FAILED: timed out waiting for the condition (Foi simulado, portanto esperado).
Depois disso, o próximo lançamento (falha 11) falhou em:
Error: UPGRADE FAILED: "app" has no deployed releases (esse é o problema!)

Seria possível que o helm sempre preservasse o último lançamento

Eu amo a ideia Precisaria modificar a funcionalidade de armazenamento, mas acho que poderia ser feito.

https://github.com/helm/helm/pull/4978 foi mesclado para o Helm 2. Talvez não tenha sido transferido para o Helm 3. Se alguém tiver tempo e quiser transferi-lo, sinta-se à vontade.

Tentei portar isso para o Helm 3 com o # 7806 e adoraria vê-lo mesclado o mais rápido possível. Obrigado, @ultimateboy!

E quanto às versões que falham na _primeira_ instalação, ou seja, não têm versões anteriores bem-sucedidas?
Estamos usando upgrade --install para implantação idempotente de versões do helm e quando a primeira versão falha, todas as invocações subsequentes de upgrade --install falham com o erro "não tem versões implantadas" (este problema).

O cenário de "falha na primeira versão" é pelo menos mais gerenciável, porque você geralmente executa ou monitora manualmente (e pode aplicar uma correção na hora) - ao contrário de ter o leme executado por um sistema CI / CD que simplesmente começa a falhar. dia e não se recupera mesmo depois de corrigir o código.

Ainda deve ser consertado, é claro.

Também há valor em preservar a última versão bem-sucedida de qualquer maneira, não apenas por causa desse bug. Por exemplo, problemas de depuração com arquivo de valores, etc.

@peterholak O cenário de "falha no primeiro lançamento" às vezes também é feito com um CI / CD e, por exemplo - restringimos o acesso ao nosso cluster e não podemos nem fazer um "comando", como podemos "gerenciar isso"?

Esse problema deve ser de alta prioridade, visto que a maioria das pessoas usa o leme na produção. Eu poderia executar a instalação do helm com --atomic , mas e se eu quiser inspecionar o motivo da falha antes da implantação? Eu ficaria paralisado pelo tempo limite antes que a instalação falhasse e depois fosse revertida. Se eu puder atualizar com sucesso, não terei que perder tempo ao inspecionar a falha.

Também estamos usando upgrade --install para implantação idempotente de versões do helm. Porque é assim que os pipelines ci / cd automatizados funcionam. Não planejamos mexer manualmente com o leme porque isso contornaria nosso pipeline de implantação.

Em um pipeline de implantação automatizado, a primeira implantação quase sempre falhará. As implantações subsequentes não devem ser disparadas de maneira diferente da primeira tentativa.

Considere aumentar consideravelmente a prioridade desse problema.

A experiência é tããããão ruim, não podemos simplesmente deletar todo o lançamento, porque está em produção! Isso causará o tempo de inatividade do servidor! Como podemos lidar com esse problema no final?

Além disso, alguém pode remover o rótulo de pergunta / suporte? Esse problema não é sobre a falta de documentação, mas sobre o comportamento atual do Helm, que não é muito favorável ao uso em pipelines de implantação automatizados.

O # 7806 PR foi mesclado com o master. Ele será lançado em 3.2. Estou encerrando este assunto de acordo.

Excelente! Isso resolve a maioria dos nossos problemas com o Helm.

Qual é o comportamento atual se a primeira versão falhar (nenhuma versão implantada ainda)?

Houve https://github.com/helm/helm/issues/3353 que foi abordado por https://github.com/helm/helm/pull/3597, mas apenas quando --force é usado.

--force tem alguns problemas no Helm 3 embora (https://github.com/helm/helm/issues/6378), com uma proposta para resolvê-lo (https://github.com/helm/helm/ questões / 7082), além de outros comentários neste tópico mencionado, usar --force nem sempre é adequado de qualquer maneira. Portanto, toda a situação ainda não está clara.

@technosophos obrigado pela correção. Curioso, quando seria 3.2. versão disponível para instalação? Continue recebendo app-name has no deployed releases erro em uma versão com falha existente. E é uma espécie de bloqueador em pipelines de CI / CD.

@peterholak veja # 7913.

3.2 será discutido na chamada pública de desenvolvimento de 16 de abril. Eu fiz a triagem apenas para aqueles que atualmente parecem que podem ser embrulhados imediatamente. Em seguida, iniciaremos o processo de lançamento do beta (assumindo que todos os mantenedores concordem com a ligação amanhã).

Eu estava enfrentando o mesmo problema na solução AKS para corrigir o problema mencionado com o seguinte comando:

helm version : 3.1.2
Acabei de deletar o pacote do cluster k8s com o comando
helm delete <release-name>

e execute o ciclo de implantação para corrigir o problema

O problema ainda está lá na versão 3.2.0

@deimosfr Isso foi corrigido no # 7653, que estará na versão 3.2.1. Ainda não foi lançado, mas você pode obter a correção se quiser construir a partir do mestre.

Estou no 3.2.1 e isso ainda está acontecendo

Ainda existem razões pelas quais este erro pode ocorrer. 3.2.1 não removeu simplesmente o erro. Ele removeu algumas das causas. Se ainda estiver tendo isso, o problema é diferente do que foi corrigido.

@yinzara Eu tenho um caso clássico de "caminho b" da descrição original em um novo cluster sem problemas. Também posso reproduzir esse erro em outro cluster onde o Helm v2 funciona bem. Podemos, é claro, fazer a dança clássica "isso é causado por outra coisa, abrir um novo problema", mas acho que será mais rápido se for simplesmente reconhecido que não está realmente consertado.

Qual é o resultado de helm list ? Qual é o "status" da versão anterior com falha? O Helm 2 tem esse problema e ele não foi corrigido, então ainda acho que seu problema não é o que você pensa.

Ainda acontece na versão 3.2.1.

Se a implantação inicial falhar 3 vezes, tudo ficará travado ... Não há como consertar se você não excluir o gráfico e implantar um bom.

Detalhes:

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

Tenho o mesmo problema no gráfico implantado e o pod está funcionando bem

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

Mas não posso atualizá-lo.

$ 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

Eu confirmo que aconteceu do meu lado também

@zodraz Seu status de leme mostra o motivo do seu erro. A versão mais recente não é exibida como falha, mas como "instalação pendente". Isso implicaria que o processo que estava gerenciando a última atualização foi finalizado artificialmente antes de ser concluído (ou seja, antes de ocorrer um erro ou ser bem-sucedido).

Foi decisão dos mantenedores do projeto não incluir o status de instalação pendente como um status de erro válido para permitir a atualização. (ou seja, está funcionando conforme o planejado)

Eu sugiro que você tente verificar por que sua atualização de leme está sendo cancelada antes de terminar. Essa deve ser uma situação evitável.

Tenho o mesmo problema no gráfico implantado e o pod está funcionando bem

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

Mas não posso atualizá-lo.

$ 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

Direi que seu problema é bastante desconcertante para mim. Não consigo ver como isso pode ter acontecido, dada a saída de log que você tem. A versão de correção no 3.2.1 certamente não ajudará em sua situação, pois você não tem uma versão com falha. Eu acho que de alguma forma alguns dos segredos foram removidos do Kubernetes que contém as informações de lançamento do leme. Eu sugeriria desinstalar completamente o lançamento e reinstalar, se possível.

Olá @yinzara ,

Acontece que não cancelei ... Pelo que entendi a terceira vez que lancei (e errei ... pois tive erros nas implantações para fazer falhar) consegui chegar naquele "estado corrompido" .. .

Este estado não é recuperável ... Portanto, a única maneira de consertá-lo é excluir o gráfico ... Minha solução para evitar isso é usar o sinalizador atômico para sempre reverter e nunca atingir esse "estado corrompido" ...

Eu entendo a decisão dos mantenedores ... Mas isso leva a confusão, nenhuma solução possível (senão deletar o gráfico) e bem, como eu disse este estado foi alcançado quando aconteceram 3 erros ... sem cancelá-lo .. .

Enfim lição aprendida e fazendo rollbacks através do flag atômico.

Oi @yinzara

Eu encontrei a razão pela qual ele falha.

Defini o parâmetro errado -selfScrapeInterval=10 ele deve ser server.extraArgs.selfScrapeInterval = 10

Portanto, o problema com - no parâmetro.
Talvez o erro de leme não fosse significativo para este tipo de erro de variável?

Falhando um:

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

Sucesso:

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

Isso também 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

Tenho o mesmo problema: '(e não posso usar a purga porque vou perder os dados e não posso fazer isso, sei que este problema está encerrado, mas apenas estou expressando minha dor.

Temos que nos livrar dos lançamentos de leme, quando implantamos cargas de trabalho críticas, mesmo istioctl de istio vala o leme por esse motivo (presumo). Usamos modelo de leme .... |

@GloriaPG você pode compartilhar mais informações? Como você está enfrentando o mesmo problema? Como @yinzara mencionou anteriormente no tópico, você pode estar enfrentando um caso que o # 7652 não corrige. Precisamos de mais informações para ajudar antes de podermos chegar a essa conclusão, no entanto.

Oi @bacongobbler

Estamos usando helm upgrade com --install e --force sinalizadores:

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

Infelizmente, quando a liberação está em estado de falha:

$ 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 em:

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

Como isso pode ser resolvido? Parece que --force com a bandeira --install não está funcionando

Como este é um ambiente de produção, não posso simplesmente limpar a versão e criá-la do zero :(

Obrigado por qualquer sugestão

Seu erro parece estar relacionado a https://github.com/kubernetes/client-go/issues/508
Você não pode alterar o seletor em uma implantação. Você teria que desimplantar e reimplantar.

@yinzara o engraçado é que não estou mudando o seletor na minha implantação, tudo está funcionando no lançamento de 9/10. Em um durante a implantação, o sth deu errado, a liberação está em estado de falha e não consigo me recuperar de nenhuma forma - a implantação em si está funcionando, os pods estão em execução, mas não consigo mais modificá-la.

É um pouco contra-intuitivo que, após o lançamento estar em um estado de falha, eu não seja capaz de alterá-lo mais usando o helm. Eu esperaria que a sinalização --force me permitiria substituir toda a implantação ou forçar a aplicação de alterações, mas não consegui encontrar uma maneira de corrigir a versão existente e trabalhar com ela.

Sim, infelizmente isso não parece ser um problema de leme. Algo falhou em sua versão e está em um estado ruim no kubernetes. É mais do que provável que o seletor esteja bagunçado ou algo não esteja como você esperava, mas o erro que você está vendo sobre "app-name" não tem versões implantadas é apenas uma pista falsa.

Eu tentei reverter para a versão anterior, a versão agora está no status deployed . Infelizmente, isso não muda nada, então acho que a única maneira é deletar e implantar novamente, infelizmente.

Portanto, meu problema específico com isso é fácil de reproduzir.

Comece implantando algo com helm3 (com --atomic e --cleanup-on-fail ) e pressione Ctrl + C o processo depois que ele começar a criar recursos. Nada é revertido, os recursos ainda existem e quaisquer tentativas subsequentes de executar install --upgrade resultam no erro "não tem versões implantadas".

Este ctrl + c é algo que basicamente acontece quando alguém envia um novo commit para um branch em nosso sistema de CI enquanto já há uma compilação em execução - a atualização do leme será cancelada e, em seguida, estará em um estado completamente quebrado.

Existe algo que podemos fazer para consertar após este ponto? Como acontece com muitos outros neste tópico, a exclusão não é uma opção.

EDITAR: uma vez quebrado, helm ls não mostra o lançamento, helm history mostra em estado de instalação pendente.

Na verdade - deixa pra lá. Para aqueles afetados por isso, há uma solução: exclua o registro de histórico do kubernetes manualmente. Está guardado como segredo. Se eu deletar a entrada do estado pending-install ofensiva, poderei executar upgrade --install novamente com sucesso!

@AirbornePorcine - você pode explicar melhor as mudanças necessárias no kubernetes para excluir as entradas de instalação pendente.

@ tarunnarang0201 O Helm cria um segredo do kubernetes para cada implantação, no mesmo namespace em que você implantou, você verá que é do tipo 'helm.sh/release.v1' e denominado algo como 'sh.helm.release.v1.release -name.v1 '. Você apenas tem que deletar o segredo mais recente (veja o sufixo 'v1' no exemplo, ele é incrementado para cada implantação), e isso pareceu desbloquear as coisas para mim.

@AirbornePorcine obrigado!

@AirbornePorcine @ tarunnarang0201 @ ninja- Você também pode apenas corrigir o rótulo de status ... especialmente, se você não tiver nenhuma versão anterior IMPLICADA.

Para Helm 3, veja meu comentário em https://github.com/helm/helm/issues/5595#issuecomment -580449247

Para obter mais detalhes e instruções para o Helm 2, consulte meu comentário em https://github.com/helm/helm/issues/5595#issuecomment -575024277

Essa conversa é muito longa ... e cada comentário tem uma solução ... qual é a conclusão?
Usamos o antigo helm 2.12 e nunca tivemos problemas, mas agora com a v3.2.4, uma implantação com falha anterior falha com este erro.

A propósito, estamos usando o Terraform e o mais recente provedor de leme. Portanto, devemos usar --force ou --replace

@xbmono A conversa é longa porque há

• há vários motivos pelos quais sua liberação pode chegar a esse estado
• isso também foi possível no Helm 2, e as soluções que funcionaram lá e no Helm 3 são diferentes.
• existem diferentes caminhos que os usuários neste problema seguiram para chegar lá
• existem diferentes opções dependendo do que você está tentando fazer e se você está disposto a arriscar / tolerar a perda de PVCs e várias combinações possíveis de tempo de inatividade.

Se você estiver em um erro "não tem versões implantadas", não tenho certeza se install --replace nem upgrade --install --force irão ajudá-lo por conta própria.

Uma sugestão sensata provavelmente só pode ser dada

• se você fornecer helm history pelo lançamento para que as pessoas possam ver o que aconteceu
• se você compartilha o motivo original da falha / o que você fez para chegar lá - e se você acha que o problema original foi resolvido

Meu resumo das opções possíveis

• se você não se importa com os recursos k8s existentes ou com o tempo de inatividade, helm uninstall && helm install pode ser uma opção
• se for a primeira vez que a instalação do gráfico falhou, você provavelmente pode apenas excluir os metadados secretos do lançamento e helm install novamente. Talvez seja necessário limpar os recursos do k8s manualmente se o lixo foi deixado além devido à falha, dependendo se você usou --atomic etc.
• se você abandonou uma instalação de --wait ed no meio e o helm history mostra que a última versão está em pending-install você pode excluir os metadados secretos da versão mais recente ou corrigir o status da versão
• em algumas outras combinações de cenários, também pode ser possível corrigir o status de upgrade subsequente pode prosseguir, no entanto, que eu saiba, a maioria desses casos foi resolvida por # 7653 (para garantir que haja uma liberação de deployed em algum lugar da história para a qual retornar), então eu ficaria surpreso se isso fosse útil agora.

Como esse é um problema fechado, suspeito que haja uma causa raiz que seria bom depurar e documentar em um tíquete diferente e mais específico.

@chadlwilson Obrigado pela sua resposta.

helm history não retorna nenhuma linha!

Error: release: not found

mas helm list retorna a implantação com falha

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 usando o Terraform e nossos ambientes são implantados a cada hora automaticamente pelo Jenkins. Com o terraform não posso usar helm upgrade , é o que o fornecedor do leme está fazendo

No código da terraform, eu defini force_update para true , sem sorte e eu defini replace para true , novamente sem sorte

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

}

Então eu me pergunto se isso tem a ver com wait=true ? Portanto, o motivo da falha da implantação anterior foi que o cluster não foi capaz de se comunicar com o repositório docker e então timeout atingiu e o status é failed mas corrigimos o problema e o pods reiniciado com sucesso, agora obviamente helm delete funciona, mas se eu fizer isso todas as vezes, meus gerentes e desenvolvedores ficarão felizes.

Com o helm v2, se a implantação falhar e os desenvolvedores corrigirem, a próxima implantação atualizará a implantação com falha.

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

A falha de helm history parece estranha (erro de digitação? Espaço de nomes perdido? Versão do helm errada?), Mas dada sua revisão 1 no list acima, parece que você está tentando fazer uma primeira vez que a instalação de um novo gráfico e a primeira vez que a instalação falhou. Se você está tentando desbloquear coisas, provavelmente pode excluir os metadados do segredo do lançamento como acima ou corrigir seu status e tentar novamente. Isso pode indicar que os metadados estão em um estado incorreto da perspectiva do Helm ou do provedor Helm Terraform, mas não como eles chegaram lá.

Em qualquer caso, não tenho problemas ao fazer upgrade em implantações iniciais com falha com Helm 3.2.1 desde que # 7653 foi mesclado. Você pode querer verificar a versão específica do Helm que o provedor está realmente usando. Também é possível que tenha a ver com a maneira como o provedor do Helm Terraform calcula o estado da versão após uma falha de install . Não tenho nenhuma experiência com esse provedor e, pessoalmente, não sou a favor de envolver o Helm com outra abstração declarativa, como TF, porque acho ainda mais opaco quando as coisas dão errado, mas você pode querer ir mais longe do mesmo jeito .

Em qualquer caso, como eu disse acima, se o erro em que você está preso for has no deployed releases após uma implantação com falha na primeira vez, não acho que replace nem force provavelmente irão ajudá-lo a ressuscitar a situação sem alguma outra intervenção e seria melhor depurá-la ainda mais e ter alguma conversa em outro lugar, pois ir e voltar neste velho tíquete fechado com 51 participantes não parece tão produtivo para todos os envolvidos.

Não, não houve erro de digitação. Além disso, isso acontece independentemente de ser a primeira implantação ou posterior.

Como mencionei, estamos usando a opção --wait para aguardar a implantação no Jenkins e, em seguida, notificar se a implantação falhou ou não.

Parece que, se o tempo limite for atingido e a implantação não for bem-sucedida, helm marcou a implantação como failed e não há outra maneira de recuperar a não ser excluir manualmente essa versão. E não queremos excluir o lançamento automaticamente porque isso é assustador.

Portanto, se removermos a opção --wait , helm marcará a implantação como successful independentemente.

Gambiarra:

Agora encontrei outra solução. Para aqueles que têm o mesmo problema e desejam que sua automação funcione bem como funcionava antes, aqui está minha solução alternativa:

• Remova a opção --wait de helm deploy
• Use este comando para recuperar a lista de implantação para o namespace que você está implantando: kubectl get deployments -n ${namespace} -o jsonpath='{range .items[*].metadata}{.name}{","}{end}'
• Você pode usar split para transformar a lista separada por vírgulas acima em uma matriz
• Em seguida, você pode executar vários comandos em paralelo (usamos Jenkins, por isso é fácil de fazer) como kubectl rollout status deployment ${deploymentName} --watch=true --timeout=${timeout} -n ${namespace}
• Se após timeout , por exemplo 7m significa 7 minutos, a implantação ainda não foi bem-sucedida, o comando sai com erro
• Problema resolvido.

Na verdade - deixa pra lá. Para aqueles afetados por isso, há uma solução: exclua o registro de histórico do kubernetes manualmente. Está guardado como segredo. Se eu deletar a entrada do estado pending-install ofensiva, poderei executar upgrade --install novamente com sucesso!

Alternativamente, isso funcionou para mim:

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

corrigido por kubectl -n $namespace delete secret -lstatus=pending-upgrade
Execute agora o leme novamente.

Não tenho certeza de por que ele está fechado, acabei de fazer isso com o novo Helm 3.3.4. Se a instalação inicial falhar, a segunda atualização do helm --install --force ainda mostra o mesmo erro. Todas essas soluções alternativas funcionam, mas são manuais e não ajudam quando você deseja CI / CD 100% automático, onde você pode simplesmente enviar a correção para acionar outra implantação sem fazer a limpeza manualmente.

Alguém já pensou em simplesmente adicionar um sinalizador de que esta é a primeira versão, então deve ser seguro excluí-la automaticamente? Ou adicionar algo como "--force-delete-on-fail"? Ignorar o problema não vai ajudar.

@ nick4fake AFIK foi fechado por PR # 7653. @yinzara pode fornecer mais detalhes.

Foi uma decisão dos mantenedores de não permitir a substituição de uma versão de atualização pendente. Mas sua afirmação de que todas as soluções alternativas são soluções alternativas que não funcionam em um pipeline de CI / CD não é verdadeira. A última solução alternativa sugerida pode ser adicionada como uma etapa de construção antes de executar a atualização do leme (eu também não usaria --force em um pipieline de CI / CD). Ele tem o mesmo efeito que o que você sugeriu, exceto que exclui a versão antes de instalar a próxima versão, em vez de imediatamente depois, permitindo que você depure a causa da falha.

Também usei o seguinte em minha compilação automatizada para desinstalar qualquer versão "pendente" antes de executar meu comando de atualização (certifique-se de definir a variável de ambiente NS_NAME para o namespace em que você está implantando):
`` `bash

! / usr / bin / env bash

RELEASES = $ (lista do helm --namespace $ NS_NAME --pending --output json | jq -r '. [] | Select (.status == "instalação pendente") | .name')
E se [[ ! -z "$ RELEASES"]]; então
helm delete --namespace $ NS_NAME $ RELEASES
fi

@yinzara obrigado pelo snippet, é muito útil para aqueles que estão encontrando este tópico.

Meu ponto ainda é válido - não é seguro simplesmente excluir a liberação. Por que o Helm não pode forçar a liberação de atualização se um único recurso falhar? Substituir a liberação por uma nova versão parece uma solução melhor do que a exclusão completa. Posso não entender alguns fundamentos básicos do Helm (como como ele gerencia o estado), então talvez não seja possível fazer, mas ainda não entendo por que é melhor forçar os usuários a intervir manualmente se a primeira instalação falhar.

Quero dizer, basta verificar este tópico de discussão, as pessoas ainda enfrentam o problema. O que você acha sobre a possibilidade de adicionar algumas informações adicionais à mensagem de erro do Helm com link para este tópico + algumas sugestões sobre o que fazer?

@ nick4fake Acho que você está

Os mantenedores da biblioteca concordam com você sobre lançamentos fracassados, é por isso que aceitaram meu PR.

Uma versão "com falha" PODE ser atualizada. Isso é o que meu PR fez. Se uma versão falhar porque um dos recursos falhou, você pode apenas atualizar essa versão (ou seja, atualizar - instalar também funciona) e não fornecerá o "app-name" sem erro de versões implantadas.

Você está falando sobre uma versão de "instalação pendente". Os mantenedores não acham que seja seguro permitir que você atualize uma versão com instalação pendente (forçada ou não), pois ela pode estar em andamento ou em um estado parcialmente completo que eles acham que não pode ser resolvido automaticamente. Meu PR originalmente permitiu este estado e os mantenedores me pediram para removê-lo.

Se você encontrar seus lançamentos neste estado, você pode querer reconsiderar sua configuração de implantação. Isso nunca deve acontecer em um pipeline de CI / CD configurado corretamente. Deve falhar ou ter sucesso. "pendente" significa que a instalação foi cancelada enquanto ainda estava em processamento.

Eu não sou um mantenedor, então minha opinião sobre sua sugestão é irrelevante, no entanto, não encontro nenhuma menção na base de código a um problema do Github que esteja realmente impresso em um erro ou mensagem, então aposto que eles não permitirão isso, mas você seja bem-vindo para montar um PR e ver :-)

Dito isso, não concordo com sua afirmação de que seu ponto ainda é válido. Minha sugestão pode remover o lançamento pendente, no entanto, a sugestão @abdennour logo antes da sua é apenas deletar o segredo que descreve o lançamento de instalação pendente. Se você fizer isso, não estará excluindo nenhum dos recursos da versão e poderá atualizá-la.

O que você acha sobre a possibilidade de adicionar algumas informações adicionais à mensagem de erro do Helm com link para este tópico + algumas sugestões sobre o que fazer?

+1 para isso. Ainda temos que pesquisar no Google para encontrar este tópico, para entender o que é uma versão pending-install , para que possamos começar a raciocinar sobre essa mensagem de erro.

Tive problemas com helm upgrade e isso me trouxe até aqui. Foi resolvido com a adição de -n <namespace> . Talvez ajude alguém lá fora.

Para Helm3, pode ser resolvido através do patch
kubectl -n <namespace> patch secret <release-name>.<version> --type=merge -p '{"metadata":{"labels":{"status":"deployed"}}}'

release-name e version - Pode ser visto de kubectl get secrets -n <namespace> | grep helm