Helm: `helm upgrade --install` não executa uma instalação / atualização se a primeira instalação falhar

Isso foi intencional por design de https://github.com/kubernetes/helm/pull/3097. Basicamente, a comparação com uma implantação com falha causou um comportamento indesejável, principalmente esta longa lista de bugs:

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

Se sua versão inicial terminar em um estado de falha, recomendamos limpar a versão via helm delete --purge foo e tentar novamente. Após uma versão inicial bem-sucedida, todas as versões subsequentes com falha serão ignoradas e o helm fará uma comparação com a última versão bem-sucedida conhecida.

Dito isso, pode ser valioso não realizar uma comparação quando nenhuma versão bem-sucedida foi implantada. A experiência seria a mesma como se o usuário executasse helm install 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?

A correção sugerida parece completamente insustentável em um sistema automatizado. Definitivamente, não quero que tudo que invoca o helm saiba "se a primeira versão falhar, exclua e tente novamente". Por um lado, a maioria das minhas ferramentas não sabe se é uma instalação ou atualização, ou se é a primeira vez ou a centésima vez, quase sempre está executando apenas helm upgrade --install .

Também gostaria de alertar que comentei no PR original https://github.com/kubernetes/helm/pull/3097#discussion_r151808599 perguntando especificamente sobre este caso.

O comportamento antigo era melhor para este caso.
Eu concordo com @chancez. Isso torna upgrade --install não idempotente para uma ocorrência comum.

@bacongobbler
Se estivermos preocupados com as falhas de lançamento e estilhaços devido a ganchos com falha, eu diria que é um problema de design do gráfico. (Ganchos funcionam melhor quando são idempotentes)
Os usuários são livres para desenvolver tratamento de erros e comportamento não idempotente em torno do helm.

Com quais outros casos extremos estamos preocupados?
Parece que o # 3097 cuida de muito 👍

Meu desenvolvimento local seria muito mais suave se eu pudesse fazer helm upgrade -i ser idempotente mesmo contra versões com falha para pelo menos alguma combinação de argumentos. Meu caso de uso é quando tenho um script de muitos lançamentos que sei que quero criar para iniciar um ambiente de desenvolvimento local.

Isso pode ser análogo ao sinalizador --replace para helm install . Observe que --replace é uma das duas únicas bandeiras de helm install que está faltando em helm upgrade , sendo a outra --name-template .

Para ser absolutamente claro, sim, isso seria uma boa coisa a corrigir. Alguém quer tentar enquanto temos nossas mãos ocupadas com outro trabalho?

Oi,
Eu criei um PR https://github.com/kubernetes/helm/pull/3437 que deve corrigir esse problema

Não sei por que precisamos dos comandos install e upgrade , só uso o comando upgrade --install e parece que muitas pessoas fazem o mesmo. Só preciso de um comando que execute upgrade --install e não tropece em uma execução com falha. Podemos simplesmente renomear upgrade --install para deploy , torná-lo verdadeiramente idempotente e descartar os outros dois?

(Estou lutando com uma nova variante desse comportamento problemático no 2.8.0. Desde a atualização do 2.7.2 agora se eu tiver uma instalação com falha, e então delete --purge it, e o upgrade --install it , Ainda posso obter o erro Error: UPGRADE FAILED: "xyz" has no deployed releases . Parece que --purge não é totalmente eficaz no 2.8.0 e o leme tem algum estado preso não aparecendo em list --all . Tenho que em seguida, para um install para fazer o leme voltar a um estado em que eu possa fazer o usual upgrade --install novamente.)

Eu concordo com @whereisaaron , eu seria legal com um comando deploy que funcionasse mais como kubectl apply . Torna a automação do Helm muito mais fácil também, já que você não precisa verificar se há versões existentes em alguma loucura de script de shell :)

Talvez a solução seja fazer com que o helm execute automaticamente helm delete --purge ?
Algo como:
1) O usuário executa helm upgrade --install
2) O primeiro lançamento falha
3) O usuário faz algumas alterações no gráfico e executa novamente helm upgrade --install
4) Helm tenta executar o comando
5) Falha e há precisamente uma versão anterior em estado de falha
6) O Helm executa silenciosamente helm delete --purge
6) Após a eliminação, o Helm tenta automaticamente helm upgrade --install e mostra a saída desse

Talvez este comportamento possa ser acionado por meio do sinalizador --force que já tem um comportamento semelhante para outros cenários

Boa ideia, mas acho que nunca devemos excluir o livro de lançamento sem que o usuário peça explicitamente para remover esses dados. Os operadores do Helm desejarão saber por que o serviço falhou ao atualizar de versões com falha anterior ou deduzir as falhas coletando esses dados do razão.

