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
The steps detailed in this document assume that you have created an AKS cluster and have established a
kubectl connection with the cluster. If you need these items see, the AKS quickstart.
You also need the Helm CLI installed, the client that runs on your development system and 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.
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. 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 --service-account tiller
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 \ --service-account tiller
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/aks-engine-autoscaler 2.2.0 2.1.1 Scales worker nodes within agent pools stable/aerospike 0.1.7 v220.127.116.11 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 Hang 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. ⎈ Happy Helming!⎈
Run Helm charts
To install charts with Helm, use the helm install command and specify the name of the chart to install. To see this in action, let's install a basic Wordpress deployment using a Helm chart. If you configured TLS/SSL, add the
--tls parameter to use your Helm client certificate.
helm install stable/wordpress
The following condensed example output shows the deployment status of the Kubernetes resources created by the Helm chart:
$ helm install stable/wordpress NAME: wishful-mastiff LAST DEPLOYED: Thu Jul 12 15:53:56 2018 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1beta1/Deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE wishful-mastiff-wordpress 1 1 1 0 1s ==> v1beta1/StatefulSet NAME DESIRED CURRENT AGE wishful-mastiff-mariadb 1 1 1s ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE wishful-mastiff-wordpress-6f96f8fdf9-q84sz 0/1 Pending 0 1s wishful-mastiff-mariadb-0 0/1 Pending 0 1s ==> v1/Secret NAME TYPE DATA AGE wishful-mastiff-mariadb Opaque 2 2s wishful-mastiff-wordpress Opaque 2 2s ==> v1/ConfigMap NAME DATA AGE wishful-mastiff-mariadb 1 2s wishful-mastiff-mariadb-tests 1 2s ==> v1/PersistentVolumeClaim NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE wishful-mastiff-wordpress Pending default 2s ==> v1/Service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE wishful-mastiff-mariadb ClusterIP 10.1.116.54 <none> 3306/TCP 2s wishful-mastiff-wordpress LoadBalancer 10.1.217.64 <pending> 80:31751/TCP,443:31264/TCP 2s ...
It takes a minute or two for the EXTERNAL-IP address of the Wordpress 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 Wordpress 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 NAMESPACE wishful-mastiff 1 Thu Jul 12 15:53:56 2018 DEPLOYED wordpress-2.1.3 default
Clean up resources
When you deploy a Helm chart, a number of Kubernetes resources are created. These resources includes 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 wishful mastiff:
$ helm delete wishful-mastiff release "wishful-mastiff" deleted
For more information about managing Kubernetes application deployments with Helm, see the Helm documentation.