Helm in Practice

Install a Chart in a Specific Namespace

By default, Helm installs charts in the default namespace. However, if you want to change this behavior, you have two options:

1. Using the environment variable HELM_NAMESPACE. This will set the default namespace for all Helm commands in the current shell session.

# Set the default namespace for Helm commands
export HELM_NAMESPACE=

# Install the chart without specifying the namespace
# and it will be installed in the namespace defined in HELM_NAMESPACE
helm install [RELEASE_NAME] [CHART]

1. Using the --namespace (or -n) flag at install time.

helm install [RELEASE_NAME] [CHART] --namespace [NAMESPACE]
# or
helm install [RELEASE_NAME] [CHART] -n [NAMESPACE]

Since version 3.2, you can force the creation of a namespace if it does not exist:

helm install [RELEASE_NAME] [CHART] --create-namespace --namespace [NAMESPACE]

For example, to install the WordPress chart in a namespace called wordpress:

# Delete any existing installation to start fresh
# This is optional and won't affect our installation
# in the new namespace
helm uninstall my-wordpress --ignore-not-found
kubectl delete pvc --all --ignore-not-found

# Install in the 'wordpress' namespace
helm install \
  my-wordpress \
  bitnami/wordpress \
  --namespace wordpress \
  --create-namespace

# Verify the installation
kubectl get all -n wordpress -l app.kubernetes.io/instance=my-wordpress

# Clean up
helm uninstall my-wordpress -n wordpress
kubectl delete pvc --all -n wordpress

This command will not delete any other WordPress installations in other namespaces, like the one we created earlier in the default namespace. In other words, you can have multiple releases (with the same or different names) installed in different namespaces without any conflicts. What may cause a conflict is having multiple releases with the same name in the same namespace (Helm will prevent this).

Test Installation without Deploying

Sometimes, you may want to see what resources will be created during the installation or the upgrade process without actually deploying them. Helm provides the --dry-run flag for this purpose. The general syntax is: