Helm packages are named helm charts. A chart contains:

• a "Chart.yaml" file.
• a "templates" directory (contains Kubernetes' manifests).
• an optional default configuration file "values.yaml".

Installing a chart involves the following steps:

• Helm reads the chart.
• Helm replaces the custom values in their corresponding place holders in the chart templates.
• Helm sends the updated templates (manifests) to Kubernetes (which creates the requested resources).

When you run the "helm install" command on a chart, you start a new installation of that chart (a first release is created).
When you run the "helm uprade" command on a chart, you start an upgrade of an existing installation of that chart (a new release is created).
A new release is also created when you rollback an installation.

A helm chart has two versions:

• the chart version: the version of the chart.
• the app version: the version of the application packaged in the chart.

The chart version and the app version are defined in the file "Chart.yaml":

apiVersion: v2
name: test
description: test chart
version: 1.0.0
appVersion: 1.0.0

Helm uses the chart version to make versioning decisions.
Multiple charts with different versions may have the same app version.

To install a chart you need to specify its path and a name of the installation.
The name of the installation identifies a specific instance of the chart and hence it must be unique within a Kubernetes' namespace.
Installing a chart using an existing installation's name, within the same namespace, will result with an error.

To install a chart, use this command:

$ helm install my-chart-install-name my-chart-package-location

You can spefify a Kubernetes' namespace where the chart will be installed:

$ helm install --namespace my-namespace my-chart-install-name my-chart-package-location

The output of running the helm install/upgrade commands is printed in the screen:

NAME:
LAST DEPLOYED:
NAMESPACE:
STATUS:
REVISION:
TEST SUITE:

You can provide more information about the installation by adding a file with the name "NOTES.txt" under the "templates" folder of the helm chart: https://helm.sh/docs/chart_template_guide/notes_files/

You can also use the helm get notes my-chart-install-name command to print the output of the execution of these commands.

You can list your charts installations using the "helm list" command:

$ helm list

This will list the installations in the current namespace along with some information for each installation (name, namespace, revision number, last update date, status, version of the chart, version of the app).

To use another namespace, use the "--namespace" flag (or "-n"):

$ helm list --namespace my-namespace

To list all installations in all namespaces to which you have access, you can use the "--all-namespaces" flag:

$ helm list --all-namespaces

To uninstall a chart installation, you can use the "helm uninstall" command:

$ helm uninstall my-chart-install-name

You can use the "--namespace" flag to uninstall a chart in a specific namespace:

$ helm uninstall my-chart-install-name --namespace my-namespace

Helm allows you to customize the helm chart at install time by either using configuration files or command-line parameters.
By default Helm will use the "values.yaml" file, if it exists in the helm chart package.
You can put all your custom settings in the default "values.yaml" file which will be used automatically when you run the "helm install" command.

You can also put your settings in a file with a different name or even put them in multiple files.
To reference these configuration files you need to use the "--values" flag:

$ helm install my-chart-install-name my-chart-package-location --values values-location-1.yaml --values values-location-2.yaml

Note that you need to repeat the "--values" flag for each configuration file.
Note also that Helm will always use the default "values.yaml" file if you have one (even if you don't explicitly list it with the "--values" flag).
The files configuration files specified by the "--values" will override any configuration in the default "values.yaml" file.
The configuration files will be executed in the order they appear in the command-line using the "--values" flags.

You can also customize the helm chart by using the "--set" flag:

$ helm install my-chart-install-name my-chart-package-location --set my-config-param=my-value

As per the "--values" flag, the configuration specified by the "--set" flag will override any configuration you put in the configuration files you specified using the "--values" flag, which by themselves will override any configuration you put in the default "values.yaml" file.

To override nested configuration, you need to concatenate the configuration name with its parents with a "." (dot) character as a separator:

foo:
  bar:
    parm1: "value1"

$ helm install my-chart-install-name my-chart-package-location --set foo.bar.param1="another-value"

Note that you might need to escape some characters in the value of the configuration you specify using the "--set" flag.

You can use the command "helm upgrade" to upgrade an existing installation of a chart.

When you run the upgrade command, Helm will:

• read the chart.
• replace the custom values in their corresponding place holders in the chart templates.
• generate the Kubernetes' manifests.
• compare the manifests with the ones already installed.
• send only the manifests that changed to Kubernetes (which creates/re-creates the requested resources).

If no changes are made to the chart then Helm will send nothing to Kubernetes.

Kubernetes won't reload/update any resource if its configuration didn't change; the difference is calculated using the hash of the resource.
An updated external resource (i.e. ConfigMap) that's referenced by another resource (i.e. Pod) won't not make Kubernetes reload/update that resource (Pod).
To force the Pod to use the new ConfigMap, you need to restart manually the Pod or otherwise add to the Pod template the hash value of the ConfigMap.

A manual restart can be done by few means: "kubectl scale" command, "kubectl rollout" command, ...

When upgrading a chart, you should use the same configuration files used to install it; this include any parameter passed using the "--set" flag. Otherwise you might introduce new settings that will cause Helm to render new manifests that could be different from the ones already installed, and hence it will cause Kubernetes to update the existing resources.

$ helm install my-chart-install-name my-chart-package-location --values values-location-1.yaml --values values-location-2.yaml

$ helm upgrade my-chart-install-name my-chart-package-location --values values-location-1.yaml --values values-location-2.yaml

To let Helm use the latest values used to install a chart, you can use the "--reuse-values" flag. Helm will download the latest values stored in Kubernetes, and use them to perform the upgrade. You should not use neither "--values" nor "--set" when using the "--reuse-values" flag.

$ helm upgrade my-chart-install-name my-chart-package-location --reuse-values

You can use the "helm get" command to see the latest values used to install/upgrade a helm chart:

helm get values my-chart-install-name

Note the following:

• Helm will only return the values that were supplied using "--values" or "--set" flags. Those values are called "User supplied values".
  
• The values that are used implicitly from the "values.yaml" file, are called "computed values" and are not returned by the "helm get" command.

Every time we perform an install/upgrade/rollback a chart, Helm creates a new Kubernetes' secret that contains the release information. The secretes are releases records that identify each revision of the chart installation (even a failed release get a new revision number). Each release record contain information and metatdata that can be used to monitor, re-create, uninstall, rollback an installation.

$ kubect get secret

Name                                         TYPE
sh.helm.release.v1.my-chart-install-name.v1  helm.sh/release.v1
sh.helm.release.v1.my-chart-install-name.v2  helm.sh/release.v1

Notes:

• sh.helm.release.v1.my-chart-install-name.vx: identifies a specific record of the release of a chart installation.
  
• The Helm secrets have a special type "helm.sh/release.v1".
  

Helm saves up to 10 releases of each installation. Once it exceeds 10 releases for an installation, Helm delete the oldest release record of that installation.

If you uninstall a chart's installation, Helm will read the secret of the last release record of that installation. The secret provides Helm with the list of all objects that it needs to delete from Kubernetes. Note that Helm will also delete all the secrets of the releases of that installation.

To keep the release secrets (in case you want to perform a rollback of the uninstallation), you can use the "--keep-history" flag.

$ helm uninstall my-chart-install-name --keep-history

To get information about a specific record you can use the "kubectl get secret" command:

$ kubectl get secret sh.helm.release.v1.my-chart-install-name.v2 -o yaml

This will print the data and the metatdata of the specified release record.
The metadata provides information about the installation: name, modification date, status, version (revision), ...

The status of a release can be:

• "pending-install": Helm creates a release record with that status, before it sends the manifests to Kubernetes, so it can use it to track the installation.
  


• "peding-upgrade": same as "pending-install", but the new record is created for an upgrade.
  


• "peding-rollback": same as "pending-install", but the new record is created for a rollback.
  


• "uninstalling": before uinstalling an installation, its last record will be marked with the status uninstalling.
  


• "deployed": indicates that the manifests were accepted by Kubernetes (install, upgrade, rollback).
  


• "failed": indicates that the manifests were rejected by Kubernetes (install, upgrade, rollback).
  


• "superseded": if an installation is upgraded, its previous release record will be marked with the status superseded.
  


• "uninstalled": this apply only if the history of the installation is preserved. In such case the last release record will be marked with the status uninstalled.