Tillerless Helm on Nutanix Karbon


Userlevel 2
Badge

What is Helm?

Helm is a tool that simplifies how your IT operation team install and manage Kubernetes applications. You could consider it like a package manager in Linux (apt/yum) but for Kubernetes.

What is a Helm chart?

A Helm chart is just a package that contains the Kubernetes application. This is similar to a .deb/.rpm package on your preferred Linux distribution.

What are the Helm use cases?

If you are wondering why use Helm is a good idea, here some of the reasons:
  • Most of the popular software has a Helm chart to facilitate its installation on Kubernetes
  • If you are looking to share your own Kubernetes application, a Helm chart is the way to go
  • Consistency during deployments is a key aspect, charts bring reproducible builds of your applications
  • Kubernetes applications are a group of manifest files. A chart helps you to manage the complexity of those Kubernetes manifest files
  • Manage releases of Helm packages

Helm architecture

From Helm website:
  • Helm has two parts: a client (helm) and a server (tiller)
  • Tiller runs inside of your Kubernetes cluster, and manages releases (installations) of your charts.
  • Helm runs on your laptop, CI/CD, or wherever you want it to run.
  • Charts are Helm packages that contain at least two things:
* A description of the package (Chart.yaml)
* One or more templates, which contain Kubernetes manifest files
  • Charts can be stored on disk, or fetched from remote chart repositories (like Debian or RedHat packages)



Security concern around Tiller (Helm Server)

Tiller is responsible for managing the releases of your Kubernetes Apps. Tiller runs with root access on your Kubernetes cluster what poses a great risk, and someone can get unauthorised access to your server.

This security risk is addressed on the future Helm v3 release. Until the new version is out, we have a way to mitigate this risk on Helm v2.

Tillerless to the rescue!

Tillerless is a Helm plug-in developed by Rimas Mocevicius at Jfrog. In a nutshell what this plug-in does is to run Tiller locally on your workstation or in CI/CD pipelines without installing Tiller on your Kubernetes clusters.

Installation

Before you start with the Tillerless Helm installation it is important you have kubectl and the kubeconfig file properly configured and working on your machine. Helm client has a dependency with the kubeconfig file.

Helm client

First install the Helm client (helm). I recommend you to follow the steps on this link for your OS platform. In my case I’m a macOS user so I’m using Homebrew to install Helm.

code:
brew install kubernetes-helm 

Initialise Helm

Make sure you initialise Helm with the right flag, --client-only. If you don’t do it Tiller will be installed on your Kubernetes cluster.

code:
helm init --client-only

Output:
code:
$HELM_HOME has been configured at /Users/jose.gomez/.helm.
Not installing Tiller due to 'client-only' flag having been set
Happy Helming!

Install Tillerless plug-in

With Helm initialised the next step is to install the Tillerless plug-in. Remember, this plug-in will make Tiller to run on your workstation instead of the Kubernetes cluster.

code:
helm plugin install https://github.com/rimusz/helm-tiller

We are ready to start using Tillerless Helm.


Using the plug-in locally

Tillerless by default starts locally and with the namespace kube-system. You can start with a different namespace, but make sure the Kubernetes namespace previously exists. On this post we are using the default namespace used by Tillerless, kube-system.

code:
helm tiller start

Output:
code:
Installed Helm version v2.9.1
Copied found /usr/local/bin/tiller to helm-tiller/bin
Helm and Tiller are the same version!
Starting Tiller...
Tiller namespace: kube-system

A new shell has been opened where you can run on a secure manner any helm command. For the purpose of this post we are going to deploy the Consul chart to check everything is running.

code:
helm install --name consul stable/consul

Output:
code:
NAME:  consul
LAST DEPLOYED: Sun Dec 2 14:03:00 2018
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1beta1/StatefulSet
NAME DESIRED CURRENT AGE
consul 3 1 0s

==> v1beta1/PodDisruptionBudget
NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE
consul-pdb N/A 1 0 0s

==> v1/Pod(related)
NAME READY STATUS RESTARTS AGE
consul-0 0/1 Pending 0 0s

==> v1/Secret
NAME TYPE DATA AGE
consul-gossip-key Opaque 1 0s

==> v1/ConfigMap
NAME DATA AGE
consul-tests 1 0s

==> v1/Service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
consul ClusterIP None 8500/TCP,8400/TCP,8301/TCP,8301/UDP,8302/TCP,8302/UDP,8300/TCP,8600/TCP,8600/UDP 0s
consul-ui NodePort 172.19.210.185 8500:31820/TCP 0s


NOTES:
1. Watch all cluster members come up.
$ kubectl get pods --namespace=default -w
2. Test cluster health using Helm test.
$ helm test consul
3. (Optional) Manually confirm consul cluster is healthy.
$ CONSUL_POD=$(kubectl get pods -l='release=consul' --output=jsonpath={.items[0].metadata.name})
$ kubectl exec $CONSUL_POD consul members --namespace=default | grep server

It takes about five minutes to fully deploy Consul. You can check the status with the following command:

code:
helm test consul --cleanup

When Consul is ready the previous command should have the following output. You will get the PASSED message once the deployment is done.

code:
RUNNING: consul-ui-test-yht8o

PASSED: consul-ui-test-yht8o

Next step is to check what port has been assigned to the consul-ui service. You can get the information on the chart installation output. Check the service section of it.

code:
==> v1/Service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
consul ClusterIP None 8500/TCP,8400/TCP,8301/TCP,8301/UDP,8302/TCP,8302/UDP,8300/TCP,8600/TCP,8600/UDP 1m
consul-ui NodePort 172.19.210.185 8500:31820/TCP 1m

On my case the consul-ui port 8500 has been mapped with the port 31820. Open a web browser and use the IP address of one of your workers and your mapped port. A quick way to get your worker IP addresses.

code:
kubectl get node -o yaml | grep address

Output:
code:
   addresses:
- address: 10.10.56.161
- address: tillerless-f42dcf-k8s-master-0
addresses:
- address: 10.10.56.162
- address: tillerless-f42dcf-k8s-worker-0

Here a screenshot for the Consul deployment with Tireless Helm

When you have finished with your Helm tasks you can close the shell and stop the Tiller service.

code:
exit
helm tiller stop

Conclusion

With Tireless Helm you don’t have the need to install Tiller on your Kubernetes cluster or create any kind of RBAC for it. With this approach you get a secure way to deploy your Helm charts.

0 replies

Be the first to reply!

Reply