Helm: FALHA NA ATUALIZAÇÃO: Nenhum recurso com o nome "" encontrado

Estou tendo um problema semelhante em que tenho um gráfico com dependências agrupadas. Se eu adicionar uma nova dependência e executar helm upgrade o resultado será o mesmo descrito. Os recursos são criados corretamente, no entanto, o helm retorna um erro.

Portanto, se estiver instalado: helm install -n my-release

my-thing/
  Chart.yml
  charts/
    depended-upon-thing/

E então um novo gráfico é adicionado como uma dependência:

my-thing/
  Chart.yml
  charts/
    depended-upon-thing/
    new-dependency/

Quando a versão é atualizada com: helm upgrade my-release my-thing helm produz o seguinte erro:

Error: UPGRADE FAILED: No resource with the name new-dependency found.

@devth Não consigo reproduzir este problema no master. Você ainda está vendo esse problema? Qual versão de leme / leme você está usando?

Obrigado!

@elementalvoid Eu também não consegui reproduzir o novo erro de dependência no master. Você ainda está vendo esse problema? Qual versão de leme / leme você está usando?

Obrigada.

Na época, eu estava no alpha 4. Usando o alpha 5 e o exemplo do @devth , também não consegui reproduzir o problema.

Bem. Vou fechar isso por enquanto. Sinta-se à vontade para registrar um problema se você ver algum desses problemas novamente.

Obrigado novamente.

@michelleN obrigado! Desculpe, não tive tempo esta semana para tentar uma reprodução no master. Ansioso para atualizar em breve!

O mesmo para mim ao mover uma especificação de implantação / volume do hostPath para o PVC.
O bug parece ser quando um manifesto de atualização depende de um novo ("ausente" no antigo?)
versão: 2.7.2

Estranho, estou vendo o mesmo comportamento ao tentar atualizar um gráfico na versão 2.7.2 com uma nova função. Tiller reclama que não consegue encontrar a função e falha nas implantações, embora tenha realmente criado a função.

Minha situação era que eu tinha um novo recurso e implantei a nova versão do gráfico de leme com o novo recurso. Essa implantação falhou porque eu gordo toquei em algum yaml. Bem, os novos objetos foram criados no kubernetes. Consertei o yaml e executei a atualização no meu gráfico novamente e voila, a mensagem de erro de que o recurso não foi encontrado aparece. Tive que entrar no kubernetes e remover os novos recursos (no meu caso, uma função e vinculação de função) que foram criados pela implantação com falha. Depois disso, a verificação do leme para ver se o objeto atual existe falha (https://github.com/kubernetes/helm/blob/7432bdd716c4bc34ad95a85a761c7cee50a74ca3/pkg/kube/client.go#L257) e os recursos são criados novamente. Parece um bug, onde talvez novos recursos para um gráfico com falha devam ser contabilizados?

Obtendo um erro semelhante durante a atualização:

$ helm upgrade --install bunny ./app --namespace=staging --reuse-values --debug
[debug] Created tunnel using local port: '53859'

[debug] SERVER: "127.0.0.1:53859"

Error: UPGRADE FAILED: no ConfigMap with the name "bunny-proxy-config" found

O Configmap foi criado

$ k get configmap
NAME                 DATA      AGE
bunny-proxy-config   1         7m

Meu configmap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ template "proxy.fullname" . }}-config
  labels:
    app: {{ template "proxy.name" . }}
    chart: {{ template "proxy.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
data:
  asd: qwe

Temos o mesmo problema.

Excluí todo o lançamento e instalei novamente. Atualmente parece estar funcionando.

$ helm del --purge bunny

Eu também estou tendo esse problema

Cliente: & version.Version {SemVer: "v2.8.0", GitCommit: "14af25f1de6832228539259b821949d20069a222", GitTreeState: "clean"}
Servidor: & version.Version {SemVer: "v2.8.0", GitCommit: "14af25f1de6832228539259b821949d20069a222", GitTreeState: "clean"}

Isso acontece freqüentemente com o nosso uso do leme e requer um --purge completo. Isso _não_ é uma solução.

Não é aplicável se você usar CI / CD.
O que acontece se uma atualização falhar e você usar a estratégia de atualização contínua. Devo excluir minha versão ainda em funcionamento?

Também vejo o mesmo problema quando há um problema de implantação ou semelhante, mas o segredo / cm foi criado, mas o Helm o perdeu de vista, recusando-se a permitir que você fizesse muito.

Eu já vi isso acontecer, embora raramente, mesmo em uma versão não quebrada (ou seja, é visto como passou), mas ainda não descobri o que pode causar isso.

Também podemos reproduzir esse problema (servidor v2.8.2) ao adicionar recursos às implantações de leme existentes. Ter que excluir a implantação e reimplantar cada vez que um novo recurso precisa ser adicionado será um grande problema na produção.

Em nosso caso, estávamos adicionando um configmap a um gráfico e o gráfico não foi atualizado com:

Erro: FALHA NO UPGRADE: nenhum recurso com o nome "" encontrado

Nota: Estamos usando 2.7.2;

Acredito que isso aconteça porque quando o helm está determinando o que mudou, ele procura o novo recurso configmap na versão anterior e não consegue encontrá-lo. Consulte https://github.com/kubernetes/helm/blob/master/pkg/kube/client.go#L276 -L280 para obter o código de onde vem esse erro.

Registros do Tiller para a atualização com falha:

[tiller] 2018/05/03 19:09:14 preparing update for staging-collector
[storage] 2018/05/03 19:09:14 getting deployed release from "staging-collector" history
[tiller] 2018/05/03 19:10:39 getting history for release staging-collector
[storage] 2018/05/03 19:10:39 getting release history for "staging-collector"
[tiller] 2018/05/03 19:10:41 preparing update for staging-collector
[storage] 2018/05/03 19:10:41 getting deployed release from "staging-collector" history
[storage] 2018/05/03 19:10:42 getting last revision of "staging-collector"
[storage] 2018/05/03 19:10:42 getting release history for "staging-collector"
[tiller] 2018/05/03 19:10:44 rendering collector chart using values
[tiller] 2018/05/03 19:10:44 creating updated release for staging-collector
[storage] 2018/05/03 19:10:44 creating release "staging-collector.v858"
[tiller] 2018/05/03 19:10:44 performing update for staging-collector
[tiller] 2018/05/03 19:10:44 executing 0 pre-upgrade hooks for staging-collector
[tiller] 2018/05/03 19:10:44 hooks complete for pre-upgrade staging-collector
[kube] 2018/05/03 19:10:44 building resources from updated manifest
[kube] 2018/05/03 19:10:44 checking 3 resources for changes
[tiller] 2018/05/03 19:10:44 warning: Upgrade "staging-collector" failed: no resource with the name "collector-config" found 
[storage] 2018/05/03 19:10:44 updating release "staging-collector.v857"
[storage] 2018/05/03 19:10:44 updating release "staging-collector.v858" 

Esse problema também surge ao alterar o rótulo name de um serviço implantado, talvez outras coisas também.

Estou mudando o nome de um serviço em uma versão e não consegue atualizar com:

Erro: FALHA NO UPGRADE: nenhum serviço com o nome "new-service-name" encontrado

Eu estaria disposto a criar um PR para corrigir esse comportamento, mas gostaria de saber qual a forma pretendida ou sugerida de lidar com isso. Mesmo um sinalizador CLI que permite --force ter precedência seria ótimo.

Combine a importância.

Esse problema pode ser estranho quando você não pode simplesmente excluir uma implantação.

Descobri que nosso problema era devido a uma falha na implantação.

O Helm não tenta limpar após uma implantação com falha, o que significa que coisas como o novo ConfigMap que adicionei acima são criadas, mas sem uma referência na implantação 'anterior'. Isso significa que quando a próxima implantação ocorre, o helm encontra o recurso no k8s e espera que ele seja referenciado na última revisão implantada (ou algo assim; não tenho certeza de qual lógica exata ele usa para encontrar a versão 'anterior') para verificar o que mudanças existem. Não está nessa versão, por isso não consegue encontrar o recurso e falha.

Este é um problema principalmente ao desenvolver um gráfico, pois uma implantação com falha coloca o k8s em um estado que o leme não rastreia corretamente. Quando descobri que isso era o que estava acontecendo, sabia que só precisava deletar o ConfigMap do k8s e tentar implantar novamente.

@krishicks Sim, esta é uma maneira de reproduzi-lo. Uma implementação com falha + um recurso nunca criado (ou seja, configmap inválido) também pode causar isso também, eu percebi, o que leva a um estado irrecuperável

Nós estamos acertando este também. É o mesmo problema que @krishicks e @jaredallard mencionam:

1. Ocorreu uma falha na implantação:
   UPGRADE FAILED: the server was unable to return a response in the time allotted, but may still be processing the request (get configmaps)
2. Quaisquer alterações subsequentes, também em outras versões, falham com um aviso como
   Error: UPGRADE FAILED: no Service with the name "…" found

Vou tentar usar o sinalizador helm upgrade --timeout … para mitigar o primeiro problema, mas uma implementação com falha bloqueando tudo é um problema para nós. Além disso, usar helm rollback … não resolveu isso.

Como helm upgrade … é executado automaticamente em nosso caso de uso, um sinalizador --auto-rollback para helm upgrade seria muito útil, o que reverte as alterações que falharam.

Isso está acontecendo comigo com a v2.7.2 ao adicionar novos recursos ao gráfico.
Existe alguma estimativa de quando haverá uma solução para isso?

Isso deve ser corrigido com # 4146.

EDITAR: veja abaixo

Então eu encontrei alguns bugs com o # 4146 que o torna um PR indesejável para seguir em frente. Eu relatei minhas descobertas entre o mestre, # 4146 e # 4223 aqui: https://github.com/kubernetes/helm/pull/4223#issuecomment -397413568

@adamreese e eu conseguimos identificar o bug subjacente que causa esse erro específico e passar pelos diferentes cenários e casos

Ah, e algo que esqueci de mencionar: como o cluster está em um estado inconsistente, isso pode ser facilmente contornado intervindo manualmente e excluindo o recurso que o erro reporta como "não encontrado". Seguindo o exemplo que demonstrei em https://github.com/kubernetes/helm/pull/4223#issuecomment -397413568:

><> helm fetch --untar https://github.com/kubernetes/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml
><> kubectl create -f foo/templates/service.yaml
service "foo-bar" created
><> helm upgrade $(helm last) ./foo/
Error: UPGRADE FAILED: no Service with the name "foo-bar" found
><> kubectl delete svc foo-bar
service "foo-bar" deleted
><> helm upgrade $(helm last) ./foo/
Release "riotous-echidna" has been upgraded. Happy Helming!
...
><> kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
foo-bar      ClusterIP   10.104.143.52   <none>        80/TCP    3s
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   1h

@bacongobbler Isso nem sempre funciona. Já tivemos situações em que excluí-lo funcionou e algumas em que ainda não funcionou depois de fazer isso.

isso pode ser facilmente contornado intervindo manualmente e excluindo o recurso

@bacongobbler Por favor, entenda que este recurso pode ser um objeto de Serviço ou Implantação de namespace de produção, que pode (e já afetou) fortemente nossas garantias de serviço.

Sim eu conheço. Estou apenas explicando e observando o comportamento do bug para que os outros saibam o que está envolvido. :)

Basta encontrar esse problema duas vezes em clusters diferentes. Cada vez com configmaps. Excluir os recursos não resolveu o problema, então tivemos que remover todo o lançamento.

Mesmo aqui. Não só o Configmaps, tenho um com ServiceAccount.

PVC aqui. :)

