Software plugins are programs that can be added to existing software applications to enhance their functionality. They are specifically designed to work in sync with the original software and can optimize its performance or offer additional features. Users can install these plugins to customize the software according to their specific requirements. In the case of Helm, plugins can be integrated to extend its core functionality and add extra features.

In this article, we’ll see how to manage plugins in Helm.

Learn how to create a Helm Chart from this blog: What is a Helm Chart? An Absolute Beginners' Guide - with Examples

Managing Plugins in Helm

As we saw, our Helm tool can do many things. But just in case there’s something extra we’d find useful, Helm is extensible. We can add more features, on top of its core functionality, by installing plugins. You can see examples of such plugins on this page.

Plugins are managed with the helm plugin subcommand. As we learned in the first few lessons, we can see detailed info about how we can use this subcommand with:

user@debian:~$ helm plugin -- help

Manage client-side Helm plugins.

Usage:
  helm plugin [command]

Available Commands:
  install     install one or more Helm plugins
  list        list installed Helm plugins
  uninstall   uninstall one or more Helm plugins
  update      update one or more Helm plugins

Flags:
  -h, --help   help for plugin

Global Flags:
      --debug                       enable verbose output
      --kube-apiserver string       the address and the port for the Kubernetes API server
      --kube-as-group stringArray   group to impersonate for the operation, this flag can be repeated to specify multiple groups.
      --kube-as-user string         username to impersonate for the operation
      --kube-ca-file string         the certificate authority file for the Kubernetes API server connection
      --kube-context string         name of the kubeconfig context to use
      --kube-token string           bearer token used for authentication
      --kubeconfig string           path to the kubeconfig file
  -n, --namespace string            namespace scope for this request
      --registry-config string      path to the registry config file (default "/home/user/.config/helm/registry.json")
      --repository-cache string     path to the file containing cached repository indexes (default "/home/user/.cache/helm/repository")
      --repository-config string    path to the file containing repository names and URLs (default "/home/user/.config/helm/repositories.yaml")

Use "helm plugin [command] --help" for more information about a command.

There are various ways we can install plugins, but the most often used (and easiest) is:

helm plugin install https://example.com/path/to/plugin

Instead of providing the URL to a plugin hosted somewhere on the Internet, we can also provide the path to a local directory where we have extracted the plugin’s files (usually from a .tgz or .tar.gz archive we previously downloaded).

helm plugin install path/to/plugin

As usual, though, it’s much easier to understand this through practical exercises, so let’s explore how this works.

Installing and Using a Helm Plugin

When we upgrade a release with Helm, we normally just “trust” that the new chart will do the proper job. But it can be useful if we could actually see what would change. We can do this with the Helm Diff plugin hosted here.

We’ve learned in our previous lessons how to do that using commands such as:

helm install --dry-run nginx-release bitnami/nginx

or

helm template bitnami/nginx

We can actually see the manifests that these charts would generate and send to Kubernetes, without installing anything (a sort of preview).

Let’s install Nginx from Bitnami’s Nginx chart:

helm install nginx-release bitnami/nginx --version 7.1.0

Now imagine we want to upgrade this to the newest available version. A simple helm upgrade command would do the trick, but as mentioned, we just have to blindly trust that it will perform the correct changes. We do have a way to check what manifests this upgrade would send to Kubernetes (without actually upgrading), with a command like:

helm upgrade --dry-run nginx-release bitnami/nginx

But this shows us the final manifests, the end result of the upgrade. It would be more useful if we could actually see the differences between our current manifests deployed into Kubernetes and the new manifests that would get deployed. This is what the Helm Diff plugin can do for us. So let’s install it with:

helm plugin install https://github.com/databus23/helm-diff

The output is very helpful:

user@debian:~$ helm plugin install https://github.com/databus23/helm-diff
Downloading https://github.com/databus23/helm-diff/releases/download/v3.1.3/helm-diff-linux.tgz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   625  100   625    0     0   3188      0 --:--:-- --:--:-- --:--:--  3188
100 14.9M  100 14.9M    0     0  6025k      0  0:00:02  0:00:02 --:--:-- 6860k
Preparing to install into /home/user/.local/share/helm/plugins/helm-diff
helm-diff installed into /home/user/.local/share/helm/plugins/helm-diff/helm-diff

The Helm Diff Plugin

* Shows a diff explaining what a helm upgrade would change:
    This fetches the currently deployed version of a release
  and compares it to a local chart plus values. This can be 
  used visualize what changes a helm upgrade will perform.

* Shows a diff explaining what had changed between two revisions:
    This fetches previously deployed versions of a release
  and compares them. This can be used visualize what changes 
  were made during revision change.

* Shows a diff explaining what a helm rollback would change:
    This fetches the currently deployed version of a release
  and compares it to adeployed versions of a release, that you 
  want to rollback. This can be used visualize what changes a 
  helm rollback will perform.

Usage:
  diff [flags]
  diff [command]

Available Commands:
  release     Shows diff between release's manifests
  revision    Shows diff between revision's manifests
  rollback    Show a diff explaining what a helm rollback could perform
  upgrade     Show a diff explaining what a helm upgrade would change.
  version     Show version of the helm diff plugin

