Skip to main content
Latest Documentation
This is the latest documentation for the Cloud Posse Reference Architecture. To determine which version you're currently using, please see Version Identification.
Version: Latest
Sponsor @cloudposse

Helm

Helm makes it easy to install charts (an application) on kubernetes clusters. Just like npm or apt make it easy to install NodeJS modules and Debian packages, helm makes it easy to deploy a full-fledged application architecture with all of its dependencies on Kubernetes.

It’s one of the original tools to deploy applications to Kubernetes and has the widest support amongst tools. One of the problem though is that something still needs to define the values you need to deploy a Helm release. That’s why there are other tools (e.g. terraform, helmfile, and argocd) required in order to integrate helm with your environment.

Alternatives​

How-to Guides​

Charts​

Charts are the deployable artifact used to create helm releases.

Our Charts​

Cloud Posse maintains a dozen or so charts. In general, we prefer not to maintain any charts and our goal is to leverage as many open source charts as possible. Our charts are available via https://charts.cloudposse.com and browsable via https://artifacthub.io/packages/search?repo=cloudposse&sort=relevance&page=1 .

https://github.com/cloudposse/charts

Open Source Charts​

There’s been a lot of churn in the open-source community regarding Helm Charts. Historically, the helm/charts repo was the “official” source of charts managed by the community at large. Maintenance became a serious problem and bottleneck, so the repo has been deprecated. https://helm.sh/blog/charts-repo-deprecation

https://github.com/helm/charts

Today, the best place to search for charts is via https://artifacthub.io/ , which is like the “DockerHub” for helm charts. We also really like the well-maintained charts from Bitnami. https://github.com/bitnami/charts

Conventions​

Charts as an Interface​

Typically, in a service-oriented architecture (SOA) aka microservices architecture, there will be dozens of very similar services. Traditionally, companies would develop a “unique” helm chart for each of these services. In reality, the charts were generated by running the helm create (https://helm.sh/docs/helm/helm_create/ ) command that would generate all the boilerplate. As a result, the services would share 99% of their DNA with each other (e.g. like monkeys and humans), and 1% would differ. This led to a lot of tech debt, sprawl, and copy & paste 🍝 mistakes.

For proprietary apps deployed by your organization, we recommend taking a different tactic when developing helm charts. Instead, treat charts like an interface - the way you want to deploy apps to Kubernetes. Develop 1-2 charts based on the patterns you want your developers to use (e.g. microservice, batchjob, etc). Then parameterize things like the image, env values, resource limits, healthcheck endpoints, etc. Think of charts like developing your own Heroku-like mechanism to deploy an application. Instead of writing 2 dozen charts, maintain one. Make your apps conform to the convention. Push back on changes to the convention unless necessary.

What if we need more than one deployment (or XYZ) in a chart? That’s easy. You have a few options: a) Deploy the same chart twice; b) Decide if as an organization you want to support that interface and then extend the chart; c) Develop an additional chart interface.

What if we want to add a feature to our chart and don’t want to disrupt other services? No problem. Charts are versioned. So think of the version of a chart as the version of your interface. Every time you change the chart, bump the version. Ensure all your services pin to a version of the chart. Now when you change the version of the chart in your service, you know that your upgrading your interface as well.

What if we need some backing services? Good question. You can still use the features of umbrella charts, and even feature flag common things like deploying a database backend for development environments by using a condition in the requirements.yaml that can be toggled in the values.yaml. Pro-tip: Use https://artifacthub.io/ to find ready-made charts you can use.

- name: elasticsearch
  version: ^1.17.0
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: elasticsearch.enabled
- name: kibana
  version: ^1.1.0
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: kibana.enabled

Usage​

Command Line​

Helm is conveniently operated from the command line using the helm cli. We provide a package in our packages repository for multiple versions of helm (helm2 and helm3) so they can be concurrently installed using dpkg-alternative

https://github.com/cloudposse/packages/tree/master/vendor

Helmfile​

For many years, we relied on helmfile as the primary delivery tool for helm. Using helmfile we could declaratively express all the applications and their settings by the environment. Starting in 2021, we started shifting our focus on using terraform and/or ArgoCD for deployments as many of the features of helmfile are now adequately supported by them.

https://github.com/roboll/helmfile

https://github.com/cloudposse/helmfiles

https://archive.sweetops.com/helmfile/

Terraform​

There are two predominant ways to deploy helm chart releases with terraform. The primary benefit to using terraform over any other tool like helmfile or ArgoCD, is it’s the ability to facilitate integration with other services like AWS IAM, S3, SAML providers, etc. For example, a very common requirement is to provision IRSAs needed by pods to perform certain operations in AWS.

Terraform helm provider​

caution

Out-of-the-box the helm provider does not detect any changes made to the cluster, helm charts or values.

https://github.com/hashicorp/terraform-provider-helm/issues/372

This means that changes that are made manually in the cluster are not detected as drift. Unlike with helmfile, which performs a diff (using helm-diff plugin), the terraform helm provider does not.

Mitigations​

The helm provider works conveniently in terraform to deploy helm releases.

https://github.com/hashicorp/terraform-provider-helm

We use our terraform-aws-helm-release module to facilitate the most common deployment patterns that we use, including the ability to automatically provision the IAM roles required by the service.

https://github.com/cloudposse/terraform-aws-helm-release

As well as publish ready-made Components for services like external-dns, cert-manager, aws-load-balancer-controller, and argocd (and many more) leveraging this pattern.

https://github.com/cloudposse/terraform-aws-components

Terraform helmfile provider​

Usage of the helmfile provider is primarily advised for customers with a sizable investment into helmfile, but who also want to consolidate deployments with terraform. The helmfile provider simply wraps the helmfile command-line tool and ties into the terraform life cycle hooks for plan, apply and destroy. In order for it to work, it depends on multiple binaries being installed: helm, helmfile, and the helm-diff plugin. In addition, the KUBECONFIG must be set and pointed to an active session.

ArgoCD​

TL;DR: Even if you use ArgoCD, you’ll still need something that manages ArgoCD itself, any integrations with other kubernetes clusters, GitHub, and your IdP. For this reason we deploy ArgoCD with terraform and your apps optionally with ArgoCD.

Learning Resources​

References​

https://github.com/kubernetes/helm

Edit this page
Last updated on by Erik Osterman (CEO @ Cloud Posse)