Helm: O `helm delete` relata" conexão perdida com o pod "" Erro: o transporte está fechando "apesar do aparente sucesso
cliente e servidor helm 2.6.1
k8s 1.7.4 (mesmo comportamento com 1.7.0 também)
Já vi várias questões discutindo "conexão perdida com o pod", mas nenhuma que reconheço que corresponda ao nosso caso.
Quando executo helm delete --purge _releaseName_ relatórios de helm
portforward.go:178] lost connection to pod
Error: transport is closing
No entanto, o delete parece ter sido bem-sucedido. Todos os recursos k8s definidos pelo gráfico são limpos conforme o esperado. O registro do leme é semelhante a este:
[storage] 2017/09/28 14:14:19 getting release history for "xxx"
[tiller] 2017/09/28 14:14:19 uninstall: Deleting xxx
[tiller] 2017/09/28 14:14:19 executing 0 pre-delete hooks for xxx
[tiller] 2017/09/28 14:14:19 hooks complete for pre-delete xxx
[storage] 2017/09/28 14:14:19 updating release "xxx.v1"
(many lines of "Starting delete for yyy" and "Using reaper for deleting yyy" omitted here)
[tiller] 2017/09/28 14:16:42 executing 0 post-delete hooks for xxx
[tiller] 2017/09/28 14:16:42 hooks complete for post-delete xxx
[tiller] 2017/09/28 14:16:42 purge requested for xxx
[storage] 2017/09/28 14:16:42 deleting release "xxx.v1"
É o fim do registro. Não contém erros ou exceções.
k8s não relata nenhuma reinicialização do pod do leme.
O tempo decorrido, de fora e do log, é de cerca de 2m 30s, bem abaixo do valor de tempo limite padrão para a operação delete .
Onde mais posso procurar mais informações sobre o que está errado e está causando esse erro?
Obrigado.
tjquinno
Todos 3 comentários
Isso se parece com https://github.com/kubernetes/helm/issues/2025 se estiver bem abaixo do tempo limite padrão (5 minutos). Você pode verificar o balanceador de carga que está à frente de sua API mestre do kubernetes e comentar sobre esse problema no futuro? Dessa forma, podemos manter a discussão em um só lugar. Obrigada! ❤️
bacongobbler
em 29 set. 2017
Também vi o erro Error: transport is closing quando executei helm install , e depois de fazer rm -rf ~/.helm , o erro não foi mais visto. Acho que deletar o cache do helm ( rm -rf ~/.helm ) pode resolver o erro.
vhosakot
em 30 mai. 2018
Consegui corrigir isso adicionando as informações do host do leme ao comando de instalação do helm.
--host=10.111.221.14:443
Você pode obter o seu Tiller IP por meio deste método
$ kubectl get svc -n kube-system tiller-deploy
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
tiller-deploy ClusterIP 10.111.221.14 <none> 44134/TCP 34h
Exemplo de comando completo
helm install stable/grafana --name=grafana --host=10.111.221.14:4413
Eu sei que isso é meio que uma solução alternativa, mas todas as outras funções do leme estão funcionando corretamente após a instalação por meio desse método. Não precisei adicionar as informações do host novamente após a instalação inicial para realizar atualizações ou reversões. Espero que isto ajude!
castironclay
em 21 abr. 2019
Questões relacionadas
danielcb
·
3Comentários
macknight
·
3Comentários
KavinduZoysa
·
3Comentários
libesz
·
3Comentários
mikhno-s
·
3Comentários
Comentários muito úteis
Consegui corrigir isso adicionando as informações do host do leme ao comando de instalação do helm.
--host=10.111.221.14:443Você pode obter o seu Tiller IP por meio deste método
$ kubectl get svc -n kube-system tiller-deployNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEtiller-deploy ClusterIP 10.111.221.14 <none> 44134/TCP 34hExemplo de comando completo
helm install stable/grafana --name=grafana --host=10.111.221.14:4413Eu sei que isso é meio que uma solução alternativa, mas todas as outras funções do leme estão funcionando corretamente após a instalação por meio desse método. Não precisei adicionar as informações do host novamente após a instalação inicial para realizar atualizações ou reversões. Espero que isto ajude!