helm Helm cheatsheet Basic interpretations context Helm cheatsheet featuring all the necessary commands required to manage an application through Helm weight 4 title Cheat Sheet

Answer:
---
title: "Cheat Sheet"
description: "Helm cheatsheet"
weight: 4
---

Helm cheatsheet featuring all the necessary commands required to manage an application through Helm.

-----------------------------------------------------------------------------------------------------------------------------------------------
### Basic interpretations/context

Chart:
- It is the name of your chart in case it has been pulled and untarred.
- It is <repo_name>/<chart_name> in case the repository has been added but chart not pulled.
- It is the URL/Absolute path to the chart.

Name:
- It is the name you want to give to your current helm chart installation.

Release:
- Is the name you assigned to an installation instance.

Revision:
- Is the value from the Helm history command

Repo-name:
- The name of a repository.

DIR:
- Directory name/path

------------------------------------------------------------------------------------------------------------------------------------------------

### Chart Management

```bash
helm create <name>                      # Creates a chart directory along with the common files and directories used in a chart.
helm package <chart-path>               # Packages a chart into a versioned chart archive file.
helm lint <chart>                       # Run tests to examine a chart and identify possible issues:
helm show all <chart>                   # Inspect a chart and list its contents:
helm show values <chart>                # Displays the contents of the values.yaml file
helm pull <chart>                       # Download/pull chart
helm pull <chart> --untar=true          # If set to true, will untar the chart after downloading it
helm pull <chart> --verify              # Verify the package before using it
helm pull <chart> --version <number>    # Default-latest is used, specify a version constraint for the chart version to use
helm dependency list <chart>            # Display a list of a chart’s dependencies:
```
--------------------------------------------------------------------------------------------------------------------------------------------------

### Install and Uninstall Apps

```bash
helm install <name> <chart>                           # Install the chart with a name
helm install <name> <chart> --namespace <namespace>   # Install the chart in a specific namespace
helm install <name> <chart> --set key1=val1,key2=val2 # Set values on the command line (can specify multiple or separate values with commas)
helm install <name> <chart> --values <yaml-file/url>  # Install the chart with your specified values
helm install <name> <chart> --dry-run --debug         # Run a test installation to validate chart (p)
helm install <name> <chart> --verify                  # Verify the package before using it
helm install <name> <chart> --dependency-update       # update dependencies if they are missing before installing the chart
helm uninstall <name>                                 # Uninstall a release
```
------------------------------------------------------------------------------------------------------------------------------------------------
### Perform App Upgrade and Rollback

```bash
helm upgrade <release> <chart>                            # Upgrade a release
helm upgrade <release> <chart> --atomic                   # If set, upgrade process rolls back changes made in case of failed upgrade.
helm upgrade <release> <chart> --dependency-update        # update dependencies if they are missing before installing the chart
helm upgrade <release> <chart> --version <version_number> # specify a version constraint for the chart version to use
helm upgrade <release> <chart> --values                   # specify values in a YAML file or a URL (can specify multiple)
helm upgrade <release> <chart> --set key1=val1,key2=val2  # Set values on the command line (can specify multiple or separate valuese)
helm upgrade <release> <chart> --force                    # Force resource updates through a replacement strategy
helm rollback <release> <revision>                        # Roll back a release to a specific revision
helm rollback <release> <revision>  --cleanup-on-fail     # Allow deletion of new resources created in this rollback when rollback fails
```
------------------------------------------------------------------------------------------------------------------------------------------------
### List, Add, Remove, and Update Repositories

```bash
helm repo add <repo-name> <url>   # Add a repository from the internet:
helm repo list                    # List added chart repositories
helm repo update                  # Update information of available charts locally from chart repositories
helm repo remove <repo_name>      # Remove one or more chart repositories
helm repo index <DIR>             # Read the current directory and generate an index file based on the charts found.
helm repo index <DIR> --merge     # Merge the generated index with an existing index file
helm search repo <keyword>        # Search repositories for a keyword in charts
helm search hub <keyword>         # Search for charts in the Artifact Hub or your own hub instance
```
-------------------------------------------------------------------------------------------------------------------------------------------------
### Helm Release monitoring

```bash
helm list                       # Lists all of the releases for a specified namespace, uses current namespace context if namespace not specified
helm list --all                 # Show all releases without any filter applied, can use -a
helm list --all-namespaces      # List releases across all namespaces, we can use -A
helm list -l key1=value1,key2=value2 # Selector (label query) to filter on, supports '=', '==', and '!='
helm list --date                # Sort by release date
helm list --deployed            # Show deployed releases. If no other is specified, this will be automatically enabled
helm list --pending             # Show pending releases
helm list --failed              # Show failed releases
helm list --uninstalled         # Show uninstalled releases (if 'helm uninstall --keep-history' was used)
helm list --superseded          # Show superseded releases
helm list -o yaml               # Prints the output in the specified format. Allowed values: table, json, yaml (default table)
helm status <release>           # This command shows the status of a named release.
helm status <release> --revision <number>   # if set, display the status of the named release with revision
helm history <release>          # Historical revisions for a given release.
helm env                        # Env prints out all the environment information in use by Helm.
```
-------------------------------------------------------------------------------------------------------------------------------------------------
### Download Release Information

```bash
helm get all <release>      # A human readable collection of information about the notes, hooks, supplied values, and generated manifest file of the given release.
helm get hooks <release>    # This command downloads hooks for a given release. Hooks are formatted in YAML and separated by the YAML '---\n' separator.
helm get manifest <release> # A manifest is a YAML-encoded representation of the Kubernetes resources that were generated from this release's chart(s). If a chart is dependent on other charts, those resources will also be included in the manifest.
helm get notes <release>    # Shows notes provided by the chart of a named release.
helm get values <release>   # Downloads a values file for a given release. use -o to format output
```
-------------------------------------------------------------------------------------------------------------------------------------------------
### Plugin Management

```bash
helm plugin install <path/url1>     # Install plugins
helm plugin list                    # View a list of all installed plugins
helm plugin update <plugin>         # Update plugins
helm plugin uninstall <plugin>      # Uninstall a plugin
```
-------------------------------------------------------------------------------------------------------------------------------------------------

