Install applications with Helm in Azure Kubernetes Service (AKS)

Helm is an open-source packaging tool that helps you install and manage the lifecycle of Kubernetes applications. Similar to Linux package managers such as APT and Yum, Helm is used to manage Kubernetes charts, which are packages of preconfigured Kubernetes resources.

This article shows you how to configure and use Helm in a Kubernetes cluster on AKS.

Before you begin

This article assumes that you have an existing AKS cluster. If you need an AKS cluster, see the AKS quickstart using the Azure CLI or using the Azure portal.

You also need the Helm CLI installed, which is the client that runs on your development system. It allows you to start, stop, and manage applications with Helm. If you use the Azure Cloud Shell, the Helm CLI is already installed. For installation instructions on your local platform see, Installing Helm.


Helm is intended to run on Linux nodes. If you have Windows Server nodes in your cluster, you must ensure that Helm pods are only scheduled to run on Linux nodes. You also need to ensure that any Helm charts you install are also scheduled to run on the correct nodes. The commands in this article use node-selectors to make sure pods are scheduled to the correct nodes, but not all Helm charts may expose a node selector. You can also consider using other options on your cluster, such as taints.

Create a service account

Before you can deploy Helm in an RBAC-enabled AKS cluster, you need a service account and role binding for the Tiller service. For more information on securing Helm / Tiller in an RBAC enabled cluster, see Tiller, Namespaces, and RBAC. If your AKS cluster is not RBAC enabled, skip this step.

Create a file named helm-rbac.yaml and copy in the following YAML:

apiVersion: v1
kind: ServiceAccount
  name: tiller
  namespace: kube-system
kind: ClusterRoleBinding
  name: tiller
  kind: ClusterRole
  name: cluster-admin
  - kind: ServiceAccount
    name: tiller
    namespace: kube-system

Create the service account and role binding with the kubectl apply command:

kubectl apply -f helm-rbac.yaml

Secure Tiller and Helm

The Helm client and Tiller service authenticate and communicate with each other using TLS/SSL. This authentication method helps to secure the Kubernetes cluster and what services can be deployed. To improve security, you can generate your own signed certificates. Each Helm user would receive their own client certificate, and Tiller would be initialized in the Kubernetes cluster with certificates applied. For more information, see Using TLS/SSL between Helm and Tiller.

With an RBAC-enabled Kubernetes cluster, you can control the level of access Tiller has to the cluster. You can define the Kubernetes namespace that Tiller is deployed in, and restrict what namespaces Tiller can then deploy resources in. This approach lets you create Tiller instances in different namespaces and limit deployment boundaries, and scope the users of Helm client to certain namespaces. For more information, see Helm role-based access controls.

Configure Helm

To deploy a basic Tiller into an AKS cluster, use the helm init command. If your cluster is not RBAC enabled, remove the --service-account argument and value. The following examples also set the history-max to 200.

If you configured TLS/SSL for Tiller and Helm, skip this basic initialization step and instead provide the required --tiller-tls- as shown in the next example.

helm init --history-max 200 --service-account tiller --node-selectors ""

If you configured TLS/SSL between Helm and Tiller provide the --tiller-tls-* parameters and names of your own certificates, as shown in the following example:

helm init \
    --tiller-tls \
    --tiller-tls-cert tiller.cert.pem \
    --tiller-tls-key tiller.key.pem \
    --tiller-tls-verify \
    --tls-ca-cert ca.cert.pem \
    --history-max 200 \
    --service-account tiller \
    --node-selectors ""

Find Helm charts

Helm charts are used to deploy applications into a Kubernetes cluster. To search for pre-created Helm charts, use the helm search command:

helm search

The following condensed example output shows some of the Helm charts available for use:

$ helm search