Basicamente, todo tipo de objeto priorizado está sujeito a esse bug.

Há alguém designado para consertar isso? Já existe um PR para isso? Posso ajudar em alguma coisa?

Já fui mordido por esse problema mais de uma vez, já que é uma situação fácil de entrar, mas aparentemente não há maneira fácil de sair dela. Suponho que a parte "boa" no meu caso é que os recursos são atualizados mesmo com o erro no lançamento (não tenho certeza se isso me deixa feliz ou preocupado)

Acho que o helm deve proibir o usuário de entrar neste estado errado ou controlá-lo corretamente.
Existem soluções reais para isso além de excluir tudo (que só é viável para usos de não produção)?

Se alguém mais puder determinar o outro caso extremo em que excluir o recurso não resolveu o problema, isso seria muito útil para determinar a causa raiz para resolver esse problema específico. Pode haver vários caminhos que podem resultar no mesmo erro.

@Draiken não, tentamos várias soluções para o problema e nenhuma delas parece razoável, pois também

a) não execute a atualização conforme pretendido, ou
b) introduzir novos bugs

Eu escrevi sobre essas soluções aqui e por que elas não funcionam. Se você puder descobrir uma solução alternativa, ficaremos felizes em dar uma olhada nela.

Não podemos impedir que os usuários entrem nesse estado errado; olhamos as soluções, mas, novamente, todas elas apresentam um conjunto diferente de problemas. Quando a instalação está em um estado inconsistente, é difícil "consertar" sem intervenção manual. 😢

Uma solução alternativa que funcionou para mim é fazer um helm rollback ... imediatamente antes da falha ocorrer. Em seguida, valido se o gráfico funciona em uma nova versão com helm install -n new-test-release . .

Depois que tudo funcionar, eu limpo a versão de teste e executo helm upgrade ... na versão antiga; e tudo funcionou. Esta é uma solução alternativa irritante, mas parece funcionar.

Não sei se isso ajuda em nada, mas acabei de encontrar esse problema em meus clusters de teste e de produção.

As alterações que fiz em meus arquivos de leme foram muito simples:
Eu tinha uma implantação existente, com um serviço associado e um orçamento de interrupção de pod, que não foi alterado.
Eu adicionei uma 2ª implantação, com serviço próprio e poddisruptionbudget.
Aumentei o número da versão do gráfico.

Ao executar o helm, recebi este erro na primeira vez:

KUBECONFIG=**** helm upgrade --kube-context=mycluster -f helm/project/mycluster.yaml project ./helm/project --install --wait --timeout 1200

Error: UPGRADE FAILED: Deployment.apps "blah-blah" is invalid: spec.template.metadata.labels: Invalid value: map[string]string{"app":"blah-blah", "chart":"blah-3", "name":"blah", "release":"project"}: `selector` does not match template `labels`

Ao executar o leme novamente, agora recebo este erro continuamente:

KUBECONFIG=**** helm upgrade --kube-context=mycluster -f helm/project/mycluster.yaml project ./helm/project --install --wait --timeout 1200

Error: UPGRADE FAILED: no Service with the name "blah-blah" found

O gráfico do leme, é claro, funcionou no teste quando excluí tudo e reimplantei. Isso não é realmente uma opção para prod.

@veqryn Já me