Eu forneci um comentário anteriormente no tópico que descreve uma solução para o problema. É semelhante à sua solução em execução, mas sem a necessidade de excluir todo o livro de lançamento. Acredito que o nº 3437 está tentando aplicar essa solução como um patch.

@rchernobelskiy também acontece comigo. Exatamente como você descreve.

Eu me deparo com esse problema talvez uma vez por dia ao implantar novos aplicativos.
É uma dor!

@gmanolache Ainda estamos no helm 2.7.0 por esse motivo.
Não está claro para mim se atualizar para usar a sinalização --force é seguro: comentário

Se você precisar fazer downgrade, esta é uma boa maneira de fazer isso: downgrade para 2.7.0

O que é esta informação de diagnóstico útil do 'livro-razão do leme' e como podemos obtê-la? :sorrir:

Estou preocupado com o que a seguir pode ser lido como temperamental, é genuinamente apenas um convite para dicas sobre como podemos obter informações de diagnóstico quando você tem uma implantação com falha. Porque realmente parece que estou faltando alguma coisa. Parece que o estado de falha deve ter alguma utilidade para os operadores? Eu pesquisei o site do manual do leme novamente; algo como 'helm get manifest' funcionará em um estado de falha para extrair informações de diagnóstico úteis?

Minha experiência do usuário quando recebo uma implantação com falha é que você não obtém nenhuma informação útil. O Helm rejeita todos os recursos parcialmente criados / restantes, de forma que o 'status do leme' não mostra nada. Tudo o que você pode fazer é 'rollback' ou 'delete --purge' (você não pode simplesmente 'deletar' ou seu 'upgrade --install' do CI continuará falhando). O estado de falha apenas parece servir para quebrar a idempotência de 'atualizar - instalar' que todos ansiamos para nossas implantações de CI.

Seria razoável ter uma opção '--auto-rollback' para situações de CI, por exemplo, 'atualizar --install --auto-rollback'. Eu geralmente prefiro um roll back que tem que sair da cama para lidar com um estado de falha 😆 😴 💤

O que é esta informação de diagnóstico útil do 'livro-razão do leme' e como podemos obtê-la? 😄

helm help history

Obrigado @bacongobbler. Ok, entendo que essa lista é o significado do razão. E se você ainda tem o livro razão, você pode usar helm get manifest --revision 123 para ver o que foi implantado que falhou? Isso certamente é útil preservar. E se rollback não perdermos essa informação.

History prints historical revisions for a given release.

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

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

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

Se tivéssemos helm upgrade --install --auto-rollback então tanto a implementação com falha quanto a reversão seriam registradas no razão e disponíveis para os operadores. E isso ajudaria muito a evitar que as implantações de CI cheguem ao intratável estado de 'falha', em que 'atualização do leme - instalar' para de funcionar. Implantações de CI com falha geralmente são desenvolvedores que injetam erros de digitação / erros no sistema de implantação. Com '--auto-rollback', eles podem inspecionar a mensagem de erro do comando helm retida no log do servidor de implantação, corrigir e implementar os valores corrigidos.

Eu acho que mesmo sem a opção '--auto-rollback' poderíamos usar um wrapper automatizado para executar helm rollback qualquer momento helm update --install retornar um erro 'FALHA'. E talvez detectar onde está a instalação inicial e helm delete --purge em vez disso.

Ou seja, poderíamos criar um script de wrapper para garantir que os resultados de um CI 'atualização do helm --install' seja sempre um estado em que o próximo CI 'atualização do helm --install' seja sempre possível. Enquanto retém as informações do razão para quaisquer tentativas malsucedidas (pelo menos para versões cuja instalação inicial funcionou).

helm deploy =

• helm upgrade --install
• se FAIL, então
  
  
  
  • se revisão = 1
  
  
  • então helm delete --purge
  
  
  • outro helm rollback
  
  

@whereisaaron isso seria elegante 👍

Existe uma maneira fácil de obter a versão de trabalho mais recente diferente de helm history ${name} | tail -2 | head -1 | awk '{print $1}' , para ser usado por helm rollback ?

Olá,

Estou usando o Helm 2.12.2 e ainda tenho o problema: o helm falha quando a primeira implantação falha. Isso é uma regressão, talvez?

Não tenho certeza se é uma regressão, mas nunca foi realmente "consertada".

@ RickS-C137 Acho que isso deve ser consertado usando helm upgrade --install --force que 'excluirá' e, em seguida, 'instalará --substituirá' uma versão com falha.