title   Cheat Sheet  description   Helm cheatsheet  weight  4      Helm cheatsheet featuring all the necessary commands required to manage an application through Helm                                                                                Basic interpretations context  Chart    It is the name of your chart in case it has been pulled and untarred    It is  repo name   chart name  in case the repository has been added but chart not pulled    It is the URL Absolute path to the chart   Name    It is the name you want to give to your current helm chart installation   Release    Is the name you assigned to an installation instance    Revision    Is the value from the Helm history command  Repo name    The name of a repository    DIR    Directory name path                                                                                Chart Management     bash helm create  name                         Creates a chart directory along with the common files and directories used in a chart  helm package  chart path                  Packages a chart into a versioned chart archive file  helm lint  chart                          Run tests to examine a chart and identify possible issues  helm show all  chart                      Inspect a chart and list its contents  helm show values  chart                   Displays the contents of the values yaml file helm pull  chart                          Download pull chart  helm pull  chart    untar true            If set to true  will untar the chart after downloading it helm pull  chart    verify                Verify the package before using it helm pull  chart    version  number       Default latest is used  specify a version constraint for the chart version to use helm dependency list  chart               Display a list of a chart s dependencies                                                                                Install and Uninstall Apps     bash helm install  name   chart                              Install the chart with a name helm install  name   chart    namespace  namespace      Install the chart in a specific namespace helm install  name   chart    set key1 val1 key2 val2   Set values on the command line  can specify multiple or separate values with commas  helm install  name   chart    values  yaml file url     Install the chart with your specified values helm install  name   chart    dry run   debug           Run a test installation to validate chart  p  helm install  name   chart    verify                    Verify the package before using it  helm install  name   chart    dependency update         update dependencies if they are missing before installing the chart helm uninstall  name                                    Uninstall a release                                                                                Perform App Upgrade and Rollback     bash helm upgrade  release   chart                               Upgrade a release helm upgrade  release   chart    atomic                     If set  upgrade process rolls back changes made in case of failed upgrade  helm upgrade  release   chart    dependency update          update dependencies if they are missing before installing the chart helm upgrade  release   chart    version  version number    specify a version constraint for the chart version to use helm upgrade  release   chart    values                     specify values in a YAML file or a URL  can specify multiple  helm upgrade  release   chart    set key1 val1 key2 val2    Set values on the command line  can specify multiple or separate valuese  helm upgrade  release   chart    force                      Force resource updates through a replacement strategy helm rollback  release   revision                           Roll back a release to a specific revision helm rollback  release   revision     cleanup on fail       Allow deletion of new resources created in this rollback when rollback fails                                                                                List  Add  Remove  and Update Repositories     bash helm repo add  repo name   url      Add a repository from the internet  helm repo list                      List added chart repositories helm repo update                    Update information of available charts locally from chart repositories helm repo remove  repo name         Remove one or more chart repositories helm repo index  DIR                Read the current directory and generate an index file based on the charts found  helm repo index  DIR    merge       Merge the generated index with an existing index file helm search repo  keyword           Search repositories for a keyword in charts helm search hub  keyword            Search for charts in the Artifact Hub or your own hub instance                                                                                Helm Release monitoring     bash helm list                         Lists all of the releases for a specified namespace  uses current namespace context if namespace not specified helm list   all                   Show all releases without any filter applied  can use  a helm list   all namespaces        List releases across all namespaces  we can use  A helm list  l key1 value1 key2 value2   Selector  label query  to filter on  supports            and      helm list   date                  Sort by release date helm list   deployed              Show deployed releases  If no other is specified  this will be automatically enabled helm list   pending               Show pending releases helm list   failed                Show failed releases helm list   uninstalled           Show uninstalled releases  if  helm uninstall   keep history  was used  helm list   superseded            Show superseded releases helm list  o yaml                 Prints the output in the specified format  Allowed values  table  json  yaml  default table  helm status  release              This command shows the status of a named release  helm status  release    revision  number      if set  display the status of the named release with revision helm history  release             Historical revisions for a given release  helm env                          Env prints out all the environment information in use by Helm                                                                                Download Release Information     bash helm get all  release         A human readable collection of information about the notes  hooks  supplied values  and generated manifest file of the given release  helm get hooks  release       This command downloads hooks for a given release  Hooks are formatted in YAML and separated by the YAML      n  separator  helm get manifest  release    A manifest is a YAML encoded representation of the Kubernetes resources that were generated from this release s chart s   If a chart is dependent on other charts  those resources will also be included in the manifest  helm get notes  release       Shows notes provided by the chart of a named release  helm get values  release      Downloads a values file for a given release  use  o to format output                                                                                Plugin Management     bash helm plugin install  path url1        Install plugins helm plugin list                      View a list of all installed plugins helm plugin update  plugin            Update plugins helm plugin uninstall  plugin         Uninstall a plugin


helm title Installing Helm aliases docs install Learn how to install and get running with Helm weight 2 This guide shows how to install the Helm CLI Helm can be installed either from source or from pre built binary releases

Answer:
---
title: "Installing Helm"
description: "Learn how to install and get running with Helm."
weight: 2
aliases: ["/docs/install/"]
---

This guide shows how to install the Helm CLI. Helm can be installed either from
source, or from pre-built binary releases.

## From The Helm Project

The Helm project provides two ways to fetch and install Helm. These are the
official methods to get Helm releases. In addition to that, the Helm community
provides methods to install Helm through different package managers.
Installation through those methods can be found below the official methods.

### From the Binary Releases

