5

I've a Kubernetes cluster installed in AWS with Kops. I've installed Helm Tiller with the Gitlab UI. The Tiller service seems to be working via Gitlab, for example I've installed Ingress from the Gitlab UI.

But when trying to use that same Tiller from my CLI, I can't manage to get it working. When I helm init it says it's already installed (which makes totally sense):

helm init --tiller-namespace gitlab-managed-apps --service-account tiller
$HELM_HOME has been configured at C:\Users\danie\.helm.
Warning: Tiller is already installed in the cluster.
(Use --client-only to suppress this message, or --upgrade to upgrade Tiller to the current version.)
Happy Helming!

But when trying to, for example, list the charts, it takes 5 minutes and then timeouts:

$ helm list --tiller-namespace gitlab-managed-apps --debug
[debug] Created tunnel using local port: '60471'

[debug] SERVER: "127.0.0.1:60471"

Error: context deadline exceeded

What I'm missing so I can use the Gitlab-installed Tiller from my CLI?

Daniel Ramos
  • 2,115
  • 3
  • 18
  • 28

2 Answers2

3

Are you pretty sure that your Tiller server is installed in "gitlab-managed-apps" namespace ? By default it's installed to 'kube-system' one as per official installation instruction on GitLab website, which would mean this is what causes your helm ls command to fail (just skip it)

The best way to verify it is via:

kubectl get deploy/tiller-deploy -n gitlab-managed-apps

Do you see any tiller related deployment object in that namespace ?

Assuming your can operate your KOPS cluster with current kube context, you should have no problem with running helm client locally. You can always explicitly use --kube-context argument with helm command.

Update:

I think I know what causes your problem, Helm when installed via GitLab UI is using secured connection (SSL) between helm and tiller (proof here).

Knowing that, it means you should retrieve set of certificates from Secret object that is mounted on Tiller Pod: 

#The CA
ca.cert.pem
ca.key.pem
#The Helm client files
helm.cert.pem
helm.key.pem
#The Tiller server files
tiller.cert.pem
tiller.key.pem

and then connect helm client to tiller server using following command, as explained here:

helm ls --tls --tls-ca-cert ca.cert.pem --tls-cert helm.cert.pem --tls-key helm.key.pem
Nepomucen
  • 4,449
  • 3
  • 9
  • 24
  • Are you able to run 'kubectl proxy --port=8080' against your KOPS cluster and explore later K8S API with 'curl http://localhost:8080/api/' ?. Basically helm does the same internally, creates tunnel based on current context (credentials/k8s server address). You may try running helm list with --debug flag, maybe it will tell something more. – Nepomucen Apr 09 '19 at 12:58
  • Yes, I'm able to access the API through the proxy... I've tried the `--debug` flag and the ouput doesn't seems to tell anything relevant: `[debug] Created tunnel using local port: '60471' [debug] SERVER: "127.0.0.1:60471" Error: context deadline exceeded` – Daniel Ramos Apr 09 '19 at 14:52
  • Please see my updated post for the probable root cause of your issue. – Nepomucen Apr 10 '19 at 08:32
  • 1
    Here's the official gitlab ticket with the commands needed: https://gitlab.com/gitlab-org/gitlab-foss/issues/56591 – Narretz Feb 28 '20 at 18:15
1

Here's the way I've been doing this.

First open a shell in the gitlab tiller pod:

# replace the pod name, tiller-deploy-5bb888969c-7bzpl with your own
kubectl exec -n gitlab-managed-apps tiller-deploy-5bb888969c-7bzpl -it -- sh

Then use the pod's native helm and certs... to connect to tiller

$ env | grep TILLER_TLS_CERTS
#cd to the result, in my case /etc/certs
$ cd /etc/certs
# connect to tiller with the certs using the native helm (/helm) in my case:
$ /helm ls --tls --tls-ca-cert ./ca.crt --tls-cert ./tls.crt --tls-key ./tls.key
mikeLundquist
  • 769
  • 1
  • 12
  • 26