EDITAR : Se alguém estiver interessado em experimentá-lo, posso enviá-lo para um repositório docker público e incluir um trecho rápido de como usá-lo.

@jaredallard estamos interessados. Obrigado!

Eu sei que os mantenedores podem não recomendá-lo, mas funciona, o que é melhor do que nada.

@jaredallard , não poderíamos recomendar esse patch simplesmente porque ele não funciona por conta própria (ref: https://github.com/helm/helm/pull/4223#issuecomment-397413568). Ele ignora o erro, mas não atualiza os recursos, portanto, o patch não faz o que o usuário pretendia fazer originalmente. Ele corrige um problema, mas introduz outro sem corrigir o problema original que os usuários pretendem realizar: atualizar um recurso.

No entanto, isso é intrigante:

Basicamente, uso minha versão em # 4146 sempre que me deparo com esse problema e, em seguida, troco de volta para a versão principal.

Se estou lendo isso direito, você está sugerindo que encontrou uma solução alternativa que

a) contorna o erro
b) permite atualizar os recursos conforme pretendido originalmente

fazendo 2 helm upgrade s: um com o patch e outro sem? Isso pode nos ajudar a identificar melhor a causa raiz e como corrigir esse erro.

@bacongobbler eu teria que revisitar isso para verificar 100% se esse é o comportamento. Vou atualizar este comentário ou postar outro quando o fizer.

Eu sei que os mantenedores podem não recomendá-lo, mas funciona, o que é melhor do que nada.

Além disso, para esclarecer, não estou tentando lançar sombra aí! É um pouco mal formulado olhando para trás agora, desculpe

Ainda estou confuso sobre por que meu elmo falhou na primeira vez.
Ele não obteve o erro no X with the name Y até a segunda vez que tentei aplicá-lo.

@veqryn Eu escrevi sobre como esse problema surge em primeiro lugar no problema que vinculei acima. Por favor, leia o comentário; Fico feliz em ajudar a esclarecer o problema com mais detalhes se não estiver claro.

Para os preguiçosos: https://github.com/helm/helm/pull/4223#issuecomment -397413568

Na verdade, eu li isso e, pelo que entendi, o problema aconteceu com você porque você mudou o nome do seu serviço.

No entanto, em nenhum momento nenhum dos meus serviços ou recursos mudou de nome.

E depois de reler seu comentário e conversar com minha equipe, descobrimos a causa de nosso erro:
Eu havia superado a versão de Chart do meu leme.
Essa versão do gráfico foi referenciada como um rótulo por minhas implantações e serviços.
O Kube / helm não gosta quando sua etiqueta muda, e é isso que causou o erro original.

A solução (para mim) foi usar o helm para reverter para a última implantação bem-sucedida e, em seguida, reverter a alteração da versão do gráfico para que a versão do gráfico permanecesse a mesma, o que foi bem-sucedido.

esta correção (feia) funciona para mim:

1. Estou recebendo um erro:

helm upgrade az-test-2-prom ./prometheus --namespace monitor --set cluster_name="az-test-2" -f values.yaml
Error: UPGRADE FAILED: no ConfigMap with the name "az-test-2-prom-prometheus-grafana-config" found

1. encontre as últimas revisões IMPLEMENTADAS

export TEMPLATE='{{range .items}}{{.metadata.name}}{{"\t"}}{{.metadata.labels.STATUS}}{{"\n"}}{{end}}'
kubectl -nkube-system get cm -l 'OWNER=TILLER' -ogo-template="$TEMPLATE"

az-test-2-prom.v1   SUPERSEDED
az-test-2-prom.v10  SUPERSEDED
az-test-2-prom.v11  SUPERSEDED
az-test-2-prom.v12  SUPERSEDED
az-test-2-prom.v13  SUPERSEDED
az-test-2-prom.v14  SUPERSEDED
az-test-2-prom.v15  SUPERSEDED
az-test-2-prom.v16  SUPERSEDED
az-test-2-prom.v17  DEPLOYED
az-test-2-prom.v18  FAILED
az-test-2-prom.v19  FAILED
az-test-2-prom.v2   SUPERSEDED
az-test-2-prom.v20  FAILED
az-test-2-prom.v21  FAILED
az-test-2-prom.v22  FAILED
az-test-2-prom.v23  FAILED
az-test-2-prom.v24  FAILED
az-test-2-prom.v25  FAILED
az-test-2-prom.v26  FAILED
az-test-2-prom.v27  FAILED
az-test-2-prom.v28  FAILED
az-test-2-prom.v29  FAILED
az-test-2-prom.v3   SUPERSEDED
az-test-2-prom.v30  FAILED
az-test-2-prom.v4   SUPERSEDED
az-test-2-prom.v5   FAILED
az-test-2-prom.v6   SUPERSEDED
az-test-2-prom.v7   SUPERSEDED
az-test-2-prom.v8   SUPERSEDED
az-test-2-prom.v9   FAILED



md5-6d9e4edff5e9111525fecb734bfec15a



for ii in {17..30}
> do
>   kubectl -nkube-system delete cm az-test-2-prom.v${ii}
> done



md5-cf6357e67a21fb9f80abb7b78b9e5b8e



kubectl -nkube-system patch cm az-test-2-prom.v16 -p '{"metadata": {"labels": {"STATUS": "DEPLOYED"}}}'

** 4. (Importante) Encontre todos os recursos existentes, novos recursos foram adicionados desde a última implantação (v16) e exclua-os, por exemplo
kubectl -nmonitor delete cm az-test-2-prom-prometheus-grafana-config
kubectl -nmonitor delect svc ...

Execute helm upgrade ... e veja Happy Helming

Como @ kosta709 disse, reverter para a última versão implementada, corrigir (manualmente) o gráfico ou o status atual (o que estiver errado) e fazer uma nova atualização, geralmente funciona.

O Helm é um ótimo software que pode ser descartado em alguns fluxos de trabalho automáticos (CI / CD) se o resultado de um comando não for estável.

Existe uma opção de que as soluções conhecidas sejam eventualmente implementadas no leme para (tentar) resolver esse problema conhecido (e um pouco chato)? Obrigado.

