Remover completamente a liberação do Helm por meio de helm delete release funciona, mas não é uma solução viável.

Por que o Helm não pode simplesmente sobrescrever tudo o que está instalado atualmente? Não estamos vivendo em um mundo declarativo com o Kubernetes?

Acabei de receber a mesma coisa ... bastante novo para mim, parece ser um novo problema. excluir o recurso irá consertá-lo.
v2.7.2 com Kubernetes 1.7.7.
bonito funcionou antes ...

Eu tive esse problema - era devido a um PersistentVolume que eu criei. Para resolver, apaguei o PV e o PVC. Executou helm upgrade XXX XXX e funcionou bem. Provavelmente ainda algo que deveria ser investigado já que o PV existia.

Tenho a sensação de que pode estar relacionado a um PV ruim ... mas o erro é bastante enganador!
também alguns logs estranhos do tiller ... parece que ele está trabalhando na versão 2 ao mesmo tempo ...

acabei de tentar com 2.7.1 sem sorte ...

[main] 2017/12/21 15:30:48 Iniciando o Tiller v2.7.1 (tls = false)
[principal] 2017/12/21 15:30:48 GRPC ouvindo em: 44134
[principal] 21/12/2017 15:30:48 Sondas ouvindo em: 44135
[main] 2017/12/21 15:30:48 O driver de armazenamento é ConfigMap
[principal] 21/12/2017 15:30:48 O histórico máximo por lançamento é 0
[tiller] 2017/12/21 15:30:55 preparando atualização para xxx
[armazenamento] 2017/12/21 15:30:55 obtendo versão implantada do histórico "xxx"
[tiller] 2017/12/21 15:30:56 copiando valores de xxx (v65) para o novo lançamento.
[armazenamento] 2017/12/21 15:30:56 obtendo a última revisão de "xxx"
[armazenamento] 2017/12/21 15:30:56 obtendo histórico de lançamento para "xxx"
[tiller] 2017/12/21 15:30:59 renderizando o gráfico helm-xxx usando valores
2017/12/21 15:30:59 informações: o manifesto "helm-xxx / templates / scheduler-deploy.yaml" está vazio. Pulando.
21/12/2017 15:30:59 informações: o manifesto "helm-xxx / templates / recomposer-deploy.yaml" está vazio. Pulando.
21/12/2017 15:31:00 informações: o manifesto "helm-xxx / templates / recomposer-pvc.yaml" está vazio. Pulando.
21/12/2017 15:31:00 informações: o manifesto "helm-xxx / templates / scheduler-pvc.yaml" está vazio. Pulando.
2017/12/21 15:31:00 informações: o manifesto "helm-xxx / templates / scheduler-secret.yaml" está vazio. Pulando.
2017/12/21 15:31:00 informações: o manifesto "helm-xxx / templates / recomposer-secret.yaml" está vazio. Pulando.
[tiller] 2017/12/21 15:31:09 criando versão atualizada para xxx
[armazenamento] 2017/12/21 15:31:09 criando versão "xxx.v80"
[tiller] 2017/12/21 15:31:09 realizando atualização para xxx
[tiller] 2017/12/21 15:31:09 executando 0 ganchos de pré-atualização para xxx
[tiller] 2017/12/21 15:31:09 ganchos completos para pré-atualização xxx
[tiller] 2017/12/21 15:31:11 preparando atualização para xxx
[armazenamento] 2017/12/21 15:31:11 obtendo versão implantada do histórico "xxx"
[armazenamento] 2017/12/21 15:31:11 obtendo a última revisão de "xxx"
[armazenamento] 2017/12/21 15:31:11 obtendo histórico de lançamento para "xxx"
[tiller] 2017/12/21 15:31:18 renderizando o gráfico helm-xxx usando valores
2017/12/21 15:31:18 informações: o manifesto "helm-xxx / templates / scheduler-secret.yaml" está vazio. Pulando.
2017/12/21 15:31:18 informações: o manifesto "helm-xxx / templates / scheduler-pvc.yaml" está vazio. Pulando.
2017/12/21 15:31:19 informações: o manifesto "helm-xxx / templates / scheduler-deploy.yaml" está vazio. Pulando.
[kube] 2017/12/21 15:31:28 recursos de criação do manifesto atualizado
[tiller] 2017/12/21 15:31:46 criando versão atualizada para xxx
[armazenamento] 2017/12/21 15:31:46 criando versão "xxx.v81"
[tiller] 2017/12/21 15:31:47 realizando atualização para xxx
[tiller] 2017/12/21 15:31:47 executando 0 ganchos de pré-atualização para xxx
[tiller] 2017/12/21 15:31:47 ganchos completos para pré-atualização xxx
[kube] 2017/12/21 15:31:49 verificando 7 recursos para alterações
[kube] 2017/12/21 15:31:49 Parece que não há alterações para o segredo "xxx-helm-xxx-nginx-secret"
[kube] 2017/12/21 15:31:50 Parece que não há alterações para o segredo "xxx-application-secret"
[kube] 2017/12/21 15:31:50 Parece que não há mudanças para o segredo "azul-secreto"
[kube] 2017/12/21 15:31:51 Parece que não há alterações para o ConfigMap "xxx-helm-xxx-nginx-config"
[kube] 2017/12/21 15:31:51 Parece que não há alterações para o ConfigMap "xxx-application-config"
[kube] 2017/12/21 15:31:51 Parece que não há alterações para o serviço "xxx-application-svc"
[kube] 2017/12/21 15:31:51 Parece que não há alterações para StatefulSet "xxx-application"
[tiller] 2017/12/21 15:31:51 executando 0 ganchos pós-atualização para xxx
[tiller] 2017/12/21 15:31:51 ganchos completos para pós-atualização xxx
[armazenamento] 2017/12/21 15:31:51 atualizando versão "xxx.v65"
[tiller] 2017/12/21 15:31:51 atualizando status para versão atualizada para xxx
[armazenamento] 2017/12/21 15:31:51 atualizando versão "xxx.v80"
[kube] 2017/12/21 15:31:57 recursos de criação do manifesto atualizado
[kube] 2017/12/21 15:32:10 verificando 11 recursos para alterações
[kube] 2017/12/21 15:32:10 Parece que não há alterações para o segredo "xxx-helm-xxx-nginx-secret"
[tiller] 2017/12/21 15:32:10 aviso: atualização "xxx" falhou: nenhum recurso com o nome "xxx-recomposer-secret" encontrado
[armazenamento] 2017/12/21 15:32:10 atualizando versão "xxx.v65"
[armazenamento] 2017/12/21 15:32:10 atualizando versão "xxx.v81"