Ainda estou tentando corrigir esse problema em um pipeline de Jenkins que estou tentando usar.
Estou tentando implantar uma nova imagem do meu aplicativo e não me importo se a implantação já existe ou não.
Quero executar um comando que substitui a implantação atual ou apenas o instala se não existir.
Eu tentei helm install --replace Eu freqüentemente recebo Error: a released named xyz is in use, cannot re-use a name that is still in use que obviamente mata meu pipeline e a compilação falha.

@bacongobbler O que você acha sobre https://github.com/helm/helm/issues/3353#issuecomment -385222233?

Não vejo como haveria tempo de inatividade ou perda de dados se destruirmos e recriarmos a versão inicial se a versão inicial falhar.

Implementei isso em nossa construção:

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

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

Com o helm atualmente, você não sabe qual combinação de comando + opções do helm usar sem inspecionar o estado atual. E para um determinado comando de leme, você não sabe o que obterá, porque depende de qual é o estado atual. Esse não é realmente o sonho declarativo do estado desejado ☁️ 💤 😄

No leme 3, podemos potencialmente descontinuar install / upgrade / --replace / --upgrade / --force e substituí-los todos por um helm deploy idempotente anterior , que se helm deploy falhar, reverter (revisão> 1) ou deletar + limpar (revisão = 1), para deixar o estado como estava antes. O manifesto com falha ainda estaria disponível em helm history/get . E pode até haver uma opção '--no-rollback' para pessoas que desejam preservar a implantação em um estado de falha para investigação

A opção de helm upgrade --install --force está chegando perto, exceto que em vez de reverter e atualizar, ele exclui e substitui lançamentos com falha (mesmo para revisões> 1), o que deixa algumas pessoas irritadas com o # 3208 ... 😮 ⚡️ 💥

Por enquanto, podemos usar scripts de wrapper ou meta-ferramentas como helmsman cuja lista de recursos em parte emprega helm mas atenua esse problema:

• Idempotência : Contanto que o arquivo de estado desejado não mude, você pode executar o Helmsman várias vezes e obter o mesmo resultado. _ [... independentemente do estado atual] _
• Continuar a partir das falhas : No caso de implantação parcial devido a uma falha de implantação de gráfico específico, conserte seu gráfico de leme e execute o Helmsman novamente sem precisar reverter os sucessos parciais primeiro.

substitua todos por um comando idempotente que atinja o estado desejado ou deixe o estado inalterado

Em retrospecto, esse é um objetivo de design incrivelmente óbvio.

Oi,
Em nosso caso, a versão inicial não falhou realmente ... É só que nosso aplicativo não estava completamente ativo quando o tempo limite de instalação expirou ou algum outro problema estranho foi corrigido. Em qualquer caso, o aplicativo está funcionando perfeitamente bem e, portanto, ter que excluí-lo seria um problema para nós (temos algum armazenamento persistente anexado que também seria removido !!).

Existe alguma solução alternativa para implantar um gráfico quando a versão inicial 'aparentemente falhou', mas na verdade está tudo bem?

Portanto, é a conclusão de que upgrade --force é muito forte, ou seja, há momentos em que excluir + substituir + retry_upgrade não é a solução correta para uma atualização com falha?

Existe um problema separado acompanhando a ideia de mesclar install & upgrade em um comando deploy ?

Não que eu conheça @dcow. Qual é o caso de uso sobre o comando helm upgrade --install ?

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

Não sei por que precisamos dos comandos de instalação e atualização, só uso o comando upgrade --install e parece que muitas pessoas fazem o mesmo. Só preciso de um comando que atualize --instalar e não tropeçar em uma execução com falha. Podemos simplesmente renomear upgrade --install para implantar, torná-lo verdadeiramente idempotente e abandonar os outros dois?
...

e

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

Com o helm atualmente, você não sabe qual combinação de comando + opções do helm usar sem inspecionar o estado atual. E para um determinado comando de leme, você não sabe o que obterá, porque depende de qual é o estado atual. Esse não é realmente o estado declarativo desejado nuvem de sonhos zzz smile

No helm 3, podemos descontinuar potencialmente o install / upgrade / --replace / --upgrade / --force e substituí-los por uma implantação do helm idempotente que atinge o estado desejado ou deixa o estado inalterado.
...

Eu geralmente concordo que o helm deve funcionar como kubectl apply e tentar alcançar a realidade desejada ao invés de precisar executar diferentes tipos de comandos dependendo do estado do seu cluster. Esperava adicionar suporte a um problema específico, caso existisse, ou pelo menos descobrir qual era a resolução, já que deploy não está implementado e estamos no comando 3.2.

@dcow Ok, você quer criar um problema então com sua proposta?

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