stable/aerospike               0.1.7        	v3.14.1.2    A Helm chart for Aerospike in Kubernetes
stable/anchore-engine          0.1.7        	0.1.10       Anchore container analysis and policy evaluatio...
stable/apm-server              0.1.0        	6.2.4        The server receives data from the Elastic APM a...
stable/ark                     1.0.1        	0.8.2        A Helm chart for ark
stable/artifactory             7.2.1        	6.0.0        Universal Repository Manager supporting all maj...
stable/artifactory-ha          0.2.1        	6.0.0        Universal Repository Manager supporting all maj...
stable/auditbeat               0.1.0        	6.2.4        A lightweight shipper to audit the activities o...
stable/aws-cluster-autoscaler  0.3.3        	             Scales worker nodes within autoscaling groups.
stable/bitcoind                0.1.3        	0.15.1       Bitcoin is an innovative payment network and a ...
stable/buildkite               0.2.3        	3            Agent for Buildkite
stable/burrow                  0.4.4        	0.17.1       Burrow is a permissionable smart contract machine
stable/centrifugo              2.0.1        	1.7.3        Centrifugo is a real-time messaging server.
stable/cerebro                 0.1.0        	0.7.3        A Helm chart for Cerebro - a web admin tool tha...
stable/cert-manager            v0.3.3       	v0.3.1       A Helm chart for cert-manager
stable/chaoskube               0.7.0        	0.8.0        Chaoskube periodically kills random pods in you...
stable/chartmuseum             1.5.0        	0.7.0        Helm Chart Repository with support for Amazon S...
stable/chronograf              0.4.5        	1.3          Open-source web application written in Go and R...
stable/cluster-autoscaler      0.6.4        	1.2.2        Scales worker nodes within autoscaling groups.
stable/cockroachdb             1.1.1        	2.0.0        CockroachDB is a scalable, survivable, strongly...
stable/concourse               1.10.1       	3.14.1       Concourse is a simple and scalable CI system.
stable/consul                  3.2.0        	1.0.0        Highly available and distributed service discov...
stable/coredns                 0.9.0        	1.0.6        CoreDNS is a DNS server that chains plugins and...
stable/coscale                 0.2.1        	3.9.1        CoScale Agent
stable/dask                    1.0.4        	0.17.4       Distributed computation in Python with task sch...
stable/dask-distributed        2.0.2        	             DEPRECATED: Distributed computation in Python
stable/datadog                 0.18.0       	6.3.0        DataDog Agent

To update the list of charts, use the helm repo update command. The following example shows a successful repo update:

$ helm repo update

Hold tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "stable" chart repository
Update Complete.

Run Helm charts

To install charts with Helm, use the helm install command and specify the name of the chart to install. To see installing a Helm chart in action, let's install a basic nginx deployment using a Helm chart. If you configured TLS/SSL, add the --tls parameter to use your Helm client certificate.

helm install stable/nginx-ingress \
    --set controller.nodeSelector."beta\.kubernetes\.io/os"=linux \
    --set defaultBackend.nodeSelector."beta\.kubernetes\.io/os"=linux

The following condensed example output shows the deployment status of the Kubernetes resources created by the Helm chart:

$ helm install stable/nginx-ingress --set controller.nodeSelector."beta\.kubernetes\.io/os"=linux --set defaultBackend.nodeSelector."beta\.kubernetes\.io/os"=linux

NAME:   flailing-alpaca
LAST DEPLOYED: Thu May 23 12:55:21 2019
NAMESPACE: default

==> v1/ConfigMap
NAME                                      DATA  AGE
flailing-alpaca-nginx-ingress-controller  1     0s

==> v1/Pod(related)
NAME                                                            READY  STATUS             RESTARTS  AGE
flailing-alpaca-nginx-ingress-controller-56666dfd9f-bq4cl       0/1    ContainerCreating  0         0s
flailing-alpaca-nginx-ingress-default-backend-66bc89dc44-m87bp  0/1    ContainerCreating  0         0s

==> v1/Service
NAME                                           TYPE          CLUSTER-IP  EXTERNAL-IP  PORT(S)                     AGE
flailing-alpaca-nginx-ingress-controller       LoadBalancer  <pending>    80:31219/TCP,443:32421/TCP  0s
flailing-alpaca-nginx-ingress-default-backend  ClusterIP  <none>       80/TCP                      0s

It takes a minute or two for the EXTERNAL-IP address of the nginx-ingress-controller service to be populated and allow you to access it with a web browser.

List Helm releases

To see a list of releases installed on your cluster, use the helm list command. The following example shows the nginx-ingress release deployed in the previous step. If you configured TLS/SSL, add the --tls parameter to use your Helm client certificate.

$ helm list

NAME        	    REVISION	UPDATED                 	STATUS  	CHART          	      APP VERSION	NAMESPACE
flailing-alpaca	  1       	Thu May 23 12:55:21 2019	DEPLOYED	nginx-ingress-1.6.13	0.24.1     	default

Clean up resources

When you deploy a Helm chart, a number of Kubernetes resources are created. These resources include pods, deployments, and services. To clean up these resources, use the helm delete command and specify your release name, as found in the previous helm list command. The following example deletes the release named flailing-alpaca:

$ helm delete flailing-alpaca

release "flailing-alpaca" deleted

Next steps

For more information about managing Kubernetes application deployments with Helm, see the Helm documentation.