parece que fica confuso em fazer para lançar ao mesmo tempo ...

apenas reaplicou a mesma configuração duas vezes ...

[tiller] 2017/12/21 15:50:46 preparando atualização para xxx
[armazenamento] 2017/12/21 15:50:46 obtendo versão implantada do histórico "xxx"
[armazenamento] 2017/12/21 15:50:46 obtendo a última revisão de "xxx"
[armazenamento] 2017/12/21 15:50:46 obtendo histórico de lançamento para "xxx"
[tiller] 2017/12/21 15:50:50 renderizando o gráfico helm-xxx usando valores
21/12/2017 15:50:50 informações: o manifesto "helm-xxx / templates / scheduler-pvc.yaml" está vazio. Pulando.
2017/12/21 15:50:50 informações: o manifesto "helm-xxx / templates / recomposer-deploy.yaml" está vazio. Pulando.
21/12/2017 15:50:50 informações: o manifesto "helm-xxx / templates / scheduler-secret.yaml" está vazio. Pulando.
2017/12/21 15:50:50 informações: o manifesto "helm-xxx / templates / scheduler-deploy.yaml" está vazio. Pulando.
2017/12/21 15:50:50 informações: o manifesto "helm-xxx / templates / recomposer-secret.yaml" está vazio. Pulando.
21/12/2017 15:50:50 informações: o manifesto "helm-xxx / templates / recomposer-pvc.yaml" está vazio. Pulando.
[tiller] 2017/12/21 15:50:58 criando versão atualizada para xxx
[armazenamento] 2017/12/21 15:50:58 criando versão "xxx.v85"
[tiller] 2017/12/21 15:50:59 realizando atualização para xxx
[tiller] 2017/12/21 15:50:59 executando 0 ganchos de pré-atualização para xxx
[tiller] 2017/12/21 15:50:59 ganchos completos para pré-atualização xxx
[kube] 2017/12/21 15:51:13 recursos de criação do manifesto atualizado
[kube] 2017/12/21 15:51:22 verificando 7 recursos para alterações
[kube] 2017/12/21 15:51:22 Parece que não há alterações para o segredo "xxx-helm-xxx-nginx-secret"
[kube] 2017/12/21 15:51:23 Parece que não há alterações para o segredo "xxx-application-secret"
[kube] 2017/12/21 15:51:23 Parece que não há alterações para o segredo "azul-secreto"
[kube] 2017/12/21 15:51:23 Parece que não há alterações para o ConfigMap "xxx-helm-xxx-nginx-config"
[kube] 2017/12/21 15:51:23 Parece que não há alterações para o ConfigMap "xxx-application-config"
[kube] 2017/12/21 15:51:24 Parece que não há alterações para o serviço "xxx-application-svc"
[kube] 2017/12/21 15:51:24 Excluindo "xxx-recomposer-secret" em xxx ...
[kube] 2017/12/21 15:51:24 Falha ao excluir "xxx-recomposer-secret", err: secrets "xxx-recomposer-secret" não encontrado
[kube] 2017/12/21 15:51:24 Excluindo "xxx-recomposer-config" em xxx ...
[kube] 2017/12/21 15:51:24 Falha ao excluir "xxx-recomposer-config", err: configmaps "xxx-recomposer-config" não encontrado
[kube] 2017/12/21 15:51:24 Excluindo "xxx-recomposer-pv" em ...
[kube] 2017/12/21 15:51:24 Falha ao excluir "xxx-recomposer-pv", erro: persistentvolumes "xxx-recomposer-pv" não encontrado
[kube] 2017/12/21 15:51:24 Excluindo "xxx-recomposer-pvc" em xxx ...
[kube] 2017/12/21 15:51:24 Falha ao excluir "xxx-recomposer-pvc", err: persistentvolumeclaims "xxx-recomposer-pvc" não encontrado
[kube] 2017/12/21 15:51:24 Excluindo "xxx-recomposer" em xxx ...
[kube] 2017/12/21 15:51:24 Usando reaper para excluir "xxx-recomposer"
[kube] 2017/12/21 15:51:24 Falha ao excluir "xxx-recomposer", err: deployments.extensions "xxx-recomposer" não encontrado
[tiller] 2017/12/21 15:51:24 executando 0 ganchos pós-atualização para xxx
[tiller] 2017/12/21 15:51:24 ganchos completos para pós-atualização xxx
[armazenamento] 2017/12/21 15:51:24 atualizando versão "xxx.v68"
[tiller] 2017/12/21 15:51:24 atualizando o status para a versão atualizada para xxx
[armazenamento] 2017/12/21 15:51:24 atualizando versão "xxx.v85"
[armazenamento] 2017/12/21 15:51:25 obtendo a última revisão de "xxx"
[armazenamento] 2017/12/21 15:51:25 obtendo histórico de lançamento para "xxx"
[kube] 2017/12/21 15:51:38 Fazendo get for Secret: "xxx-helm-xxx-nginx-secret"
[kube] 2017/12/21 15:51:39 obter pod de relação do objeto: xxx / Secret / xxx-helm-xxx-nginx-secret
[kube] 2017/12/21 15:51:39 Fazendo get for Secret: "xxx-application-secret"
[kube] 2017/12/21 15:51:39 obter pod de relação do objeto: xxx / Secret / xxx-application-secret
[kube] 2017/12/21 15:51:39 Fazendo get for Secret: "azure-secret"
[kube] 2017/12/21 15:51:39 obter pod de relação do objeto: xxx / Secret / azure-secret
[kube] 2017/12/21 15:51:39 Fazendo get para ConfigMap: "xxx-helm-xxx-nginx-config"
[kube] 2017/12/21 15:51:39 obter pod de relação do objeto: xxx / ConfigMap / xxx-helm-xxx-nginx-config
[kube] 2017/12/21 15:51:39 Fazendo get para ConfigMap: "xxx-application-config"
[kube] 2017/12/21 15:51:39 obter pod de relação do objeto: xxx / ConfigMap / xxx-application-config
[kube] 2017/12/21 15:51:39 Fazendo get for Service: "xxx-application-svc"
[kube] 2017/12/21 15:51:39 obter pod de relação do objeto: xxx / Service / xxx-application-svc
[kube] 2017/12/21 15:51:39 Fazendo get para StatefulSet: "xxx-application"
[kube] 2017/12/21 15:51:39 obter pod de relação do objeto: xxx / StatefulSet / xxx-application

