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
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 metadata: name: tiller namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: tiller roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - 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.
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 "beta.kubernetes.io/os=linux"
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 "beta.kubernetes.io/os=linux"
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:
The following condensed example output shows some of the Helm charts available for use:
$ helm search NAME CHART VERSION APP VERSION DESCRIPTION stable/aerospike 0.1.7 v188.8.131.52 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 STATUS: DEPLOYED RESOURCES: ==> 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 10.0.109.7 <pending> 80:31219/TCP,443:32421/TCP 0s flailing-alpaca-nginx-ingress-default-backend ClusterIP 10.0.44.97 <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
For more information about managing Kubernetes application deployments with Helm, see the Helm documentation.