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.
Welcome to KodeKloud!
We are the #1 DevOps courses provider. Register today to gain access to the richest collection of DevOps courses and labs and try sample lessons of all our courses.
No credit card required!
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
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.
Checkout the Helm for the Absolute Beginners course here
Checkout the Complete Kubernetes learning path here