Every [release](https://github.com/helm/helm/releases) of Helm provides binary
releases for a variety of OSes. These binary versions can be manually downloaded
and installed.

1. Download your [desired version](https://github.com/helm/helm/releases)
2. Unpack it (`tar -zxvf helm-v3.0.0-linux-amd64.tar.gz`)
3. Find the `helm` binary in the unpacked directory, and move it to its desired
   destination (`mv linux-amd64/helm /usr/local/bin/helm`)

From there, you should be able to run the client and [add the stable
chart repository](https://helm.sh/docs/intro/quickstart/#initialize-a-helm-chart-repository):
`helm help`.

**Note:** Helm automated tests are performed for Linux AMD64 only during
GitHub Actions builds and releases. Testing of other OSes are the responsibility of
the community requesting Helm for the OS in question.

### From Script

Helm now has an installer script that will automatically grab the latest version
of Helm and [install it
locally](https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3).

You can fetch that script, and then execute it locally. It's well documented so
that you can read through it and understand what it is doing before you run it.

```console
$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
$ chmod 700 get_helm.sh
$ ./get_helm.sh
```

Yes, you can `curl
https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash` if
you want to live on the edge.

## Through Package Managers

The Helm community provides the ability to install Helm through operating system
package managers. These are not supported by the Helm project and are not
considered trusted 3rd parties.

### From Homebrew (macOS)

Members of the Helm community have contributed a Helm formula build to Homebrew.
This formula is generally up to date.

```console
brew install helm
```

(Note: There is also a formula for emacs-helm, which is a different project.)

### From Chocolatey (Windows)

Members of the Helm community have contributed a [Helm
package](https://chocolatey.org/packages/kubernetes-helm) build to
[Chocolatey](https://chocolatey.org/). This package is generally up to date.

```console
choco install kubernetes-helm
```

### From Scoop (Windows)

Members of the Helm community have contributed a [Helm
package](https://github.com/ScoopInstaller/Main/blob/master/bucket/helm.json) build to [Scoop](https://scoop.sh). This package is generally up to date.

```console
scoop install helm
```

### From Winget (Windows)

Members of the Helm community have contributed a [Helm
package](https://github.com/microsoft/winget-pkgs/tree/master/manifests/h/Helm/Helm) build to [Winget](https://learn.microsoft.com/en-us/windows/package-manager/). This package is generally up to date.

```console
winget install Helm.Helm
```

### From Apt (Debian/Ubuntu)

Members of the Helm community have contributed a [Helm
package](https://helm.baltorepo.com/stable/debian/) for Apt. This package is
generally up to date.

```console
curl https://baltocdn.com/helm/signing.asc | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null
sudo apt-get install apt-transport-https --yes
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/helm.gpg] https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
sudo apt-get update
sudo apt-get install helm
```

### From dnf/yum (fedora)
Since Fedora 35, helm is available on the official repository.
You can install helm with invoking:

```console
sudo dnf install helm
```

### From Snap

The [Snapcrafters](https://github.com/snapcrafters) community maintains the Snap
version of the [Helm package](https://snapcraft.io/helm):

```console
sudo snap install helm --classic
```

### From pkg (FreeBSD)

Members of the FreeBSD community have contributed a [Helm
package](https://www.freshports.org/sysutils/helm) build to the
[FreeBSD Ports Collection](https://man.freebsd.org/ports).
This package is generally up to date.

```console
pkg install helm
```

### Development Builds

In addition to releases you can download or install development snapshots of
Helm.

### From Canary Builds

"Canary" builds are versions of the Helm software that are built from the latest
`main` branch. They are not official releases, and may not be stable. However,
they offer the opportunity to test the cutting edge features.

Canary Helm binaries are stored at [get.helm.sh](https://get.helm.sh). Here are
links to the common builds:

- [Linux AMD64](https://get.helm.sh/helm-canary-linux-amd64.tar.gz)
- [macOS AMD64](https://get.helm.sh/helm-canary-darwin-amd64.tar.gz)
- [Experimental Windows
  AMD64](https://get.helm.sh/helm-canary-windows-amd64.zip)

### From Source (Linux, macOS)

Building Helm from source is slightly more work, but is the best way to go if
you want to test the latest (pre-release) Helm version.

You must have a working Go environment.

```console
$ git clone https://github.com/helm/helm.git
$ cd helm
$ make
```

If required, it will fetch the dependencies and cache them, and validate
configuration. It will then compile `helm` and place it in `bin/helm`.

## Conclusion

In most cases, installation is as simple as getting a pre-built `helm` binary.
This document covers additional cases for those who want to do more
sophisticated things with Helm.

Once you have the Helm Client successfully installed, you can move on to using
Helm to manage charts and [add the stable
chart repository](https://helm.sh/docs/intro/quickstart/#initialize-a-helm-chart-repository).

title   Installing Helm  description   Learn how to install and get running with Helm   weight  2 aliases     docs install         This guide shows how to install the Helm CLI  Helm can be installed either from source  or from pre built binary releases      From The Helm Project  The Helm project provides two ways to fetch and install Helm  These are the official methods to get Helm releases  In addition to that  the Helm community provides methods to install Helm through different package managers  Installation through those methods can be found below the official methods       From the Binary Releases  Every  release  https   github com helm helm releases  of Helm provides binary releases for a variety of OSes  These binary versions can be manually downloaded and installed   1  Download your  desired version  https   github com helm helm releases  2  Unpack it   tar  zxvf helm v3 0 0 linux amd64 tar gz   3  Find the  helm  binary in the unpacked directory  and move it to its desired    destination   mv linux amd64 helm  usr local bin helm    From there  you should be able to run the client and  add the stable chart repository  https   helm sh docs intro quickstart  initialize a helm chart repository    helm help      Note    Helm automated tests are performed for Linux AMD64 only during GitHub Actions builds and releases  Testing of other OSes are the responsibility of the community requesting Helm for the OS in question       From Script  Helm now has an installer script that will automatically grab the latest version of Helm and  install it locally  https   raw githubusercontent com helm helm main scripts get helm 3    You can fetch that script  and then execute it locally  It s well documented so that you can read through it and understand what it is doing before you run it      console   curl  fsSL  o get helm sh https   raw githubusercontent com helm helm main scripts get helm 3   chmod 700 get helm sh     get helm sh      Yes  you can  curl https   raw githubusercontent com helm helm main scripts get helm 3   bash  if you want to live on the edge      Through Package Managers  The Helm community provides the ability to install Helm through operating system package managers  These are not supported by the Helm project and are not considered trusted 3rd parties       From Homebrew  macOS   Members of the Helm community have contributed a Helm formula build to Homebrew  This formula is generally up to date      console brew install helm       Note  There is also a formula for emacs helm  which is a different project        From Chocolatey  Windows   Members of the Helm community have contributed a  Helm package  https   chocolatey org packages kubernetes helm  build to  Chocolatey  https   chocolatey org    This package is generally up to date      console choco install kubernetes helm          From Scoop  Windows   Members of the Helm community have contributed a  Helm package  https   github com ScoopInstaller Main blob master bucket helm json  build to  Scoop  https   scoop sh   This package is generally up to date      console scoop install helm          From Winget  Windows   Members of the Helm community have contributed a  Helm package  https   github com microsoft winget pkgs tree master manifests h Helm Helm  build to  Winget  https   learn microsoft com en us windows package manager    This package is generally up to date      console winget install Helm Helm          From Apt  Debian Ubuntu   Members of the Helm community have contributed a  Helm package  https   helm baltorepo com stable debian   for Apt  This package is generally up to date      console curl https   baltocdn com helm signing asc   gpg   dearmor   sudo tee  usr share keyrings helm gpg    dev null sudo apt get install apt transport https   yes echo  deb  arch   dpkg   print architecture  signed by  usr share keyrings helm gpg  https   baltocdn com helm stable debian  all main    sudo tee  etc apt sources list d helm stable debian list sudo apt get update sudo apt get install helm          From dnf yum  fedora  Since Fedora 35  helm is available on the official repository  You can install helm with invoking      console sudo dnf install helm          From Snap  The  Snapcrafters  https   github com snapcrafters  community maintains the Snap version of the  Helm package  https   snapcraft io helm       console sudo snap install helm   classic          From pkg  FreeBSD   Members of the FreeBSD community have contributed a  Helm package  https   www freshports org sysutils helm  build to the  FreeBSD Ports Collection  https   man freebsd org ports   This package is generally up to date      console pkg install helm          Development Builds  In addition to releases you can download or install development snapshots of Helm       From Canary Builds   Canary  builds are versions of the Helm software that are built from the latest  main  branch  They are not official releases  and may not be stable  However  they offer the opportunity to test the cutting edge features   Canary Helm binaries are stored at  get helm sh  https   get helm sh   Here are links to the common builds      Linux AMD64  https   get helm sh helm canary linux amd64 tar gz     macOS AMD64  https   get helm sh helm canary darwin amd64 tar gz     Experimental Windows   AMD64  https   get helm sh helm canary windows amd64 zip       From Source  Linux  macOS   Building Helm from source is slightly more work  but is the best way to go if you want to test the latest  pre release  Helm version   You must have a working Go environment      console   git clone https   github com helm helm git   cd helm   make      If required  it will fetch the dependencies and cache them  and validate configuration  It will then compile  helm  and place it in  bin helm       Conclusion  In most cases  installation is as simple as getting a pre built  helm  binary  This document covers additional cases for those who want to do more sophisticated things with Helm   Once you have the Helm Client successfully installed  you can move on to using Helm to manage charts and  add the stable chart repository  https   helm sh docs intro quickstart  initialize a helm chart repository


helm Explains the basics of Helm install md the Helm client Kubernetes cluster It assumes that you have already installed ref title Using Helm weight 3 This guide explains the basics of using Helm to manage packages on your

Answer:
---
title: "Using Helm"
description: "Explains the basics of Helm."
weight: 3
---

This guide explains the basics of using Helm to manage packages on your
Kubernetes cluster. It assumes that you have already [installed]() the Helm client.

If you are simply interested in running a few quick commands, you may wish to
begin with the [Quickstart Guide](). This chapter
covers the particulars of Helm commands, and explains how to use Helm.

## Three Big Concepts

A *Chart* is a Helm package. It contains all of the resource definitions
necessary to run an application, tool, or service inside of a Kubernetes
cluster. Think of it like the Kubernetes equivalent of a Homebrew formula, an
Apt dpkg, or a Yum RPM file.

A *Repository* is the place where charts can be collected and shared. It's like
Perl's [CPAN archive](https://www.cpan.org) or the [Fedora Package
Database](https://src.fedoraproject.org/), but for Kubernetes packages.

A *Release* is an instance of a chart running in a Kubernetes cluster. One chart
can often be installed many times into the same cluster. And each time it is
installed, a new _release_ is created. Consider a MySQL chart. If you want two
databases running in your cluster, you can install that chart twice. Each one
will have its own _release_, which will in turn have its own _release name_.

With these concepts in mind, we can now explain Helm like this:

Helm installs _charts_ into Kubernetes, creating a new _release_ for each
installation. And to find new charts, you can search Helm chart _repositories_.

## 'helm search': Finding Charts

Helm comes with a powerful search command. It can be used to search two
different types of source:

- `helm search hub` searches [the Artifact Hub](https://artifacthub.io), which
  lists helm charts from dozens of different repositories.
- `helm search repo` searches the repositories that you have added to your local
  helm client (with `helm repo add`). This search is done over local data, and
  no public network connection is needed.

You can find publicly available charts by running `helm search hub`:

```console
$ helm search hub wordpress
URL                                                 CHART VERSION APP VERSION DESCRIPTION
https://hub.helm.sh/charts/bitnami/wordpress        7.6.7         5.2.4       Web publishing platform for building blogs and ...
https://hub.helm.sh/charts/presslabs/wordpress-...  v0.6.3        v0.6.3      Presslabs WordPress Operator Helm Chart
https://hub.helm.sh/charts/presslabs/wordpress-...  v0.7.1        v0.7.1      A Helm chart for deploying a WordPress site on ...
```

The above searches for all `wordpress` charts on Artifact Hub.

With no filter, `helm search hub` shows you all of the available charts.

`helm search hub` exposes the URL to the location on [artifacthub.io](https://artifacthub.io/) but not the actual Helm repo. `helm search hub --list-repo-url` exposes the actual Helm repo URL which comes in handy when you are looking to add a new repo: `helm repo
add [NAME] [URL]`.

Using `helm search repo`, you can find the names of the charts in repositories
you have already added:

```console
$ helm repo add brigade https://brigadecore.github.io/charts
"brigade" has been added to your repositories
$ helm search repo brigade
NAME                          CHART VERSION APP VERSION DESCRIPTION
brigade/brigade               1.3.2         v1.2.1      Brigade provides event-driven scripting of Kube...
brigade/brigade-github-app    0.4.1         v0.2.1      The Brigade GitHub App, an advanced gateway for...
brigade/brigade-github-oauth  0.2.0         v0.20.0     The legacy OAuth GitHub Gateway for Brigade
brigade/brigade-k8s-gateway   0.1.0                     A Helm chart for Kubernetes
brigade/brigade-project       1.0.0         v1.0.0      Create a Brigade project
brigade/kashti                0.4.0         v0.4.0      A Helm chart for Kubernetes
```

Helm search uses a fuzzy string matching algorithm, so you can type parts of
words or phrases:

```console
$ helm search repo kash
NAME            CHART VERSION APP VERSION DESCRIPTION
brigade/kashti  0.4.0         v0.4.0      A Helm chart for Kubernetes
```

Search is a good way to find available packages. Once you have found a package
you want to install, you can use `helm install` to install it.

## 'helm install': Installing a Package

To install a new package, use the `helm install` command. At its simplest, it
takes two arguments: A release name that you pick, and the name of the chart you
want to install.

```console
$ helm install happy-panda bitnami/wordpress
NAME: happy-panda
LAST DEPLOYED: Tue Jan 26 10:27:17 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
** Please be patient while the chart is being deployed **

Your WordPress site can be accessed through the following DNS name from within your cluster:

    happy-panda-wordpress.default.svc.cluster.local (port 80)

To access your WordPress site from outside the cluster follow the steps below:

1. Get the WordPress URL by running these commands:

  NOTE: It may take a few minutes for the LoadBalancer IP to be available.
        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'

   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "")
   echo "WordPress URL: http://$SERVICE_IP/"
   echo "WordPress Admin URL: http://$SERVICE_IP/admin"

2. Open a browser and access WordPress using the obtained URL.

3. Login with the following credentials below to see your blog:

  echo Username: user
  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)
```

Now the `wordpress` chart is installed. Note that installing a chart creates a
new _release_ object. The release above is named `happy-panda`. (If you want
Helm to generate a name for you, leave off the release name and use
`--generate-name`.)

During installation, the `helm` client will print useful information about which
resources were created, what the state of the release is, and also whether there
are additional configuration steps you can or should take.

Helm installs resources in the following order:

- Namespace
- NetworkPolicy
- ResourceQuota
- LimitRange
- PodSecurityPolicy
- PodDisruptionBudget
- ServiceAccount
- Secret
- SecretList
- ConfigMap
- StorageClass
- PersistentVolume
- PersistentVolumeClaim
- CustomResourceDefinition
- ClusterRole
- ClusterRoleList
- ClusterRoleBinding
- ClusterRoleBindingList
- Role
- RoleList
- RoleBinding
- RoleBindingList
- Service
- DaemonSet
- Pod
- ReplicationController
- ReplicaSet
- Deployment
- HorizontalPodAutoscaler
- StatefulSet
- Job
- CronJob
- Ingress
- APIService

Helm does not wait until all of the resources are running before it exits. Many
charts require Docker images that are over 600MB in size, and may take a long
time to install into the cluster.

To keep track of a release's state, or to re-read configuration information, you
can use `helm status`:

```console
$ helm status happy-panda
NAME: happy-panda
LAST DEPLOYED: Tue Jan 26 10:27:17 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
** Please be patient while the chart is being deployed **

Your WordPress site can be accessed through the following DNS name from within your cluster:

    happy-panda-wordpress.default.svc.cluster.local (port 80)

To access your WordPress site from outside the cluster follow the steps below:

1. Get the WordPress URL by running these commands:

  NOTE: It may take a few minutes for the LoadBalancer IP to be available.
        Watch the status with: 'kubectl get svc --namespace default -w happy-panda-wordpress'

   export SERVICE_IP=$(kubectl get svc --namespace default happy-panda-wordpress --template "")
   echo "WordPress URL: http://$SERVICE_IP/"
   echo "WordPress Admin URL: http://$SERVICE_IP/admin"

2. Open a browser and access WordPress using the obtained URL.

3. Login with the following credentials below to see your blog:

  echo Username: user
  echo Password: $(kubectl get secret --namespace default happy-panda-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)
```

The above shows the current state of your release.

### Customizing the Chart Before Installing

Installing the way we have here will only use the default configuration options
for this chart. Many times, you will want to customize the chart to use your
preferred configuration.

To see what options are configurable on a chart, use `helm show values`:

```console
$ helm show values bitnami/wordpress
## Global Docker image parameters
## Please, note that this will override the image parameters, including dependencies, configured to use the global value
## Current available global Docker image parameters: imageRegistry and imagePullSecrets
##
# global:
#   imageRegistry: myRegistryName
#   imagePullSecrets:
#     - myRegistryKeySecretName
#   storageClass: myStorageClass

## Bitnami WordPress image version
## ref: https://hub.docker.com/r/bitnami/wordpress/tags/
##
image:
  registry: docker.io
  repository: bitnami/wordpress
  tag: 5.6.0-debian-10-r35
  [..]
```

You can then override any of these settings in a YAML formatted file, and then
pass that file during installation.

```console
$ echo '{mariadb.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml
$ helm install -f values.yaml bitnami/wordpress --generate-name
```

The above will create a default MariaDB user with the name `user0`, and grant
this user access to a newly created `user0db` database, but will accept all the
rest of the defaults for that chart.

There are two ways to pass configuration data during install:

- `--values` (or `-f`): Specify a YAML file with overrides. This can be
  specified multiple times and the rightmost file will take precedence
- `--set`: Specify overrides on the command line.

If both are used, `--set` values are merged into `--values` with higher
precedence. Overrides specified with `--set` are persisted in a Secret.
Values that have been `--set` can be viewed for a given release with `helm get
values <release-name>`. Values that have been `--set` can be cleared by running
`helm upgrade` with `--reset-values` specified.

#### The Format and Limitations of `--set`

The `--set` option takes zero or more name/value pairs. At its simplest, it is
used like this: `--set name=value`. The YAML equivalent of that is:

```yaml
name: value
```

Multiple values are separated by `,` characters. So `--set a=b,c=d` becomes:

```yaml
a: b
c: d
```

More complex expressions are supported. For example, `--set outer.inner=value`
is translated into this:
```yaml
outer:
  inner: value
```

Lists can be expressed by enclosing values in `{` and `}`. For example, `--set
name={a, b, c}` translates to:

```yaml
name:
  - a
  - b
  - c
```

Certain name/key can be set to be `null` or to be an empty array `[]`. For example, `--set name=[],a=null` translates

```yaml
name:
  - a
  - b
  - c
a: b
```

to

```yaml
name: []
a: null
```

As of Helm 2.5.0, it is possible to access list items using an array index
syntax. For example, `--set servers[0].port=80` becomes:

```yaml
servers:
  - port: 80
```

Multiple values can be set this way. The line `--set
servers[0].port=80,servers[0].host=example` becomes:

```yaml
servers:
  - port: 80
    host: example
```

Sometimes you need to use special characters in your `--set` lines. You can use
a backslash to escape the characters; `--set name=value1\,value2` will become:

```yaml
name: "value1,value2"
```

Similarly, you can escape dot sequences as well, which may come in handy when
charts use the `toYaml` function to parse annotations, labels and node
selectors. The syntax for `--set nodeSelector."kubernetes\.io/role"=master`
becomes:

```yaml
nodeSelector:
  kubernetes.io/role: master
```

Deeply nested data structures can be difficult to express using `--set`. Chart
designers are encouraged to consider the `--set` usage when designing the format
of a `values.yaml` file  (read more about [Values Files](../chart_template_guide/values_files/)).

### More Installation Methods

The `helm install` command can install from several sources:

- A chart repository (as we've seen above)
- A local chart archive (`helm install foo foo-0.1.1.tgz`)
- An unpacked chart directory (`helm install foo path/to/foo`)
- A full URL (`helm install foo https://example.com/charts/foo-1.2.3.tgz`)

## 'helm upgrade' and 'helm rollback': Upgrading a Release, and Recovering on Failure

When a new version of a chart is released, or when you want to change the
configuration of your release, you can use the `helm upgrade` command.

An upgrade takes an existing release and upgrades it according to the
information you provide. Because Kubernetes charts can be large and complex,
Helm tries to perform the least invasive upgrade. It will only update things
that have changed since the last release.

```console
$ helm upgrade -f panda.yaml happy-panda bitnami/wordpress
```

In the above case, the `happy-panda` release is upgraded with the same chart,
but with a new YAML file:

```yaml
mariadb.auth.username: user1
```

We can use `helm get values` to see whether that new setting took effect.

```console
$ helm get values happy-panda
mariadb:
  auth:
    username: user1
```

The `helm get` command is a useful tool for looking at a release in the cluster.
And as we can see above, it shows that our new values from `panda.yaml` were
deployed to the cluster.

Now, if something does not go as planned during a release, it is easy to roll
back to a previous release using `helm rollback [RELEASE] [REVISION]`.

```console
$ helm rollback happy-panda 1
```

The above rolls back our happy-panda to its very first release version. A
release version is an incremental revision. Every time an install, upgrade, or
rollback happens, the revision number is incremented by 1. The first revision
number is always 1. And we can use `helm history [RELEASE]` to see revision
numbers for a certain release.

## Helpful Options for Install/Upgrade/Rollback

There are several other helpful options you can specify for customizing the
behavior of Helm during an install/upgrade/rollback. Please note that this is
not a full list of cli flags. To see a description of all flags, just run `helm
<command> --help`.

- `--timeout`: A [Go duration](https://golang.org/pkg/time/#ParseDuration) value
  to wait for Kubernetes commands to complete. This defaults to `5m0s`.
- `--wait`: Waits until all Pods are in a ready state, PVCs are bound,
  Deployments have minimum (`Desired` minus `maxUnavailable`) Pods in ready
  state and Services have an IP address (and Ingress if a `LoadBalancer`) before
  marking the release as successful. It will wait for as long as the `--timeout`
  value. If timeout is reached, the release will be marked as `FAILED`. Note: In
  scenarios where Deployment has `replicas` set to 1 and `maxUnavailable` is not
  set to 0 as part of rolling update strategy, `--wait` will return as ready as
  it has satisfied the minimum Pod in ready condition.
- `--no-hooks`: This skips running hooks for the command
- `--recreate-pods` (only available for `upgrade` and `rollback`): This flag
  will cause all pods to be recreated (with the exception of pods belonging to
  deployments). (DEPRECATED in Helm 3)

## 'helm uninstall': Uninstalling a Release

When it is time to uninstall a release from the cluster, use the `helm
uninstall` command:

```console
$ helm uninstall happy-panda
```

This will remove the release from the cluster. You can see all of your currently
deployed releases with the `helm list` command:

```console
$ helm list
NAME            VERSION UPDATED                         STATUS          CHART
inky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0
```

From the output above, we can see that the `happy-panda` release was
uninstalled.

In previous versions of Helm, when a release was deleted, a record of its
deletion would remain. In Helm 3, deletion removes the release record as well.
If you wish to keep a deletion release record, use `helm uninstall
--keep-history`. Using `helm list --uninstalled` will only show releases that
were uninstalled with the `--keep-history` flag.

The `helm list --all` flag will show you all release records that Helm has
retained, including records for failed or deleted items (if `--keep-history` was
specified):

```console
$  helm list --all
NAME            VERSION UPDATED                         STATUS          CHART
happy-panda     2       Wed Sep 28 12:47:54 2016        UNINSTALLED     wordpress-10.4.5.6.0
inky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0
kindred-angelf  2       Tue Sep 27 16:16:10 2016        UNINSTALLED     alpine-0.1.0
```

Note that because releases are now deleted by default, it is no longer possible
to rollback an uninstalled resource.

## 'helm repo': Working with Repositories

Helm 3 no longer ships with a default chart repository. The `helm repo` command
group provides commands to add, list, and remove repositories.

You can see which repositories are configured using `helm repo list`:

```console
$ helm repo list
NAME            URL
stable          https://charts.helm.sh/stable
mumoshu         https://mumoshu.github.io/charts
```

And new repositories can be added with `helm repo
add [NAME] [URL]`:

```console
$ helm repo add dev https://example.com/dev-charts
```

Because chart repositories change frequently, at any point you can make sure
your Helm client is up to date by running `helm repo update`.

Repositories can be removed with `helm repo remove`.

## Creating Your Own Charts

The [Chart Development Guide]() explains how
to develop your own charts. But you can get started quickly by using the `helm
create` command:

```console
$ helm create deis-workflow
Creating deis-workflow
```

Now there is a chart in `./deis-workflow`. You can edit it and create your own
templates.

As you edit your chart, you can validate that it is well-formed by running `helm
lint`.

When it's time to package the chart up for distribution, you can run the `helm
package` command:

```console
$ helm package deis-workflow
deis-workflow-0.1.0.tgz
```

And that chart can now easily be installed by `helm install`:

```console
$ helm install deis-workflow ./deis-workflow-0.1.0.tgz
...
```

Charts that are packaged can be loaded into chart repositories. See the
documentation for [Helm chart
repositories]() for more details.

## Conclusion

This chapter has covered the basic usage patterns of the `helm` client,
including searching, installation, upgrading, and uninstalling. It has also
covered useful utility commands like `helm status`, `helm get`, and `helm repo`.

For more information on these commands, take a look at Helm's built-in help:
`helm help`.

In the [next chapter](../howto/charts_tips_and_tricks/), we look at the process of developing charts.

title   Using Helm  description   Explains the basics of Helm   weight  3      This guide explains the basics of using Helm to manage packages on your Kubernetes cluster  It assumes that you have already  installed    the Helm client   If you are simply interested in running a few quick commands  you may wish to begin with the  Quickstart Guide     This chapter covers the particulars of Helm commands  and explains how to use Helm      Three Big Concepts  A  Chart  is a Helm package  It contains all of the resource definitions necessary to run an application  tool  or service inside of a Kubernetes cluster  Think of it like the Kubernetes equivalent of a Homebrew formula  an Apt dpkg  or a Yum RPM file   A  Repository  is the place where charts can be collected and shared  It s like Perl s  CPAN archive  https   www cpan org  or the  Fedora Package Database  https   src fedoraproject org    but for Kubernetes packages   A  Release  is an instance of a chart running in a Kubernetes cluster  One chart can often be installed many times into the same cluster  And each time it is installed  a new  release  is created  Consider a MySQL chart  If you want two databases running in your cluster  you can install that chart twice  Each one will have its own  release   which will in turn have its own  release name    With these concepts in mind  we can now explain Helm like this   Helm installs  charts  into Kubernetes  creating a new  release  for each installation  And to find new charts  you can search Helm chart  repositories        helm search   Finding Charts  Helm comes with a powerful search command  It can be used to search two different types of source      helm search hub  searches  the Artifact Hub  https   artifacthub io   which   lists helm charts from dozens of different repositories     helm search repo  searches the repositories that you have added to your local   helm client  with  helm repo add    This search is done over local data  and   no public network connection is needed   You can find publicly available charts by running  helm search hub       console   helm search hub wordpress URL                                                 CHART VERSION APP VERSION DESCRIPTION https   hub helm sh charts bitnami wordpress        7 6 7         5 2 4       Web publishing platform for building blogs and     https   hub helm sh charts presslabs wordpress      v0 6 3        v0 6 3      Presslabs WordPress Operator Helm Chart https   hub helm sh charts presslabs wordpress      v0 7 1        v0 7 1      A Helm chart for deploying a WordPress site on          The above searches for all  wordpress  charts on Artifact Hub   With no filter   helm search hub  shows you all of the available charts    helm search hub  exposes the URL to the location on  artifacthub io  https   artifacthub io   but not the actual Helm repo   helm search hub   list repo url  exposes the actual Helm repo URL which comes in handy when you are looking to add a new repo   helm repo add  NAME   URL     Using  helm search repo   you can find the names of the charts in repositories you have already added      console   helm repo add brigade https   brigadecore github io charts  brigade  has been added to your repositories   helm search repo brigade NAME                          CHART VERSION APP VERSION DESCRIPTION brigade brigade               1 3 2         v1 2 1      Brigade provides event driven scripting of Kube    brigade brigade github app    0 4 1         v0 2 1      The Brigade GitHub App  an advanced gateway for    brigade brigade github oauth  0 2 0         v0 20 0     The legacy OAuth GitHub Gateway for Brigade brigade brigade k8s gateway   0 1 0                     A Helm chart for Kubernetes brigade brigade project       1 0 0         v1 0 0      Create a Brigade project brigade kashti                0 4 0         v0 4 0      A Helm chart for Kubernetes      Helm search uses a fuzzy string matching algorithm  so you can type parts of words or phrases      console   helm search repo kash NAME            CHART VERSION APP VERSION DESCRIPTION brigade kashti  0 4 0         v0 4 0      A Helm chart for Kubernetes      Search is a good way to find available packages  Once you have found a package you want to install  you can use  helm install  to install it       helm install   Installing a Package  To install a new package  use the  helm install  command  At its simplest  it takes two arguments  A release name that you pick  and the name of the chart you want to install      console   helm install happy panda bitnami wordpress NAME  happy panda LAST DEPLOYED  Tue Jan 26 10 27 17 2021 NAMESPACE  default STATUS  deployed REVISION  1 NOTES     Please be patient while the chart is being deployed     Your WordPress site can be accessed through the following DNS name from within your cluster       happy panda wordpress default svc cluster local  port 80   To access your WordPress site from outside the cluster follow the steps below   1  Get the WordPress URL by running these commands     NOTE  It may take a few minutes for the LoadBalancer IP to be available          Watch the status with   kubectl get svc   namespace default  w happy panda wordpress      export SERVICE IP   kubectl get svc   namespace default happy panda wordpress   template        echo  WordPress URL  http    SERVICE IP      echo  WordPress Admin URL  http    SERVICE IP admin   2  Open a browser and access WordPress using the obtained URL   3  Login with the following credentials below to see your blog     echo Username  user   echo Password    kubectl get secret   namespace default happy panda wordpress  o jsonpath    data wordpress password     base64   decode       Now the  wordpress  chart is installed  Note that installing a chart creates a new  release  object  The release above is named  happy panda    If you want Helm to generate a name for you  leave off the release name and use    generate name     During installation  the  helm  client will print useful information about which resources were created  what the state of the release is  and also whether there are additional configuration steps you can or should take   Helm installs resources in the following order     Namespace   NetworkPolicy   ResourceQuota   LimitRange   PodSecurityPolicy   PodDisruptionBudget   ServiceAccount   Secret   SecretList   ConfigMap   StorageClass   PersistentVolume   PersistentVolumeClaim   CustomResourceDefinition   ClusterRole   ClusterRoleList   ClusterRoleBinding   ClusterRoleBindingList   Role   RoleList   RoleBinding   RoleBindingList   Service   DaemonSet   Pod   ReplicationController   ReplicaSet   Deployment   HorizontalPodAutoscaler   StatefulSet   Job   CronJob   Ingress   APIService  Helm does not wait until all of the resources are running before it exits  Many charts require Docker images that are over 600MB in size  and may take a long time to install into the cluster   To keep track of a release s state  or to re read configuration information  you can use  helm status       console   helm status happy panda NAME  happy panda LAST DEPLOYED  Tue Jan 26 10 27 17 2021 NAMESPACE  default STATUS  deployed REVISION  1 NOTES     Please be patient while the chart is being deployed     Your WordPress site can be accessed through the following DNS name from within your cluster       happy panda wordpress default svc cluster local  port 80   To access your WordPress site from outside the cluster follow the steps below   1  Get the WordPress URL by running these commands     NOTE  It may take a few minutes for the LoadBalancer IP to be available          Watch the status with   kubectl get svc   namespace default  w happy panda wordpress      export SERVICE IP   kubectl get svc   namespace default happy panda wordpress   template        echo  WordPress URL  http    SERVICE IP      echo  WordPress Admin URL  http    SERVICE IP admin   2  Open a browser and access WordPress using the obtained URL   3  Login with the following credentials below to see your blog     echo Username  user   echo Password    kubectl get secret   namespace default happy panda wordpress  o jsonpath    data wordpress password     base64   decode       The above shows the current state of your release       Customizing the Chart Before Installing  Installing the way we have here will only use the default configuration options for this chart  Many times  you will want to customize the chart to use your preferred configuration   To see what options are configurable on a chart  use  helm show values       console   helm show values bitnami wordpress    Global Docker image parameters    Please  note that this will override the image parameters  including dependencies  configured to use the global value    Current available global Docker image parameters  imageRegistry and imagePullSecrets      global      imageRegistry  myRegistryName     imagePullSecrets          myRegistryKeySecretName     storageClass  myStorageClass     Bitnami WordPress image version    ref  https   hub docker com r bitnami wordpress tags     image    registry  docker io   repository  bitnami wordpress   tag  5 6 0 debian 10 r35             You can then override any of these settings in a YAML formatted file  and then pass that file during installation      console   echo   mariadb auth database  user0db  mariadb auth username  user0     values yaml   helm install  f values yaml bitnami wordpress   generate name      The above will create a default MariaDB user with the name  user0   and grant this user access to a newly created  user0db  database  but will accept all the rest of the defaults for that chart   There are two ways to pass configuration data during install        values   or   f    Specify a YAML file with overrides  This can be   specified multiple times and the rightmost file will take precedence      set   Specify overrides on the command line   If both are used     set  values are merged into    values  with higher precedence  Overrides specified with    set  are persisted in a Secret  Values that have been    set  can be viewed for a given release with  helm get values  release name    Values that have been    set  can be cleared by running  helm upgrade  with    reset values  specified        The Format and Limitations of    set   The    set  option takes zero or more name value pairs  At its simplest  it is used like this     set name value   The YAML equivalent of that is      yaml name  value      Multiple values are separated by     characters  So    set a b c d  becomes      yaml a  b c  d      More complex expressions are supported  For example     set outer inner value  is translated into this     yaml outer    inner  value      Lists can be expressed by enclosing values in     and      For example     set name  a  b  c   translates to      yaml name      a     b     c      Certain name key can be set to be  null  or to be an empty array       For example     set name    a null  translates     yaml name      a     b     c a  b      to     yaml name     a  null      As of Helm 2 5 0  it is possible to access list items using an array index syntax  For example     set servers 0  port 80  becomes      yaml servers      port  80      Multiple values can be set this way  The line    set servers 0  port 80 servers 0  host example  becomes      yaml servers      port  80     host  example      Sometimes you need to use special characters in your    set  lines  You can use a backslash to escape the characters     set name value1  value2  will become      yaml name   value1 value2       Similarly  you can escape dot sequences as well  which may come in handy when charts use the  toYaml  function to parse annotations  labels and node selectors  The syntax for    set nodeSelector  kubernetes  io role  master  becomes      yaml nodeSelector    kubernetes io role  master      Deeply nested data structures can be difficult to express using    set   Chart designers are encouraged to consider the    set  usage when designing the format of a  values yaml  file   read more about  Values Files     chart template guide values files          More Installation Methods  The  helm install  command can install from several sources     A chart repository  as we ve seen above    A local chart archive   helm install foo foo 0 1 1 tgz     An unpacked chart directory   helm install foo path to foo     A full URL   helm install foo https   example com charts foo 1 2 3 tgz        helm upgrade  and  helm rollback   Upgrading a Release  and Recovering on Failure  When a new version of a chart is released  or when you want to change the configuration of your release  you can use the  helm upgrade  command   An upgrade takes an existing release and upgrades it according to the information you provide  Because Kubernetes charts can be large and complex  Helm tries to perform the least invasive upgrade  It will only update things that have changed since the last release      console   helm upgrade  f panda yaml happy panda bitnami wordpress      In the above case  the  happy panda  release is upgraded with the same chart  but with a new YAML file      yaml mariadb auth username  user1      We can use  helm get values  to see whether that new setting took effect      console   helm get values happy panda mariadb    auth      username  user1      The  helm get  command is a useful tool for looking at a release in the cluster  And as we can see above  it shows that our new values from  panda yaml  were deployed to the cluster   Now  if something does not go as planned during a release  it is easy to roll back to a previous release using  helm rollback  RELEASE   REVISION        console   helm rollback happy panda 1      The above rolls back our happy panda to its very first release version  A release version is an incremental revision  Every time an install  upgrade  or rollback happens  the revision number is incremented by 1  The first revision number is always 1  And we can use  helm history  RELEASE   to see revision numbers for a certain release      Helpful Options for Install Upgrade Rollback  There are several other helpful options you can specify for customizing the behavior of Helm during an install upgrade rollback  Please note that this is not a full list of cli flags  To see a description of all flags  just run  helm  command    help         timeout   A  Go duration  https   golang org pkg time  ParseDuration  value   to wait for Kubernetes commands to complete  This defaults to  5m0s        wait   Waits until all Pods are in a ready state  PVCs are bound    Deployments have minimum   Desired  minus  maxUnavailable   Pods in ready   state and Services have an IP address  and Ingress if a  LoadBalancer   before   marking the release as successful  It will wait for as long as the    timeout    value  If timeout is reached  the release will be marked as  FAILED   Note  In   scenarios where Deployment has  replicas  set to 1 and  maxUnavailable  is not   set to 0 as part of rolling update strategy     wait  will return as ready as   it has satisfied the minimum Pod in ready condition       no hooks   This skips running hooks for the command      recreate pods   only available for  upgrade  and  rollback    This flag   will cause all pods to be recreated  with the exception of pods belonging to   deployments    DEPRECATED in Helm 3       helm uninstall   Uninstalling a Release  When it is time to uninstall a release from the cluster  use the  helm uninstall  command      console   helm uninstall happy panda      This will remove the release from the cluster  You can see all of your currently deployed releases with the  helm list  command      console   helm list NAME            VERSION UPDATED                         STATUS          CHART inky cat        1       Wed Sep 28 12 59 46 2016        DEPLOYED        alpine 0 1 0      From the output above  we can see that the  happy panda  release was uninstalled   In previous versions of Helm  when a release was deleted  a record of its deletion would remain  In Helm 3  deletion removes the release record as well  If you wish to keep a deletion release record  use  helm uninstall   keep history   Using  helm list   uninstalled  will only show releases that were uninstalled with the    keep history  flag   The  helm list   all  flag will show you all release records that Helm has retained  including records for failed or deleted items  if    keep history  was specified       console    helm list   all NAME            VERSION UPDATED                         STATUS          CHART happy panda     2       Wed Sep 28 12 47 54 2016        UNINSTALLED     wordpress 10 4 5 6 0 inky cat        1       Wed Sep 28 12 59 46 2016        DEPLOYED        alpine 0 1 0 kindred angelf  2       Tue Sep 27 16 16 10 2016        UNINSTALLED     alpine 0 1 0      Note that because releases are now deleted by default  it is no longer possible to rollback an uninstalled resource       helm repo   Working with Repositories  Helm 3 no longer ships with a default chart repository  The  helm repo  command group provides commands to add  list  and remove repositories   You can see which repositories are configured using  helm repo list       console   helm repo list NAME            URL stable          https   charts helm sh stable mumoshu         https   mumoshu github io charts      And new repositories can be added with  helm repo add  NAME   URL        console   helm repo add dev https   example com dev charts      Because chart repositories change frequently  at any point you can make sure your Helm client is up to date by running  helm repo update    Repositories can be removed with  helm repo remove       Creating Your Own Charts  The  Chart Development Guide    explains how to develop your own charts  But you can get started quickly by using the  helm create  command      console   helm create deis workflow Creating deis workflow      Now there is a chart in    deis workflow   You can edit it and create your own templates   As you edit your chart  you can validate that it is well formed by running  helm lint    When it s time to package the chart up for distribution  you can run the  helm package  command      console   helm package deis workflow deis workflow 0 1 0 tgz      And that chart can now easily be installed by  helm install       console   helm install deis workflow   deis workflow 0 1 0 tgz          Charts that are packaged can be loaded into chart repositories  See the documentation for  Helm chart repositories    for more details      Conclusion  This chapter has covered the basic usage patterns of the  helm  client  including searching  installation  upgrading  and uninstalling  It has also covered useful utility commands like  helm status    helm get   and  helm repo    For more information on these commands  take a look at Helm s built in help   helm help    In the  next chapter     howto charts tips and tricks    we look at the process of developing charts


helm A closer look at best practices surrounding templates Structure of title Templates aliases docs topics chartbestpractices templates This part of the Best Practices Guide focuses on templates weight 3

Answer:
---
title: "Templates"
description: "A closer look at best practices surrounding templates."
weight: 3
aliases: ["/docs/topics/chart_best_practices/templates/"]
---

This part of the Best Practices Guide focuses on templates.

## Structure of `templates/`

The `templates/` directory should be structured as follows:

- Template files should have the extension `.yaml` if they produce YAML output.
  The extension `.tpl` may be used for template files that produce no formatted
  content.
- Template file names should use dashed notation (`my-example-configmap.yaml`),
  not camelcase.
- Each resource definition should be in its own template file.
- Template file names should reflect the resource kind in the name. e.g.
  `foo-pod.yaml`, `bar-svc.yaml`

## Names of Defined Templates

Defined templates (templates created inside a ` ` directive) are
globally accessible. That means that a chart and all of its subcharts will have
access to all of the templates created with ``.

For that reason, _all defined template names should be namespaced._

Correct:

```yaml

```

Incorrect:

```yaml

```
It is highly recommended that new charts are created via `helm create` command
as the template names are automatically defined as per this best practice.

## Formatting Templates

Templates should be indented using _two spaces_ (never tabs).

Template directives should have whitespace after the opening  braces and before
the closing braces:

Correct:
```

```

Incorrect:
```

```

Templates should chomp whitespace where possible:

```yaml
foo:

```

Blocks (such as control structures) may be indented to indicate flow of the
template code.

```

  Hello

```

However, since YAML is a whitespace-oriented language, it is often not possible
for code indentation to follow that convention.

## Whitespace in Generated Templates

It is preferable to keep the amount of whitespace in generated templates to a
minimum. In particular, numerous blank lines should not appear adjacent to each
other. But occasional empty lines (particularly between logical sections) is
fine.

This is best:

```yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: example
  labels:
    first: first
    second: second
```

This is okay:

```yaml
apiVersion: batch/v1
kind: Job

metadata:
  name: example

  labels:
    first: first
    second: second

```

But this should be avoided:

```yaml
apiVersion: batch/v1
kind: Job

metadata:
  name: example

  labels:
    first: first

    second: second

```

## Comments (YAML Comments vs. Template Comments)

Both YAML and Helm Templates have comment markers.

YAML comments:
```yaml
# This is a comment
type: sprocket
```

Template Comments:
```yaml

type: frobnitz
```

Template comments should be used when documenting features of a template, such
as explaining a defined template:

```yaml

```

Inside of templates, YAML comments may be used when it is useful for Helm users
to (possibly) see the comments during debugging.

```yaml
# This may cause problems if the value is more than 100Gi
memory:
```

The comment above is visible when the user runs `helm install --debug`, while
comments specified in `` sections are not.

Beware of adding `#` YAML comments on template sections containing Helm values that may be required by certain template functions.

For example, if `required` function is introduced to the above example, and `maxMem` is unset, then a `#` YAML comment will introduce a rendering error.

Correct: `helm template` does not render this block
```yaml

*/ -}}
```

Incorrect: `helm template` returns `Error: execution error at (templates/test.yaml:2:13): maxMem must be set`
```yaml
# This may cause problems if the value is more than 100Gi
# memory:
```

Review [Debugging Templates](../chart_template_guide/debugging.md) for another example of this behavior of how YAML comments are left intact.

## Use of JSON in Templates and Template Output

YAML is a superset of JSON. In some cases, using a JSON syntax can be more
readable than other YAML representations.

For example, this YAML is closer to the normal YAML method of expressing lists:

```yaml
arguments:
  - "--dirname"
  - "/foo"
```

But it is easier to read when collapsed into a JSON list style:

```yaml
arguments: ["--dirname", "/foo"]
```

Using JSON for increased legibility is good. However, JSON syntax should not be
used for representing more complex constructs.

When dealing with pure JSON embedded inside of YAML (such as init container
configuration), it is of course appropriate to use the JSON format.

title   Templates  description   A closer look at best practices surrounding templates   weight  3 aliases     docs topics chart best practices templates         This part of the Best Practices Guide focuses on templates      Structure of  templates    The  templates   directory should be structured as follows     Template files should have the extension   yaml  if they produce YAML output    The extension   tpl  may be used for template files that produce no formatted   content    Template file names should use dashed notation   my example configmap yaml      not camelcase    Each resource definition should be in its own template file    Template file names should reflect the resource kind in the name  e g     foo pod yaml    bar svc yaml      Names of Defined Templates  Defined templates  templates created inside a     directive  are globally accessible  That means that a chart and all of its subcharts will have access to all of the templates created with      For that reason   all defined template names should be namespaced    Correct      yaml         Incorrect      yaml        It is highly recommended that new charts are created via  helm create  command as the template names are automatically defined as per this best practice      Formatting Templates  Templates should be indented using  two spaces   never tabs    Template directives should have whitespace after the opening  braces and before the closing braces   Correct              Incorrect              Templates should chomp whitespace where possible      yaml foo                Blocks  such as control structures  may be indented to indicate flow of the template code          Hello       However  since YAML is a whitespace oriented language  it is often not possible for code indentation to follow that convention      Whitespace in Generated Templates  It is preferable to keep the amount of whitespace in generated templates to a minimum  In particular  numerous blank lines should not appear adjacent to each other  But occasional empty lines  particularly between logical sections  is fine   This is best      yaml apiVersion  batch v1 kind  Job metadata    name  example   labels      first  first     second  second      This is okay      yaml apiVersion  batch v1 kind  Job  metadata    name  example    labels      first  first     second  second       But this should be avoided      yaml apiVersion  batch v1 kind  Job  metadata    name  example        labels      first  first      second  second          Comments  YAML Comments vs  Template Comments   Both YAML and Helm Templates have comment markers   YAML comments     yaml   This is a comment type  sprocket      Template Comments     yaml  type  frobnitz      Template comments should be used when documenting features of a template  such as explaining a defined template      yaml           Inside of templates  YAML comments may be used when it is useful for Helm users to  possibly  see the comments during debugging      yaml   This may cause problems if the value is more than 100Gi memory        The comment above is visible when the user runs  helm install   debug   while comments specified in    sections are not   Beware of adding     YAML comments on template sections containing Helm values that may be required by certain template functions   For example  if  required  function is introduced to the above example  and  maxMem  is unset  then a     YAML comment will introduce a rendering error   Correct   helm template  does not render this block    yaml              Incorrect   helm template  returns  Error  execution error at  templates test yaml 2 13   maxMem must be set     yaml   This may cause problems if the value is more than 100Gi   memory        Review  Debugging Templates     chart template guide debugging md  for another example of this behavior of how YAML comments are left intact      Use of JSON in Templates and Template Output  YAML is a superset of JSON  In some cases  using a JSON syntax can be more readable than other YAML representations   For example  this YAML is closer to the normal YAML method of expressing lists      yaml arguments         dirname        foo       But it is easier to read when collapsed into a JSON list style      yaml arguments      dirname     foo        Using JSON for increased legibility is good  However  JSON syntax should not be used for representing more complex constructs   When dealing with pure JSON embedded inside of YAML  such as init container configuration   it is of course appropriate to use the JSON format


helm guide we provide recommendations on how you should structure and use your weight 2 title Values Focuses on how you should structure and use your values This part of the best practices guide covers using values In this part of the values with focus on designing a chart s file aliases docs topics chartbestpractices values

Answer:
---
title: "Values"
description: "Focuses on how you should structure and use your values."
weight: 2
aliases: ["/docs/topics/chart_best_practices/values/"]
---

This part of the best practices guide covers using values. In this part of the
guide, we provide recommendations on how you should structure and use your
values, with focus on designing a chart's `values.yaml` file.

## Naming Conventions

Variable names should begin with a lowercase letter, and words should be
separated with camelcase:

Correct:

```yaml
chicken: true
chickenNoodleSoup: true
```

Incorrect:

```yaml
Chicken: true  # initial caps may conflict with built-ins
chicken-noodle-soup: true # do not use hyphens in the name
```

Note that all of Helm's built-in variables begin with an uppercase letter to
easily distinguish them from user-defined values: `.Release.Name`,
`.Capabilities.KubeVersion`.

## Flat or Nested Values

YAML is a flexible format, and values may be nested deeply or flattened.

Nested:

```yaml
server:
  name: nginx
  port: 80
```

Flat:

```yaml
serverName: nginx
serverPort: 80
```

In most cases, flat should be favored over nested. The reason for this is that
it is simpler for template developers and users.

For optimal safety, a nested value must be checked at every level:

```

```

For every layer of nesting, an existence check must be done. But for flat
configuration, such checks can be skipped, making the template easier to read
and use.

```

```

When there are a large number of related variables, and at least one of them is
non-optional, nested values may be used to improve readability.

## Make Types Clear

YAML's type coercion rules are sometimes counterintuitive. For example, `foo:
false` is not the same as `foo: "false"`. Large integers like `foo: 12345678`
will get converted to scientific notation in some cases.

The easiest way to avoid type conversion errors is to be explicit about strings,
and implicit about everything else. Or, in short, _quote all strings_.

Often, to avoid the integer casting issues, it is advantageous to store your
integers as strings as well, and use `` in the template to
convert from a string back to an integer.

In most cases, explicit type tags are respected, so `foo: !!string 1234` should
treat `1234` as a string. _However_, the YAML parser consumes tags, so the type
data is lost after one parse.

## Consider How Users Will Use Your Values

There are three potential sources of values:

- A chart's `values.yaml` file
- A values file supplied by `helm install -f` or `helm upgrade -f`
- The values passed to a `--set` or `--set-string` flag on `helm install` or
  `helm upgrade`

When designing the structure of your values, keep in mind that users of your
chart may want to override them via either the `-f` flag or with the `--set`
option.

Since `--set` is more limited in expressiveness, the first guidelines for
writing your `values.yaml` file is _make it easy to override from `--set`_.

For this reason, it's often better to structure your values file using maps.

Difficult to use with `--set`:

```yaml
servers:
  - name: foo
    port: 80
  - name: bar
    port: 81
```

The above cannot be expressed with `--set` in Helm `<=2.4`. In Helm 2.5,
accessing the port on foo is `--set servers[0].port=80`. Not only is it harder
for the user to figure out, but it is prone to errors if at some later time the
order of the `servers` is changed.

Easy to use:

```yaml
servers:
  foo:
    port: 80
  bar:
    port: 81
```

Accessing foo's port is much more obvious: `--set servers.foo.port=80`.

## Document `values.yaml`

Every defined property in `values.yaml` should be documented. The documentation
string should begin with the name of the property that it describes, and then
give at least a one-sentence description.

Incorrect:

```yaml
# the host name for the webserver
serverHost: example
serverPort: 9191
```

Correct:

```yaml
# serverHost is the host name for the webserver
serverHost: example
# serverPort is the HTTP listener port for the webserver
serverPort: 9191
```

Beginning each comment with the name of the parameter it documents makes it easy
to grep out documentation, and will enable documentation tools to reliably
correlate doc strings with the parameters they describe.

title   Values  description   Focuses on how you should structure and use your values   weight  2 aliases     docs topics chart best practices values         This part of the best practices guide covers using values  In this part of the guide  we provide recommendations on how you should structure and use your values  with focus on designing a chart s  values yaml  file      Naming Conventions  Variable names should begin with a lowercase letter  and words should be separated with camelcase   Correct      yaml chicken  true chickenNoodleSoup  true      Incorrect      yaml Chicken  true    initial caps may conflict with built ins chicken noodle soup  true   do not use hyphens in the name      Note that all of Helm s built in variables begin with an uppercase letter to easily distinguish them from user defined values    Release Name     Capabilities KubeVersion       Flat or Nested Values  YAML is a flexible format  and values may be nested deeply or flattened   Nested      yaml server    name  nginx   port  80      Flat      yaml serverName  nginx serverPort  80      In most cases  flat should be favored over nested  The reason for this is that it is simpler for template developers and users    For optimal safety  a nested value must be checked at every level                 For every layer of nesting  an existence check must be done  But for flat configuration  such checks can be skipped  making the template easier to read and use             When there are a large number of related variables  and at least one of them is non optional  nested values may be used to improve readability      Make Types Clear  YAML s type coercion rules are sometimes counterintuitive  For example   foo  false  is not the same as  foo   false    Large integers like  foo  12345678  will get converted to scientific notation in some cases   The easiest way to avoid type conversion errors is to be explicit about strings  and implicit about everything else  Or  in short   quote all strings    Often  to avoid the integer casting issues  it is advantageous to store your integers as strings as well  and use    in the template to convert from a string back to an integer   In most cases  explicit type tags are respected  so  foo    string 1234  should treat  1234  as a string   However   the YAML parser consumes tags  so the type data is lost after one parse      Consider How Users Will Use Your Values  There are three potential sources of values     A chart s  values yaml  file   A values file supplied by  helm install  f  or  helm upgrade  f    The values passed to a    set  or    set string  flag on  helm install  or    helm upgrade   When designing the structure of your values  keep in mind that users of your chart may want to override them via either the   f  flag or with the    set  option   Since    set  is more limited in expressiveness  the first guidelines for writing your  values yaml  file is  make it easy to override from    set     For this reason  it s often better to structure your values file using maps   Difficult to use with    set       yaml servers      name  foo     port  80     name  bar     port  81      The above cannot be expressed with    set  in Helm    2 4   In Helm 2 5  accessing the port on foo is    set servers 0  port 80   Not only is it harder for the user to figure out  but it is prone to errors if at some later time the order of the  servers  is changed   Easy to use      yaml servers    foo      port  80   bar      port  81      Accessing foo s port is much more obvious     set servers foo port 80       Document  values yaml   Every defined property in  values yaml  should be documented  The documentation string should begin with the name of the property that it describes  and then give at least a one sentence description   Incorrect      yaml   the host name for the webserver serverHost  example serverPort  9191      Correct      yaml   serverHost is the host name for the webserver serverHost  example   serverPort is the HTTP listener port for the webserver serverPort  9191      Beginning each comment with the name of the parameter it documents makes it easy to grep out documentation  and will enable documentation tools to reliably correlate doc strings with the parameters they describe