pode estar relacionado a # 2941

um dito em outro tópico, uma das maneiras de corrigir o problema era excluir os configmaps com erros ... parece fazer isso por mim atualmente ...

Isso é ótimo e elegante. Até aquele momento, quando você tiver que deletar algo crítico de um namespace de produção. O que, coincidentemente, aconteceu comigo agora há pouco. : c

Eu também enfrentei o problema quando atualizamos uma versão, se houver vários status DEPLOYED desta versão, tenho que corrigi-lo excluindo os configmaps correspondentes.

Mesmo problema. Tudo estava bem ontem e fiz várias atualizações. Hoje acabei de adicionar um novo yaml com service e deployment bloco separado por --- e a atualização falhou.

O interessante é que o helm criou service e depois reclamou (e não fez a implantação).
Eu comentei service e apenas executei a atualização com o bloco deployment - funcionou. No entanto, o helm não excluiu o serviço - o que deveria acontecer ao ser removido do arquivo yaml.

Atualização : eu excluí manualmente o service , descomentei-o do yaml e executei a atualização - desta vez funcionou perfeitamente!

Eu estava cometendo exatamente este erro. Parece que o problema está relacionado a modelos com vários objetos API semelhantes ao que @amritb viu. No meu caso, eu tinha um modelo que tinha vários objetos de API que podiam ser ativados e desativados de maneira semelhante a:

{{ if .Values.enabled }}
---
...

Dividir isso em seu próprio arquivo de modelo e limpar os objetos órfãos que o helm criou e esqueceu resolveu o problema para mim. Parece que há um bug em como o helm obtém a configuração anterior se o número de objetos por modelo mudar entre as versões.

Adicionando outro ponto de dados: parece que estou tendo exatamente o mesmo problema que @awwithro. Estamos usando um loop jinja para criar vários cronjobs por meio de um modelo e, quando uma nova atualização fez com que esse loop preenchesse um cronjob adicional, encontramos o bug. Parecia disparar # 2941 também (ou possivelmente um bug causa o outro), e deletar o configmaps zumbi corrige isso.

Apenas preso nisso, mesmo sem usar configmaps

Alguma cor extra para quem pode estar preso:
Eu estava correndo para isso ao apresentar novos subcharts e objetos para o meu lançamento. Consegui resolver verificando cada tipo de objeto que estava sendo adicionado e excluindo todos os objetos existentes que causariam uma colisão de nomenclatura.

Isso parece estar de acordo com a evidência de outros de que a exclusão é a única maneira de resolver agora 😕

Também percorrendo este = \

Eu também precisava excluir os recursos afetados. Não é bom para um ambiente de produção = _ (

Estou vendo algo que acho semelhante. O problema parece ser que helm upgrade não - reutiliza os valores da implantação anterior. Se eu especificar o mesmo conjunto de valores na linha de comando que a instalação inicial fez, helm upgrade funcionará. Não sei se isso ajuda (ou qualquer outra pessoa pode confirmar).

Como @amritb , depois de excluir manualmente o objeto no qual o helm falhou inicialmente, ele teve êxito após a próxima atualização. Eu não experimentei o # 2941.

O mesmo problema ao usar o leme 2.8.0 . Versões client=v1.8.6 e server=v1.8.5-gke.0 Kubernetes.

$ helm upgrade bunny ./app --debug
[debug] Created tunnel using local port: '54274'

[debug] SERVER: "127.0.0.1:54274"

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

Mas o configmap existe em $ kubectl get configmap . Se eu excluir manualmente o configmap, ele funciona, mas da próxima vez ele falhará novamente.

Aqui está o configmap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ template "proxy.fullname" . }}-config
  # namespace: {{ .Release.Namespace }} # I've tried adding and removing it
  labels: # labels are the same as labels from $ kubectl describe configmap bunny-proxy-config
    app: {{ template "proxy.name" . }}
    chart: {{ template "proxy.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
data:
  asd: qwe

Excluí a versão e instalei novamente. Além disso, estava usando a versão da API extensions/v1beta para implantação, mudei para apiVersion: apps/v1beta2 , não sei se isso ajudou ou não.
Também estou executando tiller localmente.

Agora parece que tudo está funcionando.

Isso é muito fácil de reproduzir, acontece se houver um erro no manifesto.

Como temos resource1 e resource2, resource2 depende primeiro. Quando atualizamos a versão, o recurso1 é criado (por exemplo, PV e PVC), mas o recurso2 falha. Depois disso, apenas a exclusão do resource1 ajuda, pois o helm sempre relata um problema na atualização (PersistentVolume com nome ... não encontrado)

Tivemos o mesmo problema (o recurso que nos trouxe foi o Secrets). Remover os novos segredos e reimplantá-los corrigiu-os.

Observe que, por causa das falhas, agora temos 11 versões diferentes quando executamos helm list , 10 FALHADAS e 1 IMPLANTADA. Isso não era esperado, certo? O mesmo problema que parece aqui: https://github.com/kubernetes/helm/issues/2941

Isso praticamente tornou o helm inutilizável para implantações de produção regulares para nós :( Atualmente estamos investigando coisas como passar --dry-run para o helm e canalizá-lo para kubectl se aplicam ... Uma vez que isso parece afetar apenas um subconjunto de usuários , não tenho certeza do que estamos fazendo de errado :(

Depois de rastrear os registros do leme, descobri que o leme estava tentando atualizar uma versão antiga ao mesmo tempo:

[storage] 2018/02/14 18:25:40 updating release "s2osf.v10"
[storage] 2018/02/14 18:25:40 updating release "s2osf.v44"

Excluir o antigo configmap para s2osf.v10 e depois atualizar funcionou.

Client: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}

Tendo o mesmo problema que @binoculars :

[storage] 2018/02/15 10:20:50 updating release "control.v136"
[storage] 2018/02/15 10:20:50 updating release "control.v226"

Causando problemas estranhos com UPGRADE FAILED: no Secret with the name "foobar" found .
Eu até tentei deletar esse segredo, o que causou erros em algum configmap, e na terceira execução ele voltou a reclamar do segredo anterior.

Isso pode ter sido acionado após a atualização do helm 2.7.x para 2.8.1.

Client: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}

se seu último recurso for excluir a versão antiga, pode haver uma solução menos destrutiva, como meu comentário https://github.com/kubernetes/helm/issues/3513#issuecomment -366918019

basicamente encontrando aquela revisão antiga nos logs e editando o configmap manualmente onde o tiller armazena o status implantado. Não deve haver duas revisões com o status DEPLOYED afaik.

Encontrou uma nova solução para este problema.

kubectl -n kube-system edit cm name_of_your_release.v2 , onde v2 é o último número de revisão marcado como FALHOU em helm list . Você também pode querer editar uma das versões DEPLOYED e alterar o status para SUPERSEDED, para que não tenhamos duas versões implementadas ao mesmo tempo.

@zuzzas foi a isso que me referi. Funcionou para mim também

@balboah, o problema é que temos apenas uma implantação no estado DEPLOYED, mas se não for das mais recentes (marcadas como FAILED, na maioria dos cenários), ela ainda travará. O problema não parece relacionado a ter duas ou mais implantações no estado DEPLOYED na maioria de nossos casos.

@zuzzas você tem muitos lançamentos no mesmo namespace ou apenas um? Uma vez, tive um problema com duas versões atualizando os mesmos objetos, então eles entrarão em conflito entre si.

Se for apenas uma, quantas falhas você teve até a versão implantada? como você verificou que é o único implantado?

Acreditamos que isso foi corrigido (no futuro) por meio do número 3539. Por favor, reabra se acontecer de estarmos errados. :)

Obrigado a todos pelo seu trabalho nisso!

Observe que isso não foi corrigido para gráficos existentes neste estado; você ainda precisará remover as versões antigas que estão no estado IMPLICADO para que as coisas funcionem novamente. @balboah apenas evitou o caso em que você pode entrar no estado "vários lançamentos marcados como IMPLANTADO". :)