Recentemente, também estou acertando isso com frequência, o suficiente para me ajudar a resolver esse problema sozinho. Para começar, criei uma solução alternativa (
https://github.com/Nopik/helm/commit/afe6451cc2c6295e71ea2213ccce654ec3f5b686) que basicamente faz com que o Tiller obtenha o recurso existente como ponto de partida em vez do recurso obtido do manifesto antigo. Funciona como um encanto para mim, embora eu acredite que os desenvolvedores principais não irão querer mesclá-lo, pois contém comportamento embutido em código.

Pode haver dois bugs ocultos sob o mesmo comportamento, pois pelo menos uma vez, quando esse bug me incomodou, tive que deletar muitos (> 40) recursos, incluindo alguns que já estavam presentes em> 20 versões de lançamento bem-sucedidas. Mas em 99% dos casos, basta excluir recursos recém-criados (e ainda desconhecidos para o leme).

Então, estive pensando em como resolver isso da maneira adequada. Estou descrevendo isso abaixo. Core devs, por favor, corrija-me aqui e pondere se você concorda comigo. Em caso afirmativo, estou disposto a liderar esse esforço e fornecer relações públicas para corrigi-lo.

Geralmente o helm parece operar no modo 'patch': se o usuário modifica o recurso de alguma forma, e a nova versão de lançamento muda alguns outros parâmetros, o helm calcula o patch entre 2 revisões e o aplica - eu acredito que ele está tentando manter as alterações do usuário intactas.

Isso, infelizmente, nos deixa com o problema de mesclagem de 3 vias, pois temos a versão do recurso retirada do manifesto antigo, outra versão do novo manifesto e outra versão do recurso ativo atualmente. E o leme aparentemente é ruim para resolver conflitos, quando eles surgem.

Eu acho que a maneira correta seria escolher melhores padrões (basicamente mesclar meu branch servirá por muito tempo) ou fornecer um sinalizador para o usuário. Por exemplo, assim:

• --ignore-old-manifest=never (padrão, comportamento atual)
• --ignore-old-manifest=create-only (aplica-se a este caso, quando o manifesto antigo não tem noção do recurso, mas o recurso já existe, podemos tomá-lo como uma nova base e apenas corrigi-lo, se necessário) - Eu recomendaria que fosse novo padrão. Isso também permitiria que o helm começasse a assumir a propriedade de recursos criados manualmente.
• --ignore-old-manifest=always - apenas por uma questão de integridade, provavelmente não é estritamente necessário. Ele sempre criaria um patch entre o recurso atual e o manifesto mais recente, basicamente removendo todas as modificações do usuário.

Claro que você pode renomear o sinalizador para usar a lógica reversa: --use-current-resources=never(currently default)/create-only/always ou algo parecido.

Posteriormente, este sinalizador pode ser obtido de anotações de recursos, algo como:

annotations:
  helm.io/ignore-old-manifest: always

qual leme poderia reconhecer e aplicar esta estratégia por recurso. Não tenho certeza se os desenvolvedores do Helm querem ir para lá;)

Então, o que você acha dessa proposta?

Veja também a edição # 3805, onde os desenvolvedores do Helm estão considerando um patch de fusão de 3 vias.

O mesmo problema aqui.
Tentando configurar um ambiente de CD / CI com o Google Cloud Build.
Error: UPGRADE FAILED: no Deployment with the name "baobab-sidekiq" found

O engraçado é que a implantação existe:

kc get deployments
NAME             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
baobab           3         3         3            2           2d
baobab-ermis     1         1         1            1           23h
baobab-sidekiq   1         1         1            1           23h

Este é o primeiro gráfico que crio e esperava que helm fosse a solução para lidar com a complexidade da implantação de aplicativos complexos em um ambiente de CI / CD.

A intenção do leme é poder trabalhar em um pipeline de CI / CD?

Obrigado

Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

Também estou passando por isso, tentando atualizar o helm 0.8.0 para o helm 1.0.0.

helm version --tls Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

Também tenho encontrado isso ao atualizar os requisitos de um gráfico. Vejo que o Istio também está enfrentando esse bug, seu documento de instalação usa helm template . Isso é uma solução alternativa para esse problema?

Verifique as discussões recentes em https://github.com/helm/helm/issues/3805

tendo isso também, ainda acontece para o último leme 2.10

É hora de esse problema ser considerado seriamente. Já se passaram 2 anos e muuuuito pessoas relatam os mesmos problemas exatos, o que torna o leme totalmente inutilizável na produção e é uma verdadeira dor quando sua implantação depende do leme.

Muitas estrelas do GitHub trazem grandes responsabilidades

@brendan-rius Você pode contribuir com código para corrigir esse problema ou ter ideias. Veja # 3805 e # 4146 para algumas dicas.

@ brendan-rius, # 3805 em particular tem as discussões mais recentes atualizadas em torno deste bug. Eu sugiro dar uma leitura nesse tópico para ter uma ideia do que estamos enfrentando.

Repostando meu comentário aqui, pois ele está mais relacionado a este problema do que estratégias de mesclagem de 3 vias:

Se uma mesclagem de três vias não for viável para novas implantações no Helm 2.yz, quando o # 1193 será corrigido? O bug está aberto há quase dois anos sem uma resolução clara planejada para o Helm 2.0.

Neste ponto, não sabemos como proceder. Discutimos o bug por semanas e nenhuma das soluções propostas funcionará em todos os casos, seja pela introdução de novos bugs ou pela mudança significativa do comportamento de atualização do tilizador.

Por exemplo, @michelleN e eu

1. Quando uma atualização falha, automaticamente revertemos e excluímos os recursos que foram criados durante este lançamento.

Isso é muito arriscado, pois o cluster pode estar em um estado desconhecido após uma atualização com falha, portanto, o Helm pode não ser capaz de prosseguir de forma limpa, causando potencialmente o tempo de inatividade do aplicativo.

1. Durante uma atualização, se estivermos criando um novo recurso e virmos que ele já existe, em vez disso, aplicamos essas alterações ao recurso existente ou o excluímos / recriámos.

Isso é extremamente arriscado, pois o Helm pode excluir objetos que foram instalados por meio de outros pacotes ou por meio de kubectl create , nenhum dos quais os usuários podem querer.

A opção mais segura até agora tem sido pedir aos usuários que intervenham manualmente no caso desse conflito, o que demonstrarei a seguir.

Se alguém tiver sugestões / comentários / propostas alternativas, adoraríamos saber sua opinião.

@bacongobbler , se nenhum suporte para o recurso de mesclagem de 3 vias for planejado, precisamos de uma alternativa ou solução alternativa. Caso contrário, # 1193 é um bocker seriamente doloroso.

Para reiterar o problema, bem como a solução alternativa:

Quando uma atualização que instala novos recursos falha, a versão entra em um estado FALHA e interrompe o processo de atualização. Na próxima vez que você chamar helm upgrade , o Helm fará uma comparação com a última versão IMPLEMENTADA. Na última versão DEPLOYED, este objeto não existia, então ele tenta criar o novo recurso, mas falha porque ele já existe. A mensagem de erro é completamente enganosa, como @arturictus aponta.

Isso pode ser facilmente contornado intervindo manualmente e excluindo o recurso que o erro relata como "não encontrado". Seguindo o exemplo que demonstrei em https://github.com/helm/helm/pull/4223#issuecomment -397413568:

><> helm fetch --untar https://github.com/helm/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml                    # change the service name from "foo" to "foo-bar"
><> kubectl create -f foo/templates/service.yaml      # create the service
service "foo-bar" created
><> helm upgrade $(helm last) ./foo/
Error: UPGRADE FAILED: no Service with the name "foo-bar" found
><> kubectl delete svc foo-bar
service "foo-bar" deleted
><> helm upgrade $(helm last) ./foo/
Release "riotous-echidna" has been upgraded. Happy Helming!
...
><> kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
foo-bar      ClusterIP   10.104.143.52   <none>        80/TCP    3s
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   1h

Em outras palavras, a exclusão de recursos criados durante a versão FAILED contorna o problema.

@bacongobbler primeiro, quero agradecer por dar uma olhada nesta edição com mais detalhes nas últimas semanas. Não tenho certeza exatamente qual é o problema na atualização do Istio 0.8.0 para o Istio 1.0.0 que causa o problema ou se corresponde completamente à declaração do problema. Minha especulação é que cerca de 3 dias antes do lançamento, alguns objetos que não eram gerenciados anteriormente (ou seja, adicionados em um trabalho pós-instalação) foram migrados para não serem instalados em um trabalho pós-instalação.

Ao falar com a comunidade de operadores do Istio, que tem muita experiência anterior com o Helm, alguns operadores nos disseram que os recursos não gerenciados no Helm são más notícias e geralmente levam a falhas de atualização. Se a implementação de gráficos do Istio tiver uma falha que os torne incompatíveis com o upgrade com o Helm 2.yz, seria ótimo corrigir essas incompatibilidades - portanto, não teremos falhas de upgrade no futuro.

