helm: "Error: Transport is closing" message when attempting to install

I am trying to install spinnaker from the kubeapps hub using:

helm install stable/spinnaker --name spinnaker -f values.yaml

This gave me no output but i could see the pods being created, and then later:

Error: transport is closing

Using --wait and --timeout didn’t help.

Spinnaker seems to have spun up successfully, but since helm didn’t finish registering the installation as complete, helm is stuck in “PENDING_INSTALL” state for spinnaker meaning I can’t update/upgrade later.

Any ideas what might be happening?

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 27
Comments: 63 (20 by maintainers)

Commits related to this issue

Tiller should only enforce what we expect from Helm https://github.com/kubernetes/helm/pull/3183 added a keepalive to the Helm client of 30s period, while Tiller was never configured to permit this, ... — committed to powerhome/helm by benlangfeld 6 years ago
Tiller should only enforce what we expect from Helm https://github.com/kubernetes/helm/pull/3183 added a keepalive to the Helm client of 30s period, while Tiller was never configured to permit this, ... — committed to powerhome/helm by benlangfeld 6 years ago
Tiller should only enforce what we expect from Helm https://github.com/kubernetes/helm/pull/3183 added a keepalive to the Helm client of 30s period, while Tiller was never configured to permit this, ... — committed to helm/helm by benlangfeld 6 years ago
Wait for K8S upgrades before we continue Otherwise, the kubelet will be rebooted and any tiller releases will fail to install: https://github.com/kubernetes/helm/issues/3409#issuecomment-402692073 — committed to EngineerBetter/kcf by gerhard 6 years ago
Tiller should only enforce what we expect from Helm https://github.com/kubernetes/helm/pull/3183 added a keepalive to the Helm client of 30s period, while Tiller was never configured to permit this, ... — committed to splisson/helm by benlangfeld 6 years ago
Tiller should only enforce what we expect from Helm https://github.com/kubernetes/helm/pull/3183 added a keepalive to the Helm client of 30s period, while Tiller was never configured to permit this, ... — committed to splisson/helm by benlangfeld 6 years ago
Tiller should only enforce what we expect from Helm https://github.com/kubernetes/helm/pull/3183 added a keepalive to the Helm client of 30s period, while Tiller was never configured to permit this, ... — committed to jianghang8421/helm by benlangfeld 6 years ago

Most upvoted comments

This is fixed for me by https://github.com/kubernetes/helm/pull/3482. If you would like to try that, do helm init --force-upgrade --tiller-image powerhome/tiller:git-3b22ecd. I’d appreciate feedback, particularly from @huang-jy, @Nowaker and @cmdshepard

+13

benlangfeld on Feb 9, 2018

Add --tls flag to helm install command.

makandas on Nov 23, 2018

So, I reproduced this without using hooks, against minikube and with a minimal chart: https://gist.github.com/benlangfeld/005f5d934c074d67a34fe9f881c84e89

While this particular deployment would of course never succeed (because of the impossible healthchecks), I would not expect it to time out in 210s as it does, but rather continue until the timeout at 300 seconds indicated in the Tiller log, as is the primary contention in this ticket.

benlangfeld on Feb 7, 2018

I just had this error and it turned out to be I had to little resources set for the tiller deploy.

JPWKU on Apr 22, 2019

I’m facing this issue yet. Event on the last version available 2.12.3.

I can see that tiller just crash with a log of errors

[tiller] 2019/01/23 16:25:50 preparing install for my-release
[storage] 2019/01/23 16:25:50 getting release history for "my-release"
[tiller] 2019/01/23 16:25:50 rendering my-release chart using values
panic: should not happen [recovered]
	panic: should not happen

goroutine 29 [running]:
k8s.io/helm/vendor/gopkg.in/yaml%2ev2.handleErr(0xc00078af78)
	/go/src/k8s.io/helm/vendor/gopkg.in/yaml.v2/yaml.go:164 +0x9a
....

I’m using at GCP (GKE version: 1.11.5-gke.5)

alanwds on Jan 23, 2019

The results of bisecting:

803f7c706ef4ce44aa6418c42c77dbf7e60ac66d is the first bad commit
commit 803f7c706ef4ce44aa6418c42c77dbf7e60ac66d
Author: Helgi Þormar Þorbjörnsson <helgith@gmail.com>
Date:   Wed Nov 22 08:30:25 2017 -0800

    add a keepalive of 30s to the client (#3183)

:040000 040000 3b1218a94f23f51ccbbf253676e1457f0c42d663 3d207d79bad28de7dc17f922e44d5faa1e31cf45 M	pkg

Indeed, current master with this commit reverted does not present this issue.

I suspect we have an incompatibility in configuration between helm and tiller; the relevant docs are at https://godoc.org/google.golang.org/grpc/keepalive.

benlangfeld on Feb 9, 2018

I’ve been experiencing the same problem. The deployment is “visibly” successful - yet it fails due to “Error: transport is closing” after around three minutes of waiting. This is happening whether I add --wait --timeout 600 or not. Moreover, the release looks just fine:

NAME                    	REVISION	UPDATED                 	STATUS  	CHART            	NAMESPACE
review-feature-ld-s9rxem	1       	Tue Jan 30 18:55:42 2018	DEPLOYED	lde-nginx-941.0.0	default

Nowaker on Jan 31, 2018

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 May 30, 2018

I downgraded to 2.6.0. No longer have the issue. I have timeout set to 10 mins. Tiller is honoring the timeout but the Helm client does not.

cmdshepard on Feb 7, 2018