<p>atualização do helm - instalar não funciona mais</p>

Achei que estava tendo o mesmo problema, mas descobri que tinha apenas uma exclusão antiga (mas não removida) e a liberação estava pendurada. verifique a lista do helm -a e, se sua versão estiver lá, exclua o helm --purge releasename. helm upgrade -i está funcionando com sucesso no 2.7.2 para mim.

Este é um efeito colateral da correção de problemas de atualização de versões que estavam em um estado incorreto. https://github.com/kubernetes/helm/pull/3097 foi o PR que corrigiu esse problema. Existe um caso extremo aqui que não conseguimos detectar?

Verifique helm list -a como @tcolgate mencionou, talvez também explicar como reproduzi-lo também seria útil para determinar se é um caso extremo não detectado ou um bug.

Também tendo o mesmo problema, junto com nomes de lançamento duplicados:

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

Quando você estava atualizando, qual mensagem foi exibida?

mesmo erro que o diff acima, mas uma instalação diria que já foi instalado.

Quero dizer, nas tentativas de atualização anteriores que terminaram em um status FALHA. Quero saber como chegamos à situação em que todas as versões estão em um estado de falha.

Ohh, as implantações de nomes de lançamento duplicados? Isso eu não tenho certeza, eu consigo muitas vezes. Às vezes, eles estão todos em um estado DEPLOYED, às vezes uma mistura de FAILED e DEPLOYED. Usamos um servidor CI / CD Jenkins que atualiza constantemente cada fusão de PR, portanto, fazemos vários helm upgrade dia, normalmente tendo apenas uma nova tag de contêiner. Normalmente, as duplicatas são apenas irritantes quando observamos o que está sendo implantado. Esta foi a primeira vez que tivemos um problema difícil com elas e, normalmente, não atualizamos o controlador de ingresso como estávamos neste caso.

Parece que acabei com algo semelhante, vejo algumas duplicatas em minhas listas de lançamentos:

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

Todos eles parecem estar em um estado DEPLOYED, mas pode muito bem ser que uma atualização anterior tenha falhado em algum ponto, já que achei esse bug várias vezes. Ainda estou no K8S 1.7, então não atualizei para o helm 2.7 ainda.

Mesmo problema, não é possível atualizar após FALHA na implantação

O mesmo aqui usando 2.7.2. A primeira tentativa de lançamento falhou. Então, quando tentei fazer uma atualização --install, recebi o erro "Erro: FALHA NO UPGRADE:" $ {RELEASE} "não tem versões implantadas".

O mesmo problema aqui com 2.7.2, helm upgrade --install falha com:

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

Se a liberação for totalmente eliminada com helm del --purge APPNAME , um upgrade --install subsequente funcionará bem.

Estou passando pelo mesmo problema. Combinado com # 3134, que não deixa opção para implantações idempotentes automatizadas sem alguns scripts para contornar o problema.

@winjer acabou de tentar deletar com --purge e para mim não funcionou, embora o erro tenha mudado
/ # atualização do helm foo / charts / foo / -i --wait
Erro: FALHA NO UPGRADE: "foo" não tem versões implementadas
/ # helm delete --purge foo
lançamento "foo" excluído
/ # atualização do helm foo / charts / foo / -i --wait
Lançamento "foo" não existe. Instalando agora.
Erro: a liberação do foo falhou: deployments.extensions "foo-foo-some-service-name" já existe

@prein Isso ocorre porque você tem um serviço que não é "proprietário" do helm, mas já existe no cluster. O comportamento que você está experimentando parece correto para mim. A implantação não pode ser bem-sucedida porque o helm teria que "assumir a propriedade" de um objeto API que não possuía antes.

Faz sentido poder atualizar uma versão FALHA, se o novo manifesto estiver realmente correto e não se contentar com nenhum outro recurso do cluster.

Também estou vendo esse comportamento em uma versão chamada content :

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

Terei que deletar isso para poder continuar a implantação. Avise-me se houver algo que eu possa fazer para ajudar a depurar isso.
(Acho que devemos renomear o problema, pois é mais sobre as duplicatas?)
(também executamos 2.7.2 )

Na verdade, tenho outra versão duplicada no meu cluster, se você tem algum comando para eu executar para ajudar a depurar isso? Avise!

acabamos de atualizar para o tiller 2.7.2 e estamos vendo a mesma coisa. helm delete RELEASE_NAME seguido por helm upgrade RELEASE_NAME . falha com Error: UPGRADE FAILED: "RELEASE_NAME" has no deployed releases . upgrade é a forma pretendida de restaurar uma versão excluída (mas não eliminada), correto?

Parece que você pode restaurar a versão revertendo para a versão excluída.

ver o mesmo problema com v2.7.2 , falha quando não há versões anteriores implantadas com sucesso

Também vendo duas versões possíveis desse problema:

em CI:

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

na minha máquina local:

(em meu OSX bash e em um contêiner gcloud / kubectl)

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

Os avisos são normais para nosso gráfico.
Os erros são interessantes porque um de nossos subgráficos contém um pvc.yaml .

helm del --purge <release> atenua o problema.
Isso torna nosso pipeline de CI difícil de atualizar.

@adamreese qual é a resolução final para este problema? Estamos no 2.8 e ainda não podemos atualizar uma versão anterior de FAILED com a alteração para helm list .

Em particular, estamos enfrentando o seguinte tipo de problema:

• implantar uma versão, OK
• upgrade --install --wait , mas talvez haja um pequeno bug e --wait não teve êxito (por exemplo, as sondas de vivacidade nunca o inventam)
• depois de corrigir o gráfico, upgrade --install --wait falha com xxx has no deployed releases

Excluir / limpar não é desejável ou aceitável aqui: a versão pode ter vários recursos (pods, balanceadores de carga) que não são afetados pelo único recurso que não aumenta. Nas versões anteriores do Helm, upgrade --install nos permitia corrigir apenas a alteração que quebrou a versão completa, sem ter que remover todos os recursos.

O Helm é o proprietário de todos os recursos envolvidos em todos os momentos aqui - o recurso só é marcado FAILED porque --wait não conseguiu esperar que todos os recursos estivessem em bom estado. Presumo que o mesmo acontecerá se um pod for um pouco lento para iniciar e em muitos casos semelhantes.

@peay veja # 3353 para discussão de acompanhamento.

Obrigado - isso esclarece tudo. Na verdade, percebemos que só estávamos acertando quando não tínhamos um lançamento bem-sucedido para começar. Nesse caso, a eliminação é uma boa solução alternativa.

Isso ainda acontece se a instalação falhar.
Você precisa limpar e tentar novamente.

UPGRADE FAILED: "API" has no deployed releases
então você precisa limpar manualmente
helm delete --purge API
e vai funcionar.

A partir do leme 2.9, você também pode executar helm upgrade --install --force portanto, não há necessidade de limpar. Para versões anteriores:

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

@bacongobbler Ainda estou confuso sobre esse comportamento.
Você poderia responder https://github.com/kubernetes/helm/pull/3597#issuecomment -382843932 quando tiver tempo?

Obrigado pelo seu trabalho nisso.

Certo. Estou AFK no momento, mas posso responder mais tarde esta noite. Compreenda perfeitamente a confusão e tentarei responder às suas perguntas da melhor forma possível. É uma loucura no escritório preparar outras coisas para a KubeCon EU. :)

Estou aberto para ajudar a hackear isso e / ou melhorar a documentação quando estivermos por aí.
Definitivamente vamos nos encontrar: +1:

@bacongobbler isso aborda # 3353 e nega o monte de código que escrevi como parte de # 4004?

No meu caso helm upgrade --install --force fez um delete --purge e depois instalei.

Este é o comportamento esperado? Quase perdi 2 meses de trabalho por causa disso. Quando force começou a significar delete ?