Estamos dispostos a fazer o primeiro hit de atualização de 0.8.0 para 1.0.0. Se a atualização estiver constantemente instável - o problema é diferente.

Eu executei uma bisect no Istio - uma vez que a atualização estava funcionando até 27 de julho (3 dias antes do lançamento do Istio 1.0.0) e achei este commit problemático: https://github.com/istio/istio/commit/301612af08128b15069d27ff6d03cdb87420e15b

Este PR essencialmente removeu o registro do objeto dos trabalhos pós-instalação. Acredito, mas não tenho certeza, removemos todas as instâncias de trabalhos pós-instalação na execução de 3 dias para o Istio 1.0.0.

Você pode oferecer conselhos sobre o gráfico Helm específico do Istio no que se refere ao upgrade? Manter o registro de objetos fora dos trabalhos de pós-instalação resolverá nossos problemas de atualização permanentemente?

Eu realmente não posso oferecer nenhum conselho forte ou proposta para consertar este problema em todo o helm, já que as pessoas com experiência mais recente com o Helm não conseguiram encontrar uma solução generalizada (e não por falta de dar uma olhada no problema). Não acho que poderia fazer melhor.

Saúde
-steve

Atualizado o título para refletir melhor o erro.

Também somos afetados pelo problema. Usamos o leme mais recente 2.10 com GKE 10.6.
Quando posso esperar que isso seja corrigido?
Temos alguma solução alternativa razoável para o problema? Remover toda a implantação com a opção --purge é muito ruim.

Sinta-se à vontade para opinar sobre meu último comentário. Realmente precisamos de feedback sobre a melhor forma de proceder aqui.

Uma solução alternativa foi repetida várias vezes neste thread. Leia https://github.com/helm/helm/issues/1193#issuecomment -419555433.

Gosto da ideia de um recurso de reversão automática do leme ( opção 1 ) para resolver esse problema. Sabemos que a última versão DEPLOYED Helm estava funcionando e o cluster estava em um bom estado, portanto, deve ser seguro reverter para ele. Se for arriscado para alguns casos de uso, pode ser opt-in por meio de um sinalizador para atualização do leme.

Isso é muito arriscado, pois o cluster pode estar em um estado desconhecido após uma atualização com falha, portanto, o Helm pode não ser capaz de prosseguir de forma limpa, causando potencialmente o tempo de inatividade do aplicativo.

Acho que muitos usuários do helm usam o helm de maneira automatizada por meio de uma ferramenta de CD ou CM e é mais arriscado deixar a versão do helm em um estado FALHA. Esses recursos incompletos em uma liberação com falha podem afetar outros recursos inesperadamente e podem causar tempo de inatividade. Por exemplo, se a especificação do pod continha uma versão de imagem ausente que, de alguma forma, entrou em produção, então sua carga de trabalho estaria em um estado ImagePullBackOff não funcional. Para nossa empresa, é ainda pior, já que temos alguns clientes locais que podem se atualizar por meio de nossa IU e, se falhar, temos que obter acesso ao sistema para depuração.

Mesmo desconsiderando o fato de que poderia corrigir esse problema, a reversão automática seria um recurso útil e ajudaria a garantir que as versões do Helm sejam mais transacionais por natureza. Ele movimenta o Helm das implantações de melhor esforço para priorizar a estabilidade e implantações bem-sucedidas.

@bacongobbler seria a seguinte abordagem viável para novas implantações:

• Adicionar uma bandeira - -three-way-merge
• Permitir apenas que esse sinalizador seja consumido em uma helm install (nova implantação)
• Uma vez que este sinalizador é habilitado, a atualização sempre usaria uma fusão de 3 vias
• As implantações existentes estariam presas sem um caminho de migração - a solução alternativa padrão que as pessoas parecem estar usando neste ponto é helm delete --purge seguida por helm reinstall portanto, pode não ser tão desagradável quanto parece à primeira vista.

Isso realmente resolveria o problema?

Algumas pessoas estão considerando a implementação de um operador para contornar essa limitação do leme. Isso seria uma pena. Veja https://github.com/istio/istio/issues/8841#issue -361871147

Saúde
-steve

Voltando ao comentário anterior de @bacongobbler :

1. Durante uma atualização, se estivermos criando um novo recurso e virmos que ele já existe, em vez disso, aplicamos essas alterações ao recurso existente ou o excluímos / recriámos.
   Isso é extremamente arriscado, pois o Helm pode excluir objetos que foram instalados por meio de outros pacotes ou por meio de kubectl create, nenhum dos quais os usuários podem querer.

Será que podemos mitigar esse risco tornando o novo comportamento opt-in? Em um determinado namespace, geralmente uso o helm exclusivamente e suspeito que esse seja o caso de muitos. Se eu pudesse dar ao Helm install / upgrade um sinalizador para informar que qualquer coisa no namespace fornecido que não faça parte de uma versão existente pode ser excluída / substituída, isso ajudaria?

Como você também disse "por meio de outros pacotes", presumo que você não queira que o Helm examine outras versões como parte da execução de uma versão, então minha sugestão não funcionaria, exceto no modelo single-release-per-namespace. Para responder a essa objeção, eu diria: se você deseja gerenciar vários pacotes em um namespace e ainda obter esse comportamento, crie um gráfico guarda-chuva cujo único propósito é especificar as dependências do gráfico que você deseja. Em seguida, use o novo sinalizador ("--exclusive"?) Ao implantar esse gráfico guarda-chuva.

Obviamente, isso não resolve o problema para todos os casos de uso, mas talvez seja uma solução alternativa.

@bacongobbler Eu poderia estar bem longe daqui. Estou enfrentando problemas semelhantes na atualização. A julgar pela dificuldade de resolver esse problema, me pergunto se algo mais fundamental precisa ser reconsiderado. Parte da complexidade parece ser devido ao fato de que Helm mantém sua própria versão da configuração conhecida, separada da fonte da verdade real que é o kubernetes. O sistema seria mais confiável se o Helm apenas mantivesse uma cópia dos gráficos de leme previamente implantados para fins de histórico e reversão, mas não a usasse durante a atualização? Em vez disso, o Helm obteria a verdade do próprio kubectl e sempre teria um diff bidirecional para executar?

Se um gráfico de leme disser que ele deve ter o recurso X, e kubectl vê um recurso X existente, então:

• Se o recurso existente estiver marcado como sendo controlado pelo Helm, o Helm executará a atualização necessária
• Se o recurso existente não estiver marcado como sendo controlado pelo Helm, o Helm falhará com uma mensagem de erro de limpeza (ou algum sinalizador de linha de comando pode ser usado para - forçar a atualização e fazer com que o Helm se aproprie do Recurso X existente).

Se o gráfico do helm diz que ele deve ter o recurso X e não há um de acordo com kubectl, o Helm o cria.

Se kubectl relatar que tem um recurso Y marcado como sendo controlado por este gráfico de leme, e não há recurso Y neste gráfico de leme, o helm exclui o recurso.

Quaisquer recursos não marcados como sendo controlados por este gráfico de leme são sempre ignorados pelo leme ao realizar a atualização, exceto no caso mencionado acima em que o gráfico de leme diz que os recursos X e X existem, mas não estão marcados.

