Managing Releases with Helm: Upgrades and Rollbacks

Previously in this course, we explored the introduction-to-helm-simplifying-kubernetes-deployment, where we installed the tool and deployed our first chart. Now that you have a chart running, you need to know how to maintain it. In this lesson, we will move beyond the initial install to master the operational lifecycle of your applications: upgrading, rolling back, and tracking versions.

The Helm Release Lifecycle

In Kubernetes, a "release" is a specific instance of a chart running in your cluster. When you run helm install, you create a release. As you evolve your application—perhaps by changing environment variables or updating image tags—you perform an upgrade.

Helm keeps a record of every change you make to a release. This record is stored as a "revision" inside the cluster's secret storage. Understanding this history is critical, as it allows you to treat your infrastructure as a series of snapshots you can revert to if an deployment fails, much like how you might manage tagging-and-versioning-mastering-docker-image-releases for your container images.

Listing and Inspecting Releases

Before you change anything, you need to see what is currently running. Helm provides the list command to show you all releases within your current namespace.

Bash
# List all releases in the current namespace
helm list

# List releases across all namespaces
helm list --all-namespaces

When you inspect a release, you’ll see the REVISION column. This is the key to managing your history. Every time you run an upgrade or rollback, this number increments. To see the history of a specific release, use:

Bash
helm history my-app-release

Performing Upgrades

An upgrade is how you apply new configuration or update container versions to an existing release. Instead of deleting and reinstalling, you run helm upgrade [RELEASE_NAME] [CHART].

If you have a local folder for your chart, you would run:

Bash
# Upgrade an existing release with new values
helm upgrade my-app-release ./my-chart --set replicaCount=3

Helm performs a three-way merge: it looks at the old manifest, the old values, and the new values to determine what actually needs to change in the cluster. This is significantly safer than manual patching, as it ensures the cluster state matches your intended configuration.

Rolling Back When Things Go Wrong

Even with careful testing, production deployments can fail. If a new upgrade breaks your application, you don't need to manually revert your YAML files or re-run previous commands. You can trigger an instant rollback to the previous known-good state.

1. Check the history: Identify the revision number that worked.

   Bash
   helm history my-app-release
   

2. Execute the rollback: Use the revision number from the output.

   Bash
   helm rollback my-app-release 1
   

Helm effectively re-applies the resources exactly as they were configured at that specific revision. It is the fastest recovery mechanism available for Helm-managed applications.

Hands-on Exercise: The Upgrade-Rollback Cycle

Let's apply this to our running project.

1. Check current status: Run helm list to find your release name.
2. Upgrade: Update a value (e.g., set a new image tag or replica count): helm upgrade [RELEASE_NAME] [CHART_PATH] --set replicaCount=2
3. Verify: Run kubectl get pods to see the new replicas spinning up.
4. Rollback: Revert to the previous state: helm rollback [RELEASE_NAME] 1
5. Verify: Observe the cluster returning to the original replica count.

Common Pitfalls

• Forgetting to update dependencies: If your chart uses sub-charts, running helm upgrade won't automatically fetch new versions of those dependencies unless you run helm dependency update first.
• Over-relying on --set: While convenient, using --set on the command line makes your upgrades harder to audit. Whenever possible, maintain separate values.yaml files for different environments to keep your configuration explicit.
• Ignoring the Revision History: Never assume the current state is the only state. Always check helm history before attempting a manual fix; you might be able to solve the problem with a simple rollback.

FAQ

Does rolling back delete my data? No. Helm rollbacks manage the Kubernetes resource configuration (Deployments, Services, etc.). If your application uses persistent-volumes-and-claims-managing-kubernetes-storage, those volumes remain attached to the underlying nodes.

Can I rollback to any previous version? Yes, as long as the release still exists in the cluster's secret storage. helm history will show you all available revisions.

What happens if the upgrade fails halfway? Helm attempts to maintain "atomic" releases. If an upgrade fails, Helm will try to roll back automatically, though it is always good practice to verify the status with helm status [RELEASE_NAME].

Recap

Managing Helm releases is about mastering the flow of change. By using helm upgrade for updates and helm rollback for recovery, you ensure your cluster remains in a predictable state. Keep your release history clean and use explicit values.yaml files to avoid "configuration drift."

Up next: We will dive into Advanced Networking Concepts, where we’ll explain the CNI (Container Network Interface) and how to visualize pod-to-pod communication.