^ Tive algumas conversas com o pessoal da kubecon e descobri que algumas equipes estão fixadas na v2.7.0 por causa dessa mudança de comportamento.

Eu concordo que upgrade install nunca deve ser destrutivo, mesmo com o que --force possa significar.

@bacongobbler , desculpe, não pude me encontrar quando estávamos no CPH.
Existe documentação por trás da justificativa para alterar o comportamento para não permitir a atualização de uma versão com falha?
O antigo comportamento parece muito mais desejável do que o que temos agora.

Veja o segundo comentário em https://github.com/kubernetes/helm/issues/3353 para um contexto de fundo sobre por que tivemos que fazer essa mudança

Estou muito curioso para saber qual é o caminho proposto para seguir adiante. Não podemos voltar atrás no número 3097 por causa dos problemas demonstrados no número 3353, então adoraria saber o que a comunidade pensa ser o caminho certo para corrigir esse problema. Podemos voltar atrás # 3597, mas pelo que ouvi, não há uma boa solução para corrigir o problema de helm upgrade --install . : desapontado:

Eu sei que estamos trabalhando para retrabalhar a lógica de aplicação do Helm 3, mas isso é um longo caminho

Obrigado por vincular esse @bacongobbler :)
Sua sugestão aqui parece uma abordagem razoável:

pode ser valioso não realizar uma comparação quando nenhuma versão bem-sucedida foi implementada. A experiência seria a mesma como se o usuário executasse a instalação do helm pela primeira vez, no sentido de que não haveria nenhuma versão "atual" para comparação. Eu ficaria um pouco preocupado com alguns casos extremos. @adamreese , você tem alguma opinião sobre este?

Isso nos permitiria recuar # 3597, uma vez que o único caso de falha (nada contra o que diferenciar) seria resolvido.
Isso torna upgrade --install não destrutivo novamente e mais semelhante a kubectl apply .

Intuitivamente, isso é o que eu esperaria que upgrade --force fizesse: não faça operações de diff e patch, mas apenas aplique o modelo completo, ignorando o que está em vigor no momento. Não consigo pensar em nenhuma razão técnica por que isso não seria possível, mas também não estou familiarizado com o funcionamento interno do Helm.
Ainda pode ser uma operação perigosa, mas qualquer um que use um sinalizador --force normalmente espera um certo risco ao forçar atualizações. Embora eu diria que não se espera que isso exclua e recrie sua implantação, com possível tempo de inatividade.

Eu li as discussões, mas ainda não estou certo sobre como ter um comando idempotente upgrade --install (ou sequência de comandos).

Com a versão estável atual, como posso fazer isso em um script automatizado? Eu preciso ser capaz de implantar de forma não interativa sem usar delete --purge , mesmo se uma tentativa anterior falhar.

Quanto aos planos futuros, este é o comportamento que eu esperava originalmente de upgrade --install :

• Instale se nenhuma instalação anterior foi feita
• Atualize uma instalação anterior bem-sucedida
• Substitua uma instalação que falhou anteriormente
• Se a instalação falhar, os recursos antigos ainda devem estar no local, sem tempo de inatividade quando possível
• Sem operações destrutivas (como o delete --purge automático mencionado acima)

Na minha opinião pessoal, nenhum sinalizador extra deve ser exigido para esse comportamento. É assim que os gerenciadores de pacotes geralmente se comportam. A menos que eu tenha entendido mal os requisitos, não acho que um sinalizador --force , por exemplo, seja necessário.

Houve alguma atualização em relação a isso? Qual é a maneira adequada de executar de forma confiável uma atualização em uma instalação existente sem ter que executar uma limpeza se algo falhar?

@MythicManiac FWIW:
Ainda tenho nossas equipes fixadas na v2.7.0 por causa desse comportamento.
Parece que não temos problemas com a atualização e exclusão de recursos quando deveriam usar helm upgrade --install com esta versão.