Se por algum motivo a implantação de um gráfico de leme acontece e falha, e apenas metade dos recursos foram lançados, então, durante uma reversão, o leme usaria os arquivos de configuração armazenados da implantação anterior bem-sucedida e executaria exatamente o mesmo algoritmo, ou coisas pode ser deixado em um estado quebrado em relação a algum sinalizador de linha de comando do leme. Se o usuário tentar atualizar novamente, já que o kubernetes é usado como a fonte da verdade e não a última implantação bem-sucedida conhecida, ainda deve ser uma diferença de duas vias simples entre o novo gráfico de leme e o estado existente do sistema.

Também estamos vendo esse problema. Nossas etapas de reprodução:

1. helm install um gráfico que instala com sucesso uma implantação
2. Atualize o gráfico para incluir um recurso personalizado além da implantação existente
3. Altere a imagem do podspec de implantação para simular uma falha de implantação
4. helm install novo gráfico. Isso causará uma atualização contínua da implantação, que intencionalmente configuramos para falhar.
5. A instalação do leme deve falhar. Mas o recurso personalizado deve ser deixado no k8s etcd. (verifique usando kubectl )
6. (Neste ponto, o leme está em mau estado)
7. Corrija o gráfico - coloque uma imagem goot no podspec de implantação.
8. helm install . Esperamos que isso funcione, mas não funciona. Relata a mensagem "Nenhum recurso com o nome ___". O nome é o do recurso personalizado.
9. Recuperação: exclua o recurso personalizado residual usando kubectl . Agora helm install funcionará.

Observe que a primeira tentativa de helm install com um recurso personalizado recém-introduzido no gráfico deve falhar para entrar neste estado.

@ rbair23 tentamos isso antes e não funcionou. Existe o Grupo de Trabalho Apply que está procurando melhorar o estado do gerenciamento de objetos declarativos corrigindo kubectl apply, movendo a lógica do cliente para o servidor , mas isso ainda está em seus estágios iniciais. Kubectl (e tiller) precisam reter uma cópia da última configuração aplicada para realizar uma comparação. Você não pode diferenciar contra o estado ativo do cluster sem executar uma estratégia de patch de mesclagem de três vias, circulando de volta para este tíquete.

Como # 3275 foi fechado como duplicata: temos uma situação semelhante, como em # 3275

Já existe um job em execução my-long-running-job . E estamos tentando atualizar a versão:

>helm upgrade --install my-release --namespace my-environment my-chart --timeout 60
Error: UPGRADE FAILED: no Job with the name "my-long-running-job" found

O trabalho existe:

>kubectl -n=my-environment get jobs
NAME                                DESIRED   SUCCESSFUL   AGE
my-long-running-job                 1         0            16m

Excluindo esse trabalho:

>kubectl -n=my-environment delete job my-long-running-job
job.batch "my-long-running-job" deleted

Resolve esse impedimento:

>helm upgrade --install my-release --namespace my-environment my-chart --timeout 60
Error: UPGRADE FAILED: timed out waiting for the condition

Pelo menos a mensagem no Job with the name "my-long-running-job" found é enganosa, mas minha expectativa era de que o trabalho também seria atualizado.

Ainda vejo isso na v2.9.1 (versão estável lançada atualmente)

Não concordo que seja "muito perigoso" desistir de uma atualização. Acho que fazer isso é a solução correta.

Kubernetes é declarativo. Faça um instantâneo do estado do cluster antes de tentar fazer upgrade.
Se houver um erro no meio do caminho, volte para o instantâneo.
Se alguém tem scripts de hooks que deixariam o cluster em um estado ruim ao fazer isso, então é sua própria culpa. (Talvez isso também possa ser resolvido com ganchos de reversão)

Claro, seria ótimo se uma atualização fosse pré-executada e não fosse arquivada tanto quanto possível.
Erros em gráficos de dependências gerados por valores ou argumentos --set devem ser verificados antes de tentar mudar qualquer coisa, por exemplo. Coisas como esquecer de aumentar o número da versão também podem ser pré-executadas para evitar fazer alterações quando não funcionar.

Oi,

Tive o mesmo problema com:

Cliente: v2.10.0 + g9ad53aa
Servidor: v2.10.0 + g9ad53aa

Excluir serviceAccount, configMap e service era a única maneira de fazer o Helm atualizar a versão.

Oi,

temos o mesmo problema que @dilumr descrito ... com a versão 2.11.0:

Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}

Error: UPGRADE FAILED: no ConfigMap with the name "xxx" found

Encontrei isso na v2.9.1.

A atualização do gráfico que eu estava executando estava pulando algumas versões principais de um gráfico privado com muitas mudanças, então não tenho certeza do que exatamente desencadeou o erro no futuro, mas o motivo pelo qual a implantação originalmente terminou no estado FAILED foi que eu tinha uma bandeira --wait e ele expirou.

Terminamos com várias implantações duplicadas de FAILED em helm list mas a última implantação de trabalho foi DEPLOYED . A criação de novas implantações gerou No resource with the name x found .

Conseguiu consertar executando helm rollback até a última versão que estava no estado DEPLOYED em helm list . Depois dessa atualização, ele foi executado sem erros.

Confira https://github.com/helm/helm/pull/4871.

Como outros, pelo que parece, esse erro parece acontecer com mais frequência (não tenho certeza de sempre) para mim quando minha última implantação falhou e novos ativos dessa implantação foram deixados instalados.

Eu entendo como pode ser complicado e / ou indesejável desinstalar componentes de uma implantação do Helm com falha, mas qual é o comportamento ideal do Helm para esse tipo de situação?

Em primeiro lugar, acho que o Helm deve estar OK com namespaces e outros recursos já existentes, se estiver tentando (re) instalá-los. O Kubernetes tem tudo a ver com "fazer a configuração certa e deixar o kube descobrir como fazer o mundo corresponder à configuração".
Em segundo lugar, acho que Helm deve ser tudo ou nada. Se uma implantação falhar, o cluster deve estar no estado em que estava antes do início da implantação.
Se houver duas versões que desejam criar namespace X, há um problema de contagem de referência. Se houver um release que deseja criar o namespace X, mas ele já existe, há um problema de proveniência. No entanto, o helm pode registrar isso usando anotações nos objetos e fazer a coisa certa.

Também estou enfrentando esse problema com o helm 2.12.0 e o kubernetes 1.10.11 mais recentes, mesmo reverter para o último bom lançamento como @aguilarm sugeriu não funcionou, excluir também os recursos dos quais o helm reclama não ajuda, e após a atualização o comando falhar, ele deixa os mesmos recursos parcialmente recriados. Muito chato para um env ...

Tenho 2 clusters com ambiente muito semelhante, sendo a principal diferença entre os 2 o número total de nós. Em um caso, helm delete --purge seguido por helm install fresco funcionou, mas em outro não funcionou e ainda estou para descobrir uma maneira de trazer isso para as últimas alterações de modelo.

Existe algum HEC sobre isso?

Consegui contornar isso com helm rollback e especificando a revisão mais recente (aquela que falhou)

Tive o mesmo problema hoje,
Error: UPGRADE FAILED: no Service with the name "xxx-api" found
kubectl get svc -n stage | grep xxx-api
xxx-api ClusterIP 172.20.149.229 <none> 8300/TCP 19h
helm rollback funcionou.

Estamos experimentando isso com bastante regularidade ao fazer atualizações de leme - isso acontece depois de implantações bem-sucedidas, não apenas das que falharam. Não podemos helm delete --purge, pois esses são sistemas de produção com componentes não triviais que 1) não podem estar indisponíveis e 2) levariam muito tempo para se recuperar totalmente do zero para serem aceitáveis.

