Installation: Frequently Asked Questions

    We’d love your help making this document better. To add, correct, or removeinformation, file an issue orsend us a pull request.

    I want to know more about my downloading options.

    Q: I can’t get to GitHub releases of the newest Helm. Where are they?

    Binaries are stored at .

    Q: Why aren’t there Debian/Fedora/… native packages of Helm?

    We’d love to provide these or point you toward a trusted provider. If you’reinterested in helping, we’d love it. This is how the Homebrew formula wasstarted.

    Q: Why do you provide a script?

    A: There is a script in our repository (scripts/get) that can be executed asa curl ..|bash script. The transfers are all protected by HTTPS, and the scriptdoes some auditing of the packages it fetches. However, the script has all theusual dangers of any shell script.

    We provide it because it is useful, but we suggest that users carefully read thescript first. What we’d really like, though, are better packaged releases ofHelm.

    I’m trying to install Helm/Tiller, but something is not right.

    Q: How do I put the Helm client files somewhere other than ~/.helm?

    Set the $HELM_HOME environment variable, and then run helm init:

    Note that if you have existing repositories, you will need to re-add themwith helm repo add….

    Q: How do I configure Helm, but not install Tiller?

    A: By default, helm init will ensure that the local $HELM_HOME is configured,and then install Tiller on your cluster. To locally configure, but not installTiller, use helm init —client-only.

    Q: How do I manually install Tiller on the cluster?

    Q: Why do I get Error response from daemon: target is unknown during Tiller install?

    A: Users have reported being unable to install Tiller on Kubernetes instances thatare using Docker 1.13.0. The root cause of this was a bug in Docker that madethat one version incompatible with images pushed to the Docker registry byearlier versions of Docker.

    This issue was fixed shortlyafter the release, and is available in Docker 1.13.1-RC1 and later.

    I successfully installed Helm/Tiller but I can’t use it.

    Q: Trying to use Helm, I get the error “client transport was broken”

    1. E1014 02:26:32.885226   16143 portforward.go:329] an error occurred forwarding 37008 -> 44134: error forwarding port 44134 to pod tiller-deploy-2117266891-e4lev_kube-system, uid : unable to do port forwarding: socat not found.
    2. 2016/10/14 02:26:32 transport: http2Client.notifyError got notified that the client transport was broken EOF.
    3. Error: transport is closing

    A: This is usually a good indication that Kubernetes is not set up to allow port forwarding.

    Typically, the missing piece is socat. If you are running CoreOS, we have beentold that it may have been misconfigured on installation. The CoreOS teamrecommends reading this:

    Here are a few resolved issues that may help you get started:

    Q: Trying to use Helm, I get the error “lookup XXXXX on 8.8.8.8:53: no such host”

    A: We have seen this issue with Ubuntu and Kubeadm in multi-node clusters. Theissue is that the nodes expect certain DNS records to be obtainable via globalDNS. Until this is resolved upstream, you can work around the issue asfollows. On each of the control plane nodes:

    1) Add entries to /etc/hosts, mapping your hostnames to their public IPs2) Install dnsmasq (e.g. apt install -y dnsmasq)3) Remove the k8s api server container (kubelet will recreate it)4) Then systemctl restart docker (or reboot the node) for it to pick up the /etc/resolv.conf changes

    See this issue for more information: https://github.com/helm/helm/issues/1455

    Q: On GKE (Google Container Engine) I get “No SSH tunnels currently open”

    1. Error: Error forwarding ports: error upgrading connection: No SSH tunnels currently open. Were the targets able to accept an ssh-key for user "gke-[redacted]"?

    Another variation of the error message is:

    A: The issue is that your local Kubernetes config file must have the correct credentials.

    When you create a cluster on GKE, it will give you credentials, including SSLcertificates and certificate authorities. These need to be stored in a Kubernetesconfig file (Default: ~/.kube/config so that and helm can accessthem.

    A: Helm uses the Kubernetes proxy service to connect to the Tiller server.If the command kubectl proxy does not work for you, neither will Helm.Typically, the error is related to a missing socat service.

    Q: Tiller crashes with a panic

    When I run a command on Helm, Tiller crashes with an error like this:

    1. Tiller is listening on :44134
    2. Probes server is listening on :44135
    3. Storage driver is ConfigMap
    4. panic: runtime error: invalid memory address or nil pointer dereference
    5. [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x8053d5]
    7. goroutine 77 [running]:
    8. panic(0x1abbfc0, 0xc42000a040)
    9.         /usr/local/go/src/runtime/panic.go:500 +0x1a1
    10. k8s.io/helm/vendor/k8s.io/kubernetes/pkg/client/unversioned.(*ConfigMaps).Get(0xc4200c6200, 0xc420536100, 0x15, 0x1ca7431, 0x6, 0xc42016b6a0)
    11.         /home/ubuntu/.go_workspace/src/k8s.io/helm/vendor/k8s.io/kubernetes/pkg/client/unversioned/configmap.go:58 +0x75
    12. k8s.io/helm/pkg/storage/driver.(*ConfigMaps).Get(0xc4201d6190, 0xc420536100, 0x15, 0xc420536100, 0x15, 0xc4205360c0)
    13.         /home/ubuntu/.go_workspace/src/k8s.io/helm/pkg/storage/driver/cfgmaps.go:69 +0x62
    14. k8s.io/helm/pkg/storage.(*Storage).Get(0xc4201d61a0, 0xc4205360c0, 0x12, 0xc400000001, 0x12, 0x0, 0xc420200070)
    15.         /home/ubuntu/.go_workspace/src/k8s.io/helm/pkg/storage/storage.go:38 +0x160
    16. k8s.io/helm/pkg/tiller.(*ReleaseServer).uniqName(0xc42002a000, 0x0, 0x0, 0xc42016b800, 0xd66a13, 0xc42055a040, 0xc420558050, 0xc420122001)
    17.         /home/ubuntu/.go_workspace/src/k8s.io/helm/pkg/tiller/release_server.go:577 +0xd7
    18. k8s.io/helm/pkg/tiller.(*ReleaseServer).prepareRelease(0xc42002a000, 0xc42027c1e0, 0xc42002a001, 0xc42016bad0, 0xc42016ba08)
    19. k8s.io/helm/pkg/tiller.(*ReleaseServer).InstallRelease(0xc42002a000, 0x7f284c434068, 0xc420250c00, 0xc42027c1e0, 0x0, 0x31a9, 0x31a9)
    20.         /home/ubuntu/.go_workspace/src/k8s.io/helm/pkg/tiller/release_server.go:604 +0x78
    21. k8s.io/helm/pkg/proto/hapi/services._ReleaseService_InstallRelease_Handler(0x1c51f80, 0xc42002a000, 0x7f284c434068, 0xc420250c00, 0xc42027c190, 0x0, 0x0, 0x0, 0x0, 0x0)
    22.         /home/ubuntu/.go_workspace/src/k8s.io/helm/pkg/proto/hapi/services/tiller.pb.go:747 +0x27d
    23. k8s.io/helm/vendor/google.golang.org/grpc.(*Server).processUnaryRPC(0xc4202f3ea0, 0x28610a0, 0xc420078000, 0xc420264690, 0xc420166150, 0x288cbe8, 0xc420250bd0, 0x0, 0x0)
    24.         /home/ubuntu/.go_workspace/src/k8s.io/helm/vendor/google.golang.org/grpc/server.go:608 +0xc50
    25. k8s.io/helm/vendor/google.golang.org/grpc.(*Server).handleStream(0xc4202f3ea0, 0x28610a0, 0xc420078000, 0xc420264690, 0xc420250bd0)
    26.         /home/ubuntu/.go_workspace/src/k8s.io/helm/vendor/google.golang.org/grpc/server.go:766 +0x6b0
    27. k8s.io/helm/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1(0xc420124710, 0xc4202f3ea0, 0x28610a0, 0xc420078000, 0xc420264690)
    28.         /home/ubuntu/.go_workspace/src/k8s.io/helm/vendor/google.golang.org/grpc/server.go:419 +0xab
    29. created by k8s.io/helm/vendor/google.golang.org/grpc.(*Server).serveStreams.func1
    30.         /home/ubuntu/.go_workspace/src/k8s.io/helm/vendor/google.golang.org/grpc/server.go:420 +0xa3

    A: Check your security settings for Kubernetes.

    A panic in Tiller is almost always the result of a failure to negotiate with theKubernetes API server (at which point Tiller can no longer do anything useful, soit panics and exits).

    Often, this is a result of authentication failing because the Pod in which Tilleris running does not have the right token.

    To fix this, you will need to change your Kubernetes configuration. Make surethat —service-account-private-key-file from controller-manager and—service-account-key-file from apiserver point to the same x509 RSA key.

    My Helm used to work, then I upgrade. Now it is broken.

    Q: After upgrade, I get the error “Client version is incompatible”. What’s wrong?

    Tiller and Helm have to negotiate a common version to make sure that they can safelycommunicate without breaking API assumptions. That error means that the versiondifference is too great to safely continue. Typically, you need to upgradeTiller manually for this.

    The has definitive information about safelyupgrading Helm and Tiller.

    The rules for version numbers are as follows:

    • Pre-release versions are incompatible with everything else. Alpha.1 is incompatible with Alpha.2.
    • Patch revisions are compatible: 1.2.3 is compatible with 1.2.4
    • Minor revisions are not compatible: 1.2.0 is not compatible with 1.3.0,though we may relax this constraint in the future.

    I am trying to remove stuff.

    Q: When I delete the Tiller deployment, how come all the releases are still there?

    Releases are stored in ConfigMaps inside of the kube-system namespace. You willhave to manually delete them to get rid of the record, or use helm delete —purge.

    Q: I want to delete my local Helm. Where are all its files?