Flags:
      --allow-unreleased             enables diffing of releases that are not yet deployed via Helm
  -C, --context int                  output NUM lines of context around changes (default -1)
      --detailed-exitcode            return a non-zero exit code when there are changes
      --devel                        use development versions, too. Equivalent to version '>0.0.0-0'. If --version is set, this is ignored.
      --disable-openapi-validation   disables rendered templates validation against the Kubernetes OpenAPI Schema
      --disable-validation           disables rendered templates validation against the Kubernetes cluster you are currently pointing to. This is the same validation performed on an install
      --dry-run                      disables cluster access and show diff as if it was install. Implies --install, --reset-values, and --disable-validation
  -h, --help                         help for diff
      --include-tests                enable the diffing of the helm test hooks
      --install                      enables diffing of releases that are not yet deployed via Helm (equivalent to --allow-unreleased, added to match "helm upgrade --install" command
      --kubeconfig string            This flag is ignored, to allow passing of this top level flag to helm
      --no-color                     remove colors from the output
      --no-hooks                     disable diffing of hooks
      --output string                Possible values: diff, simple, json, template. When set to "template", use the env var HELM_DIFF_TPL to specify the template. (default "diff")
      --post-renderer string         the path to an executable to be used for post rendering. If it exists in $PATH, the binary will be used, otherwise it will try to look for the executable at the given path
      --reset-values                 reset the values to the ones built into the chart and merge in any new values
      --reuse-values                 reuse the last release's values and merge in any new values. If '--reset-values' is specified, this is ignored
      --set stringArray              set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)
      --set-file stringArray         set values from respective files specified via the command line (can specify multiple or separate values with commas: key1=path1,key2=path2)
      --set-string stringArray       set STRING values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)
      --show-secrets                 do not redact secret values in the output
      --suppress stringArray         allows suppression of the values listed in the diff output
  -q, --suppress-secrets             suppress secrets in the output
  -f, --values valueFiles            specify values in a YAML file (can specify multiple) (default [])
      --version string               specify the exact chart version to use. If this is not specified, the latest version is used

Additional help topics:
  diff          

Use "diff [command] --help" for more information about a command.
Installed plugin: diff

First of all, this shows us the new subcommands that this plugin adds to Helm. In this case, it’s helm diff. We can consult the plugin’s help page whenever we need with this command:

helm diff --help

We see that we’re not only able to compare the differences an upgrade would generate but also the differences when we roll back to a different revision or the differences between two revisions.

Available Commands:
  release     Shows diff between release's manifests
  revision    Shows diff between revision's manifests
  rollback    Show a diff explaining what a helm rollback could perform
  upgrade     Show a diff explaining what a helm upgrade would change.
  version     Show version of the helm diff plugin

But we might wonder, what’s the command syntax to compare between two revisions? Well, plugins mimic Helm’s core functionality. So that means that just like we can display help info about a Helm sub-sub-command, we can do the same for a plugin’s sub-sub-command. So to see how we would use the helm diff revision command, we just enter:

user@debian:~$ helm diff revision --help

This command compares the manifests details of a named release.

It can be used to compare the manifests of

 - lastest REVISION with specified REVISION
	$ helm diff revision [flags] RELEASE REVISION1
   Example:
	$ helm diff revision my-release 2

 - REVISION1 with REVISION2
	$ helm diff revision [flags] RELEASE REVISION1 REVISION2
   Example:
	$ helm diff revision my-release 2 3

Usage:
  diff revision [flags] RELEASE REVISION1 [REVISION2]

Flags:
  -C, --context int            output NUM lines of context around changes (default -1)
      --detailed-exitcode      return a non-zero exit code when there are changes
  -h, --help                   help for revision
      --include-tests          enable the diffing of the helm test hooks
      --output string          Possible values: diff, simple, template. When set to "template", use the env var HELM_DIFF_TPL to specify the template. (default "diff")
      --show-secrets           do not redact secret values in the output
      --suppress stringArray   allows suppression of the values listed in the diff output
  -q, --suppress-secrets       suppress secrets in the output

Global Flags:
      --no-color   remove colors from the outpu

And we can see in one example how we would compare revision 2 with revision 3 of some releases.

But let’s return to our scenario, seeing what differences an upgrade of our release would generate.

helm diff upgrade nginx-release bitnami/nginx

And we see the differences nicely highlighted with different colors:

In this case, the minus “-” sign signals that the line would get removed by the upgrade, and the “+” sign shows what the upgrade would add to the new manifest. Although the output is a bit long, it’s very easy to read since changes are highlighted this way. We can see that in our case, most of the changes revolve around upgrading nginx-7.1.0 to a newer nginx-9.3.0. In a real scenario, we would be satisfied that the upgrade indeed does what we need it to do.

Listing and Removing Plugins

To see what plugins we currently have installed, we use the following command:

user@debian:~$ helm plugin list
NAME	VERSION	DESCRIPTION                           
diff	3.1.3  	Preview helm upgrade changes as a diff

To remove the plugin:

helm plugin uninstall diff

Now if we try the helm diff command again we see that the functionality was indeed removed from Helm.

user@debian:~$ helm diff
Error: unknown command "diff" for "helm"
Run 'helm --help' for usage.

Check out the Helm for the Absolute Beginners course.

Helm for Beginners | KodeKloud

Learn and get certified with simple and easy hands-on labs

KodeKloud logo

Conclusion

Learning how to use plugins in Helm allows you to create more dynamic charts. However, it's important to manage them correctly to avoid errors when installing the charts.

More on Helm:

• Uploading a Helm Chart
• Package, Sign, and Verify Helm Charts (Commands & Examples)
• Understanding and Building Helm Chart Tests
• NOTES.txt File, Post-Install Upgrade Instructions for Helm Chart Users
• Helm Flow Control with Conditional Control Structures
• What are Template Function and Pipeline in Helm?