Hm, ainda tenho esse problema no Helm 2.8.2 (não o mais recente, mas tentei com o 2.9.0 e dá o mesmo erro.) Normalmente, excluir o recurso ofensivo manualmente pode corrigi-lo, embora muitas vezes ele se espalhe em vários recursos que todos precisam ser excluídos antes de serem atualizados com sucesso.

Eu tenho um gráfico de leme grande com dependências aninhadas; pode ser isso?

Estou vendo o mesmo problema com clusterrolebinding. Eu adicionei o novo recurso ao meu gráfico e upgrade , bem como upgrade --install , falharia com Error: UPGRADE FAILED: no ClusterRoleBinding with the name "test-clusterrolebinding" found

Estou tendo o mesmo problema que @ramyala com ClusterRole. O ClusterRole existe, mas a criação de RoleBinding falha com esse erro.

No Helm 2.9.1 encontrei o mesmo problema:

helm upgrade --install --namespace my-namespace my-stack stack
Error: UPGRADE FAILED: no ConfigMap with the name "my-stack-my-app" found

Enquanto vejo este ConfigMap no meu cluster.

Eu experimento esse problema se eu tiver vários recursos com ganchos em um arquivo

+1, isso está acontecendo novamente com 2.9.1. Por favor, reabra.

Remarcando isso como um bug. Não temos certeza do que causou essa regressão, mas se alguém puder fornecer etapas sobre como reproduzir esse bug no 2.9.1, isso seria muito apreciado.

