Helm: `helm delete` reports "lost connection to pod" "Error: transport is closing" despite apparent success
helm 2.6.1 client and server
k8s 1.7.4 (same behavior with 1.7.0 also)
I have seen several issues discussing "lost connection to pod" but none that I recognize as matching our case.
When I run helm delete --purge _releaseName_ helm reports
portforward.go:178] lost connection to pod
Error: transport is closing
Yet the delete seems to have succeeded. All the k8s resources defined by the chart are cleaned up as expected. The tiller log looks like this:
[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"
That's the end of the log. It contains no errors or exceptions.
k8s reports no restarts of the tiller pod.
The elapsed time, from outside and from the log, is about 2m 30s, well under the default timeout value for the delete operation.
Where else can I look for more info as to what is going wrong that causes that error?
Thanks.
tjquinno
All 3 comments
This looks like https://github.com/kubernetes/helm/issues/2025 if it's well below the default timeout (5 minutes). Can you check on the load balancer fronting your kubernetes master API and comment on that issue moving forward? That way we can keep the discussion all in one place. Thank you! ❤️
bacongobbler
on 29 Sep 2017
I saw the Error: transport is closing error too when I ran helm install, and after doing rm -rf ~/.helm, the error was not seen anymore. Guess deleting the helm cache (rm -rf ~/.helm) may resolve the error.
vhosakot
on 30 May 2018
I was able to correct this by adding the tiller host information to the helm install command.
--host=10.111.221.14:443
You can get your tiller IP via this method
$ 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
Full command example
helm install stable/grafana --name=grafana --host=10.111.221.14:4413
I know this is a bit of a work around but all other functions of helm are performing properly after installing via this method. I did not have to add the host information again after the initial install for performing upgrades or rollbacks. Hope this helps!
castironclay
on 21 Apr 2019
Related issues
PhilippeDupont
·
3Comments
kvolkovich-sc
·
3Comments
InAnimaTe
·
3Comments
vdice
·
3Comments
libesz
·
3Comments
Most helpful comment
I was able to correct this by adding the tiller host information to the helm install command.
--host=10.111.221.14:443You can get your tiller IP via this method
$ 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 34hFull command example
helm install stable/grafana --name=grafana --host=10.111.221.14:4413I know this is a bit of a work around but all other functions of helm are performing properly after installing via this method. I did not have to add the host information again after the initial install for performing upgrades or rollbacks. Hope this helps!