Veja o diagnóstico e a solução alternativa que postei acima. Deixe-me saber se isso funciona para você.

@bacongobbler Obrigado pela resposta. Essa é, na verdade, a solução alternativa que eu propus também e terá que ser suficiente por enquanto, mas estamos usando atualizações de leme dezenas de vezes por dia por meio de nosso CICD, então isso surge com frequência para ser uma dor de cabeça. Não tenho certeza de que o acima é toda a história, embora os recursos nomeados muitas vezes já existam, fazem parte de uma implantação bem-sucedida e não foram alterados na implantação atual - iirc é quase sempre o conjunto de recursos mais recente na última implantação bem-sucedida embora curiosamente.

+1 para @ajcann e obrigado @bacongobbler
Estou exatamente na mesma situação.
Nosso CICD é automatizado e muitas vezes as implantações são feitas por um bot slack para ambientes inferiores.
Quando ele falha, tenho que fazer rollback do helm e implantar novamente.
O problema não é consistente, mas frequente.
Para mim, isso acontece apenas durante a segunda implantação do gráfico / recurso até agora.
O recurso sempre existe.

observamos o mesmo problema. Isso acontece se você tiver um modelo, que é:

• em uma instrução {{if $condition -}}
• ou em um {{ range $index, $value := $array-}}

@jkroepke acaba de me dizer que o PR # 5143 oferece uma boa solução para isso. Quando o sinalizador --atomic é lançado na próxima versão secundária, você deve ser capaz de usá-lo para limpar ou reverter automaticamente quando houver um erro.

@bacongobbler dado que você esteve envolvido na maior parte das idas e vindas neste caso, há algo mais que pode ser feito para consertar totalmente isso, ou a sinalização --atomic seria suficiente?

Acho que @distorhead pode querer dar uma olhada nisso e ver se também resolve as preocupações que ele levantou em https://github.com/helm/helm/pull/4871. Fora isso, parece que --atomic deve resolver o problema, presumindo que você sempre use a sinalização --atomic .

Não acredito que tenha havido propostas de solução para resolver o problema quando você entra nesse estado específico, mas posso estar errado. Se a estratégia de mitigação para este problema é

• passar manualmente pelo estado ativo do cluster e corrigi-lo de acordo com a solução alternativa
• atualize para o Helm 2.13.0 e use helm upgrade --atomic daqui para frente

Então eu acho que é seguro fechar.

Esperançosamente, Helm 2.13.0 não está tão longe.
Este bug interrompe o CI se ocorrer um erro em algum lugar de uma versão.

Atomic não resolverá o problema

Gráfico de exemplo: https://github.com/distorhead/ex-helm-upgrade-failure

1. Verifique o mestre, execute o deploy.

git clone https://github.com/distorhead/ex-helm-upgrade-failure
cd ex-helm-upgrade-failure
helm upgrade --atomic --install --namespace myns myrelease .

O gráfico contém 2 implantações - myserver1 e myserver2 :

Release "myrelease" does not exist. Installing it now.
NAME:   myrelease
LAST DEPLOYED: Tue Feb  5 23:48:57 2019
NAMESPACE: myns
STATUS: DEPLOYED

RESOURCES:
==> v1beta1/Deployment
NAME       READY  UP-TO-DATE  AVAILABLE  AGE
myserver1  1/1    1           1          5s
myserver2  1/1    1           1          5s

1. Faça mudanças significativas. Exclua a implantação myserver1 do gráfico e modifique a implantação myserver2 com erro do usuário (exclua o campo de imagem, por exemplo):

git checkout break-atomic
git diff master

diff --git a/templates/deploy.yaml b/templates/deploy.yaml
index 198516e..64be153 100644
--- a/templates/deploy.yaml
+++ b/templates/deploy.yaml
@@ -1,21 +1,5 @@
 apiVersion: apps/v1beta1
 kind: Deployment
-metadata:
-  name: myserver1
-spec:
-  replicas: 1
-  template:
-    metadata:
-      labels:
-        service: myserver1
-    spec:
-      containers:
-      - name: main
-        command: ["/bin/bash", "-c", "while true ; do date ; sleep 1 ; done"]
-        image: ubuntu:16.04
----
-apiVersion: apps/v1beta1
-kind: Deployment
 metadata:
   name: myserver2
 spec:
@@ -28,4 +12,3 @@ spec:
       containers:
       - name: main
         command: ["/bin/bash", "-c", "while true ; do date ; sleep 1 ; done"]
-        image: ubuntu:16.04

1. Execute deploy:

git checkout break-atomic
helm upgrade --atomic --install --namespace myns myrelease .

Diga olá ao nosso amigo novamente:

UPGRADE FAILED
ROLLING BACK
Error: Deployment.apps "myserver2" is invalid: spec.template.spec.containers[0].image: Required value
Error: no Deployment with the name "myserver1" found

@bacongobbler @ thomastaylor312 @jkroepke

@distorhead qual era o seu comportamento esperado para este cenário?

Um pouco offtop sobre rollbacks, mas enfim.