Nós também temos esse problema. É muito chato que eu precise excluir serviços K8s e ELBs AWS relacionados por causa do comando has no deployed releases . O gerenciador de pacotes é ótimo, mas esse problema leva ao tempo de inatividade da produção, o que não é bom.

Como uma solução alternativa muito hacky, se o problema com a implantação de origem for
resolvível (por exemplo, serviço preexistente.), Fazendo uma reversão para o original
a liberação com falha pode funcionar.

Na sexta-feira, 5 de outubro de 2018, 18:13, Eugene Glotov, [email protected] escreveu:

Nós também temos esse problema. É muito chato precisar deletar K8s
serviços e AWS ELBs relacionados porque o helm não tem versões implantadas. O
gerenciador de pacotes é ótimo, mas este problema leva ao tempo de inatividade da produção que
não é bom.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/helm/helm/issues/3208#issuecomment-427436187 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AAEo8_pISzHFAuOz6Lsv5EjrFaEo_HkYks5uh5M7gaJpZM4Qtexz
.

@tcolgate , obrigado! Acabei de consertar outro problema (https://github.com/helm/helm/issues/2426#issuecomment-427388715) com sua solução alternativa e tentarei testá-la para ELBs existentes quando implantarei um novo gráfico na próxima semana sobre os recursos existentes .

Fazer uma reversão para a versão original com falha pode funcionar.

@tcolgate , acabei de testar e não, não funciona no caso do primeiro deploy.

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

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

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

Estou curioso, se o Helm não pode implantar um gráfico sobre os recursos existentes, então por que helm delete causa a exclusão exata desses recursos?

@ thomastaylor312 , enfrentamos esse problema ~ e também https://github.com/helm/helm/issues/2426~ (acima: encontrei a causa raiz real de 2426) com o helm 2.11.0. Você acha que eles deveriam ser reabertos?

Eu encontrei este tópico depois de Error: UPGRADE FAILED: "xxx-service" has no deployed releases
Embora fosse visível de um leme, ls -a.

Decidi ver se era um problema por causa de um valor --set incorreto e --debug --dry-run --force na verdade AINDA excluiu meu pod em execução ... minha expectativa era que uma ação de simulação NUNCA modificaria recursos do cluster.

No entanto, funcionou e o serviço pôde ser reimplantado depois, mas tivemos um tempo de inatividade.

minha expectativa era que uma ação de simulação NUNCA modificaria os recursos do cluster.

Esta é uma expectativa justa - devemos fazer isso ... não acontecer

Eu acredito que foi corrigido em https://github.com/helm/helm/pull/4402, mas seria bom se alguém verificasse. Desculpe por isso!

mesmo problema após a atualização para 2.11.0

Postagem cruzada:
https://github.com/reactiveops/reckoner/issues/48#issuecomment -453411283

Por que está fechado? Temos uma maneira adequada de lidar com isso agora?

@gerbsen , não há uma maneira de contornar isso com as versões atuais do Helm que não seja destrutiva.
Ainda usamos o Helm 2.7.0 para tudo na minha organização. É uma versão muito antiga que tem outros bugs, mas não tem esse problema.

Acabei de fazer helm upgrade --install --force fazer um delete --purge e destruir meu pvc / pv sem me avisar (sobre a reciclagem). Tinha várias versões com falha, então estava em um estado de execução no kubernetes, mas o helm achava que não havia versões em execução. Não são bons tempos de forma alguma.

@notque depois de perder todo o painel de grafana duas vezes comecei a fazer backups antes de fazer qualquer tipo de atualização, ter esse tipo de risco remove todos os benefícios de usar o helm

Para aqueles que estão procurando por ajuda, o problema foi embora depois de atualizar o leme para v.2.15.2

Ainda estou vendo este problema em 2.16.0

Por que ainda está fechado? 2.16.1 ainda é afetado

@ nick4fake , acho que é uma duplicata de https://github.com/helm/helm/issues/5595