@bacongobbler

Também estou vendo isso ao tentar implantar um novo Ingress em meu gráfico de comando. Reconheço que sou novo no Ingress, mas parece que está correto com base em todos os exemplos e estou fazendo outras coisas sobre o helm / k8s há alguns meses.

Já implantei o gráfico de leme stable/nginx-ingress então o controlador está presente. O erro parece sugerir que ele está tentando encontrar o que estou tentando criar. Aqui está o comando que estou executando:

helm upgrade some-existing-release-name -i --set imageTag=$TAG-$BUILD_NUMBER --namespace=default ./deploy/helm onde deploy/helm contém meus manifestos de gráfico.

Error: UPGRADE FAILED: no Ingress with the name "my-ingress" found

yaml:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  labels:
    app: my-app
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - host: {{ $.Values.appDomain }}
    http:
      paths:
      - path: /*
        backend:
          serviceName: web-app
          servicePort: 80
      - path: /api/*
        backend:
          serviceName: api
          servicePort: 8080

ATUALIZAR
Eu removi /* de ambos os meus caminhos e não deu mais um erro ao tentar atualizar / instalar. Talvez essa não seja uma sintaxe válida

Oi,
Aqui estão as etapas que introduziram o problema em meu env:

1. Tive um gráfico de leme implantado e atualizado várias vezes.
2. Novo objeto CronJob criado no gráfico e atualizado novamente - o cron job foi criado com sucesso.
3. Todas as próximas atualizações estão falhando com o erro relatado "Erro: FALHA NO UPGRADE: nenhum CronJob com o nome“ cronjob-name ”encontrado"

Também estou vendo o problema quando adiciono um segredo que não existia anteriormente. Tentei adicionar um "db-credentials"
segredo que levou a:

Error: UPGRADE FAILED: no Secret with the name "db-credentials" found

correção potencialmente relevante: # 4146

se alguém com esse erro pudesse testar esse PR e ver se ele corrige isso, poderíamos confirmar que é provável que seja uma regressão na API k8s e seguir em frente com a correção. Obrigado!

Não posso confirmar 100% se isso sempre será reproduzido, mas percebi que isso tende a acontecer nas seguintes situações:

1. Eu atualizo um gráfico do Helm, incluindo um novo recurso
2. Essa atualização falha, mas o recurso foi criado como parte da atualização que falhou
3. Todas as atualizações subsequentes falham

Se eu fizer um helm rollback para a última implantação bem-sucedida e, em seguida, tentar atualizar novamente, parece que funciona.

Parece muito fácil reproduzi-lo manualmente, sem tentar intencionalmente atualizar um gráfico com alterações prejudiciais (por exemplo, modificar objetos de trabalho imutáveis):

1. Pegue um gráfico e implante-o (mas omita um recurso, digamos um serviço)
2. Adicione o recurso omitido manualmente (por exemplo, com "kubectl create"), mas com o nome correspondente à versão
3. Adicione o recurso omitido de volta ao gráfico e tente atualizá-lo, o helm deve relatar "FALHA NO ATUALIZAÇÃO: nãocom o nomeencontrado"

As etapas são diferentes, mas a causa raiz parece a mesma. Corrija-me se eu estiver errado na suposição, mas me parece que a última revisão da versão DEPLOYED não tem informações sobre o recurso específico, seja porque foi adicionado "fora" do Helm (manualmente, por exemplo) ou porque a última atualização falhou em alguma etapa (digamos, na atualização de um trabalho imutável), ao mesmo tempo implantando outros objetos e, em seguida, gravando-os na revisão FALHA (mas ainda sem qualquer trilha na revisão DEPLOYED o que é esperado, caso contrário, significaria alterar o histórico) . Na próxima execução, o cliente kube do Tiller vê os recursos no cluster, o que significa que eles já devem estar implantados e, portanto, registrados, ele verifica a última revisão DEPLOYED (parece que a revisão FAILED não foi contatada) e não os vê listados lá portanto, ele relata o erro.

@bacongobbler Eu testei o # 4146 com uma imagem de rebento personalizada e corrigiu este problema! Para outras pessoas que estão procurando uma solução, você pode aplicar o patch no problema no mestre atual e compilar:

make bootstrap build docker-build

Você terá que fazer o upload da imagem do rebento para o seu repo e reinstalar o rebento para o seu cluster. Consegui fazer uma reinicialização forçada e reinstalar sem destruir as versões atuais.

$GO_HOME/src/k8s.io/helm/bin/helm init -i gcr.io/my-repo/tiller:1 --service-account tiller

obrigado @ramyala por testar a correção! Mencionarei isso na chamada de dev amanhã e verei se algum dos outros mantenedores do núcleo vê algum caso extremo que pode surgir com o patch. Se não, vamos nos fundir.

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

No interesse de manter as coisas todas juntas, fecharei isso como uma duplicata do # 1193, pois os dois tickets são idênticos. Relate quaisquer descobertas lá para que possamos trabalhar em um único tíquete. Obrigado!

Aviso: esta informação é um pouco superficial e não consigo entender, mas caso seja útil para alguém, resolvi esse problema alterando meu seletor de serviço de:

selector:
    app: {{ template "mything.name" . }}

para

selector:
    app: mything

Talvez haja algum tipo de problema com o uso de uma variável neste contexto?

Experimente helm delete RELEASE_NAME --purge
e instale-o novamente.

Eu também estou acertando esse problema. Eu tentei adicionar subchart com uma implantação em meu gráfico, ele teve sucesso ao atualizar com helm upgrade chart chart-1.0.1.tgz apenas pela primeira vez, depois disso, quando tentei helm upgrade chart chart-1.0.1.tgz ele falhou com o erro Error: UPGRADE FAILED: no Deployment with name "subchart-deployment" found

Client: &version.Version{SemVer:"v2.12.0", GitCommit:"d325d2a9c179b33af1a024cdb5a4472b6288016a", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.12.0", GitCommit:"d325d2a9c179b33af1a024cdb5a4472b6288016a", GitTreeState:"clean"}

Os registros do leme do leme registram apenas o mesmo erro. Alguém está passando por isso também?

Mesmo problema. Tudo estava bem ontem e fiz várias atualizações. Hoje acabei de adicionar um novo yaml com service e deployment bloco separado por --- e a atualização falhou.

O interessante é que o helm criou service e depois reclamou (e não fez a implantação).
Eu comentei service e apenas executei a atualização com o bloco deployment - funcionou. No entanto, o helm não excluiu o serviço - o que deveria acontecer ao ser removido do arquivo yaml.

Atualização : eu excluí manualmente o service , descomentei-o do yaml e executei a atualização - desta vez funcionou perfeitamente!

oi, eu também tenho esse problema e não consigo resolvê-lo, você gostaria de me dar algumas dicas.

consulte https://github.com/helm/helm/issues/1193#issuecomment -419555433.

Apenas confirmando que estou testemunhando o mesmo problema e a causa também é conforme indicado anteriormente.

Adicionado um novo segredo, referenciado em um volume (sintaxe inválida). A atualização falhou, as atualizações subsequentes falharam com o erro acima.

Os segredos da lista mostraram que ele havia sido criado. Segredo excluído manualmente e a atualização foi concluída com êxito.

Mesmo, @thedumbtechguy. Eu encontro esse problema rotineiramente. É especialmente divertido quando Helm decide que você precisa deletar _todos_ seus segredos, configmaps, funções, etc. A atualização se torna um jogo de maluquices com uma lista cada vez maior de argumentos para kubectl delete . Eu deveria ter jogado a toalha nessa tarefa sísifo meses atrás, mas é tarde demais para isso agora. Espero que isso e as dezenas de problemas semelhantes possam ser corrigidos!

Estou usando o leme há uma semana e já enfrentei tudo que foi delineado
aqui https://medium.com/@7mind_dev/the -problems-with-helm-72a48c50cb45

Muita coisa precisa ser consertada aqui.

Na sexta-feira, 15 de março de 2019, às 22h49, Tom Davis [email protected] escreveu:

Mesmo, @thedumbtechguy https://github.com/thedumbtechguy . Eu encontro
este problema rotineiramente. É especialmente divertido quando Helm decide que você precisa
exclua todos os seus segredos, configmaps, funções, etc. A atualização torna-se um
jogo de wack-a-mole com uma lista cada vez maior de argumentos para kubectl
excluir. Eu deveria ter jogado a toalha nesta tarefa sísifo meses
atrás, mas agora é tarde para isso. Claro, espero que este e as dezenas de
problemas semelhantes podem ser corrigidos!

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

Eu experimentei o mesmo com Helm v2.10. Eu já tinha um gráfico implantado, adicionei outro configMap ao gráfico. Ele relatou que a implantação falhou porque não foi possível localizar o configMap "blah". Eu fiz

helm upgrade <NAME> chart --debug --dryrun 

Para verificar se o configMap estava realmente sendo renderizado, estava. Verifiquei os configMaps no cluster e o encontrei lá. Excluído o blah configMap, execute novamente a atualização e funcione.

https://github.com/helm/helm/pull/5460 deve esclarecer melhor a mensagem de erro daqui para frente.

Ponto justo.

$ helm upgrade linting-unicorn testrail                                                                                                                                                                                        
Error: UPGRADE FAILED: no ConfigMap with the name "linting-unicorn-testrail-php-config" found

Mantenha o bom trabalho da equipe de leme.

Caso isso seja um grande problema para outra pessoa, pensei em apontar https://github.com/helm/helm/pull/4871 deve corrigir esses problemas.

Observe que parece que ainda não foi aprovado pela equipe do Helm. Além disso, havia algumas preocupações sobre os recursos de exclusão automática. Basta mencioná-lo caso alguém queira compilá-lo a partir do código-fonte e tentar.

Tendo o mesmo problema e a única solução alternativa parece ser helm delete --purge release e instale novamente!

Eu tive o mesmo problema. @fbcbarbosa parece que foi fundido há 2 semanas. Esperançosamente, deve fazer parte da próxima versão

Tendo o mesmo problema e a única solução alternativa parece ser helm delete --purge release e instale novamente!

Uma opção menos destrutiva é fazer um helm rollback para a / atual / versão (ou seja, em 0 etapas). Não posso garantir o sucesso, mas para nós, até agora, sempre conseguiu desviar as coisas com sucesso.

Há uma ideia se isso vai estar no próximo lançamento e se vai sair quando estiver chegando?

5460 foi fundido 2 meses atrás, o que significa que deveria estar no leme 2.14.0.

Eu consertei o problema por

1. exclua os recursos que reclamaram de "atualização do leme". (Diz Não encontrado, mas na verdade ele pode ser encontrado). Não exclua todo o lançamento, caso contrário, se estiver em produção, você ficará completamente ferrado.
2. refaça a atualização do leme. Agora, desta vez, deve ser "Happy Helming" aparece. :)

Encontramos esse problema no PROD, quando um requisito para nosso gráfico de leme guarda-chuva adicionava um mapa de configuração baseado em uma condição. Para nós, a solução alternativa era

helm rollback <some revision that's acceptable>
helm upgrade <desired version>

Para nós, um simples rollback para a revisão atual sempre funcionou:

helm ls
helm rollback <NAME> <current REVISION>

@tobypeschel , você tem ideia de como sua correção funciona?