Para aquelas pessoas que desejam usar o rollback, mas também não querem que o rollback ocorra imediatamente após a implantação como em --atomic por alguns motivos. Porque, por exemplo, não há como o usuário inspecionar manualmente o estado do cluster defeituoso após a falha e porque o sinalizador --wait não faz com que o helm registre nenhuma informação sobre falhas nos recursos que estão sendo implantados. Então, há uma maneira: reverter na próxima execução, antes da atualização (mais informações https://github.com/helm/helm/issues/3149#issuecomment-462271103)

Para reiterar o problema, bem como a solução alternativa:

Quando uma atualização que instala novos recursos falha, a versão entra em um estado FALHA e interrompe o processo de atualização. Na próxima vez que você chamar helm upgrade , o Helm fará uma comparação com a última versão IMPLEMENTADA. Na última versão DEPLOYED, este objeto não existia, então ele tenta criar o novo recurso, mas falha porque ele já existe. A mensagem de erro é completamente enganosa, como @arturictus aponta.

Isso pode ser facilmente contornado intervindo manualmente e excluindo o recurso que o erro relata como "não encontrado". Seguindo o exemplo que demonstrei em # 4223 (comentário) :

><> helm fetch --untar https://github.com/helm/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml                    # change the service name from "foo" to "foo-bar"
><> kubectl create -f foo/templates/service.yaml      # create the service
service "foo-bar" created
><> helm upgrade $(helm last) ./foo/
Error: UPGRADE FAILED: no Service with the name "foo-bar" found
><> kubectl delete svc foo-bar
service "foo-bar" deleted
><> helm upgrade $(helm last) ./foo/
Release "riotous-echidna" has been upgraded. Happy Helming!
...
><> kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
foo-bar      ClusterIP   10.104.143.52   <none>        80/TCP    3s
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   1h

Em outras palavras, a exclusão de recursos criados durante a versão FAILED contorna o problema.

Obrigado por colocar esta solução alternativa em conjunto @bacongobbler - é essencialmente o que chegamos como um processo também. Um problema doloroso aqui é durante atualizações complexas, muitos novos recursos - às vezes alguns níveis de dependências profundos - podem se encontrar neste estado. Ainda não encontrei uma maneira de enumerar totalmente esses estados de uma maneira automática, levando a situações em que é necessário falhar repetidamente em uma atualização para "pesquisar" todos os recursos relevantes. Por exemplo, recentemente uma dependência recém-adicionada tinha uma dependência em um gráfico postgresql. Para resolver este problema, foi necessário excluir um segredo, configmap, serviço, implantação e pvc - cada um encontrou o caminho mais longo.

Você poderia escrever um plugin semelhante a helm diff que enumeraria os modelos criados na última versão. Você pode até consumir pkg/kube diretamente do Helm. client.Update tem alguma lógica de negócios escrita para rastreamento / exclusão de recursos do helm que pode ser reutilizada obtendo as duas versões do Tiller e invertendo a ordem de comparação. target.Difference(original) deve fornecer um resultado de todos os recursos que foram introduzidos desde a versão anterior.

@bacongobbler Qual solução você recomendaria para pegar um aplicativo implantado como parte da versão A (por exemplo, uma versão maior composta de vários aplicativos) e separá-lo da versão A em sua própria versão (ou vice-versa) sem incorrer em qualquer tempo de inatividade (a solução alternativa para excluir recursos causaria algum tempo de inatividade) ... Tentar atualizar um recurso por meio de uma versão diferente resulta no erro descrito por este problema do Github.

parece que este novo gráfico foi instalado e substitui os gráficos antigos antes mesmo de uma implantação bem-sucedida. A mesma coisa com uma atualização com falha --install. Não deve ser instalado se o gráfico estiver errado.
Basta reverter para o estado anterior em caso de erro ou atualizar os gráficos de rebento em caso de sucesso.

Este é um processo que uso para me recuperar deste problema (até agora tem funcionado todas as vezes sem nenhum incidente ... mas tenha cuidado de qualquer maneira):

1. Execute helm list e descubra a revisão mais recente do gráfico afetado

   NAME        REVISION UPDATED                  STATUS  CHART              NAMESPACE
   fetlife-web 381      Thu Mar 15 19:46:00 2018 FAILED  fetlife-web-0.1.0  default
   

2. Vá a partir daí e encontre a revisão mais recente com o estado DEPLOYED
kubectl -n kube-system edit cm fetlife-web.v381 kubectl -n kube-system edit cm fetlife-web.v380 kubectl -n kube-system edit cm fetlife-web.v379 kubectl -n kube-system edit cm fetlife-web.v378
3. Depois de encontrar a última revisão IMPLANTADA, mude seu estado de DEPLOYED para SUPERSEDED e salve o arquivo
4. Tente fazer helm upgrade novamente, se for bem-sucedido, você terminou!
5. Se você encontrar um erro de atualização como este:
   Error: UPGRADE FAILED: "fetlife-web" has no deployed releases
   em seguida, edite o status da última revisão de FAILED para DEPLOYED
kubectl -n kube-system edit cm fetlife-web.v381
6. Tente fazer helm upgrade novamente, se falhar novamente, basta virar a mesa ...

@bacongobbler @michelleN
Existe algo que torna difícil melhorar a mensagem de erro para este problema?

Acredito que a mensagem de erro deve indicar que "há um conflito porque o recurso não foi criado pelo leme e a intervenção manual é necessária" e não "não encontrado". Somente essa pequena alteração no erro melhorará a experiência do usuário por uma boa margem.

@selslack Eu seria a favor de melhorar a mensagem de erro 👍

@michelleN Eu preparei um PR para alterar o texto do erro: # 5460.

Estou enfrentando esse problema e não tenho certeza de como resolvê-lo.

Tentei todas as etapas listadas por @reneklacan aqui: https://github.com/helm/helm/issues/1193#issuecomment -470208910

Infelizmente isso não funcionou. A única coisa que resolve o problema é deletar o recurso que gerou a mensagem de erro e então helm upgrade novamente, o que terá sucesso.

No entanto, a próxima atualização do leme irá falhar com o mesmo erro, e eu tenho que excluir o recurso novamente e atualizar ... isso não é sustentável ou bom.

Tenho dois ambientes nos quais uso o helm para implantar como parte de nosso processo de CI: um ambiente de controle de qualidade e um ambiente de produção.

O ambiente de controle de qualidade tinha o mesmo problema, então usei helm delete --purge e, em seguida, helm upgrade - isso resolveu o problema permanentemente.

No entanto, não posso fazer isso para o ambiente de produção - não posso simplesmente eliminá-lo e fazer um novo upgrade, portanto, atualmente, estou preso ao excluir o recurso antes de cada implantação. Tenho sorte de não ser um recurso de importação.

@zacharyw que erro você está enfrentando no momento? No resource with the name ... ou "fetlife-web" has no deployed releases ?

Você pode compartilhar alguma informação adicional que possa ajudar a depurar isso?

Talvez a saída de kubectl -n kube-system describe cm -l NAME=YOUR_RELEASE_NAME | grep -A1 STATUS= (substitua YOUR_RELEASE_NAME )

Sinta-se à vontade para me enviar um e-mail com mais informações se não quiser enviar spam para esse problema com dados potencialmente não relacionados (rene (at) klacan (ponto) sk).

Consulte https://github.com/helm/helm/issues/1193#issuecomment -419555433 para um possível diagnóstico e solução alternativa, @zacharyw.

@reneklacan É o erro no resource with the name ... . No nosso caso, adicionamos um ingresso, aparentemente funcionou, mas as atualizações subsequentes começaram a falhar com esse erro ... embora o ingresso já existisse.

O status da minha versão mais recente (depois de excluir o ingresso ofensivo e permitir que a atualização do leme o recrie) é DEPLOYED :

STATUS=DEPLOYED
VERSION=197

No entanto, se eu tentasse atualizar novamente, ele iria falhar.

@bacongobbler A menos que esteja mal-entendido, acho que já estou fazendo a solução alternativa nesse comentário: excluo o recurso e deixo que seja recriado ... o problema é que tenho que fazer isso todas as vezes.

@reneklacan em https://github.com/helm/helm/issues/1193#issuecomment -470208910 salvou minha vida.

É uma decepção que Helm falhe dessa forma. Excluir coisas em praticamente qualquer ambiente está longe de ser ideal.

Seria ótimo se o helm atualizasse seu próprio banco de dados quando esse tipo de erro aparecer e tente novamente.

Acredito que com o sinalizador --cleanup-on-fail habilitado, esse caso de erro deve desaparecer. Fechamento resolvido via # 4871 e # 5143.

Se houver mais problemas surgindo sem esses sinalizadores, reabra um novo problema. Obrigado!

O problema foi encerrado, mas pensei em adicionar um comentário sobre como lidar com o problema sem ter que excluir a liberação do helm ou as implantações em execução.

Portanto, reproduzi o problema com as seguintes etapas:

1. Instale o gráfico test-chart-failure com um modelo de serviço.
2. Adicione um subchart com um modelo de serviço que tenha uma string (por exemplo, "teste") na porta do serviço
3. Atualize o gráfico. Irá falhar com o erro Service in version "v1" cannot be handled as a Service: v1.Service.Spec: v1.ServiceSpec.Ports: []v1.ServicePort: v1.ServicePort.Port: readUint32: unexpected character: ...

Consegui atualizar depois de corrigir a porta para um número, sem executar helm delete , aplicando a sugestão em http://centosquestions.com/helm-how-to-delete-bad-deployment :

1. Encontrou a revisão com falha com helm history test-chart-failure
2. Excluído o mapa de configuração da revisão específica com kubectl delete cm -n kube-system test-chart-failure.v2
3. Executado helm upgrade com o gráfico corrigido